From ed19b23c9242378de1cc9e279029da5b9c073945 Mon Sep 17 00:00:00 2001 From: duck Date: Sat, 31 Jul 2010 15:24:13 +0000 Subject: [PATCH 01/75] Website revamp, work in progress. --- www.i2p2/pages/_layout.html | 49 +++- www.i2p2/pages/_menu.html | 347 ++++--------------------- www.i2p2/pages/index.html | 188 ++++++++------ www.i2p2/static/images/btn_left.png | Bin 0 -> 699 bytes www.i2p2/static/images/btn_right.png | Bin 0 -> 686 bytes www.i2p2/static/images/btn_stretch.png | Bin 0 -> 212 bytes www.i2p2/static/styles/960.css | 1 + www.i2p2/static/styles/default.css | 84 ++++++ www.i2p2/static/styles/mainmenu.css | 165 ++++++++++++ 9 files changed, 449 insertions(+), 385 deletions(-) create mode 100644 www.i2p2/static/images/btn_left.png create mode 100644 www.i2p2/static/images/btn_right.png create mode 100644 www.i2p2/static/images/btn_stretch.png create mode 100644 www.i2p2/static/styles/960.css create mode 100644 www.i2p2/static/styles/default.css create mode 100644 www.i2p2/static/styles/mainmenu.css diff --git a/www.i2p2/pages/_layout.html b/www.i2p2/pages/_layout.html index 0271a3af..b75ebf3f 100644 --- a/www.i2p2/pages/_layout.html +++ b/www.i2p2/pages/_layout.html @@ -1,27 +1,48 @@ -{% include "_urlify" %} +{% include "_urlify" -%} {% filter capture('title') %}{% block title %}{% endblock %}{% endfilter %} - I2P - - + + + + - - + + +
Skip navigation
- -

{{ title }}

-
- {% include "_menu.html" %} -
-
- {% block content %}{% endblock %} +
+ +
+
+ {% block content %}{% endblock %} +
diff --git a/www.i2p2/pages/_menu.html b/www.i2p2/pages/_menu.html index 6512639a..d0b066c1 100644 --- a/www.i2p2/pages/_menu.html +++ b/www.i2p2/pages/_menu.html @@ -1,293 +1,56 @@ -
-English -Deutsch -中文 -Français -
-Italiano -Nederlands -Русский -
+
+ +
-
Dark  -Light -
- -{% if lang == "de" %} -
Willkommen bei I2P
-
Download
-
News
- Ankündigungen
- - Entwicklertreffen
- Zeitplan
- Aufgabenliste
-
Über I2P
- FAQ
- Forum
- Prämien
- Beteilige dich
- Spende!
- - I2P Team
- Ruhmeshalle
-
Dokumentationen
- Wie funktioniert es?
- Tech-intro
- Howto Dokumente
- Anwendungen
-
Entwickeln
- API
- Lizenzen
- Trac - -

Syndie
-
Links
-
Mirror -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
- -{% elif lang == "it" %} -
Benvenuti su I2P! -
Download -
News
- Versioni
- - Incontraci
- Roadmap
- Cose-da-fare
-
Informazioni su I2P
- FAQ
- Forum
- Bounties
- Get Involved!
- Donazioni
- - Team I2P
- Hall of Fame
-
Documentazione
- Come funziona?
- Introduzione Tecnica
- Come funziona
- documenti
- Applicazioni
-
Sviluppo
- API
- Licenze
- Trac - -

Syndie
-
Links
-
Mirror 1 -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
- -{% elif lang == "nl" %} -
Welkom bij I2P
-
Download
-
Nieuws
- Aankondigingen
- Vergaderingen
- Routekaart
- Taken lijst
-
Over I2P
- FAQ
- Forum
- Premies
- Werk mee
- Doneer!
- - I2P Team
- Eregalerij
-
Documentation
- Hoe werkt het?
- Tech intro
- Howto docs
- Applicaties
-
Development
- API
- Licenties
- Trac - -

Syndie
-
Links
-
Mirror -
Mirror 2 -
Mirror 3 -
Beveiligde Site -
Beveiligde Mirror -
-
Impressum
- -{% elif lang == "zh" %} -
√ I2P首页
-
√ I2P下载
- - -
项目动态
- 公告
- - - 会议
- 路线图
- 任务
-
I2P简介
- √ 常见问题集
- i2p论坛
- 赏金项目
- 志愿者
- 捐助!
- - I2P团队
- 名人堂
-
技术文档
- 工作原理
- 技术内幕
- 安装指南
- 程序开发
-
开发
- API
- 许可证
- Trac - -

Syndie
-
链接
-
Mirror -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
- -{% elif lang == "fr" %} -
Bienvenue sur I2P
-
Téléchargement
- - -
Nouveautés
- Versions
- - - Rencontres i2p
- Roadmap
- Les choses à faire
-
A propos d'i2p
- Foire aux questions
- I2P forums
- Primes
- Contribuer
- Faire un don
- - L'équipe
- Panthéon des héros
-
Documentation
- Fonctionnement
- Intro technique
- Turoriaux (How to)
- Applications pour I2P
-
Développement
- API
- Licences
- Trac - -

Syndie
-
Liens
-
Mirror -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
- - -{% elif lang == "ru" %} -
Добро пожаловать
-
Скачать
- -
Новости
- Объявления
- Проектные митинги
- План развития
- Список задач
- -
О проекте I2P
- FAQ
- Форумы
- Премии за проекты
- Как стать участником
- Donate!
- - Команда I2P
- Зал Славы
- -
Документация
- Как это работает?
- Техническая вводная
- Howto docs
- Приложения
- -
Разработка
- API
- Лицензии
- Багтрекер - -

Syndie
-
Ссылки
-
Mirror -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
- - -{% else %} -
Welcome to I2P
-
Download
- -
News
- Announcements
- - - Meetings
- Roadmap
- Task list
-
About I2P
- FAQ
- Forums
- Bounties
- Get involved
- Donate!
- - I2P Team
- Hall of Fame
-
Documentation
- How does it work?
- Tech intro
- Howto docs
- Applications
-
Development
- API
- Licenses
- Trac - -

Syndie
-
Links
-
Mirror -
Mirror 2 -
Mirror 3 -
Secure Site -
Secure Mirror -
-
Impressum
-{% endif %} +
+
+English +Deutsch +中文 +Français +Italiano +Nederlands +Русский +
+
diff --git a/www.i2p2/pages/index.html b/www.i2p2/pages/index.html index 3805ef14..e2d97fc1 100644 --- a/www.i2p2/pages/index.html +++ b/www.i2p2/pages/index.html @@ -1,88 +1,118 @@ {% extends "_layout.html" %} {% block title %}I2P Anonymous Network{% endblock %} {% block content %} -
-
-Latest version:
-2010-07-12 - I2P 0.8 - {{ urlify("release-0.8", "Announcement", "html")}} -- Download
-2007-09-28 - Syndie 1.101a - - -- Download +
+
+

What can I2P do for you?

+ +

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 on I2P. Though suitable for general privacy-conscious usage, I2P is also designed to protect users under high risk, such as:

+ +
    +
  • + Activists
    + Coordinate on human rights, free speech, peace. +
    • +
  • + Marginalized groups
    + Associate without threat of ethnic, political, or religious persecution. +
    • +
+ +
-
-Latest News:
-2010-07-12 - I2P 0.8 -Released -
-2010-06-07 - I2P 0.7.14 -Released -
-2010-04-27 - I2P 0.7.13 -Released -
-2010-03-15 - I2P 0.7.12 -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. -

-I2P is growing fast! There were nine releases in 2009, and traffic grew by a factor of 5: -

-

-2009 bandwidth -
-

- -

-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 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 +
+

Get started with I2P

-
+ +
+
+ Download Now +   +
+
+
+ +
+

How does I2P work?

+

+Network diagram

+

On the public Internet your external IP address is unique and provides a strong correlation between your online activities and your true identity. Effective privacy is hard to achieve because the Internet, by design, allows senders and receivers to see each other's external IP address. Another fundamental threat to privacy results from Internet-enabled applications that don't encrypt – or don't sufficiently encrypt – your sensitive communications.

+ +

I2P anonymizes Internet communications by: 1) employing many techniques to make it exceedingly difficult for a receiver to prove the IP address of a sender and vice versa; and 2) by strongly encrypting all communication between the sender and receiver.

+ +

To explore the workings of I2P in further detail please read A Gentle Introduction to the I2P Network. The technically-minded may wish to proceed to the I2P Network Technical Introduction.

+
+
+ +
+
+

Supported Applications

+ +
+ + + + +
{% endblock %} diff --git a/www.i2p2/static/images/btn_left.png b/www.i2p2/static/images/btn_left.png new file mode 100644 index 0000000000000000000000000000000000000000..9e49dd0028f4f784d39eaa1a55b0f46b03092af1 GIT binary patch literal 699 zcmV;s0!00ZP);#Ek>=2XNrVKjBYtZ~g#WkT~Q3;*>;!8>%WkdO$*;!XXuq z!ou!$-o)NIt0ctI$YXo_-kTXO$cToZv0AO}`~CjSY&KhOHk(K6IgS%zmQqF%frG)| zy4UNC%H{G^Hk2&(zd_I4GCLCZkzP=Eu?RI;lg*+S%ei(+JK>{I3 zM_^#qF8Gm<(PIo6jd3zSAq#^b;4)xf&m=*<;6QU=3>Q#ZAZaP=E3ncbG)a*d_MQs_ zjV7oxl4eO+%BO}fy(C1T^vzIQ7(kSS#Au*GsWc@Jh3>U*5kSUCX!Q8d4rFQy;!+y% zn4#5PGqtH>yy?23RYS?;(TF06Xs?0Jh@dtd0D{qK>*N-mPN$gKDz*vYdMYhEvgwl4 ztQ(Y|PL?N$=(gMKO{rA++-kMf$jdT_j*Q_wO41nVB$D>Oh1fu6E(I!$n0y0vAp4An zWL`m(Hnq@*Zw8tcUVe`{8Sx(Kx3Yd7csw58g{bsrsjN;sdmsEJ;rYJ*8dB^7(a{=T zLNwKQ>NO!MEAXZ6L@J-pdz4H>--!cseIYq3Rjbv$&`)2K$z(izV9d22>fgfpX1xFa002ovPDHLkV1mC>LoWaT literal 0 HcmV?d00001 diff --git a/www.i2p2/static/images/btn_right.png b/www.i2p2/static/images/btn_right.png new file mode 100644 index 0000000000000000000000000000000000000000..d4a6d2b8ae87fb30be8c369fec1352a74e9749c1 GIT binary patch literal 686 zcmV;f0#W^mP)2CB6ZLaFP2n1G8 z620o3oNqF78D}@#J#d)e%y+)?y7#bNuXiV1O?RjbvvqtR&02^ezDL&liI9cu2Y)#^T#NaAy*RQ zr;0JT?)UqENZ59}JqWr;C?2F1FdBuxQJhXEPZt9gI2gR7oMD4V0fTOha@LQLlW~l4 zGL_o`8#w~W#PN7!rr9u1DtJ^j!;C20ixFg|iUFeu>oVd*u{Z^2bq73Cj422w0VSNd z&8B&w^);Rei{kveK70666z6E-~sB`om12Sz> zKw{)(gxvaKE=~v)BWYD%39FYjqXMSW=_^`!vfXZHVEpJ7kw_$bTA+!1KA&8#*THNy z`z&g;+O@r;u(&V{TB6=^xeWUK{tbP+AMp6eWvo;xFFKvhn{KyzTP~Lyc>F8C068iw UvLE!R#{d8T07*qoM6N<$f#@c;k- literal 0 HcmV?d00001 diff --git a/www.i2p2/static/images/btn_stretch.png b/www.i2p2/static/images/btn_stretch.png new file mode 100644 index 0000000000000000000000000000000000000000..4dd0197e8eaa83b3ac66bdb5a0221ecdfe113ab4 GIT binary patch literal 212 zcmeAS@N?(olHy`uVBq!ia0vp^j6kfx!3HGlw@oMqQY`6?zK#qG>ra@ocD)4hB}-f* zN`mv#O3D+9QW+dm@{>{(JaZG%Q-e|yQz{EjrrH1%rFptIhE&`t>Aon~puppN`-;E) zp9EgF0`fro1StS@$+x6Y9mQ}k0ZDjCt^>bP0 Hl+XkK>G4X? literal 0 HcmV?d00001 diff --git a/www.i2p2/static/styles/960.css b/www.i2p2/static/styles/960.css new file mode 100644 index 00000000..fe3d05f6 --- /dev/null +++ b/www.i2p2/static/styles/960.css @@ -0,0 +1 @@ +.container_12,.container_16{margin-left:auto;margin-right:auto;width:960px}.grid_1,.grid_2,.grid_3,.grid_4,.grid_5,.grid_6,.grid_7,.grid_8,.grid_9,.grid_10,.grid_11,.grid_12,.grid_13,.grid_14,.grid_15,.grid_16{display:inline;float:left;margin-left:10px;margin-right:10px}.push_1,.pull_1,.push_2,.pull_2,.push_3,.pull_3,.push_4,.pull_4,.push_5,.pull_5,.push_6,.pull_6,.push_7,.pull_7,.push_8,.pull_8,.push_9,.pull_9,.push_10,.pull_10,.push_11,.pull_11,.push_12,.pull_12,.push_13,.pull_13,.push_14,.pull_14,.push_15,.pull_15{position:relative}.container_12 .grid_3,.container_16 .grid_4{width:220px}.container_12 .grid_6,.container_16 .grid_8{width:460px}.container_12 .grid_9,.container_16 .grid_12{width:700px}.container_12 .grid_12,.container_16 .grid_16{width:940px}.alpha{margin-left:0}.omega{margin-right:0}.container_12 .grid_1{width:60px}.container_12 .grid_2{width:140px}.container_12 .grid_4{width:300px}.container_12 .grid_5{width:380px}.container_12 .grid_7{width:540px}.container_12 .grid_8{width:620px}.container_12 .grid_10{width:780px}.container_12 .grid_11{width:860px}.container_16 .grid_1{width:40px}.container_16 .grid_2{width:100px}.container_16 .grid_3{width:160px}.container_16 .grid_5{width:280px}.container_16 .grid_6{width:340px}.container_16 .grid_7{width:400px}.container_16 .grid_9{width:520px}.container_16 .grid_10{width:580px}.container_16 .grid_11{width:640px}.container_16 .grid_13{width:760px}.container_16 .grid_14{width:820px}.container_16 .grid_15{width:880px}.container_12 .prefix_3,.container_16 .prefix_4{padding-left:240px}.container_12 .prefix_6,.container_16 .prefix_8{padding-left:480px}.container_12 .prefix_9,.container_16 .prefix_12{padding-left:720px}.container_12 .prefix_1{padding-left:80px}.container_12 .prefix_2{padding-left:160px}.container_12 .prefix_4{padding-left:320px}.container_12 .prefix_5{padding-left:400px}.container_12 .prefix_7{padding-left:560px}.container_12 .prefix_8{padding-left:640px}.container_12 .prefix_10{padding-left:800px}.container_12 .prefix_11{padding-left:880px}.container_16 .prefix_1{padding-left:60px}.container_16 .prefix_2{padding-left:120px}.container_16 .prefix_3{padding-left:180px}.container_16 .prefix_5{padding-left:300px}.container_16 .prefix_6{padding-left:360px}.container_16 .prefix_7{padding-left:420px}.container_16 .prefix_9{padding-left:540px}.container_16 .prefix_10{padding-left:600px}.container_16 .prefix_11{padding-left:660px}.container_16 .prefix_13{padding-left:780px}.container_16 .prefix_14{padding-left:840px}.container_16 .prefix_15{padding-left:900px}.container_12 .suffix_3,.container_16 .suffix_4{padding-right:240px}.container_12 .suffix_6,.container_16 .suffix_8{padding-right:480px}.container_12 .suffix_9,.container_16 .suffix_12{padding-right:720px}.container_12 .suffix_1{padding-right:80px}.container_12 .suffix_2{padding-right:160px}.container_12 .suffix_4{padding-right:320px}.container_12 .suffix_5{padding-right:400px}.container_12 .suffix_7{padding-right:560px}.container_12 .suffix_8{padding-right:640px}.container_12 .suffix_10{padding-right:800px}.container_12 .suffix_11{padding-right:880px}.container_16 .suffix_1{padding-right:60px}.container_16 .suffix_2{padding-right:120px}.container_16 .suffix_3{padding-right:180px}.container_16 .suffix_5{padding-right:300px}.container_16 .suffix_6{padding-right:360px}.container_16 .suffix_7{padding-right:420px}.container_16 .suffix_9{padding-right:540px}.container_16 .suffix_10{padding-right:600px}.container_16 .suffix_11{padding-right:660px}.container_16 .suffix_13{padding-right:780px}.container_16 .suffix_14{padding-right:840px}.container_16 .suffix_15{padding-right:900px}.container_12 .push_3,.container_16 .push_4{left:240px}.container_12 .push_6,.container_16 .push_8{left:480px}.container_12 .push_9,.container_16 .push_12{left:720px}.container_12 .push_1{left:80px}.container_12 .push_2{left:160px}.container_12 .push_4{left:320px}.container_12 .push_5{left:400px}.container_12 .push_7{left:560px}.container_12 .push_8{left:640px}.container_12 .push_10{left:800px}.container_12 .push_11{left:880px}.container_16 .push_1{left:60px}.container_16 .push_2{left:120px}.container_16 .push_3{left:180px}.container_16 .push_5{left:300px}.container_16 .push_6{left:360px}.container_16 .push_7{left:420px}.container_16 .push_9{left:540px}.container_16 .push_10{left:600px}.container_16 .push_11{left:660px}.container_16 .push_13{left:780px}.container_16 .push_14{left:840px}.container_16 .push_15{left:900px}.container_12 .pull_3,.container_16 .pull_4{left:-240px}.container_12 .pull_6,.container_16 .pull_8{left:-480px}.container_12 .pull_9,.container_16 .pull_12{left:-720px}.container_12 .pull_1{left:-80px}.container_12 .pull_2{left:-160px}.container_12 .pull_4{left:-320px}.container_12 .pull_5{left:-400px}.container_12 .pull_7{left:-560px}.container_12 .pull_8{left:-640px}.container_12 .pull_10{left:-800px}.container_12 .pull_11{left:-880px}.container_16 .pull_1{left:-60px}.container_16 .pull_2{left:-120px}.container_16 .pull_3{left:-180px}.container_16 .pull_5{left:-300px}.container_16 .pull_6{left:-360px}.container_16 .pull_7{left:-420px}.container_16 .pull_9{left:-540px}.container_16 .pull_10{left:-600px}.container_16 .pull_11{left:-660px}.container_16 .pull_13{left:-780px}.container_16 .pull_14{left:-840px}.container_16 .pull_15{left:-900px}.clear{clear:both;display:block;overflow:hidden;visibility:hidden;width:0;height:0}.clearfix:after{clear:both;content:' ';display:block;font-size:0;line-height:0;visibility:hidden;width:0;height:0}* html .clearfix,*:first-child+html .clearfix{zoom:1} \ No newline at end of file diff --git a/www.i2p2/static/styles/default.css b/www.i2p2/static/styles/default.css new file mode 100644 index 00000000..4862060c --- /dev/null +++ b/www.i2p2/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/www.i2p2/static/styles/mainmenu.css b/www.i2p2/static/styles/mainmenu.css new file mode 100644 index 00000000..7299b342 --- /dev/null +++ b/www.i2p2/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 =========================*/ + +.menu { + 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 */ +} + +.menu img { + vertical-align: top; /* prevent images from being pushed down by text */ +} + +.menu 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 */ + +.menu 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 ========================*/ + +.menu ul li ul { + display:none; /* initially hide the entire list hierarchy */ + padding:1px; /* this is our box border width */ +} + +.menu ul li a, +.menu ul li a:visited { /* unselected top-level menu items */ + display:block; + float:left; + text-decoration:none; + height:24px; +} + +/*======================== 2ND LEVEL MENU DEFINITIONS ========================*/ + +.menu ul li:hover ul, +.menu 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 */ +} + +.menu ul li:hover ul.leftbutton, +.menu ul li a:hover ul.leftbutton {/* our first dropdown should not be skewed */ + left:0px; +} + +.menu ul li:hover ul.skinny, +.menu 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) */ +} + +.menu ul.rightmenu li:hover ul, +.menu 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 .menu ul.rightmenu li a:hover ul { /* IE5/6 needs a tweak here */ + right:-1px; +} + +.menu ul li:hover ul li a, +.menu 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; +} + +.menu ul li:hover ul li:hover a, +.menu ul li a:hover ul li a:hover { /* 2nd level selected item */ + color:black; + background:white; +} + +.menu ul li:hover ul.skinny li a, +.menu ul li a:hover ul.skinny li a, +.menu ul li:hover ul.skinny li a:hover, +.menu ul li a:hover ul.skinny li a:hover { /* 2nd level un+selected items */ + width:8.08333em; +} + +/*======================== 3RD LEVEL MENU DEFINITIONS ========================*/ + +.menu ul li:hover ul li ul, +.menu ul li a:hover ul li a ul { /* hide inactive 3rd-level menus */ + visibility:hidden; +} + +.menu ul li:hover ul li:hover ul, +.menu 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; +} + +.menu ul li:hover ul li:hover ul li a, +.menu ul li a:hover ul li a:hover ul li a { /* 3rd level unselected items */ + width:14em; + background:#d8d8d8; +} + +.menu ul li:hover ul li:hover ul li a:hover, +.menu ul li a:hover ul li a:hover ul li a:hover { /* level3 selected items */ + width:14em; + background:white; +} From cdc3328bbf12f17633ecc3869511bdea40b3f2a4 Mon Sep 17 00:00:00 2001 From: dev Date: Wed, 5 Oct 2011 21:35:41 +0000 Subject: [PATCH 02/75] started working on the new version of the website --- app.py | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 76 insertions(+) create mode 100644 app.py diff --git a/app.py b/app.py new file mode 100644 index 00000000..e14803b3 --- /dev/null +++ b/app.py @@ -0,0 +1,76 @@ +from jinja2 import Environment, FileSystemLoader +from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash + +app=application=Flask(__name__, template_folder=TEMPLATE_DIR) +app.debug=bool(os.environ.get('APP_DEBUG', 'False')) + +@app.url_value_preprocessor +def pull_lang(endpoint, values): + if not values: + return + g.lang=values.pop('lang', None) + +@app.view('/') +def main_index(): + redirect(url_for('site_show', lang='en')) + +@app.view('//site/') +@app.view('//site/') +def site_show(page=''): + # TODO: set content_type + +@app.view('//meetings/') +def meetings_index(): + return render_template('meetings/index.html') + +@app.view('//meetings/') +def meetings_show(id): + # TODO: implement + +@app.view('//meetings//raw') +def meetings_show_raw(id): + # TODO: implement + +@app.view('//download') +def downloads_list(): + # TODO: implement + +@app.view('//download/') +def downloads_select(file): + # TODO: implement + +@app.view('/download//any/') +@app.view('/download///') +def downloads_redirect(protocol, file, mirror=None): + # TODO: implement + +@app.view('//blog/') +@app.view('//blog/page/') +def blog_index(page=0): + # TODO: implement + +@app.view('//blog/entry/') +def blog_entry(slug): + # TODO: implement + +@app.view('/feed/blog/rss') +def blog_rss(): + # TODO: implement + +@app.view('/feed/blog/atom') +def blog_atom(): + # TODO: implement + +@app.view('/'): +def legacy_show(f): + # TODO: redirect to correct new url + +@app.view('/meeting') +@app.view('/meeting.html') +def legacy_meeting(id): + redirect(url_for('meetings_show', id=id, lang='en')) + +@app.view('/status---') +@app.view('/status---.html') +def legacy_status(year, month, day): + redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) From 894b9bb72b1b8c48e32b9491aa2983ae6b86c795 Mon Sep 17 00:00:00 2001 From: dev Date: Fri, 1 Jun 2012 21:15:42 +0000 Subject: [PATCH 03/75] finally! some progress --- app.py | 116 ++++++++++++++++++++++++++++++++++++++++++--------------- 1 file changed, 87 insertions(+), 29 deletions(-) diff --git a/app.py b/app.py index e14803b3..7c79e524 100644 --- a/app.py +++ b/app.py @@ -1,8 +1,16 @@ from jinja2 import Environment, FileSystemLoader -from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash +from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash, send_from_directory, safe_join +import os.path +import fileinput + + +TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages') +MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings') + +app = application = Flask(__name__, template_folder=TEMPLATE_DIR) +app.debug = bool(os.environ.get('APP_DEBUG', 'False')) + -app=application=Flask(__name__, template_folder=TEMPLATE_DIR) -app.debug=bool(os.environ.get('APP_DEBUG', 'False')) @app.url_value_preprocessor def pull_lang(endpoint, values): @@ -10,67 +18,117 @@ def pull_lang(endpoint, values): return g.lang=values.pop('lang', None) -@app.view('/') +@app.route('/') def main_index(): - redirect(url_for('site_show', lang='en')) + return redirect(url_for('site_show', lang='en')) -@app.view('//site/') -@app.view('//site/') +@app.route('//site/') +@app.route('//site/') def site_show(page=''): # TODO: set content_type + pass -@app.view('//meetings/') +@app.route('//meetings/') def meetings_index(): return render_template('meetings/index.html') -@app.view('//meetings/') -def meetings_show(id): - # TODO: implement +@app.route('//meetings/') +def meetings_show(id, raw=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) + + log='' + header=None -@app.view('//meetings//raw') + # load log + with open(lfile, 'rb') as fd: + log = fd.read() + + # now try to load header if that makes sense + if os.path.exists(hfile): + with open(hfile, 'rb') as fd: + header = fd.read() + + + + # now only rendering left to do + if raw: + # 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') + else: + return render_template('meetings/show.html', log=log, header=header) + + +@app.route('//meetings//raw') def meetings_show_raw(id): - # TODO: implement + return meetings_show(id, raw=True) -@app.view('//download') +@app.route('//download') def downloads_list(): # TODO: implement + pass -@app.view('//download/') +@app.route('//download/') def downloads_select(file): # TODO: implement + pass -@app.view('/download//any/') -@app.view('/download///') +@app.route('/download//any/') +@app.route('/download///') def downloads_redirect(protocol, file, mirror=None): # TODO: implement + pass -@app.view('//blog/') -@app.view('//blog/page/') +@app.route('//blog/') +@app.route('//blog/page/') def blog_index(page=0): # TODO: implement + pass -@app.view('//blog/entry/') +@app.route('//blog/entry/') def blog_entry(slug): # TODO: implement + pass -@app.view('/feed/blog/rss') +@app.route('/feed/blog/rss') def blog_rss(): # TODO: implement + pass -@app.view('/feed/blog/atom') +@app.route('/feed/blog/atom') def blog_atom(): # TODO: implement + pass -@app.view('/'): -def legacy_show(f): - # TODO: redirect to correct new url -@app.view('/meeting') -@app.view('/meeting.html') + + +## legacy stuff: + +@app.route('/meeting') +@app.route('/meeting.html') def legacy_meeting(id): redirect(url_for('meetings_show', id=id, lang='en')) -@app.view('/status---') -@app.view('/status---.html') +@app.route('/status---') +@app.route('/status---.html') def legacy_status(year, month, day): redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) + + +@app.route('/') +def legacy_show(f): + # TODO: redirect to correct new url + pass From a4571ab6dae8954c0112020dd86e80dc0deacc71 Mon Sep 17 00:00:00 2001 From: dev Date: Fri, 1 Jun 2012 23:15:41 +0000 Subject: [PATCH 04/75] more progress! --- app.py | 79 +++++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 53 insertions(+), 26 deletions(-) diff --git a/app.py b/app.py index 7c79e524..263c26fb 100644 --- a/app.py +++ b/app.py @@ -1,16 +1,30 @@ -from jinja2 import Environment, FileSystemLoader +from jinja2 import Environment, FileSystemLoader, environmentfilter from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash, send_from_directory, safe_join import os.path +import os import fileinput +import codecs TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages') +STATIC_DIR = os.path.join(os.path.dirname(__file__), 'static') + MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings') -app = application = Flask(__name__, template_folder=TEMPLATE_DIR) +app = application = Flask(__name__, template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR) app.debug = bool(os.environ.get('APP_DEBUG', 'False')) +@app.template_filter('restructuredtext') +def restructuredtext(env, value): + try: + from docutils.core import publish_parts + except ImportError: + print u"Install docutils!!11" + raise + parts = publish_parts(source=value, writer_name="html") + return parts['html_body'] + @app.url_value_preprocessor def pull_lang(endpoint, values): @@ -18,6 +32,10 @@ def pull_lang(endpoint, values): return g.lang=values.pop('lang', None) +#@app.url_value_preprocessor +#def fix_theme(endpoint, values): +# pass + @app.route('/') def main_index(): return redirect(url_for('site_show', lang='en')) @@ -33,7 +51,7 @@ def meetings_index(): return render_template('meetings/index.html') @app.route('//meetings/') -def meetings_show(id, raw=False): +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 @@ -48,32 +66,41 @@ def meetings_show(id, raw=False): if not os.path.exists(lfile): abort(404) - log='' - header=None - - # load log - with open(lfile, 'rb') as fd: - log = fd.read() - - # now try to load header if that makes sense - if os.path.exists(hfile): - with open(hfile, 'rb') as fd: - header = fd.read() - - - - # now only rendering left to do - if raw: + # 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') - else: - return render_template('meetings/show.html', log=log, header=header) + + 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) -@app.route('//meetings//raw') -def meetings_show_raw(id): - return meetings_show(id, raw=True) +@app.route('//meetings/.log') +def meetings_show_log(id): + return meetings_show(id, log=True) + +@app.route('//meetings/.rst') +def meetings_show_rst(id): + return meetings_show(id, rst=True) @app.route('//download') def downloads_list(): @@ -120,12 +147,12 @@ def blog_atom(): @app.route('/meeting') @app.route('/meeting.html') def legacy_meeting(id): - redirect(url_for('meetings_show', id=id, lang='en')) + return redirect(url_for('meetings_show', id=id, lang='en')) @app.route('/status---') @app.route('/status---.html') def legacy_status(year, month, day): - redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) + return redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) @app.route('/') From 7baf77ad1c381ca07c33218ccba123d5d8617b9d Mon Sep 17 00:00:00 2001 From: dev Date: Fri, 1 Jun 2012 23:36:38 +0000 Subject: [PATCH 05/75] first kinda working setup well.. kinda... /en/meetings/208 works and that's about it --- app.py | 35 ++++++++- .../pages/meeting208.html => meetings/208.log | 71 ------------------ .../_layout.html => pages/global/layout.html | 14 ++-- .../_menu.html => pages/global/menu.html | 22 +++--- www.i2p2/pages/_urlify => pages/global/urlify | 2 +- .../meetings/index.html | 2 +- {www.i2p2/static => static}/favicon.ico | Bin .../images/I2PTunnel-streamr.png | Bin .../images/add-key-terminal.png | Bin .../images/bandwidth2009.png | Bin {www.i2p2/static => static}/images/cz.png | Bin {www.i2p2/static => static}/images/dark.png | Bin .../static => static}/images/darkbluebg.png | Bin .../static => static}/images/darkbluetile.png | Bin .../images/darkerbluetile.png | Bin {www.i2p2/static => static}/images/de.png | Bin .../static => static}/images/download.png | Bin .../images/download_dark.png | Bin .../images/endToEndEncryption.png | Bin .../images/endToEndEncryption_fr.png | Bin .../images/endToEndEncryption_zh.png | Bin {www.i2p2/static => static}/images/es.png | Bin {www.i2p2/static => static}/images/eu.png | Bin .../images/firefox.options.jpg | Bin .../images/firefox.options_fr.png | Bin .../images/firefox.proxyports.jpg | Bin .../images/firefox.proxyports_fr.png | Bin {www.i2p2/static => static}/images/fr.png | Bin .../static => static}/images/garliccloves.png | Bin {www.i2p2/static => static}/images/help.png | Bin .../static => static}/images/help_dark.png | Bin .../static => static}/images/i2plogo.png | Bin .../images/i2ptunnel_peertopeer.png | Bin .../images/i2ptunnel_serverclient.png | Bin .../static => static}/images/i2pvstor_zh.png | Bin .../static => static}/images/ie.options.jpg | Bin .../images/ie.options_fr.png | Bin .../images/ie.proxyports.jpg | Bin .../images/ie.proxyports_fr.png | Bin {www.i2p2/static => static}/images/info.png | Bin .../static => static}/images/info_dark.png | Bin {www.i2p2/static => static}/images/it.png | Bin .../static => static}/images/itoopie.png | Bin .../images/konqueror.options.jpg | Bin .../images/konqueror.options_fr.jpg | Bin .../images/konqueror.proxyports.jpg | Bin .../images/konqueror.proxyports_fr.jpg | Bin .../static => static}/images/lang_ar.png | Bin {www.i2p2/static => static}/images/light.png | Bin .../images/lightbluetile.png | Bin {www.i2p2/static => static}/images/link.png | Bin .../static => static}/images/link_dark.png | Bin .../static => static}/images/logo07c.jpg | Bin {www.i2p2/static => static}/images/net.png | Bin {www.i2p2/static => static}/images/net_fr.png | Bin .../images/netdb_get_leaseset.png | Bin .../images/netdb_get_leaseset_fr.png | Bin .../images/netdb_get_routerinfo_1.png | Bin .../images/netdb_get_routerinfo_1_fr.png | Bin .../images/netdb_get_routerinfo_2.png | Bin .../images/netdb_get_routerinfo_2_fr.png | Bin {www.i2p2/static => static}/images/nl.png | Bin {www.i2p2/static => static}/images/plan.png | Bin .../images/protocol_stack.png | Bin .../images/protocol_stack_fr.png | Bin {www.i2p2/static => static}/images/ru.png | Bin .../static => static}/images/sqbullet.png | Bin .../images/stackoverflow_ad.png | Bin .../static => static}/images/tabletile.png | Bin .../images/tabletile_alt.png | Bin .../images/tabletitledark.png | Bin .../images/tabletitlelight-tall.png | Bin .../images/tabletitlelight.png | Bin {www.i2p2/static => static}/images/target.png | Bin .../images/tunnelSending.png | Bin .../static => static}/images/tunnels.png | Bin .../static => static}/images/tunnels_fr.png | Bin {www.i2p2/static => static}/images/udp.png | Bin {www.i2p2/static => static}/images/us.png | Bin {www.i2p2/static => static}/images/zh.png | Bin {www.i2p2/static => static}/news/news.xml | 0 {www.i2p2/static => static}/pdf/I2CP_spec.pdf | Bin {www.i2p2/static => static}/pdf/I2NP_spec.pdf | Bin .../pdf/I2P-PET-CON-2009.1.pdf | Bin .../static => static}/pdf/datastructures.pdf | Bin .../static => static}/pdf/i2p_philosophy.pdf | Bin .../pdf/polling_http_transport.pdf | Bin {www.i2p2/static => static}/styles/dark.css | 0 {www.i2p2/static => static}/styles/light.css | 0 .../static => static}/styles/light_ar.css | 0 .../static => static}/styles/light_zh.css | 0 91 files changed, 51 insertions(+), 95 deletions(-) rename www.i2p2/pages/meeting208.html => meetings/208.log (83%) rename www.i2p2/pages/_layout.html => pages/global/layout.html (59%) rename www.i2p2/pages/_menu.html => pages/global/menu.html (95%) rename www.i2p2/pages/_urlify => pages/global/urlify (79%) rename www.i2p2/pages/meetings.html => pages/meetings/index.html (99%) rename {www.i2p2/static => static}/favicon.ico (100%) rename {www.i2p2/static => static}/images/I2PTunnel-streamr.png (100%) rename {www.i2p2/static => static}/images/add-key-terminal.png (100%) rename {www.i2p2/static => static}/images/bandwidth2009.png (100%) rename {www.i2p2/static => static}/images/cz.png (100%) rename {www.i2p2/static => static}/images/dark.png (100%) rename {www.i2p2/static => static}/images/darkbluebg.png (100%) rename {www.i2p2/static => static}/images/darkbluetile.png (100%) rename {www.i2p2/static => static}/images/darkerbluetile.png (100%) rename {www.i2p2/static => static}/images/de.png (100%) rename {www.i2p2/static => static}/images/download.png (100%) rename {www.i2p2/static => static}/images/download_dark.png (100%) rename {www.i2p2/static => static}/images/endToEndEncryption.png (100%) rename {www.i2p2/static => static}/images/endToEndEncryption_fr.png (100%) rename {www.i2p2/static => static}/images/endToEndEncryption_zh.png (100%) rename {www.i2p2/static => static}/images/es.png (100%) rename {www.i2p2/static => static}/images/eu.png (100%) rename {www.i2p2/static => static}/images/firefox.options.jpg (100%) rename {www.i2p2/static => static}/images/firefox.options_fr.png (100%) rename {www.i2p2/static => static}/images/firefox.proxyports.jpg (100%) rename {www.i2p2/static => static}/images/firefox.proxyports_fr.png (100%) rename {www.i2p2/static => static}/images/fr.png (100%) rename {www.i2p2/static => static}/images/garliccloves.png (100%) rename {www.i2p2/static => static}/images/help.png (100%) rename {www.i2p2/static => static}/images/help_dark.png (100%) rename {www.i2p2/static => static}/images/i2plogo.png (100%) rename {www.i2p2/static => static}/images/i2ptunnel_peertopeer.png (100%) rename {www.i2p2/static => static}/images/i2ptunnel_serverclient.png (100%) rename {www.i2p2/static => static}/images/i2pvstor_zh.png (100%) rename {www.i2p2/static => static}/images/ie.options.jpg (100%) rename {www.i2p2/static => static}/images/ie.options_fr.png (100%) rename {www.i2p2/static => static}/images/ie.proxyports.jpg (100%) rename {www.i2p2/static => static}/images/ie.proxyports_fr.png (100%) rename {www.i2p2/static => static}/images/info.png (100%) rename {www.i2p2/static => static}/images/info_dark.png (100%) rename {www.i2p2/static => static}/images/it.png (100%) rename {www.i2p2/static => static}/images/itoopie.png (100%) rename {www.i2p2/static => static}/images/konqueror.options.jpg (100%) rename {www.i2p2/static => static}/images/konqueror.options_fr.jpg (100%) rename {www.i2p2/static => static}/images/konqueror.proxyports.jpg (100%) rename {www.i2p2/static => static}/images/konqueror.proxyports_fr.jpg (100%) rename {www.i2p2/static => static}/images/lang_ar.png (100%) rename {www.i2p2/static => static}/images/light.png (100%) rename {www.i2p2/static => static}/images/lightbluetile.png (100%) rename {www.i2p2/static => static}/images/link.png (100%) rename {www.i2p2/static => static}/images/link_dark.png (100%) rename {www.i2p2/static => static}/images/logo07c.jpg (100%) rename {www.i2p2/static => static}/images/net.png (100%) rename {www.i2p2/static => static}/images/net_fr.png (100%) rename {www.i2p2/static => static}/images/netdb_get_leaseset.png (100%) rename {www.i2p2/static => static}/images/netdb_get_leaseset_fr.png (100%) rename {www.i2p2/static => static}/images/netdb_get_routerinfo_1.png (100%) rename {www.i2p2/static => static}/images/netdb_get_routerinfo_1_fr.png (100%) rename {www.i2p2/static => static}/images/netdb_get_routerinfo_2.png (100%) rename {www.i2p2/static => static}/images/netdb_get_routerinfo_2_fr.png (100%) rename {www.i2p2/static => static}/images/nl.png (100%) rename {www.i2p2/static => static}/images/plan.png (100%) rename {www.i2p2/static => static}/images/protocol_stack.png (100%) rename {www.i2p2/static => static}/images/protocol_stack_fr.png (100%) rename {www.i2p2/static => static}/images/ru.png (100%) rename {www.i2p2/static => static}/images/sqbullet.png (100%) rename {www.i2p2/static => static}/images/stackoverflow_ad.png (100%) rename {www.i2p2/static => static}/images/tabletile.png (100%) rename {www.i2p2/static => static}/images/tabletile_alt.png (100%) rename {www.i2p2/static => static}/images/tabletitledark.png (100%) rename {www.i2p2/static => static}/images/tabletitlelight-tall.png (100%) rename {www.i2p2/static => static}/images/tabletitlelight.png (100%) rename {www.i2p2/static => static}/images/target.png (100%) rename {www.i2p2/static => static}/images/tunnelSending.png (100%) rename {www.i2p2/static => static}/images/tunnels.png (100%) rename {www.i2p2/static => static}/images/tunnels_fr.png (100%) rename {www.i2p2/static => static}/images/udp.png (100%) rename {www.i2p2/static => static}/images/us.png (100%) rename {www.i2p2/static => static}/images/zh.png (100%) rename {www.i2p2/static => static}/news/news.xml (100%) rename {www.i2p2/static => static}/pdf/I2CP_spec.pdf (100%) rename {www.i2p2/static => static}/pdf/I2NP_spec.pdf (100%) rename {www.i2p2/static => static}/pdf/I2P-PET-CON-2009.1.pdf (100%) rename {www.i2p2/static => static}/pdf/datastructures.pdf (100%) rename {www.i2p2/static => static}/pdf/i2p_philosophy.pdf (100%) rename {www.i2p2/static => static}/pdf/polling_http_transport.pdf (100%) rename {www.i2p2/static => static}/styles/dark.css (100%) rename {www.i2p2/static => static}/styles/light.css (100%) rename {www.i2p2/static => static}/styles/light_ar.css (100%) rename {www.i2p2/static => static}/styles/light_zh.css (100%) diff --git a/app.py b/app.py index 263c26fb..5108529b 100644 --- a/app.py +++ b/app.py @@ -14,9 +14,21 @@ MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings') app = application = Flask(__name__, template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR) app.debug = bool(os.environ.get('APP_DEBUG', 'False')) +@app.after_request +def call_after_request_callbacks(response): + for callback in getattr(g, 'after_request_callbacks', ()): + response = callback(response) + return response + +def after_this_request(f): + if not hasattr(g, 'after_request_callbacks'): + g.after_request_callbacks = [] + g.after_request_callbacks.append(f) + return f + @app.template_filter('restructuredtext') -def restructuredtext(env, value): +def restructuredtext(value): try: from docutils.core import publish_parts except ImportError: @@ -32,9 +44,24 @@ def pull_lang(endpoint, values): return g.lang=values.pop('lang', None) -#@app.url_value_preprocessor -#def fix_theme(endpoint, values): -# pass +@app.before_request +def detect_theme(): + theme = 'light' + if 'style' in request.cookies: + theme = request.cookies['style'] + if 'theme' in request.args.keys(): + theme = request.args['theme'] + if not os.path.isfile(safe_join('static/styles', '%s.css' % theme)): + theme = 'light' + g.theme = theme + @after_this_request + def remember_theme(resp): + if g.theme == 'light' and 'style' in request.cookies: + resp.delete_cookie('style') + elif g.theme != 'light': + resp.set_cookie('style', g.theme) + return resp + @app.route('/') def main_index(): diff --git a/www.i2p2/pages/meeting208.html b/meetings/208.log similarity index 83% rename from www.i2p2/pages/meeting208.html rename to meetings/208.log index 18448cd8..0d0f5157 100644 --- a/www.i2p2/pages/meeting208.html +++ b/meetings/208.log @@ -1,69 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 208{% endblock %} -{% block content %}

I2P dev meeting, September 8, 2010

-
-

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. -

    -
    • -
-
-
-

Full IRC Log

-
-{% 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 #}
-
-
-{% endblock %} diff --git a/www.i2p2/pages/_layout.html b/pages/global/layout.html similarity index 59% rename from www.i2p2/pages/_layout.html rename to pages/global/layout.html index 26fa7599..4889c68a 100644 --- a/www.i2p2/pages/_layout.html +++ b/pages/global/layout.html @@ -1,24 +1,24 @@ -{% include "_urlify" -%} +{% include "global/urlify" -%} - {% filter capture('title') %}{% block title %}{% endblock %}{% endfilter %} - I2P + {% block title %}{% endblock %} - I2P - - + +
Skip navigation
-

{{ title }}

+

{{ self.title() }}

- {% include "_menu.html" %} + {% include "global/menu.html" %}
{% block content %}{% endblock %} diff --git a/www.i2p2/pages/_menu.html b/pages/global/menu.html similarity index 95% rename from www.i2p2/pages/_menu.html rename to pages/global/menu.html index 046e00a2..86adfcae 100644 --- a/www.i2p2/pages/_menu.html +++ b/pages/global/menu.html @@ -1,20 +1,20 @@
-English -Deutsch -Castellano -中文 +English +Deutsch +Castellano +中文
-Français -Italiano -Nederlands -Русский +Français +Italiano +Nederlands +Русский
-Čeština -العربية +Čeština +العربية
Dark  -Light +Light
{% if lang == "de" %} diff --git a/www.i2p2/pages/_urlify b/pages/global/urlify similarity index 79% rename from www.i2p2/pages/_urlify rename to pages/global/urlify index a9bdbf3d..59ffe02c 100644 --- a/www.i2p2/pages/_urlify +++ b/pages/global/urlify @@ -1,4 +1,4 @@ -{% macro urlify url, title, suffix %} +{% macro urlify(url, title, suffix) %} {% if static %} {{title}} {% else %} diff --git a/www.i2p2/pages/meetings.html b/pages/meetings/index.html similarity index 99% rename from www.i2p2/pages/meetings.html rename to pages/meetings/index.html index 9e65b231..b8effc6b 100644 --- a/www.i2p2/pages/meetings.html +++ b/pages/meetings/index.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Meetings{% endblock %} {% block content %}

Logs of past I2P meetings

diff --git a/www.i2p2/static/favicon.ico b/static/favicon.ico similarity index 100% rename from www.i2p2/static/favicon.ico rename to static/favicon.ico diff --git a/www.i2p2/static/images/I2PTunnel-streamr.png b/static/images/I2PTunnel-streamr.png similarity index 100% rename from www.i2p2/static/images/I2PTunnel-streamr.png rename to static/images/I2PTunnel-streamr.png diff --git a/www.i2p2/static/images/add-key-terminal.png b/static/images/add-key-terminal.png similarity index 100% rename from www.i2p2/static/images/add-key-terminal.png rename to static/images/add-key-terminal.png diff --git a/www.i2p2/static/images/bandwidth2009.png b/static/images/bandwidth2009.png similarity index 100% rename from www.i2p2/static/images/bandwidth2009.png rename to static/images/bandwidth2009.png diff --git a/www.i2p2/static/images/cz.png b/static/images/cz.png similarity index 100% rename from www.i2p2/static/images/cz.png rename to static/images/cz.png diff --git a/www.i2p2/static/images/dark.png b/static/images/dark.png similarity index 100% rename from www.i2p2/static/images/dark.png rename to static/images/dark.png diff --git a/www.i2p2/static/images/darkbluebg.png b/static/images/darkbluebg.png similarity index 100% rename from www.i2p2/static/images/darkbluebg.png rename to static/images/darkbluebg.png diff --git a/www.i2p2/static/images/darkbluetile.png b/static/images/darkbluetile.png similarity index 100% rename from www.i2p2/static/images/darkbluetile.png rename to static/images/darkbluetile.png diff --git a/www.i2p2/static/images/darkerbluetile.png b/static/images/darkerbluetile.png similarity index 100% rename from www.i2p2/static/images/darkerbluetile.png rename to static/images/darkerbluetile.png diff --git a/www.i2p2/static/images/de.png b/static/images/de.png similarity index 100% rename from www.i2p2/static/images/de.png rename to static/images/de.png diff --git a/www.i2p2/static/images/download.png b/static/images/download.png similarity index 100% rename from www.i2p2/static/images/download.png rename to static/images/download.png diff --git a/www.i2p2/static/images/download_dark.png b/static/images/download_dark.png similarity index 100% rename from www.i2p2/static/images/download_dark.png rename to static/images/download_dark.png diff --git a/www.i2p2/static/images/endToEndEncryption.png b/static/images/endToEndEncryption.png similarity index 100% rename from www.i2p2/static/images/endToEndEncryption.png rename to static/images/endToEndEncryption.png diff --git a/www.i2p2/static/images/endToEndEncryption_fr.png b/static/images/endToEndEncryption_fr.png similarity index 100% rename from www.i2p2/static/images/endToEndEncryption_fr.png rename to static/images/endToEndEncryption_fr.png diff --git a/www.i2p2/static/images/endToEndEncryption_zh.png b/static/images/endToEndEncryption_zh.png similarity index 100% rename from www.i2p2/static/images/endToEndEncryption_zh.png rename to static/images/endToEndEncryption_zh.png diff --git a/www.i2p2/static/images/es.png b/static/images/es.png similarity index 100% rename from www.i2p2/static/images/es.png rename to static/images/es.png diff --git a/www.i2p2/static/images/eu.png b/static/images/eu.png similarity index 100% rename from www.i2p2/static/images/eu.png rename to static/images/eu.png diff --git a/www.i2p2/static/images/firefox.options.jpg b/static/images/firefox.options.jpg similarity index 100% rename from www.i2p2/static/images/firefox.options.jpg rename to static/images/firefox.options.jpg diff --git a/www.i2p2/static/images/firefox.options_fr.png b/static/images/firefox.options_fr.png similarity index 100% rename from www.i2p2/static/images/firefox.options_fr.png rename to static/images/firefox.options_fr.png diff --git a/www.i2p2/static/images/firefox.proxyports.jpg b/static/images/firefox.proxyports.jpg similarity index 100% rename from www.i2p2/static/images/firefox.proxyports.jpg rename to static/images/firefox.proxyports.jpg diff --git a/www.i2p2/static/images/firefox.proxyports_fr.png b/static/images/firefox.proxyports_fr.png similarity index 100% rename from www.i2p2/static/images/firefox.proxyports_fr.png rename to static/images/firefox.proxyports_fr.png diff --git a/www.i2p2/static/images/fr.png b/static/images/fr.png similarity index 100% rename from www.i2p2/static/images/fr.png rename to static/images/fr.png diff --git a/www.i2p2/static/images/garliccloves.png b/static/images/garliccloves.png similarity index 100% rename from www.i2p2/static/images/garliccloves.png rename to static/images/garliccloves.png diff --git a/www.i2p2/static/images/help.png b/static/images/help.png similarity index 100% rename from www.i2p2/static/images/help.png rename to static/images/help.png diff --git a/www.i2p2/static/images/help_dark.png b/static/images/help_dark.png similarity index 100% rename from www.i2p2/static/images/help_dark.png rename to static/images/help_dark.png diff --git a/www.i2p2/static/images/i2plogo.png b/static/images/i2plogo.png similarity index 100% rename from www.i2p2/static/images/i2plogo.png rename to static/images/i2plogo.png diff --git a/www.i2p2/static/images/i2ptunnel_peertopeer.png b/static/images/i2ptunnel_peertopeer.png similarity index 100% rename from www.i2p2/static/images/i2ptunnel_peertopeer.png rename to static/images/i2ptunnel_peertopeer.png diff --git a/www.i2p2/static/images/i2ptunnel_serverclient.png b/static/images/i2ptunnel_serverclient.png similarity index 100% rename from www.i2p2/static/images/i2ptunnel_serverclient.png rename to static/images/i2ptunnel_serverclient.png diff --git a/www.i2p2/static/images/i2pvstor_zh.png b/static/images/i2pvstor_zh.png similarity index 100% rename from www.i2p2/static/images/i2pvstor_zh.png rename to static/images/i2pvstor_zh.png diff --git a/www.i2p2/static/images/ie.options.jpg b/static/images/ie.options.jpg similarity index 100% rename from www.i2p2/static/images/ie.options.jpg rename to static/images/ie.options.jpg diff --git a/www.i2p2/static/images/ie.options_fr.png b/static/images/ie.options_fr.png similarity index 100% rename from www.i2p2/static/images/ie.options_fr.png rename to static/images/ie.options_fr.png diff --git a/www.i2p2/static/images/ie.proxyports.jpg b/static/images/ie.proxyports.jpg similarity index 100% rename from www.i2p2/static/images/ie.proxyports.jpg rename to static/images/ie.proxyports.jpg diff --git a/www.i2p2/static/images/ie.proxyports_fr.png b/static/images/ie.proxyports_fr.png similarity index 100% rename from www.i2p2/static/images/ie.proxyports_fr.png rename to static/images/ie.proxyports_fr.png diff --git a/www.i2p2/static/images/info.png b/static/images/info.png similarity index 100% rename from www.i2p2/static/images/info.png rename to static/images/info.png diff --git a/www.i2p2/static/images/info_dark.png b/static/images/info_dark.png similarity index 100% rename from www.i2p2/static/images/info_dark.png rename to static/images/info_dark.png diff --git a/www.i2p2/static/images/it.png b/static/images/it.png similarity index 100% rename from www.i2p2/static/images/it.png rename to static/images/it.png diff --git a/www.i2p2/static/images/itoopie.png b/static/images/itoopie.png similarity index 100% rename from www.i2p2/static/images/itoopie.png rename to static/images/itoopie.png diff --git a/www.i2p2/static/images/konqueror.options.jpg b/static/images/konqueror.options.jpg similarity index 100% rename from www.i2p2/static/images/konqueror.options.jpg rename to static/images/konqueror.options.jpg diff --git a/www.i2p2/static/images/konqueror.options_fr.jpg b/static/images/konqueror.options_fr.jpg similarity index 100% rename from www.i2p2/static/images/konqueror.options_fr.jpg rename to static/images/konqueror.options_fr.jpg diff --git a/www.i2p2/static/images/konqueror.proxyports.jpg b/static/images/konqueror.proxyports.jpg similarity index 100% rename from www.i2p2/static/images/konqueror.proxyports.jpg rename to static/images/konqueror.proxyports.jpg diff --git a/www.i2p2/static/images/konqueror.proxyports_fr.jpg b/static/images/konqueror.proxyports_fr.jpg similarity index 100% rename from www.i2p2/static/images/konqueror.proxyports_fr.jpg rename to static/images/konqueror.proxyports_fr.jpg diff --git a/www.i2p2/static/images/lang_ar.png b/static/images/lang_ar.png similarity index 100% rename from www.i2p2/static/images/lang_ar.png rename to static/images/lang_ar.png diff --git a/www.i2p2/static/images/light.png b/static/images/light.png similarity index 100% rename from www.i2p2/static/images/light.png rename to static/images/light.png diff --git a/www.i2p2/static/images/lightbluetile.png b/static/images/lightbluetile.png similarity index 100% rename from www.i2p2/static/images/lightbluetile.png rename to static/images/lightbluetile.png diff --git a/www.i2p2/static/images/link.png b/static/images/link.png similarity index 100% rename from www.i2p2/static/images/link.png rename to static/images/link.png diff --git a/www.i2p2/static/images/link_dark.png b/static/images/link_dark.png similarity index 100% rename from www.i2p2/static/images/link_dark.png rename to static/images/link_dark.png diff --git a/www.i2p2/static/images/logo07c.jpg b/static/images/logo07c.jpg similarity index 100% rename from www.i2p2/static/images/logo07c.jpg rename to static/images/logo07c.jpg diff --git a/www.i2p2/static/images/net.png b/static/images/net.png similarity index 100% rename from www.i2p2/static/images/net.png rename to static/images/net.png diff --git a/www.i2p2/static/images/net_fr.png b/static/images/net_fr.png similarity index 100% rename from www.i2p2/static/images/net_fr.png rename to static/images/net_fr.png diff --git a/www.i2p2/static/images/netdb_get_leaseset.png b/static/images/netdb_get_leaseset.png similarity index 100% rename from www.i2p2/static/images/netdb_get_leaseset.png rename to static/images/netdb_get_leaseset.png diff --git a/www.i2p2/static/images/netdb_get_leaseset_fr.png b/static/images/netdb_get_leaseset_fr.png similarity index 100% rename from www.i2p2/static/images/netdb_get_leaseset_fr.png rename to static/images/netdb_get_leaseset_fr.png diff --git a/www.i2p2/static/images/netdb_get_routerinfo_1.png b/static/images/netdb_get_routerinfo_1.png similarity index 100% rename from www.i2p2/static/images/netdb_get_routerinfo_1.png rename to static/images/netdb_get_routerinfo_1.png diff --git a/www.i2p2/static/images/netdb_get_routerinfo_1_fr.png b/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 static/images/netdb_get_routerinfo_1_fr.png diff --git a/www.i2p2/static/images/netdb_get_routerinfo_2.png b/static/images/netdb_get_routerinfo_2.png similarity index 100% rename from www.i2p2/static/images/netdb_get_routerinfo_2.png rename to static/images/netdb_get_routerinfo_2.png diff --git a/www.i2p2/static/images/netdb_get_routerinfo_2_fr.png b/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 static/images/netdb_get_routerinfo_2_fr.png diff --git a/www.i2p2/static/images/nl.png b/static/images/nl.png similarity index 100% rename from www.i2p2/static/images/nl.png rename to static/images/nl.png diff --git a/www.i2p2/static/images/plan.png b/static/images/plan.png similarity index 100% rename from www.i2p2/static/images/plan.png rename to static/images/plan.png diff --git a/www.i2p2/static/images/protocol_stack.png b/static/images/protocol_stack.png similarity index 100% rename from www.i2p2/static/images/protocol_stack.png rename to static/images/protocol_stack.png diff --git a/www.i2p2/static/images/protocol_stack_fr.png b/static/images/protocol_stack_fr.png similarity index 100% rename from www.i2p2/static/images/protocol_stack_fr.png rename to static/images/protocol_stack_fr.png diff --git a/www.i2p2/static/images/ru.png b/static/images/ru.png similarity index 100% rename from www.i2p2/static/images/ru.png rename to static/images/ru.png diff --git a/www.i2p2/static/images/sqbullet.png b/static/images/sqbullet.png similarity index 100% rename from www.i2p2/static/images/sqbullet.png rename to static/images/sqbullet.png diff --git a/www.i2p2/static/images/stackoverflow_ad.png b/static/images/stackoverflow_ad.png similarity index 100% rename from www.i2p2/static/images/stackoverflow_ad.png rename to static/images/stackoverflow_ad.png diff --git a/www.i2p2/static/images/tabletile.png b/static/images/tabletile.png similarity index 100% rename from www.i2p2/static/images/tabletile.png rename to static/images/tabletile.png diff --git a/www.i2p2/static/images/tabletile_alt.png b/static/images/tabletile_alt.png similarity index 100% rename from www.i2p2/static/images/tabletile_alt.png rename to static/images/tabletile_alt.png diff --git a/www.i2p2/static/images/tabletitledark.png b/static/images/tabletitledark.png similarity index 100% rename from www.i2p2/static/images/tabletitledark.png rename to static/images/tabletitledark.png diff --git a/www.i2p2/static/images/tabletitlelight-tall.png b/static/images/tabletitlelight-tall.png similarity index 100% rename from www.i2p2/static/images/tabletitlelight-tall.png rename to static/images/tabletitlelight-tall.png diff --git a/www.i2p2/static/images/tabletitlelight.png b/static/images/tabletitlelight.png similarity index 100% rename from www.i2p2/static/images/tabletitlelight.png rename to static/images/tabletitlelight.png diff --git a/www.i2p2/static/images/target.png b/static/images/target.png similarity index 100% rename from www.i2p2/static/images/target.png rename to static/images/target.png diff --git a/www.i2p2/static/images/tunnelSending.png b/static/images/tunnelSending.png similarity index 100% rename from www.i2p2/static/images/tunnelSending.png rename to static/images/tunnelSending.png diff --git a/www.i2p2/static/images/tunnels.png b/static/images/tunnels.png similarity index 100% rename from www.i2p2/static/images/tunnels.png rename to static/images/tunnels.png diff --git a/www.i2p2/static/images/tunnels_fr.png b/static/images/tunnels_fr.png similarity index 100% rename from www.i2p2/static/images/tunnels_fr.png rename to static/images/tunnels_fr.png diff --git a/www.i2p2/static/images/udp.png b/static/images/udp.png similarity index 100% rename from www.i2p2/static/images/udp.png rename to static/images/udp.png diff --git a/www.i2p2/static/images/us.png b/static/images/us.png similarity index 100% rename from www.i2p2/static/images/us.png rename to static/images/us.png diff --git a/www.i2p2/static/images/zh.png b/static/images/zh.png similarity index 100% rename from www.i2p2/static/images/zh.png rename to static/images/zh.png diff --git a/www.i2p2/static/news/news.xml b/static/news/news.xml similarity index 100% rename from www.i2p2/static/news/news.xml rename to static/news/news.xml diff --git a/www.i2p2/static/pdf/I2CP_spec.pdf b/static/pdf/I2CP_spec.pdf similarity index 100% rename from www.i2p2/static/pdf/I2CP_spec.pdf rename to static/pdf/I2CP_spec.pdf diff --git a/www.i2p2/static/pdf/I2NP_spec.pdf b/static/pdf/I2NP_spec.pdf similarity index 100% rename from www.i2p2/static/pdf/I2NP_spec.pdf rename to static/pdf/I2NP_spec.pdf diff --git a/www.i2p2/static/pdf/I2P-PET-CON-2009.1.pdf b/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 static/pdf/I2P-PET-CON-2009.1.pdf diff --git a/www.i2p2/static/pdf/datastructures.pdf b/static/pdf/datastructures.pdf similarity index 100% rename from www.i2p2/static/pdf/datastructures.pdf rename to static/pdf/datastructures.pdf diff --git a/www.i2p2/static/pdf/i2p_philosophy.pdf b/static/pdf/i2p_philosophy.pdf similarity index 100% rename from www.i2p2/static/pdf/i2p_philosophy.pdf rename to static/pdf/i2p_philosophy.pdf diff --git a/www.i2p2/static/pdf/polling_http_transport.pdf b/static/pdf/polling_http_transport.pdf similarity index 100% rename from www.i2p2/static/pdf/polling_http_transport.pdf rename to static/pdf/polling_http_transport.pdf diff --git a/www.i2p2/static/styles/dark.css b/static/styles/dark.css similarity index 100% rename from www.i2p2/static/styles/dark.css rename to static/styles/dark.css diff --git a/www.i2p2/static/styles/light.css b/static/styles/light.css similarity index 100% rename from www.i2p2/static/styles/light.css rename to static/styles/light.css diff --git a/www.i2p2/static/styles/light_ar.css b/static/styles/light_ar.css similarity index 100% rename from www.i2p2/static/styles/light_ar.css rename to static/styles/light_ar.css diff --git a/www.i2p2/static/styles/light_zh.css b/static/styles/light_zh.css similarity index 100% rename from www.i2p2/static/styles/light_zh.css rename to static/styles/light_zh.css From b26bbd81d98b93f91282274c4e2d89a9168d18c9 Mon Sep 17 00:00:00 2001 From: dev Date: Sun, 3 Jun 2012 01:06:09 +0000 Subject: [PATCH 06/75] 1/2 of blog implementation done! --- app.py | 94 ++++++++++++++++--- .../2006/10/10/status.html | 9 +- blog/2006/10/10/status.rst | 6 ++ .../downloads/list.html | 2 +- pages/global/error_404.html | 21 +++++ pages/global/urlify | 2 + {www.i2p2/pages => pages/site}/index.html | 5 +- www.i2p2/pages/not_found.html | 5 - www.i2p2/pages/not_found_de.html | 5 - www.i2p2/pages/not_found_zh.html | 7 -- 10 files changed, 115 insertions(+), 41 deletions(-) rename www.i2p2/pages/status-2006-10-10.html => blog/2006/10/10/status.html (94%) create mode 100644 blog/2006/10/10/status.rst rename www.i2p2/pages/download.html => pages/downloads/list.html (99%) create mode 100644 pages/global/error_404.html rename {www.i2p2/pages => pages/site}/index.html (94%) delete mode 100644 www.i2p2/pages/not_found.html delete mode 100644 www.i2p2/pages/not_found_de.html delete mode 100644 www.i2p2/pages/not_found_zh.html diff --git a/app.py b/app.py index 5108529b..866b6308 100644 --- a/app.py +++ b/app.py @@ -1,5 +1,6 @@ from jinja2 import Environment, FileSystemLoader, environmentfilter from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash, send_from_directory, safe_join +from docutils.core import publish_parts import os.path import os import fileinput @@ -9,6 +10,7 @@ import codecs 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') app = application = Flask(__name__, template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR) @@ -29,11 +31,6 @@ def after_this_request(f): @app.template_filter('restructuredtext') def restructuredtext(value): - try: - from docutils.core import publish_parts - except ImportError: - print u"Install docutils!!11" - raise parts = publish_parts(source=value, writer_name="html") return parts['html_body'] @@ -44,6 +41,15 @@ def pull_lang(endpoint, values): return g.lang=values.pop('lang', None) +@app.url_defaults +def set_lang(endpoint, values): + if not values: + return + if 'lang' in values: + return + if hasattr(g, 'lang'): + values['lang'] = g.lang + @app.before_request def detect_theme(): theme = 'light' @@ -63,15 +69,30 @@ def detect_theme(): return resp +@app.errorhandler(404) +def page_not_found(error): + return render_template('global/error_404.html'), 404 + @app.route('/') def main_index(): return redirect(url_for('site_show', lang='en')) + + @app.route('//site/') @app.route('//site/') -def site_show(page=''): - # TODO: set content_type - pass +def site_show(page='index'): + 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) + + # bah! those damn users all the time! + if not os.path.exists(page_file): + abort(404) + + # hah! + return render_template(name, page=page) @app.route('//meetings/') def meetings_index(): @@ -131,8 +152,8 @@ def meetings_show_rst(id): @app.route('//download') def downloads_list(): - # TODO: implement - pass + # TODO: read mirror list or list of available files + return render_template('downloads/list.html') @app.route('//download/') def downloads_select(file): @@ -145,6 +166,28 @@ def downloads_redirect(protocol, file, mirror=None): # TODO: implement pass + + +def render_blog_entry(slug): + """ + Render the blog entry + 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() + + return publish_parts(source=content, source_path=BLOG_DIR, writer_name="html") + + + @app.route('//blog/') @app.route('//blog/page/') def blog_index(page=0): @@ -153,8 +196,15 @@ def blog_index(page=0): @app.route('//blog/entry/') def blog_entry(slug): - # TODO: implement - pass + # try to render that blog entry.. throws 404 if it does not exist + parts = render_blog_entry(slug) + + if parts: + # now just pass to simple template file and we are done + return render_template('blog/entry.html', parts=parts, title=parts['title'], body=parts['fragment']) + else: + abort(404) + @app.route('/feed/blog/rss') def blog_rss(): @@ -181,8 +231,24 @@ def legacy_meeting(id): def legacy_status(year, month, day): return redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) +LEGACY_MAP={ + 'download': 'downloads_list' +} +@app.route('/_') +@app.route('/_.html') @app.route('/') +@app.route('/.html') def legacy_show(f): - # TODO: redirect to correct new url - pass + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + if f in LEGACY_MAP: + return redirect(url_for(LEGACY_MAP[f], lang=lang)) + else: + return redirect(url_for('site_show', lang=lang, page=f)) + + + +if __name__ == '__main__': + app.run(debug=True) diff --git a/www.i2p2/pages/status-2006-10-10.html b/blog/2006/10/10/status.html similarity index 94% rename from www.i2p2/pages/status-2006-10-10.html rename to blog/2006/10/10/status.html index 6578b642..a3c787e3 100644 --- a/www.i2p2/pages/status-2006-10-10.html +++ b/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/blog/2006/10/10/status.rst b/blog/2006/10/10/status.rst
new file mode 100644
index 00000000..b77847b7
--- /dev/null
+++ b/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/www.i2p2/pages/download.html b/pages/downloads/list.html
similarity index 99%
rename from www.i2p2/pages/download.html
rename to pages/downloads/list.html
index 7f5f9201..f7e5667f 100644
--- a/www.i2p2/pages/download.html
+++ b/pages/downloads/list.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Download{% endblock %}
 {% block content %}
 
Download I2P

diff --git a/pages/global/error_404.html b/pages/global/error_404.html
new file mode 100644
index 00000000..d8563c03
--- /dev/null
+++ b/pages/global/error_404.html
@@ -0,0 +1,21 @@
+{% extends "global/layout.html" %}
+{% block title -%}
+{% if g.lang == 'de' %}
+Nicht gefunden
+{% elif g.lang == 'zh' %}
+未找到
+{% else %}
+Not found
+{% endif %}
+{%- endblock %}
+
+{% block content %}
+{% if g.lang == 'de' %}
+Yep... die Information nach der du suchst, nennt sich anders, existiert nicht oder wurde entfernt.
+{% elif g.lang == 'zh' %}
+您搜索的页面或资源的名称不正确或不存在或已被删除。
+{% else %}
+Yep... the resource, you were searching for, is named differently, doesn't exist or was removed.
+{% endif %}
+
+{% endblock %}
diff --git a/pages/global/urlify b/pages/global/urlify
index 59ffe02c..e8c9cd78 100644
--- a/pages/global/urlify
+++ b/pages/global/urlify
@@ -1,7 +1,9 @@
 {% macro urlify(url, title, suffix) %}
+   {% autoescape false %}
     {% if static %}
     {{title}}
     {% else %}
     {{title}}
     {% endif %}
+   {% endautoescape %}
 {% endmacro %}
\ No newline at end of file
diff --git a/www.i2p2/pages/index.html b/pages/site/index.html
similarity index 94%
rename from www.i2p2/pages/index.html
rename to pages/site/index.html
index 4c6debbf..c3df28ee 100644
--- a/www.i2p2/pages/index.html
+++ b/pages/site/index.html
@@ -1,10 +1,11 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
+{% from "global/urlify" import urlify as urlify %}
 {% block title %}I2P Anonymous Network{% endblock %}
 {% block content %}
 

 

 Latest version:

-2012-05-02 - I2P 0.9 - {{ urlify("release-0.9", "Announcement", "html")}}
+2012-05-02 - I2P 0.9 - Announcement
 - Download

 2007-09-28 - Syndie 1.101a -
 
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

From 382d158489f6b80f0f3c4def02775c61c6e8fd8d Mon Sep 17 00:00:00 2001
From: dev 
Date: Mon, 10 Sep 2012 09:38:42 +0000
Subject: [PATCH 07/75] start hacking blog index

---
 app.py | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/app.py b/app.py
index 866b6308..8e942443 100644
--- a/app.py
+++ b/app.py
@@ -168,6 +168,24 @@ def downloads_redirect(protocol, file, mirror=None):
 
 
 
+def get_blog_index():
+    """
+    Returns list of valid slugs sorted by date
+    """
+    ret=[]
+    
+    # list of slugs(not sorted in any way)
+    entries=[]
+    # walk over all directories/files
+    for v in os.walk(BLOG_DIR):
+        # iterate over all files
+        for f in v[2]:
+            # ignore all non-.rst files
+            if not f.endswith('.rst'):
+                continue
+            
+
+
 def render_blog_entry(slug):
     """
     Render the blog entry

From 17224eba28e7a97be474eb57131f0f5b4a9bd5e1 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 11:28:34 +0000
Subject: [PATCH 08/75] Removed whitespace

---
 app.py | 31 +++++++++++++++----------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/app.py b/app.py
index 8e942443..8a9651b0 100644
--- a/app.py
+++ b/app.py
@@ -72,7 +72,7 @@ def detect_theme():
 @app.errorhandler(404)
 def page_not_found(error):
     return render_template('global/error_404.html'), 404
-    
+
 @app.route('/')
 def main_index():
     return redirect(url_for('site_show', lang='en'))
@@ -86,11 +86,11 @@ def site_show(page='index'):
         return redirect(url_for('site_show', page=page[:-5]))
     name = 'site/%s.html' % page
     page_file = safe_join(TEMPLATE_DIR, name)
-    
+
     # bah! those damn users all the time!
     if not os.path.exists(page_file):
         abort(404)
-    
+
     # hah!
     return render_template(name, page=page)
 
@@ -109,38 +109,38 @@ def meetings_show(id, log=False, rst=False):
     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)
-     
+
 
 @app.route('//meetings/.log')
 def meetings_show_log(id):
@@ -173,7 +173,7 @@ def get_blog_index():
     Returns list of valid slugs sorted by date
     """
     ret=[]
-    
+
     # list of slugs(not sorted in any way)
     entries=[]
     # walk over all directories/files
@@ -183,7 +183,6 @@ def get_blog_index():
             # ignore all non-.rst files
             if not f.endswith('.rst'):
                 continue
-            
 
 
 def render_blog_entry(slug):
@@ -201,7 +200,7 @@ def render_blog_entry(slug):
     # read file
     with codecs.open(path, encoding='utf-8') as fd:
         content = fd.read()
-    
+
     return publish_parts(source=content, source_path=BLOG_DIR, writer_name="html")
 
 
@@ -216,13 +215,13 @@ def blog_index(page=0):
 def blog_entry(slug):
     # try to render that blog entry.. throws 404 if it does not exist
     parts = render_blog_entry(slug)
-    
+
     if parts:
         # now just pass to simple template file and we are done
         return render_template('blog/entry.html', parts=parts, title=parts['title'], body=parts['fragment'])
     else:
         abort(404)
-    
+
 
 @app.route('/feed/blog/rss')
 def blog_rss():

From 9b575cb30afc4c4fd9db4f1c0fa44002e8871e64 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 11:56:51 +0000
Subject: [PATCH 09/75] Some comments to clarify app.py

---
 app.py | 35 +++++++++++++++++++++++++++++------
 1 file changed, 29 insertions(+), 6 deletions(-)

diff --git a/app.py b/app.py
index 8a9651b0..449a677c 100644
--- a/app.py
+++ b/app.py
@@ -69,16 +69,23 @@ def detect_theme():
         return resp
 
 
+###############
+# Error handlers
+
 @app.errorhandler(404)
 def page_not_found(error):
     return render_template('global/error_404.html'), 404
 
+
+#######################
+# General page handlers
+
+# Index - redirects to en homepage
 @app.route('/')
 def main_index():
     return redirect(url_for('site_show', lang='en'))
 
-
-
+# Site pages
 @app.route('//site/')
 @app.route('//site/')
 def site_show(page='index'):
@@ -94,10 +101,16 @@ def site_show(page='index'):
     # hah!
     return render_template(name, page=page)
 
+
+##################
+# Meeting handlers
+
+# Meeting index
 @app.route('//meetings/')
 def meetings_index():
     return render_template('meetings/index.html')
 
+# Renderer for specific meetings
 @app.route('//meetings/')
 def meetings_show(id, log=False, rst=False):
     """
@@ -141,20 +154,27 @@ def meetings_show(id, log=False, rst=False):
 
     return render_template('meetings/show.html', log=log, header=header, id=id)
 
-
+# Just return the raw .log for the meeting
 @app.route('//meetings/.log')
 def meetings_show_log(id):
     return meetings_show(id, log=True)
 
+# Just return the raw .rst for the meeting
 @app.route('//meetings/.rst')
 def meetings_show_rst(id):
     return meetings_show(id, rst=True)
 
+
+###################
+# Download handlers
+
+# List of downloads
 @app.route('//download')
 def downloads_list():
     # TODO: read mirror list or list of available files
     return render_template('downloads/list.html')
 
+# Specific file downloader
 @app.route('//download/')
 def downloads_select(file):
     # TODO: implement
@@ -167,6 +187,8 @@ def downloads_redirect(protocol, file, mirror=None):
     pass
 
 
+#####################
+# Blog helper methods
 
 def get_blog_index():
     """
@@ -204,6 +226,8 @@ def render_blog_entry(slug):
     return publish_parts(source=content, source_path=BLOG_DIR, writer_name="html")
 
 
+###############
+# Blog handlers
 
 @app.route('//blog/')
 @app.route('//blog/page/')
@@ -234,9 +258,8 @@ def blog_atom():
     pass
 
 
-
-
-## legacy stuff:
+##############
+# Legacy paths
 
 @app.route('/meeting')
 @app.route('/meeting.html')

From c9640766f86046d4a4197c136e67e98571be21fa Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 12:14:29 +0000
Subject: [PATCH 10/75] Reordered and commented hooks

---
 app.py | 39 +++++++++++++++++++++++++++++----------
 1 file changed, 29 insertions(+), 10 deletions(-)

diff --git a/app.py b/app.py
index 449a677c..477c4c87 100644
--- a/app.py
+++ b/app.py
@@ -16,11 +16,9 @@ MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings')
 app = application = Flask(__name__, template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR)
 app.debug =  bool(os.environ.get('APP_DEBUG', 'False'))
 
-@app.after_request
-def call_after_request_callbacks(response):
-    for callback in getattr(g, 'after_request_callbacks', ()):
-        response = callback(response)
-    return response
+
+##########################
+# Hooks - helper functions
 
 def after_this_request(f):
     if not hasattr(g, 'after_request_callbacks'):
@@ -29,11 +27,8 @@ def after_this_request(f):
     return f
 
 
-@app.template_filter('restructuredtext')
-def restructuredtext(value):
-    parts = publish_parts(source=value, writer_name="html")
-    return parts['html_body']
-
+###########################
+# Hooks - url preprocessing
 
 @app.url_value_preprocessor
 def pull_lang(endpoint, values):
@@ -50,6 +45,11 @@ def set_lang(endpoint, values):
     if hasattr(g, 'lang'):
         values['lang'] = g.lang
 
+
+########################
+# Hooks - before request
+
+# Detect and store chosen theme
 @app.before_request
 def detect_theme():
     theme = 'light'
@@ -69,6 +69,25 @@ def detect_theme():
         return resp
 
 
+############################
+# Hooks - request processing
+
+@app.template_filter('restructuredtext')
+def restructuredtext(value):
+    parts = publish_parts(source=value, writer_name="html")
+    return parts['html_body']
+
+
+#######################
+# 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
+
+
 ###############
 # Error handlers
 

From d48acb9c8aadff874aff67480cec5ba157ee0d39 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 12:34:33 +0000
Subject: [PATCH 11/75] Moved "new website" into a package in www.i2p2 dir

---
 app.py => www.i2p2/i2p2www/__init__.py              |   0
 .../i2p2www/blog}/2006/10/10/status.html            |   0
 .../i2p2www/blog}/2006/10/10/status.rst             |   0
 {meetings => www.i2p2/i2p2www/meetings}/208.log     |   0
 .../i2p2www/pages}/downloads/list.html              |   0
 .../i2p2www/pages}/global/error_404.html            |   0
 .../i2p2www/pages}/global/layout.html               |   0
 {pages => www.i2p2/i2p2www/pages}/global/menu.html  |   0
 {pages => www.i2p2/i2p2www/pages}/global/urlify     |   0
 .../i2p2www/pages}/meetings/index.html              |   0
 {pages => www.i2p2/i2p2www/pages}/site/index.html   |   0
 {static => www.i2p2/i2p2www/static}/favicon.ico     | Bin
 .../i2p2www/static}/images/I2PTunnel-streamr.png    | Bin
 .../i2p2www/static}/images/add-key-terminal.png     | Bin
 .../i2p2www/static}/images/bandwidth2009.png        | Bin
 {static => www.i2p2/i2p2www/static}/images/cz.png   | Bin
 {static => www.i2p2/i2p2www/static}/images/dark.png | Bin
 .../i2p2www/static}/images/darkbluebg.png           | Bin
 .../i2p2www/static}/images/darkbluetile.png         | Bin
 .../i2p2www/static}/images/darkerbluetile.png       | Bin
 {static => www.i2p2/i2p2www/static}/images/de.png   | Bin
 .../i2p2www/static}/images/download.png             | Bin
 .../i2p2www/static}/images/download_dark.png        | Bin
 .../i2p2www/static}/images/endToEndEncryption.png   | Bin
 .../static}/images/endToEndEncryption_fr.png        | Bin
 .../static}/images/endToEndEncryption_zh.png        | Bin
 {static => www.i2p2/i2p2www/static}/images/es.png   | Bin
 {static => www.i2p2/i2p2www/static}/images/eu.png   | Bin
 .../i2p2www/static}/images/firefox.options.jpg      | Bin
 .../i2p2www/static}/images/firefox.options_fr.png   | Bin
 .../i2p2www/static}/images/firefox.proxyports.jpg   | Bin
 .../static}/images/firefox.proxyports_fr.png        | Bin
 {static => www.i2p2/i2p2www/static}/images/fr.png   | Bin
 .../i2p2www/static}/images/garliccloves.png         | Bin
 {static => www.i2p2/i2p2www/static}/images/help.png | Bin
 .../i2p2www/static}/images/help_dark.png            | Bin
 .../i2p2www/static}/images/i2plogo.png              | Bin
 .../i2p2www/static}/images/i2ptunnel_peertopeer.png | Bin
 .../static}/images/i2ptunnel_serverclient.png       | Bin
 .../i2p2www/static}/images/i2pvstor_zh.png          | Bin
 .../i2p2www/static}/images/ie.options.jpg           | Bin
 .../i2p2www/static}/images/ie.options_fr.png        | Bin
 .../i2p2www/static}/images/ie.proxyports.jpg        | Bin
 .../i2p2www/static}/images/ie.proxyports_fr.png     | Bin
 {static => www.i2p2/i2p2www/static}/images/info.png | Bin
 .../i2p2www/static}/images/info_dark.png            | Bin
 {static => www.i2p2/i2p2www/static}/images/it.png   | Bin
 .../i2p2www/static}/images/itoopie.png              | Bin
 .../i2p2www/static}/images/konqueror.options.jpg    | Bin
 .../i2p2www/static}/images/konqueror.options_fr.jpg | Bin
 .../i2p2www/static}/images/konqueror.proxyports.jpg | Bin
 .../static}/images/konqueror.proxyports_fr.jpg      | Bin
 .../i2p2www/static}/images/lang_ar.png              | Bin
 .../i2p2www/static}/images/light.png                | Bin
 .../i2p2www/static}/images/lightbluetile.png        | Bin
 {static => www.i2p2/i2p2www/static}/images/link.png | Bin
 .../i2p2www/static}/images/link_dark.png            | Bin
 .../i2p2www/static}/images/logo07c.jpg              | Bin
 {static => www.i2p2/i2p2www/static}/images/net.png  | Bin
 .../i2p2www/static}/images/net_fr.png               | Bin
 .../i2p2www/static}/images/netdb_get_leaseset.png   | Bin
 .../static}/images/netdb_get_leaseset_fr.png        | Bin
 .../static}/images/netdb_get_routerinfo_1.png       | Bin
 .../static}/images/netdb_get_routerinfo_1_fr.png    | Bin
 .../static}/images/netdb_get_routerinfo_2.png       | Bin
 .../static}/images/netdb_get_routerinfo_2_fr.png    | Bin
 {static => www.i2p2/i2p2www/static}/images/nl.png   | Bin
 {static => www.i2p2/i2p2www/static}/images/plan.png | Bin
 .../i2p2www/static}/images/protocol_stack.png       | Bin
 .../i2p2www/static}/images/protocol_stack_fr.png    | Bin
 {static => www.i2p2/i2p2www/static}/images/ru.png   | Bin
 .../i2p2www/static}/images/sqbullet.png             | Bin
 .../i2p2www/static}/images/stackoverflow_ad.png     | Bin
 .../i2p2www/static}/images/tabletile.png            | Bin
 .../i2p2www/static}/images/tabletile_alt.png        | Bin
 .../i2p2www/static}/images/tabletitledark.png       | Bin
 .../i2p2www/static}/images/tabletitlelight-tall.png | Bin
 .../i2p2www/static}/images/tabletitlelight.png      | Bin
 .../i2p2www/static}/images/target.png               | Bin
 .../i2p2www/static}/images/tunnelSending.png        | Bin
 .../i2p2www/static}/images/tunnels.png              | Bin
 .../i2p2www/static}/images/tunnels_fr.png           | Bin
 {static => www.i2p2/i2p2www/static}/images/udp.png  | Bin
 {static => www.i2p2/i2p2www/static}/images/us.png   | Bin
 {static => www.i2p2/i2p2www/static}/images/zh.png   | Bin
 {static => www.i2p2/i2p2www/static}/news/news.xml   |   0
 .../i2p2www/static}/pdf/I2CP_spec.pdf               | Bin
 .../i2p2www/static}/pdf/I2NP_spec.pdf               | Bin
 .../i2p2www/static}/pdf/I2P-PET-CON-2009.1.pdf      | Bin
 .../i2p2www/static}/pdf/datastructures.pdf          | Bin
 .../i2p2www/static}/pdf/i2p_philosophy.pdf          | Bin
 .../i2p2www/static}/pdf/polling_http_transport.pdf  | Bin
 {static => www.i2p2/i2p2www/static}/styles/dark.css |   0
 .../i2p2www/static}/styles/light.css                |   0
 .../i2p2www/static}/styles/light_ar.css             |   0
 .../i2p2www/static}/styles/light_zh.css             |   0
 www.i2p2/runserver.py                               |   2 ++
 97 files changed, 2 insertions(+)
 rename app.py => www.i2p2/i2p2www/__init__.py (100%)
 rename {blog => www.i2p2/i2p2www/blog}/2006/10/10/status.html (100%)
 rename {blog => www.i2p2/i2p2www/blog}/2006/10/10/status.rst (100%)
 rename {meetings => www.i2p2/i2p2www/meetings}/208.log (100%)
 rename {pages => www.i2p2/i2p2www/pages}/downloads/list.html (100%)
 rename {pages => www.i2p2/i2p2www/pages}/global/error_404.html (100%)
 rename {pages => www.i2p2/i2p2www/pages}/global/layout.html (100%)
 rename {pages => www.i2p2/i2p2www/pages}/global/menu.html (100%)
 rename {pages => www.i2p2/i2p2www/pages}/global/urlify (100%)
 rename {pages => www.i2p2/i2p2www/pages}/meetings/index.html (100%)
 rename {pages => www.i2p2/i2p2www/pages}/site/index.html (100%)
 rename {static => www.i2p2/i2p2www/static}/favicon.ico (100%)
 rename {static => www.i2p2/i2p2www/static}/images/I2PTunnel-streamr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/add-key-terminal.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/bandwidth2009.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/cz.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/dark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/darkbluebg.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/darkbluetile.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/darkerbluetile.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/de.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/download.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/download_dark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/endToEndEncryption.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/endToEndEncryption_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/endToEndEncryption_zh.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/es.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/eu.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/firefox.options.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/firefox.options_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/firefox.proxyports.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/firefox.proxyports_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/garliccloves.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/help.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/help_dark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/i2plogo.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/i2ptunnel_peertopeer.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/i2ptunnel_serverclient.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/i2pvstor_zh.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/ie.options.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/ie.options_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/ie.proxyports.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/ie.proxyports_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/info.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/info_dark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/it.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/itoopie.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/konqueror.options.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/konqueror.options_fr.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/konqueror.proxyports.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/konqueror.proxyports_fr.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/lang_ar.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/light.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/lightbluetile.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/link.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/link_dark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/logo07c.jpg (100%)
 rename {static => www.i2p2/i2p2www/static}/images/net.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/net_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_leaseset.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_leaseset_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_routerinfo_1.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_routerinfo_1_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_routerinfo_2.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/netdb_get_routerinfo_2_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/nl.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/plan.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/protocol_stack.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/protocol_stack_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/ru.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/sqbullet.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/stackoverflow_ad.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tabletile.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tabletile_alt.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tabletitledark.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tabletitlelight-tall.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tabletitlelight.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/target.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tunnelSending.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tunnels.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/tunnels_fr.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/udp.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/us.png (100%)
 rename {static => www.i2p2/i2p2www/static}/images/zh.png (100%)
 rename {static => www.i2p2/i2p2www/static}/news/news.xml (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/I2CP_spec.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/I2NP_spec.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/I2P-PET-CON-2009.1.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/datastructures.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/i2p_philosophy.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/pdf/polling_http_transport.pdf (100%)
 rename {static => www.i2p2/i2p2www/static}/styles/dark.css (100%)
 rename {static => www.i2p2/i2p2www/static}/styles/light.css (100%)
 rename {static => www.i2p2/i2p2www/static}/styles/light_ar.css (100%)
 rename {static => www.i2p2/i2p2www/static}/styles/light_zh.css (100%)
 create mode 100644 www.i2p2/runserver.py

diff --git a/app.py b/www.i2p2/i2p2www/__init__.py
similarity index 100%
rename from app.py
rename to www.i2p2/i2p2www/__init__.py
diff --git a/blog/2006/10/10/status.html b/www.i2p2/i2p2www/blog/2006/10/10/status.html
similarity index 100%
rename from blog/2006/10/10/status.html
rename to www.i2p2/i2p2www/blog/2006/10/10/status.html
diff --git a/blog/2006/10/10/status.rst b/www.i2p2/i2p2www/blog/2006/10/10/status.rst
similarity index 100%
rename from blog/2006/10/10/status.rst
rename to www.i2p2/i2p2www/blog/2006/10/10/status.rst
diff --git a/meetings/208.log b/www.i2p2/i2p2www/meetings/208.log
similarity index 100%
rename from meetings/208.log
rename to www.i2p2/i2p2www/meetings/208.log
diff --git a/pages/downloads/list.html b/www.i2p2/i2p2www/pages/downloads/list.html
similarity index 100%
rename from pages/downloads/list.html
rename to www.i2p2/i2p2www/pages/downloads/list.html
diff --git a/pages/global/error_404.html b/www.i2p2/i2p2www/pages/global/error_404.html
similarity index 100%
rename from pages/global/error_404.html
rename to www.i2p2/i2p2www/pages/global/error_404.html
diff --git a/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
similarity index 100%
rename from pages/global/layout.html
rename to www.i2p2/i2p2www/pages/global/layout.html
diff --git a/pages/global/menu.html b/www.i2p2/i2p2www/pages/global/menu.html
similarity index 100%
rename from pages/global/menu.html
rename to www.i2p2/i2p2www/pages/global/menu.html
diff --git a/pages/global/urlify b/www.i2p2/i2p2www/pages/global/urlify
similarity index 100%
rename from pages/global/urlify
rename to www.i2p2/i2p2www/pages/global/urlify
diff --git a/pages/meetings/index.html b/www.i2p2/i2p2www/pages/meetings/index.html
similarity index 100%
rename from pages/meetings/index.html
rename to www.i2p2/i2p2www/pages/meetings/index.html
diff --git a/pages/site/index.html b/www.i2p2/i2p2www/pages/site/index.html
similarity index 100%
rename from pages/site/index.html
rename to www.i2p2/i2p2www/pages/site/index.html
diff --git a/static/favicon.ico b/www.i2p2/i2p2www/static/favicon.ico
similarity index 100%
rename from static/favicon.ico
rename to www.i2p2/i2p2www/static/favicon.ico
diff --git a/static/images/I2PTunnel-streamr.png b/www.i2p2/i2p2www/static/images/I2PTunnel-streamr.png
similarity index 100%
rename from static/images/I2PTunnel-streamr.png
rename to www.i2p2/i2p2www/static/images/I2PTunnel-streamr.png
diff --git a/static/images/add-key-terminal.png b/www.i2p2/i2p2www/static/images/add-key-terminal.png
similarity index 100%
rename from static/images/add-key-terminal.png
rename to www.i2p2/i2p2www/static/images/add-key-terminal.png
diff --git a/static/images/bandwidth2009.png b/www.i2p2/i2p2www/static/images/bandwidth2009.png
similarity index 100%
rename from static/images/bandwidth2009.png
rename to www.i2p2/i2p2www/static/images/bandwidth2009.png
diff --git a/static/images/cz.png b/www.i2p2/i2p2www/static/images/cz.png
similarity index 100%
rename from static/images/cz.png
rename to www.i2p2/i2p2www/static/images/cz.png
diff --git a/static/images/dark.png b/www.i2p2/i2p2www/static/images/dark.png
similarity index 100%
rename from static/images/dark.png
rename to www.i2p2/i2p2www/static/images/dark.png
diff --git a/static/images/darkbluebg.png b/www.i2p2/i2p2www/static/images/darkbluebg.png
similarity index 100%
rename from static/images/darkbluebg.png
rename to www.i2p2/i2p2www/static/images/darkbluebg.png
diff --git a/static/images/darkbluetile.png b/www.i2p2/i2p2www/static/images/darkbluetile.png
similarity index 100%
rename from static/images/darkbluetile.png
rename to www.i2p2/i2p2www/static/images/darkbluetile.png
diff --git a/static/images/darkerbluetile.png b/www.i2p2/i2p2www/static/images/darkerbluetile.png
similarity index 100%
rename from static/images/darkerbluetile.png
rename to www.i2p2/i2p2www/static/images/darkerbluetile.png
diff --git a/static/images/de.png b/www.i2p2/i2p2www/static/images/de.png
similarity index 100%
rename from static/images/de.png
rename to www.i2p2/i2p2www/static/images/de.png
diff --git a/static/images/download.png b/www.i2p2/i2p2www/static/images/download.png
similarity index 100%
rename from static/images/download.png
rename to www.i2p2/i2p2www/static/images/download.png
diff --git a/static/images/download_dark.png b/www.i2p2/i2p2www/static/images/download_dark.png
similarity index 100%
rename from static/images/download_dark.png
rename to www.i2p2/i2p2www/static/images/download_dark.png
diff --git a/static/images/endToEndEncryption.png b/www.i2p2/i2p2www/static/images/endToEndEncryption.png
similarity index 100%
rename from static/images/endToEndEncryption.png
rename to www.i2p2/i2p2www/static/images/endToEndEncryption.png
diff --git a/static/images/endToEndEncryption_fr.png b/www.i2p2/i2p2www/static/images/endToEndEncryption_fr.png
similarity index 100%
rename from static/images/endToEndEncryption_fr.png
rename to www.i2p2/i2p2www/static/images/endToEndEncryption_fr.png
diff --git a/static/images/endToEndEncryption_zh.png b/www.i2p2/i2p2www/static/images/endToEndEncryption_zh.png
similarity index 100%
rename from static/images/endToEndEncryption_zh.png
rename to www.i2p2/i2p2www/static/images/endToEndEncryption_zh.png
diff --git a/static/images/es.png b/www.i2p2/i2p2www/static/images/es.png
similarity index 100%
rename from static/images/es.png
rename to www.i2p2/i2p2www/static/images/es.png
diff --git a/static/images/eu.png b/www.i2p2/i2p2www/static/images/eu.png
similarity index 100%
rename from static/images/eu.png
rename to www.i2p2/i2p2www/static/images/eu.png
diff --git a/static/images/firefox.options.jpg b/www.i2p2/i2p2www/static/images/firefox.options.jpg
similarity index 100%
rename from static/images/firefox.options.jpg
rename to www.i2p2/i2p2www/static/images/firefox.options.jpg
diff --git a/static/images/firefox.options_fr.png b/www.i2p2/i2p2www/static/images/firefox.options_fr.png
similarity index 100%
rename from static/images/firefox.options_fr.png
rename to www.i2p2/i2p2www/static/images/firefox.options_fr.png
diff --git a/static/images/firefox.proxyports.jpg b/www.i2p2/i2p2www/static/images/firefox.proxyports.jpg
similarity index 100%
rename from static/images/firefox.proxyports.jpg
rename to www.i2p2/i2p2www/static/images/firefox.proxyports.jpg
diff --git a/static/images/firefox.proxyports_fr.png b/www.i2p2/i2p2www/static/images/firefox.proxyports_fr.png
similarity index 100%
rename from static/images/firefox.proxyports_fr.png
rename to www.i2p2/i2p2www/static/images/firefox.proxyports_fr.png
diff --git a/static/images/fr.png b/www.i2p2/i2p2www/static/images/fr.png
similarity index 100%
rename from static/images/fr.png
rename to www.i2p2/i2p2www/static/images/fr.png
diff --git a/static/images/garliccloves.png b/www.i2p2/i2p2www/static/images/garliccloves.png
similarity index 100%
rename from static/images/garliccloves.png
rename to www.i2p2/i2p2www/static/images/garliccloves.png
diff --git a/static/images/help.png b/www.i2p2/i2p2www/static/images/help.png
similarity index 100%
rename from static/images/help.png
rename to www.i2p2/i2p2www/static/images/help.png
diff --git a/static/images/help_dark.png b/www.i2p2/i2p2www/static/images/help_dark.png
similarity index 100%
rename from static/images/help_dark.png
rename to www.i2p2/i2p2www/static/images/help_dark.png
diff --git a/static/images/i2plogo.png b/www.i2p2/i2p2www/static/images/i2plogo.png
similarity index 100%
rename from static/images/i2plogo.png
rename to www.i2p2/i2p2www/static/images/i2plogo.png
diff --git a/static/images/i2ptunnel_peertopeer.png b/www.i2p2/i2p2www/static/images/i2ptunnel_peertopeer.png
similarity index 100%
rename from static/images/i2ptunnel_peertopeer.png
rename to www.i2p2/i2p2www/static/images/i2ptunnel_peertopeer.png
diff --git a/static/images/i2ptunnel_serverclient.png b/www.i2p2/i2p2www/static/images/i2ptunnel_serverclient.png
similarity index 100%
rename from static/images/i2ptunnel_serverclient.png
rename to www.i2p2/i2p2www/static/images/i2ptunnel_serverclient.png
diff --git a/static/images/i2pvstor_zh.png b/www.i2p2/i2p2www/static/images/i2pvstor_zh.png
similarity index 100%
rename from static/images/i2pvstor_zh.png
rename to www.i2p2/i2p2www/static/images/i2pvstor_zh.png
diff --git a/static/images/ie.options.jpg b/www.i2p2/i2p2www/static/images/ie.options.jpg
similarity index 100%
rename from static/images/ie.options.jpg
rename to www.i2p2/i2p2www/static/images/ie.options.jpg
diff --git a/static/images/ie.options_fr.png b/www.i2p2/i2p2www/static/images/ie.options_fr.png
similarity index 100%
rename from static/images/ie.options_fr.png
rename to www.i2p2/i2p2www/static/images/ie.options_fr.png
diff --git a/static/images/ie.proxyports.jpg b/www.i2p2/i2p2www/static/images/ie.proxyports.jpg
similarity index 100%
rename from static/images/ie.proxyports.jpg
rename to www.i2p2/i2p2www/static/images/ie.proxyports.jpg
diff --git a/static/images/ie.proxyports_fr.png b/www.i2p2/i2p2www/static/images/ie.proxyports_fr.png
similarity index 100%
rename from static/images/ie.proxyports_fr.png
rename to www.i2p2/i2p2www/static/images/ie.proxyports_fr.png
diff --git a/static/images/info.png b/www.i2p2/i2p2www/static/images/info.png
similarity index 100%
rename from static/images/info.png
rename to www.i2p2/i2p2www/static/images/info.png
diff --git a/static/images/info_dark.png b/www.i2p2/i2p2www/static/images/info_dark.png
similarity index 100%
rename from static/images/info_dark.png
rename to www.i2p2/i2p2www/static/images/info_dark.png
diff --git a/static/images/it.png b/www.i2p2/i2p2www/static/images/it.png
similarity index 100%
rename from static/images/it.png
rename to www.i2p2/i2p2www/static/images/it.png
diff --git a/static/images/itoopie.png b/www.i2p2/i2p2www/static/images/itoopie.png
similarity index 100%
rename from static/images/itoopie.png
rename to www.i2p2/i2p2www/static/images/itoopie.png
diff --git a/static/images/konqueror.options.jpg b/www.i2p2/i2p2www/static/images/konqueror.options.jpg
similarity index 100%
rename from static/images/konqueror.options.jpg
rename to www.i2p2/i2p2www/static/images/konqueror.options.jpg
diff --git a/static/images/konqueror.options_fr.jpg b/www.i2p2/i2p2www/static/images/konqueror.options_fr.jpg
similarity index 100%
rename from static/images/konqueror.options_fr.jpg
rename to www.i2p2/i2p2www/static/images/konqueror.options_fr.jpg
diff --git a/static/images/konqueror.proxyports.jpg b/www.i2p2/i2p2www/static/images/konqueror.proxyports.jpg
similarity index 100%
rename from static/images/konqueror.proxyports.jpg
rename to www.i2p2/i2p2www/static/images/konqueror.proxyports.jpg
diff --git a/static/images/konqueror.proxyports_fr.jpg b/www.i2p2/i2p2www/static/images/konqueror.proxyports_fr.jpg
similarity index 100%
rename from static/images/konqueror.proxyports_fr.jpg
rename to www.i2p2/i2p2www/static/images/konqueror.proxyports_fr.jpg
diff --git a/static/images/lang_ar.png b/www.i2p2/i2p2www/static/images/lang_ar.png
similarity index 100%
rename from static/images/lang_ar.png
rename to www.i2p2/i2p2www/static/images/lang_ar.png
diff --git a/static/images/light.png b/www.i2p2/i2p2www/static/images/light.png
similarity index 100%
rename from static/images/light.png
rename to www.i2p2/i2p2www/static/images/light.png
diff --git a/static/images/lightbluetile.png b/www.i2p2/i2p2www/static/images/lightbluetile.png
similarity index 100%
rename from static/images/lightbluetile.png
rename to www.i2p2/i2p2www/static/images/lightbluetile.png
diff --git a/static/images/link.png b/www.i2p2/i2p2www/static/images/link.png
similarity index 100%
rename from static/images/link.png
rename to www.i2p2/i2p2www/static/images/link.png
diff --git a/static/images/link_dark.png b/www.i2p2/i2p2www/static/images/link_dark.png
similarity index 100%
rename from static/images/link_dark.png
rename to www.i2p2/i2p2www/static/images/link_dark.png
diff --git a/static/images/logo07c.jpg b/www.i2p2/i2p2www/static/images/logo07c.jpg
similarity index 100%
rename from static/images/logo07c.jpg
rename to www.i2p2/i2p2www/static/images/logo07c.jpg
diff --git a/static/images/net.png b/www.i2p2/i2p2www/static/images/net.png
similarity index 100%
rename from static/images/net.png
rename to www.i2p2/i2p2www/static/images/net.png
diff --git a/static/images/net_fr.png b/www.i2p2/i2p2www/static/images/net_fr.png
similarity index 100%
rename from static/images/net_fr.png
rename to www.i2p2/i2p2www/static/images/net_fr.png
diff --git a/static/images/netdb_get_leaseset.png b/www.i2p2/i2p2www/static/images/netdb_get_leaseset.png
similarity index 100%
rename from static/images/netdb_get_leaseset.png
rename to www.i2p2/i2p2www/static/images/netdb_get_leaseset.png
diff --git a/static/images/netdb_get_leaseset_fr.png b/www.i2p2/i2p2www/static/images/netdb_get_leaseset_fr.png
similarity index 100%
rename from static/images/netdb_get_leaseset_fr.png
rename to www.i2p2/i2p2www/static/images/netdb_get_leaseset_fr.png
diff --git a/static/images/netdb_get_routerinfo_1.png b/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1.png
similarity index 100%
rename from static/images/netdb_get_routerinfo_1.png
rename to www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1.png
diff --git a/static/images/netdb_get_routerinfo_1_fr.png b/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1_fr.png
similarity index 100%
rename from static/images/netdb_get_routerinfo_1_fr.png
rename to www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1_fr.png
diff --git a/static/images/netdb_get_routerinfo_2.png b/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2.png
similarity index 100%
rename from static/images/netdb_get_routerinfo_2.png
rename to www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2.png
diff --git a/static/images/netdb_get_routerinfo_2_fr.png b/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2_fr.png
similarity index 100%
rename from static/images/netdb_get_routerinfo_2_fr.png
rename to www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2_fr.png
diff --git a/static/images/nl.png b/www.i2p2/i2p2www/static/images/nl.png
similarity index 100%
rename from static/images/nl.png
rename to www.i2p2/i2p2www/static/images/nl.png
diff --git a/static/images/plan.png b/www.i2p2/i2p2www/static/images/plan.png
similarity index 100%
rename from static/images/plan.png
rename to www.i2p2/i2p2www/static/images/plan.png
diff --git a/static/images/protocol_stack.png b/www.i2p2/i2p2www/static/images/protocol_stack.png
similarity index 100%
rename from static/images/protocol_stack.png
rename to www.i2p2/i2p2www/static/images/protocol_stack.png
diff --git a/static/images/protocol_stack_fr.png b/www.i2p2/i2p2www/static/images/protocol_stack_fr.png
similarity index 100%
rename from static/images/protocol_stack_fr.png
rename to www.i2p2/i2p2www/static/images/protocol_stack_fr.png
diff --git a/static/images/ru.png b/www.i2p2/i2p2www/static/images/ru.png
similarity index 100%
rename from static/images/ru.png
rename to www.i2p2/i2p2www/static/images/ru.png
diff --git a/static/images/sqbullet.png b/www.i2p2/i2p2www/static/images/sqbullet.png
similarity index 100%
rename from static/images/sqbullet.png
rename to www.i2p2/i2p2www/static/images/sqbullet.png
diff --git a/static/images/stackoverflow_ad.png b/www.i2p2/i2p2www/static/images/stackoverflow_ad.png
similarity index 100%
rename from static/images/stackoverflow_ad.png
rename to www.i2p2/i2p2www/static/images/stackoverflow_ad.png
diff --git a/static/images/tabletile.png b/www.i2p2/i2p2www/static/images/tabletile.png
similarity index 100%
rename from static/images/tabletile.png
rename to www.i2p2/i2p2www/static/images/tabletile.png
diff --git a/static/images/tabletile_alt.png b/www.i2p2/i2p2www/static/images/tabletile_alt.png
similarity index 100%
rename from static/images/tabletile_alt.png
rename to www.i2p2/i2p2www/static/images/tabletile_alt.png
diff --git a/static/images/tabletitledark.png b/www.i2p2/i2p2www/static/images/tabletitledark.png
similarity index 100%
rename from static/images/tabletitledark.png
rename to www.i2p2/i2p2www/static/images/tabletitledark.png
diff --git a/static/images/tabletitlelight-tall.png b/www.i2p2/i2p2www/static/images/tabletitlelight-tall.png
similarity index 100%
rename from static/images/tabletitlelight-tall.png
rename to www.i2p2/i2p2www/static/images/tabletitlelight-tall.png
diff --git a/static/images/tabletitlelight.png b/www.i2p2/i2p2www/static/images/tabletitlelight.png
similarity index 100%
rename from static/images/tabletitlelight.png
rename to www.i2p2/i2p2www/static/images/tabletitlelight.png
diff --git a/static/images/target.png b/www.i2p2/i2p2www/static/images/target.png
similarity index 100%
rename from static/images/target.png
rename to www.i2p2/i2p2www/static/images/target.png
diff --git a/static/images/tunnelSending.png b/www.i2p2/i2p2www/static/images/tunnelSending.png
similarity index 100%
rename from static/images/tunnelSending.png
rename to www.i2p2/i2p2www/static/images/tunnelSending.png
diff --git a/static/images/tunnels.png b/www.i2p2/i2p2www/static/images/tunnels.png
similarity index 100%
rename from static/images/tunnels.png
rename to www.i2p2/i2p2www/static/images/tunnels.png
diff --git a/static/images/tunnels_fr.png b/www.i2p2/i2p2www/static/images/tunnels_fr.png
similarity index 100%
rename from static/images/tunnels_fr.png
rename to www.i2p2/i2p2www/static/images/tunnels_fr.png
diff --git a/static/images/udp.png b/www.i2p2/i2p2www/static/images/udp.png
similarity index 100%
rename from static/images/udp.png
rename to www.i2p2/i2p2www/static/images/udp.png
diff --git a/static/images/us.png b/www.i2p2/i2p2www/static/images/us.png
similarity index 100%
rename from static/images/us.png
rename to www.i2p2/i2p2www/static/images/us.png
diff --git a/static/images/zh.png b/www.i2p2/i2p2www/static/images/zh.png
similarity index 100%
rename from static/images/zh.png
rename to www.i2p2/i2p2www/static/images/zh.png
diff --git a/static/news/news.xml b/www.i2p2/i2p2www/static/news/news.xml
similarity index 100%
rename from static/news/news.xml
rename to www.i2p2/i2p2www/static/news/news.xml
diff --git a/static/pdf/I2CP_spec.pdf b/www.i2p2/i2p2www/static/pdf/I2CP_spec.pdf
similarity index 100%
rename from static/pdf/I2CP_spec.pdf
rename to www.i2p2/i2p2www/static/pdf/I2CP_spec.pdf
diff --git a/static/pdf/I2NP_spec.pdf b/www.i2p2/i2p2www/static/pdf/I2NP_spec.pdf
similarity index 100%
rename from static/pdf/I2NP_spec.pdf
rename to www.i2p2/i2p2www/static/pdf/I2NP_spec.pdf
diff --git a/static/pdf/I2P-PET-CON-2009.1.pdf b/www.i2p2/i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
similarity index 100%
rename from static/pdf/I2P-PET-CON-2009.1.pdf
rename to www.i2p2/i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
diff --git a/static/pdf/datastructures.pdf b/www.i2p2/i2p2www/static/pdf/datastructures.pdf
similarity index 100%
rename from static/pdf/datastructures.pdf
rename to www.i2p2/i2p2www/static/pdf/datastructures.pdf
diff --git a/static/pdf/i2p_philosophy.pdf b/www.i2p2/i2p2www/static/pdf/i2p_philosophy.pdf
similarity index 100%
rename from static/pdf/i2p_philosophy.pdf
rename to www.i2p2/i2p2www/static/pdf/i2p_philosophy.pdf
diff --git a/static/pdf/polling_http_transport.pdf b/www.i2p2/i2p2www/static/pdf/polling_http_transport.pdf
similarity index 100%
rename from static/pdf/polling_http_transport.pdf
rename to www.i2p2/i2p2www/static/pdf/polling_http_transport.pdf
diff --git a/static/styles/dark.css b/www.i2p2/i2p2www/static/styles/dark.css
similarity index 100%
rename from static/styles/dark.css
rename to www.i2p2/i2p2www/static/styles/dark.css
diff --git a/static/styles/light.css b/www.i2p2/i2p2www/static/styles/light.css
similarity index 100%
rename from static/styles/light.css
rename to www.i2p2/i2p2www/static/styles/light.css
diff --git a/static/styles/light_ar.css b/www.i2p2/i2p2www/static/styles/light_ar.css
similarity index 100%
rename from static/styles/light_ar.css
rename to www.i2p2/i2p2www/static/styles/light_ar.css
diff --git a/static/styles/light_zh.css b/www.i2p2/i2p2www/static/styles/light_zh.css
similarity index 100%
rename from static/styles/light_zh.css
rename to www.i2p2/i2p2www/static/styles/light_zh.css
diff --git a/www.i2p2/runserver.py b/www.i2p2/runserver.py
new file mode 100644
index 00000000..45e60621
--- /dev/null
+++ b/www.i2p2/runserver.py
@@ -0,0 +1,2 @@
+from i2p2www import app
+app.run(debug=True)

From cd26692cdb032926f0ec663aa232464004e3639b Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 13:12:03 +0000
Subject: [PATCH 12/75] Link logo to / instead of index.html

---
 www.i2p2/i2p2www/pages/global/layout.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
index 4889c68a..102251c6 100644
--- a/www.i2p2/i2p2www/pages/global/layout.html
+++ b/www.i2p2/i2p2www/pages/global/layout.html
@@ -14,7 +14,7 @@
   
     
Skip navigation

     
     
{{ self.title() }}

     


From c7dd13d750e780052c87cc1849fba19872736409 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 16:01:01 +0000
Subject: [PATCH 13/75] Whitespace fixes

---
 www.i2p2/i2p2www/static/styles/default.css  |  36 ++---
 www.i2p2/i2p2www/static/styles/mainmenu.css | 144 ++++++++++----------
 2 files changed, 90 insertions(+), 90 deletions(-)

diff --git a/www.i2p2/i2p2www/static/styles/default.css b/www.i2p2/i2p2www/static/styles/default.css
index 4862060c..11a4aa40 100644
--- a/www.i2p2/i2p2www/static/styles/default.css
+++ b/www.i2p2/i2p2www/static/styles/default.css
@@ -13,7 +13,7 @@ img {border:0;}
 }
 
 #header {
-	border-bottom:1px solid black;        /* give us a black border underneath */
+    border-bottom:1px solid black;        /* give us a black border underneath */
     margin-bottom: 10px;
 }
 
@@ -57,28 +57,28 @@ img {border:0;}
 }
 
 .btn {
-	float: left;
-	clear: both;
-	background: url(../images/btn_left.png) no-repeat;
-	padding: 0 0 0 10px;
-	margin: 5px 0;
+    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;
+    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;
+    text-decoration: none;
 }
 .btn span {
-	background: url(../images/btn_right.png) no-repeat;
-	float: left;
-	width: 10px;
-	height: 40px;
+    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/www.i2p2/i2p2www/static/styles/mainmenu.css b/www.i2p2/i2p2www/static/styles/mainmenu.css
index 7299b342..9d410985 100644
--- a/www.i2p2/i2p2www/static/styles/mainmenu.css
+++ b/www.i2p2/i2p2www/static/styles/mainmenu.css
@@ -1,165 +1,165 @@
 /*==============================================================================
 
-	GRC multi-level script-free pure-CSS menuing system stylesheet.
+    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.
+    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							 
+                      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.
-	
+    benefit of anyone who may find it useful for any purpose whatsoever.
+
 ==============================================================================*/
 
  /*========================= TOP OF THE MENU CASCADE =========================*/
 
 .menu {
-	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 */
+    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 */
 }
 
 .menu img {
-	vertical-align: top;      /* prevent images from being pushed down by text */
+    vertical-align: top;      /* prevent images from being pushed down by text */
 }
 
 .menu 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 */
+    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 */
 
 .menu 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;
+    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 */
+    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 */
+    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 */
+    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 ========================*/
 
 .menu ul li ul {
-	display:none;                  /* initially hide the entire list hierarchy */
-	padding:1px;                               /* this is our box border width */
+    display:none;                  /* initially hide the entire list hierarchy */
+    padding:1px;                               /* this is our box border width */
 }
 
 .menu ul li a,
 .menu ul li a:visited {                    /* unselected top-level menu items */
-	display:block;
-	float:left;
-	text-decoration:none;
-	height:24px;
+    display:block;
+    float:left;
+    text-decoration:none;
+    height:24px;
 }
 
 /*======================== 2ND LEVEL MENU DEFINITIONS ========================*/
 
 .menu ul li:hover ul,
 .menu 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 */
+    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 */
 }
 
 .menu ul li:hover ul.leftbutton,
 .menu ul li a:hover ul.leftbutton {/* our first dropdown should not be skewed */
-	left:0px;
+    left:0px;
 }
 
 .menu ul li:hover ul.skinny,
 .menu 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) */
+    width:8.08333em;   /* with a 12px default font, this is 97px width (97/12) */
 }
 
 .menu ul.rightmenu li:hover ul,
 .menu 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) */
+    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 .menu ul.rightmenu li a:hover ul {         /* IE5/6 needs a tweak here */
-	right:-1px;
+    right:-1px;
 }
 
 .menu ul li:hover ul li a,
 .menu 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;
+    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;
 }
 
 .menu ul li:hover ul li:hover a,
 .menu ul li a:hover ul li a:hover {                /* 2nd level selected item */
-	color:black;
-	background:white;
+    color:black;
+    background:white;
 }
 
 .menu ul li:hover ul.skinny li a,
 .menu ul li a:hover ul.skinny li a,
 .menu ul li:hover ul.skinny li a:hover,
 .menu ul li a:hover ul.skinny li a:hover {     /* 2nd level un+selected items */
-	width:8.08333em;
+    width:8.08333em;
 }
 
 /*======================== 3RD LEVEL MENU DEFINITIONS ========================*/
 
 .menu ul li:hover ul li ul,
 .menu ul li a:hover ul li a ul {             /* hide inactive 3rd-level menus */
-	visibility:hidden;
+    visibility:hidden;
 }
-     
+
 .menu ul li:hover ul li:hover ul,
 .menu 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;
+    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;
 }
 
 .menu ul li:hover ul li:hover ul li a,
 .menu ul li a:hover ul li a:hover ul li a {     /* 3rd level unselected items */
-	width:14em;
-	background:#d8d8d8;
+    width:14em;
+    background:#d8d8d8;
 }
 
 .menu ul li:hover ul li:hover ul li a:hover,
 .menu ul li a:hover ul li a:hover ul li a:hover {    /* level3 selected items */
-	width:14em;
-	background:white;
+    width:14em;
+    background:white;
 }

From 63f8d2936119e5abbc37e0c009a11415307f2ab3 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 23:11:13 +0000
Subject: [PATCH 14/75] Migrated in duck's proposed layout, added (bad)
 drop-down menus based on mainmenu.css

---
 www.i2p2/i2p2www/__init__.py                  |   8 +-
 www.i2p2/i2p2www/pages/global/footer.html     |  59 ++++++
 www.i2p2/i2p2www/pages/global/lang.html       |  13 ++
 www.i2p2/i2p2www/pages/global/layout.html     |  59 ++----
 www.i2p2/i2p2www/pages/global/menu.html       |  56 ------
 www.i2p2/i2p2www/pages/global/nav.html        |  42 +++++
 www.i2p2/i2p2www/pages/site/index.html        | 174 ++++++------------
 www.i2p2/i2p2www/static/images/ar.png         | Bin 0 -> 228 bytes
 www.i2p2/i2p2www/static/images/cs.png         | Bin 0 -> 476 bytes
 www.i2p2/i2p2www/static/images/dots.png       | Bin 0 -> 5784 bytes
 .../i2p2www/static/images/logo_medium.png     | Bin 0 -> 11608 bytes
 www.i2p2/i2p2www/static/images/sv.png         | Bin 0 -> 542 bytes
 www.i2p2/i2p2www/static/styles/960.css        |   1 -
 www.i2p2/i2p2www/static/styles/duck.css       | 100 ++++++++++
 www.i2p2/i2p2www/static/styles/reset.css      | 102 ++++++++++
 15 files changed, 400 insertions(+), 214 deletions(-)
 create mode 100644 www.i2p2/i2p2www/pages/global/footer.html
 create mode 100644 www.i2p2/i2p2www/pages/global/lang.html
 delete mode 100644 www.i2p2/i2p2www/pages/global/menu.html
 create mode 100644 www.i2p2/i2p2www/pages/global/nav.html
 create mode 100755 www.i2p2/i2p2www/static/images/ar.png
 create mode 100755 www.i2p2/i2p2www/static/images/cs.png
 create mode 100644 www.i2p2/i2p2www/static/images/dots.png
 create mode 100644 www.i2p2/i2p2www/static/images/logo_medium.png
 create mode 100644 www.i2p2/i2p2www/static/images/sv.png
 delete mode 100644 www.i2p2/i2p2www/static/styles/960.css
 create mode 100644 www.i2p2/i2p2www/static/styles/duck.css
 create mode 100644 www.i2p2/i2p2www/static/styles/reset.css

diff --git a/www.i2p2/i2p2www/__init__.py b/www.i2p2/i2p2www/__init__.py
index 477c4c87..78c7f8ae 100644
--- a/www.i2p2/i2p2www/__init__.py
+++ b/www.i2p2/i2p2www/__init__.py
@@ -52,19 +52,19 @@ def set_lang(endpoint, values):
 # Detect and store chosen theme
 @app.before_request
 def detect_theme():
-    theme = 'light'
+    theme = 'duck'
     if 'style' in request.cookies:
         theme = request.cookies['style']
     if 'theme' in request.args.keys():
         theme = request.args['theme']
     if not os.path.isfile(safe_join('static/styles', '%s.css' % theme)):
-        theme = 'light'
+        theme = 'duck'
     g.theme = theme
     @after_this_request
     def remember_theme(resp):
-        if g.theme == 'light' and 'style' in request.cookies:
+        if g.theme == 'duck' and 'style' in request.cookies:
             resp.delete_cookie('style')
-        elif g.theme != 'light':
+        elif g.theme != 'duck':
             resp.set_cookie('style', g.theme)
         return resp
 
diff --git a/www.i2p2/i2p2www/pages/global/footer.html b/www.i2p2/i2p2www/pages/global/footer.html
new file mode 100644
index 00000000..314bc691
--- /dev/null
+++ b/www.i2p2/i2p2www/pages/global/footer.html
@@ -0,0 +1,59 @@
+      

+        
News

+        
+      

+      

+        
About I2P

+        
+      

+      

+        
Documentation

+        
+      

+      

+        
Development

+        
+      

+      

+        
Mirrors

+        
+        
Secure

+        
+      

+      

+        
Misc.

+        
+        Donate
+      

diff --git a/www.i2p2/i2p2www/pages/global/lang.html b/www.i2p2/i2p2www/pages/global/lang.html
new file mode 100644
index 00000000..4bff095f
--- /dev/null
+++ b/www.i2p2/i2p2www/pages/global/lang.html
@@ -0,0 +1,13 @@
+
    
+  
  • English
    • 
+  
  • Castellano
    • 
+  
  • Chinese
    • 
+  
  • Deutsch
    • 
+  
  • Français
    • 
+  
  • Italiano
    • 
+  
  • Nederlands
    • 
+  
  • Russian
    • 
+  
  • Svenska
    • 
+  
  • Czech
    • 
+  
  • Arabic
    • 
+

diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
index 4d0ac763..c5a0dc59 100644
--- a/www.i2p2/i2p2www/pages/global/layout.html
+++ b/www.i2p2/i2p2www/pages/global/layout.html
@@ -1,48 +1,27 @@
-{% include "global/urlify" -%}
-
-
-
+
+
   
+    
     {% block title %}{% endblock %} - I2P
-    
-    
-    
-    
-    
-    
+    
+    
     
-    
   
   
-    
Skip navigation

-    

-        
-        

-        

-        {% block content %}{% endblock %}
-        

+    
Skip navigation

+    

+      
I2P

+      
{{ self.title() }}

+    

+    

+      {% include "global/lang.html" %}
+      {% include "global/nav.html" %}
+    

+    

+      {% block content %}{% endblock %}
+    

+    
   
 
diff --git a/www.i2p2/i2p2www/pages/global/menu.html b/www.i2p2/i2p2www/pages/global/menu.html
deleted file mode 100644
index d0b066c1..00000000
--- a/www.i2p2/i2p2www/pages/global/menu.html
+++ /dev/null
@@ -1,56 +0,0 @@
-

-
-

-
-

-    

-English
-Deutsch
-中文
-Français
-Italiano
-Nederlands
-Русский
-    

-

diff --git a/www.i2p2/i2p2www/pages/global/nav.html b/www.i2p2/i2p2www/pages/global/nav.html
new file mode 100644
index 00000000..d51055d6
--- /dev/null
+++ b/www.i2p2/i2p2www/pages/global/nav.html
@@ -0,0 +1,42 @@
+
diff --git a/www.i2p2/i2p2www/pages/site/index.html b/www.i2p2/i2p2www/pages/site/index.html
index ad0fada2..c7647ddd 100644
--- a/www.i2p2/i2p2www/pages/site/index.html
+++ b/www.i2p2/i2p2www/pages/site/index.html
@@ -1,119 +1,67 @@
 {% extends "global/layout.html" %}
-{% from "global/urlify" import urlify as urlify %}
-{% block title %}I2P Anonymous Network{% endblock %}
+{% block title %}The Invisible Internet Project{% endblock %}
 {% block content %}
-

-

-
What can I2P do for you?

-
-
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 on I2P. Though suitable for general privacy-conscious usage, I2P is also designed to protect users under high risk, such as:

-
-
    
-    
  • 
-        Activists
    
-        Coordinate on human rights, free speech, peace.
-    
    • 
-    
  • 
-        Marginalized groups
    
-        Associate without threat of ethnic, political, or religious persecution.
-    
    • 
-

-
-
+

+  
What does I2P do for you?

+  
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 on I2P.

+  Get I2P 0.9.1
 

-
-

-    
Get started with I2P

-

-
-

-

-    Download Now
-     
-

-

-

-
-

-
How does I2P work?

-

-Network diagram
-

-
-
On the public Internet your external IP address is unique and provides a strong correlation between your online activities and your true identity. Effective privacy is hard to achieve because the Internet, by design, allows senders and receivers to see each other's external IP address. Another fundamental threat to privacy results from Internet-enabled applications that don't encrypt – or don't sufficiently encrypt – your sensitive communications.

-
-
I2P anonymizes Internet communications by: 1) employing many techniques to make it exceedingly difficult for a receiver to prove the IP address of a sender and vice versa; and 2) by strongly encrypting all communication between the sender and receiver.

-
-
To explore the workings of I2P in further detail please read A Gentle Introduction to the I2P Network. The technically-minded may wish to proceed to the I2P Network Technical Introduction.

-

-

-
-

-

-
Supported Applications

+

+  

+    
Who Uses I2P?

+    
I2P is used by many people who care about their privacy, as well as those in high-risk situations such as:

     
-

-
-
-
-
+      
  • Activists
    • 
+      
  • Oppressed People
    • 
+      
  • Journalists
    • 
+      
  • Whistleblowers
    • 
+      
  • The Privacy-Conscious
    • 
+      
  • Ur Mom
    • 
+    
+  
    
+  
    
+    
    Supported Software
    
+    
+  
    
+  
    
+    
    News & Updates
    
+      
+  
    
 
    
 {% endblock %}
diff --git a/www.i2p2/i2p2www/static/images/ar.png b/www.i2p2/i2p2www/static/images/ar.png
new file mode 100755
index 0000000000000000000000000000000000000000..f9dee35851c8c76ae16b6cc53fe27aa1ead25f3d
GIT binary patch
literal 228
zcmeAS@N?(olHy`uVBq!ia0vp^0zk~o!3HGD9`RZNDaPU;cPEB*=VV?2IrBVS978nD
zCwDv+_;dci0S7xf^%dXjJDodnm}f`;L6L>4#3RcVi4%-E25xf8IheWCU;o|NGe2%p
zDuXgJv$GiU{zvZ7l1EK%#kfcxXgQOZl8~Tb`)j7-pVRT5cz&Edav?
z0048MLcfb{@Lpld*gfdL?Z
zSQvhRtN^J#x6%GQNHxSfxHgc;AD{-1tAIKH0tl!9q}uD*5!1Kl8Kk6va!f$;fJ%WL
z`2Cv^NdEc54D$xi27mx!VfgXqT8ME7!~2)OPy-`SXu#NiAkhzFFflLy1Q-A_8F>@M
S6G{sJ0000+P)001Zm1^@s6c`Wgm00004b3#c}2nYxW
zdH)3f%_$*$Uknc2O&d-dvd`v0}i
z`|9~u031C#0_exx1LnXCm<>;c_;vK`s0VC>EFm`?o($(nPC6w!2c{vLbrNztv%jL#
z?8{d^AS?S`rj~u_l&s`t9rkt0{`>>>H&Xf6mFq(~Ww&QPuhdh>Vmj&4X}*52{>_J6
z{x17or?~yzSI@ta&=&9rH~_YR5%3l`113@)PTmKe0{fx#9C!g-slr0%Ch!>e9C!fS
z0zU#j03$gPh1mk0gw9Ri8h8U-3{QsBRPbHk(~#{07r;y4vSI(D@b!M!|0!fgR;FH*
z`RBmLz`fAZ@5>m!ri
z{~*e<9Tj^ATmpB=zRI;5v6zLg*H|O8SRF(i?1bFAxW`F$BVx1}_QxSVY1kix4{Csu
zsE6tBWXQ&E|Mj;-Kz|XHx);j#s0ns`e0Dqwg$Kajg`*1CLEPtu2Zy)EXU7~K91ehI
zz&}uuaF3FNAICdC9UdG`4i65A0{;s5S;*}~fDeH2;lbg}@!9b_?B56eCiKYH2T{>i
zVSgU>KL-xundBaY{nN0oO8R?BqU>9lKBn|o=T`n5;FFNqib~iC{kMk)htuP;Ve)Bro*o_?&dmN+)R+9+Fh3^8XUFs2d_M0-
zfu6++y>yR&uPH5T(~?g^mAdR1rDyq?(jxYOe~!TSlg?YTbn
zo8ifDdi3mQ7x))S61zUa{x`sXg|GKRZo_2MlZ+|7<|y<$3i*DLQ&0Sc(r7j*^|Y1b
zi02n^L#eC3rS|BOpHu4U8%k{Fl(^n&lxZI2Ivbu0XE9Pf3_o(2?~p^4t2&!jqPXr2O8xZG
zdtI^vTO(}HeQg3gIVeFdkOxGC^2xkcf}Hb7>>%lD1xr^;*6qkY>DTWqpH-%=gvw=d
z`<_gGNmp*9t;xLJmCtz*BO3#gZ}nz=^&6jCvGoxtcM>f*eI9hk=~BJJYHa-KrO*Do
zx$seC-cSOS3#Ar&9e-~rLxO&HS;q3?nMM4SN@1Hr&7UBDJ#x#l2zsZPkf$I
zR+_h|@Us7ovJ%wym&v|l@4~lntS-;ZzL#rCNzRvM{{>~PspL}N@4~m!&?&vSOdhLQ
z_nKW0_Dpl^JDzd(Lul>DhJEf%N1K
z0Fxh4SJ&#WvVDI>--7i$B{A;8`P&Ho33VAhrBvMa)D|uX;5*=zIdBUcQ!4j5z6;v<
z9dJH8848oSq$K2p=@ex1=Ln1(e;cw_CVLe=y`Z+_JK)>!>4w@no`zo+X8!{CJtbjp
z!uB-18VoZg8k*@;lANmiR#&It
zqh!ZnV*x`2baO!+3Df}YC=KOqcrwK5>Uos^*5dk}QvbIWtJ|=pjz)TKs0~HFs?0tL
zs9fXW$#CvCpeC+6@mC2mP1p|9<@_#nxLII3CM%u0aWC*H62KV~ciA6=ZRyPRH>fa0
z{{!|1A$O08t&N8XU=I6Rl*PkV1auLohOFQRLhqy@r&#TV-f5J-<*UlI8Gk2ncY)@T
z6%MxonkOP)Kuv&I!&k*>hf=q95rbB_GHBlf*DbFks}X1chW7!r0(H$dl$N8+T~ca2
z;Vq>nP_MOunA=crNd>i=vMjfb3mVC1_9c5mNhk%iWnZoHJH)~+l20Khuow1d=0#g%4qqjo|1^wmCJ>!
z;Gn1Bv*w8}Sst!Et^#<~z($EN5!~}>=yRBpC4CWr)rw#9
z$ZsML#PeU9uYwOWH+nHV8BQYjJK=-N$=6e2ZWR^!gu=w^Sox>n>(`XVH4j-aFdowx
zCAluF{CmJ(Qxa>#bdI7-idCPIc+XhIL#LER^(~QvrgxWR-c}0>r&vV;4p@fbw745b
znSA<{A)yJS0Zzq)d_>_vRiT*)`6iT$iBO`t+>Fw){ul;!D3!mRgz<*K_p-1U;
zcao2iy`uEOv!iE6+rU3k8cLR(P#V^s!tZ<3m`az+o<{ixl*a$GAv>oe*6%5e;U0yu
z+@mInWXF`n-K(&_MFsf1JWx@KyZA1uG-G^9tP5)ZO4NL56+9AXxtkQt?C%COiwEHV
zNoE#$G$e>Kb;iQ=s>Suv=UI}Qv%J_4gU~a(nvaR6R&TRs_A|WU?2DLye$uIT1}5tZ
zj|{^=G&UP1MQvrhIaXp9T5~xq&YZRI-rV20M;-3ORcATbcZyW{b9v_WoFq$`@UJi
zbza$TSJWXW57$~5YKW0e4<`0py_{CEEk0CpyIFd##mB4MirW>-d~CKaLP2%WN-nL;
z^*ys2F0Xl`%Vyr#%aupQF8Xr8gv==`BPF3L(5m&)zQ3U+gbypXR3KV&rxqP2*)x0h
zl$x+UWQ-~E8tomNP!grOgg+m{6lfQz+
z#!SV-*#K4Ms1d6cyCOE`*2@2ynq+?8QGolg>3m0pNoHnWB!jaiE&H;0YpYw?_RH&4
z(2;!d29nD)7ZWmyf{9%a6LLzKs83Ak+mO96*(=JV_N_T5icPG6FeAYmj;>!vgj{2TIE-nMEKthPloGar5<&qLM0c;a~owkV|f!mt4udxTif)+Q^R>JS#m-M8e^fs}{T
zvjm@FyOr%s#Lp=x`+nS?5TLW2*b>0~%XlvRU&i~JN6(Ht_)jQ+^g{}O`G^9z?nu%`W47)z1xKC+>qS^L9-I66HMyS2()CB!~d_SNvL2h63+wZ7M
z#1|o-;e{z>!Sf<$OM%_3E$o^LUdQ(blyfOtNlp{_6O&ctx0skQu_Y_0&~;3N7DjVw
z@7uy-g&K^*rjov8e?n}@GBCaij2;7HKa(KG9EQN2Yl6CCN*uOOA}cX9nRmIV$@)11
zB}vAR=9HxH!&3K5)^E&apGuZzxJdT3fDvorI(=TJsfo(JyGG}ISQ=G)tGnOMD9C;n
z6QgNN&)#e4l+C^kz5RxqWWBLF|DJXGbJAy*Me($ux1VG@xi_*CGy5zBS}-`f;mMbQ
zXn%i$TA5j=7exBkP4;sS>V?sF*QKB-QCjG|2QsrJUJmsTS!b5hX9vjje(Uo06svrx
zocSzHOD^ke^-x{*TfVk*>T_3J>3Oe1Zsk3n7^@f5%Ss$gMt#+nsUf}Rd&7k1c|hi-
zQ%s2LZzjE%tnY}vOLG2K6I{tnlZ*#K!w=z$PZiw0pbN!e+>n#3V_xb-Te6sMb9*me
z(&K<`W@57ZEd9;Tvwc|Z#k+L6?79S7XMaVfdY;7wNS22n-*l;$bS5GPT3fwkShU#K
zbSXi!!jo*?;_VE_HTA^5=6QbL#zE6_mf3~OZa8ajZr{&Y1!3L3wwh0)jQO02biQYm
z32-?dJ^Tzz2BAG(0kb8yEYt~rbQs}H7L;i>GBZJ{nN>W`?d*n-&6GgsWQmH%n
zys~rJ%5_DhBCn|jnj|OtdOotx4Y%NA>*mfNzgF8tPHTS&YQcUN?rb1`4lL+TXUx-%(a
zf}FK!`6_u0sXiQLU;Rvs0O&4XRW|j6bl8`iMu0B+S+>b;tg*k23Gu1gQk^;zBE;H}
za1ApH<>{oEpUPS~#A7gLgcIdWr#+Fl>_29ewGhCo_{(3{saWaomKX;4x|8e=Ohyoqck%oYC9(3Q
zmH(+R5l^V_R+iObYDP`A7Q7Pjgmi-sm)iW&aDJ$&br{Jnl}Wy+0&@bYHxmB14m9@XUB@T%
zy#+*f>FympJIeK#^(}NN0i7*q^?>fkEWP7*W*w9$EuGo1T&b;OmtEKC@3>E{w-tGJ9_SyW2Z1}ixG;md2^z^TAZI^OZ5
zTI{Gcxh2rl99cj)$-b|yWnaMZG~JqiP7Tty?XWK#OZG>mv&GtIb*okUIO%lOM2LYf
zz;z6dWHVUnw^pJme``Cue0IdZp$|`lr9`#*pV94uuWq|!7Kxf*y_}FsiMqf61C^f*
z>){*cRUPA*blgJH9se2G??TY^pQok?T^D1b1iz!6zwp+oa}tu3PW>k+Z>cvS?|y2d
zt=peccXm4yGwQH^-O!lC`!mQIho?+qnUFQb{%^
z*HQ=6=&W)NzR+p1KDsU?;815m{x6roEUjT}2@ExeC(kEaX9r;QoWTmfna&ybzoz(*
zte;6}opbpA*w;|BNSwb^HUrElR$x6x!&k}4*LC(??>e0>t81lBJ7k-34cSGRCHueZ
WzL}HyuSli<00002GAF6@~C$3k
z-zWqCMJ7%t4;%^(j%C@&EX(?EEI^LQ|4yNlQmX6va{zPznE*j1AUK9$3VEK-0l@x`
zQ9LHc~00aOM02=@f$3~H3^1n+cGLKgZfVA%6d1b}9g&N&D=1B9US@rpUj&upPtKYJ5v0wDW$YdzU@
z_EmRZ9Q%^&`hSSMo;dzb;>Wlh9d7+;PSi8OKr=$nHG(u`g2wzF2Y}Bi=14<~?`il9f1OPM7=krfsCG=2LeH(Zfm{7^uwn)IfaH@t1bb6U;WBv
zTd*LIm*oSqZsz)FPUjnM`20QK1OPL4u0QvpizLx<)4On6w4!%zfsX^h!*K(^8T#2c
z1;99`Ii0?Fhv(*-=kq(K9o}z-?QCv`@TE%+`K=pwu8`vo!<_C`;
z)m2SROoEEci#_g>yu87`a5`r?SoVBMX*y2G(x=HdhSzEMzD_X09EfNLl&z9Cl-?hsh^IGK=d8WiQ({tXQ)0Fcv86UDjnf{!^}
z+$5G^{Hc_-X7{f2jI+-UeG7n2o96LPyW2m@<>DqVfRsv+4>x|Dc=Xaso2vle!%qu_
zjW|J?;jr`P=#+NE241jv3
zdwl-;{IggWJAq*si6qH~i7yh5HlLH>miI~CK<6)kr}0`WKV0G{?gFnYTh!q@g*%K
z_X%EMGQ%^)BtaWemf(NRoV%+M0Se^vlp50GhR3
zS*6DSF&Z`pz)?|A@vO~eyRo+x7K_C$Xl!g;3qYon>RENz%F4>F5k>JahGFuKpuuK~
zs;cTcp-||7WHQ+SBM2?^+sn$z?v^BJ#!=MWqYy&2CzHuL8X6k5zz9qO;sDsA0|vb5
z<@w93ItSC~hbs;qeA&ygeDi<-+Xa>_w!m~{H2TYnL!q5d1pl>QGD#62b3tuq
z*Vdl6HkFER+*onNpyQ;!TI)_EwSSiuRb2vr?A+Dw_r=BHOe-FZs!RJS0=~CeNK)Fygo4{Oe%ph%}Yd4;olCvb~*X(Y-NEIs%l0B(>n=o_{xH?*&A|36LVH*NjRZ|trGi^~4Pag6^EH%hg?z1DKl
zLl3pq7JgQEs^{09kFB~yA>Z#6_x=KaURGUpv%R1F&sJP-*H={es;&i)%G`$T!O&Ye
zmjz(sI8GD<0lgK5VeH5}t}vz;`eOh7{inL!?$>NKTV7xF9Hs~khvUZ5($YB`$2pKm
zM_cDf0?V>}a{M7h6vdH#zkf|dMa5+RM07q%a<_WDd2UI%0D=H($#*!e2H&o_n17&?S=Hk*HTLBUl3Tty|)W#a%i9r=!{t-1mPNM322d!jq&_&<&u$tzuu
zjXQE3*8y;reqK6G6vXmu-19TfEdU%dXBA$>aW=ozHpAHX3oZ=Y48Y|X?ztsfSG0-8
z7k^NEIsm6L==@zb+%2Bxy~&%8Ub42m1qcIxDtQ6%YWr|yZ^%T
zJkwVleHBTP&Ko#z;A2@0_J}ziMUgxn&uhiS#U~nfgayDZiN{rytP<<|0z3^FaR+Uq20JK;OVw)sb&Bo
zlVqB+bvc!5PkxfrQeUOOs%(2U&Lo*;0Ft~(4)fqiHcnbe7=T#4R|)lC8%?1MPNJk6
zcaCy;>hn~j7jCim^0?Al9Q3sy$Z#CT^ws0CENe{*n~y${*Xw;q5Cpz2eV*s_Bk9>)
zF4qk?nTaiL4M>jT*q?F)F^kP+a|Qx|hb=*gW?k3z$?}Tq5oBE=u>=6UI~3X*rF5qi
zBRntP8wxE3KrXAVU#+lg)QZP}>IrpqUjv}4R<_RpBfwhf>$Fe4_#zntK)>3MUXYDf
z?Ne5^w-asmZaH0Bqkfo;fAVR^LI7mO^l(*cMBiq`2;t@F4>c|UK$>oETE^*I(%Q?S
z1K%}HZu}1b^6(!U7ZbwER{dx@**SfBXfFVoSeICm-Al`R<&}C=*JzsR%3ftvHlA3Y
zm=A!2?+foEtz?@O;|VW^9}Le2K(D!`?(0Mn)mGbz%0_Rxv34Z@(mbmr=CIB@4S$tl$ZDqgmzTT``6G+{Jn=xZXw-0B|oO!5`7Zw(tXSdsjaU6%kl|&-3
zJQ|JeMdo=O0BrsG^&1-q1Rmr#jyas3qA1&IYHDUyS69E>(b4gt-EL={PUmsG=-6yF
zn;H&>*Q0a2M$FI8Ki%nc{=7Gigpd#+Bt$7~V;Dx`d0yZ$a#$UX;~)q^MI;jWyQ-=w
zWac8=n~})QAvRkmR}^z2npQPG9DefJ+S*S6!~u{m;_>yziK5~W1b=lp{rRlAxAw*uRa(m*0Bu;LLrB(hMN|&ws{S9Co@j7__+wVbUAcwZDGF
z6;-b!lcXJhvTRvfZC)<3yP&}4S7b!jeAf2zWtUX_L)Q@lpe|q5wr%hru_X`?a+{l#
z-E-%K9{a;R_3Hs70FclB9a}&6I7#ui1^>YV=?%|6S2umhl4uoxlv=B*N?2JZ^^+vd
z#tE^lu_Xs@JUB}^s5AqR_wQGf_NcPHq*Rn_JSS}59$R$#tp}c{uUA_E$nA^TYuN&J
zw-^-tkP(f19C>-)x%=KmhMN|7EAp*vh^s1tqMRA0R47*;@|!IOVs5Qyp?;CYyLE&_Tdd1;&lMh=^g2$mejtG
zN+k!&v24etj(Gkv9K<_CQ
zdYh!%0QgQi>7*CjZui7)U$RJjef`z@_U-%7xCs=1bHs=d4|~1ddk&|gC`$e2&6}^*
zb-fLl1xgNpYuK=1(*l9OVeO?-sWqE7Z=Pg06#(4Bh7Ef#5D47e8^?x*hS^nBRjZK6
zh%gMp*ai(6G(JB+|9X~X?Y-%SLZNH-?Af#2;3)v`0Pq5E8rK^K5JhIP$60U@MwSeK
zc_VBVTrfWCFp7rEZU!F!7cw0{%FvA=6QB+Y&LHFScH<{waPk4L8{dx`coLbB*KOFA
z40|00u2{HvEZo|S@2JN0_>4NTaowv|IavxESI>+0&}^rpvg
zTp2RX`avmOmSq!$jXD6el+wD&%F2JVw6wh2m#!cP{gH7x0O&rBQ#KAAdPe)0F)y@^
z9zAQ#;K9R?XI%b@$TGp^3C;)W8d1g
zedM)MrsSD7Tm_)apFgmF)xMuSTvvbUYa2EUKWFGr$(pBE)(jpztabG0S?y!Sys&ZT
z&@+4-cgS{WsZCw?#qcw0>&Cpgci+!uEM7ctFft8H1E7u{@8`B`8F5*Cx93SC_Kmo9Y<%onBM*+ex#Z~*kJWD#Z&d_OX*lKXQ{$(;e&Tm0UgEvL%UJP2
z9}OBZx@GiZW7@~OJao&@U)#!UChx;OV)Z$Kj2JPZ&k>}dq2cQ4>S}WYVF0*>4tR{e#c`aIVHg1bs;a6kXliQOg3g|k1K0z-!m9r~}s*-EF=-)z~k
zj=`^-2CXCJ$v3TI1(5mfzRg~GHlqe)xGJqx3|BzbLY;P
zFnZypkt1goxZPds?T$pQI$_tY_W^LpF=N))ZMIWPj8K~XjOgx>Iw*(6|o&`WZVb=*41cnCYS#8Hc
zvFEl2x6cHCJ$p}nxFFwkuNB|(ecQET#_U`Hfa{6dpP$$}>@R<53IX89Dq}bD0zdc=
zPDo_i&$kUtZcHYMpDQlwH?7}xvwZ=8oRI&u$+c-b05W9jkaKfS%3W-=9dC)hye)6r
z1Nbo`2&EK+kX}nxkWm2YjvYJxymjl=o40J)^1Dr&HckBc>#r~P;)^eSvt`Scvnneq
zFKlXR+JQ`CHG4lD00{8a2x9^LWGw+4_S9xNZU9
zc8BLO(tv(GvX2taAJZI05wZ(Oe2;!{Nz#}YTq
zdSc*sS`NToQ6e2rLArH{g1`&_U}r^kpxy&FF324ZU>DD0Ko8uRk^=E~00+UNBwL?y
zG~hnlojWX~6ON@h+4?q~DFNUpE0Tuv#7z{D;pSt9^u&#EFoOWt8HwrF4QIfMCy0Xp
zv_e2>58Qn2v)wt7HzP50-Jf+xe(Dj#+-Rtxb8;C0&;p>@C@siLj*`eUbOwMe7z~yd
z6%{Q7;O}MhsIRWBUWu-&+aQGWIf4*ESOB6VN$&FU@*#r;4Z2|X@Zs|$NgCgW9&Kr9
z`P#JiZd+TtDVbcG-HY$(=vWDWIj_3Sl~QPO%);r?CEp8VpAc)F=6u{N7qWo2wR0QU0Bd*p`Y%bMo_U=Ch;aHXbc
z9oD*aqU()+X&;wdZKBnrmD$(vDm6R
z>gpB%kY!3!E5hN&BB|8(&~+qbIlQ^G_0@YC8+QVb=fB%l|HYTB&m`hG-89r0)sH>Z^FBV&+scMpFnpzi+
zuYazg;RVyjZ@%61Y*SZ9ZZz8Xzl5!Z((bksy
z{(}!gkI6Dk0g&tNs9O-*7h9!jYEmPb8n275ZuAMAH*>i7%R7X?i}pEoDoelk~xZ2S4v{
zI41QLM9t03SJv0pe}qihuE#wsS#_K1EaJd{1Fv#AozF51LCb#+UTNeXD_Omzmvxm+dHs+!m>%Pj_;FgSSu
z_-^p|`p<1|uTdy%H}JGY-+Rq9zKS_>qWh5u3sD~<_i4AMtcO{^WEU<7kw*wz_1%NxJdwftdsS-C%A*{@3bE@bWOiG
z0r+i$Z8_o)(H&bEt2J=5{vW&-3&4?$Aicyx7qJ8fZ?oB)g9i_O&ThBAMhJ2CR(~>?
z+*nmrH4B}OW?B}E|~}Vh?xmo5?*UjgnFuZu1Us-+PE#5}j}P#a!cDs&A^Vzi+CKwfOB2cmF+pyYD97
zK=DK|ne7(<(VPc!a(#FDN*Oz2`qkVe-eV)~a|G$%zyGt6Bwf{$vMG^B_1@AuE)IPR3}?`2Cmo&Kz*rsiQy)9TUL3!4EV0PvKTm*3}fI{(mDT|Yo*
zDwSGw;J|?yl+qA76Al0%Y$`4N^+=cNHGyTz03faFI~TUKU2%OVbN~QX*T4U?pd{VL
zF^ro6dR)^!^6c4jHH?ME$l$>*`FQ>chGA@k(qvecUn$(T?=b-S%{TjU9(gplRI>9w
z1HkASY1&_%zIXKK>JJ}N8Tb2TyzML1A%+*@up
ze<8y#JS8+14#_VJ8B+C>;dAl0j^pO?F8(|);HXYx>8AA4)g{%l0q8HkTu^c8WjPBE
z!wsdIO3!eObiKw38NcaieP`Q}wn?FDL;C@6{cHQ*Diul(F&yIog|5Z5kM?->Ty6MX
z7|=N2VKHC4jbRxFrBuQ+27w_E+rxI{=dR
za$ZT!LA)-@lGw
zm{aH5iRFjUEEK0Sg0(^J6l>>?%%(E|D%-B7IgM9=1W=P
z5J|dU0Lsisvcxbap6hhp3cx-EA)K3K$9-8+at;7#X)rj_&vDl<
zl-i6Gu%kc_?tIkmF99Ika%*6UWM@YMgaHUR9>J0_;g85X-blaxjq46k#EIr4mgiA6
z_;~4l1Go3Dus_HPDC|tbvZE$V^4$bLI^!INzc45~z;M(95HJkoTuyG>$7?d&R<11i
zmB+(f!Z4Hv2pE>S^9qE!Crxta1CUBKmYmJH*>Qv+90394sM{8_-Rl_V2mr93d6w(e
z-ndD}OZP!QnK?;jB<4id*{(YP*d6CMe6~W{1C*m40s_Jij&-x+N;j9D55Vq!)L$YL
z2zOGJItU0TLv5U&yS8v;;m-g_MQe*LVO{Jw1c$i!#1ip-VSwNUAi2i7Zet{7#Gw?i
zfMRj5cpoy4m4{99{x{Y^4jUY$rKOiU9FAp_(!4&_9U|dy_^$f;`oAMH=Pz?qZ7jnB^H
zND?#TxfgPW1913#+y&XV)5)E7*=4T688ZTd?GB90#sfLrg#a86-=8~<<)|+k@7FKG
zZP0Pj#B7XZspIBb{TBhS+bV1mvok@IqaOcs|2O~+pN~7gCvFobx`OsI?K!NAJw02W
z^|KcMaQbKZFQ6RtW#hJfwkrVGU01j!Qih7zxHL+-5`a@E6E5$8TYm0ebAJuM!3X#Y
zyV-WKr+TM(&9@i-tLq>=er^d4sidT2ip^$w#z?mwRuo0~DjW{~NtR`Ea%w(D_81(d
z{k}NHVzKv{o0~s`aax6`Y7}#BVa>K3I@!W_L5l^zzTDA~cp@jK(#>(lTk8+0>NWtj
z7o*Xwb0kS+Ei1YJusfOD1VGrBOnzM^2sc|X3eZKd*hT=hhDLewzyabgD=y2V>7n~u
zYXJz&&FOE7io_x--VxLHE?E*!FIj^0l&St&yTq1S@urZx1%U9<3oTpUe7i_y8Ai0?
zmEWZ|0T6cWN^J}la9t8I6wv3s+qM~iko-Qm(UtGIv9G$Y^&(v
z_qblUXi+=`07^{xj`MI`u1#rHz5yV#J=6A$v`CT}wkx;fcge2-*kbR+z7qc^5@dDi
ziA{;G00^l)sm<)E>^WVy=`v8UZqC60
z5Q~b6ZV&|F8A1qqxH@!QPsd`h*|oK`(_~q$0?-O$BN>c^!NU!MN4S!nL}pZI08o$2
zo~(MKGyrHc@CY)KKN;PFk^;~-CKB%uLUeNk&~-hzxV?Qo0BwFE(R@%*R$E7igr?PA
z)!e)qfOdIv^Vd;T-EGAiWclASqS1W-w3lCu%u_VI!;D=@3EBCd)Vy?>ssOZ=D`M|z
zx}G#~LUsL{&B=FR?A7{qTXHU?L^p9&)8qemt8F0wedWqz%Yps!`_>*lnbK;fP7SRF
zpxyAh(3*HcJz&M_>(ZaT{(7ttfZlv%^J*=j)mnRD<)E@UF+b4^KwG}7eSS8#Et`^a
zjQgi2HYVl~LUdDC*Y#w_!j3rr^yJcHt5U7JZ>?KPYPI2s;Z*>%==5l{TrYoa#nq_#
zUHFpl1^{}?4K2&Gl-6j$saz#5lQ+mQ09y1P(Yd;&CpuB0CpRbO85er=d$EGS;L|pn
z?V7_?008lL{EA2<@(GMdy74g!K+Ma_JKJuzFF`M(6{WNz8jU^>i^VphGc}h+XO231
zrQZBM55SY3pMQ@eNe}eKF_}z0*wWJSj=|BoL5*69SvSoNdc!9?GHKSF3nhMcDn0-J
z49Q7EK~!nb10K(12};}VjYgM!tEzQI-8=yQ!*2KJ2`<-fx2Mxvr$nQlD4F?83Yll#
zoWJ^fXO6Yof4(}ASo2^<$Ctl=R`BdPdf&#AO&DT4YE?AKK4wk)VLx&0_
zk3H_c#N}kY&psbr`sqjMy~sQcG5~xNCOD3}VwsZkDhv>W0S#62H;?9OrGy`
z-#OAq>E!s*`0ChWu}$bqfxCL)1^`~^LTRAq0ncSLLEEGEMwhAIcJ-V4e)lP^D_!Ty
zJLPZNrnY@dGu#rU-#kxxe(wCO^Q_cYsV}29M?W*Tr2#k?CzI!Y-Tzy0s5mS(C$=*F
zY+MyM*<#IkCUQmZaWGRU)%+9Y^N9^zI#fUjb53Q1G-M2z>@fG#a%A
z2m?THxm+b)ulK7y-bL5b>GXU;$XOAyI-^m6JnH%K>;GG~zMSFEU`K_w9qI15&ArnO2
zTb#~{x016>pJ;%06r6#;lfk#Sq_c68o%34m7^A>?p_I7fQvA#Po^yI*{TAo
zUVbQ_BMcK87U}OMT&}Kt+22o
z91OmFqupMD%zF;*O@Y9KSTMMS78Oysu(0MpUfv@HXFCATp4{AN>B7P)T2w?6!QhT<
zIXTxFH{UUY=W`ni3SLzU3nQecNQ(x8Yu@+yPBR*p{YJaJBpeLBtrZq_kfI_vQc$q!
z9j|w!fjj>(&v$C|f#An2kzzI6T-3IwGWfS&{?e9j*mkY{I557ZF1WF^t(Z23it4uS
zEUmZFZz%HZ2qU3JKB
zuE2)C_+Tu!v4|GYLbmU|g=H(b!{HdJI}`|lD2;i2Ai
z6h*l&8jZe%OpnpyaN3(#Pf=;j&wnGpFqd2L1FHJRev!y)ZieAo^YXR|3{zr(>3gZv
z8524>c0BHM7Cq>4eVcWvN#wWD=!j1hCBD<|zkHa@_BU(YF+%?3X>OhXfb0(h?x+xi
zKUwhzrAuAz`?wEZVz{^6|dZ@-8Ob~%Y3(+5%%uO-y{f3g_YZ?70ENMzrJJV
z%YSnZo^-jh%c&-sMngY8wPnP={+yx8$MER$MQp>=}>hEI;gs212CxJ9TC
z9=F=25xO{>li^lXo&Sp8&vr=y)YfW`j2zzbGUI0Wyw)^aRt`1(e0)^moI53&81Kif16@#t2)0XYlL0t|5yI4Nwncipd%62G
z01md0{arWQOV1alih1ZI&HGbrR6^Rn@ds=sK(=
zo>}P^*C|Q}x=yq4CPirgARbiJhHMPFjvb0p4?t`uq&^$dbUm?1mSX_Kn5K2pS2QiM
zT2ZtQK9EzIrgc#0u$EYd)&M|U_eH9SLMPdHb2x)Hg|zx?j6%oO&8bEJVkoRN^nlY1
zU!_6-L@ln>>*)GVQ?!Wkp`xu{uM%0&TDozIs|^4|;9T`6Ia*fT+c^x^CQ5Eut({e$=TZM>>L7&tBzhHd`U3wEVv@dh|3B97&q@
zaBC<(P-v1;{X11%n%#?kCd-Qf&_~kg{jIvb#fs^Kr0+_lRso=wB@%1Wy54HVW4gZQ
z>SS^o0JXa;?XvJ$Ab^1_5dJ{Oi!%Tb&|H?Z4qtDQ%|J#
z1EBI}^5X1XTHUQKg`9aAZqN7H@@#G!)@cg>ko2F@2eq)av5U4&(#d<0?*X96tCL&x
zn7+q~>uEibxIFO@0Fs)KT0#g>thm;sZBYKMgaJ_bW4YUQcy*7ug0|A5KGlQ;U=sx4
zOaLeMHhI-`eW9jl`;p0X@S-T5&oIomqnQXFNl_H#Ib@z22>^lT`Oyr+{Hiw{Lda@W
zRlkL?_}9~Q_a-xE&V=C;?rlZ+t_;|p1Gt+B+4YtzKYnvM{W**|*gsWuU4Nj%%`mR-
zH0{$z(&7`
z)r*tKH&dC6jIvbI>Rps>%V!uVK}dLoqRhTHnOvY7TVfV3Qnrk?+PrDM
zPd?SqKwAOGH8n(OsMr5hSjZ4gpv{V3T)8UUopZj#i)`sZvh3(8VmU8laCnv|MN
zTMce2v?gk!-!KJ?NYbQL`9OIwbxCRt6m;MyPc`9@nP3M1_>JGq^Qf#ZM#YfHMVs4>
z1!OW0Iml!;Z0J1X?P$fcXTGV}g3fKslEE*4OeV*Apo7UVj?BVi6o=W*)t6XLi-eJm
zG;9Nz#%JzoHPe+YWUgH|?3?LGGhOLI#-FAS&2*%hMs^zZ(gtpx7$aG5Sa37V>#%Sm
z#^+`u;0!(UzF4`bS=`LS7));F$stx;F)(YIw=Zt)Ui@}AZVEcrpv)6hG>dK3&@pYB
z+&a*iI5N38(0N)+44sR@J?`l35+Ih9YO_JxU~Duqez!i7nG0*?HfM9in={Bb(Df9=
zA1mfb-R9QjwDB2l@N*#Jxa>o*&3DmF9dqO151o^k*I@p!ArYO6pXQ5Uht`0Q@fVMb
zkE}RrU}mC0N5+Tdq9|`*=4p;9I#2eX7Tjjo*3fw}2(oNbi@s*m*Bdv^Qa6jvm)=Zn
zz2P(q?};1#BmHLj-SnG@_r)#SuZ)G8c}O{oYv}$*JT32OWd9*g^G^y`|2%+I%pmD<
z{C$?rPZ1ned)A}$O?%e&-g^=qT{#}@ggyJ6cIy%R))jseV|u`?FN~SjbZ7;?hq|dn
z|43|`b@ycZNVxqF+egFg$NJ5RTkq%5aJSAsy6vc-ly>_Yg^x1~lWY0RDu-+6y*0L<
zGB|#Wy`Lh3bxi*M7Ycw7LT-hz9jQxzP)c`EO1=2+{|UBZa!meT6YJ9u2S8^ShWWn`
WOOx`q;Wlaj0000a|fPuet^$h(7pHv_{jfB<3vn*8q{15ov!pR5qo|Ns4BVf^v!57RHO
zo?l?}`yWs<(7C?=0*LYNK?X*pGKOD3v;Q#s|MUOfZxH$qCjb2cBQWFtZ$@_cPkRpn
z1P}|u9|n-AAQdnT|9?TXAyk7H4FCQBl>h_~&`AvcLF)bhMS(&{8jwh^2qVzve;5D)
zh>=0RIIAq+{+o}$pxEl(3%2T)`P!1-fBt~{@Pp~sA7J?W`}60ovKZgl)=2;X#KQ37
z&mWM7{{H^+4`$e}UqIEMAo>Rk|KALM|1kdh!vsX^3=B^I0*D0|DL|!?{M^6*VPKPH
z00z{*-?BnHps)wJ`QKllIe-8D1EGJQNCgNWMh3}bctpOPvlbWzK!=K^+cJPc;};D5
g19O2S13-WQ0NlBGh$rR(5C8xG07*qoM6N<$f_QiWUjP6A

literal 0
HcmV?d00001

diff --git a/www.i2p2/i2p2www/static/styles/960.css b/www.i2p2/i2p2www/static/styles/960.css
deleted file mode 100644
index fe3d05f6..00000000
--- a/www.i2p2/i2p2www/static/styles/960.css
+++ /dev/null
@@ -1 +0,0 @@
-.container_12,.container_16{margin-left:auto;margin-right:auto;width:960px}.grid_1,.grid_2,.grid_3,.grid_4,.grid_5,.grid_6,.grid_7,.grid_8,.grid_9,.grid_10,.grid_11,.grid_12,.grid_13,.grid_14,.grid_15,.grid_16{display:inline;float:left;margin-left:10px;margin-right:10px}.push_1,.pull_1,.push_2,.pull_2,.push_3,.pull_3,.push_4,.pull_4,.push_5,.pull_5,.push_6,.pull_6,.push_7,.pull_7,.push_8,.pull_8,.push_9,.pull_9,.push_10,.pull_10,.push_11,.pull_11,.push_12,.pull_12,.push_13,.pull_13,.push_14,.pull_14,.push_15,.pull_15{position:relative}.container_12 .grid_3,.container_16 .grid_4{width:220px}.container_12 .grid_6,.container_16 .grid_8{width:460px}.container_12 .grid_9,.container_16 .grid_12{width:700px}.container_12 .grid_12,.container_16 .grid_16{width:940px}.alpha{margin-left:0}.omega{margin-right:0}.container_12 .grid_1{width:60px}.container_12 .grid_2{width:140px}.container_12 .grid_4{width:300px}.container_12 .grid_5{width:380px}.container_12 .grid_7{width:540px}.container_12 .grid_8{width:620px}.container_12 .grid_10{width:780px}.container_12 .grid_11{width:860px}.container_16 .grid_1{width:40px}.container_16 .grid_2{width:100px}.container_16 .grid_3{width:160px}.container_16 .grid_5{width:280px}.container_16 .grid_6{width:340px}.container_16 .grid_7{width:400px}.container_16 .grid_9{width:520px}.container_16 .grid_10{width:580px}.container_16 .grid_11{width:640px}.container_16 .grid_13{width:760px}.container_16 .grid_14{width:820px}.container_16 .grid_15{width:880px}.container_12 .prefix_3,.container_16 .prefix_4{padding-left:240px}.container_12 .prefix_6,.container_16 .prefix_8{padding-left:480px}.container_12 .prefix_9,.container_16 .prefix_12{padding-left:720px}.container_12 .prefix_1{padding-left:80px}.container_12 .prefix_2{padding-left:160px}.container_12 .prefix_4{padding-left:320px}.container_12 .prefix_5{padding-left:400px}.container_12 .prefix_7{padding-left:560px}.container_12 .prefix_8{padding-left:640px}.container_12 .prefix_10{padding-left:800px}.container_12 .prefix_11{padding-left:880px}.container_16 .prefix_1{padding-left:60px}.container_16 .prefix_2{padding-left:120px}.container_16 .prefix_3{padding-left:180px}.container_16 .prefix_5{padding-left:300px}.container_16 .prefix_6{padding-left:360px}.container_16 .prefix_7{padding-left:420px}.container_16 .prefix_9{padding-left:540px}.container_16 .prefix_10{padding-left:600px}.container_16 .prefix_11{padding-left:660px}.container_16 .prefix_13{padding-left:780px}.container_16 .prefix_14{padding-left:840px}.container_16 .prefix_15{padding-left:900px}.container_12 .suffix_3,.container_16 .suffix_4{padding-right:240px}.container_12 .suffix_6,.container_16 .suffix_8{padding-right:480px}.container_12 .suffix_9,.container_16 .suffix_12{padding-right:720px}.container_12 .suffix_1{padding-right:80px}.container_12 .suffix_2{padding-right:160px}.container_12 .suffix_4{padding-right:320px}.container_12 .suffix_5{padding-right:400px}.container_12 .suffix_7{padding-right:560px}.container_12 .suffix_8{padding-right:640px}.container_12 .suffix_10{padding-right:800px}.container_12 .suffix_11{padding-right:880px}.container_16 .suffix_1{padding-right:60px}.container_16 .suffix_2{padding-right:120px}.container_16 .suffix_3{padding-right:180px}.container_16 .suffix_5{padding-right:300px}.container_16 .suffix_6{padding-right:360px}.container_16 .suffix_7{padding-right:420px}.container_16 .suffix_9{padding-right:540px}.container_16 .suffix_10{padding-right:600px}.container_16 .suffix_11{padding-right:660px}.container_16 .suffix_13{padding-right:780px}.container_16 .suffix_14{padding-right:840px}.container_16 .suffix_15{padding-right:900px}.container_12 .push_3,.container_16 .push_4{left:240px}.container_12 .push_6,.container_16 .push_8{left:480px}.container_12 .push_9,.container_16 .push_12{left:720px}.container_12 .push_1{left:80px}.container_12 .push_2{left:160px}.container_12 .push_4{left:320px}.container_12 .push_5{left:400px}.container_12 .push_7{left:560px}.container_12 .push_8{left:640px}.container_12 .push_10{left:800px}.container_12 .push_11{left:880px}.container_16 .push_1{left:60px}.container_16 .push_2{left:120px}.container_16 .push_3{left:180px}.container_16 .push_5{left:300px}.container_16 .push_6{left:360px}.container_16 .push_7{left:420px}.container_16 .push_9{left:540px}.container_16 .push_10{left:600px}.container_16 .push_11{left:660px}.container_16 .push_13{left:780px}.container_16 .push_14{left:840px}.container_16 .push_15{left:900px}.container_12 .pull_3,.container_16 .pull_4{left:-240px}.container_12 .pull_6,.container_16 .pull_8{left:-480px}.container_12 .pull_9,.container_16 .pull_12{left:-720px}.container_12 .pull_1{left:-80px}.container_12 .pull_2{left:-160px}.container_12 .pull_4{left:-320px}.container_12 .pull_5{left:-400px}.container_12 .pull_7{left:-560px}.container_12 .pull_8{left:-640px}.container_12 .pull_10{left:-800px}.container_12 .pull_11{left:-880px}.container_16 .pull_1{left:-60px}.container_16 .pull_2{left:-120px}.container_16 .pull_3{left:-180px}.container_16 .pull_5{left:-300px}.container_16 .pull_6{left:-360px}.container_16 .pull_7{left:-420px}.container_16 .pull_9{left:-540px}.container_16 .pull_10{left:-600px}.container_16 .pull_11{left:-660px}.container_16 .pull_13{left:-780px}.container_16 .pull_14{left:-840px}.container_16 .pull_15{left:-900px}.clear{clear:both;display:block;overflow:hidden;visibility:hidden;width:0;height:0}.clearfix:after{clear:both;content:' ';display:block;font-size:0;line-height:0;visibility:hidden;width:0;height:0}* html .clearfix,*:first-child+html .clearfix{zoom:1}
\ No newline at end of file
diff --git a/www.i2p2/i2p2www/static/styles/duck.css b/www.i2p2/i2p2www/static/styles/duck.css
new file mode 100644
index 00000000..55c3d39a
--- /dev/null
+++ b/www.i2p2/i2p2www/static/styles/duck.css
@@ -0,0 +1,100 @@
+@import url('reset.css');
+
+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#branding {width:80%; margin:1em auto; position:relative;}
+    div#branding .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;
+    }
+
+div.navigation {position:relative;}
+    ul.nav li {display:inline-block; *display:inline; *zoom:1;}
+ul.languages {width:130px; position:absolute; right:10%; top:0;}
+ul.sections {margin:1em 10%; padding-right:130px;}
+ul.sections li {
+    font-size:2em; font-family:"URW Gothic L", "Century Gothic", sans-serif;
+    font-weight:bold; margin:0 1.3em 0 0; text-shadow:1px 1px 1px rgba(100,20,20,.2);
+    position:relative;}
+    ul.sections li ul {display:none; padding:1px; z-index:1;}
+    ul.sections li:hover ul, ul.sections li a:hover ul {
+        display:block; position:absolute; margin:0; top:24px; left:-1px; height:auto;
+        width:13.5em; background:black;}
+    ul.sections li:hover ul li a, u.sections li a:hover ul li a {
+        border:0; margin:0; padding:0; height:auto;
+        width:13.5em; background:#d8d8d8;}
+    ul.sections li:hover ul li:hover a, u.sections li a:hover ul li a:hover {
+        background:white;}
+    ul.sections li:hover ul li ul, ul.sections li a:hover ul li a ul {visibility:hidden;}
+    ul.sections li:hover ul li:hover ul, ul.sections li a:hover ul li a:hover ul {
+        visibility:visible; position:absolute; margin-top:-1px; top:0;
+        left:8.08333em; width:14em;}
+    ul.sections li:hover ul li:hover ul li a, ul.sections li a:hover ul li a:hover ul li a {
+        width:14em; background:#d8d8d8;}
+    ul.sections li:hover ul li:hover ul li a:hover, ul.sections li a:hover ul li a:hover ul li a:hover {
+        width:14em; background:white;}
+
+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;}
+
+    /**
+     * The .inner class is for the content wrapper on inner pages (as opposed to the home page)
+     */
+    div#content .inner {
+        width:auto; padding: 4em 10%; position:relative;
+        background: rgba(171, 204, 113, 0.6); border-top:2px solid #abcc71;
+        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 ul {margin:1.5em; 1em;}
+    div#content .inner p {margin:1em 0;}
+
+div#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);}
+    div#footer .aside {display:inline-block; width:15%; margin-left:1%; vertical-align:top;}
+        div#footer .aside.first {margin-left:0;}
+        div#footer .aside.third, div#footer .aside.fifth {margin-left:2.5%}
+        div#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;}
+        div#footer .aside ul {margin:0; padding:0;}
+        div#footer .aside ul li {list-style-type:none; line-height:1.5em;}
+        div#footer .aside ul li a {color:#ccaa66; font-weight:bold;}
+        div#footer .aside ul li a:hover {text-decoration:underline;}
+        div#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/www.i2p2/i2p2www/static/styles/reset.css b/www.i2p2/i2p2www/static/styles/reset.css
new file mode 100644
index 00000000..907f6e20
--- /dev/null
+++ b/www.i2p2/i2p2www/static/styles/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;
+}

From a6ad8818e5e754482864af35b5bc502d69d6ecc3 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Mon, 10 Sep 2012 23:40:49 +0000
Subject: [PATCH 15/75] Replaced hard-coded paths in layout and langbox with
 url_for

---
 www.i2p2/i2p2www/pages/global/lang.html   | 22 +++++++++++-----------
 www.i2p2/i2p2www/pages/global/layout.html |  6 +++---
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/www.i2p2/i2p2www/pages/global/lang.html b/www.i2p2/i2p2www/pages/global/lang.html
index 4bff095f..f871689c 100644
--- a/www.i2p2/i2p2www/pages/global/lang.html
+++ b/www.i2p2/i2p2www/pages/global/lang.html
@@ -1,13 +1,13 @@
 
      
-  
    • English
      • 
-  
    • Castellano
      • 
-  
    • Chinese
      • 
-  
    • Deutsch
      • 
-  
    • Français
      • 
-  
    • Italiano
      • 
-  
    • Nederlands
      • 
-  
    • Russian
      • 
-  
    • Svenska
      • 
-  
    • Czech
      • 
-  
    • Arabic
      • 
+  
    • English
      • 
+  
    • Castellano
      • 
+  
    • Chinese
      • 
+  
    • Deutsch
      • 
+  
    • Français
      • 
+  
    • Italiano
      • 
+  
    • Nederlands
      • 
+  
    • Russian
      • 
+  
    • Svenska
      • 
+  
    • Czech
      • 
+  
    • Arabic
      • 
 
    
diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
index c5a0dc59..82cd27a9 100644
--- a/www.i2p2/i2p2www/pages/global/layout.html
+++ b/www.i2p2/i2p2www/pages/global/layout.html
@@ -3,14 +3,14 @@
   
     
     {% block title %}{% endblock %} - I2P
-    
-    
+    
+    
     
   
   
     
    Skip navigation
    
     
    
-      
    I2P
    
+      
    I2P
    
       
    {{ self.title() }}
    
     
    
     
    

From a2bc992a49dd1912de9d936f3448b6a5b17e2f41 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Tue, 11 Sep 2012 00:01:46 +0000
Subject: [PATCH 16/75] Some more url migrations

---
 www.i2p2/i2p2www/pages/global/layout.html |  2 +-
 www.i2p2/i2p2www/pages/global/nav.html    | 10 +++++-----
 www.i2p2/i2p2www/pages/site/index.html    |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
index 82cd27a9..5a8b5dca 100644
--- a/www.i2p2/i2p2www/pages/global/layout.html
+++ b/www.i2p2/i2p2www/pages/global/layout.html
@@ -10,7 +10,7 @@
   
     
    Skip navigation
    
     
    
-      
    I2P
    
+      
    I2P
    
       
    {{ self.title() }}
    
     
    
     
    
diff --git a/www.i2p2/i2p2www/pages/global/nav.html b/www.i2p2/i2p2www/pages/global/nav.html
index d51055d6..7a839d29 100644
--- a/www.i2p2/i2p2www/pages/global/nav.html
+++ b/www.i2p2/i2p2www/pages/global/nav.html
@@ -1,6 +1,6 @@
 
      
-  
    • Home
      • 
-  
    • Download
      • 
+  
    • Home
      • 
+  
    • Download
      • 
   
    • Docs
     
   
      • 
   
    • Volunteer
      • 
-  
    • News
+  
    • News
     
diff --git a/www.i2p2/i2p2www/pages/site/index.html b/www.i2p2/i2p2www/pages/site/index.html
index c7647ddd..d1204bcc 100644
--- a/www.i2p2/i2p2www/pages/site/index.html
+++ b/www.i2p2/i2p2www/pages/site/index.html
@@ -4,7 +4,7 @@
 
      
   
      What does I2P do for you?
      
   
      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 on I2P.
      
-  Get I2P 0.9.1
+  Get I2P 0.9.1
 
      
 
      
   
      

From 4f9ef2b7114ffdc02bf5c582336db4f0d3693265 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Tue, 11 Sep 2012 00:09:39 +0000
Subject: [PATCH 17/75] Modified layout.html to use 
       by
 default

---
 www.i2p2/i2p2www/pages/global/layout.html | 4 ++++
 www.i2p2/i2p2www/pages/site/index.html    | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/www.i2p2/i2p2www/pages/global/layout.html
index 5a8b5dca..78fd3d7f 100644
--- a/www.i2p2/i2p2www/pages/global/layout.html
+++ b/www.i2p2/i2p2www/pages/global/layout.html
@@ -18,7 +18,11 @@
       {% include "global/nav.html" %}
     
      
     
      
+      {% block content_outer %}
+      
      
       {% block content %}{% endblock %}
+      
      
+      {% endblock %}
     
      
     
    • Download
      • 
   
    • Docs
     
diff --git a/www.i2p2/pages/how_cryptography.html b/www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
similarity index 91%
rename from www.i2p2/pages/how_cryptography.html
rename to www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
index 08377b1f..c5ffc62a 100644
--- a/www.i2p2/pages/how_cryptography.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Low-level Cryptography Details{% endblock %}
 {% block content %}
 
      
@@ -12,7 +12,7 @@ one asymmetric algorithm, one signing algorithm, and one hashing algorithm.  How
 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).
+technique used in ElGamal/AES+SessionTag (but we're sure others have done it).
 
      
 
      ElGamal encryption
      
 
@@ -25,7 +25,7 @@ To encrypt router-to-router Tunnel Build Mess
 For end-to-end (destination-to-destination) encryption as a part of ElGamal/AES+SessionTag
 using the encryption key in the LeaseSet
 
    • 
-For encryption of some netDb stores and queries sent to floodfill routers
+For encryption of some netDb stores and queries sent to floodfill routers
 as a part of ElGamal/AES+SessionTag
 (destination-to-router or router-to-router).
 
    
@@ -158,13 +158,13 @@ AES is used for symmetric encryption, in several cases:
 
 
    
 We use AES with 256 bit keys and 128 bit blocks in CBC mode.
@@ -327,9 +327,9 @@ It may be quite difficult to make any change backward-compatible.
 
    References
    
 
      
 
    • 
-Meeting 51
+Meeting 51
 
    • 
-Meeting 52
+Meeting 52
 
    • 
 Choosing the constants
 
    • 
@@ -376,7 +376,7 @@ 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.
 
      
 
      
 In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
diff --git a/www.i2p2/pages/how_elgamalaes.html b/www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
similarity index 98%
rename from www.i2p2/pages/how_elgamalaes.html
rename to www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
index b2b501fd..01e45f7c 100644
--- a/www.i2p2/pages/how_elgamalaes.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}ElGamal/AES + SessionTag  Encryption{% endblock %}
 {% block content %}
 Updated February 2011, current as of router version 0.8.3
@@ -142,7 +142,7 @@ The 32-byte Pre-IV will be used to generate the IV for the AES block that follow
 the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
 
      
 The 222 byte payload is encrypted
-using ElGamal
+using ElGamal
 and the encrypted block is 514 bytes long.
 
      
 
@@ -212,7 +212,7 @@ Minimum length: 48 bytes
 
 
 
      
-The data is then AES Encrypted,
+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.
 
      
diff --git a/www.i2p2/pages/how_garlicrouting.html b/www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
similarity index 90%
rename from www.i2p2/pages/how_garlicrouting.html
rename to www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
index 71841492..cd311d88 100644
--- a/www.i2p2/pages/how_garlicrouting.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Garlic Routing{% endblock %}
 {% block content %}
      
 Updated August 2010 for release 0.8
@@ -42,7 +42,7 @@ 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.
 
      
 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
@@ -84,7 +84,7 @@ and reliable delivery.
 
 
      ElGamal/AES Encryption
      
 In some cases, "garlic encryption" may simply mean
-ElGamal/AES+SessionTag encryption
+ElGamal/AES+SessionTag encryption
 (without multiple layers).
 
 
@@ -117,7 +117,7 @@ This is described on the
 Tunnel building details are defined on
 this page.
 We use
-ElGamal/AES+SessionTag for the encryption.
+ElGamal/AES+SessionTag for the encryption.
 
      
 Tunnels are a general-purpose mechanism to transport all
 I2NP messages, and
@@ -134,7 +134,7 @@ the tunnel encryption is sufficient.
 At the layer above tunnels, I2P delivers end-to-end messages between
 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
@@ -174,7 +174,7 @@ By periodically bundling a LeaseSet, the router ensures that the far-end will be
 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.
 
      • 
 
 
      
@@ -191,7 +191,7 @@ and not part of a general-purpose routing scheme.
 
       Storage to the Floodfill Network Database
      
 
      
 As explained on the
-network database page,
+network database page,
 local
 LeaseSets
 are sent to floodfill routers in a
@@ -220,14 +220,14 @@ as limiting certain routing paths, restricting the types of I2NP messages that m
 be forwarded along various paths, and enforcing certain message expiration times.
 
      
 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.
 
      
 Encryption of additional messages to and from the
-floodfill routers.
+floodfill routers.
 
      
 
 
@@ -246,7 +246,7 @@ see Section 8.1.1 authored by
 
    • 
 Garlic Routing on Wikipedia
 
    • 
-I2P Meeting 58 (2003) discussing the implementation of garlic routing
+I2P Meeting 58 (2003) discussing the implementation of garlic routing
 
    • 
 Tor
 
    • 
diff --git a/www.i2p2/pages/how.html b/www.i2p2/i2p2www/pages/site/docs/how/index.html
similarity index 76%
rename from www.i2p2/pages/how.html
rename to www.i2p2/i2p2www/pages/site/docs/how/index.html
index f9121635..0d6950df 100644
--- a/www.i2p2/pages/how.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/index.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Index to Technical Documentation{% endblock %}
 {% block content %}
 
      How does I2P work?
      
@@ -21,13 +21,13 @@ If you find any inaccuracies in the documents linked below, please
 
 
      Overview
      
 
 
 
      Application-Layer Topics
      
@@ -101,16 +101,16 @@ 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
      
@@ -130,16 +130,16 @@ I2P is a message-oriented router. The messages sent between routers are defined
 
      Tunnels
      
 Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
 
 
@@ -154,9 +154,9 @@ The protocols for direct (point-to-point) router to router communication.
 
    • 
 SSU specification
 
    • 
-NTCP transport encryption
+NTCP transport encryption
 
    • 
-SSU transport encryption
+SSU transport encryption
 
    • 
 Transport Javadoc
 
    • 
diff --git a/www.i2p2/pages/how_intro.html b/www.i2p2/i2p2www/pages/site/docs/how/intro.html
similarity index 81%
rename from www.i2p2/pages/how_intro.html
rename to www.i2p2/i2p2www/pages/site/docs/how/intro.html
index d56bf2ca..b460686d 100644
--- a/www.i2p2/pages/how_intro.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/intro.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}A Gentle Introduction{% endblock %}
 {% block content %}
 
@@ -32,7 +32,7 @@ Instead their view will be of one of the I2P enabled applications, or perhaps as
 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 
+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
@@ -43,23 +43,23 @@ 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 
+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). 
+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 
+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
      
+
      Network topology example
      
 
 
 
      In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their 
@@ -73,7 +73,7 @@ network database, which is constantly updated as new leases are authorized and o
   
 
      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 
+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.
      
 
@@ -81,12 +81,12 @@ in the network database for the current data.
      
 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.
      
+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 - 
+
      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.
      
+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 
@@ -98,9 +98,9 @@ Notice the different use of terms! All data from a to h is end-to-end encrypted,
 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
      
+
      End to end layered encryption
      
 
-
      The specific use of these algorithms are outlined elsewhere.
      
+
      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 
@@ -111,7 +111,7 @@ 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 
+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.
      
@@ -138,13 +138,13 @@ are being written in Python and other languages. The code works on archives are available.
      
+archives are available.
      
 
 
      The current source is available in monotone.
      
 
 
      Additional Information
      
 
      
-See the Index to Technical Documentation
+See the Index to Technical Documentation
 
      
 
 {% endblock %}
diff --git a/www.i2p2/pages/how_networkcomparisons.html b/www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
similarity index 97%
rename from www.i2p2/pages/how_networkcomparisons.html
rename to www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
index f3733e99..2a15493c 100644
--- a/www.i2p2/pages/how_networkcomparisons.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/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 
@@ -37,8 +37,8 @@ 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.
      
+opposed to I2P's distributed network 
+database and peer selection.
      
 
 
      The I2P/Tor outproxy functionality does have a few 
 substantial weaknesses against certain attackers - 
diff --git a/www.i2p2/pages/how_networkdatabase.html b/www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
similarity index 97%
rename from www.i2p2/pages/how_networkdatabase.html
rename to www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
index 3f44ccba..f05d9761 100644
--- a/www.i2p2/pages/how_networkdatabase.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}The Network Database{% endblock %}
 {% block content %}
 
@@ -506,7 +506,7 @@
 
 
      Threat Analysis
      
 
      
-  Also discussed on the threat model page.
+  Also discussed on the threat model page.
 
      
 
      
   A hostile user may attempt to harm the network by
@@ -538,7 +538,7 @@
 
      Slow or Unresponsive
      
 
      
   Each router maintains an expanded set of statistics in the
-  peer profile for each floodfill router,
+  peer profile for each floodfill router,
   covering various quality metrics for that peer.
   The set includes:
 
      
@@ -709,7 +709,7 @@ This attack becomes more difficult as the network size grows.
 
      
 
      
   This doesn't have much to do with floodfill, but see
-  the peer selection page
+  the peer selection page
   for a discussion of the vulnerabilities of peer selection for tunnels.
 
      
 
@@ -722,8 +722,8 @@ This attack becomes more difficult as the network size grows.
   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
+  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.
 
      
@@ -739,7 +739,7 @@ This attack becomes more difficult as the network size grows.
   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,
   here and
   here)
   become problematic for several reasons.
diff --git a/www.i2p2/pages/how_peerselection.html b/www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
similarity index 92%
rename from www.i2p2/pages/how_peerselection.html
rename to www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
index 429a028d..693d5c1b 100644
--- a/www.i2p2/pages/how_peerselection.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Peer Profiling and Selection{% endblock %}
 {% block content %}
 
@@ -11,14 +11,14 @@ Updated July 2010 for release 0.8
 
      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.
+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
+    which is discussed on the network database page
 
      
 
 
@@ -38,7 +38,7 @@ 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
+timing attacks
 more difficult.
 
      
 
      
@@ -49,7 +49,7 @@ 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
+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.
@@ -230,7 +230,7 @@ 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,
+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
@@ -243,7 +243,7 @@ please keep in mind the following minor changes in I2P since the paper's publica
 
        References
        
 
          
 
        • 
-Peer Profiling and Selection in the I2P Anonymous Network
+Peer Profiling and Selection in the I2P Anonymous Network
 
        • 
 One Cell Enough
 
        • 
diff --git a/www.i2p2/pages/how_threatmodel.html b/www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
similarity index 94%
rename from www.i2p2/pages/how_threatmodel.html
rename to www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
index 604cd01c..f82c3455 100644
--- a/www.i2p2/pages/how_threatmodel.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}I2P's Threat Model{% endblock %}
 {% block content %}
 
@@ -24,7 +24,7 @@ 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 
+
          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
@@ -88,8 +88,8 @@ 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
+network comparisons and
+"garlic" terminology pages may also be helpful
 to review.
 
            
 
@@ -147,7 +147,7 @@ routers contain limits as to how many tunnels can be routed through a single pee
 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.
+peer selection page.
 
            
 
 
@@ -203,7 +203,7 @@ Partial defenses implemented in I2P:
 
 
 Even in total, these defenses are not a complete solution.
@@ -270,7 +270,7 @@ each with different costs and consequences:
              
     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 
+    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
@@ -305,10 +305,10 @@ each with different costs and consequences:
              
 
@@ -356,7 +356,7 @@ matter, the attacker would need to control a significant portion of the network
 which other tunnels or messages have those delays).
 
              
 Also discussed on the
-    network database page (bootstrap attack).
+    network database page (bootstrap attack).
 
              
 
 
              Predecessor attacks
              
@@ -371,7 +371,7 @@ 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
+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
@@ -505,7 +505,7 @@ in several IP blocks.
 However, this is not a meaningful defense against a powerful adversary.
 
              
 See the
-  network database page
+  network database page
 for more Sybil discussion.
 
              
 
@@ -521,7 +521,7 @@ 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
+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.
@@ -537,7 +537,7 @@ Further research and defenses may be necessary.
 
              
 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. 
+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,
@@ -555,7 +555,7 @@ 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 
+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.
@@ -578,9 +578,9 @@ 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.
+  network database page.
 The specific mechanisms by which routers communicate with floodfills have been
-  carefully designed.
+  carefully designed.
 However, these threats should be studied further.
 The specific potential threats and corresponding defenses are a topic for future research.
 
              
@@ -592,7 +592,7 @@ The specific potential threats and corresponding defenses are a topic for future
   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.
+  network database page.
 
              
 
 
diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
similarity index 90%
rename from www.i2p2/pages/how_tunnelrouting.html
rename to www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
index cc9849de..43ae9767 100644
--- a/www.i2p2/pages/how_tunnelrouting.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Tunnel Overview{% endblock %}
 {% block content %}
 
              
@@ -10,7 +10,7 @@ Updated July 2011 for release 0.8.7
 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" -
+
              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
@@ -20,7 +20,7 @@ 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
+Tunnel
 
               A: Outbound Gateway (Alice)
 B: Outbound Participant
@@ -35,7 +35,7 @@ F: Inbound Endpoint (Bob)
 
                
 	
              • 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
+	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
@@ -157,7 +157,7 @@ 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,
+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.
                
@@ -190,12 +190,12 @@ DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunne
 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.
+capacity rating in the peer profile.
 
                
 
 
 
                Tunnel creation
                
-
                Tunnel creation is handled by garlic routing
+
                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
@@ -207,7 +207,7 @@ Details are in the
 
 
 
                Tunnel encryption
                
-
                Multi-layer encryption is handled by garlic encryption
+
                Multi-layer encryption is handled by garlic encryption
 of tunnel messages.
 Details are in the
 tunnel specification.
@@ -245,9 +245,9 @@ tunnel's lifetime may be implemented (e.g. no more than 300 messages or
 
              • 
 tunnel message specification
 
              • 
-garlic routing
+garlic routing
 
              • 
-ElGamal/AES+SessionTag
+ElGamal/AES+SessionTag
 
              • 
 I2CP options
 
                • 
diff --git a/www.i2p2/pages/techintro.html b/www.i2p2/i2p2www/pages/site/docs/techintro.html
similarity index 98%
rename from www.i2p2/pages/techintro.html
rename to www.i2p2/i2p2www/pages/site/docs/techintro.html
index 3e4645f2..e05b35c9 100644
--- a/www.i2p2/pages/techintro.html
+++ b/www.i2p2/i2p2www/pages/site/docs/techintro.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Introducing I2P{% endblock %}
 {% block content %}
 
@@ -111,7 +111,7 @@
     another tunnel is required.
   
                
     
                
-      Inbound and outbound tunnel schematic
+      Inbound and outbound tunnel schematic
       

                
       Figure 1: Two types of tunnels exist: inbound and outbound.
     
                
@@ -159,9 +159,9 @@
     that router to send the construction message onward, until the tunnel has been constructed.
   
                
     
                
-      Request information on other routers
+      Request information on other routers
                          
-      Build tunnel using router information
+      Build tunnel using router information
       

                
       Figure 2: Router information is used to build tunnels.
     
                
@@ -183,7 +183,7 @@
     for it when he wants to reply, but this is optional.
   
                
     
                
-      Connect tunnels using leaseSets
+      Connect tunnels using leaseSets
       

                
       Figure 3: Leasesets are used to connect outbound and inbound tunnels.
     
                
@@ -306,7 +306,7 @@
   
                Network Database
                
   
                
     As mentioned earlier, I2P's netDb works to share the network's metadata.
-    This is detailed in the networkdatabase page,
+    This is detailed in the networkdatabase page,
     but a basic explanation is available below.
   
                
   
                
@@ -320,7 +320,7 @@
     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.
+    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).
   
                
@@ -576,7 +576,7 @@ What other tunnel peer selection and ordering strategies should be available?
     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. 
+  
                 See also the Network Comparisons Page. 
   
                
 
   
                Tor
                

From 1b4e2025256c7fd198e8764efda0a470d418d861 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 05:08:51 +0000
Subject: [PATCH 21/75] Finished blog index methods, added a basic blog index
 template

---
 www.i2p2/i2p2www/__init__.py           | 13 ++++++++-----
 www.i2p2/i2p2www/pages/blog/index.html | 10 ++++++++++
 2 files changed, 18 insertions(+), 5 deletions(-)
 create mode 100644 www.i2p2/i2p2www/pages/blog/index.html

diff --git a/www.i2p2/i2p2www/__init__.py b/www.i2p2/i2p2www/__init__.py
index c1644d0a..6526416c 100644
--- a/www.i2p2/i2p2www/__init__.py
+++ b/www.i2p2/i2p2www/__init__.py
@@ -221,18 +221,19 @@ def get_blog_index():
     """
     Returns list of valid slugs sorted by date
     """
-    ret=[]
-
-    # list of slugs(not sorted in any way)
+    # list of slugs
     entries=[]
     # 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
-
+            entries.append(safe_join(slugbase, f[:-4]))
+    entries.sort()
+    return entries
 
 def render_blog_entry(slug):
     """
@@ -260,7 +261,9 @@ def render_blog_entry(slug):
 @app.route('//blog/page/')
 def blog_index(page=0):
     # TODO: implement
-    pass
+    entries = get_blog_index()
+
+    return render_template('blog/index.html', entries=entries)
 
 @app.route('//blog/entry/')
 def blog_entry(slug):
diff --git a/www.i2p2/i2p2www/pages/blog/index.html b/www.i2p2/i2p2www/pages/blog/index.html
new file mode 100644
index 00000000..da883323
--- /dev/null
+++ b/www.i2p2/i2p2www/pages/blog/index.html
@@ -0,0 +1,10 @@
+{% extends "global/layout.html" %}
+{% block title %}Blog Index{% endblock %}
+{% block content %}
+
                Some descriptive text.
                
+
                  
+{% for entry in entries -%}
+  
                • {{ entry }}
                  • 
+{%- endfor %}
+
                
+{% endblock %}

From b9255e78cb3520bfea22a56710c1422521ced469 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 06:15:29 +0000
Subject: [PATCH 22/75] Modified language urls to track current page (in most
 cases)

---
 www.i2p2/i2p2www/pages/global/lang.html | 28 +++++++++++++++----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/www.i2p2/i2p2www/pages/global/lang.html b/www.i2p2/i2p2www/pages/global/lang.html
index f871689c..c62ab667 100644
--- a/www.i2p2/i2p2www/pages/global/lang.html
+++ b/www.i2p2/i2p2www/pages/global/lang.html
@@ -1,13 +1,19 @@
+{%- macro change_lang(lang) -%}
+{%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
+{%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
+{%- else -%}{{ url_for('site_show', lang=lang) }}
+{%- endif -%}
+{%- endmacro -%}
 
                  
-  
                • English
                  • 
-  
                • Castellano
                  • 
-  
                • Chinese
                  • 
-  
                • Deutsch
                  • 
-  
                • Français
                  • 
-  
                • Italiano
                  • 
-  
                • Nederlands
                  • 
-  
                • Russian
                  • 
-  
                • Svenska
                  • 
-  
                • Czech
                  • 
-  
                • Arabic
                  • 
+  
                • English
                  • 
+  
                • Castellano
                  • 
+  
                • Chinese
                  • 
+  
                • Deutsch
                  • 
+  
                • Français
                  • 
+  
                • Italiano
                  • 
+  
                • Nederlands
                  • 
+  
                • Russian
                  • 
+  
                • Svenska
                  • 
+  
                • Czech
                  • 
+  
                • Arabic
                  • 
 
                

From ed9fd2694c0d0ec71512dcc238a79b100e25411a Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 06:16:18 +0000
Subject: [PATCH 23/75] Hard-coded application name (as per Flask docs)

---
 www.i2p2/i2p2www/__init__.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www.i2p2/i2p2www/__init__.py b/www.i2p2/i2p2www/__init__.py
index 6526416c..60fa4f47 100644
--- a/www.i2p2/i2p2www/__init__.py
+++ b/www.i2p2/i2p2www/__init__.py
@@ -13,7 +13,7 @@ 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')
 
-app = application = Flask(__name__, template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR)
+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'))
 
 

From cfc96e284292e4a4b71ee1f703b7d8e4be4df515 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 06:20:10 +0000
Subject: [PATCH 24/75] Run i2p2www in production mode

---
 www.i2p2/runserver.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/www.i2p2/runserver.py b/www.i2p2/runserver.py
index 45e60621..695772b8 100644
--- a/www.i2p2/runserver.py
+++ b/www.i2p2/runserver.py
@@ -1,2 +1,2 @@
 from i2p2www import app
-app.run(debug=True)
+app.run(debug=False)

From 03b8c33b8677bf6bb5a32c5545ba4ccdd198d6b9 Mon Sep 17 00:00:00 2001
From: dev 
Date: Wed, 12 Sep 2012 17:21:37 +0000
Subject: [PATCH 25/75] add basic blog entry template

---
 pages/blog/entry.html | 7 +++++++
 1 file changed, 7 insertions(+)
 create mode 100644 pages/blog/entry.html

diff --git a/pages/blog/entry.html b/pages/blog/entry.html
new file mode 100644
index 00000000..93786cb2
--- /dev/null
+++ b/pages/blog/entry.html
@@ -0,0 +1,7 @@
+{% extends "global/layout.html" %}
+{% block title %}{{ title }} - Blog{% endblock %}
+{% block content %}
+{% autoescape false %}
+{{ body }}
+{% endautoescape %}
+{% endblock %}

From 897e8605b02e901e7a97e3ee67ea23f6f63c1f7c Mon Sep 17 00:00:00 2001
From: dev 
Date: Wed, 12 Sep 2012 17:22:56 +0000
Subject: [PATCH 26/75] applied partial changes from
 720393956bd6eaceef4ba3f5be0dc3296a0f7e86                      through
 a7375a677ec43f581eeae1b569f1ccd1885d5198

---
 app.py | 13 ++++++++-----
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/app.py b/app.py
index 477c4c87..59d47749 100644
--- a/app.py
+++ b/app.py
@@ -213,18 +213,19 @@ def get_blog_index():
     """
     Returns list of valid slugs sorted by date
     """
-    ret=[]
-
-    # list of slugs(not sorted in any way)
+    # list of slugs
     entries=[]
     # 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
-
+            entries.append(safe_join(slugbase, f[:-4]))
+    entries.sort()
+    return entries
 
 def render_blog_entry(slug):
     """
@@ -252,7 +253,9 @@ def render_blog_entry(slug):
 @app.route('//blog/page/')
 def blog_index(page=0):
     # TODO: implement
-    pass
+    entries = get_blog_index()
+
+    return render_template('blog/index.html', entries=entries)
 
 @app.route('//blog/entry/')
 def blog_entry(slug):

From 6d0fbc13cb6390cd42f1708a5e169a093daac15a Mon Sep 17 00:00:00 2001
From: dev 
Date: Wed, 12 Sep 2012 17:25:46 +0000
Subject: [PATCH 27/75] backport simple blog index page from rev
 a7375a677ec43f581eeae1b569f1ccd1885d5198

---
 pages/blog/index.html | 10 ++++++++++
 1 file changed, 10 insertions(+)
 create mode 100644 pages/blog/index.html

diff --git a/pages/blog/index.html b/pages/blog/index.html
new file mode 100644
index 00000000..da883323
--- /dev/null
+++ b/pages/blog/index.html
@@ -0,0 +1,10 @@
+{% extends "global/layout.html" %}
+{% block title %}Blog Index{% endblock %}
+{% block content %}
+
                Some descriptive text.
                
+
                  
+{% for entry in entries -%}
+  
                • {{ entry }}
                  • 
+{%- endfor %}
+
                
+{% endblock %}

From 0cae2d6bb8630f70a9a0af912adfae0ad519f593 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 21:15:30 +0000
Subject: [PATCH 28/75] Pass date and 'title' through to blog/index.html

If the same info is needed on the front page, should the date/title stuff
be moved into get_blog_index, or a separate method which both can call
(maybe straight from the template)?
---
 www.i2p2/i2p2www/__init__.py           | 12 ++++++++++--
 www.i2p2/i2p2www/pages/blog/index.html |  2 +-
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/www.i2p2/i2p2www/__init__.py b/www.i2p2/i2p2www/__init__.py
index 60fa4f47..be03a629 100644
--- a/www.i2p2/i2p2www/__init__.py
+++ b/www.i2p2/i2p2www/__init__.py
@@ -235,6 +235,10 @@ def get_blog_index():
     entries.sort()
     return entries
 
+def get_date_from_slug(slug):
+    parts = slug.split('/')
+    return "%s-%s-%s" % (parts[0], parts[1], parts[2])
+
 def render_blog_entry(slug):
     """
     Render the blog entry
@@ -260,8 +264,12 @@ def render_blog_entry(slug):
 @app.route('//blog/')
 @app.route('//blog/page/')
 def blog_index(page=0):
-    # TODO: implement
-    entries = get_blog_index()
+    slugs = get_blog_index()
+    entries= []
+    for slug in slugs:
+        date = get_date_from_slug(slug)
+        title = slug.rsplit('/', 1)[1]
+        entries.append((slug, date, title))
 
     return render_template('blog/index.html', entries=entries)
 
diff --git a/www.i2p2/i2p2www/pages/blog/index.html b/www.i2p2/i2p2www/pages/blog/index.html
index da883323..28853787 100644
--- a/www.i2p2/i2p2www/pages/blog/index.html
+++ b/www.i2p2/i2p2www/pages/blog/index.html
@@ -4,7 +4,7 @@
 
                Some descriptive text.
                
 
 {% endblock %}

From e55dd6185ef70f5186291a07e16c232823673083 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 21:30:36 +0000
Subject: [PATCH 29/75] Moved i2p2www to root directory (since other sites
 stored in i2p.www will be (re)moved)

---
 {www.i2p2/i2p2www => i2p2www}/__init__.py           |   0
 .../i2p2www => i2p2www}/blog/2006/10/10/status.html |   0
 .../i2p2www => i2p2www}/blog/2006/10/10/status.rst  |   0
 {www.i2p2/i2p2www => i2p2www}/meetings/208.log      |   0
 {www.i2p2/i2p2www => i2p2www}/pages/blog/index.html |   0
 .../i2p2www => i2p2www}/pages/downloads/list.html   |   0
 .../i2p2www => i2p2www}/pages/global/error_404.html |   0
 .../i2p2www => i2p2www}/pages/global/error_500.html |   0
 .../i2p2www => i2p2www}/pages/global/footer.html    |   0
 .../i2p2www => i2p2www}/pages/global/lang.html      |   0
 .../i2p2www => i2p2www}/pages/global/layout.html    |   0
 {www.i2p2/i2p2www => i2p2www}/pages/global/nav.html |   0
 {www.i2p2/i2p2www => i2p2www}/pages/global/urlify   |   0
 .../i2p2www => i2p2www}/pages/meetings/index.html   |   0
 .../pages/site/docs/how/cryptography.html           |   0
 .../pages/site/docs/how/elgamalaes.html             |   0
 .../pages/site/docs/how/garlicrouting.html          |   0
 .../pages/site/docs/how/index.html                  |   0
 .../pages/site/docs/how/intro.html                  |   0
 .../pages/site/docs/how/networkcomparisons.html     |   0
 .../pages/site/docs/how/networkdatabase.html        |   0
 .../pages/site/docs/how/peerselection.html          |   0
 .../pages/site/docs/how/threatmodel.html            |   0
 .../pages/site/docs/how/tunnelrouting.html          |   0
 .../pages/site/docs/techintro.html                  |   0
 {www.i2p2/i2p2www => i2p2www}/pages/site/index.html |   0
 {www.i2p2/i2p2www => i2p2www}/static/favicon.ico    | Bin
 .../static/images/I2PTunnel-streamr.png             | Bin
 .../static/images/add-key-terminal.png              | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/ar.png  | Bin
 .../static/images/bandwidth2009.png                 | Bin
 .../i2p2www => i2p2www}/static/images/btn_left.png  | Bin
 .../i2p2www => i2p2www}/static/images/btn_right.png | Bin
 .../static/images/btn_stretch.png                   | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/cs.png  | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/cz.png  | Bin
 .../i2p2www => i2p2www}/static/images/dark.png      | Bin
 .../static/images/darkbluebg.png                    | Bin
 .../static/images/darkbluetile.png                  | Bin
 .../static/images/darkerbluetile.png                | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/de.png  | Bin
 .../i2p2www => i2p2www}/static/images/dots.png      | Bin
 .../i2p2www => i2p2www}/static/images/download.png  | Bin
 .../static/images/download_dark.png                 | Bin
 .../static/images/endToEndEncryption.png            | Bin
 .../static/images/endToEndEncryption_fr.png         | Bin
 .../static/images/endToEndEncryption_zh.png         | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/es.png  | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/eu.png  | Bin
 .../static/images/firefox.options.jpg               | Bin
 .../static/images/firefox.options_fr.png            | Bin
 .../static/images/firefox.proxyports.jpg            | Bin
 .../static/images/firefox.proxyports_fr.png         | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/fr.png  | Bin
 .../static/images/garliccloves.png                  | Bin
 .../i2p2www => i2p2www}/static/images/help.png      | Bin
 .../i2p2www => i2p2www}/static/images/help_dark.png | Bin
 .../i2p2www => i2p2www}/static/images/i2plogo.png   | Bin
 .../static/images/i2ptunnel_peertopeer.png          | Bin
 .../static/images/i2ptunnel_serverclient.png        | Bin
 .../static/images/i2pvstor_zh.png                   | Bin
 .../static/images/ie.options.jpg                    | Bin
 .../static/images/ie.options_fr.png                 | Bin
 .../static/images/ie.proxyports.jpg                 | Bin
 .../static/images/ie.proxyports_fr.png              | Bin
 .../i2p2www => i2p2www}/static/images/info.png      | Bin
 .../i2p2www => i2p2www}/static/images/info_dark.png | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/it.png  | Bin
 .../i2p2www => i2p2www}/static/images/itoopie.png   | Bin
 .../static/images/konqueror.options.jpg             | Bin
 .../static/images/konqueror.options_fr.jpg          | Bin
 .../static/images/konqueror.proxyports.jpg          | Bin
 .../static/images/konqueror.proxyports_fr.jpg       | Bin
 .../i2p2www => i2p2www}/static/images/lang_ar.png   | Bin
 .../i2p2www => i2p2www}/static/images/light.png     | Bin
 .../static/images/lightbluetile.png                 | Bin
 .../i2p2www => i2p2www}/static/images/link.png      | Bin
 .../i2p2www => i2p2www}/static/images/link_dark.png | Bin
 .../i2p2www => i2p2www}/static/images/logo07c.jpg   | Bin
 .../static/images/logo_medium.png                   | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/net.png | Bin
 .../i2p2www => i2p2www}/static/images/net_fr.png    | Bin
 .../static/images/netdb_get_leaseset.png            | Bin
 .../static/images/netdb_get_leaseset_fr.png         | Bin
 .../static/images/netdb_get_routerinfo_1.png        | Bin
 .../static/images/netdb_get_routerinfo_1_fr.png     | Bin
 .../static/images/netdb_get_routerinfo_2.png        | Bin
 .../static/images/netdb_get_routerinfo_2_fr.png     | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/nl.png  | Bin
 .../i2p2www => i2p2www}/static/images/plan.png      | Bin
 .../static/images/protocol_stack.png                | Bin
 .../static/images/protocol_stack_fr.png             | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/ru.png  | Bin
 .../i2p2www => i2p2www}/static/images/sqbullet.png  | Bin
 .../static/images/stackoverflow_ad.png              | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/sv.png  | Bin
 .../i2p2www => i2p2www}/static/images/tabletile.png | Bin
 .../static/images/tabletile_alt.png                 | Bin
 .../static/images/tabletitledark.png                | Bin
 .../static/images/tabletitlelight-tall.png          | Bin
 .../static/images/tabletitlelight.png               | Bin
 .../i2p2www => i2p2www}/static/images/target.png    | Bin
 .../static/images/tunnelSending.png                 | Bin
 .../i2p2www => i2p2www}/static/images/tunnels.png   | Bin
 .../static/images/tunnels_fr.png                    | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/udp.png | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/us.png  | Bin
 {www.i2p2/i2p2www => i2p2www}/static/images/zh.png  | Bin
 {www.i2p2/i2p2www => i2p2www}/static/news/news.xml  |   0
 .../i2p2www => i2p2www}/static/pdf/I2CP_spec.pdf    | Bin
 .../i2p2www => i2p2www}/static/pdf/I2NP_spec.pdf    | Bin
 .../static/pdf/I2P-PET-CON-2009.1.pdf               | Bin
 .../static/pdf/datastructures.pdf                   | Bin
 .../static/pdf/i2p_philosophy.pdf                   | Bin
 .../static/pdf/polling_http_transport.pdf           | Bin
 .../i2p2www => i2p2www}/static/styles/dark.css      |   0
 .../i2p2www => i2p2www}/static/styles/default.css   |   0
 .../i2p2www => i2p2www}/static/styles/duck.css      |   0
 .../i2p2www => i2p2www}/static/styles/light.css     |   0
 .../i2p2www => i2p2www}/static/styles/light_ar.css  |   0
 .../i2p2www => i2p2www}/static/styles/light_zh.css  |   0
 .../i2p2www => i2p2www}/static/styles/mainmenu.css  |   0
 .../i2p2www => i2p2www}/static/styles/reset.css     |   0
 www.i2p2/runserver.py => runserver.py               |   0
 124 files changed, 0 insertions(+), 0 deletions(-)
 rename {www.i2p2/i2p2www => i2p2www}/__init__.py (100%)
 rename {www.i2p2/i2p2www => i2p2www}/blog/2006/10/10/status.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/blog/2006/10/10/status.rst (100%)
 rename {www.i2p2/i2p2www => i2p2www}/meetings/208.log (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/blog/index.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/downloads/list.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/error_404.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/error_500.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/footer.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/lang.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/layout.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/nav.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/global/urlify (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/meetings/index.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/cryptography.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/elgamalaes.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/garlicrouting.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/index.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/intro.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/networkcomparisons.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/networkdatabase.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/peerselection.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/threatmodel.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/how/tunnelrouting.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/docs/techintro.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/pages/site/index.html (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/favicon.ico (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/I2PTunnel-streamr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/add-key-terminal.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ar.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/bandwidth2009.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/btn_left.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/btn_right.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/btn_stretch.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/cs.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/cz.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/dark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/darkbluebg.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/darkbluetile.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/darkerbluetile.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/de.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/dots.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/download.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/download_dark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/endToEndEncryption.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/endToEndEncryption_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/endToEndEncryption_zh.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/es.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/eu.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/firefox.options.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/firefox.options_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/firefox.proxyports.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/firefox.proxyports_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/garliccloves.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/help.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/help_dark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/i2plogo.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/i2ptunnel_peertopeer.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/i2ptunnel_serverclient.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/i2pvstor_zh.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ie.options.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ie.options_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ie.proxyports.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ie.proxyports_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/info.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/info_dark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/it.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/itoopie.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/konqueror.options.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/konqueror.options_fr.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/konqueror.proxyports.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/konqueror.proxyports_fr.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/lang_ar.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/light.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/lightbluetile.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/link.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/link_dark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/logo07c.jpg (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/logo_medium.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/net.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/net_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_leaseset.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_leaseset_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_routerinfo_1.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_routerinfo_1_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_routerinfo_2.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/netdb_get_routerinfo_2_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/nl.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/plan.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/protocol_stack.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/protocol_stack_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/ru.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/sqbullet.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/stackoverflow_ad.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/sv.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tabletile.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tabletile_alt.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tabletitledark.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tabletitlelight-tall.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tabletitlelight.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/target.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tunnelSending.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tunnels.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/tunnels_fr.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/udp.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/us.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/images/zh.png (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/news/news.xml (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/I2CP_spec.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/I2NP_spec.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/I2P-PET-CON-2009.1.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/datastructures.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/i2p_philosophy.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/pdf/polling_http_transport.pdf (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/dark.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/default.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/duck.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/light.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/light_ar.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/light_zh.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/mainmenu.css (100%)
 rename {www.i2p2/i2p2www => i2p2www}/static/styles/reset.css (100%)
 rename www.i2p2/runserver.py => runserver.py (100%)

diff --git a/www.i2p2/i2p2www/__init__.py b/i2p2www/__init__.py
similarity index 100%
rename from www.i2p2/i2p2www/__init__.py
rename to i2p2www/__init__.py
diff --git a/www.i2p2/i2p2www/blog/2006/10/10/status.html b/i2p2www/blog/2006/10/10/status.html
similarity index 100%
rename from www.i2p2/i2p2www/blog/2006/10/10/status.html
rename to i2p2www/blog/2006/10/10/status.html
diff --git a/www.i2p2/i2p2www/blog/2006/10/10/status.rst b/i2p2www/blog/2006/10/10/status.rst
similarity index 100%
rename from www.i2p2/i2p2www/blog/2006/10/10/status.rst
rename to i2p2www/blog/2006/10/10/status.rst
diff --git a/www.i2p2/i2p2www/meetings/208.log b/i2p2www/meetings/208.log
similarity index 100%
rename from www.i2p2/i2p2www/meetings/208.log
rename to i2p2www/meetings/208.log
diff --git a/www.i2p2/i2p2www/pages/blog/index.html b/i2p2www/pages/blog/index.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/blog/index.html
rename to i2p2www/pages/blog/index.html
diff --git a/www.i2p2/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/downloads/list.html
rename to i2p2www/pages/downloads/list.html
diff --git a/www.i2p2/i2p2www/pages/global/error_404.html b/i2p2www/pages/global/error_404.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/error_404.html
rename to i2p2www/pages/global/error_404.html
diff --git a/www.i2p2/i2p2www/pages/global/error_500.html b/i2p2www/pages/global/error_500.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/error_500.html
rename to i2p2www/pages/global/error_500.html
diff --git a/www.i2p2/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/footer.html
rename to i2p2www/pages/global/footer.html
diff --git a/www.i2p2/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/lang.html
rename to i2p2www/pages/global/lang.html
diff --git a/www.i2p2/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/layout.html
rename to i2p2www/pages/global/layout.html
diff --git a/www.i2p2/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/nav.html
rename to i2p2www/pages/global/nav.html
diff --git a/www.i2p2/i2p2www/pages/global/urlify b/i2p2www/pages/global/urlify
similarity index 100%
rename from www.i2p2/i2p2www/pages/global/urlify
rename to i2p2www/pages/global/urlify
diff --git a/www.i2p2/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/meetings/index.html
rename to i2p2www/pages/meetings/index.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/cryptography.html b/i2p2www/pages/site/docs/how/cryptography.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
rename to i2p2www/pages/site/docs/how/cryptography.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html b/i2p2www/pages/site/docs/how/elgamalaes.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
rename to i2p2www/pages/site/docs/how/elgamalaes.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html b/i2p2www/pages/site/docs/how/garlicrouting.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
rename to i2p2www/pages/site/docs/how/garlicrouting.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/index.html b/i2p2www/pages/site/docs/how/index.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/index.html
rename to i2p2www/pages/site/docs/how/index.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/intro.html
rename to i2p2www/pages/site/docs/how/intro.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html b/i2p2www/pages/site/docs/how/networkcomparisons.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
rename to i2p2www/pages/site/docs/how/networkcomparisons.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html b/i2p2www/pages/site/docs/how/networkdatabase.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
rename to i2p2www/pages/site/docs/how/networkdatabase.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/peerselection.html b/i2p2www/pages/site/docs/how/peerselection.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
rename to i2p2www/pages/site/docs/how/peerselection.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html b/i2p2www/pages/site/docs/how/threatmodel.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
rename to i2p2www/pages/site/docs/how/threatmodel.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html b/i2p2www/pages/site/docs/how/tunnelrouting.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
rename to i2p2www/pages/site/docs/how/tunnelrouting.html
diff --git a/www.i2p2/i2p2www/pages/site/docs/techintro.html b/i2p2www/pages/site/docs/techintro.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/docs/techintro.html
rename to i2p2www/pages/site/docs/techintro.html
diff --git a/www.i2p2/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html
similarity index 100%
rename from www.i2p2/i2p2www/pages/site/index.html
rename to i2p2www/pages/site/index.html
diff --git a/www.i2p2/i2p2www/static/favicon.ico b/i2p2www/static/favicon.ico
similarity index 100%
rename from www.i2p2/i2p2www/static/favicon.ico
rename to i2p2www/static/favicon.ico
diff --git a/www.i2p2/i2p2www/static/images/I2PTunnel-streamr.png b/i2p2www/static/images/I2PTunnel-streamr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/I2PTunnel-streamr.png
rename to i2p2www/static/images/I2PTunnel-streamr.png
diff --git a/www.i2p2/i2p2www/static/images/add-key-terminal.png b/i2p2www/static/images/add-key-terminal.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/add-key-terminal.png
rename to i2p2www/static/images/add-key-terminal.png
diff --git a/www.i2p2/i2p2www/static/images/ar.png b/i2p2www/static/images/ar.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ar.png
rename to i2p2www/static/images/ar.png
diff --git a/www.i2p2/i2p2www/static/images/bandwidth2009.png b/i2p2www/static/images/bandwidth2009.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/bandwidth2009.png
rename to i2p2www/static/images/bandwidth2009.png
diff --git a/www.i2p2/i2p2www/static/images/btn_left.png b/i2p2www/static/images/btn_left.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/btn_left.png
rename to i2p2www/static/images/btn_left.png
diff --git a/www.i2p2/i2p2www/static/images/btn_right.png b/i2p2www/static/images/btn_right.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/btn_right.png
rename to i2p2www/static/images/btn_right.png
diff --git a/www.i2p2/i2p2www/static/images/btn_stretch.png b/i2p2www/static/images/btn_stretch.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/btn_stretch.png
rename to i2p2www/static/images/btn_stretch.png
diff --git a/www.i2p2/i2p2www/static/images/cs.png b/i2p2www/static/images/cs.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/cs.png
rename to i2p2www/static/images/cs.png
diff --git a/www.i2p2/i2p2www/static/images/cz.png b/i2p2www/static/images/cz.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/cz.png
rename to i2p2www/static/images/cz.png
diff --git a/www.i2p2/i2p2www/static/images/dark.png b/i2p2www/static/images/dark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/dark.png
rename to i2p2www/static/images/dark.png
diff --git a/www.i2p2/i2p2www/static/images/darkbluebg.png b/i2p2www/static/images/darkbluebg.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/darkbluebg.png
rename to i2p2www/static/images/darkbluebg.png
diff --git a/www.i2p2/i2p2www/static/images/darkbluetile.png b/i2p2www/static/images/darkbluetile.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/darkbluetile.png
rename to i2p2www/static/images/darkbluetile.png
diff --git a/www.i2p2/i2p2www/static/images/darkerbluetile.png b/i2p2www/static/images/darkerbluetile.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/darkerbluetile.png
rename to i2p2www/static/images/darkerbluetile.png
diff --git a/www.i2p2/i2p2www/static/images/de.png b/i2p2www/static/images/de.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/de.png
rename to i2p2www/static/images/de.png
diff --git a/www.i2p2/i2p2www/static/images/dots.png b/i2p2www/static/images/dots.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/dots.png
rename to i2p2www/static/images/dots.png
diff --git a/www.i2p2/i2p2www/static/images/download.png b/i2p2www/static/images/download.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/download.png
rename to i2p2www/static/images/download.png
diff --git a/www.i2p2/i2p2www/static/images/download_dark.png b/i2p2www/static/images/download_dark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/download_dark.png
rename to i2p2www/static/images/download_dark.png
diff --git a/www.i2p2/i2p2www/static/images/endToEndEncryption.png b/i2p2www/static/images/endToEndEncryption.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/endToEndEncryption.png
rename to i2p2www/static/images/endToEndEncryption.png
diff --git a/www.i2p2/i2p2www/static/images/endToEndEncryption_fr.png b/i2p2www/static/images/endToEndEncryption_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/endToEndEncryption_fr.png
rename to i2p2www/static/images/endToEndEncryption_fr.png
diff --git a/www.i2p2/i2p2www/static/images/endToEndEncryption_zh.png b/i2p2www/static/images/endToEndEncryption_zh.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/endToEndEncryption_zh.png
rename to i2p2www/static/images/endToEndEncryption_zh.png
diff --git a/www.i2p2/i2p2www/static/images/es.png b/i2p2www/static/images/es.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/es.png
rename to i2p2www/static/images/es.png
diff --git a/www.i2p2/i2p2www/static/images/eu.png b/i2p2www/static/images/eu.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/eu.png
rename to i2p2www/static/images/eu.png
diff --git a/www.i2p2/i2p2www/static/images/firefox.options.jpg b/i2p2www/static/images/firefox.options.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/firefox.options.jpg
rename to i2p2www/static/images/firefox.options.jpg
diff --git a/www.i2p2/i2p2www/static/images/firefox.options_fr.png b/i2p2www/static/images/firefox.options_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/firefox.options_fr.png
rename to i2p2www/static/images/firefox.options_fr.png
diff --git a/www.i2p2/i2p2www/static/images/firefox.proxyports.jpg b/i2p2www/static/images/firefox.proxyports.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/firefox.proxyports.jpg
rename to i2p2www/static/images/firefox.proxyports.jpg
diff --git a/www.i2p2/i2p2www/static/images/firefox.proxyports_fr.png b/i2p2www/static/images/firefox.proxyports_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/firefox.proxyports_fr.png
rename to i2p2www/static/images/firefox.proxyports_fr.png
diff --git a/www.i2p2/i2p2www/static/images/fr.png b/i2p2www/static/images/fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/fr.png
rename to i2p2www/static/images/fr.png
diff --git a/www.i2p2/i2p2www/static/images/garliccloves.png b/i2p2www/static/images/garliccloves.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/garliccloves.png
rename to i2p2www/static/images/garliccloves.png
diff --git a/www.i2p2/i2p2www/static/images/help.png b/i2p2www/static/images/help.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/help.png
rename to i2p2www/static/images/help.png
diff --git a/www.i2p2/i2p2www/static/images/help_dark.png b/i2p2www/static/images/help_dark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/help_dark.png
rename to i2p2www/static/images/help_dark.png
diff --git a/www.i2p2/i2p2www/static/images/i2plogo.png b/i2p2www/static/images/i2plogo.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/i2plogo.png
rename to i2p2www/static/images/i2plogo.png
diff --git a/www.i2p2/i2p2www/static/images/i2ptunnel_peertopeer.png b/i2p2www/static/images/i2ptunnel_peertopeer.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/i2ptunnel_peertopeer.png
rename to i2p2www/static/images/i2ptunnel_peertopeer.png
diff --git a/www.i2p2/i2p2www/static/images/i2ptunnel_serverclient.png b/i2p2www/static/images/i2ptunnel_serverclient.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/i2ptunnel_serverclient.png
rename to i2p2www/static/images/i2ptunnel_serverclient.png
diff --git a/www.i2p2/i2p2www/static/images/i2pvstor_zh.png b/i2p2www/static/images/i2pvstor_zh.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/i2pvstor_zh.png
rename to i2p2www/static/images/i2pvstor_zh.png
diff --git a/www.i2p2/i2p2www/static/images/ie.options.jpg b/i2p2www/static/images/ie.options.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ie.options.jpg
rename to i2p2www/static/images/ie.options.jpg
diff --git a/www.i2p2/i2p2www/static/images/ie.options_fr.png b/i2p2www/static/images/ie.options_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ie.options_fr.png
rename to i2p2www/static/images/ie.options_fr.png
diff --git a/www.i2p2/i2p2www/static/images/ie.proxyports.jpg b/i2p2www/static/images/ie.proxyports.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ie.proxyports.jpg
rename to i2p2www/static/images/ie.proxyports.jpg
diff --git a/www.i2p2/i2p2www/static/images/ie.proxyports_fr.png b/i2p2www/static/images/ie.proxyports_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ie.proxyports_fr.png
rename to i2p2www/static/images/ie.proxyports_fr.png
diff --git a/www.i2p2/i2p2www/static/images/info.png b/i2p2www/static/images/info.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/info.png
rename to i2p2www/static/images/info.png
diff --git a/www.i2p2/i2p2www/static/images/info_dark.png b/i2p2www/static/images/info_dark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/info_dark.png
rename to i2p2www/static/images/info_dark.png
diff --git a/www.i2p2/i2p2www/static/images/it.png b/i2p2www/static/images/it.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/it.png
rename to i2p2www/static/images/it.png
diff --git a/www.i2p2/i2p2www/static/images/itoopie.png b/i2p2www/static/images/itoopie.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/itoopie.png
rename to i2p2www/static/images/itoopie.png
diff --git a/www.i2p2/i2p2www/static/images/konqueror.options.jpg b/i2p2www/static/images/konqueror.options.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/konqueror.options.jpg
rename to i2p2www/static/images/konqueror.options.jpg
diff --git a/www.i2p2/i2p2www/static/images/konqueror.options_fr.jpg b/i2p2www/static/images/konqueror.options_fr.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/konqueror.options_fr.jpg
rename to i2p2www/static/images/konqueror.options_fr.jpg
diff --git a/www.i2p2/i2p2www/static/images/konqueror.proxyports.jpg b/i2p2www/static/images/konqueror.proxyports.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/konqueror.proxyports.jpg
rename to i2p2www/static/images/konqueror.proxyports.jpg
diff --git a/www.i2p2/i2p2www/static/images/konqueror.proxyports_fr.jpg b/i2p2www/static/images/konqueror.proxyports_fr.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/konqueror.proxyports_fr.jpg
rename to i2p2www/static/images/konqueror.proxyports_fr.jpg
diff --git a/www.i2p2/i2p2www/static/images/lang_ar.png b/i2p2www/static/images/lang_ar.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/lang_ar.png
rename to i2p2www/static/images/lang_ar.png
diff --git a/www.i2p2/i2p2www/static/images/light.png b/i2p2www/static/images/light.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/light.png
rename to i2p2www/static/images/light.png
diff --git a/www.i2p2/i2p2www/static/images/lightbluetile.png b/i2p2www/static/images/lightbluetile.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/lightbluetile.png
rename to i2p2www/static/images/lightbluetile.png
diff --git a/www.i2p2/i2p2www/static/images/link.png b/i2p2www/static/images/link.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/link.png
rename to i2p2www/static/images/link.png
diff --git a/www.i2p2/i2p2www/static/images/link_dark.png b/i2p2www/static/images/link_dark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/link_dark.png
rename to i2p2www/static/images/link_dark.png
diff --git a/www.i2p2/i2p2www/static/images/logo07c.jpg b/i2p2www/static/images/logo07c.jpg
similarity index 100%
rename from www.i2p2/i2p2www/static/images/logo07c.jpg
rename to i2p2www/static/images/logo07c.jpg
diff --git a/www.i2p2/i2p2www/static/images/logo_medium.png b/i2p2www/static/images/logo_medium.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/logo_medium.png
rename to i2p2www/static/images/logo_medium.png
diff --git a/www.i2p2/i2p2www/static/images/net.png b/i2p2www/static/images/net.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/net.png
rename to i2p2www/static/images/net.png
diff --git a/www.i2p2/i2p2www/static/images/net_fr.png b/i2p2www/static/images/net_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/net_fr.png
rename to i2p2www/static/images/net_fr.png
diff --git a/www.i2p2/i2p2www/static/images/netdb_get_leaseset.png b/i2p2www/static/images/netdb_get_leaseset.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/netdb_get_leaseset.png
rename to i2p2www/static/images/netdb_get_leaseset.png
diff --git a/www.i2p2/i2p2www/static/images/netdb_get_leaseset_fr.png b/i2p2www/static/images/netdb_get_leaseset_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/netdb_get_leaseset_fr.png
rename to i2p2www/static/images/netdb_get_leaseset_fr.png
diff --git a/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1.png b/i2p2www/static/images/netdb_get_routerinfo_1.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/netdb_get_routerinfo_1.png
rename to i2p2www/static/images/netdb_get_routerinfo_1.png
diff --git a/www.i2p2/i2p2www/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/i2p2www/static/images/netdb_get_routerinfo_1_fr.png
rename to i2p2www/static/images/netdb_get_routerinfo_1_fr.png
diff --git a/www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2.png b/i2p2www/static/images/netdb_get_routerinfo_2.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/netdb_get_routerinfo_2.png
rename to i2p2www/static/images/netdb_get_routerinfo_2.png
diff --git a/www.i2p2/i2p2www/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/i2p2www/static/images/netdb_get_routerinfo_2_fr.png
rename to i2p2www/static/images/netdb_get_routerinfo_2_fr.png
diff --git a/www.i2p2/i2p2www/static/images/nl.png b/i2p2www/static/images/nl.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/nl.png
rename to i2p2www/static/images/nl.png
diff --git a/www.i2p2/i2p2www/static/images/plan.png b/i2p2www/static/images/plan.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/plan.png
rename to i2p2www/static/images/plan.png
diff --git a/www.i2p2/i2p2www/static/images/protocol_stack.png b/i2p2www/static/images/protocol_stack.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/protocol_stack.png
rename to i2p2www/static/images/protocol_stack.png
diff --git a/www.i2p2/i2p2www/static/images/protocol_stack_fr.png b/i2p2www/static/images/protocol_stack_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/protocol_stack_fr.png
rename to i2p2www/static/images/protocol_stack_fr.png
diff --git a/www.i2p2/i2p2www/static/images/ru.png b/i2p2www/static/images/ru.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/ru.png
rename to i2p2www/static/images/ru.png
diff --git a/www.i2p2/i2p2www/static/images/sqbullet.png b/i2p2www/static/images/sqbullet.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/sqbullet.png
rename to i2p2www/static/images/sqbullet.png
diff --git a/www.i2p2/i2p2www/static/images/stackoverflow_ad.png b/i2p2www/static/images/stackoverflow_ad.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/stackoverflow_ad.png
rename to i2p2www/static/images/stackoverflow_ad.png
diff --git a/www.i2p2/i2p2www/static/images/sv.png b/i2p2www/static/images/sv.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/sv.png
rename to i2p2www/static/images/sv.png
diff --git a/www.i2p2/i2p2www/static/images/tabletile.png b/i2p2www/static/images/tabletile.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tabletile.png
rename to i2p2www/static/images/tabletile.png
diff --git a/www.i2p2/i2p2www/static/images/tabletile_alt.png b/i2p2www/static/images/tabletile_alt.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tabletile_alt.png
rename to i2p2www/static/images/tabletile_alt.png
diff --git a/www.i2p2/i2p2www/static/images/tabletitledark.png b/i2p2www/static/images/tabletitledark.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tabletitledark.png
rename to i2p2www/static/images/tabletitledark.png
diff --git a/www.i2p2/i2p2www/static/images/tabletitlelight-tall.png b/i2p2www/static/images/tabletitlelight-tall.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tabletitlelight-tall.png
rename to i2p2www/static/images/tabletitlelight-tall.png
diff --git a/www.i2p2/i2p2www/static/images/tabletitlelight.png b/i2p2www/static/images/tabletitlelight.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tabletitlelight.png
rename to i2p2www/static/images/tabletitlelight.png
diff --git a/www.i2p2/i2p2www/static/images/target.png b/i2p2www/static/images/target.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/target.png
rename to i2p2www/static/images/target.png
diff --git a/www.i2p2/i2p2www/static/images/tunnelSending.png b/i2p2www/static/images/tunnelSending.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tunnelSending.png
rename to i2p2www/static/images/tunnelSending.png
diff --git a/www.i2p2/i2p2www/static/images/tunnels.png b/i2p2www/static/images/tunnels.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tunnels.png
rename to i2p2www/static/images/tunnels.png
diff --git a/www.i2p2/i2p2www/static/images/tunnels_fr.png b/i2p2www/static/images/tunnels_fr.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/tunnels_fr.png
rename to i2p2www/static/images/tunnels_fr.png
diff --git a/www.i2p2/i2p2www/static/images/udp.png b/i2p2www/static/images/udp.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/udp.png
rename to i2p2www/static/images/udp.png
diff --git a/www.i2p2/i2p2www/static/images/us.png b/i2p2www/static/images/us.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/us.png
rename to i2p2www/static/images/us.png
diff --git a/www.i2p2/i2p2www/static/images/zh.png b/i2p2www/static/images/zh.png
similarity index 100%
rename from www.i2p2/i2p2www/static/images/zh.png
rename to i2p2www/static/images/zh.png
diff --git a/www.i2p2/i2p2www/static/news/news.xml b/i2p2www/static/news/news.xml
similarity index 100%
rename from www.i2p2/i2p2www/static/news/news.xml
rename to i2p2www/static/news/news.xml
diff --git a/www.i2p2/i2p2www/static/pdf/I2CP_spec.pdf b/i2p2www/static/pdf/I2CP_spec.pdf
similarity index 100%
rename from www.i2p2/i2p2www/static/pdf/I2CP_spec.pdf
rename to i2p2www/static/pdf/I2CP_spec.pdf
diff --git a/www.i2p2/i2p2www/static/pdf/I2NP_spec.pdf b/i2p2www/static/pdf/I2NP_spec.pdf
similarity index 100%
rename from www.i2p2/i2p2www/static/pdf/I2NP_spec.pdf
rename to i2p2www/static/pdf/I2NP_spec.pdf
diff --git a/www.i2p2/i2p2www/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/i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
rename to i2p2www/static/pdf/I2P-PET-CON-2009.1.pdf
diff --git a/www.i2p2/i2p2www/static/pdf/datastructures.pdf b/i2p2www/static/pdf/datastructures.pdf
similarity index 100%
rename from www.i2p2/i2p2www/static/pdf/datastructures.pdf
rename to i2p2www/static/pdf/datastructures.pdf
diff --git a/www.i2p2/i2p2www/static/pdf/i2p_philosophy.pdf b/i2p2www/static/pdf/i2p_philosophy.pdf
similarity index 100%
rename from www.i2p2/i2p2www/static/pdf/i2p_philosophy.pdf
rename to i2p2www/static/pdf/i2p_philosophy.pdf
diff --git a/www.i2p2/i2p2www/static/pdf/polling_http_transport.pdf b/i2p2www/static/pdf/polling_http_transport.pdf
similarity index 100%
rename from www.i2p2/i2p2www/static/pdf/polling_http_transport.pdf
rename to i2p2www/static/pdf/polling_http_transport.pdf
diff --git a/www.i2p2/i2p2www/static/styles/dark.css b/i2p2www/static/styles/dark.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/dark.css
rename to i2p2www/static/styles/dark.css
diff --git a/www.i2p2/i2p2www/static/styles/default.css b/i2p2www/static/styles/default.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/default.css
rename to i2p2www/static/styles/default.css
diff --git a/www.i2p2/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/duck.css
rename to i2p2www/static/styles/duck.css
diff --git a/www.i2p2/i2p2www/static/styles/light.css b/i2p2www/static/styles/light.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/light.css
rename to i2p2www/static/styles/light.css
diff --git a/www.i2p2/i2p2www/static/styles/light_ar.css b/i2p2www/static/styles/light_ar.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/light_ar.css
rename to i2p2www/static/styles/light_ar.css
diff --git a/www.i2p2/i2p2www/static/styles/light_zh.css b/i2p2www/static/styles/light_zh.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/light_zh.css
rename to i2p2www/static/styles/light_zh.css
diff --git a/www.i2p2/i2p2www/static/styles/mainmenu.css b/i2p2www/static/styles/mainmenu.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/mainmenu.css
rename to i2p2www/static/styles/mainmenu.css
diff --git a/www.i2p2/i2p2www/static/styles/reset.css b/i2p2www/static/styles/reset.css
similarity index 100%
rename from www.i2p2/i2p2www/static/styles/reset.css
rename to i2p2www/static/styles/reset.css
diff --git a/www.i2p2/runserver.py b/runserver.py
similarity index 100%
rename from www.i2p2/runserver.py
rename to runserver.py

From 5aff8d2d9a9e9cf5a2a2270c3c98b8d40ec02063 Mon Sep 17 00:00:00 2001
From: dev 
Date: Wed, 12 Sep 2012 22:30:18 +0000
Subject: [PATCH 30/75] add example meeting..

---
 meetings/208.rst | 41 +++++++++++++++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 meetings/208.rst

diff --git a/meetings/208.rst b/meetings/208.rst
new file mode 100644
index 00000000..9543338a
--- /dev/null
+++ b/meetings/208.rst
@@ -0,0 +1,41 @@
+I2P dev meeting, September 8, 2010
+==================================
+
+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.
+
+Full IRC Log
+------------

From 135ce35ac6e251ec638cf73272fd3745e8d3f10d Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 22:40:45 +0000
Subject: [PATCH 31/75] Beginning of migration of meeting logs

---
 i2p2www/meetings/1.log                        |  704 ++++++++++
 i2p2www/meetings/10.log                       |  171 +++
 i2p2www/meetings/100.log                      |  195 +++
 i2p2www/meetings/101.log                      |  221 ++++
 i2p2www/meetings/102.log                      |  120 ++
 i2p2www/meetings/103.log                      |  217 ++++
 i2p2www/meetings/104.log                      |  422 ++++++
 i2p2www/meetings/105.log                      |  225 ++++
 i2p2www/meetings/106.log                      |  476 +++++++
 i2p2www/meetings/107.log                      |  500 ++++++++
 i2p2www/meetings/108.log                      |   40 +
 i2p2www/meetings/109.log                      |  119 ++
 i2p2www/meetings/11.log                       |  161 +++
 i2p2www/meetings/110.log                      |  186 +++
 i2p2www/meetings/111.log                      |  201 +++
 i2p2www/meetings/112.log                      |  272 ++++
 i2p2www/meetings/113.log                      |  273 ++++
 i2p2www/meetings/114.log                      |  404 ++++++
 i2p2www/meetings/115.log                      |  523 ++++++++
 i2p2www/meetings/116.log                      |  183 +++
 i2p2www/meetings/117.log                      |   70 +
 i2p2www/meetings/118.log                      |  324 +++++
 i2p2www/meetings/119.log                      |  174 +++
 i2p2www/meetings/12.log                       |  619 +++++++++
 i2p2www/meetings/120.log                      |  490 +++++++
 i2p2www/meetings/121.log                      |  329 +++++
 i2p2www/meetings/122.log                      |  201 +++
 i2p2www/meetings/123.log                      |  160 +++
 i2p2www/meetings/124.log                      |  384 ++++++
 i2p2www/meetings/125.log                      |  284 +++++
 i2p2www/meetings/126.log                      |  178 +++
 i2p2www/meetings/127.log                      |  159 +++
 i2p2www/meetings/128.log                      |  291 +++++
 i2p2www/meetings/129.log                      |  253 ++++
 i2p2www/meetings/130.log                      |  288 +++++
 i2p2www/meetings/131.log                      |  372 ++++++
 i2p2www/meetings/132.log                      |  365 ++++++
 i2p2www/meetings/133.log                      |  323 +++++
 i2p2www/meetings/134.log                      |  177 +++
 i2p2www/meetings/135.log                      |  125 ++
 i2p2www/meetings/136.log                      |  103 ++
 i2p2www/meetings/137.log                      |  286 +++++
 i2p2www/meetings/138.log                      |  106 ++
 i2p2www/meetings/139.log                      |   64 +
 i2p2www/meetings/140.log                      |  199 +++
 i2p2www/meetings/141.log                      |  135 ++
 i2p2www/meetings/142.log                      |   94 ++
 i2p2www/meetings/143.log                      |   56 +
 i2p2www/meetings/144.log                      |  149 +++
 i2p2www/meetings/145.log                      |  134 ++
 i2p2www/meetings/146.log                      |  218 ++++
 i2p2www/meetings/147.log                      |   47 +
 i2p2www/meetings/148.log                      |  103 ++
 i2p2www/meetings/149.log                      |  258 ++++
 i2p2www/meetings/15.log                       |  526 ++++++++
 i2p2www/meetings/150.log                      |  148 +++
 i2p2www/meetings/151.log                      |  240 ++++
 i2p2www/meetings/152.log                      |  276 ++++
 i2p2www/meetings/153.log                      |  446 +++++++
 i2p2www/meetings/154.log                      |  182 +++
 i2p2www/meetings/155.log                      |   66 +
 i2p2www/meetings/156.log                      |  351 +++++
 i2p2www/meetings/157.log                      |  144 +++
 i2p2www/meetings/158.log                      |  228 ++++
 i2p2www/meetings/159.log                      |  266 ++++
 i2p2www/meetings/160.log                      |   55 +
 i2p2www/meetings/161.log                      |  122 ++
 i2p2www/meetings/162.log                      |   93 ++
 i2p2www/meetings/163.log                      |  176 +++
 i2p2www/meetings/164.log                      |  267 ++++
 i2p2www/meetings/165.log                      |  114 ++
 i2p2www/meetings/166.log                      |  142 +++
 i2p2www/meetings/167.log                      |  151 +++
 i2p2www/meetings/168.log                      |   74 ++
 i2p2www/meetings/170.log                      |  122 ++
 i2p2www/meetings/171.log                      |   78 ++
 i2p2www/meetings/172.log                      |   65 +
 i2p2www/meetings/173.log                      |  122 ++
 i2p2www/meetings/174.log                      |   78 ++
 i2p2www/meetings/175.log                      |  132 ++
 i2p2www/meetings/176.log                      |  180 +++
 i2p2www/meetings/177.log                      |  154 +++
 i2p2www/meetings/178.log                      |   41 +
 i2p2www/meetings/179.log                      |   67 +
 i2p2www/meetings/18.log                       |  179 +++
 i2p2www/meetings/180.log                      |   83 ++
 i2p2www/meetings/181.log                      |   58 +
 i2p2www/meetings/182.log                      |   63 +
 i2p2www/meetings/183.log                      |  191 +++
 i2p2www/meetings/184.log                      |  268 ++++
 i2p2www/meetings/185.log                      |   85 ++
 i2p2www/meetings/186.log                      |  103 ++
 i2p2www/meetings/187.log                      |   76 ++
 i2p2www/meetings/188.log                      |   93 ++
 i2p2www/meetings/189.log                      |   96 ++
 i2p2www/meetings/190.log                      |  120 ++
 i2p2www/meetings/191.log                      |   58 +
 i2p2www/meetings/192.log                      |   58 +
 i2p2www/meetings/193.log                      |   26 +
 i2p2www/meetings/194.log                      |  160 +++
 i2p2www/meetings/195.log                      |   78 ++
 i2p2www/meetings/196.log                      |  117 ++
 i2p2www/meetings/197.log                      |   39 +
 i2p2www/meetings/198.log                      |   63 +
 i2p2www/meetings/199.log                      |  241 ++++
 i2p2www/meetings/2.log                        | 1134 +++++++++++++++++
 i2p2www/meetings/20.log                       |  413 ++++++
 i2p2www/meetings/200.log                      |   79 ++
 i2p2www/meetings/201.log                      |   40 +
 i2p2www/meetings/202.log                      |   87 ++
 i2p2www/meetings/203.log                      |  111 ++
 i2p2www/meetings/204.log                      |   81 ++
 i2p2www/meetings/205.log                      |   88 ++
 i2p2www/meetings/206.log                      |   45 +
 .../meetings/207.log                          |    0
 i2p2www/meetings/21.log                       |  691 ++++++++++
 i2p2www/meetings/22.log                       |  153 +++
 i2p2www/meetings/23.log                       |  340 +++++
 i2p2www/meetings/25.log                       |  150 +++
 i2p2www/meetings/26.log                       |  269 ++++
 i2p2www/meetings/28.log                       |  149 +++
 i2p2www/meetings/29.log                       |  205 +++
 i2p2www/meetings/3.log                        |  618 +++++++++
 i2p2www/meetings/30.log                       |  457 +++++++
 i2p2www/meetings/31.log                       |  446 +++++++
 i2p2www/meetings/32.log                       |  307 +++++
 i2p2www/meetings/33.log                       |  426 +++++++
 i2p2www/meetings/34.log                       |  136 ++
 i2p2www/meetings/35.log                       |  208 +++
 i2p2www/meetings/4.log                        |  428 +++++++
 i2p2www/meetings/47.log                       |  912 +++++++++++++
 i2p2www/meetings/49.log                       |  746 +++++++++++
 i2p2www/meetings/50.log                       |  597 +++++++++
 i2p2www/meetings/51.log                       |  886 +++++++++++++
 i2p2www/meetings/52.log                       |  381 ++++++
 i2p2www/meetings/53.log                       |  113 ++
 i2p2www/meetings/54.log                       |  441 +++++++
 i2p2www/meetings/55.log                       |  214 ++++
 i2p2www/meetings/56.log                       |  215 ++++
 i2p2www/meetings/57.log                       |  170 +++
 i2p2www/meetings/58.log                       |  314 +++++
 i2p2www/meetings/59.log                       |  734 +++++++++++
 i2p2www/meetings/60.log                       |  279 ++++
 i2p2www/meetings/61.log                       |   82 ++
 i2p2www/meetings/62.log                       |  288 +++++
 i2p2www/meetings/63.log                       |  183 +++
 i2p2www/meetings/64.log                       |  196 +++
 i2p2www/meetings/65.log                       |  623 +++++++++
 i2p2www/meetings/66.log                       |  477 +++++++
 i2p2www/meetings/68.log                       |  281 ++++
 i2p2www/meetings/69.log                       |  250 ++++
 i2p2www/meetings/7.log                        |  458 +++++++
 i2p2www/meetings/70.log                       |  164 +++
 i2p2www/meetings/71.log                       |  336 +++++
 i2p2www/meetings/72.log                       |  659 ++++++++++
 i2p2www/meetings/73.log                       |  143 +++
 i2p2www/meetings/74.log                       |  190 +++
 i2p2www/meetings/75.log                       |  104 ++
 i2p2www/meetings/76.log                       |  520 ++++++++
 i2p2www/meetings/77.log                       |  502 ++++++++
 i2p2www/meetings/78.log                       |  290 +++++
 i2p2www/meetings/79.log                       |  187 +++
 i2p2www/meetings/8.log                        |  149 +++
 i2p2www/meetings/80.log                       |  358 ++++++
 i2p2www/meetings/81.log                       |  405 ++++++
 i2p2www/meetings/82.log                       |  470 +++++++
 i2p2www/meetings/9.log                        |   98 ++
 i2p2www/meetings/90.log                       |  203 +++
 i2p2www/meetings/92.log                       |  341 +++++
 i2p2www/meetings/93.log                       |  280 ++++
 i2p2www/meetings/95.log                       |  287 +++++
 i2p2www/meetings/99.log                       |  203 +++
 www.i2p2/pages/meeting1.html                  |  704 ----------
 www.i2p2/pages/meeting10.html                 |  171 ---
 www.i2p2/pages/meeting100.html                |  195 ---
 www.i2p2/pages/meeting101.html                |  221 ----
 www.i2p2/pages/meeting102.html                |  120 --
 www.i2p2/pages/meeting103.html                |  217 ----
 www.i2p2/pages/meeting104.html                |  422 ------
 www.i2p2/pages/meeting105.html                |  225 ----
 www.i2p2/pages/meeting106.html                |  476 -------
 www.i2p2/pages/meeting107.html                |  500 --------
 www.i2p2/pages/meeting108.html                |   40 -
 www.i2p2/pages/meeting109.html                |  119 --
 www.i2p2/pages/meeting11.html                 |  161 ---
 www.i2p2/pages/meeting110.html                |  186 ---
 www.i2p2/pages/meeting111.html                |  201 ---
 www.i2p2/pages/meeting112.html                |  272 ----
 www.i2p2/pages/meeting113.html                |  273 ----
 www.i2p2/pages/meeting114.html                |  404 ------
 www.i2p2/pages/meeting115.html                |  523 --------
 www.i2p2/pages/meeting116.html                |  183 ---
 www.i2p2/pages/meeting117.html                |   70 -
 www.i2p2/pages/meeting118.html                |  324 -----
 www.i2p2/pages/meeting119.html                |  174 ---
 www.i2p2/pages/meeting12.html                 |  619 ---------
 www.i2p2/pages/meeting120.html                |  490 -------
 www.i2p2/pages/meeting121.html                |  329 -----
 www.i2p2/pages/meeting122.html                |  201 ---
 www.i2p2/pages/meeting123.html                |  160 ---
 www.i2p2/pages/meeting124.html                |  384 ------
 www.i2p2/pages/meeting125.html                |  284 -----
 www.i2p2/pages/meeting126.html                |  178 ---
 www.i2p2/pages/meeting127.html                |  159 ---
 www.i2p2/pages/meeting128.html                |  291 -----
 www.i2p2/pages/meeting129.html                |  253 ----
 www.i2p2/pages/meeting130.html                |  288 -----
 www.i2p2/pages/meeting131.html                |  372 ------
 www.i2p2/pages/meeting132.html                |  365 ------
 www.i2p2/pages/meeting133.html                |  323 -----
 www.i2p2/pages/meeting134.html                |  177 ---
 www.i2p2/pages/meeting135.html                |  125 --
 www.i2p2/pages/meeting136.html                |  103 --
 www.i2p2/pages/meeting137.html                |  286 -----
 www.i2p2/pages/meeting138.html                |  106 --
 www.i2p2/pages/meeting139.html                |   64 -
 www.i2p2/pages/meeting140.html                |  199 ---
 www.i2p2/pages/meeting141.html                |  135 --
 www.i2p2/pages/meeting142.html                |   94 --
 www.i2p2/pages/meeting143.html                |   56 -
 www.i2p2/pages/meeting144.html                |  149 ---
 www.i2p2/pages/meeting145.html                |  134 --
 www.i2p2/pages/meeting146.html                |  218 ----
 www.i2p2/pages/meeting147.html                |   47 -
 www.i2p2/pages/meeting148.html                |  103 --
 www.i2p2/pages/meeting149.html                |  258 ----
 www.i2p2/pages/meeting15.html                 |  526 --------
 www.i2p2/pages/meeting150.html                |  148 ---
 www.i2p2/pages/meeting151.html                |  240 ----
 www.i2p2/pages/meeting152.html                |  276 ----
 www.i2p2/pages/meeting153.html                |  446 -------
 www.i2p2/pages/meeting154.html                |  182 ---
 www.i2p2/pages/meeting155.html                |   66 -
 www.i2p2/pages/meeting156.html                |  351 -----
 www.i2p2/pages/meeting157.html                |  144 ---
 www.i2p2/pages/meeting158.html                |  228 ----
 www.i2p2/pages/meeting159.html                |  266 ----
 www.i2p2/pages/meeting160.html                |   55 -
 www.i2p2/pages/meeting161.html                |  122 --
 www.i2p2/pages/meeting162.html                |   93 --
 www.i2p2/pages/meeting163.html                |  176 ---
 www.i2p2/pages/meeting164.html                |  267 ----
 www.i2p2/pages/meeting165.html                |  114 --
 www.i2p2/pages/meeting166.html                |  142 ---
 www.i2p2/pages/meeting167.html                |  151 ---
 www.i2p2/pages/meeting168.html                |   74 --
 www.i2p2/pages/meeting170.html                |  122 --
 www.i2p2/pages/meeting171.html                |   78 --
 www.i2p2/pages/meeting172.html                |   65 -
 www.i2p2/pages/meeting173.html                |  122 --
 www.i2p2/pages/meeting174.html                |   78 --
 www.i2p2/pages/meeting175.html                |  132 --
 www.i2p2/pages/meeting176.html                |  180 ---
 www.i2p2/pages/meeting177.html                |  154 ---
 www.i2p2/pages/meeting178.html                |   41 -
 www.i2p2/pages/meeting179.html                |   67 -
 www.i2p2/pages/meeting18.html                 |  179 ---
 www.i2p2/pages/meeting180.html                |   83 --
 www.i2p2/pages/meeting181.html                |   58 -
 www.i2p2/pages/meeting182.html                |   63 -
 www.i2p2/pages/meeting183.html                |  191 ---
 www.i2p2/pages/meeting184.html                |  268 ----
 www.i2p2/pages/meeting185.html                |   85 --
 www.i2p2/pages/meeting186.html                |  103 --
 www.i2p2/pages/meeting187.html                |   76 --
 www.i2p2/pages/meeting188.html                |   93 --
 www.i2p2/pages/meeting189.html                |   96 --
 www.i2p2/pages/meeting190.html                |  120 --
 www.i2p2/pages/meeting191.html                |   58 -
 www.i2p2/pages/meeting192.html                |   58 -
 www.i2p2/pages/meeting193.html                |   26 -
 www.i2p2/pages/meeting194.html                |  160 ---
 www.i2p2/pages/meeting195.html                |   78 --
 www.i2p2/pages/meeting196.html                |  117 --
 www.i2p2/pages/meeting197.html                |   39 -
 www.i2p2/pages/meeting198.html                |   63 -
 www.i2p2/pages/meeting199.html                |  241 ----
 www.i2p2/pages/meeting2.html                  | 1134 -----------------
 www.i2p2/pages/meeting20.html                 |  413 ------
 www.i2p2/pages/meeting200.html                |   79 --
 www.i2p2/pages/meeting201.html                |   40 -
 www.i2p2/pages/meeting202.html                |   87 --
 www.i2p2/pages/meeting203.html                |  111 --
 www.i2p2/pages/meeting204.html                |   81 --
 www.i2p2/pages/meeting205.html                |   88 --
 www.i2p2/pages/meeting206.html                |   45 -
 www.i2p2/pages/meeting21.html                 |  691 ----------
 www.i2p2/pages/meeting22.html                 |  153 ---
 www.i2p2/pages/meeting23.html                 |  340 -----
 www.i2p2/pages/meeting25.html                 |  150 ---
 www.i2p2/pages/meeting26.html                 |  269 ----
 www.i2p2/pages/meeting28.html                 |  149 ---
 www.i2p2/pages/meeting29.html                 |  205 ---
 www.i2p2/pages/meeting3.html                  |  618 ---------
 www.i2p2/pages/meeting30.html                 |  457 -------
 www.i2p2/pages/meeting31.html                 |  446 -------
 www.i2p2/pages/meeting32.html                 |  307 -----
 www.i2p2/pages/meeting33.html                 |  426 -------
 www.i2p2/pages/meeting34.html                 |  136 --
 www.i2p2/pages/meeting35.html                 |  208 ---
 www.i2p2/pages/meeting4.html                  |  428 -------
 www.i2p2/pages/meeting47.html                 |  912 -------------
 www.i2p2/pages/meeting49.html                 |  746 -----------
 www.i2p2/pages/meeting50.html                 |  597 ---------
 www.i2p2/pages/meeting51.html                 |  886 -------------
 www.i2p2/pages/meeting52.html                 |  381 ------
 www.i2p2/pages/meeting53.html                 |  113 --
 www.i2p2/pages/meeting54.html                 |  441 -------
 www.i2p2/pages/meeting55.html                 |  214 ----
 www.i2p2/pages/meeting56.html                 |  215 ----
 www.i2p2/pages/meeting57.html                 |  170 ---
 www.i2p2/pages/meeting58.html                 |  314 -----
 www.i2p2/pages/meeting59.html                 |  734 -----------
 www.i2p2/pages/meeting60.html                 |  279 ----
 www.i2p2/pages/meeting61.html                 |   82 --
 www.i2p2/pages/meeting62.html                 |  288 -----
 www.i2p2/pages/meeting63.html                 |  183 ---
 www.i2p2/pages/meeting64.html                 |  196 ---
 www.i2p2/pages/meeting65.html                 |  623 ---------
 www.i2p2/pages/meeting66.html                 |  477 -------
 www.i2p2/pages/meeting68.html                 |  281 ----
 www.i2p2/pages/meeting69.html                 |  250 ----
 www.i2p2/pages/meeting7.html                  |  458 -------
 www.i2p2/pages/meeting70.html                 |  164 ---
 www.i2p2/pages/meeting71.html                 |  336 -----
 www.i2p2/pages/meeting72.html                 |  659 ----------
 www.i2p2/pages/meeting73.html                 |  143 ---
 www.i2p2/pages/meeting74.html                 |  190 ---
 www.i2p2/pages/meeting75.html                 |  104 --
 www.i2p2/pages/meeting76.html                 |  520 --------
 www.i2p2/pages/meeting77.html                 |  502 --------
 www.i2p2/pages/meeting78.html                 |  290 -----
 www.i2p2/pages/meeting79.html                 |  187 ---
 www.i2p2/pages/meeting8.html                  |  149 ---
 www.i2p2/pages/meeting80.html                 |  358 ------
 www.i2p2/pages/meeting81.html                 |  405 ------
 www.i2p2/pages/meeting82.html                 |  470 -------
 www.i2p2/pages/meeting9.html                  |   98 --
 www.i2p2/pages/meeting90.html                 |  203 ---
 www.i2p2/pages/meeting92.html                 |  341 -----
 www.i2p2/pages/meeting93.html                 |  280 ----
 www.i2p2/pages/meeting95.html                 |  287 -----
 www.i2p2/pages/meeting99.html                 |  203 ---
 343 files changed, 42282 insertions(+), 42282 deletions(-)
 create mode 100644 i2p2www/meetings/1.log
 create mode 100644 i2p2www/meetings/10.log
 create mode 100644 i2p2www/meetings/100.log
 create mode 100644 i2p2www/meetings/101.log
 create mode 100644 i2p2www/meetings/102.log
 create mode 100644 i2p2www/meetings/103.log
 create mode 100644 i2p2www/meetings/104.log
 create mode 100644 i2p2www/meetings/105.log
 create mode 100644 i2p2www/meetings/106.log
 create mode 100644 i2p2www/meetings/107.log
 create mode 100644 i2p2www/meetings/108.log
 create mode 100644 i2p2www/meetings/109.log
 create mode 100644 i2p2www/meetings/11.log
 create mode 100644 i2p2www/meetings/110.log
 create mode 100644 i2p2www/meetings/111.log
 create mode 100644 i2p2www/meetings/112.log
 create mode 100644 i2p2www/meetings/113.log
 create mode 100644 i2p2www/meetings/114.log
 create mode 100644 i2p2www/meetings/115.log
 create mode 100644 i2p2www/meetings/116.log
 create mode 100644 i2p2www/meetings/117.log
 create mode 100644 i2p2www/meetings/118.log
 create mode 100644 i2p2www/meetings/119.log
 create mode 100644 i2p2www/meetings/12.log
 create mode 100644 i2p2www/meetings/120.log
 create mode 100644 i2p2www/meetings/121.log
 create mode 100644 i2p2www/meetings/122.log
 create mode 100644 i2p2www/meetings/123.log
 create mode 100644 i2p2www/meetings/124.log
 create mode 100644 i2p2www/meetings/125.log
 create mode 100644 i2p2www/meetings/126.log
 create mode 100644 i2p2www/meetings/127.log
 create mode 100644 i2p2www/meetings/128.log
 create mode 100644 i2p2www/meetings/129.log
 create mode 100644 i2p2www/meetings/130.log
 create mode 100644 i2p2www/meetings/131.log
 create mode 100644 i2p2www/meetings/132.log
 create mode 100644 i2p2www/meetings/133.log
 create mode 100644 i2p2www/meetings/134.log
 create mode 100644 i2p2www/meetings/135.log
 create mode 100644 i2p2www/meetings/136.log
 create mode 100644 i2p2www/meetings/137.log
 create mode 100644 i2p2www/meetings/138.log
 create mode 100644 i2p2www/meetings/139.log
 create mode 100644 i2p2www/meetings/140.log
 create mode 100644 i2p2www/meetings/141.log
 create mode 100644 i2p2www/meetings/142.log
 create mode 100644 i2p2www/meetings/143.log
 create mode 100644 i2p2www/meetings/144.log
 create mode 100644 i2p2www/meetings/145.log
 create mode 100644 i2p2www/meetings/146.log
 create mode 100644 i2p2www/meetings/147.log
 create mode 100644 i2p2www/meetings/148.log
 create mode 100644 i2p2www/meetings/149.log
 create mode 100644 i2p2www/meetings/15.log
 create mode 100644 i2p2www/meetings/150.log
 create mode 100644 i2p2www/meetings/151.log
 create mode 100644 i2p2www/meetings/152.log
 create mode 100644 i2p2www/meetings/153.log
 create mode 100644 i2p2www/meetings/154.log
 create mode 100644 i2p2www/meetings/155.log
 create mode 100644 i2p2www/meetings/156.log
 create mode 100644 i2p2www/meetings/157.log
 create mode 100644 i2p2www/meetings/158.log
 create mode 100644 i2p2www/meetings/159.log
 create mode 100644 i2p2www/meetings/160.log
 create mode 100644 i2p2www/meetings/161.log
 create mode 100644 i2p2www/meetings/162.log
 create mode 100644 i2p2www/meetings/163.log
 create mode 100644 i2p2www/meetings/164.log
 create mode 100644 i2p2www/meetings/165.log
 create mode 100644 i2p2www/meetings/166.log
 create mode 100644 i2p2www/meetings/167.log
 create mode 100644 i2p2www/meetings/168.log
 create mode 100644 i2p2www/meetings/170.log
 create mode 100644 i2p2www/meetings/171.log
 create mode 100644 i2p2www/meetings/172.log
 create mode 100644 i2p2www/meetings/173.log
 create mode 100644 i2p2www/meetings/174.log
 create mode 100644 i2p2www/meetings/175.log
 create mode 100644 i2p2www/meetings/176.log
 create mode 100644 i2p2www/meetings/177.log
 create mode 100644 i2p2www/meetings/178.log
 create mode 100644 i2p2www/meetings/179.log
 create mode 100644 i2p2www/meetings/18.log
 create mode 100644 i2p2www/meetings/180.log
 create mode 100644 i2p2www/meetings/181.log
 create mode 100644 i2p2www/meetings/182.log
 create mode 100644 i2p2www/meetings/183.log
 create mode 100644 i2p2www/meetings/184.log
 create mode 100644 i2p2www/meetings/185.log
 create mode 100644 i2p2www/meetings/186.log
 create mode 100644 i2p2www/meetings/187.log
 create mode 100644 i2p2www/meetings/188.log
 create mode 100644 i2p2www/meetings/189.log
 create mode 100644 i2p2www/meetings/190.log
 create mode 100644 i2p2www/meetings/191.log
 create mode 100644 i2p2www/meetings/192.log
 create mode 100644 i2p2www/meetings/193.log
 create mode 100644 i2p2www/meetings/194.log
 create mode 100644 i2p2www/meetings/195.log
 create mode 100644 i2p2www/meetings/196.log
 create mode 100644 i2p2www/meetings/197.log
 create mode 100644 i2p2www/meetings/198.log
 create mode 100644 i2p2www/meetings/199.log
 create mode 100644 i2p2www/meetings/2.log
 create mode 100644 i2p2www/meetings/20.log
 create mode 100644 i2p2www/meetings/200.log
 create mode 100644 i2p2www/meetings/201.log
 create mode 100644 i2p2www/meetings/202.log
 create mode 100644 i2p2www/meetings/203.log
 create mode 100644 i2p2www/meetings/204.log
 create mode 100644 i2p2www/meetings/205.log
 create mode 100644 i2p2www/meetings/206.log
 rename www.i2p2/pages/meeting207.html => i2p2www/meetings/207.log (100%)
 create mode 100644 i2p2www/meetings/21.log
 create mode 100644 i2p2www/meetings/22.log
 create mode 100644 i2p2www/meetings/23.log
 create mode 100644 i2p2www/meetings/25.log
 create mode 100644 i2p2www/meetings/26.log
 create mode 100644 i2p2www/meetings/28.log
 create mode 100644 i2p2www/meetings/29.log
 create mode 100644 i2p2www/meetings/3.log
 create mode 100644 i2p2www/meetings/30.log
 create mode 100644 i2p2www/meetings/31.log
 create mode 100644 i2p2www/meetings/32.log
 create mode 100644 i2p2www/meetings/33.log
 create mode 100644 i2p2www/meetings/34.log
 create mode 100644 i2p2www/meetings/35.log
 create mode 100644 i2p2www/meetings/4.log
 create mode 100644 i2p2www/meetings/47.log
 create mode 100644 i2p2www/meetings/49.log
 create mode 100644 i2p2www/meetings/50.log
 create mode 100644 i2p2www/meetings/51.log
 create mode 100644 i2p2www/meetings/52.log
 create mode 100644 i2p2www/meetings/53.log
 create mode 100644 i2p2www/meetings/54.log
 create mode 100644 i2p2www/meetings/55.log
 create mode 100644 i2p2www/meetings/56.log
 create mode 100644 i2p2www/meetings/57.log
 create mode 100644 i2p2www/meetings/58.log
 create mode 100644 i2p2www/meetings/59.log
 create mode 100644 i2p2www/meetings/60.log
 create mode 100644 i2p2www/meetings/61.log
 create mode 100644 i2p2www/meetings/62.log
 create mode 100644 i2p2www/meetings/63.log
 create mode 100644 i2p2www/meetings/64.log
 create mode 100644 i2p2www/meetings/65.log
 create mode 100644 i2p2www/meetings/66.log
 create mode 100644 i2p2www/meetings/68.log
 create mode 100644 i2p2www/meetings/69.log
 create mode 100644 i2p2www/meetings/7.log
 create mode 100644 i2p2www/meetings/70.log
 create mode 100644 i2p2www/meetings/71.log
 create mode 100644 i2p2www/meetings/72.log
 create mode 100644 i2p2www/meetings/73.log
 create mode 100644 i2p2www/meetings/74.log
 create mode 100644 i2p2www/meetings/75.log
 create mode 100644 i2p2www/meetings/76.log
 create mode 100644 i2p2www/meetings/77.log
 create mode 100644 i2p2www/meetings/78.log
 create mode 100644 i2p2www/meetings/79.log
 create mode 100644 i2p2www/meetings/8.log
 create mode 100644 i2p2www/meetings/80.log
 create mode 100644 i2p2www/meetings/81.log
 create mode 100644 i2p2www/meetings/82.log
 create mode 100644 i2p2www/meetings/9.log
 create mode 100644 i2p2www/meetings/90.log
 create mode 100644 i2p2www/meetings/92.log
 create mode 100644 i2p2www/meetings/93.log
 create mode 100644 i2p2www/meetings/95.log
 create mode 100644 i2p2www/meetings/99.log
 delete mode 100644 www.i2p2/pages/meeting1.html
 delete mode 100644 www.i2p2/pages/meeting10.html
 delete mode 100644 www.i2p2/pages/meeting100.html
 delete mode 100644 www.i2p2/pages/meeting101.html
 delete mode 100644 www.i2p2/pages/meeting102.html
 delete mode 100644 www.i2p2/pages/meeting103.html
 delete mode 100644 www.i2p2/pages/meeting104.html
 delete mode 100644 www.i2p2/pages/meeting105.html
 delete mode 100644 www.i2p2/pages/meeting106.html
 delete mode 100644 www.i2p2/pages/meeting107.html
 delete mode 100644 www.i2p2/pages/meeting108.html
 delete mode 100644 www.i2p2/pages/meeting109.html
 delete mode 100644 www.i2p2/pages/meeting11.html
 delete mode 100644 www.i2p2/pages/meeting110.html
 delete mode 100644 www.i2p2/pages/meeting111.html
 delete mode 100644 www.i2p2/pages/meeting112.html
 delete mode 100644 www.i2p2/pages/meeting113.html
 delete mode 100644 www.i2p2/pages/meeting114.html
 delete mode 100644 www.i2p2/pages/meeting115.html
 delete mode 100644 www.i2p2/pages/meeting116.html
 delete mode 100644 www.i2p2/pages/meeting117.html
 delete mode 100644 www.i2p2/pages/meeting118.html
 delete mode 100644 www.i2p2/pages/meeting119.html
 delete mode 100644 www.i2p2/pages/meeting12.html
 delete mode 100644 www.i2p2/pages/meeting120.html
 delete mode 100644 www.i2p2/pages/meeting121.html
 delete mode 100644 www.i2p2/pages/meeting122.html
 delete mode 100644 www.i2p2/pages/meeting123.html
 delete mode 100644 www.i2p2/pages/meeting124.html
 delete mode 100644 www.i2p2/pages/meeting125.html
 delete mode 100644 www.i2p2/pages/meeting126.html
 delete mode 100644 www.i2p2/pages/meeting127.html
 delete mode 100644 www.i2p2/pages/meeting128.html
 delete mode 100644 www.i2p2/pages/meeting129.html
 delete mode 100644 www.i2p2/pages/meeting130.html
 delete mode 100644 www.i2p2/pages/meeting131.html
 delete mode 100644 www.i2p2/pages/meeting132.html
 delete mode 100644 www.i2p2/pages/meeting133.html
 delete mode 100644 www.i2p2/pages/meeting134.html
 delete mode 100644 www.i2p2/pages/meeting135.html
 delete mode 100644 www.i2p2/pages/meeting136.html
 delete mode 100644 www.i2p2/pages/meeting137.html
 delete mode 100644 www.i2p2/pages/meeting138.html
 delete mode 100644 www.i2p2/pages/meeting139.html
 delete mode 100644 www.i2p2/pages/meeting140.html
 delete mode 100644 www.i2p2/pages/meeting141.html
 delete mode 100644 www.i2p2/pages/meeting142.html
 delete mode 100644 www.i2p2/pages/meeting143.html
 delete mode 100644 www.i2p2/pages/meeting144.html
 delete mode 100644 www.i2p2/pages/meeting145.html
 delete mode 100644 www.i2p2/pages/meeting146.html
 delete mode 100644 www.i2p2/pages/meeting147.html
 delete mode 100644 www.i2p2/pages/meeting148.html
 delete mode 100644 www.i2p2/pages/meeting149.html
 delete mode 100644 www.i2p2/pages/meeting15.html
 delete mode 100644 www.i2p2/pages/meeting150.html
 delete mode 100644 www.i2p2/pages/meeting151.html
 delete mode 100644 www.i2p2/pages/meeting152.html
 delete mode 100644 www.i2p2/pages/meeting153.html
 delete mode 100644 www.i2p2/pages/meeting154.html
 delete mode 100644 www.i2p2/pages/meeting155.html
 delete mode 100644 www.i2p2/pages/meeting156.html
 delete mode 100644 www.i2p2/pages/meeting157.html
 delete mode 100644 www.i2p2/pages/meeting158.html
 delete mode 100644 www.i2p2/pages/meeting159.html
 delete mode 100644 www.i2p2/pages/meeting160.html
 delete mode 100644 www.i2p2/pages/meeting161.html
 delete mode 100644 www.i2p2/pages/meeting162.html
 delete mode 100644 www.i2p2/pages/meeting163.html
 delete mode 100644 www.i2p2/pages/meeting164.html
 delete mode 100644 www.i2p2/pages/meeting165.html
 delete mode 100644 www.i2p2/pages/meeting166.html
 delete mode 100644 www.i2p2/pages/meeting167.html
 delete mode 100644 www.i2p2/pages/meeting168.html
 delete mode 100644 www.i2p2/pages/meeting170.html
 delete mode 100644 www.i2p2/pages/meeting171.html
 delete mode 100644 www.i2p2/pages/meeting172.html
 delete mode 100644 www.i2p2/pages/meeting173.html
 delete mode 100644 www.i2p2/pages/meeting174.html
 delete mode 100644 www.i2p2/pages/meeting175.html
 delete mode 100644 www.i2p2/pages/meeting176.html
 delete mode 100644 www.i2p2/pages/meeting177.html
 delete mode 100644 www.i2p2/pages/meeting178.html
 delete mode 100644 www.i2p2/pages/meeting179.html
 delete mode 100644 www.i2p2/pages/meeting18.html
 delete mode 100644 www.i2p2/pages/meeting180.html
 delete mode 100644 www.i2p2/pages/meeting181.html
 delete mode 100644 www.i2p2/pages/meeting182.html
 delete mode 100644 www.i2p2/pages/meeting183.html
 delete mode 100644 www.i2p2/pages/meeting184.html
 delete mode 100644 www.i2p2/pages/meeting185.html
 delete mode 100644 www.i2p2/pages/meeting186.html
 delete mode 100644 www.i2p2/pages/meeting187.html
 delete mode 100644 www.i2p2/pages/meeting188.html
 delete mode 100644 www.i2p2/pages/meeting189.html
 delete mode 100644 www.i2p2/pages/meeting190.html
 delete mode 100644 www.i2p2/pages/meeting191.html
 delete mode 100644 www.i2p2/pages/meeting192.html
 delete mode 100644 www.i2p2/pages/meeting193.html
 delete mode 100644 www.i2p2/pages/meeting194.html
 delete mode 100644 www.i2p2/pages/meeting195.html
 delete mode 100644 www.i2p2/pages/meeting196.html
 delete mode 100644 www.i2p2/pages/meeting197.html
 delete mode 100644 www.i2p2/pages/meeting198.html
 delete mode 100644 www.i2p2/pages/meeting199.html
 delete mode 100644 www.i2p2/pages/meeting2.html
 delete mode 100644 www.i2p2/pages/meeting20.html
 delete mode 100644 www.i2p2/pages/meeting200.html
 delete mode 100644 www.i2p2/pages/meeting201.html
 delete mode 100644 www.i2p2/pages/meeting202.html
 delete mode 100644 www.i2p2/pages/meeting203.html
 delete mode 100644 www.i2p2/pages/meeting204.html
 delete mode 100644 www.i2p2/pages/meeting205.html
 delete mode 100644 www.i2p2/pages/meeting206.html
 delete mode 100644 www.i2p2/pages/meeting21.html
 delete mode 100644 www.i2p2/pages/meeting22.html
 delete mode 100644 www.i2p2/pages/meeting23.html
 delete mode 100644 www.i2p2/pages/meeting25.html
 delete mode 100644 www.i2p2/pages/meeting26.html
 delete mode 100644 www.i2p2/pages/meeting28.html
 delete mode 100644 www.i2p2/pages/meeting29.html
 delete mode 100644 www.i2p2/pages/meeting3.html
 delete mode 100644 www.i2p2/pages/meeting30.html
 delete mode 100644 www.i2p2/pages/meeting31.html
 delete mode 100644 www.i2p2/pages/meeting32.html
 delete mode 100644 www.i2p2/pages/meeting33.html
 delete mode 100644 www.i2p2/pages/meeting34.html
 delete mode 100644 www.i2p2/pages/meeting35.html
 delete mode 100644 www.i2p2/pages/meeting4.html
 delete mode 100644 www.i2p2/pages/meeting47.html
 delete mode 100644 www.i2p2/pages/meeting49.html
 delete mode 100644 www.i2p2/pages/meeting50.html
 delete mode 100644 www.i2p2/pages/meeting51.html
 delete mode 100644 www.i2p2/pages/meeting52.html
 delete mode 100644 www.i2p2/pages/meeting53.html
 delete mode 100644 www.i2p2/pages/meeting54.html
 delete mode 100644 www.i2p2/pages/meeting55.html
 delete mode 100644 www.i2p2/pages/meeting56.html
 delete mode 100644 www.i2p2/pages/meeting57.html
 delete mode 100644 www.i2p2/pages/meeting58.html
 delete mode 100644 www.i2p2/pages/meeting59.html
 delete mode 100644 www.i2p2/pages/meeting60.html
 delete mode 100644 www.i2p2/pages/meeting61.html
 delete mode 100644 www.i2p2/pages/meeting62.html
 delete mode 100644 www.i2p2/pages/meeting63.html
 delete mode 100644 www.i2p2/pages/meeting64.html
 delete mode 100644 www.i2p2/pages/meeting65.html
 delete mode 100644 www.i2p2/pages/meeting66.html
 delete mode 100644 www.i2p2/pages/meeting68.html
 delete mode 100644 www.i2p2/pages/meeting69.html
 delete mode 100644 www.i2p2/pages/meeting7.html
 delete mode 100644 www.i2p2/pages/meeting70.html
 delete mode 100644 www.i2p2/pages/meeting71.html
 delete mode 100644 www.i2p2/pages/meeting72.html
 delete mode 100644 www.i2p2/pages/meeting73.html
 delete mode 100644 www.i2p2/pages/meeting74.html
 delete mode 100644 www.i2p2/pages/meeting75.html
 delete mode 100644 www.i2p2/pages/meeting76.html
 delete mode 100644 www.i2p2/pages/meeting77.html
 delete mode 100644 www.i2p2/pages/meeting78.html
 delete mode 100644 www.i2p2/pages/meeting79.html
 delete mode 100644 www.i2p2/pages/meeting8.html
 delete mode 100644 www.i2p2/pages/meeting80.html
 delete mode 100644 www.i2p2/pages/meeting81.html
 delete mode 100644 www.i2p2/pages/meeting82.html
 delete mode 100644 www.i2p2/pages/meeting9.html
 delete mode 100644 www.i2p2/pages/meeting90.html
 delete mode 100644 www.i2p2/pages/meeting92.html
 delete mode 100644 www.i2p2/pages/meeting93.html
 delete mode 100644 www.i2p2/pages/meeting95.html
 delete mode 100644 www.i2p2/pages/meeting99.html

diff --git a/i2p2www/meetings/1.log b/i2p2www/meetings/1.log
new file mode 100644
index 00000000..d352999f
--- /dev/null
+++ b/i2p2www/meetings/1.log
@@ -0,0 +1,704 @@
+{% 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/i2p2www/meetings/10.log b/i2p2www/meetings/10.log
new file mode 100644
index 00000000..56e5cf6c
--- /dev/null
+++ b/i2p2www/meetings/10.log
@@ -0,0 +1,171 @@
+{% 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/i2p2www/meetings/100.log b/i2p2www/meetings/100.log
new file mode 100644
index 00000000..4a658280
--- /dev/null
+++ b/i2p2www/meetings/100.log
@@ -0,0 +1,195 @@
+{% 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/i2p2www/meetings/101.log b/i2p2www/meetings/101.log
new file mode 100644
index 00000000..b772578e
--- /dev/null
+++ b/i2p2www/meetings/101.log
@@ -0,0 +1,221 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 101{% endblock %}
+{% block content %}
                I2P dev meeting, August 3 @ 21:00 GMT
                
+
                
+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  <hypercubus> 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
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/102.log b/i2p2www/meetings/102.log
new file mode 100644
index 00000000..328aea2b
--- /dev/null
+++ b/i2p2www/meetings/102.log
@@ -0,0 +1,120 @@
+{% 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/i2p2www/meetings/103.log b/i2p2www/meetings/103.log
new file mode 100644
index 00000000..0df1096b
--- /dev/null
+++ b/i2p2www/meetings/103.log
@@ -0,0 +1,217 @@
+{% 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/i2p2www/meetings/104.log b/i2p2www/meetings/104.log
new file mode 100644
index 00000000..7ef7c3a3
--- /dev/null
+++ b/i2p2www/meetings/104.log
@@ -0,0 +1,422 @@
+{% 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/i2p2www/meetings/105.log b/i2p2www/meetings/105.log
new file mode 100644
index 00000000..ddec83da
--- /dev/null
+++ b/i2p2www/meetings/105.log
@@ -0,0 +1,225 @@
+{% 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/i2p2www/meetings/106.log b/i2p2www/meetings/106.log
new file mode 100644
index 00000000..d9a9c279
--- /dev/null
+++ b/i2p2www/meetings/106.log
@@ -0,0 +1,476 @@
+{% 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/i2p2www/meetings/107.log b/i2p2www/meetings/107.log
new file mode 100644
index 00000000..71ed965c
--- /dev/null
+++ b/i2p2www/meetings/107.log
@@ -0,0 +1,500 @@
+{% 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/i2p2www/meetings/108.log b/i2p2www/meetings/108.log
new file mode 100644
index 00000000..5a140d76
--- /dev/null
+++ b/i2p2www/meetings/108.log
@@ -0,0 +1,40 @@
+{% 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/i2p2www/meetings/109.log b/i2p2www/meetings/109.log
new file mode 100644
index 00000000..50a8ad8a
--- /dev/null
+++ b/i2p2www/meetings/109.log
@@ -0,0 +1,119 @@
+{% 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/i2p2www/meetings/11.log b/i2p2www/meetings/11.log
new file mode 100644
index 00000000..5964e32e
--- /dev/null
+++ b/i2p2www/meetings/11.log
@@ -0,0 +1,161 @@
+{% 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/i2p2www/meetings/110.log b/i2p2www/meetings/110.log
new file mode 100644
index 00000000..46845697
--- /dev/null
+++ b/i2p2www/meetings/110.log
@@ -0,0 +1,186 @@
+{% 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/i2p2www/meetings/111.log b/i2p2www/meetings/111.log
new file mode 100644
index 00000000..650459d6
--- /dev/null
+++ b/i2p2www/meetings/111.log
@@ -0,0 +1,201 @@
+{% 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/i2p2www/meetings/112.log b/i2p2www/meetings/112.log
new file mode 100644
index 00000000..5acac7a0
--- /dev/null
+++ b/i2p2www/meetings/112.log
@@ -0,0 +1,272 @@
+{% 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/i2p2www/meetings/113.log b/i2p2www/meetings/113.log
new file mode 100644
index 00000000..08d574f7
--- /dev/null
+++ b/i2p2www/meetings/113.log
@@ -0,0 +1,273 @@
+{% 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/i2p2www/meetings/114.log b/i2p2www/meetings/114.log
new file mode 100644
index 00000000..fe3717ad
--- /dev/null
+++ b/i2p2www/meetings/114.log
@@ -0,0 +1,404 @@
+{% 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/i2p2www/meetings/115.log b/i2p2www/meetings/115.log
new file mode 100644
index 00000000..42b035e2
--- /dev/null
+++ b/i2p2www/meetings/115.log
@@ -0,0 +1,523 @@
+{% 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/i2p2www/meetings/116.log b/i2p2www/meetings/116.log
new file mode 100644
index 00000000..2a28fe98
--- /dev/null
+++ b/i2p2www/meetings/116.log
@@ -0,0 +1,183 @@
+{% 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/i2p2www/meetings/117.log b/i2p2www/meetings/117.log
new file mode 100644
index 00000000..1772cdb4
--- /dev/null
+++ b/i2p2www/meetings/117.log
@@ -0,0 +1,70 @@
+{% 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/i2p2www/meetings/118.log b/i2p2www/meetings/118.log
new file mode 100644
index 00000000..fb4644b2
--- /dev/null
+++ b/i2p2www/meetings/118.log
@@ -0,0 +1,324 @@
+{% 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/i2p2www/meetings/119.log b/i2p2www/meetings/119.log
new file mode 100644
index 00000000..f7ebefc4
--- /dev/null
+++ b/i2p2www/meetings/119.log
@@ -0,0 +1,174 @@
+{% 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/i2p2www/meetings/12.log b/i2p2www/meetings/12.log
new file mode 100644
index 00000000..ee8c39a5
--- /dev/null
+++ b/i2p2www/meetings/12.log
@@ -0,0 +1,619 @@
+{% 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/i2p2www/meetings/120.log b/i2p2www/meetings/120.log
new file mode 100644
index 00000000..346d123c
--- /dev/null
+++ b/i2p2www/meetings/120.log
@@ -0,0 +1,490 @@
+{% 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/i2p2www/meetings/121.log b/i2p2www/meetings/121.log
new file mode 100644
index 00000000..9e7740c0
--- /dev/null
+++ b/i2p2www/meetings/121.log
@@ -0,0 +1,329 @@
+{% 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/i2p2www/meetings/122.log b/i2p2www/meetings/122.log
new file mode 100644
index 00000000..87e5162e
--- /dev/null
+++ b/i2p2www/meetings/122.log
@@ -0,0 +1,201 @@
+{% 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/i2p2www/meetings/123.log b/i2p2www/meetings/123.log
new file mode 100644
index 00000000..076d9577
--- /dev/null
+++ b/i2p2www/meetings/123.log
@@ -0,0 +1,160 @@
+{% 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/i2p2www/meetings/124.log b/i2p2www/meetings/124.log
new file mode 100644
index 00000000..a0781999
--- /dev/null
+++ b/i2p2www/meetings/124.log
@@ -0,0 +1,384 @@
+{% 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/i2p2www/meetings/125.log b/i2p2www/meetings/125.log
new file mode 100644
index 00000000..e6c7e57e
--- /dev/null
+++ b/i2p2www/meetings/125.log
@@ -0,0 +1,284 @@
+{% 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/i2p2www/meetings/126.log b/i2p2www/meetings/126.log
new file mode 100644
index 00000000..7083eca0
--- /dev/null
+++ b/i2p2www/meetings/126.log
@@ -0,0 +1,178 @@
+{% 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/i2p2www/meetings/127.log b/i2p2www/meetings/127.log
new file mode 100644
index 00000000..ada0e44c
--- /dev/null
+++ b/i2p2www/meetings/127.log
@@ -0,0 +1,159 @@
+{% 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/i2p2www/meetings/128.log b/i2p2www/meetings/128.log
new file mode 100644
index 00000000..774dbd81
--- /dev/null
+++ b/i2p2www/meetings/128.log
@@ -0,0 +1,291 @@
+{% 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/i2p2www/meetings/129.log b/i2p2www/meetings/129.log
new file mode 100644
index 00000000..8a81ea7a
--- /dev/null
+++ b/i2p2www/meetings/129.log
@@ -0,0 +1,253 @@
+{% 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/i2p2www/meetings/130.log b/i2p2www/meetings/130.log
new file mode 100644
index 00000000..e618b93a
--- /dev/null
+++ b/i2p2www/meetings/130.log
@@ -0,0 +1,288 @@
+{% 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/i2p2www/meetings/131.log b/i2p2www/meetings/131.log
new file mode 100644
index 00000000..2131d894
--- /dev/null
+++ b/i2p2www/meetings/131.log
@@ -0,0 +1,372 @@
+{% 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/i2p2www/meetings/132.log b/i2p2www/meetings/132.log
new file mode 100644
index 00000000..60d3cd0d
--- /dev/null
+++ b/i2p2www/meetings/132.log
@@ -0,0 +1,365 @@
+{% 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/i2p2www/meetings/133.log b/i2p2www/meetings/133.log
new file mode 100644
index 00000000..43a70829
--- /dev/null
+++ b/i2p2www/meetings/133.log
@@ -0,0 +1,323 @@
+{% 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/i2p2www/meetings/134.log b/i2p2www/meetings/134.log
new file mode 100644
index 00000000..62dfb1b5
--- /dev/null
+++ b/i2p2www/meetings/134.log
@@ -0,0 +1,177 @@
+{% 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/i2p2www/meetings/135.log b/i2p2www/meetings/135.log
new file mode 100644
index 00000000..cc0cd36d
--- /dev/null
+++ b/i2p2www/meetings/135.log
@@ -0,0 +1,125 @@
+{% 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/i2p2www/meetings/136.log b/i2p2www/meetings/136.log
new file mode 100644
index 00000000..8c0a7466
--- /dev/null
+++ b/i2p2www/meetings/136.log
@@ -0,0 +1,103 @@
+{% 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/i2p2www/meetings/137.log b/i2p2www/meetings/137.log
new file mode 100644
index 00000000..4953812b
--- /dev/null
+++ b/i2p2www/meetings/137.log
@@ -0,0 +1,286 @@
+{% 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/i2p2www/meetings/138.log b/i2p2www/meetings/138.log
new file mode 100644
index 00000000..ae1afef8
--- /dev/null
+++ b/i2p2www/meetings/138.log
@@ -0,0 +1,106 @@
+{% 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/i2p2www/meetings/139.log b/i2p2www/meetings/139.log
new file mode 100644
index 00000000..edcb3ce1
--- /dev/null
+++ b/i2p2www/meetings/139.log
@@ -0,0 +1,64 @@
+{% 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/i2p2www/meetings/140.log b/i2p2www/meetings/140.log
new file mode 100644
index 00000000..dd03992e
--- /dev/null
+++ b/i2p2www/meetings/140.log
@@ -0,0 +1,199 @@
+{% 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/i2p2www/meetings/141.log b/i2p2www/meetings/141.log
new file mode 100644
index 00000000..136227cb
--- /dev/null
+++ b/i2p2www/meetings/141.log
@@ -0,0 +1,135 @@
+{% 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/i2p2www/meetings/142.log b/i2p2www/meetings/142.log
new file mode 100644
index 00000000..60f92ed9
--- /dev/null
+++ b/i2p2www/meetings/142.log
@@ -0,0 +1,94 @@
+{% 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/i2p2www/meetings/143.log b/i2p2www/meetings/143.log
new file mode 100644
index 00000000..b62d56f8
--- /dev/null
+++ b/i2p2www/meetings/143.log
@@ -0,0 +1,56 @@
+{% 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/i2p2www/meetings/144.log b/i2p2www/meetings/144.log
new file mode 100644
index 00000000..ee66a9ea
--- /dev/null
+++ b/i2p2www/meetings/144.log
@@ -0,0 +1,149 @@
+{% 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/i2p2www/meetings/145.log b/i2p2www/meetings/145.log
new file mode 100644
index 00000000..cf33de28
--- /dev/null
+++ b/i2p2www/meetings/145.log
@@ -0,0 +1,134 @@
+{% 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/i2p2www/meetings/146.log b/i2p2www/meetings/146.log
new file mode 100644
index 00000000..6a6f865a
--- /dev/null
+++ b/i2p2www/meetings/146.log
@@ -0,0 +1,218 @@
+{% 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/i2p2www/meetings/147.log b/i2p2www/meetings/147.log
new file mode 100644
index 00000000..927fd091
--- /dev/null
+++ b/i2p2www/meetings/147.log
@@ -0,0 +1,47 @@
+{% 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/i2p2www/meetings/148.log b/i2p2www/meetings/148.log
new file mode 100644
index 00000000..06c33ae0
--- /dev/null
+++ b/i2p2www/meetings/148.log
@@ -0,0 +1,103 @@
+{% 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/i2p2www/meetings/149.log b/i2p2www/meetings/149.log
new file mode 100644
index 00000000..9da682a6
--- /dev/null
+++ b/i2p2www/meetings/149.log
@@ -0,0 +1,258 @@
+{% 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/i2p2www/meetings/15.log b/i2p2www/meetings/15.log
new file mode 100644
index 00000000..e568271e
--- /dev/null
+++ b/i2p2www/meetings/15.log
@@ -0,0 +1,526 @@
+{% 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/i2p2www/meetings/150.log b/i2p2www/meetings/150.log
new file mode 100644
index 00000000..95797f0a
--- /dev/null
+++ b/i2p2www/meetings/150.log
@@ -0,0 +1,148 @@
+{% 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/i2p2www/meetings/151.log b/i2p2www/meetings/151.log
new file mode 100644
index 00000000..c0195d8d
--- /dev/null
+++ b/i2p2www/meetings/151.log
@@ -0,0 +1,240 @@
+{% 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/i2p2www/meetings/152.log b/i2p2www/meetings/152.log
new file mode 100644
index 00000000..4de2f908
--- /dev/null
+++ b/i2p2www/meetings/152.log
@@ -0,0 +1,276 @@
+{% 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  [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  GregorK : maybe, I'm working on it
                
+17:04  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  cool...I have lots of cool movies I can share with myself :)
                
+17:05  * strike that from the meeting notes *
                
+17:06  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/i2p2www/meetings/153.log b/i2p2www/meetings/153.log
new file mode 100644
index 00000000..c83fd4ac
--- /dev/null
+++ b/i2p2www/meetings/153.log
@@ -0,0 +1,446 @@
+{% 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/i2p2www/meetings/154.log b/i2p2www/meetings/154.log
new file mode 100644
index 00000000..7bb1bd52
--- /dev/null
+++ b/i2p2www/meetings/154.log
@@ -0,0 +1,182 @@
+{% 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  :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/i2p2www/meetings/155.log b/i2p2www/meetings/155.log
new file mode 100644
index 00000000..15954237
--- /dev/null
+++ b/i2p2www/meetings/155.log
@@ -0,0 +1,66 @@
+{% 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/i2p2www/meetings/156.log b/i2p2www/meetings/156.log
new file mode 100644
index 00000000..de250272
--- /dev/null
+++ b/i2p2www/meetings/156.log
@@ -0,0 +1,351 @@
+{% 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/i2p2www/meetings/157.log b/i2p2www/meetings/157.log
new file mode 100644
index 00000000..9fed0c62
--- /dev/null
+++ b/i2p2www/meetings/157.log
@@ -0,0 +1,144 @@
+{% 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/i2p2www/meetings/158.log b/i2p2www/meetings/158.log
new file mode 100644
index 00000000..73a1f49c
--- /dev/null
+++ b/i2p2www/meetings/158.log
@@ -0,0 +1,228 @@
+{% 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/i2p2www/meetings/159.log b/i2p2www/meetings/159.log
new file mode 100644
index 00000000..93309585
--- /dev/null
+++ b/i2p2www/meetings/159.log
@@ -0,0 +1,266 @@
+{% 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/i2p2www/meetings/160.log b/i2p2www/meetings/160.log
new file mode 100644
index 00000000..afd55b92
--- /dev/null
+++ b/i2p2www/meetings/160.log
@@ -0,0 +1,55 @@
+{% 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/i2p2www/meetings/161.log b/i2p2www/meetings/161.log
new file mode 100644
index 00000000..1d57559c
--- /dev/null
+++ b/i2p2www/meetings/161.log
@@ -0,0 +1,122 @@
+{% 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/i2p2www/meetings/162.log b/i2p2www/meetings/162.log
new file mode 100644
index 00000000..f1658f1b
--- /dev/null
+++ b/i2p2www/meetings/162.log
@@ -0,0 +1,93 @@
+{% 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/i2p2www/meetings/163.log b/i2p2www/meetings/163.log
new file mode 100644
index 00000000..733b9c4f
--- /dev/null
+++ b/i2p2www/meetings/163.log
@@ -0,0 +1,176 @@
+{% 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/i2p2www/meetings/164.log b/i2p2www/meetings/164.log
new file mode 100644
index 00000000..48f992a8
--- /dev/null
+++ b/i2p2www/meetings/164.log
@@ -0,0 +1,267 @@
+{% 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/i2p2www/meetings/165.log b/i2p2www/meetings/165.log
new file mode 100644
index 00000000..bcd549cd
--- /dev/null
+++ b/i2p2www/meetings/165.log
@@ -0,0 +1,114 @@
+{% 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/i2p2www/meetings/166.log b/i2p2www/meetings/166.log
new file mode 100644
index 00000000..1d52749d
--- /dev/null
+++ b/i2p2www/meetings/166.log
@@ -0,0 +1,142 @@
+{% 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/i2p2www/meetings/167.log b/i2p2www/meetings/167.log
new file mode 100644
index 00000000..b3ee153b
--- /dev/null
+++ b/i2p2www/meetings/167.log
@@ -0,0 +1,151 @@
+{% 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/i2p2www/meetings/168.log b/i2p2www/meetings/168.log
new file mode 100644
index 00000000..7efe3230
--- /dev/null
+++ b/i2p2www/meetings/168.log
@@ -0,0 +1,74 @@
+{% 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/i2p2www/meetings/170.log b/i2p2www/meetings/170.log
new file mode 100644
index 00000000..a0abe54e
--- /dev/null
+++ b/i2p2www/meetings/170.log
@@ -0,0 +1,122 @@
+{% 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/i2p2www/meetings/171.log b/i2p2www/meetings/171.log
new file mode 100644
index 00000000..3a1fc17e
--- /dev/null
+++ b/i2p2www/meetings/171.log
@@ -0,0 +1,78 @@
+{% 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/i2p2www/meetings/172.log b/i2p2www/meetings/172.log
new file mode 100644
index 00000000..4938692a
--- /dev/null
+++ b/i2p2www/meetings/172.log
@@ -0,0 +1,65 @@
+{% 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/i2p2www/meetings/173.log b/i2p2www/meetings/173.log
new file mode 100644
index 00000000..eeefbb5e
--- /dev/null
+++ b/i2p2www/meetings/173.log
@@ -0,0 +1,122 @@
+{% 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/i2p2www/meetings/174.log b/i2p2www/meetings/174.log
new file mode 100644
index 00000000..0dce7b5c
--- /dev/null
+++ b/i2p2www/meetings/174.log
@@ -0,0 +1,78 @@
+{% 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/i2p2www/meetings/175.log b/i2p2www/meetings/175.log
new file mode 100644
index 00000000..a6030831
--- /dev/null
+++ b/i2p2www/meetings/175.log
@@ -0,0 +1,132 @@
+{% 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/i2p2www/meetings/176.log b/i2p2www/meetings/176.log
new file mode 100644
index 00000000..27b01e62
--- /dev/null
+++ b/i2p2www/meetings/176.log
@@ -0,0 +1,180 @@
+{% 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/i2p2www/meetings/177.log b/i2p2www/meetings/177.log
new file mode 100644
index 00000000..6d0cf70e
--- /dev/null
+++ b/i2p2www/meetings/177.log
@@ -0,0 +1,154 @@
+{% 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/i2p2www/meetings/178.log b/i2p2www/meetings/178.log
new file mode 100644
index 00000000..d385f2cc
--- /dev/null
+++ b/i2p2www/meetings/178.log
@@ -0,0 +1,41 @@
+{% 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/i2p2www/meetings/179.log b/i2p2www/meetings/179.log
new file mode 100644
index 00000000..9f41502a
--- /dev/null
+++ b/i2p2www/meetings/179.log
@@ -0,0 +1,67 @@
+{% 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/i2p2www/meetings/18.log b/i2p2www/meetings/18.log
new file mode 100644
index 00000000..ca960a73
--- /dev/null
+++ b/i2p2www/meetings/18.log
@@ -0,0 +1,179 @@
+{% 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/i2p2www/meetings/180.log b/i2p2www/meetings/180.log
new file mode 100644
index 00000000..5aeb118c
--- /dev/null
+++ b/i2p2www/meetings/180.log
@@ -0,0 +1,83 @@
+{% 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/i2p2www/meetings/181.log b/i2p2www/meetings/181.log
new file mode 100644
index 00000000..e00e7e9d
--- /dev/null
+++ b/i2p2www/meetings/181.log
@@ -0,0 +1,58 @@
+{% 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/i2p2www/meetings/182.log b/i2p2www/meetings/182.log
new file mode 100644
index 00000000..f91c1006
--- /dev/null
+++ b/i2p2www/meetings/182.log
@@ -0,0 +1,63 @@
+{% 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/i2p2www/meetings/183.log b/i2p2www/meetings/183.log
new file mode 100644
index 00000000..165e9570
--- /dev/null
+++ b/i2p2www/meetings/183.log
@@ -0,0 +1,191 @@
+{% 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/i2p2www/meetings/184.log b/i2p2www/meetings/184.log
new file mode 100644
index 00000000..8cec865b
--- /dev/null
+++ b/i2p2www/meetings/184.log
@@ -0,0 +1,268 @@
+{% 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/i2p2www/meetings/185.log b/i2p2www/meetings/185.log
new file mode 100644
index 00000000..5e1708ea
--- /dev/null
+++ b/i2p2www/meetings/185.log
@@ -0,0 +1,85 @@
+{% 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/i2p2www/meetings/186.log b/i2p2www/meetings/186.log
new file mode 100644
index 00000000..367ec69f
--- /dev/null
+++ b/i2p2www/meetings/186.log
@@ -0,0 +1,103 @@
+{% 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/i2p2www/meetings/187.log b/i2p2www/meetings/187.log
new file mode 100644
index 00000000..ca688108
--- /dev/null
+++ b/i2p2www/meetings/187.log
@@ -0,0 +1,76 @@
+{% 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/i2p2www/meetings/188.log b/i2p2www/meetings/188.log
new file mode 100644
index 00000000..70b2b42b
--- /dev/null
+++ b/i2p2www/meetings/188.log
@@ -0,0 +1,93 @@
+{% 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/i2p2www/meetings/189.log b/i2p2www/meetings/189.log
new file mode 100644
index 00000000..263a2b26
--- /dev/null
+++ b/i2p2www/meetings/189.log
@@ -0,0 +1,96 @@
+{% 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/i2p2www/meetings/190.log b/i2p2www/meetings/190.log
new file mode 100644
index 00000000..068ed543
--- /dev/null
+++ b/i2p2www/meetings/190.log
@@ -0,0 +1,120 @@
+{% 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/i2p2www/meetings/191.log b/i2p2www/meetings/191.log
new file mode 100644
index 00000000..7fc09e70
--- /dev/null
+++ b/i2p2www/meetings/191.log
@@ -0,0 +1,58 @@
+{% 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/i2p2www/meetings/192.log b/i2p2www/meetings/192.log
new file mode 100644
index 00000000..f14a2d46
--- /dev/null
+++ b/i2p2www/meetings/192.log
@@ -0,0 +1,58 @@
+{% 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/i2p2www/meetings/193.log b/i2p2www/meetings/193.log
new file mode 100644
index 00000000..51b12b4f
--- /dev/null
+++ b/i2p2www/meetings/193.log
@@ -0,0 +1,26 @@
+{% 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/i2p2www/meetings/194.log b/i2p2www/meetings/194.log
new file mode 100644
index 00000000..39c4c502
--- /dev/null
+++ b/i2p2www/meetings/194.log
@@ -0,0 +1,160 @@
+{% 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/i2p2www/meetings/195.log b/i2p2www/meetings/195.log
new file mode 100644
index 00000000..d52a9f96
--- /dev/null
+++ b/i2p2www/meetings/195.log
@@ -0,0 +1,78 @@
+{% 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/i2p2www/meetings/196.log b/i2p2www/meetings/196.log
new file mode 100644
index 00000000..aee807ae
--- /dev/null
+++ b/i2p2www/meetings/196.log
@@ -0,0 +1,117 @@
+{% 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/i2p2www/meetings/197.log b/i2p2www/meetings/197.log
new file mode 100644
index 00000000..b404b52c
--- /dev/null
+++ b/i2p2www/meetings/197.log
@@ -0,0 +1,39 @@
+{% 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/i2p2www/meetings/198.log b/i2p2www/meetings/198.log
new file mode 100644
index 00000000..aedd393e
--- /dev/null
+++ b/i2p2www/meetings/198.log
@@ -0,0 +1,63 @@
+{% 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/i2p2www/meetings/199.log b/i2p2www/meetings/199.log
new file mode 100644
index 00000000..2b477f6e
--- /dev/null
+++ b/i2p2www/meetings/199.log
@@ -0,0 +1,241 @@
+{% 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/i2p2www/meetings/2.log b/i2p2www/meetings/2.log
new file mode 100644
index 00000000..16c39de9
--- /dev/null
+++ b/i2p2www/meetings/2.log
@@ -0,0 +1,1134 @@
+{% 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/i2p2www/meetings/20.log b/i2p2www/meetings/20.log
new file mode 100644
index 00000000..340a2a0e
--- /dev/null
+++ b/i2p2www/meetings/20.log
@@ -0,0 +1,413 @@
+{% 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/i2p2www/meetings/200.log b/i2p2www/meetings/200.log
new file mode 100644
index 00000000..24767866
--- /dev/null
+++ b/i2p2www/meetings/200.log
@@ -0,0 +1,79 @@
+{% 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/i2p2www/meetings/201.log b/i2p2www/meetings/201.log
new file mode 100644
index 00000000..cc1a4edb
--- /dev/null
+++ b/i2p2www/meetings/201.log
@@ -0,0 +1,40 @@
+{% 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/i2p2www/meetings/202.log b/i2p2www/meetings/202.log
new file mode 100644
index 00000000..371ee6af
--- /dev/null
+++ b/i2p2www/meetings/202.log
@@ -0,0 +1,87 @@
+{% 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/i2p2www/meetings/203.log b/i2p2www/meetings/203.log
new file mode 100644
index 00000000..75c07a7d
--- /dev/null
+++ b/i2p2www/meetings/203.log
@@ -0,0 +1,111 @@
+{% 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/i2p2www/meetings/204.log b/i2p2www/meetings/204.log
new file mode 100644
index 00000000..d2051733
--- /dev/null
+++ b/i2p2www/meetings/204.log
@@ -0,0 +1,81 @@
+{% 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/i2p2www/meetings/205.log b/i2p2www/meetings/205.log
new file mode 100644
index 00000000..365b59c4
--- /dev/null
+++ b/i2p2www/meetings/205.log
@@ -0,0 +1,88 @@
+{% 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/i2p2www/meetings/206.log b/i2p2www/meetings/206.log
new file mode 100644
index 00000000..9352186e
--- /dev/null
+++ b/i2p2www/meetings/206.log
@@ -0,0 +1,45 @@
+{% 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/meeting207.html b/i2p2www/meetings/207.log
similarity index 100%
rename from www.i2p2/pages/meeting207.html
rename to i2p2www/meetings/207.log
diff --git a/i2p2www/meetings/21.log b/i2p2www/meetings/21.log
new file mode 100644
index 00000000..b1df2265
--- /dev/null
+++ b/i2p2www/meetings/21.log
@@ -0,0 +1,691 @@
+{% 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/i2p2www/meetings/22.log b/i2p2www/meetings/22.log
new file mode 100644
index 00000000..0e110f52
--- /dev/null
+++ b/i2p2www/meetings/22.log
@@ -0,0 +1,153 @@
+{% 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/i2p2www/meetings/23.log b/i2p2www/meetings/23.log
new file mode 100644
index 00000000..664d7949
--- /dev/null
+++ b/i2p2www/meetings/23.log
@@ -0,0 +1,340 @@
+{% 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/i2p2www/meetings/25.log b/i2p2www/meetings/25.log
new file mode 100644
index 00000000..bac28733
--- /dev/null
+++ b/i2p2www/meetings/25.log
@@ -0,0 +1,150 @@
+{% 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/
+ nop, no meeting today?
+ yes
+ sorry
+ ok
+ welcome
+ hi nop ;)
+ hi
+ agenda
+ 1) welcome
+ whats going on? everybody sleeps?
+ 2) Happy New Year
+ 3) Happy Holidays
+ hi, happy new year
+ 4) IIP
+ hehe, happy new year too
+ happy new year! :)
+ 5) IIP logo contest
+ 6) CryptoCon
+ 4) IIP
+ ok IIP
+ it's kind of stagnant because of the holidays
+ but I believe we're picking it back up
+ any bug reports please send to iip@invisiblenet.net
+ ok
+ 5) IIP logo contest
+ we'll being putting up something on our site about the rules etc
+ and display the drawings we have so far
+ please help out if you can
+ get a free t-shirt and your logo on it
+ 6) CryptoCon
+ cool
+ we're trying to get a program committee and some organizational
+planning for Jan 2004 to have cryptocon happen
+ join #cryptocon for any assistance etc
+ anyway, that's about it
+ questions?
+ questions?
+ ;)
+ nope
+ ok
+ meeting ajourned
+ nope
+ thanks. :)
+ np
+ oo, 1 thing
+ about cryptocon
+ is there a particular reason for organising your/your own?
+ there are general crypto confs out there that cyou could submit
+stuff 2
+ well
+ we want to attract businesses to meet cipherpunks
+ and push cryptography more than it is
+ this will be different
+ fsck
+ gotcha
+ missed it
+ ;)
+ sorry folks :)
+ it will just be a lot of work 4 u all
+ is there still a point in bringing the logger here?
+ lol
+ hehe
+ 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/i2p2www/meetings/26.log b/i2p2www/meetings/26.log
new file mode 100644
index 00000000..9cdf7963
--- /dev/null
+++ b/i2p2www/meetings/26.log
@@ -0,0 +1,269 @@
+{% 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/i2p2www/meetings/28.log b/i2p2www/meetings/28.log
new file mode 100644
index 00000000..6086192d
--- /dev/null
+++ b/i2p2www/meetings/28.log
@@ -0,0 +1,149 @@
+{% 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/i2p2www/meetings/29.log b/i2p2www/meetings/29.log
new file mode 100644
index 00000000..990a9f72
--- /dev/null
+++ b/i2p2www/meetings/29.log
@@ -0,0 +1,205 @@
+{% 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/i2p2www/meetings/3.log b/i2p2www/meetings/3.log
new file mode 100644
index 00000000..9b0e8f8d
--- /dev/null
+++ b/i2p2www/meetings/3.log
@@ -0,0 +1,618 @@
+{% 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/i2p2www/meetings/30.log b/i2p2www/meetings/30.log
new file mode 100644
index 00000000..4f4c0784
--- /dev/null
+++ b/i2p2www/meetings/30.log
@@ -0,0 +1,457 @@
+{% 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/i2p2www/meetings/31.log b/i2p2www/meetings/31.log
new file mode 100644
index 00000000..1161ff5d
--- /dev/null
+++ b/i2p2www/meetings/31.log
@@ -0,0 +1,446 @@
+{% 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/i2p2www/meetings/32.log b/i2p2www/meetings/32.log
new file mode 100644
index 00000000..f4d4d013
--- /dev/null
+++ b/i2p2www/meetings/32.log
@@ -0,0 +1,307 @@
+{% 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/i2p2www/meetings/33.log b/i2p2www/meetings/33.log
new file mode 100644
index 00000000..307ce1d0
--- /dev/null
+++ b/i2p2www/meetings/33.log
@@ -0,0 +1,426 @@
+{% 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/i2p2www/meetings/34.log b/i2p2www/meetings/34.log
new file mode 100644
index 00000000..5810219c
--- /dev/null
+++ b/i2p2www/meetings/34.log
@@ -0,0 +1,136 @@
+{% 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/i2p2www/meetings/35.log b/i2p2www/meetings/35.log
new file mode 100644
index 00000000..9a4b50ef
--- /dev/null
+++ b/i2p2www/meetings/35.log
@@ -0,0 +1,208 @@
+{% 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/i2p2www/meetings/4.log b/i2p2www/meetings/4.log
new file mode 100644
index 00000000..ea20e22c
--- /dev/null
+++ b/i2p2www/meetings/4.log
@@ -0,0 +1,428 @@
+{% 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/i2p2www/meetings/47.log b/i2p2www/meetings/47.log
new file mode 100644
index 00000000..464a87a2
--- /dev/null
+++ b/i2p2www/meetings/47.log
@@ -0,0 +1,912 @@
+{% 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/
                
+	it's 21:13
                
+<--	wilde has quit (Ping timeout)
                
+---	Trent@anon.iip gives channel operator status to UserX
                
+	ok
                
+ !time
                
+	al-jebr: 00:21 here
                
+	I believe everyone has settled
                
+	Let's go. :)
                
+	11:06 here
                
+	let's start
                
+	anyone get my agenda
                
+	so they can play it back
                
+	I forgot the order
                
+<--	leenookx has quit (Ping timeout)
                
+	my clock is 15 minutes ahead :)
                
+-->	hifi (~MetroPipe@anon.iip) has joined #iip-dev
                
+	<nop> on the agenda
                
+	<nop> 1) Welcome
                
+	<nop> 2)Our Goodbyes
                
+	<nop> 3)IIP development now
                
+	<nop> 4) IIP development restructuring proposal
                
+ actually its xx:13 everywhere...
                
+	<nop> 5) Recruiting for services to aid with IIP
                
+	<-- Delly has quit (Ping timeout)
                
+	<nop> 6) comments suggestions and people who want to help
                
+	23:05:28 <@nop> 1) Welcome
                
+	23:05:38 <@nop> 2)Our Goodbyes
                
+	23:05:43 <@nop> 3)IIP development now
                
+	23:05:56 <@nop> 4) IIP development restructuring proposal
                
+	23:06:16 <@nop> 5) Recruiting for services to aid with IIP
                
+	23:06:53 <@nop> 6) comments suggestions and people who want to help
                
+	wow, flood in here ;)
                
+	pl
                
+ Out goodbyes?
                
+	lol
                
+	TROLLS !!!
                
+	Ok, welcome all
                
+	let's settle down now :)
                
+	.
                
+	settled
                
+-->	wilde (~anon@anon.iip) has joined #iip-dev
                
+	settled
                
+	anyone logging?
                
+-->	thecrypto (~thecrypto@anon.iip) has joined #iip-dev
                
+	I am (sort of).
                
+	mids should be.
                
+*	jrand0m logs at all times
                
+	let's go!
                
+	ok
                
+	nop: Agenda item number 2?
                
+	Our goodbyes
                
+ Bye!
                
+	where is the livelog?
                
+	Ok, mids has come to a point where he is moving to other projects
                
+-->	Phiberoptika (~none@anon.iip) has joined #iip-dev
                
+	After having worked for IIP for more than I year now, I have decided to
                
+	  resign as IIP developer.
                
+ Awww.
                
+	It has been fun and an educative experience
                
+	but it is time to move on, refresh the spirit and shuffle the cards.
                
+	Will you still be online/around?
                
+	I'll keep running Trent as long as needed and possible.
                
+	Yes, I do plan to stay around as user
                
+-->	ntk (~blob@anon.iip) has joined #iip-dev
                
+*	nop is in the corner sobbing
                
+	oh, ah hem
                
+	many thanks mids, iip w/out trent would be a pita
                
+ It's so sad.
                
+	yes
                
+	thank you mids for all your workup
                
+	work
                
+	Although I'll be off on vacation soon :)
                
+	.
                
+---	mids removes channel operator status from mids
                
+	:D
                
+	Seem's like you've done a great job.  :)
                
+	..how symbolic..
                
+	we love you mids!!!
                
+	you hear that
                
+	that was my window opening
                
+	we all do!
                
+	fan base out there
                
+-->	w (~w@anon.iip) has joined #iip-dev
                
+---	nop is now known as we
                
+	lol, yep.
                
+	:D
                
+*	we love you mids
                
+	Go mids go!
                
+	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!
                
+	weeeeee are the chaaaampins, my frieeeennnndd...
                
+	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.
                
+	yeah mids take your toys and go to tigertown lol
                
+	and don't forget the PR and web management
                
+	he's been a vital aspect to IIP
                
+	getting it this far would have been hard without his work
                
+-->	ChZEROHag (hag@anon.iip) has joined #iip-dev
                
+	hifi bitches with mids over trolling issue
                
+<--	hezekiah has quit (Ping timeout)
                
+	heh hifi
                
+-->	hezekiah (~hezekiah@anon.iip) has joined #iip-dev
                
+---	Trent@anon.iip gives channel operator status to hezekiah
                
+	Back. :)
                
+	Yay.
                
+	(And in case anyone doubted, Hezekiah == Ehud.)
                
+	i never used frucking trent and don't know what mids did . i only troll .
                
+	obviously your hezekiah@anon.iip gave it away
                
+<--	Ehud has quit (Ping timeout)
                
+	Ugh
                
+	Item number 3?
                
+	(If we're all done sobbing yet ...)
                
+	and i never was pingouted in my life . I am the most disciplined user of
                
+	  IIP .
                
+	3)IIP development now
                
+	heh
                
+	Ok everyone!  Shhh.  Back on track!
                
+	BUT I CRY that MIDS GO !!!
                
+	ok
                
+	.
                
+	IIP development.  Whats the current status of that code snapshot
                
+	  release?
                
+	That was supposed to happen today?
                
+	Well, unless UserX has an objection to the tarball I made,
                
+	  it's done.
                
+	Ok.  Post it on the wiki?
                
+	UserX? Were there any problems with the tarball?
                
+ no problems with the tarball
                
+	Yes, but are there any windows compilations?
                
+	OK1
                
+	http://invisiblenet.net/hezekiah
                
+	Get your tarballs there!
                
+ there hasn't been a windows compilation on the windows version yet
                
+	hm
                
+ "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!
                
+	They are.  For GCC.
                
+	lol
                
+	Sticky food.
                
+	There is one 'documented bug'.
                
+	I can compile a win32 version if you'd like
                
+	So, could you give a quick describtion of what is new in this release?
                
+	If you run isproxy, and it fails to bind the port, then it will
                
+	  /not/ abort. It will just sit there wasting memory.
                
+	Rain: That's too much for me to handle (not to mention I don't
                
+	  even _know_ all the differences).
                
+	this one I assume: iip-1.2-dev1.tar.bz2    01-Jul-2003 01:45
                
+	  292k  tar archive ?
                
+	UserX could give a much better description
                
+	UserX?
                
+	hezekiah/UserX can we get a changelog of the differences by chance
                
+	that may be a day before that gets done
                
+	Ambience: Yup! Or the Gziped one. There the same tarball.
                
+	because there are a log of changes
                
+	Oh, and has the expired IIP signing-key been replaced?
                
+	hezekiah: ok
                
+	nop: I joined IIP after the development branch was already in
                
+	  progress.
                
+-->	Ehud (~hezekiah@anon.iip) has joined #iip-dev
                
+	Rain: No. I had to use my GPG key.
                
+	no one has tested the compile of this dev branch in win32 have they?
                
+	Hey, is this src is CVS?
                
+	Rain: I couldn't contact anyone who had the IIP release key.
                
+	luckypunk: Yes.
                
+*	luckypunk has, but his system didn't work for it.
                
+	hezekiah: Ok, roger.
                
+ changes: multi-threading,  bignum support via openSSL or GMP, numerous
                
+	  inmprovements to the memory management system
                
+	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'.
                
+	Gah!  I hate windows.
                
+	UserX: niceties ;)
                
+	And of course there are other internal changes that only the
                
+	  developers see. :)
                
+ just as a question for the qurious... what defines the holder for "Trent"...
                
+	One simple thing is that now that BigNum is implemented using
                
+	  either GMP or SSL, login is a LOT faster.
                
+	May i mention a IIP quirk i noticed earlier today?
                
+*	luckypunk guesses its a yes.
                
+	at wiki search button is absent . only window to type in but nowhere to
                
+	  click lol .
                
+	hit enter.
                
+ and what about channel/nick expiration...
                
+---	Ehud is now known as logger
                
+ registration that is...
                
+	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
                
+	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
                
+	Is that intentional, or just some quirk of my local system?
                
+	hezekiah: yes.
                
+	Rain: You need to make a .iip subdirectory in your home directory.
                
+	It claims that the conf-file is not found.
                
+	with my .conf file?
                
+	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
                
+	Ahh. Of course.
                
+	OK ...
                
+	nop? Was there anything else for item 3?
                
+	have we tested it for win32
                
+	compile wise
                
+	I haven't.
                
+	UserX: ?
                
+ no
                
+	I will test it this week then
                
+	luckypunk, tried doing hezekiah-dev recently and complained for
                
+	  compile errors.
                
+	that's key to maintain portability
                
+	I suspect there might be problems.
                
+*	luckypunk tried, it balked.
                
+	Yup. There are problems.
                
+	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.
                
+	see ya guys!
                
+	later
                
+ bye
                
+	Bye, Ambience. :)
                
+	i'll be back.
                
+	<--gone (log on)
                
+	ok
                
+	this topic is done
                
+	next on agenda
                
+	what's 4?
                
+	4) IIP development restructuring proposal
                
+	ok
                
+	we had a meeting about a discussion and proposal brought to us by jrand0m
                
+	  for the future development
                
+	and as well
                
+	I have had a lot of privmessages directed at me
                
+	for requests to focus on an arbitrary framework, instead of IRC specific
                
+	aka a framework that supports IRC + a whole lot more
                
+	so the want is obviously there
                
+	and the developers definitely want to go there as well
                
+	Amen!
                
+	the question of how to go about doing it
                
+	and how to make the most productive use of our developers
                
+	is up in the air
                
+	XML
                
+	is his framework site available to everybody?
                
+	this isn't specifically about language
                
+	create a communications protocol
                
+	ok, please let me finish
                
+	I've started on that somewhere...
                
+	then we can comment
                
+	My apologies
                
+	I'm a bit in and out at the moment
                
+	ok,
                
+	no prob
                
+	We are at a stage where there is discussion of an arbitrary communications
                
+	  protocol
                
+	specifically for anonymous and secure communication
                
+	at this point jrand0m, any chance we can post the logs of #iip-future
                
+	  meeting
                
+	sure
                
+	perhaps those zips I sent you so people don't have to struggle
                
+	  through freenet for the other pages too
                
+	ok
                
+	hold
                
+	please
                
+	(btw, the logs were unedited, so expect the usual occational banter)
                
+	lol. Yup! You'll get to see exactly how much I DON'T know about
                
+	  p2p networks! lol
                
+	heh
                
+	(And they'll probably have my conspiracy theories about nop
                
+	  too! So be sure to read the logs! ;-) )
                
+<--	logger has quit (Ping timeout)
                
+	Ugh
                
+	ok
                
+	the logs will be a lot to read. can someone summarizze for the meeting
                
+	  what was covered and some key points of all this?
                
+	http://office.invisiblenet.net/iip_future.zip
                
+	and
                
+	At this point, the 'stable' release is being more unstable than
                
+	  the 'unstable' one!! Urg.
                
+	http://office.invisiblenet.net/meetingPrepnotes.zip
                
+	http://office.invisiblenet.net/jrand0mnetwork_protocol.txt
                
+	meetingPrepnotes.zip is a small doc that summarizes the meeting,
                
+	  and the meeting was basically "ok, any thoughts?".
                
+<--	Delly has quit (EOF From client)
                
+	essentially, the proposal is to get going on a generic secure
                
+	  anonymous message based system, and run iip on top of that
                
+	is there a zip with anonCommFramework too?
                
+	I didn't see that
                
+	jrand0m can you zip and send I'll post to site
                
+	sure, h/o
                
+<--	Phiberoptika has quit (* ciaito mua mua *)
                
+	what is anonCommFramework?
                
+	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?
                
+	if you're on freenet, anonCommFramework is at
                
+	  SSK@MQNd5lT-X5wHA4vONvtVadi6q1IPAgM/anonCommFramework/2//
                
+*	jrand0m is sending nop a zip of that momentarily
                
+	Did you discuss support for PGP-based nyms?
                
+	ah hem, this is early discussions
                
+<--	ChZEROHag has quit (Ping timeout)
                
+	no, endpoints in the framework are not nym based, they're idents
                
+	Right. So nyms an higher level.
                
+	are
                
+	(and for lots of reasons, they shouldn't be long term idents
                
+	  like nyms)
                
+	yes
                
+	I was just thinking of something like trent with PGP signarute auth.
                
+	trent is central
                
+	central=bad
                
+-->	logger (~hezekiah@anon.iip) has joined #iip-dev
                
+	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
                
+ what's the one sentence explanation of your ideas on network topology?
                
+-->	ChZEROHag (~hag@anon.iip) has joined #iip-dev
                
+	that was fun
                
+-->	Delly (dedede@anon.iip) has joined #iip-dev
                
+	mids: Yea. I meant similar services.
                
+	what about having to pay with hashcash to send data? couldn't
                
+	  that help against flooding?
                
+	wilde> heterogeneous.  no one answer solves all problems.
                
+	  interoperate, balancing latency, bandwidth, anonymity, and reliability to provide
                
+	  the user's needs
                
+ still in 4) ?
                
+	Delly: Yup
                
+ thx
                
+	I think when the ircd is removed from the equation, we'll have
                
+	  far better options than (hash|think|real)cash
                
+	jrand0m: any luck sending
                
+	;)
                
+	uploading to hush now.
                
+	ChZEROHag> anonCommFramework has built in support for providing
                
+	  network use authorization credentials
                
+	There has been a lot of talk of IIP-Freenet interoparability. Will that
                
+	  fit into the framework, or are we talking application-level again?
                
+	come again?
                
+	app level
                
+	what we're discussing is splitting iip into two parts - the irc
                
+	  part, and the message based secure anonymous network
                
+ one solution could be:
                
+	jrand0m: k.
                
+ Application <-> SOCKS5 Proxy Interface <-> Onion Wrapper <-> Onion Router
                
+	  1 <-> ... <-> Onion Router N <-> Exit Relay <-> Public Server
                
+	building a DHT on top of the message layer should be fairly easy
                
+	DHT?
                
+	distributed hash table
                
+	(ala freenet)
                
+	ok, jrand0m let me clarify
                
+	wilde: I think the plan is to design it such that the 'public
                
+	  server' could be removed from the equation at some point
                
+	are we talking about splitting irc, or merging to focus on anonymity
                
+	  framework
                
+	well, given unlimited # of developers, splitting and doing both
                
+	  (well, 3 things ;) in parallel.
                
+	what I mean is that the irc part is application layer
                
+	given reality, there's prolly only enough dev time to get the
                
+	  comm system running first, then iip on top
                
+	right exactly
                
+	and since we have a somewhat viable network working with IIP
                
+	irc is just another app running on it
                
+	then the idea should be
                
+	is to have developers start focusing on framework aspects
                
+ ChZEROHag: ok, what I suggested is an anonymizing layer for regular
                
+	  internet traffic, not a seperate network
                
+	(This could get fun.)
                
+	wilde there are weaknesses to that
                
+	just to let you know
                
+	aka the clear text on the outer ends
                
+<--	AmishOne has quit (EOF From client)
                
+ nop: yes, so all connections should be encrypted to the ends
                
+	we have an effort as well to have anonymous web browsing possible with
                
+	  this network
                
+	yes.  it must be able to operate without ever leaving the mixnet
                
+	but it is not as real time direct as your proposal wilde
                
+	it uses some time delay tactics
                
+	with caching etc
                
+	timing attacks are a serious threat to anonymity
                
+	I WANT ANONYMISER BASED on IIP !! I DON"t TRUST OTHER ANONYSERS THEY ARE
                
+	  FBI TRAPs !!
                
+	http://mids.student.utwente.nl/~mids/anonCommFramework/
                
+	hifi, this isn't changing IIP, this is moving us forward
                
+	thanks mids
                
+	heh word mids, my moz is hanging
                
+	ok
                
+ although independant mixnets are cool, the real killer apps will probably
                
+	  be general ip traffic anonymizers
                
+	wilde, they are myths
                
+ killer apps?
                
+	no
                
+<--	thetower has quit (EOF From client)
                
+	wilde> that could be a service built on top of the comm layer
                
+	general ip traffic anonymizers
                
+ or ip traffic anonymizers?
                
+	so far they don't exist
                
+	they exist in papers only
                
+-->	thetower (none@anon.iip) has joined #iip-dev
                
+	if you build an anonymizing service on top of the comm layer,
                
+	  however, your outbound routers will get shut down quickly
                
+	Haha, I just noticed I wasn't port forwarding.
                
+	Oop, sorry, wrong chan
                
+ nop: what about the ZKS system?
                
+	is it still around?
                
+	and working
                
+ nope, bad business
                
+ few people paid
                
+ but the framework seemed to work, but all nodes were ZKS:s paid relays
                
+	wilde but they were internal and it wasn't complete
                
+	it still had certain vulnerabilities
                
+	it was a start
                
+	I met Ian Goldberg at CodeCon 2k2, and he himself admitted it was incomplete
                
+	  to what he desired
                
+ yes, everything has vulnerabilities, we just raise the cost of tracing
                
+	  dramatically
                
+	right, after the mixnet is up and running, i'd like to see wilde
                
+	  offer generic outbound proxy services.	that'd be cool
                
+	(sincerely)
                
+	jrand0m: but again the ultimate would be using that magic mirror concept
                
+	  for optimum protection
                
+	Probably the hardest option, but wouldn't freenet be a good
                
+	  framework to build from?
                
+	wilde, maybe you and I can discuss this in another forum at some point
                
+	but in any case, the network must be built first
                
+	Or is that not what we're discussing?
                
+	ChZEROHag> no.
                
+	freenet doesn't provide hard anonymity
                
+	aah
                
+	I should try paying attention
                
+	ok, moving forward
                
+	UserX you still here
                
+ nop: yes, if you have decided on topology there is no need to discuss
                
+	  this in public
                
+ I'm still here
                
+	well it's application layer, so that comes after net design etc
                
+	ok
                
+	where did we leave off at #iip-future meeting
                
+<--	hezekiah has quit (Ping timeout)
                
+	let's start there
                
+---	logger is now known as Ehud
                
+*	nop is catching up on the meeting logs
                
+	[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.
                
+	[04:31] <jrand0m> the right way for the irc development to go is
                
+	  not for me to say
                
+	Basically, UserX had some thinking to do about wether IIP could run
                
+	  satisfactorily on the mixnet.
                
+	nite all
                
+<--	mids (mids@anon.iip) has left #iip-dev (mids)
                
+	Would it not be an idea to create a replacement irc in parallel
                
+	  with a mixnet?
                
+	After all it's going to be damn hard to use a normal ircd
                
+	ChZEROHag> given infinite # devs, yes
                
+	ok ChZEROHag silence please :)
                
+	Assume infinite devs
                
+	Oh is this not a question bit?
                
+-->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
                
+	not yet
                
+ Unfortuantlely I haven't had time to seriously sit down and think about
                
+	  how your proposal would fit in with IIP
                
+	oh
                
+	oops
                
+	just want to get into the discussion
                
+	well
                
+	UserX> think of the mixnet as a socket
                
+	let me suggest something
                
+	do we agree that our goal is not just IRC ?
                
+	well
                
+ it's a great idea sure
                
+	nop: Beyond all doubts, I agree that the goal is an anonymous
                
+	  network.
                
+	doing something traffic-intensive would have the potential to
                
+	  ruin the whole project
                
+	nop: IRC is just a starting point.
                
+	ok, well what we should look at is this
                
+	NOT doing something traffic intensive has the potential to get
                
+	  us to overlook problems :)
                
+	instead of saying IIP doesn't fit
                
+	or it does fit
                
+	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
                
+	jrand0m: hmm
                
+	for instance
                
+	UserX has a vision of using channels as endpoints
                
+	Jrand0m calls them idents
                
+	are they having subtle differences
                
+	or are they largely different
                
+	there's substance to those differences.
                
+	can we review that
                
+	on both sides
                
+	from jrand0m and UserX
                
+<--	hezekiah has quit (EOF From client)
                
+	actually
                
+	read the log
                
+	nevermind
                
+	;)
                
+-->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
                
+	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
                
+	how does it get plaintext?
                
+	instead, I'd suggest having a channel contain just the channel info
                
+	  (modes, users, topic, etc)
                
+	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
                
+	well
                
+	I had a proposal for that
                
+	that would have the channel not contain plaintext
                
+	directly
                
+	at least, without adding a channel key (which would be managed
                
+	  by the channel application itself, which defeats the point)
                
+	well
                
+	we were having channel keys
                
+	for private channels
                
+	and pub channels are public anyway
                
+	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
                
+	see the neat thing with message channels is this
                
+	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
                
+	I'm not sure you scale better, but you do redistribute the load
                
+	(we can find idents via O(log(n)))
                
+-->	sahara (~sahara@anon.iip) has joined #iip-dev
                
+	but thats neither here nor there, this is application layer
                
+	  design ;)
                
+	right
                
+	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
                
+ 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
                
+	did I miss the meeting?
                
+	you've got some ways that could work, it sounds like, right?
                
+	UserX> how does a user joining a channel get the key?
                
+	sahara: Nope. You're right in the middle of it! :)
                
+	it's a key exchange
                
+	with whom nop?
                
+	brand new user joining #anonymous, and the app containing the
                
+	  list of users on #anonymous doesn't have the key (As userx said)
                
+	(all I'm saying is there's a way to get all the functionality
                
+	  and still avoid having a channel key)
                
+ 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
                
+	'k, cool
                
+	so apps managing public channels can read the plaintext (by
                
+	  deriving from the channel name)
                
+	(which is prolly fine)
                
+	right
                
+ jrand0m: if the apps encrypt the plaintext to each recepient, will it
                
+	  scale well?
                
+	yes wilde, perhaps better (depending on the algorithm used to
                
+	  nominate channel managers)
                
+	(though it will potentially have a nonserialized delivery)
                
+	((though i think thats the case with normal irc anyway))
                
+<--	thecrypto has quit (Ping timeout)
                
+	but, getting back on to the question -
                
+	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
                
+	well
                
+<--	sahara has quit (EOF From client)
                
+	simple site , problem is i am tech blond but want good things lol
                
+	I was hoping that we could re-organize, but this is gonna be a discussion
                
+	  for later
                
+	sorry OOPS
                
+	UserX
                
+<--	d has quit (Client exiting)
                
+	how long will you need to think about certain aspects, and maybe doc them
                
+	  up as a concern list
                
+ hard to say. maybe a week
                
+	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
                
+	so let's push a week into this
                
+	and see what concerns are coming into play
                
+	because again
                
+	we want an adaptable mixnet
                
+	any application should be able to survive
                
+	absolutely
                
+	thats the point of the anon comm framework
                
+<--	wilde has quit ()
                
+	ok, so let's put this off a week, and focus on some realistic proposals
                
+	  that can fit all of our needs
                
+	you say "send message M to location L" and it magically, securely,
                
+	  anonymously gets delivered
                
+	but magic is one thing
                
+	science is another
                
+	of course you know that :)
                
+	the magic is from the app level's perspective ;)
                
+	yes
                
+	understood
                
+	the science is in that 15 page anonCommFramework/2// ;)
                
+	ok
                
+	lol
                
+	UserX, if you can get that in a week that would be helpful
                
+	?
                
+	I'll aim at revamping the docs & getting comm layer network design
                
+	  ready for then so we can hit the ground running
                
+	well
                
+	we haven't agreed on certain aspects
                
+	I think that still should be hashed out
                
+	what, in the network layer, haven't we agreed on?
                
+	personally I agree that maybe you post your anonCommFramework on iip-dev
                
+	and have it reviewed and commented
                
+*	jrand0m isn't on iip-dev
                
+	So, meeting again next tuesday, same bat-time, same bat-channel?
                
+	what haven't we agreed on is whether it can support all applications
                
+	jrand0m: Just post to iip-dev@invisiblenet.net .
                
+	Rain: We are on item #4. There are still other items to go. :)
                
+	its ~800k.  if someone could post the URL to mids' mirror that'd
                
+	  be cool
                
+ argh
                
+ re
                
+ 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
                
+	nop> I'm 100% certain it can support all applications.
                
+	hezekiah: Right. My missunderstanding.
                
+	this layer has been used for over a decade in hundreds of industries
                
+ was my thought of the day
                
+	well then where do we not agree
                
+	if Irc is an issue, then how is it adaptable?
                
+	it isn't an issue
                
+	y'all just don't understand the layer's abstraction ;)
                
+	Delly: i have a perl script that allows one to use ssh/telnet/etc
                
+	  over irc
                
+	(really, think of it as a socket)
                
+ lonelynerd, the goal was just to enhance mirc
                
+ for iip network
                
+	Delly: yeah, but if you use base64, i think it's compatible with
                
+	  this one
                
+ could be possible tu use it
                
+	ok, we ready for #5 yet?
                
+	nop?
                
+<--	hezekiah has quit (Client exiting)
                
+ oups i thought it was 5)  !
                
+	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
                
+	sorry
                
+	delly
                
+	you guys
                
+	this is off topic
                
+	please reserve your conversation outside this channel
                
+-->	hezekiah_ (~hezekiah@anon.iip) has joined #iip-dev
                
+<--	hezekiah has quit (EOF From client)
                
+	well
                
+	jrand0m
                
+---	hezekiah_ is now known as hezekiah
                
+	before I agree to go to 5
                
+	the problem I'm seeing is
                
+	UserX has a voice
                
+	as well
                
+---	Trent@anon.iip gives channel operator status to hezekiah
                
+	of course
                
+	and if he sees logistical problems
                
+	I believe they should be heard
                
+	so you can't just say, hey it's gonna work
                
+	it has to be "solidly" agreed on both ends
                
+	aka he needs convincing
                
+	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
                
+	or he needs to convine you
                
+	but the idea is this
                
+	what I'm trying to propose with this
                
+	is to reorganize our dev team to get on your bandwagon
                
+	with that
                
+	it would put our energy in working on the network design
                
+	that's the idea
                
+	thus helping all of us get somewhere specific
                
+	I'm not trying to slow down
                
+	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
                
+	ok
                
+	so can we post your proposal to iip-dev
                
+	and get some review
                
+	coo'
                
+	also I advise on your own to propose it on cryptography@metzdowd.com
                
+	which will get some serious review
                
+	sounds good
                
+	ok
                
+	UserX, you there
                
+ i'm here
                
+	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?
                
+ yes
                
+	ok, let's resume this in a week
                
+	what was 5?
                
+	sorry If I'm being a pain
                
+	just want to organize it
                
+	to make sure we're all on same page
                
+	recruiting for services...?
                
+	5) Recruiting for services to aid with IIP
                
+	ok
                
+	yes
                
+	since mids departure
                
+	and cohesions return
                
+	we are possibly looking for others to contribute to IIP in some aspect
                
+	this does not mean you have to be a hardcore core developer
                
+	but additives like maybe a web maintainer would be good,
                
+	some PR would be good
                
+	luckypunk volunteered to manage the website.
                
+	<luckypunk> I wanna help/take over the IIP website.
                
+	<luckypunk> :D
                
+	and if more people would like to hop on with the upcoming project that
                
+	  jrand0m is proposing
                
+	wikked
                
+	even if you just want to review the protocol
                
+	that is more than enough help
                
+	the reality is this
                
+	we have a lot of developers with real time jobs
                
+	and it is consuming them at the moment
                
+	and any additional help is wanted
                
+	since this is a huge endeavor
                
+	to take IIP to where it needs to be
                
+	aka InvisibleNet at some point
                
+	real life jobs ;)
                
+	anyway
                
+	the idea is
                
+	it would be cool if people would love to add to this project in some ways
                
+	using their skills, and I know their are some programmers out there
                
+	and a few that have some spare tiem
                
+	time
                
+	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
                
+	nop: I can understand that one. ;-)
                
+	nop: He just asked me to forward the offer along because he
                
+	  wouldn't be here.
                
+	ok
                
+	nop: I did. My part's done. :)
                
+	well, either way, anyone who wants to join in
                
+	contact one of us
                
+	either at iip@invisiblenet.net
                
+	One of whom?
                
+	or just by nick,
                
+	hezekiah, userx, nop,
                
+	I hear anyone who volutneers to help iip gets free hookers and blow
                
+	What are 'hookers and blow'?
                
+	... or do I not want to know?
                
+	heh
                
+	hezekiah: don't ask
                
+	OK.
                
+	I don't want to know. :)
                
+	hezekiah: enjoy your sheltered life ;)
                
+	while you can
                
+	cuz college is gonna be fun :)
                
+	I'm enjoying it! I'm enjoying it!
                
+*	jrand0m enjoys the hookers and blow ;)
                
+	jrand0m: quick question
                
+*	w hugs luckypunk and nop
                
+	si sr?
                
+	jrand0m: are you considering yourself a dev of IIP at some time soon?
                
+	since you are offering a merge ;)
                
+
                
+	  http://www.guerrillanews.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=gnn&Number=182767&page=0&view=collapsed&sb=5&o=0&part=
                
+	sorry , opps again
                
+	nop> a dev of invisiblenet, but I can't contribute to iip
                
+	understood
                
+	IIP == invisiblenet future projects
                
+	jrand0m: Good working!
                
+	jrand0m: Wording.
                
+	devs wanted for either
                
+	to make that clear
                
+	specifically cuz jrand0m could use a good team set
                
+ I could take a look of the Windows code...
                
+	si sr.	once we get rolling into software design, there's going
                
+	  to be more truckloads of work than one can imagine
                
+	word Addic
                
+	awesome
                
+	ok
                
+	I will send this request on iip-dev line as well
                
+	anyone interested please don't hesitate to contact
                
+	was there a 6?
                
+	I believe so
                
+	6) comments suggestions and people who want to help
                
+	suggestion: < 1.8 hours next time :)
                
+	(not that any of the topics could have been condensed any more
                
+	  than they were)
                
+	no comments?
                
+*	nop thinks everyone's asleep
                
+	hehe
                
+	we bored them
                
+	w3wt
                
+ heh, who has been working on the Windows' code this far?
                
+	ok
                
+	zzzzzz...
                
+	UserX has made it so far portable
                
+	What kind of talents are we looking for?
                
+ ok
                
+	ok, let me re-iterate
                
+	Coders, Graphics dudes, Web devs, PR people, Web maintainers
                
+	Ok, missed that. Sry.
                
+	and if you can write biz plans, that helps me too :)
                
+	you didn't miss
                
+	I didn't go in enough detail
                
+	heh
                
+<--	Ehud has quit (EOF From client)
                
+	I am Born PR people
                
+	Step one: Collect Underpants.
                
+ translating to other languages at wiki?
                
+	yes
                
+	that would be great
                
+	translations
                
+ ok, i could do that too
                
+	documentation
                
+	etc
                
+<--	hezekiah has quit (Ping timeout)
                
+	even organization
                
+	anyone who wants to be actively involved in helping InvisibelNet/IIP
                
+	I invite ppl to use IIP alll the time
                
+	thnx hifi
                
+-->	hezekiah (hezekiah@anon.iip) has joined #iip-dev
                
+	What kind of org skills?
                
+	well, maybe help run the meetings, or maybe forcing us dev guys to get
                
+	  more docs on the protocol
                
+	etc
                
+	possibly organize interviews and some type of press releases
                
+	some ideas for the future of promoting the use of IIP
                
+	etc
                
+	ok, please contact one of us if you want to help out
                
+	Ok, org question, that I have mentioned before: IIP Signing key? (nag, nag)
                
+-->	Ehud (~hezekiah@anon.iip) has joined #iip-dev
                
+	IIP notification service :) for ppl to knoe I /him is online LOL
                
+ just as a question for the qurious... what defines the holder for "Trent"...
                
+ and what about channel/nick expiration...
                
+ registration that is...
                
+<--	ChZEROHag has quit (Ping timeout)
                
+	trent is a service, not a nick, so trent must have access to the
                
+	  ircd (i think)
                
+	these questions are mids questions for trent, he's an abstract piece
                
+	yes jrand0m
                
+	iip notification would be cool.  how does anonymail do it?
                
+	can clients send a /notify nick to the server and get a msg when
                
+	  the nick joins?
                
+	IIP SMS notification LOL
                
+	actually
                
+	we did have IIP SMS as the first version of anonymail
                
+	but it tended to flood
                
+	oh
                
+	so now we do it as anonymail database delivery
                
+	IIP invitation msg as signature to ordinary e-mails ...
                
+	Kinda " Do yo Yahoo ? Get MSN free " stuff
                
+	ooOOoo textAds
                
+	but does iip need more users?
                
+	oh
                
+	or is getting more users just a "oh cool, lets service more people"?
                
+	no
                
+	dunno
                
+	i just brainstorm
                
+<--	Mira has quit (Ping timeout)
                
+	More people ... more ideas ... more volunteers
                
+	IIP as world standart will be cool
                
+	More people ... more problems ... more strain on the network ...
                
+	... more floods of #anonymous ...
                
+	It's a two sided question.
                
+	more channels lol
                
+-->	Mira (~Mira@anon.iip) has joined #iip-dev
                
+	IIP Eugenics Program LOL Less Population Less Problems
                
+-->	ChZEROHag (~hag@anon.iip) has joined #iip-dev
                
+ hmm... going back to the notification question... is it so the /notify
                
+	  nick does not work here? Or am I not understanding the question...
                
+	Addic: sure it works
                
+ well what's the problem then?
                
+	?
                
+<--	Delly has quit (EOF From client)
                
+	wasn't much following the conversation, but they talked about
                
+	  having a /notify that wouldn't require the client to poll
                
+ ok
                
+<--	ChZEROHag has quit (Ping timeout)
                
+<--	w has quit (Ping timeout)
                
+<--	Rain has quit (I Quit)
                
+-->	w (~w@anon.iip) has joined #iip-dev
                
+	Hmmm ...
                
+	I think it's about time we adjurne this meeting.
                
+	What do you say, nop?
                
+*	jrand0m thinks he fell asleep too
                
+	yeah
                
+	ok
                
+	later
                
+<--	jrand0m (jrandom@anon.iip) has left #iip-dev (jrand0m)
                
+	Meeting adjurned! :)
                
+	*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/i2p2www/meetings/49.log b/i2p2www/meetings/49.log
new file mode 100644
index 00000000..68573bff
--- /dev/null
+++ b/i2p2www/meetings/49.log
@@ -0,0 +1,746 @@
+{% 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/i2p2www/meetings/50.log b/i2p2www/meetings/50.log
new file mode 100644
index 00000000..4b74dce0
--- /dev/null
+++ b/i2p2www/meetings/50.log
@@ -0,0 +1,597 @@
+{% 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/i2p2www/meetings/51.log b/i2p2www/meetings/51.log
new file mode 100644
index 00000000..c0143226
--- /dev/null
+++ b/i2p2www/meetings/51.log
@@ -0,0 +1,886 @@
+{% 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/i2p2www/meetings/52.log b/i2p2www/meetings/52.log
new file mode 100644
index 00000000..19f599ca
--- /dev/null
+++ b/i2p2www/meetings/52.log
@@ -0,0 +1,381 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 52{% endblock %}
+{% block content %}
                
+	ok, meeting started
                
+	what's on the agenda
                
+-->	logger (logger@anon.iip) has joined #iip-dev
                
+-->	Anon02 (~anon@anon.iip) has joined #iip-dev
                
+	Tue Aug  5 21:03:10 UTC 2003
                
+	Welcome to the Nth iip-dev meeting.
                
+	What's on the agenda?
                
+	Tue Aug  5 21:02:44 UTC 2003
                
+	synced to a NTP stratum 2 :)
                
+	Tue Aug  5 21:03:13 UTC 2003
                
+-->	ptm (~ptm@anon.iip) has joined #iip-dev
                
+	Just synced to NIST. :)
                
+	this sync does not help w/ iip delays ;)
                
+	nop: things I want to see covered: java dev status, java crypto
                
+	  status, python dev status, sdk status, naming service
                
+	(We're going into the naming service _already_?)
                
+	not design you wanker, thats co's schpeel.  just talk about stuff
                
+	  if there's stuff to talk about.
                
+	Ah
                
+*	jrand0m puts LART away
                
+	anything else on the agenda?
                
+	or shall we dig in?
                
+	Well, I can't think of anything else to add.
                
+	Ah!
                
+	Oh!
                
+	ok.  java dev status:
                
+	Good.
                
+<--	mrflibble has quit (Ping timeout)
                
+	ok
                
+	agenda
                
+	1) Welcome
                
+	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.
                
+	2) IIP 1.1 blackouts
                
+	3) I2P
                
+	4) The End with comments and stuff
                
+*	jrand0m goes back to corner
                
+	sorry
                
+	  joeyo jrand0m Aug 05 17:08:24 * hezekiah gives jrand0m a dunce hat to wear in
                
+	  the corner. ;-)
                
+	sorry about that
                
+	didn't see you started there
                
+	maybe I should go in corner
                
+	lol
                
+	no worry.  item 1)
                
+*	hezekiah hands nop a dunce hat too. :)
                
+	ok welcome everybuddy
                
+	blah blah
                
+	2) IIP 1.1 blackouts
                
+-->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
                
+	52nd iip-dev meeting and all that good rot!
                
+	the server recently had some issues with the hard drive sectors and has
                
+	  been replaced
                
+	I plan to be moving the darn server into a more stable environment with
                
+	  redundancy
                
+	and possibly lend out control of multiple ircd servers
                
+	dunno
                
+	that's something to be discussed
                
+<--	Anon02 has quit (EOF From client)
                
+	hopefully our servers should stay up now since the harddrive was replaced
                
+	sorry about the inconvenience folks
                
+	3) I2P - Jrand0m take it away
                
+	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
                
+	lol!
                
+	sorry, back
                
+*	nop grabs dunce hat from hezekiah
                
+*	nop puts it on his head
                
+*	nop applauds for jrand0m
                
+*	jrand0m just watches the show
                
+	er... um ok
                
+	jrand0m: i2p, java status, etc. Talk man!
                
+	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.
                
+	File transfer already!?
                
+	si sr
                
+	Wow.
                
+	I'm sure behind the times.
                
+	but not the most graceful
                
+	lol
                
+	it takes a file and tosses it in a message
                
+	Ouch.
                
+	how long did 1.8 mb local transfer take?
                
+	I've tested with a 4K file and a 1.8Mb file
                
+	a few seconds
                
+	nice
                
+	:)
                
+	Does the java stuff do real encryption yet, or does it still
                
+	  fake that?
                
+	fake
                
+	even I know that
                
+	:)
                
+	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
                
+	right, its faked largely
                
+	most of the encryption is fake
                
+	that's being worked on though
                
+	Of course. :)
                
+	definitely.
                
+	on that front, wanna give us an update thecrypto?
                
+	well, right now i'm done with ElGamal and SHA256
                
+	right now I'm working on generating primes for DSA
                
+	I'll send out 5 and then we can just pick one
                
+	nop: Didn't you have prime(s) coming for use with DSA?
                
+	We also have some benchmarks on ElGamal and SHA256
                
+	And they are all fast
                
+	latest benchmarks w/ elg:
                
+	Key Generation Time Average: 4437	total: 443759	min:
                
+	  872	   max: 21110	   Keygen/second: 0
                
+	Encryption Time Average    : 356	total: 35657	min:
                
+	  431	   max: 611	   Encryption Bps: 179
                
+	Decryption Time Average    : 983	total: 98347	min:
                
+	  881	   max: 2143	   Decryption Bps: 65
                
+
+	min and max: are they in seconds?
                
+	note that the Bps isn't really useful, as we only encrypt/decrypt
                
+	  64 bytes
                
+	ms
                
+	no, sorry, those are all milliseconds
                
+	Cool. :)
                
+	And this is done in java?
                
+	yes
                
+	pure java
                
+	OK. I am officiall impressed. :)
                
+	100%.  P4 1.8
                
+	they are about the same on my 800 Mhz
                
+	How can I do the same tests?
                
+	sha256 benchmark:
                
+	Short Message Time Average  : 0 total: 0	min: 0	max:
                
+	  0  Bps: NaN
                
+	Medium Message Time Average : 1 total: 130	min: 0	max:
                
+	  10 Bps: 7876923
                
+	Long Message Time Average   : 146	total: 14641	min:
                
+	  130	   max: 270	   Bps: 83037
                
+	run the ElGamalBench program
                
+	OK.
                
+	I'll go find it.
                
+	(short size: ~10 bytes, medium ~10KB, long ~ 1MB)
                
+	java -cp i2p.jar ElGamalBench
                
+	(after running "ant all")
                
+	jrand0m: Thanks. :)
                
+	np
                
+	The NaN thing means it's so fast that we end up dividing by 0
                
+	  it's so fast :)
                
+	What's the sha bench?
                
+	java -cp i2p.jar SHA256Bench
                
+-->	Neo (anon@anon.iip) has joined #iip-dev
                
+	OK.
                
+	we'll probably want to move those to be main() methods of the
                
+	  associated engines, but they're good where they are atm
                
+	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.)
                
+	heh
                
+	ok so we have DSA and AES left, right?
                
+	this is all wikked thecrypto.  nice work.
                
+	yup
                
+	can I nag you for an ETA on the other two?  ;)
                
+	If this is anywhere near as fast on my box as it is on yours,
                
+	  you have to show me how you do that. ;-)
                
+	DSA should be done almost as soon as i have primes ready
                
+	hezekiah have you tried the sslcrypto for python
                
+	copying some code around from the prime generator and things like
                
+	  that and it's done
                
+	the one off that link
                
+	nop: sslcrypto won't do us any good.
                
+	nop: It doesn't implment ElGamal _or_ AES _or_ sha256.
                
+	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
                
+	thecrypto> so by friday, DSA keygen, sign, verify, and AES encrypt,
                
+	  decrypt for arbitrary size inputs?
                
+	the one on McNab's site does not?
                
+	yeah
                
+	darn
                
+	should be friday
                
+	most likey thursday
                
+	thecrypto> does that include the UnsignedBigInteger stuff?
                
+	i'll be missing next weeks meeting because of summer camp, and
                
+	  i'll be back after that
                
+	jrand0m: prolly not
                
+	ok.
                
+	so for the time being, interoperability between java and python
                
+	  is b0rked.
                
+	for crypto, that is.
                
+---	Notify: jeremiah is online (anon.iip).
                
+-->	jeremiah (~chatzilla@anon.iip) has joined #iip-dev
                
+	(aka for signatures, keys, encryption, and decryption)
                
+
+	hmm maybe we should focus more on C/C++
                
+	well, once we get it working completely we can then make sure
                
+	  both java and python can speak to each other
                
+	while you're out I'll look into the unsigned stuff.
                
+	can someone email me a backlog? jeremiah@kingprimate.com
                
+	jeremiah: Give me a minute. :)
                
+	nop> do we have devs for C/C++?
                
+	I have one guy yes
                
+	and Hezekiah we know could do it
                
+	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
                
+	right, of course.  but hez+jeremiah are working on python atm
                
+	  (right?)
                
+	Yeah.
                
+<--	mrflibble has quit (Ping timeout)
                
+	I'm sort of giving poor jeremiah lots of trouble.
                
+	I was just saying if python won't be fast speeds
                
+	Python is mainly for me to understand this network.
                
+	ahh
                
+	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.
                
+	It's not meant to be a killer implementation of the spec.
                
+	(If I wanted that, I'd use C++.)
                
+	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?
                
+	sure jeremiah.	all depends on the app
                
+-->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
                
+	jeremiah: In theory.
                
+	so where are we on the python side?  client api, local only
                
+	  router, etc?
                
+	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
                
+	jrand0m: OK. Here's what I've got.
                
+	In _theory_ the router should be able to handle all non-admin
                
+	  messages from a client.
                
+	However, I don't have client yet, so I haven't been able to debug
                
+	  it (i.e. there are still bugs.)
                
+	I'm working on the client right now.
                
+	'k.  if you can disable signature verification, we should be able
                
+	  to run the java client against it now
                
+	I'm hoping to have that done except for admin messages in a day
                
+	  or two.
                
+	we can test that out after the meeting
                
+	jrand0m: OK.
                
+	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
                
+	cool
                
+	jeremiah: You know what, just wait.
                
+	jeremiah: I'm probably throwing in too much new stuff for you to
                
+	  deal with right now.
                
+	hezekiah: right, what I was going to say is that you should
                
+	  probably just go ahead and implement the base stuff
                
+	jeremiah: In a little while, it will be stabalized and you can
                
+	  start refining it. (There are lots of TODO comments that need help.)
                
+	and then I can extend it later once I get the picture
                
+	Exactly.
                
+	You get to maintain all this code. :)
                
+	cool.  so eta 1-2 weeks for a working python router + client api?
                
+	I'm going on vacation next week so probably.
                
+	Are we going to have more details on router to router soon?
                
+	no.
                
+	well, yes.
                
+	but no.
                
+	lol
                
+	hezekiah: how long is the vacation?
                
+	1 week.
                
+	ok
                
+	(aka as soon as the SDK goes out, 100% of my time goes into I2NP)
                
+	I'm hoping to have all non-admin functionality written before I
                
+	  go on vacation
                
+	.
                
+	but then soon after you get back you're off to college, right?
                
+	I2NP?
                
+	Right.
                
+	network proto
                
+	I have about 1 week after vacation.
                
+	Then I'm gone.
                
+	And my free time drops like a stone.
                
+	so that 1 week should only be debugging
                
+	I can work on the code while hez is gone though
                
+	word
                
+	whats your summer look like jeremiah?
                
+	jeremiah: Perhaps you can get those admin functions working?
                
+
+	i'll still have a month after i come back from my vaction to work
                
+	  on things
                
+	having a life, or being like the rest of us l00sers?  :)
                
+	maybe
                
+	100sers?
                
+	What's a 100ser?
                
+	i leave for college on the 22nd, other than that I can dev
                
+	hezekiah: a loser
                
+	and the last week before I leave all my friends will be gone... so
                
+	  I can go into hyperdev mode
                
+	mihi: Ah!
                
+	hehe
                
+	OK. So where were we on the agenda?
                
+	i.e. What's next?
                
+	sdk status
                
+	sdk == one client impl, a local only router impl, an app, and docs.
                
+	I'd like to have that out by next tuesday.
                
+	jeremiah: That backlog is on the way. Sorry I forgot you there. :)
                
+	thanks
                
+	ok, co isn't around, so the naming service stuff is prolly a bit
                
+	  off base
                
+	we can discuss the naming service after he puts out specs or
                
+	  he's around
                
+	ok, thats it for I2P stuff
                
+	anyone else have I2P stuff, or we on to: <nop> 4) The End with
                
+	  comments and stuff
                
+	I can't think of anything.
                
+	I assume everyone's seen
                
+	  http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html ?
                
+	not here
                
+	(nop posted it here earlier)
                
+	The thing about the guy who got arrested for linking to a bomb
                
+	  building site?
                
+	yes
                
+	relevence to the need to get I2P up ASAP should be aparent ;)
                
+	OK! jeremiah, those logs are now sent.
                
+	thanks
                
+	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)
                
+	damn y'all are quiet today ;)
                
+	question:
                
+	where can non devs get yout java code?
                
+	si sr?
                
+	not yet
                
+	404
                
+	that'll be made available once we're release ready.  aka the
                
+	  source will go out with the SDK
                
+	heh
                
+	yeah, we don't use SF
                
+	nop: Is it possible that we can get anonymous cvs working some tiem?
                
+	time?
                
+<--	mrflibble has quit (Ping timeout)
                
+	well, I would open up a non-standard port
                
+	hezekiah> we'll have that once the code has the GPL license on there
                
+	but I am working on viewcvs
                
+	aka not now since the gpl doc hasn't been added to the code yet
                
+	jrand0m: It's in all the python code directories and all python
                
+	  source files speceify licensing under GPL-2.
                
+	hezekiah> is that on the cathedral?
                
+	Yes.
                
+	ah word.  i2p/core/code/python ?  or a different module?
                
+*	jrand0m hasn't seen it in there
                
+	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
                
+	It's i2p/router/python and i2p/api/python
                
+	'k
                
+	so, yeah, by next tuesday we'll have the SDK + public source access.
                
+	Cool.
                
+	Or as you like to say, wikked. ;-)
                
+	heh
                
+	nada mas?
                
+	nada mas? What's that mean!?
                
+	nothing more
                
+*	jrand0m suggests you learn a lil espanol en universidad
                
+-->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
                
+	Questions anyone?
                
+	Going once!
                
+<--	ptm (~ptm@anon.iip) has left #iip-dev (ptm)
                
+	Going twice!
                
+<--	mrflibble has quit (mr. flibble says "game over boys")
                
+	Speak now .. or wait until you feel like speaking later!
                
+	okay, i'm going to be optimizing the elgamal even more, so expect
                
+	  even faster elgamal benches in the future
                
+	please focus on DSA and AES before tuning... puhleeeease :)
                
+	i will
                
+	The reason he's doing that is 'cause I'm causing trouble for
                
+	  people again. ;-)
                
+	i'm making DSA primes
                
+-->	mrflibble (mrflibble@anon.iip) has joined #iip-dev
                
+	well, at least making the program to make DSA primes right now
                
+	ElGamal in Java doesn't like an AMD K-6 II 333MHz.
                
+	OK.
                
+	Question round is over!
                
+	ok hez, we're done.  you wanna powow on getting the java client
                
+	  and the python router work?
                
+	See you all next week citizens!
                
+*	hezekiah smashes down the *baf*er
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/53.log b/i2p2www/meetings/53.log
new file mode 100644
index 00000000..28d964c1
--- /dev/null
+++ b/i2p2www/meetings/53.log
@@ -0,0 +1,113 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 53{% endblock %}
+{% block content %}
                
+[21:09]  ok.  21:00 UTC esta ahora
                
+[21:09]  welcome to the um meeting
                
+[21:09]  we have a lot of people out today (nop, hezekiah, thecrypto, and userx), so we'll keep it brief
                
+[21:10]  agenda: 1) hi 2) sdk 3) status 4) questions
                
+[21:10]  1) hi
                
+[21:10]  hello.
                
+[21:10]  2) sdk
                
+[21:11]  the I2P SDK 0.1 is ready for quiet release.  
                
+[21:11]  quiet release?
                
+[21:11]  basically we're not publicizing it except for people in the know, and those trusted by people in the know
                
+[21:12]  it is however fully ready to do application design, development, and testing with
                
+[21:12]  If you're on #iip-dev, you're in the know
                
+[21:13]  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]  hey, its UserX
                
+[21:14]  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]  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]  september that never ended? ;)
                
+[21:16]  (rather than having the network up and running with no applications)
                
+[21:16]  heh
                
+[21:16]  no, we're actually beating the schedule I posted to iip-dev a few weeks back in the ganttproject document
                
+[21:16]  not by much (5 days), but beating it none the less.
                
+[21:17]  I'm quite confident that we'll be 1.0alpha in september.
                
+[21:17]  Also, for status, I suspect that there will be a new I2NP (network proto) draft out by the end of the week.
                
+[21:18]  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]  'lo shardy
                
+[21:18]  hiya.
                
+[21:18]  how goes?
                
+[21:19]  wikked.  
                
+[21:19]  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]  .net? nope, that's not me...
                
+[21:21]  ah 'k, my bad
                
+[21:21]  soy muy tonto
                
+[21:21]  well, hi anyway :)
                
+[21:21]  I also got some feedback from co wrt the naming service application
                
+[21:22] * ion has joined #iip-dev
                
+[21:22]  "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]  1. Client program to interact with naming service.
                
+[21:22]  2. Program for the naming service itself.
                
+[21:22]  3. Administrative utilities for the naming service.
                
+[21:22]  4. A Certificate Authority (CA) component."
                
+[21:23]  That's co's status report
                
+[21:23]  I think that may be it for status, unless someone has something to add.
                
+[21:24]  neat.
                
+[21:24]  definitely neat
                
+[21:24]  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]  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]  I'll be posting a new version probably on friday.
                
+[21:25]  (and as this project only began in earnest maybe a month ago, we're open for variations in how we work)
                
+[21:26]  oh wait, now I remember, you're the ecc guy :)
                
+[21:26]  yep, that's me. although I haven't really done much with ecc in a while... I'm now the prng guy.
                
+[21:27]  oh nice.  we're currently using generic prngs, and will want a better way to deal with random data
                
+[21:27]  ok
                
+[21:27]  generic ones? nop mentioned using yarrow, which seems pretty good.
                
+[21:28]  I'm doing implementation work on a new prng now. trying to reduce the theory and practice gap somewhat. :)
                
+[21:28]  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]  heh
                
+[21:29]  be careful w/ yarrow from freenet, it does heisenbugs ;)
                
+[21:29]  lol
                
+[21:29]  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]  shite.  I inserted it a dozen times at htl 25
                
+[21:30]  I'll reinsert it yet again
                
+[21:32]  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]  heh
                
+[21:33]  who puts the log onto the wiki this time? /me has it completely this time.
                
+[21:33]  awesome, go for it
                
+[21:34]  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]  your java sux, jrandom ;) (HHOK)
                
+[21:35]  thats more like it
                
+[21:35]  I'm reinserting the .zip from freenet's CLI, so it'll probably have a different CHK
                
+[21:36]  I'll msg people with it after I reinsert it a few times
                
+[21:36]  mihi wants it.  anyone else I should msg?
                
+[21:36]  (or anyone can ask at another time, as well)
                
+[21:36]  you could mail it to me...
                
+[21:36]  1.1Mb
                
+[21:37]  if it is not *too* large.
                
+[21:37]  erm, okay then not.
                
+[21:37] * mihi is not kind on fetching splitfiles anyway
                
+[21:37]  s/kind/keen/
                
+[21:37]  heh, are you going to suggest I insert it without FEC?
                
+[21:38]  i guess it won't have any chance in current freenet.
                
+[21:38]  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]  just put it on some webspace and put some gpg conventional encryption around it - and tell the passphrase here.
                
+[21:40]  or use the key mentioned above as passphrase
                
+[21:40]  btw - shall i strip that one from the log?
                
+[21:41]  no need to.  I'm paranoid enough to believe if its said here, its available to those who want to see it ;)
                
+[21:41]  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]  thx. "this evening" regarding which time zone? (me will go to bea in about 1 hour)
                
+[21:43]  s/bea/bed
                
+[21:46]  heh, evening for nop, which is california
                
+[21:46]  ok, I've got to jet.  
                
+[21:46] * jrand0m !thwaps meeting to an end
                
+[21:46]  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]  2 blocks downloading above url
                
+[21:48]  nice
                
+[21:48] * shardy has joined #iip-dev
                
+[21:48] * mihi drops dead.
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/54.log b/i2p2www/meetings/54.log
new file mode 100644
index 00000000..e9ba7ffe
--- /dev/null
+++ b/i2p2www/meetings/54.log
@@ -0,0 +1,441 @@
+{% 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/i2p2www/meetings/55.log b/i2p2www/meetings/55.log
new file mode 100644
index 00000000..6a88781d
--- /dev/null
+++ b/i2p2www/meetings/55.log
@@ -0,0 +1,214 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 55{% endblock %}
+{% block content %}
                
+[23:00]  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]  is x == 0 or 1 or 2? 
                
+[23:00]  22/7
                
+[23:01]  i think it's 0
                
+[23:01] * jrand0m always logs, so wtf, why not.
                
+[23:01]  0.0: welcome. 
                
+[23:01]  hi. 
                
+[23:01]  0.1: spec questions 
                
+[23:01]  anyone read the specs?  :) 
                
+[23:02] * mihi did. at least tried to
                
+[23:02]  w0ah word 
                
+[23:02]  nope
                
+[23:02]  what are the new ones?
                
+[23:02]  occasionally
                
+[23:02]  mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck? 
                
+[23:03]  i'm just not familiar enough with crypto. the first part was very interesting.
                
+[23:03]  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]  but when it got into detaily, you could have described how to brew an irish stew and i would not hav noticed ;)
                
+[23:04]  sweet
                
+[23:04]  lol mihi 
                
+[23:05]  although the format had its problems as well -don't have open office here, just ol' staroffice 5.2
                
+[23:05]  does star office 5.2 not read it?  would you prefer .pdf or kludged html? 
                
+[23:05]  (or .txt?  though txt wouldn't have pics or real formatting) 
                
+[23:05]  i'd prefer "old" .sdw format.
                
+[23:05]  pdf if at all possible
                
+[23:05]  or pdf
                
+[23:06]  pdf is a one click solution. 
                
+[23:06] * jrand0m edits in open office, reads in pdf
                
+[23:06]  or appleworks
                
+[23:06]  ;)
                
+[23:06]  sxw is supported only in staroffice 6.0 and above
                
+[23:06]  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]  (or maybe .doc if i'm feeling dirty) 
                
+[23:07]  i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either...
                
+[23:07]  s/bzw/bz2/
                
+[23:07]  heh, zipped up, for sure. 
                
+[23:08]  the data structures spec may require a mod, and the network proto requires some fixed urls before release. 
                
+[23:08]  anyone have any questions on any of the four specs? 
                
+[23:09]  not at the momemet
                
+[23:10]  ok.  0.2: elg issues 
                
+[23:10]  we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec. 
                
+[23:11]  it may be key related, algorithm related, or implementation related.  probably not implementation related, as this has been tested against two implementations. 
                
+[23:11]  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]  if its implementation or key generation related, we can publish the spec and fix the sdk when resolved. 
                
+[23:13]  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]  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]  'k 
                
+[23:15] *** mihi_ is now known as mihi
                
+[23:15]  i have to run some math and through some other implementation and figure it out
                
+[23:15]  i never had a problem with elgamal
                
+[23:15]  last time i tested
                
+[23:16] *** Signoff: mihi ((null))
                
+[23:17]  with that benchmark
                
+[23:17]  right, but the benchmark only tried one key 
                
+[23:17]  ahh
                
+[23:17]  i can quite repeatedly get the error without any mods to the elg impl 
                
+[23:17]  didn't we have a wrong key message that came up?
                
+[23:18]  yes, those still come up 
                
+[23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
                
+[23:18]  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]  and we still get bad keys?
                
+[23:19]  or something. 
                
+[23:19]  all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {" 
                
+[23:19]  no value evaluation, etc. 
                
+[23:20]  one second
                
+[23:23]  can you check if x the private key is < p
                
+[23:23]  if (m.compareTo(CryptoConstants.elgp) >= 0) 
                
+[23:23]  already done. 
                
+[23:23]  (throw new IllegalArgumentException("ARGH.  Data cannot be larger than the ElGamal prime.  FIXME");)  that exception is never thrown. 
                
+[23:23]  er x?  hmm.   
                
+[23:24]  'k.  perhaps we may want to steal bouncycastle's or another impl's elg key gen algo 
                
+[23:25]  ok.  0.3> sdk issues 
                
+[23:26]  elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs) 
                
+[23:26]  (only the elg issue plus the LeaseSet modification is left) 
                
+[23:26]  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]  or even whether we need to include SDK 0.1 with the spec release. 
                
+[23:27]  gah! annoying
                
+[23:28]  miracl which nop pointed me too does the exact same thing we do
                
+[23:28]  and they have no checks
                
+[23:28]  unsigned though. 
                
+[23:28]  (since miracl is in c) 
                
+[23:28] * jrand0m assumes
                
+[23:28]  yes
                
+[23:29]  but still, i make sure we never have a signed biginteger
                
+[23:30]  biginteger.toByteArray() returns a signed byte array 
                
+[23:30]  sorry, continue
                
+[23:30]  'k 
                
+[23:30]  any movement on the python front jeremiah? 
                
+[23:31]  hey
                
+[23:31]  sorry I was reading the backlog
                
+[23:31]  heh hi 
                
+[23:31]  nope, I'm still getting used to classes
                
+[23:31]  coo' 
                
+[23:31]  no prob 
                
+[23:31]  I think I'm gonna sleep for a bit actually
                
+[23:31]  'k 
                
+[23:32]  0.4: release plan 
                
+[23:32]  we need the sdk issues resolved in the next day or so, one way or another. 
                
+[23:32]  we need to get working on wiki-fiying the security model 
                
+[23:32]  (wiki, where art thou) 
                
+[23:33]  we need to get the performance model up (not a prob, ill have it in a day or so) 
                
+[23:33]  we need to update the specs to include any elg mods, plus real URLs to other specs. 
                
+[23:33]  miracl
                
+[23:33]  has a port
                
+[23:33]  to java
                
+[23:33]  perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care] 
                
+[23:34]  right, but miracl's java port doesnt have elg encryption last i checked. 
                
+[23:34]  i'll check again. 
                
+[23:34]  jrand0m, we don't care, but we'll worry about that later
                
+[23:34]  jrand0m if it has bigdig() and modexp()
                
+[23:34]  you're fine
                
+[23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev
                
+[23:34]  one second
                
+[23:34]  i think i found our problem
                
+[23:35]  word, whats up thecrypto? 
                
+[23:35]  can you check jrand0m
                
+[23:35]  our k isn't being checked for relitive prime
                
+[23:36]  will that cause the problems described thecrypto?  i thought that would just render the encryption insecure (a problem, nonetheless) 
                
+[23:36]  but that would mean only some messages with the key would fail
                
+[23:36]  it's something in keygen
                
+[23:36]  nop> we'll find something to solve it.  but i outlined some specific questions in my email that are implementation independent 
                
+[23:36]  ok thecrypto, we'll work through that after the meeting 
                
+[23:37]  the double ciphertext question?
                
+[23:37]  okay
                
+[23:37]  nop> thats one of the questions 
                
+[23:37] * nop goes to read
                
+[23:39]  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]  quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time?
                
+[23:41]  let me get it up, hold
                
+[23:41]  wiki.invisiblenet.net == jasonclinton.com [64.91.236.103]
                
+[23:41]  gracias mihi 
                
+[23:42]  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]  can i see this ElGamalAESEngine?
                
+[23:42]  just commit it to CVS and i'll see what the problem is
                
+[23:43]  ok wiki is cname'd
                
+[23:43]  should propagate in a bit
                
+[23:43] * jrand0m doesnt commit things that don't work, but I'll email you
                
+[23:43]  thanks nop 
                
+[23:43]  it's up
                
+[23:43]  ;)
                
+[23:43]  (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net
                
+[23:43]  not on my box it aint 
                
+[23:43]  ;) 
                
+[23:44]  what are we wiki'ing
                
+[23:44]  ?
                
+[23:44]  the security doc, plus a place to distro the specs. 
                
+[23:44]  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]  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]  I have a grphx guy working on the website
                
+[23:47]  for i2p
                
+[23:47]  any problems with that for a deadline?  [friday deadline, fallback only if Bad Things Happen] 
                
+[23:47]  sure
                
+[23:47]  jrand0m: sent?
                
+[23:47]  'k, so just the security docs and the i2p spec distro location 
                
+[23:47]  no thecrypto, there are half a dozen files.  i'll send after the meeting. 
                
+[23:47]  okay
                
+[23:48]  i'd like them sooner because we're moving tables around today so i need to move computers soon
                
+[23:48]  jrand0m, I'll need to look at your email and I'll respond shortly
                
+[23:48]  multi-tasking
                
+[23:49]  'k. 
                
+[23:49]  0.5> apps 
                
+[23:49]  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]  mihi has an awesome awesome i2ptunnel app 
                
+[23:50] *** Signoff: WinBear_ (EOF From client)
                
+[23:50]  strip one or two `awesome's ;)
                
+[23:50]  heh 
                
+[23:51]  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]  it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order)
                
+[23:52]  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]  ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something 
                
+[23:52]  (so that it didn't block on send and didn't require GUARANTEED) 
                
+[23:53]  that's a bot too many ifs i think...
                
+[23:53]  s/bot/bit/
                
+[23:55]  but perhaps i'll have some time to add reordering/resending to it...
                
+[23:55]  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]  word 
                
+[23:56]  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]  hmm
                
+[23:57]  test
                
+[23:57]  tset 
                
+[23:57]  still connected?
                
+[23:57]  si sr 
                
+[23:58]  we're unplugging phonelines right now
                
+[23:58]  IIP, it defies phone lines
                
+[23:58]  heh 
                
+[23:58]  :)
                
+[23:58]  i can get back on the IM front and file transfer
                
+[23:58]  wikked 
                
+[00:00]  ok.  thats all i have for agenda items. 
                
+[00:00]  any comments/questions/concerns/frisbees? 
                
+[00:00] * thecrypto throws a frisbee
                
+[00:00] * jrand0m gets a frisbee in the face
                
+[00:01]  i just want to get this crypto stuff done so i can go back and optimize elg
                
+[00:01]  and do the same for python hopefully
                
+[00:01]  word.  I'll get you the code in the next 5 
                
+[00:02]  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/i2p2www/meetings/56.log b/i2p2www/meetings/56.log
new file mode 100644
index 00000000..e6100436
--- /dev/null
+++ b/i2p2www/meetings/56.log
@@ -0,0 +1,215 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 56{% endblock %}
+{% block content %}
                
+[22:53]  ok, wtf, why not.  agenda: 
                
+[22:53]  0) welcome 
                
+[22:53]  1) spec & sdk release  
                
+[22:53]  2) spec & sdk questions  
                
+[22:53]  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]  4) meeting time change?   
                
+[22:53]  5) cvs administravia 
                
+[22:54]  6) shardy's stuff 
                
+[22:54]  7) peanut gallery 
                
+[22:54]  thazzit. 
                
+[22:54]  0) welcome 
                
+[22:54]  hihi
                
+[22:54]  so welcome everyone to meeting number 55
                
+[22:54]  56
                
+[22:55]  56 is correct
                
+[22:55] *** Signoff: mihi (EOF From client)
                
+[22:55]  hi.  welcome to meeting 56 
                
+[22:55]  yea 
                
+[22:55]  1) spec & sdk release 
                
+[22:55]  haha
                
+[22:55] *** mihi (~none@anon.iip) has joined channel #iip-dev
                
+[22:55]  the specs are out and the sdk 0.2 is out as well. 
                
+[22:56]  currently, they're only available on freenet [http://localhost:8888/CHK@p1VU1U67UgXYJ7v7cS4Xqn~p4ssLAwI,RvdwV4jZyZYcJgYabpVPOQ/I2P_SDK.zip] 
                
+[22:56]  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]  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]  well, first question in there is, how goes the progress /reading/ the specs?  :) 
                
+[22:58]  needa do that :)
                
+[22:58]  slowlyu
                
+[22:58]  therefore I have no questions
                
+[22:58]  heh word 
                
+[22:59]  I'll start now then
                
+[22:59]  suggested order of reading the PDFs is> I2POverview.pdf, then I2NP, then datastructures, then I2CP, then polling HTTP transport 
                
+[22:59]  ok I'll do it in that order then
                
+[23:00]  ok.  on to # 3 then, unless there are any q's on the specs 
                
+[23:00]  3.1) co's naming service proposal 
                
+[23:00]  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]  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]  how can one get the address of a name server? ;)
                
+[23:02]  OOB, but good point.  he should toss in a "bootstrapping" section 
                
+[23:03]  OOB?
                
+[23:03]  out of band.  e.g. from a web site or built into the software 
                
+[23:03]  ahh
                
+[23:03] *** naphtala (asdf@anon.iip) has joined channel #iip-dev
                
+[23:04]  (co may actually have different ideas, I'm just assuming thats what he meant.  definitely something to mention on the list) 
                
+[23:04]  is there any general way to make a text representation of Destinations (e.g. ascii armor)?
                
+[23:05]  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]  perhaps that should be added to the I2P data structures spec.  good idea.   
                
+[23:06]  does anyone have any qualms with base64? 
                
+[23:07]  ok.  at least for now that'll get added in. 
                
+[23:08]  3.2) SDK 1.0 criteria 
                
+[23:08]  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]  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]  optionally, we may want to include a streaming API as well 
                
+[23:10]  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]  ok.  post to the list if you think of anything 
                
+[23:11]  3.3) network simulator 
                
+[23:12]  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]  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]  ok.  3.4) other apps 
                
+[23:14]  haha
                
+[23:14] *** Signoff: mihi_backup (Ping timeout)
                
+[23:14] * thecrypto jumps up...and writes something else
                
+[23:14]  heh 
                
+[23:15]  mihi> any mods/updates/plans for the i2ptunnel?   
                
+[23:17]  nope.
                
+[23:17]  cool, just checkin' in :) 
                
+[23:17]  if someone writes a TCP layer for I2P, i might use it, but I wont write it.
                
+[23:18]  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]  and in a production environ waiting for an ACK before sending the next message is only a ~.4s delay 
                
+[23:19]  <insert caveat on latency models here> 
                
+[23:19]  ok.  next "other apps" 
                
+[23:20]  thecrypto> IM? 
                
+[23:20]  well, i'm working on a UI prototype right now
                
+[23:20]  as soon as we have some way of communicating with other people, i can just put in the networking stuff
                
+[23:20]  we /have/ some way of communicating with other people 
                
+[23:21]  (not that I'm against doing it in pieces anyway) 
                
+[23:21]  i'm going to start with just UI
                
+[23:21]  wikked. 
                
+[23:21]  I do wish to help thecrypto with the IM but I've some reading to do
                
+[23:21]  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]  nice 
                
+[23:22]  and i thought we only had local only unless you want to tunnel?
                
+[23:22]  will the UI have an address book feature for storing destinations of friends? 
                
+[23:22]  buddy list
                
+[23:23]  we'll have to poll the name server somehow to check when people are online
                
+[23:23]  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]  hmm, the IM app will depend on the name server? 
                
+[23:23]  or will the IM have a central "presence" server? 
                
+[23:23]  it'll need someway to keep track of everyone
                
+[23:23]  i'm trying to avoid central anything
                
+[23:24]  but some sort of distributed presense would have to be thought up and it looks like the NS will do that
                
+[23:24]  I don't think the NS has presence.  it only says what the Destinations are 
                
+[23:24]  (for each service for each nym) 
                
+[23:25]  but doesn't it have an online offline state?
                
+[23:25]  no, the NS is just like DNS.  it doesn't tell you if the host is reachable. 
                
+[23:25]  at least i thought it do
                
+[23:25] *** mihi_backup (~none@anon.iip) has joined channel #iip-dev
                
+[23:25]  so you have to try it to find out
                
+[23:26]  then i'll have to come up with my own spec to work out that part
                
+[23:26]  coo'.  perhaps start without one, and maybe add a rudimentary periodic ping, and then a fully distributed whatever ;) 
                
+[23:27]  well step 1 is UI
                
+[23:27]  anyway, you know best, whatever works for ya.  if there's anything anyone can do to help, just say the word 
                
+[23:27]  right 
                
+[23:27]  ok.  I don't have any other apps to discuss in the "other apps" section.  anyone else have app related ideas / discussion? 
                
+[23:28]  well what apps do we have planned already other than IM and NS and Tunnel?
                
+[23:29]  will file transfer be implemented along with IM or separately?
                
+[23:29]  separately I imagine
                
+[23:29]  you will be allowed to file transfer IM, but other people can come up with file transfer only protocols like FTP
                
+[23:29]  ok so what you're working on will have file transfer as well
                
+[23:29]  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]  IE replace freenet :)
                
+[23:30]  a multiplexing "outdial" tcp tunnel would be cool too 
                
+[23:30]  naw, freenet is a CDN, this would require having a server to store space on 
                
+[23:31]  okay
                
+[23:31]  (the outdial would probably require SOCKS integration though) 
                
+[23:32]  that it for the top of my head though.  with mihi's tunnel we can already ssh and cvs over i2p 
                
+[23:32]  ok.  3.5) more transports 
                
+[23:33]  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]  but if someone wants to look at the polling HTTP transport and define some other transport, that'd be fantastic 
                
+[23:33]  transports kinda like the jabber transports
                
+[23:33]  translating one to another?
                
+[23:34]  hmm?  transports are the actual means of sending bytes from one router to another. 
                
+[23:34]  ahh okay
                
+[23:34] *** jnk has left #iip-dev
                
+[23:34]  so instead of just one method of getting the bits from one router to another there are many?
                
+[23:34]  exactly. 
                
+[23:34]  I2NP does /not/ specify a particular transport 
                
+[23:35]  so if one is firewalled/blocked/slow/... you use another
                
+[23:35]  exactly 
                
+[23:35]  sweee
                
+[23:35]  yah that sweet :)
                
+[23:35]  ok, 3.6) java router reference implementation 
                
+[23:36]  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]  then individual subsystems can be stub'ed and implemented in turn (or in parallel).   
                
+[23:37] *** Signoff: mihi (EOF From client)
                
+[23:37]  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]  can do
                
+[23:38]  w3wt 
                
+[23:38]  hopefully can do :)
                
+[23:38]  word 
                
+[23:38]  ok.  any other dev status questions / thoughts / comments? 
                
+[23:39]  thecrypto: is anyone else working on the IM with you as of now?
                
+[23:39]  co should be
                
+[23:39]  is co cohesion?
                
+[23:39]  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]  no co == whit
                
+[23:39]  no, co is wiht, cohesion is a different person :) 
                
+[23:39]  ok thanks
                
+[23:40] *** mihi (~none@anon.iip) has joined channel #iip-dev
                
+[23:40]  if it was cohesion then we would use tab compleletion
                
+[23:40]  heh 
                
+[23:40]  some people are too lazy for even that 
                
+[23:41]  ok.  agenda item 4) meeting time change 
                
+[23:41]  is anyone here further east than GMT+2? 
                
+[23:41]  you don't need to answer that... 
                
+[23:41]  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]  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]  not much later. 8p or 7p would be better
                
+[23:42]  ah 'k 
                
+[23:42]  but if i can't come; i'll read the log.
                
+[23:43] *** Signoff: cohesion (class)
                
+[23:43]  well, we have no hard reason to make it later and its good to have you here ;) 
                
+[23:43]  i say it's perfect where it is
                
+[23:44]  cool.  I just wanted to bring it up to possibly help out the left coast 'mericans who have jobs :) 
                
+[23:44]  but 9P GMT it is and 9P GMT it stays 
                
+[23:44]  ok.  item 5) cvs administravia 
                
+[23:45]  well, none of the python people are here, and thecrypto and I have already spoken re: cvs module conventions :) 
                
+[23:45]  we still are working on getting anon cvs 
                
+[23:45]  or at the very least nightly snapshots of the cvs on the web. 
                
+[23:45]  that'll be announced once its ready. 
                
+[23:46]  most of the reason for limiting access to to make sure not too many people start getting at it
                
+[23:46]  before it's ready
                
+[23:46]  right, but the SDK has the full source of everything in the tree atm anyway ;) 
                
+[23:47]  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]  dunno though.  we'll cross that bridge when it comes  
                
+[23:47] *** Trifixion has left #iip-dev
                
+[23:48]  item 6) shardy's stuff 
                
+[23:48] * jrand0m waves to shardy
                
+[23:48]  hiya
                
+[23:48]  um, I don't really have much of anything to say
                
+[23:48]  just thought I'd say hi and all
                
+[23:48]  seeing as how I've got myself involved in the project latey :)
                
+[23:48]  lately.
                
+[23:48]  hihi
                
+[23:49]  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]  like if you need random code debugged, or crypto implemented, or optimized
                
+[23:49]  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]  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]  nice 
                
+[23:50]  I'll be hanging around, so grab me for whatever if you need anything.
                
+[23:50]  yah
                
+[23:50]  wikked. 
                
+[23:50]  ok.  7) peanut gallery 
                
+[23:50]  any i2p thoughts / comments / questions / concerns? 
                
+[23:52]  ok then :) 
                
+[23:52] *** naphtala has left #iip-dev
                
+[23:52]  i2p is neat
                
+[23:52]  heh 
                
+[23:52]  ;0
                
+[23:52] * jrand0m pulls the *baf* off the wall...
                
+[23:53]  ... the wind-up 
                
+[23:53]  and the *baf* 
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/57.log b/i2p2www/meetings/57.log
new file mode 100644
index 00000000..38739a9d
--- /dev/null
+++ b/i2p2www/meetings/57.log
@@ -0,0 +1,170 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 57{% endblock %}
+{% block content %}
                
+[22:57]  ok, buenos noches srs y srtas 
                
+[22:57]  agenda: 
                
+[22:57]  0) welcome 
                
+[22:57]  1) cvs 
                
+[22:57]  4) naming service 
                
+[22:58]  You forgot 5) questions.
                
+[22:58]  3) dev status 
                
+[22:58]  2) spec questions? 
                
+[22:58]  5) other questions? 
                
+[22:58]  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]  lets see if I can keep that straight as we go... 
                
+[22:59]  ok, 0) welcome 
                
+[22:59]  yay for permutation groups!
                
+[22:59]  welcome to meeting 57 
                
+[22:59]  yeah, they're all just symbols anyway 
                
+[22:59]  sweet whatup ;0
                
+[23:00]  I'll help comprise peanut gallery
                
+[23:00]  1) cvs is still down, after 10+ days.  we're finding a new host. 
                
+[23:00]  sf.net sucks, and I have no reason to believe gnu's nongnu is better. 
                
+[23:00]  jrand0m: Why not make that host have the alias "cvs.invisiblenet.net"?
                
+[23:00]  nop is leading the charge on finding the new host. 
                
+[23:01]  sure co, once we get the server 
                
+[23:01]  what do you need for a host?
                
+[23:01]  shardy> reliable net connection, ssh/cvs access.  and some disk space 
                
+[23:01]  do you have something lined up?
                
+[23:01]  because if not. I may be able to assist.
                
+[23:02]  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]  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]  how much disk space would you need?
                
+[23:03]  the repository currently comprises ~ 6Mb.  so probably 50M would handle growth for a good while 
                
+[23:04]  oh. pfft. that's nothing.
                
+[23:04]  and the machine wouldn't need to be super fast?
                
+[23:04]  you wouldn't be doing big compile jobs on it?
                
+[23:04]  naw, a 286 would probably do it. 
                
+[23:04]  no, strictly cvs checking / checkout  
                
+[23:04]  (well, and diff, and log, etc ;) 
                
+[23:05]  "we're java, we don't need compile farms" </fark> 
                
+[23:05] *** Signoff: cohesion (class)
                
+[23:05]  do people concerned with anonymity access CVS using something like JAP?  I've never used CVS
                
+[23:05]  w0rmus> I use cvs through a private series of ssh proxies 
                
+[23:05]  jrand0m: Keep in mind that a C or C++ implementation may be likely in the future.
                
+[23:06]  jap does not allow cvs access AFAIK :(
                
+[23:06]  ssh tunnelling
                
+[23:06]  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]  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]  awesome shardy.  there's anything we can do, just say the word. 
                
+[23:07]  jrand0m: You are right. They should be separate.
                
+[23:07]  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]  shardy++ 
                
+[23:07]  yay ;0
                
+[23:07]  ok, 4) naming service 
                
+[23:08]  co, how goes?   
                
+[23:08]  I am still writing, but would like to say a few words about it.
                
+[23:08]  First, to address a question from thecrypto during the last meeting, the NS does not provide notification of someone's being online.
                
+[23:09]  It merely says that a person can be contacted via certain methods, such as AIM.
                
+[23:09]  Second, the client side.
                
+[23:09]  There will be an API which programs can use to make queries to naming servers.
                
+[23:10]  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]  The underlying mechanism will also read the destination mechanism for the local router to contact from a file.
                
+[23:11]  the destination mechanism? 
                
+[23:11]  I'm sorry, the destination address.
                
+[23:11]  ah 'k 
                
+[23:12]  That is all at this time.
                
+[23:12]  cool 
                
+[23:12]  I agree
                
+[23:12]  ;)
                
+[23:12]  any ballpark ideas on timelines for various milestones?   
                
+[23:13]  obviously nothing anyone could hold you to, of course, just wondering 
                
+[23:13]  Let's say end of the week for finishing the specification and publishing it and the API.
                
+[23:14] * mariesofie arrives late
                
+[23:14]  ah nice co 
                
+[23:14]  Then, I will start implementing it. I am not certain how long that will take, though.
                
+[23:14]  understandable 
                
+[23:15]  anyone else have any naming service questions/thoughts? 
                
+[23:15]  ok, 3) dev status 
                
+[23:16]  dev goes well. 
                
+[23:16]  the java side is up to spec and implements all I2CP and I2NP messages and structures 
                
+[23:17]  the java architecture itself is functional and I'm going to continue stubbing out the various subsystems 
                
+[23:17]  Have you tested it?
                
+[23:17]  the messages & structures?  yes via the TestData harness in net.invisiblenet.i2p.data.test 
                
+[23:17]  I mean connecting two different computers with I2P.
                
+[23:18]  oh, no, thats requires the full implementation of the communication subsystem 
                
+[23:18]  I see.
                
+[23:18]  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]  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]  there's still a lot of work to be done after that before the alpha, but thats progress  
                
+[23:21]  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]  man. i really need to read up on the specs.
                
+[23:22]  well, they'll soon be hosted on your machine so it'll be easy :) 
                
+[23:22]  haha
                
+[23:22]  I have not finished specs either
                
+[23:23]  i printed the specs, read them so many times it got worn out and i had to print out another copy
                
+[23:23]  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]  heh
                
+[23:23]  rofl mariesofie 
                
+[23:23]  ok, thats it for 3) dev status 
                
+[23:24]  now for 2) spec questions 
                
+[23:24]  I suppose I'll read them instead of stupid calculus
                
+[23:24]  I am thinking a little bit into the future.
                
+[23:24]  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]  correct co 
                
+[23:25]  How will you accomplish that?
                
+[23:25]  the datastructures spec specifically defines the byte layouts 
                
+[23:25]  and everything is big endian and all numbers are unsigned 
                
+[23:25]  what level of technical knowledge are you targetting the specs for? anyone with decent comp. knowledge? college level CS engineer students?
                
+[23:25]  Oh, all right.
                
+[23:25] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
                
+[23:26]  i.e. who is the target audience?
                
+[23:26] *** mihi_ is now known as mihi
                
+[23:26]  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]  we really really need some docs that go in the middle 
                
+[23:27]  i see
                
+[23:27]  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]  maybe thats reflective on me more than the documentation :)
                
+[23:28]  heh geek :) 
                
+[23:29]  ok, any other questions on the specs?  lets move on to 5) other questions  
                
+[23:29]  anyone have any other questions?  this is our last bullet point on the meeting agenda 
                
+[23:30]  I wonder where thecrypto is with achat
                
+[23:30]  ah, thecrypto is offline for the next three weeks or so 
                
+[23:30]  what happens with peer review?
                
+[23:30]  or atalk
                
+[23:30]  wow
                
+[23:30]  is anyone reviewing it?
                
+[23:30]  i thought thecrypto has 2hrs per day
                
+[23:31]  and I can't even see the codes he has :(
                
+[23:31]  mihi> reviews have been sent to various people for review and as feedback comes it will be addressed. 
                
+[23:31]  w0rmus> do you have any questions on ATalk? 
                
+[23:32]  I will be reviewing it as soon as I have time :)
                
+[23:32]  i meant, did any feedback come till nowß
                
+[23:32]  I suppose not
                
+[23:32]  s/nowß/now?/
                
+[23:32]  mihi> largely in the form of discussions and clarifications 
                
+[23:32]  awesome shardy :) 
                
+[23:33]  hapy birthday google
                
+[23:33]  mariesofie> right, but thats not even enough time for him to d/l the java lang docs to continue dev :/ 
                
+[23:33]  ahaha wtf
                
+[23:35]  ok, any other questions / thoughts? 
                
+[23:35]  I guess I should mention that I've never coded outside of school
                
+[23:35]  but I gotta start somewhere anyways
                
+[23:35]  now's a good time to start :) 
                
+[23:35]  word 
                
+[23:35]  ;0
                
+[23:35]  i have questions on the api, but not yet, in a day or two when i can try it out some more
                
+[23:35]  I've taken 2 years of java or so
                
+[23:36]  ok cool mariesofie, just bounce a msg to the list or bounce me a message here whenever 
                
+[23:37]  mariesofie: Have you read the discussion on the iip-dev mailing list?
                
+[23:37]  where is it archived?
                
+[23:37]  http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel 
                
+[23:37]  (fairly low traffic atm) 
                
+[23:38]  jrand0m wants you code something that can not logicly exist, to tear the world usunder, to end the reign of god.
                
+[23:38]  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]  Brownspider: huh?
                
+[23:39]  co, it was on his freesite, nevermind
                
+[23:40]  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]  co> i've only read back to about issue #52 or so
                
+[23:42]  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]  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/i2p2www/meetings/58.log b/i2p2www/meetings/58.log
new file mode 100644
index 00000000..778cf6d3
--- /dev/null
+++ b/i2p2www/meetings/58.log
@@ -0,0 +1,314 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 58{% endblock %}
+{% block content %}
                
+[22:53]  0) welcome 
                
+[22:54]  1) apps: 
                
+[22:54]  1.1) IM 
                
+[22:54]  1.2) NS  
                
+[22:54]  2) dev status: 
                
+[22:54]  2.1) subsystems 
                
+[22:54]  2.2) encryption key persistence 
                
+[22:54]  2.3) todo 
                
+[22:54]  3) spec stuff 
                
+[22:54]  3.1) mods 
                
+[22:54]  4) administravia: 
                
+[22:54]  4.1) anon cvs 
                
+[22:54]  5) ? 
                
+[22:55]  ok, 0) welcome  
                
+[22:55]  welcome to meeting 58 
                
+[22:55]  that all
                
+[22:55]  si sr, unless anyone else has things to add? 
                
+[22:55] * nop notices jrand0m is object oriented with his numbering :)
                
+[22:56]  3.1.2.2.4.5.8() ;)
                
+[22:56]  hey, they could be structs ;) 
                
+[22:56]  haha
                
+[22:56]  that is definitely true
                
+[22:56]  ok, 1.1) IM.  thecrypto? 
                
+[22:56]  although
                
+[22:56]  2 has inheritance
                
+[22:57]  ;)
                
+[22:57]  heh 
                
+[22:57]  nevermind me
                
+[22:57]  ok
                
+[22:57]  sorry
                
+[22:57]  continue
                
+[22:57] *** mihi_ (~none@anon.iip) has joined channel #iip-dev
                
+[22:57]  okay, right now i'm uploading some basic specs for IM
                
+[22:58]  (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw for oowriter
                
+[22:58]  and i'm working on uploading the pdf
                
+[22:58]  if you want I can put on i2p site
                
+[22:59]  give me a second
                
+[22:59]  sure
                
+[22:59] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
                
+[22:59]  do you want to put that into i2p/apps/IM/doc/ ? 
                
+[22:59] *** mihi_ is now known as mihi_backup
                
+[23:00]  I can
                
+[23:00]  yes
                
+[23:00]  I meant in cvs :) 
                
+[23:00]  i can do that too
                
+[23:00]  (but on the web is good too) 
                
+[23:00]  oh
                
+[23:00]  haha
                
+[23:00]  (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf
                
+[23:01]  "the file is damaged and could not be repaired"  AR error
                
+[23:01]  try again
                
+[23:01] * jrand0m loaded it fine
                
+[23:01]  MrEcho: The PDF file?
                
+[23:01]  (the sxw) 
                
+[23:01]  only partially uploaded at that time
                
+[23:01]  now it works
                
+[23:01]  hehe
                
+[23:02]  basicall i just put in the presence stuff, online offline messages, and a message message
                
+[23:02]  i shameless ripped some sections from the I2NP documenty
                
+[23:02]  :)
                
+[23:02]  heh I thought some of it looked familiar :) 
                
+[23:02]  i'm also working on uploading the UI i
                
+[23:02]  i've been working on
                
+[23:03]  jrand0m: do i need to create the dirs apps/IM/doc
                
+[23:03]  yes, and cvs add them individually 
                
+[23:03]  -kb?
                
+[23:03]  yes 
                
+[23:03]  thecrypto: I believe apps/ is there now.
                
+[23:04]  whats a presence? 
                
+[23:05]  let me run update
                
+[23:05]  but it's getting in there
                
+[23:05] *** Signoff: shardy (Ping timeout)
                
+[23:05]  i'm just saying rip apart the specs
                
+[23:05]  and the UI will be in there soon as well
                
+[23:05]  and if you have anything that needs to be clarified then anonymail, e-mail, anything me and i'll fix it
                
+[23:05]  did i miss the meeting?
                
+[23:05] *** shardy (~shardy@anon.iip) has joined channel #iip-dev
                
+[23:05]  thecrypto: You might want to announce it on the e-mail list, as well, with a link to the documents.
                
+[23:05]  i thought i put that in there?
                
+[23:05]  nope still on the first item point mrflibble 
                
+[23:05]  mrflibble: Meeting is in progress.
                
+[23:05]  oh sorry, just couldnt see "logger"
                
+[23:06]  thecrypto> you state that its a destination, but is that the destination at which to send messages?  how do offline messages work? 
                
+[23:06]  no mids here, so no logger ;)
                
+[23:06]  k
                
+[23:06] * mrflibble goes back to lurking
                
+[23:06]  oh wait, these are just presence notifications, sorry 
                
+[23:06]  how can one subscribe to a presence?
                
+[23:06]  jrand0m: no offline messages
                
+[23:07]  basically
                
+[23:07]  the presence just wraps a destination and a name together
                
+[23:07]  to make things easy
                
+[23:08]  so if we want to move onto NS we can do that, and we can come back to this later?
                
+[23:09]  'k cool 
                
+[23:09]  and you can still message me questions
                
+[23:09]  actually, one quick question 
                
+[23:09]  shoot
                
+[23:09]  so the IM is strictly text only? 
                
+[23:10]  with this basic one yes, but i will be adding file support in
                
+[23:10]  coo' 
                
+[23:10]  i just want the beginnings of the system taken care of and build on it
                
+[23:10]  (iterative and incremental)++ 
                
+[23:11]  ok great.  I'll go through this further and other people should too... for now, moving on to 1.2) NS.  co? 
                
+[23:11]  Version 1.1 (final) of the naming service specification was released earlier today.
                
+[23:12]  (and there was much rejoicing) 
                
+[23:12]  Basically, I finished the sections on the data structures and network messages that the program needs.
                
+[23:12]  I will be releasing the client API on Thursday.
                
+[23:12]  And will begin implementing the NS application.
                
+[23:12]  great 
                
+[23:13]  One idea that has changed is what the CA does when entities register with it.
                
+[23:13]  co: how will you be implementing it?
                
+[23:13]  co: the name server or the client?
                
+[23:14]  thecrypto: Well, first I will implement the data structures necessary.
                
+[23:14]  Then, the client, then the server and CA components.
                
+[23:14]  okay
                
+[23:15]  As I was saying, I now would like the CA to issue a certificate to newly registered entities.
                
+[23:15]  They will present this certificate to naming servers when modifying their records.
                
+[23:15]  I have not specified what the certificate contains in this version; that will go into the next version of the specification.
                
+[23:16]  Does this strike anyone as a bad idea?
                
+[23:16]  hmm.  wouldn't it be simpler / safer to just have the client use a public key / private key? 
                
+[23:16]  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]  (so that hte CA never gets the private key) 
                
+[23:17]  Sidenote: all the I2PIM stuff is now committed to the cvs respository
                
+[23:17]  great 
                
+[23:17]  It may be simpler to do just that. I will re-think this issue. Thank you for the comment.
                
+[23:17]  That is all I have to discuss for the naming service at this time, if you have no other questions.
                
+[23:18]  its lookin good, I haven't gone through the 1.1 yet but I'll email if I come across something 
                
+[23:19]  OK. Next topic?
                
+[23:19]  ok, 2.1) dev status for subsystems. 
                
+[23:19] *** w0rmus (o0o@anon.iip) has joined channel #iip-dev
                
+[23:20]  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]  What do you mean by stupid algorithms?
                
+[23:21]  not fast?
                
+[23:21]  eh, the peer management subsystem isn't keeping track of peer performance, its just returning random peers. 
                
+[23:22]  the algorithm will be updated and tuned as things progress to more adequately provide peer selection 
                
+[23:22]  current task on my plate is building and handling garlic messages, which is a PITA. 
                
+[23:23]  but workable, just annoying  
                
+[23:23]  that actually leads into 2.2) encryption key persistence. 
                
+[23:24]  garlic messages use ElG+AES encryption to wrap the layers of the cloves 
                
+[23:24]  and private keys are used in other places (transport, client management) 
                
+[23:25] *** Signoff: thecrypto (Ping timeout)
                
+[23:25]  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]  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]  Option 2.
                
+[23:27]  jrand0m option 2, or do what we said before
                
+[23:27]  we must trust localhost 
                
+[23:27] *** Signoff: cohesion (class)
                
+[23:27]  we assume localhost is not compromised
                
+[23:27]  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]  good point nop. 
                
+[23:28]  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]  depending on paranoia level
                
+[23:28]  security vs convenience measure
                
+[23:29]  Then I propose having 3 by default, and giving the user the option to use 2.
                
+[23:29]  exactly
                
+[23:29]  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]  ok, cool, I'll just go with the simple 3) for now then 
                
+[23:30]  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]  'k, you're item #5 now 
                
+[23:30]  I can wait until the end.
                
+[23:31]  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]  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]  word
                
+[23:34]  other todo's... um, I fixed the "Wrong Size generating key" thing this morning plus a few random bugs 
                
+[23:34]  ok, thats it for dev status.  3) spec stuff 
                
+[23:35]  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]  3.2) [I know, this one wasn't on the agenda, but here it is anyway] spec questions 
                
+[23:35]  (brb, I'm still lurking if you need me)
                
+[23:35]  anyone have any questions on any of the specs? 
                
+[23:35]  cool shardy 
                
+[23:36]  jrand0m: Please tell us again which spec is in which document.
                
+[23:37]  (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs has 'em mapped out 
                
+[23:37]  I will look at it.
                
+[23:38]  (looking at that it reminds me I need to document the secure reliable UDP transport.  yet another todo...) 
                
+[23:39]  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]  jrand0m
                
+[23:40]  si sr? 
                
+[23:41]  do you mean actual UDP as in UDP packets 
                
+[23:41]  or UDP as in a general UDP protocol
                
+[23:41]  yes, UDP as in UDP packets 
                
+[23:41]  for I2P
                
+[23:41] *** thecrypt1 (~thecrypto@anon.iip) has joined channel #iip-dev
                
+[23:41] *** thecrypt1 is now known as thecrypto
                
+[23:41]  i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp for the implementation 
                
+[23:42]  back
                
+[23:42]  wb 
                
+[23:42]  anyone want to send me what happened while i was gone?
                
+[23:43]  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]  rekeying is supported though not automatic atm 
                
+[23:43]  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]  (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]  of course
                
+[23:45]  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]  good
                
+[23:46]  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]  ok, so, yeah, that needs to get doc'ed up into a spec :) 
                
+[23:48] * jrand0m !thwaps self for coding before specing
                
+[23:48]  coding before specing helps me
                
+[23:48]  yeah, it works best iteratively 
                
+[23:48]  (as we're finding problems with the specs by implementing them, etc) 
                
+[23:49]  ok, thats 3) specs.  4) administravia 
                
+[23:49]  4.1) anon cvs.  thecrypto?  :) 
                
+[23:49]  just in the nick of time
                
+[23:49]  well, i'm looking into it, i think 2401 is currently blocked
                
+[23:49]  can you cvs -d :pserver: locally? 
                
+[23:49]  and there might be some inetd stuff to do as well thanks jrandom
                
+[23:50]  ah coo' 
                
+[23:50]  let me test that i forgot you cood do that :)
                
+[23:51]  would it just be cvs -d :pserver: ?
                
+[23:51]  cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p 
                
+[23:52]  also, it'd be great if we could get a bugzilla on there too 
                
+[23:52]  acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused
                
+[23:52]  'k, after adding the inetd.conf line and kill -HUP identd? 
                
+[23:52]  let me try that inet line and i'll get back to you
                
+[23:52]  er, inetd :) 
                
+[23:52]  'k cool 
                
+[23:53]  does the pserver go on the same line?
                
+[23:53]  yes, thats all on one line 
                
+[23:55]  ok, thats it for administravia, at least that I can think of 
                
+[23:55]  5a) co, you're up 
                
+[23:56]  When two people want to register the same entity name, the second is refused.
                
+[23:56]  But if we use a signature-based approach,
                
+[23:56]  the person who was refused could send a message to the naming server
                
+[23:56]  anyway, telling it to modify the record.
                
+[23:56]  There are two possibilities:
                
+[23:57]  1) CA sends the naming server a copy of the public key for the entity that was approved.
                
+[23:57]  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]  If a malicious user tells the naming server to modify a certain record, the lack of a certificate would prevent the modification.
                
+[23:58]  That is what I was thinking.
                
+[23:59]  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]  what you're describing sounds more like symmetric crypto - just using a passphrase, eseentially 
                
+[00:00]  cvs is screwing with me!
                
+[00:00]  (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]  whats up thecrypto? 
                
+[00:01]  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]  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]  coo' 
                
+[00:01] *** LeerokLacerta (~leerok@anon.iip) has joined channel #iip-dev
                
+[00:02]  Konnichiwa.
                
+[00:02]  hmm thecrypto, I don't think you want an anonymous OS user 
                
+[00:02]  heya LeerokLacerta 
                
+[00:02]  Hello, jrand0m.
                
+[00:02]  well i stuck on a password and it works now
                
+[00:03]  jrand0m: And if you have any more suggestions after reading the spec, send them to me.
                
+[00:03]  shall do co 
                
+[00:03]  cool thecrypto.. is /bin/false their shell? 
                
+[00:03]  now i just have to find that section in the cvs manual about how to make a user
                
+-> *thecrypto* whats the pw?
                
+[00:04]  now it is
                
+[00:05]  ok, we can work through this after the meeting. 
                
+[00:05]  ok, last point on the agenda: 5b) ? 
                
+[00:05]  any questions / thoughts / concerns? 
                
+[00:05]  just check out the IM app
                
+[00:06]  right now all it does is make a tree but it shows you what it's starting to look like
                
+[00:06]  No SOCKS?
                
+[00:06]  ohh yeah that's what i forgot
                
+[00:06]  ah cool thecrypto 
                
+[00:06]  SOCKS?  as in, the proxy protocol? 
                
+[00:06]  anyone here good at making icons?
                
+[00:06]  Yup.
                
+[00:06]  The answer for all the times I've asked as been "No".
                
+[00:07]  ah.  yes, we're definitely going to want a socks proxy, but no one is working on it atm. 
                
+[00:07]  Hmm.
                
+[00:07]  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]  there are enough socks proxies available for free, i'd say ;)
                
+[00:08]  exactly, we just need to integrate 'em 
                
+[00:08]  but i don't know any in java.
                
+[00:08]  the JAP client app might work well, I don't know if its GPL though 
                
+[00:08]  the jap client does not contain a proxy.
                
+[00:08]  well I need some icons for the I2PIM project
                
+[00:09]  Something to represent online offline and a group of people
                
+[00:09]  the only proxy is a http/ftp proxy and that is in the last mix.
                
+[00:10]  like with iip - isproxy does not know any IRC protocol.
                
+[00:10]  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]  anyone interested?
                
+[00:11]  thecrypto: Could you take the icons from the GPL'd gaim project?
                
+[00:11] * jrand0m makes horrificly boring graphics in ms paint
                
+[00:11]  Since it's under GPL, and so is this, unless I am mistaken.
                
+[00:11]  yeah, i could
                
+[00:11]  if I2PIM uses the sdk's client libs, I2PIM is definitely GPL :) 
                
+[00:12]  ahh the wonderful GPL
                
+[00:12]  LeerokLacerta> any particular reason you ask, or just wanting to prod us to do it? ;) 
                
+[00:13]  the problem with the gaim ones is they are from the IM apps they are using
                
+[00:14]  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]  ok, anyone have any other thoughts / questions / commnets? 
                
+[00:16]  I have commnets
                
+[00:16]  (other than "wtf is a commnet") 
                
+[00:16]  is that contagious? 
                
+[00:16] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev
                
+[00:16]  lol
                
+[00:17]  'k, well, if not, that about wraps up the meetin', no more agenda items left 
                
+[00:17]  did i miss the meeting?
                
+[00:17]  yup, 9p GMT 
                
+[00:17]  well, technically you made it for the end :) 
                
+[00:17]  oh
                
+[00:18]  nop: Let's hear them.
                
+[00:18]  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]  anon cvs is still not liking me, more work tommorow
                
+[00:20]  gimmie root and I'll get 'er up 
                
+[00:21]  talk to nop about that one
                
+[00:21]  heh 'k 
                
+[00:22]  ok, as nop seems to have been dragged back into work... 
                
+[00:22]  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/i2p2www/meetings/59.log b/i2p2www/meetings/59.log
new file mode 100644
index 00000000..6ceb77ca
--- /dev/null
+++ b/i2p2www/meetings/59.log
@@ -0,0 +1,734 @@
+{% extends "_layout.html" %}
+{% block title %}Meeting 59{% endblock %}
+{% block content %}
                
+[22:56]  ok ok 
                
+[22:56]  agenda 
                
+[22:56]  0.0) welcome 
                
+[22:56]  1.0) dev status 
                
+[22:56]  1.1) router 
                
+[22:56] *** Myself248 (~ident@anon.iip) has joined channel #iip-dev
                
+[22:56]  1.2) DH precalc 
                
+[22:56]  2.0) microroadmap 
                
+[22:56]  3.0) apps / usage 
                
+[22:56]  4.0) ns 
                
+[22:56]  5.0) IM 
                
+[22:56]  6.0) administravia (cvs, bugzilla, cvs list, cvs web) 
                
+[22:56]  7.0) questions 
                
+[22:57]  (yes, 7 points today.  w00t) 
                
+[22:57]  0.0) welcome 
                
+[22:57]  hi. 
                
+[22:57]  hey
                
+[22:57]  17 users today.  neat 
                
+[22:57] *** Ryan_Singer (chatzilla@anon.iip) has joined channel #iip-dev
                
+[22:57]  and counting 
                
+[22:57]  ok 
                
+[22:57]  1~hi
                
+[22:57]  1.1) dev status for router 
                
+[22:58]  the java reference impl router is doing very well 
                
+[22:58] *** ChZEROHag (hag@anon.iip) has joined channel #iip-dev
                
+[22:58]  we can now run applications on different routers and send messages ot each other 
                
+[22:59]  Sorry to interrupt, but hopefully it'll just be once
                
+[22:59]  taking an iterative and incremental approach, the current state is secure, not anonymous, not scalable, and harvestable 
                
+[22:59]  Is anyone else working on a C api?
                
+[22:59]  'lo ChZEROHag, whats shakin? 
                
+[22:59]  Because I am, but very slowly
                
+[22:59] *** dcat (dirtycat@anon.iip) has joined channel #iip-dev
                
+[22:59]  oh cool 
                
+[22:59]  shardy will be working on one after toorcon is finished 
                
+[22:59]  perhaps you two could work together on that? 
                
+[23:00]  jrand0m: Can you input a destination to send messages to by hand?
                
+[23:00]  Better said, is there an ASCII representation of a destination?
                
+[23:00]  yes co, to both 
                
+[23:00]  Excellent.
                
+[23:00]  destinations, and all I2P structures, are loadable and serializable in (an alternate alphabet) base 64 
                
+[23:01]  so it won't be easy to remember, but it will be ascii?
                
+[23:01]  (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]  [though that is H(destination).toBase64() 
                
+[23:03]  ChZEROHag> if there's anything we can do to help you with that, just say the word 
                
+[23:03]  ok thats 1.1.  1.2) DH precalc 
                
+[23:03]  You could do it for me? :-)
                
+[23:04]  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]  lol ChZEROHag 
                
+[23:04]  aah I know what I needed
                
+[23:04]  A netdb implementation
                
+[23:04]  is it in cvs?
                
+[23:04]  the dh
                
+[23:04]  yes thecrypto 
                
+[23:05]  C:\dev\i2p\code\core\java\src\net\invisiblenet\i2p\crypto\DHSessionKeyBuilder.java 
                
+[23:05]  Well I'm going to be up for a good 3/4 hours yet, maybe it'll give me something to do
                
+[23:05]  er, s/C:\\dev/g; s/\\/\//g 
                
+[23:05] *** wax_off (~nomail@anon.iip) has joined channel #iip-dev
                
+[23:06]  word.  what do you need a netdb impl for? 
                
+[23:06]  I don't remember
                
+[23:06]  we currently have a non-scalable netdb in cvs 
                
+[23:06]  heh 
                
+[23:06]  Haven't touched it in at least a week
                
+[23:06]  you're working on a C I2CP api, right?  not I2NP? 
                
+[23:07]  I was just going to do everything
                
+[23:07] *** wax_off has left #iip-dev
                
+[23:07]  I2NP is really, really, really significantly more work than I2CP 
                
+[23:07]  Once I actually get properly started, it'll just roll out
                
+[23:07]  but if you impl an I2NP in C that'd rule 
                
+[23:07]  is there a I2NP in anything right now?
                
+[23:07]  (I2CP:I2NP::FCP:FNP) 
                
+[23:07]  yes dm 
                
+[23:08] * ChZEROHag deminimizes emacs
                
+[23:08]  the java impl i'm working on has I2NP functioning 
                
+[23:08]  alrighty...
                
+[23:08]  jrand0m: url? I could do with a reference, even if it's in a horrible language.
                
+[23:08]  heh 
                
+[23:08]  erm, actually thats 6.0 administravia: aka where the fuck is our anon cvs access ;) 
                
+[23:09]  i'm getting the DH stuff
                
+[23:09]  coo' 
                
+[23:09]  Oh right
                
+[23:09]  jrand0m,  back to schedule, the microroadmap?
                
+[23:09] * thecrypto hides his face
                
+[23:09]  well I'll wait :)
                
+[23:09]  heh 'k 
                
+[23:09]  microroadmap 
                
+[23:09]  I have 0.1 through 0.5 mapped out 
                
+[23:09]  followed freenet's roadmap then?
                
+[23:10] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
                
+[23:10]  0.1) functional, secure, not anonymous, not scalable, harvestable 
                
+[23:10]  development slows down and freezes during 0.5...
                
+[23:10]  we are now at 0.1.   
                
+[23:10]  heh I noticed that dm, flinks hosed off at 0.5.2 as well ;) 
                
+[23:10]  What are you calling the whole package?
                
+[23:10]  (strange coincidence) 
                
+[23:10]  i.e. version 0.1 of?
                
+[23:10]  the whole package?  i2p router reference implementation 
                
+[23:10]  co: Wonga
                
+[23:10] * beefbroth joins the meeting
                
+[23:11]  buenos noches beefbroth 
                
+[23:11]  All right. That explains it.
                
+[23:11]  Actually maybe I will call it that. Certainly sounds more interesting than 'i2pd'
                
+[23:11]  0.1 has bugs.  thats a given.  and it has no optimizations of note (though the DH precalc helps).   
                
+[23:11]  heh 
                
+[23:11]  jrand0m,  what's 0.2) then?
                
+[23:11]  invisible internet police department 
                
+[23:11]  ok, 0.2 
                
+[23:12]  0.2 is functional, secure, anonymous, not scalable, harvestable 
                
+[23:12]  0.2 adds support for non-zero-length tunnels 
                
+[23:12]  I actually implemented most of that last night, but not thoroughly tested 
                
+[23:12]  I think 0.2 will be ready by end of week 
                
+[23:12]  how far away are we from that from a dev perspective?
                
+[23:13]  great
                
+[23:13]  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]  0.3 adds a kademliaDatabaseManager 
                
+[23:13]  right now we use a BroadcastDatabaseManager 
                
+[23:13]  (aka gnunet ;) 
                
+[23:14]  trivial to implement and functional for small networks, but we need the kademlia to scale 
                
+[23:14]  0.4) is functional, secure, anonymous, scalable, non-harvestable 
                
+[23:14]  that adds trusted links 
                
+[23:14]  jrand0m,  and how much of a dev challenge is it to implement kademlia?
                
+[23:14]  I have two ideas for trusted links.. one is more easily implementable and usable 
                
+[23:15]  kademlia will probably take a full week 
                
+[23:15]  (to get right) 
                
+[23:15]  note that all of this has lots of room for refactoring and tuning.  I'm aiming functional first, then we tune. 
                
+[23:16]  Are you certain you will be able to develop and test that quickly?
                
+[23:16]  I am certain of nothing 
                
+[23:16]  thats just my estimate 
                
+[23:16]  co, hegets functional, we test
                
+[23:16]  Are you sure?
                
+[23:16]  (sorry)
                
+[23:16]  Ryan_Singer: I see.
                
+[23:17] * jrand0m <3 people who test :)
                
+[23:17]  When you say "we" test. Is there any place for non-coders to help with the testing?
                
+[23:17]  Myself248> probably not until 0.4 
                
+[23:17]  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]  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]  Document, document, document.
                
+[23:18]  is there any though being put into active monitoring of network internals, or is it straightforward?
                
+[23:18]  yes dm, absolutely 
                
+[23:18]  one of the key pieces of i2np is the inclusion of stats in the routerInfo strutures published 
                
+[23:18]  jrand0m: do a s/0./0.0./ ;)
                
+[23:18]  the initial revs will publish real stats so we can tune 
                
+[23:19]  later revs will either not publish any stats or publish fake ones 
                
+[23:19] * jrand0m does not do 0.0
                
+[23:19]  ok, I'm here
                
+[23:19]  wb shardy 
                
+[23:19]  sorry for being late, forgot about this window being open, heh
                
+[23:19]  cool.
                
+[23:19]  is there a higher level document describing the archetecture for the network under .4?
                
+[23:19]  off with your head 
                
+[23:20]  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]  0.4 is full i2np as described in the spec, just not optimally implemented 
                
+[23:20]  oh and jrand0m, I'll check out the DH optimization for you
                
+[23:20]  word, gracias  
                
+[23:20]  can I get those docs?
                
+[23:21]  the overview is at (Link: http://www.invisiblenet.net/i2p/i2p_philosophy.pdf)http://www.invisiblenet.net/i2p/i2p_philosophy.pdf 
                
+[23:21]  they're on the wiki I think?
                
+[23:21]  hte old overview docs... hmm 
                
+[23:21]  (i2p specs are at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs) 
                
+[23:21]  They are on (Link: www.invisiblenet.net/i2p/.)www.invisiblenet.net/i2p/.
                
+[23:21]  right beefbroth 
                
+[23:22]  though there are old docs in html format w/ ugly ms paint pictures from before showing how tunnels work... 
                
+[23:22]  I should know, I've read them enough
                
+[23:22]  hehe 
                
+[23:22]  Unless those are older versions or mirrors.
                
+[23:22]  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]  jrand0m: the precalc looks good
                
+[23:23]  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]  ok, thats the microroadmap 
                
+[23:25]  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]  that's okay, even that would be the fastest ever implementation of a network of this type ;)
                
+[23:26]  lol
                
+[23:26]  when reading jrand0m's time estimates here, please remember that he has been drinking whiskey for the last 4 hours :-P
                
+[23:26]  heh 
                
+[23:26]  ok...apps/usage?
                
+[23:26]  good whiskey at that ;) 
                
+[23:26]  ok, apps/usage 
                
+[23:27]  0.7 in 4 seconds....3...2...1..!!
                
+[23:27]  I'm aiming for low hanging fruit here - these are things that we can do with 0 or minimal new code. 
                
+[23:27]  How are you supposed to code properly if you're stone sober?
                
+[23:27]  all of these make significant use of mihi's kickass i2ptunnel 
                
+[23:27]  ChZEROHag: Easily.
                
+[23:27] *** mihi has changed the topic on channel #iip-dev to  0.7 in 4 seconds....3...2...1..!!
                
+[23:28]  using the i2ptunnel, we can do the following without writing any new code: 
                
+[23:28]  public ww proxy (using i2ptunnel + squid) 
                
+[23:28] * dm tips his hat to mihi.
                
+[23:28]  JAP (using i2ptunnel + JAP) 
                
+[23:28]  you cannot kick asses though i2p (not through a tunnel either...)
                
+[23:28]  browse www anon (i2ptunnel + web browser) 
                
+[23:28]  run an i2p web server (i2ptunnel + httpd) 
                
+[23:29]  Very nice. Bravo, mihi.
                
+[23:29]  cvs outproxy (i2ptunnel) [e.g. cvs outproxy to sourceforge for anon freenet dev] 
                
+[23:29]  cvs client, cvs server 
                
+[23:29]  IM app, pop3 server, imap server, opennap 
                
+[23:29]  those are all really low hanging fruit 
                
+[23:29]  okay, now all we need is i2p :)
                
+[23:30]  right ;) 
                
+[23:30]  wouldn't i2p webserver kinda supplant freenet? :)
                
+[23:30] * jrand0m thinks that qualifies as a faq I should answer
                
+[23:30]  jrand0m,  but they are also very valuable
                
+[23:30]  From that list, I'd consider cvs more important/useful
                
+[23:30]  Partly because I wish to remain anonymous, but also because if anonymous www is provided you'll get lusers
                
+[23:30]  i2p + web doesn't supplant freenet - freenet adds significant value on top of an anon comm framework - content distribution 
                
+[23:31]  And at the moment the idea of anonymous email is scary :)
                
+[23:31] * dm writes down: "no lusers"
                
+[23:31]  cvs definitely is in the top 3 
                
+[23:31]  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]  ChZEROHag,  if it's scalable thats a goodthing
                
+[23:31]  dm: lusers are only a problem during the early stages, but they tend not to use cvs
                
+[23:31]  okay, add lots of hashcash to any anon email thing.
                
+[23:31]  Or, for that matter, even know what (or that) it is
                
+[23:31]  I think one of the tests that needs to be done is a test attack on the network.
                
+[23:31]  yes beefbroth, once i2p does what we aim at, freenet will most likely adjust to make use of it 
                
+[23:32]  Sorry if that is offtopic.
                
+[23:32]  Myself248: just add a redirector to an anon remailer.
                
+[23:32]  no, thats definitely on topic co - attacking this network is key 
                
+[23:32]  Myself248: hashcash is primarily to stop flooding while we're forced to use the ancient protocol that is 'irc'
                
+[23:32]  Not to stop what could be termed 'abuse'
                
+[23:32]  right mihi.  though perhaps mixminion run over i2p would be useful 
                
+[23:33]  right, hashcash is even built into i2p itself to keep messages from being delivered a single hop unless they "pay up" 
                
+[23:33]  jrand0m,  we could run imap over this easily?
                
+[23:33]  absolutely 
                
+[23:33]  impressive
                
+[23:33]  imapd with an i2ptunnel pointing at it, with i2ptunnel on the client pointing at that tunnel's destination 
                
+[23:34]  and freenet search engines :)
                
+[23:34]  ftp or several non-jabber instant messengers will make problems...
                
+[23:34]  right, things that require two connections are more complex 
                
+[23:34]  jrand0m: hashcash in i2p?
                
+[23:34]  I shall bug you about that when this is over.
                
+[23:34]  hashcash in i2p? nice. 
                
+[23:34]  we're getting ahead of ourselves! oh alright, who cares.. QUAKE + IIP!!!!!!
                
+[23:34]  sorry, I2p :)
                
+[23:34]  lol dm 
                
+[23:35]  Those of us with little CPUs get nervous when someone says hashcash, but as an anti-spamming measure I understand it.
                
+[23:35]  dm: That is *reallY* getting ahead of ourselves.
                
+[23:35] * mihi is jabber:schierlm@a-message.de ;)
                
+[23:35]  yes ChZEROHag - Destination == public signing key (DSA) + public encryption key (ElGamal) + certificate (either null or hashcash(keys)) 
                
+[23:35]  is the i2p tunnel static or dynamic on the client end?
                
+[23:35]  beefbroth: atm it is all static. but you could use a socks proxy as dest. ;)
                
+[23:35]  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]  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]  beefbroth: It can be dynamic.
                
+[23:36]  the potential applications of the "low-hanging fruit"  here are very impressive
                
+[23:36]  right mihi 
                
+[23:36]  "eleventy".  heh 
                
+[23:36]  the low hanging fruit is essentially 'normal' internet apps, but anonymously
                
+[23:36]  right?
                
+[23:36]  right 
                
+[23:36]  yes
                
+[23:36]  (quake)
                
+[23:37]  0.1 runs them securely, 0.2 runs them anonymously, 0.3 runs them scalably, 0.4 runs them non-harvestably 
                
+[23:37]  (we're @ 0.1 now) 
                
+[23:37]  what do you mean by non-harvestably?
                
+[23:37]  Sorry, what is harvestable again?
                
+[23:37]  dm: Unfortunately we've ben held back enough that realtime is after more than 30 years still not 'normal'
                
+[23:37]  Phew. I was hoping someone would ask that. ;)
                
+[23:37]  loggable
                
+[23:37]  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]  oh, like you can do with gnutella. :)
                
+[23:38]  secret-servicy like goons
                
+[23:38]  right 
                
+[23:39]  ah, gotcha.
                
+[23:39]  ok, but yeah, thats the microroadmap. 
                
+[23:40]  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]  jrand0m,  and we will see .4 when?
                
+[23:40]  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]  1.0 should be stable.
                
+[23:40]  Let 1.0 be functional and safe.
                
+[23:40]  dittos co
                
+[23:41]  1.0 should be functional, stable and safe
                
+[23:41]  jrand0m: My philosophy, regarding version numbers, is if in doubt, copy Linux
                
+[23:41]  5.0 can be "perfect". Free software people are overly afraid of version number bloat.
                
+[23:41]  word 
                
+[23:41]  jrand0m, v1 of things are never perfect :)
                
+[23:41] *** dm (~gj@anon.iip) has joined channel #iip-dev
                
+[23:41]  people dont expect them to be perfect either
                
+[23:41]  did I miss 1.0?
                
+[23:41]  mrflibble: People don't expect any software to be perfect. People use windows.
                
+[23:41]  this software will beGPL orLGPL?
                
+[23:41]  cool, I've already gotten flack for 1.0 being not-perfect yet 
                
+[23:41]  That doesn't mean it shouldn't be.
                
+[23:41]  good point ChZEROHag
                
+[23:42]  ah shit, I did didn't i..
                
+[23:42]  dm: stop kidding
                
+[23:42]  yup, u did
                
+[23:42]  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]  alright alright I'm sorry :(
                
+[23:42]  actually, I take that back 
                
+[23:42]  I used the Base64.java from freenet too 
                
+[23:43]  are we still on agenda item 0.3 Apps ?
                
+[23:43]  so base64 is GPL :) 
                
+[23:43]  and the IM client will be GPL
                
+[23:43]  oh yeah, we're on 0.3 aren't we 
                
+[23:43]  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]  heh thecrypto 
                
+[23:43]  GPL sounds good to me
                
+[23:43]  w0ah, 23 users 
                
+[23:43]  we're on agenda item 6.02E23, random crap. :)
                
+[23:43]  jrand0m,  if you get time, I want to talk to you about liscencing and potential consulting gigs
                
+[23:43]  cool Ryan_Singer 
                
+[23:43]  Though as someone (Fillament?) pointed out - if someone breaks the license how is an anonymous person going to do anything about it?
                
+[23:43]  jrand0m: 22 ;)
                
+[23:43]  ChZEROHag> read my license on flinks ;) 
                
+[23:43]  we need an anonymous court system.
                
+[23:44] * mihi is here twice
                
+[23:44]  Myself248> its called yodel ;) 
                
+[23:44]  "The court now hears docket number 34534, J. Doe v. J. Doe"
                
+[23:44]  ChZEROHag,  the reason I ask is for corporations to make use of this software for security against industrialespionage
                
+[23:44]  Naming server will be licensed under GPL as well.
                
+[23:44]  lol
                
+[23:44]  "Baliff, aren't those the same parties as the last 34533 cases we've heard?"
                
+[23:44]  well
                
+[23:45]  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]  shardy: You mean public domain?
                
+[23:45]  i think that was co's lead in to 0.4 agenda item :-P
                
+[23:45]  shardy> the specs are public and open.  I have not asserted copyright on the specs. 
                
+[23:45]  shardy,  no, we would like work on the protocol to stay available
                
+[23:45]  public domain, bsd license, "do whatever you want just give us credit please" license, etc
                
+[23:45]  the code is GPL for the router.  one client api implementation in java is GPL 
                
+[23:46]  check out the liberty protocol.... (Link: http://projectliberty.org)http://projectliberty.org
                
+[23:46]  jrand0m: ok cool. gotcha.
                
+[23:46] * jrand0m has thought about "no government use" licenses ;)
                
+[23:46]  ok, the reason I tossed 3.0) apps into the list of issues is this 
                
+[23:46]  we need help. 
                
+[23:46]  help with what?
                
+[23:46]  i2ptunnel is good code.  i2p's router will be good code. 
                
+[23:47]  what we need is for people to start figuring out the nuts and bolts of release engineering 
                
+[23:47]  why do you need apps if you can just use i2ptunner?
                
+[23:47]  jrand0m: come again?
                
+[23:47]  aka, how to actually package something up that joe sixpack can download and browse the web 
                
+[23:47]  dm: Why do you need apps if you can just use telnet?
                
+[23:47]  what?
                
+[23:47] * dm scratches his head.
                
+[23:47]  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]  dm: To use i2ptunnel would be like having a working car and then dragging it around on a handcart
                
+[23:48]  ok, thats just that.  I just wanted to mention in case people had spare time :) 
                
+[23:48]  ok, 4.0) 
                
+[23:48]  naming service 
                
+[23:48]  I can see he's trying to make a point.
                
+[23:48]  hi co, hows it going?  :) 
                
+[23:48]  The naming server must be GPL, since at least the Java implementation uses code from the client library to contact routers.
                
+[23:49]  but we just spent 20 minutes going: I2Ptunnel + web server!, I2Ptunnel + quake! ;)
                
+[23:49]  Or, in computing terms, like doing all your internet stuff with telnet instead if directly on the ip stack
                
+[23:49]  I did not do much last week. I released the client API, which also needs work.
                
+[23:49]  i2ptunnel is an interrim solution
                
+[23:49]  I will have time this week, though, to begin implementing the naming server.
                
+[23:49]  cool 
                
+[23:49]  where is the client api again? 
                
+[23:50]  on the mailing list ;)
                
+[23:50]  One of its assumptions is that destinations can be encoded in base64, which is why I asked the question about that earlier.
                
+[23:50]  ChZEROHag> in some ways its interim 
                
+[23:50] * jrand0m !thwaps self
                
+[23:50] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev
                
+[23:50]  so is TCP!
                
+[23:50] *** yodel (yodel@anon.iip) has joined channel #iip-dev
                
+[23:50]  'lo yodel 
                
+[23:50]  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]  I will put the naming service specification and client API into CVS.
                
+[23:50]  wb thecrypto 
                
+[23:50]  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]  beefbroth> with the naming service or without? 
                
+[23:50]  heh mihi 
                
+[23:50]  avoiding the squatting, etc. that has plagued DNS
                
+[23:50]  can someone send me what happened?
                
+[23:51]  jrand0m: with. i think without would be a long string of numbers.
                
+[23:51]  ChZEROHag: You will register with a group of naming servers, then will use the name of that group to identify yourself.
                
+[23:51]  As in IM.beefbroth.mygroup if you provide IM service.
                
+[23:51]  oops, s/iip/i2p
                
+[23:51] *** godmode0_ (~mode@anon.iip) has joined channel #iip-dev
                
+[23:51] *** Signoff: godmode0 (EOF From client)
                
+[23:51]  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]  Yes, it will be possible for someone to register the username beefbroth with group2.
                
+[23:51]  in the 4 minutes i was gone
                
+[23:52]  co: So the only issue is the .mygroup uniqueness?
                
+[23:52]  And who gets the group 'com'? :-)
                
+[23:52]  and that is selected by the client 
                
+[23:52]  ChZEROHag: i2p is not COMmerical
                
+[23:52]  (e.g. you tell your ns client lib "group '.com' is group 0123ff33aefcbb34fe 
                
+[23:52]  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]  ChZEROHag: I am not sure who gets the "com" group.
                
+[23:52]  Good question.
                
+[23:53]  beefbroth: except the "regular web" is no longer only 3 letter lds
                
+[23:53]  beefbroth: or add a .i2p to all addresses.
                
+[23:53]  beefbroth: That illusion is only present in america
                
+[23:53]  tlds.
                
+[23:53]  to start with, we may just want to initially have one group of naming servers, ".i2p" 
                
+[23:53]  beefbroth: The naming server software permits you to have up to 32 letters.
                
+[23:53]  Elsewhere we use the 2-letter country codes given us
                
+[23:53]  .us is also in use in america.
                
+[23:53]  Actually, I wanted the first group to be "test".
                
+[23:53]  as are things like .info and .name
                
+[23:53]  heh 'k 
                
+[23:54]  shardy: yeah, by about 5 people.
                
+[23:54]  But this is perhaps a rant for another time :)
                
+[23:54]  actually... 
                
+[23:54]  there's even a .museum
                
+[23:54]  jrand0m,  using .12p sounds good
                
+[23:54]  I ran into a distributed DNS based of JXTA the other day 
                
+[23:54]  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]  YEs that bit makes perfect sense
                
+[23:55]  ChZEROHag: (Link: http://www.nic.us/press/audio/dotus-mayEM.wav)http://www.nic.us/press/audio/dotus-mayEM.wav ;)
                
+[23:55]  co> can't you just say "well, they 'think' they're .com, but I say .com is run by group2"? 
                
+[23:55]  What I'm getting at, I suppose, is does it rely on first-come-first-served?
                
+[23:55]  You may configure your client to do anything.
                
+[23:56]  how does the JXTA name system work?
                
+[23:56]  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]  ChZEROHag: In registering your username with a group, yes.
                
+[23:56]  jrand0m: I will look at that after the meeting.
                
+[23:56]  jxta runs naming servers off rendevous points 
                
+[23:56]  mihi: wassat?
                
+[23:56]  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]  beefbroth: I think not.
                
+[23:57]  ChZEROHag: listen to it. why xxx million americans prefer .us over .com
                
+[23:57]  68 million
                
+[23:57]  As I envision it, people setting up groups will announce those groups.
                
+[23:57]  mimicing?  they can't mimic as the servers in the group are authenticated by public key systems 
                
+[23:58]  however, if groups allow non-trusted members to join the group, they can be taken over trivially. 
                
+[23:58]  but how is the key exchange done?
                
+[23:58]  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]  mihi: Well I've always said it makes sense to prefer it, patriotism and whatnot, I've just never really seen it.
                
+[23:58]  what happens if two groups of naming servers both claim to resolve the .i2p group?
                
+[23:58]  Good question, though, and I will think over it again, carefully.
                
+[23:58]  Anyway, I shall have a listen
                
+[23:58]  shardy> no key exchange - key publishing 
                
+[23:58]  i see, good point
                
+[23:58]  co: Yeah that's another thing I was trying to get at
                
+[23:58]  but keys can still be intercepted if they're published online
                
+[23:58]  beefbroth> no one claims anything.  your client says "i2p == [dest1, dest2, dest]" 
                
+[23:59]  what we need is a trust-based dns system :)
                
+[23:59]  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]  Thank you for bringing this up.
                
+[23:59]  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]  Yeah we have one - everyone trusts IANA (or whatever they call themselves) or else.
                
+[23:59] * shardy ducks
                
+[23:59]  :-D
                
+[23:59]  they're trying that with dnssec, but of course that's not anonymous
                
+[00:00]  what this naming service does is get away from root servers 
                
+[00:00]  you could always have an i2p homepage that listed active naming groups and authorites?
                
+[00:00]  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]  shardy: I think I covered key exchange in the spec. If not, tell me.
                
+[00:00]  but packaging it oob makes it better
                
+[00:00]  co: I'll check it out. 
                
+[00:00]  shardy> oh, right.  yes, people need to be able to trust the code they download 
                
+[00:00]  beefbroth: Certainly.
                
+[00:01]  aah that reminds me
                
+[00:01]  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]  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]  heh ok 
                
+[00:01]  Please understand that the naming server specification is still open to suggestions for improvement.
                
+[00:02]  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]  I do not claim it is perfect or finalized at this time.
                
+[00:02]  heh I hope its a long flight 
                
+[00:02]  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]  And I have to write the code.
                
+[00:02]  I think we can move on to the next topic now.
                
+[00:02]  'k 
                
+[00:02]  5.0) IM 
                
+[00:03]  hi thecrypto 
                
+[00:03]  names should not be able to clash with base64 representations.
                
+[00:03]  hi
                
+[00:03]  okay
                
+[00:03]  and the namin server should transparently return bas64 addressas as is.
                
+[00:03]  mihi: Very well, I will try to avoid that problem.
                
+[00:03]  first since my e-mail isn't working again (damn spammers)
                
+[00:03]  (all classes that extend DataStructure have String .toBase64() and .fromBase64(InputStream) ) 
                
+[00:03]  i'll answer whit's questions about me system here
                
+[00:04] * jrand0m loads up co's email
                
+[00:04]  jrandom? why Inputstream and not Reader?
                
+[00:04]  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]  if you want a Reader, just run an InputStreamReader, you brat 
                
+[00:04]  base64 is characters, not bytes in my opinion.
                
+[00:04]  jrand0m: IM == Instant Messaging?
                
+[00:04]  yes ChZEROHag 
                
+[00:04]  if people have a problem with that, give me a suggestion for what to call it about
                
+[00:05]  jabber?
                
+[00:05]  IM == my own distributed IM network
                
+[00:05]  you should call it "bob"
                
+[00:05]  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]  How about IM application?
                
+[00:05]  (anonabber)
                
+[00:05]  jrand0m: I see.
                
+[00:05]  jabber requires a centerized server
                
+[00:05]  terminology doesn't matter to me.  I like shardy's idea 
                
+[00:05]  thecrypto: Nothing *requires* a centralised server
                
+[00:05]  and i cannot spell today so bear with me
                
+[00:06]  That's just the way things are written
                
+[00:06]  (though I prefer Betty) 
                
+[00:06]  so you want me to call it I2PIM bob?
                
+[00:06]  :)
                
+[00:06]  how about wilma? 
                
+[00:06]  fred is taken thoug 
                
+[00:06]  How about distributed IM?
                
+[00:06]  DIM, heh 
                
+[00:06]  But then, distributed IM *application*?
                
+[00:06]  AIM, anonymous Instant messaging!
                
+[00:06]  bad acronym :)
                
+[00:07]  then we can take over AOL.
                
+[00:07]  ohh i can just wait for AOL to get wind of that
                
+[00:07]  dm: That would realy piss certain wankers off. I like it.
                
+[00:07]  heh do it 
                
+[00:07]  thecrypto,  will webe able to implement IM in a decentralised way, or will it have to be centrallized?
                
+[00:07]  dm: Good idea. I would back that acronym.
                
+[00:07]  the way I've read thecrypto's docs, the IM is fully decentralized 
                
+[00:07]  i am implementing a distributed IM, it's in the CVS
                
+[00:07]  I would vote against anything that is going to confuse people
                
+[00:08]  AOL TimeWarner changed it's name to Time Warner
                
+[00:08]  beefbroth: I would too, but the vote to piss AOL off outweighs that.
                
+[00:08]  You want the system to be familiar enough that people won't be afraid to install it, but different enough to differentiate
                
+[00:08]  actually, thats a good point 
                
+[00:08]  I2PIM is the name of the application
                
+[00:08]  being transparently anonymous isn't useful if people don't understand what anonymous is. 
                
+[00:09]  Oh wait, I have something like this down on paper
                
+[00:09]  I like the crypto's idea
                
+[00:09]  what "network" I2PIM runs on is what I'm looking for
                
+[00:09]  teaching people how to protect themselves is a really important thing 
                
+[00:09]  i was thinking Presence System?
                
+[00:09]  hypethe security aspect of anon
                
+[00:09]  I2M (instant 2 messaging)
                
+[00:09]  Although I only called it XIrc
                
+[00:10]  you're the man thecrypto, whatever works for ya ;) 
                
+[00:10]  and in the I2M logo, the 2 will be really small :)
                
+[00:10]  well I2P expands to Invisible ... jrand0m ?
                
+[00:10]  The main thing I liked about it was that everyone was called a Borg and they chatted in Collectives
                
+[00:10]  i2p = i^2p (invisible internet project) 
                
+[00:10]  I thought the P stands for protocol.
                
+[00:10]  that too 
                
+[00:10]  well, actually, no 
                
+[00:11]  so it's Invisible Internet Project Instant Messaging
                
+[00:11]  i2np is the protocol 
                
+[00:11]  i2p is the project 
                
+[00:11]  I thought it stood for "poop"
                
+[00:11]  i2cp is the client proto 
                
+[00:11]  thecrypto: You are right, the name does not matter too much.
                
+[00:11]  i2m = i^2m = instant invisible messaging
                
+[00:11]  so next topic then
                
+[00:11]  ok....so, we're drifting off agenda...are we done with IM?
                
+[00:11]  if "bob" isn't good enough, we can call it "jimbob"
                
+[00:11]  0k, 6.0) administravia 
                
+[00:11]  no, still more here
                
+[00:12]  sorry
                
+[00:12]  It's administrivia.
                
+[00:12]  no it's IM
                
+[00:12]  nop> give me root.  I need to get anon cvs, bugzilla, and cvsweb installed. 
                
+[00:12]  i wasn't finished
                
+[00:12]  :)
                
+[00:12]  rewind!
                
+[00:12] * jrand0m backs up
                
+[00:12]  5.1) thecrypto v2 
                
+[00:12]  what else is there in IM, thecrypto?
                
+[00:13]  thecrypto: just talk on; /me idi it the same way as i missed the naming services
                
+[00:13]  okay, the thing about presences communicating is different
                
+[00:13]  not everyone knows everyone else
                
+[00:13]  there is practically no way to "stalk" someone
                
+[00:13]  you have to ask to be shown
                
+[00:14]  in anonymous networks, usually no one knows anyone else ;)
                
+[00:14]  (as long as people's Destination is random) 
                
+[00:14] *** Signoff: pitu (Lost terminal)
                
+[00:14]  what do you mean?
                
+[00:14]  Alice wants to talk to Bob
                
+[00:14]  mihi> though the naming service allows search by service 
                
+[00:14]  (service being IM, www, etc) 
                
+[00:14]  Alice finds Bobs IM destination some how, prolly by the naming service
                
+[00:15]  So Alice sends a message to Bobs IM destination
                
+[00:15]  yes?
                
+[00:15]  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]  but there is no central presence server, Alice can also just see her message disappear and not get a response
                
+[00:16]  ok, like MSN then?
                
+[00:16]  (though Alice can know that Bob ignored her) 
                
+[00:16]  and Alice can't just put Bob on her buddy list and wait for him
                
+[00:16]  thecrypto,  ok...how is this different then properly configured Y!, MSN or AIM..apart from the nocentral server bit
                
+[00:16]  because Bob has to send a message to Alice to see her sign on
                
+[00:16]  oh
                
+[00:16]  ok, it doesn't change anything as far as the user is concerned, but I see what you mean.
                
+[00:17]  thecrypto> not quite true 
                
+[00:17]  got it..no buddylist functionality...
                
+[00:17]  oh, well, hmm, technically... 
                
+[00:17]  Ryan_Singer: no there is still a buddy list
                
+[00:17]  how does alice send bob a message if she can't see him?
                
+[00:17]  you just have to try random contacts in case they are there?
                
+[00:17]  bob has to send a message to alice's router, which can happen without alice knowing it 
                
+[00:17]  Alice can just randomly try
                
+[00:18]  that's not very convenient? you go online and have to send everyone a message saying (you there?, you there?)
                
+[00:18]  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]  beefbroth: that was just want i'm saying
                
+[00:18]  ok, so similar to current scheme but you are invisible by default.
                
+[00:18]  gotcha.
                
+[00:19]  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]  if you want to
                
+[00:19]  So the user controls who can see him/her/it.
                
+[00:19]  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]  when you get off do you first send a msg that says "I'm getting off"?
                
+[00:20]  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]  hopefully
                
+[00:20]  Ryan_Singer> or just have a periodic "I'm still on" ping 
                
+[00:20]  (and missing ping == off) 
                
+[00:21]  keep-alive type deal?
                
+[00:21]  It might need to "ping" the other IM user every so often to make sure there wasn't an unintentional disconnect
                
+[00:21]  if Bob has Alice on his buddy list and Bob recives and Online message from Alice the return message is automatic
                
+[00:21]  heh
                
+[00:21]  If Bob doesn't have Alice on his buddy list and bob recives an online message from alice, the user is propmted
                
+[00:21]  ok, so the IM experience is the same as it is now. Just wanted to confirm that.
                
+[00:22]  just you now have a confirm on buddy adds
                
+[00:22]  which i think only ICQ has
                
+[00:22]  will the IM app be a stand alone or will I be able to use trillian? 
                
+[00:22]  yeah, that's how MSN works.
                
+[00:22]  [etc] 
                
+[00:22]  thecrypto: ICQ only pretends to require confirmation
                
+[00:22]  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]  jrand0m: i'll make a spec, trillian can either give me a plugin interface or they can write thier own
                
+[00:23]  i will be writing a plugin for gaim at leasty
                
+[00:23]  along with a standalong client
                
+[00:23]  cool 
                
+[00:23]  which is built to be used with the network
                
+[00:23]  does gaim support file xfer or will that be the benefit of the i2pim client? 
                
+[00:23]  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]  i'll try to make the gaim plugin work as well as the standalong, but i don't know
                
+[00:24]  thecrypto: Let's have the standalone application first.
                
+[00:24]  gaim file transfer i think only works on AIM
                
+[00:24]  so it might take some wrangling to get it into a plugin
                
+[00:24]  ok..I think we all understand this now...any more IM issues?
                
+[00:25]  and co's final thing
                
+[00:25]  gaim suffers problems with it's IM xfers for people using NAT
                
+[00:25]  more than one person can have the same name
                
+[00:25]  they will have unique destinations
                
+[00:25] *** Signoff: mihi (Ping timeout)
                
+[00:25]  All right.
                
+[00:25] * mihi_backup is still here...
                
+[00:25]  but someone can't masquerde
                
+[00:26]  heh nice1 mihi_backup 
                
+[00:26]  If you use the naming server, it will be "Bob from group1" and "Bob from group2".
                
+[00:26]  With unique destinations.
                
+[00:26]  right thecrypto.  names are arbitrary.  kind of like dns ;) 
                
+[00:26] *** mihi (~none@anon.iip) has joined channel #iip-dev
                
+[00:26]  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]  mihi: your backup talked while you were gone.
                
+[00:27]  if they person is trying to masquerde Bob, you'll know, otherwise, you can alias them out
                
+[00:27]  i know...
                
+[00:27]  "someone called bob"?  says who?  they call themself bob?  or some group calls them bob?  or you call their dest bob? 
                
+[00:27]  there is a feild in the presence called name
                
+[00:27]  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]  As an aside, should I make the NS entity names case insensitive?
                
+[00:28]  probably co 
                
+[00:28]  base64 things must be case sensitive still ;)
                
+[00:28] * jrand0m doesn't want people spoofing Jrand0m
                
+[00:28]  mihi: Entity names, not destinations.
                
+[00:28]  right right mihi 
                
+[00:29]  (well, people can spoof jrand0m all they want.  I just want jrandom back) 
                
+[00:29]  Go on, thecrypto.
                
+[00:29] *** Signoff: UserX_ (Ping timeout)
                
+[00:29]  that's all i have
                
+[00:29]  finally :)
                
+[00:29]  co: you should be able to place a destination wherever you can place an entity name.
                
+[00:29]  like it is with dns names and IPs
                
+[00:29]  mihi: Good point. I will add that to the specification.
                
+[00:29]  jrand0m: actully it's kinda like ICQ except you tell people what you'd like your alias to be
                
+[00:30]  which i think they do now
                
+[00:30]  The idea, though, is that it will be much shorter to type names than destinations.
                
+[00:30]  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]  ok guys...I have a meeting... jrand0m, anonymail me
                
+[00:30]  'k adios 
                
+[00:30]  jrand0m: yes, and it should return that dest itself, and not "not found"
                
+[00:31]  right 
                
+[00:31] *** Signoff: Ryan_Singer ((null))
                
+[00:31]  ok.  we're at 7.0)  
                
+[00:31]  questions 
                
+[00:31]  hi 
                
+[00:31]  What about 6.0) Administrivia?
                
+[00:32]  Or were you done with that?
                
+[00:32]  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]  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]  you volunteering? 
                
+[00:33]  (aka yeah, that'd be great) 
                
+[00:33]  If I learn how to make a package for my distribution :)
                
+[00:33]  what distro do you use? 
                
+[00:34]  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]  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]  jr makes for a good manager :)
                
+[00:34]  yes co, simpler, but not as scalable 
                
+[00:34] *** UserX_ (~User@anon.iip) has joined channel #iip-dev
                
+[00:34]  yes, but some people don't want IRC
                
+[00:35]  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]  thecrypto: Good point, though I2P will anonymize people's IP addresses.
                
+[00:35]  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]  awesome beefbroth 
                
+[00:35]  if we have IM and IRC, more adoption
                
+[00:36]  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]  thecrypto> instant adoption: opennap 
                
+[00:36]  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]  IRC is quite tough though isn't it?
                
+[00:36]  distributed IRC that is...
                
+[00:36]  mihi: Of course. I forgot that. Thank you for reminding me. Objection withdrawn.
                
+[00:37]  dm> irc can have multiple irc servers (ala efnet, etc) that talk to each other through i2p 
                
+[00:37]  do you mean an "irc lookalike" chat protocol?
                
+[00:37]  or adapting irc?
                
+[00:37]  with people talking to each other by tunneling to one of the irc servers via i2p 
                
+[00:37]  irc with servers behind i2p is fine, I'm saying without servers. Doesn't matter I guess.
                
+[00:38]  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]  anyway, it's off-topic.
                
+[00:39]  carry on!
                
+[00:39]  any other questions?   
                
+[00:39]  anyone read the specs yet?  ;) 
                
+[00:39]  (other than beefbroth, who has them memorized) 
                
+[00:39] * dm looks at the ceiling.
                
+[00:40]  ok, 100 minute meeting it is then 
                
+[00:40]  i'm reading the, when i need something :)
                
+[00:40]  specs!
                
+[00:40]  That's what I forgot!
                
+[00:40]  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/i2p2www/meetings/60.log b/i2p2www/meetings/60.log
new file mode 100644
index 00000000..12262e42
--- /dev/null
+++ b/i2p2www/meetings/60.log
@@ -0,0 +1,279 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 60{% endblock %}
+{% block content %}
                
+[22:53]  0.x) welcome 
                
+[22:53]  1.x) todo before i2p 0.2: 
                
+[22:53]  1.1) bw limiting 
                
+[22:54]  1.2) AES the tcp transport 
                
+[22:54]  1.3) package up [distro, building, seeding, running] 
                
+[22:54]  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]  2.x) apps 
                
+[22:54]  2.1) ns 
                
+[22:54]  2.2) i2pim 
                
+[22:54]  2.3) i2ptunnel 
                
+[22:54]  3.x) ??? 
                
+[22:54]  0.x) welcome 
                
+[22:54]  welcome to meeting 60 
                
+[22:54]  thanks
                
+[22:55]  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]  hi
                
+[22:55] * jrand0m takes back the german beer
                
+[22:55]  i'm not awake
                
+[22:55]  but not asleep either ;)
                
+[22:55]  heh interesting 
                
+[22:56]  ok, 1.{x,1}) todo before 0.2 
                
+[22:56]  i just remembered the meeting it today
                
+[22:56]  i was just discussing wireless cards
                
+[22:56]  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]  there are three things that need to get implemented first though.  bandwidth limiting, AES on the TCP, and ElG session ack 
                
+[22:57]  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]  the code is committed to tie it in, but the limit is set at infinity atm 
                
+[22:58]  for point 1.2, the TCP transport has key exchange and authentication, but needs encryption 
                
+[22:59]  nop/semi-awake-thecrypto> thoughts on AES for streaming?   
                
+[22:59]  carefully
                
+[22:59]  !thwap 
                
+[22:59]  sorry
                
+[23:00] * CounterRev eats popcorn in the grand stands
                
+[23:00]  CBC using first 16 bytes of H(sessionKey) work, or should we do something else? 
                
+[23:00]  I can't remember where that originated, exclamation mark before an action.
                
+[23:00]  i realized when the agenda started being pasted today was tuesday
                
+[23:00]  dm> some eggdrops use them as command identifiers 
                
+[23:01]  why not use more bits from the DH for that?
                
+[23:01]  hmm? 
                
+[23:01]  i don't see any problem for that
                
+[23:01]  for the IV
                
+[23:01]  more bits of what?  X, Y, x, y? 
                
+[23:02] *** mihi (mihi@anon.iip) has joined channel #iip-dev
                
+[23:02]  K
                
+[23:02]  !thwap thecrypto
                
+[23:02]  what?
                
+[23:02]  he said X,Y,x or y
                
+[23:02]  AES 256 only has a 16 byte K 
                
+[23:02]  er, IV 
                
+[23:03]  the session key is 32 bytes 
                
+[23:03]  but you generate many more
                
+[23:03]  (originally I was stupid and made the IV the first 16 bytes of the key ;) 
                
+[23:03]  so use 48 bytes from the DH
                
+[23:04]  we all make mistakes.
                
+[23:04]  hmm ok, pulling more bytes off the modPow will work.  cool.  but why 48?   
                
+[23:04]  (why not just another 16?) 
                
+[23:05]  i meant 32+16
                
+[23:05]  ah 'k 
                
+[23:06]  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]  (rekey would be just drop the connection and re-DH) 
                
+[23:06]  ok, 1.3) packaging up for 0.2 
                
+[23:07]  that just means a make / ant script, install / build doc, plus a method for distributing seed routerInfo references  
                
+[23:07]  (plus, most likely, a set of a few routers for people to connect to) 
                
+[23:08]  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]  the one last point holding up 0.2 is the ElG session ack 
                
+[23:09]  can we use 0.2 to talk to each other?
                
+[23:09]  yes dm 
                
+[23:09]  ok, that's useful.
                
+[23:10]  dm: is talking with you really useful? *veg*
                
+[23:10]  (Killer App: Cyber Sex)
                
+[23:10]  0.2 is definitely not even alpha, so it won't be for the faint of heart 
                
+[23:10]  heh 
                
+[23:10]  (but we need to get some testing and experience on some platforms and usage patterns other than my xp box here) 
                
+[23:11]  I'll take care of the marketing for I2P, I have a knack for it.
                
+[23:11]  lol 
                
+[23:11]  0.2 code name: CyberSex, features, anonymous CyberSex through text.
                
+[23:11]  ok, the ElG session ack stuff.   
                
+[23:11]  I can test on FreeBSD and Gentoo Linux.
                
+[23:11]  awesome wiht! 
                
+[23:11] * popopopo can test Debian
                
+[23:11]  nice 
                
+[23:12]  i can test on mandrake
                
+[23:12] * dm can test windows XP
                
+[23:12]  damn we're going to have pretty good coverage :) 
                
+[23:12] * dm stands out from the crowd.
                
+[23:12]  I can test win2k as well I think, although that should be about the same as XP I think
                
+[23:12]  hopefully 
                
+[23:12]  stick to unix popopopo
                
+[23:13] * thecrypto plays the trump: I can test win 98 :)
                
+[23:13]  uuuugh 
                
+[23:13] * dm welcomes his little brother to the crowd.
                
+[23:13]  I have an old DOS disk around here. Will java run on that? :)
                
+[23:13]  popopopo: Probably not.
                
+[23:13]  actually, probably. 
                
+[23:14]  since gcc supports java 
                
+[23:14]  and djgpp runs on dos 
                
+[23:14]  I2P on DOS, now that would be an accomplishment
                
+[23:14]  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]  Getting PPP working on DOS would be accomplishment enough.
                
+[23:14]  dm: use arachne.
                
+[23:15]  gcj
                
+[23:15]  should work via parallel modem.
                
+[23:15]  oh shit
                
+[23:15]  it's tuesday
                
+[23:15]  haha
                
+[23:15]  ah right popopopo... I always type it wrong 
                
+[23:15]  oops, serial modem ;)
                
+[23:15]  wb nop ;) 
                
+[23:15]  nop: you and me both
                
+[23:15]  haha
                
+[23:16]  sorry
                
+[23:16]  my brain is fried this week
                
+[23:16]  re-cooping
                
+[23:16]  from this weekend
                
+[23:16]  nop: you and me both
                
+[23:16]  ok, the ElG ack stuff. 
                
+[23:16]  (take 4) 
                
+[23:16] * CounterRev could test xp as well "its running.. its running... its stopped"
                
+[23:17]  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]  and "it's bluescreened, it's autorebooting"
                
+[23:17]  (these tags are distributed in the streams, and the session keys are distributed in the ElG) 
                
+[23:18]  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]  brb, playing magic
                
+[23:18]  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]  there are lots of optimizations and tradeoffs here - one could always ElG and just forget about acks 
                
+[23:19]  (trading cpu for bandwidth) 
                
+[23:19]  or one could always require an ack for the first block, and then AES 
                
+[23:20]  but that breaks if the recipient crashes and loses the session key 
                
+[23:20] * nop is backlogging
                
+[23:20]  there are a few different patterns that can be used to implement these sessions 
                
+[23:21]  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]  like P frames in MPEG!
                
+[23:22]  'k, I dont know the MPEG standard really 
                
+[23:22]  sorry, I frames.
                
+[23:23]  the thing is, these ElG messages are expensive.  ~0.5-1.0 seconds 
                
+[23:23]  (cpu time) 
                
+[23:23]  though, hmm, we could precalculate them 
                
+[23:23]  (if we don't rotate session keys) 
                
+[23:23]  which cpu? ;)
                
+[23:23]  sender or reciever cpu time?
                
+[23:24]  exactly mihi - mine.  p4 1.7g.  so we need some perf tuning on the algorithm 
                
+[23:24]  both dm 
                
+[23:24]  (.5 encrypt, .5 decrypt) 
                
+[23:24]  (hand wavey approx) 
                
+[23:24] * mihi has celeron 700
                
+[23:24] * dm has PIII 850
                
+[23:24]  cool.  I'm also getting a sun ultra1 (150Mhz) in a few weeks 
                
+[23:25]  Why you getting a SUN?
                
+[23:25]  I'm leaving the option open for reevaluating our ElG keysize if we need to 
                
+[23:26]  dm> its free (you can buy a u1 for ~50-100 USD).  I also have a few sparc for various purposes 
                
+[23:26]  sweet.
                
+[23:27]  ok, unless anyone has any comments on the ElG stuff, on to agenda item 2.x... 
                
+[23:27]  ok, 2.x) apps 
                
+[23:27]  2.1) ns 
                
+[23:27]  wiht, how goes? 
                
+[23:28] *** Signoff: mihi_backup (Ping timeout)
                
+[23:30]  I have not done any coding on the naming server this past week.
                
+[23:30]  I should say "of" the naming server.
                
+[23:31]  '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]  But I will be working on it this week, and should have something more to report during the next meeting.
                
+[23:31]  cool, great 
                
+[23:31]  what is i2p like sans ns?
                
+[23:32]  icq, I suppose 
                
+[23:32]  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]  you need the secret number for contacting someone, but once you have it, you're ok 
                
+[23:33]  CounterRev: lots of very long destination keys...
                
+[23:33]  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]  ok, 2.2) i2pim... 
                
+[23:33]  thecrypto> you still playing magic?   
                
+[23:34]  i2pim, is that the name of the IM app?
                
+[23:34]  yup 
                
+[23:34]  dm: Yes.
                
+[23:34]  crap! i2m, Invisible Instant messaging.
                
+[23:34]  i^2m, just like i^2p!
                
+[23:34]  sounds like there's a market 
                
+[23:35]  dm: we had that discussion last meeting...
                
+[23:35]  fine fine... I'll have to live with it.
                
+[23:36]  ok, thecrypto is probably still off.  he'll post to the list if there's any news on the i2pim 
                
+[23:36]  (i hope) 
                
+[23:36]  ok, 2.3) i2ptunnel 
                
+[23:36] * jrand0m waves to mihi
                
+[23:37]  jrand0m: I see that we have three applications being developed at this time. Have others been proposed?
                
+[23:37]  oops...
                
+[23:37]  but i have nothing to tell anyway ;)
                
+[23:37]  i2p is in cvs; look @ it ;)
                
+[23:37]  mihi speaks in code.
                
+[23:38]  heh word.  any updates since you added that config> command? 
                
+[23:38]  or rather, his code speaks for itself.
                
+[23:38]  i2ptunnel is in cvs i mean...
                
+[23:38] * nop proposes ex-lax for i2p
                
+[23:38]  jrand0m: nope.
                
+[23:38]  coo' 
                
+[23:38]  would that be like a LaTeX clone nop? 
                
+[23:39]  wiht> some various discussions, but those three have been the main ones discussed 
                
+[23:39]  (the i2ptunnel enables a shitload of normal apps to operate over it) 
                
+[23:40]  has it been tested with anything?
                
+[23:40]  i2ptunnel has been tested extensively with the local router.
                
+[23:40]  (not locally)
                
+[23:40]  I've done some web browsing with it, as well as ssh 
                
+[23:40]  (browsing a single site, that is) 
                
+[23:41] * wiht wonders if that website can still track people through cookies.
                
+[23:41]  great.
                
+[23:41]  sure wiht, cookies are still sent  
                
+[23:43]  ok, thats it for apps atm, and on to 3.x) ??? 
                
+[23:43]  any questions, thoughts, concerns, toenail clippers, hedgehogs? 
                
+[23:43]  a pony? ;)
                
+[23:43]  yeah, I want a pony! 
                
+[23:43] * dm raises his glass.
                
+[23:43]  nop will give you onw...
                
+[23:43]  TO 0.2!!!
                
+[23:44]  oh yeah, mihi pointed out that in 17 minutes we miss the deadline I set in my flog a month ago 
                
+[23:44]  to 1.0! 
                
+[23:45]  7 minutes ;)
                
+[23:45]  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]  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]  yes dm (and files, etc) 
                
+[23:45]  sickening
                
+[23:45]  there will still be room for performance improvements, of course.  there hasn't been much tuning at all 
                
+[23:45]  sorry, I already spent my budget the next month
                
+[23:45]  Alrighty, well if that happens, I will applaud.
                
+[23:45]  pony has to wait
                
+[23:46]  damnit! 
                
+[23:46]  bought a grand piano instead
                
+[23:46]  ;)
                
+[23:46]  heh nice 
                
+[23:47]  jrand0m: here are some virtual ponies for you: (Link: http://tinyurl.com/p8kx)http://tinyurl.com/p8kx
                
+[23:47]  estimated latency?
                
+[23:47]  with network < 30 nodes?
                
+[23:48]  dm> depends on the sender and receiver's tunnel length 
                
+[23:48]  order of magnitude.
                
+[23:48]  (e.g. if they have 0 length tunnels, it'll be approx 400ms) 
                
+[23:49]  0 length tunnels, don't know how I2P works, but 0 length doesn't sound good ;)
                
+[23:49]  or (Link: http://tinyurl.com/p8l7)http://tinyurl.com/p8l7
                
+[23:49]  if they have 2 hop tunnels, the latency should be ~ 1s 
                
+[23:49]  alrighty.
                
+[23:49]  throughput?
                
+[23:50]  harder to estimate?
                
+[23:50]  depends on bandwidth 
                
+[23:51]  Say X is the non I2P bandwidth between 2 nodes, through all the hops I2P uses.
                
+[23:51]  what is the equation for Y(X) where Y is the throughput of I2P from one node to the other.
                
+[23:51]  I2P doesn't add a significant overhead to the size of the data 
                
+[23:52]  alrighty.
                
+[23:52]  wait and see I guess.
                
+[23:53]  once she's up and running, we'll definitely get some modeling going on 
                
+[23:53]  aye..
                
+[23:54] * dm raises his glass.
                
+[23:54]  To women!
                
+[23:54]  dm: you forgot to lower it first ;)
                
+[23:55]  You germans...
                
+[23:55]  You wacky germans.
                
+[23:55]  ok, I think thazzabout it 
                
+[23:55]  It's no suprise an american is leading us into the 21st century of anonymous networking.
                
+[23:55] * mihi /igs dm
                
+[23:55]  american? 
                
+[23:56]  jrand0m is spanish i guess.
                
+[23:56]  I was referring to you!
                
+[23:56]  or italian or sth in CET timezone.
                
+[23:56]  jrand0m, the quiet american.
                
+[23:56]  dm: jrand0m seems to be a European.
                
+[23:56]  !thwap mihi
                
+[23:57]  !thwap wiht
                
+[23:57]  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]  nice try jr!
                
+[23:58] * jrand0m *baf*s the meeting away
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/61.log b/i2p2www/meetings/61.log
new file mode 100644
index 00000000..60699462
--- /dev/null
+++ b/i2p2www/meetings/61.log
@@ -0,0 +1,82 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 61{% endblock %}
+{% block content %}
                
+[23:04]  0.0) welcome 
                
+[23:04]  1.0) dev status 
                
+[23:04]  2.0) new server 
                
+[23:04]  3.0) questions? 
                
+[23:04]  0.0) welcome to the 61st iip meeting 
                
+[23:04]  hi. 
                
+[23:04]  hi all
                
+[23:04]  hi you two ;)
                
+[23:04]  ok, 1.0) dev status 
                
+[23:05]  we're pretty much ready for 0.2 - which is where people would be able to run i2p.   
                
+[23:06]  great!
                
+[23:06]  ETA?
                
+[23:06]  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]  eta: a few days (related point: agenda item 2.0) 
                
+[23:07]  but it will be functional.  I'm able to send messages of 10 bytes as well as 100K in ~10s 
                
+[23:07]  (both on the same CPU, so its cpu contention) 
                
+[23:07]  still some tunnel failback I'm working through, then its time to build the ant scripts, etc 
                
+[23:07]  actually 
                
+[23:08]  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]  but it wasn't working either, was it? ;)
                
+[23:08]  heh 
                
+[23:09]  no, it works 
                
+[23:09]  the prob I'm working through is a failover (aka if one is shut down and starts back up, comm recovers cleanly) 
                
+[23:10]  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]  not yet, havent tried i2ptunnel yet either.  but shall tonight 
                
+[23:10]  try i2ptunnel with a binary connection (like ssh), no text based one.
                
+[23:11]  'k 
                
+[23:11]  what if a node shuts down and does not come up again?
                
+[23:11]  then communication with it will fail ;) 
                
+[23:12]  (guaranteed delivery now fails correctly and the SDK has been patched to act on that) 
                
+[23:13]  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]  2.0) new server 
                
+[23:13]  we have a new server on a triple homed T3.   
                
+[23:14]  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]  i'll also be tossing on a public isproxy later 
                
+[23:15]  damn, how much is that costing you?
                
+[23:15]  65/mo 
                
+[23:15]  40Gb transfer, 2Gb data 
                
+[23:15]  bandwidth limit?
                
+[23:15]  cool.
                
+[23:16] *** mihi_ is now known as mihi
                
+[23:16]  perhaps that server will become our cvs, but no need to switch right now.   
                
+[23:16]  ok, 3.0) questions 
                
+[23:17]  [yes, this has been the fastest meeting I've ever seen ;)] 
                
+[23:17]  do you know anything about naming service progress?
                
+[23:17]  I hear wiht has committed a few files, but I haven't checked them out yet 
                
+[23:17]  I'd like to offer my (mental) support to all the developers. Stay humble yet determined.
                
+[23:18]  they are only dummies afaik.
                
+[23:18]  clueless wankers, for sure. 
                
+[23:18]  interfaces to implement against.
                
+[23:18]  dummies?
                
+[23:18]  lol 
                
+[23:19]  ah
                
+[23:19] * jrand0m extends MyParents
                
+[23:19]  java does not allow multiple inheritance ;)
                
+[23:19]  no bastards...
                
+[23:20] * jrand0m implements MyDad, MyMom // just seems wrong
                
+[23:20]  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]  ;)
                
+[23:20]  oh, good point mihi 
                
+[23:20] * dm now implements mihi'smother
                
+[23:20]  heh 
                
+[23:21] *** Signoff: mihi (Ping timeout)
                
+[23:21]  you just need a constructor public Human(Human father, Human mother) throws SameSexException
                
+[23:22]  nice one
                
+[23:22]  I think modern science requires a few more constructors 
                
+[23:22]  although it's not public
                
+[23:22]  it's pubic
                
+[23:22] *** mihi (mihi@anon.iip) has joined channel #iip-dev
                
+[23:22]  I crack myself up.
                
+[23:23]  ok, on that note 
                
+[23:23]  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/i2p2www/meetings/62.log b/i2p2www/meetings/62.log
new file mode 100644
index 00000000..99836336
--- /dev/null
+++ b/i2p2www/meetings/62.log
@@ -0,0 +1,288 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 62{% endblock %}
+{% block content %}
                
+[23:01]  agenda 
                
+[23:01]  0) welcome 
                
+[23:01]  1) 0.2 status 
                
+[23:01]  2) www proxy 
                
+[23:01] * dm ponders.
                
+[23:02]  oh, meeting?
                
+[23:02]  3) phttprelay 
                
+[23:02]  4) i2ptunnel 
                
+[23:02]  5) installation 
                
+[23:02]  sorry.
                
+[23:02]  6) iip feature request 
                
+[23:02]  7) ??? 
                
+[23:02]  0) welcome  
                
+[23:02]  hi. 
                
+[23:02]  meeting 62? is it? 
                
+[23:02]  hi
                
+[23:02]  (no worry dm, we can forgive you) 
                
+[23:02]  hi jrand0m
                
+[23:02]  hi mihi
                
+[23:02] * mihi thinks so
                
+[23:03]  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]  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]  cool jr!
                
+[23:05]  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]  the comm across NAT/firewall/HTTP proxy is the PHTTP transport.  its slow, but reliable. 
                
+[23:05]  how does it work? what ports does it use?
                
+[23:06]  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]  there is a LOT that can be tuned and improved on that side of things, which is agenda point 3 :) 
                
+[23:06]  P stands for?
                
+[23:06]  Polling HTTP 
                
+[23:06]  ok thanks.
                
+[23:07]  I'm going to update the "kludges" page on the wiki after the meeting too, to note the things that are funky 
                
+[23:07]  (such as not yet handling a lease change during communication) 
                
+[23:08]  the other point to discuss is agenda item 5 - installation.  aka how we should handle installation of the router/sdk/tunnel/etc 
                
+[23:08]  ok, thats it for 0.2 status 
                
+[23:08]  2) www proxy. 
                
+[23:09]  moi had a really cool idea for browsing in-i2p www sites. 
                
+[23:09]  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]  well
                
+[23:10]  i am just modifying an HTTP proxy and using mihi's tunnel
                
+[23:10]  so that you can go to (Link: http://i2p/BASE64KEYHERE)http://i2p/BASE64KEYHERE
                
+[23:10]  eventually the naming server would be there--
                
+[23:11]  sweet
                
+[23:11] *** Signoff: mihi (Ping timeout)
                
+[23:11]  you have to paste in the first long key, but after that you should technically be able to follow links I think
                
+[23:11]  so an internal web page or a page outside of i2p?
                
+[23:11]  i2p resolves to localhost?
                
+[23:11]  so someone could put up an i2p Google, and go from there.... mabye
                
+[23:12]  !thwap dm.
                
+[23:12]  a proxy...
                
+[23:12]  for security, the proxy should 404 all hosts other than (Link: http://i2p/)http://i2p/ 
                
+[23:12]  oops!
                
+[23:12]  good point
                
+[23:12]  missed that part
                
+[23:12]  although a simple servlet would be nice too
                
+[23:12]  hmm? 
                
+[23:13] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
                
+[23:13]  hmm, there may be a problem. 
                
+[23:13]  this would use HTTP 1.0 or 1.1? 
                
+[23:14]  if the server requests a Host: header?
                
+[23:14]  [aka, would it have a Host: header?] 
                
+[23:14]  exactly 
                
+[23:14] * mihi wishes for something
                
+[23:14]  I wonder if we can have the proxy blank that out
                
+[23:14]  if the server's outbound tunnel is always on the same host, thats fine 
                
+[23:14]  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]  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]  right? 
                
+[23:15] *** Signoff: dm (Ping timeout)
                
+[23:16] * moi hadn't thought that deeply into it yet
                
+[23:16]  if you run the server on your own box you can also alias i2p to localhost or sth like that.
                
+[23:16]  so do people have to run web servers now?
                
+[23:16]  dm_backup> this is only for people who want to. 
                
+[23:16] *** dm_backup is now known as dm
                
+[23:16]  like me
                
+[23:16]  yeah, I mean for this (Link: http://i2p)http://i2p thingie
                
+[23:17]  if you want to provide content, yes.
                
+[23:17]  but you have to run one to provide content in good ol' www as well.
                
+[23:18]  why?
                
+[23:18]  Hmmm, maybe I should build a P2P app for I2P.
                
+[23:18]  a filesharing app over i2p would rule. 
                
+[23:18]  yes sorry, filesharing.
                
+[23:19]  I think it would be possible for someone to run an OpenNap server in conjunction with i2ptunnel
                
+[23:19]  yes. 
                
+[23:19]  (though a native i2p p2p would have better performance) 
                
+[23:19]  but the downloads will be hard. 
                
+[23:20]  no way to get to the correct host as all are localhost ;)
                
+[23:20]  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]  perhaps just a simple FTP client designed to run over i2p? 
                
+[23:20]  (not ping literally)
                
+[23:20]  jrand0m: ftp needs 2 ports...
                
+[23:20]  designed to run over i2p. 
                
+[23:21]  a general file transfer app, not the FTP protocol, specifically 
                
+[23:21]  then it's not ftp.
                
+[23:21]  ATalk ;)
                
+[23:21]  (taking advantage of larger message sizes) 
                
+[23:21]  battle of the wise men!
                
+[23:21]  heh 
                
+[23:21]  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]  (kind of) 
                
+[23:22]  you won't want to use an i2ptunnel, specifically.  
                
+[23:22]  you'll want to use the i2ptunnel protocol, and send messages directly, not via TCP/IP sockets. 
                
+[23:23]  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]  is there any large protocol functionality? I2PTunnelRunner can be used as is.
                
+[23:25]  You just have to adjust the client class for your needs.
                
+[23:25]  hmm, not really - i2ptunnelRunner uses a socket 
                
+[23:26]  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]  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]  but perhaps switching I2PTunnelRunner to use an InputStream (all it uses is socket.getInputStream) would be easy... 
                
+[23:28]  but then we still need the listen side 
                
+[23:28] *** Signoff: mihi (Ping timeout)
                
+[23:28]  d'oh 
                
+[23:28] * jrand0m hopes the backup isn't about to ping out...
                
+[23:28]  backup's gonna die as well ,watch it!
                
+[23:29]  ;)
                
+[23:29]  w00t 
                
+[23:29]  [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket
                
+[23:29]  [23:25] <mihi> oops, right. and you want to do it completely without sockets?
                
+[23:29]  [23:26] <mihi> then there is not much code left from i2ptunnel. most is for handling the sockets.
                
+[23:29]  [23:26] <mihi> best stick to the protocol and implement it yourself (build the messages w/ the static method in i2ptunnel.java)
                
+[23:29]  [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]  ah 'k.  thanks 
                
+[23:30]  moi> tu sabes? 
                
+[23:30]  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]  toi thinks
                
+[23:31]  just forget the tunnelrunner. ;)
                
+[23:31]  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]  but that will cause the runner to send a "Connection closed" when the string is sent.
                
+[23:32]  as the stream ends.
                
+[23:32]  right, which is normal HTTP 
                
+[23:33]  just forget the runner, i said ;)
                
+[23:33]  'k 
                
+[23:33]  jrand0m: nope. the connection is closed when the answer is here, not when the question is out.
                
+[23:33]  oh yeah 
                
+[23:33]  ;) 
                
+[23:36]  cool moi, we can work through this stuff later on. 
                
+[23:36]  ok, thats agenda item 2).  now for 3) 
                
+[23:36]  ok
                
+[23:37]  3) phttprelay 
                
+[23:37]  phttp relay is a set of servlets wrapped in a .war file 
                
+[23:38]  it works out of the box on windows / sun JVM, but I had to hack jetty to run w/ kaffe 
                
+[23:38]  make .peace not .war
                
+[23:39] * jrand0m groans
                
+[23:39]  you can run .war files without a J2ee server?
                
+[23:39]  good to know.
                
+[23:39]  .war files run in any servlet container - tomcat, apache w/ mod_jk, jetty, etc 
                
+[23:40]  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]  which ports do you need to redirect if you want to go through a nat without that?
                
+[23:41]  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]  just the I2NP TCP port 
                
+[23:41]  (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]  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]  the code is in i2p/code/apps/phttprelay/ for anyone with servlets experience who wants to hack on a small app 
                
+[23:45]  (it should also work transparently with https as well as plain http) 
                
+[23:45]  I'll doc up the PHTTP protocol Real Soon Now.  :) 
                
+[23:45] *** Signoff: mihi (Ping timeout)
                
+[23:45]  ok, thats it for item 3) phttprelay 
                
+[23:45]  4) i2ptunnel 
                
+[23:46]  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]  hola wilde 
                
+[23:47]  ok.  that said, item 5 :) 
                
+[23:47]  5) installation 
                
+[23:48]  to get 0.2 out the door, and beyond, I'm thinking of some ant scripts. 
                
+[23:48]  or should we use another open source installation system? 
                
+[23:48]  anyone have any experiences / thoughts on this? 
                
+[23:49]  hmm
                
+[23:50]  ant has the benefit of being unified with the build system, platform independent, and has headless operation. 
                
+[23:50]  hey
                
+[23:50]  but it requires ant (which requires java).  and it doesn't have a GUI 
                
+[23:51]  i can think of many install programs for windows... i dont know how many are gpl though
                
+[23:51]  yeah, I have a licensed InstallAnywhere Enterprise installation, but its bad for open source 
                
+[23:51]  NSIS is open source, but has its nuances. 
                
+[23:51]  stupid question: is ant included in java?
                
+[23:52]  nope. 
                
+[23:52]  oh, though we COULD distribute a GCJ'ed ant 
                
+[23:52]  alright, must have come with eclipse then.
                
+[23:52]  (compiled to native code) 
                
+[23:52]  definitely dm. 
                
+[23:52]  apache makes ant (ant.apache.org) and its apache licensed. 
                
+[23:52]  oh, yuck. 
                
+[23:52] * jrand0m just read the sentence I typed)
                
+[23:53]  gpl is not apl friendly, according to the FSF 
                
+[23:53]  we probably can't distribute ant. 
                
+[23:53]  can't we just a script? what needs to be done for it to be installed?
                
+[23:53]  but we can use it. 
                
+[23:53]  not much at all.  a script is fine. 
                
+[23:53]  but do we want a .bat and a .sh, etc. 
                
+[23:54] *** shardy (~shardy@anon.iip) has joined channel #iip-dev
                
+[23:54]  what does an installation entail, a couple of questions?
                
+[23:54]  writing a java installer to do the install platform independent is overkill, so we should ideally use an existing install framework 
                
+[23:54]  yeah, a few questions 
                
+[23:54]  the installation targets I forsee: 
                
+[23:54]  do we get a flashy new logo? whos working on that?
                
+[23:54]  install-router 
                
+[23:55]  install-www-tunnel, install-www-proxy, install-sdk, install-cvs-tunnel, update-seednodes 
                
+[23:55]  why not use InstallAnywhere? if the code is open that is what matters
                
+[23:55] * jrand0m thinks YOU are Dellammo :)
                
+[23:55]  InstallAnywhere isn't open source. 
                
+[23:55] * Dellammo gets to work
                
+[23:56]  script would probably be enough at this point, but I guess might as well think ahead.
                
+[23:56]  (its about 4k euro / seat) 
                
+[23:56]  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]  so if anyone can help out with that, it'd be appreciated :) 
                
+[23:57]  ah okay, I was thinking shell scripts.
                
+[23:57]  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]  managing different installers for different platforms is a PITA 
                
+[23:59]  java installer? Why is it a PITA?
                
+[23:59]  a java installer would be great 
                
+[23:59]  pain in the a**e
                
+[23:59]  oops, sorry...
                
+[23:59]  system.out.println("Please enter where you would like to install I2P") ;)
                
+[23:59]  s/tln/t; s/P"/P: "/
                
+[23:59]  s/sys/Sys/
                
+[00:00]  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]  mihi's having an epileptic seizure.
                
+[00:00] * mihi-backup slaps dm around a bit with a large trout
                
+[00:00]  Tell you what...
                
+[00:01]  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]  dm: read the ant script ;)
                
+[00:01]  word dm.  once I get the ant thing working I'll doc 'er up for you 
                
+[00:01]  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]  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]  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]  ok, thats 5) installation 
                
+[00:03]  6) iip feature request 
                
+[00:04]  someone came on here with a request for auto-nicktheifing 
                
+[00:04]  basically, if someone has registered a nick, no one can stay as that nick unless they're identified 
                
+[00:04]  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]  heh 
                
+[00:05]  Maybe I'll make an I2P logo as well... for the gui part of my installer ;)
                
+[00:05] *** Signoff: wilde ((null))
                
+[00:05]  lets all make them, so we dont get stuck with a sucky logo
                
+[00:05]  jrand0m: ask mids - he maintains trent.
                
+[00:06]  the trent source is in cvs btw
                
+[00:06]  the logo is the most important part of any activity
                
+[00:06]  definitely Dellammo. 
                
+[00:06] * dm dusts off Corel Draw...
                
+[00:06]  man I love Corel Draw.
                
+[00:07]  ok, thats it for 6) 
                
+[00:07]  7) ??? 
                
+[00:07]  any questions / thoughts / frisbees/ toenails? 
                
+[00:07]  Thought: hope it works.
                
+[00:08]  heh 
                
+[00:08] * jrand0m too.
                
+[00:09]  jrand0m: keep the good work!
                
+[00:09]  yes, keep it up.
                
+[00:09]  good work?  you obviously haven't seen the code ;) 
                
+[00:09]  Love your code, except for the bliding underscores.
                
+[00:09]  blinding...bleeding..etc..
                
+[00:09]  heh, instance variables have _, so we don't ever need to do this.var = var; 
                
+[00:10]  ok... 68 minutes... if I can drag this out for one more minute... 
                
+[00:10]  w00t 
                
+[00:10] * jrand0m *baf*s the meeting closed.
                
+
                {% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/63.log b/i2p2www/meetings/63.log
new file mode 100644
index 00000000..582dbbcd
--- /dev/null
+++ b/i2p2www/meetings/63.log
@@ -0,0 +1,183 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 63{% endblock %}
+{% block content %}
                Tuesday, October 28, 2003 21:02:50 UTC
                
+
                
+[22:59]  so when IS this meeting?
                
+[23:00]  now. 
                
+[23:00]  0) welcome [63] 
                
+[23:00]  1) roadmap: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
                
+[23:00]  2) 0.2 todo: 
                
+[23:00]  - long lasting comm testing 
                
+[23:00]  - lease rebuilding bugs 
                
+[23:00]  3) prng (yay) 
                
+[23:00]  4) apps / questions / etc 
                
+[23:00]  0) hi 
                
+[23:00]  sorry for being stupid and forgetting about daylight savings time 
                
+[23:00]  welcome to meeting #63 
                
+[23:01] *** darl_mcbride has left #iip-dev
                
+[23:01]  1) roadmap 
                
+[23:01]  the roadmap is at the above url and will be updated whenever necessary. 
                
+[23:02]  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]  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]  0.2 itself will allow actual useful functionality 
                
+[23:03] *** Signoff: thecrypto (Ping timeout)
                
+[23:03]  that's good news.
                
+[23:03]  ok, item 2) 0.2 todo 
                
+[23:04]  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]  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]  (the problem has been that after a few hours of use, communication with a router or a destination fails) 
                
+[23:05]  what kind of testing rig are you using? Is it all local at this point?
                
+[23:05]  three routers local, three routers remote 
                
+[23:05]  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]  yes 
                
+[23:06]  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]  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]  however, running three routers plus two active destinations locally is, well, a CPU beast. 
                
+[23:08]  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]  ok, thats it for 0.2 todo 
                
+[23:09]  for your testing purposes?
                
+[23:09]  yeah basically 
                
+[23:09]  (and/or for anyone else who is doing their own testing to add new features / etc ;) 
                
+[23:10]  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]  but i think thats a Bad Idea. 
                
+[23:11]  this feature will most certainly get pulled once the AES+SessionTag stuff gets worked out 
                
+[23:11]  ok, 3) prng 
                
+[23:11]  Are there any suggested minimum CPU and RAM requirements?
                
+[23:12]  sorry
                
+[23:12]  hmm, RAM is minimal (sun's JVM takes 7-10Mb, kaffe 16-22Mb) 
                
+[23:13]  CPU is definitely the limiting factor at the moment,but I don't have a wide array of boxes to test on ;) 
                
+[23:14]  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]  i might be a little more active if you want me to say somethingh
                
+[23:14]  alright, say something.
                
+[23:15]  hiya thecrypto :) 
                
+[23:15]  Why would anyone run more than one router on the same computer?
                
+[23:15]  sisr> only a developer would. 
                
+[23:16]  Ok, so the CPU should not be too bad and we can run some tests over the weeks
                
+[23:16]  word 
                
+[23:17]  ok, the prng stuff turned out to be a bug in kaffe, which is now fixed.   
                
+[23:17]  with that, we don't have any hard need to get a yarrow impl, as they use sha1prng 
                
+[23:18]  (but it'd be nice, whenever we get it) 
                
+[23:18]  ok, 4) apps / questions / etc 
                
+[23:18]  I don't have anything else, so... hi :) 
                
+[23:19]  any questions / thoughts / comments on anything else? 
                
+[23:19]  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]  speaking of the devil 
                
+[23:19]  hi co 
                
+[23:19]  haha
                
+[23:19]  Hello.
                
+[23:20]  we're at that point where there's not really anything left on the agenda 'cept for questions 
                
+[23:20]  [23:19] <sisr> How is the naming server? I have not seen co for a long time 
                
+[23:20]  [23:19] *** co (anon@anon.iip) has joined channel #iip-dev 
                
+[23:20]  and that happened :) 
                
+[23:20] *** Signoff: godmode0 (EOF From client)
                
+[23:21]  There has been no progress on it. I wrote just a small part of the client, and none of the server.
                
+[23:22]  coo' 
                
+[23:22] * dm points the shame-stick at co.
                
+[23:22]  I believe the HTTP i2p tunnel is working good now
                
+[23:22]  i have adapt mihis excellent httpclient so that you type it into your proxy setting
                
+[23:23]  aweseme! 
                
+[23:23]  it also does some simple filter of non i2p site
                
+[23:23]  i think jrand0m has commit this already, yes?
                
+[23:23]  do we know what browsers it works with?  I know moz... 
                
+[23:23]  yeah, I think I committed that stuff.. lemmie check 
                
+[23:23] * co is appropriately ashamed.
                
+[23:23]  It working with Mozilla and the Konqueror
                
+[23:24] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
                
+[23:24]  dont worry co, I'm already 2 months behind schedule 
                
+[23:24]  I will try to get the mihi I2P tunnel to work with E-mail server this week
                
+[23:24]  Also many wiki pages have updated
                
+[23:24]  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]  "Also many wiki pages have updated"
                
+[23:25]  Ok go ahead
                
+[23:25]  mmmm.....MMmmmm.....mmmmmm...
                
+[23:26]  ah, another clue?
                
+[23:26]  But I can not tell you if you are correct
                
+[23:26]  "..... has commit this already, yes?"
                
+[23:26]  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]  I've found that what I want and what happens isn't always the same thing 
                
+[23:27]  I mean release them together.
                
+[23:27]  I have a question after co
                
+[23:27]  the current plan is up at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
                
+[23:28]  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]  (the installer right now bundles the router, sdk, phttprelay, atalk, and i2ptunnel) 
                
+[23:29] *** Signoff: dm (Ping timeout)
                
+[23:29]  'sup sisr? 
                
+[23:29]  That page is quite helpful. Thank you.
                
+[23:30]  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]  absolutely. 
                
+[23:30]  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]  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]  personally, I'd love if the former could happen.  however, there will be performance gains by designing apps native to i2p 
                
+[23:32]  unix principle: one job, one tool. so don't write new browsers.
                
+[23:32]  right 
                
+[23:32]  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]  one job, one tool? silly principle.
                
+[23:33]  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]  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]  Haha, ok sisr has a very old computer
                
+[23:34]  It seem real slow to me because of this
                
+[23:34]  what was latency like on the first few real tests? Just out of curiosity.
                
+[23:35]  I can pull news.google.com with all images in ~ 30-60 seconds 
                
+[23:35]  k
                
+[23:36]  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]  And how much time does it take without the tunnel?
                
+[23:36]  sisr> if I worked on it fulltime, I'd suspect ~ 1 month to get a DHT on top of i2p 
                
+[23:37]  co> ~ 10-15 seconds 
                
+[23:38]  So i2ptunnel is 3 times as slow.
                
+[23:39]  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]  For you, at least.
                
+[23:39]  the overhead is in the message wrapping 
                
+[23:39]  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]  Like checkbox to set up I2P Tunnel web server with port, and Checkbox for E-mail server, so it real simple
                
+[23:40]  sisr> I personally really really like its interface atm :)   
                
+[23:40]  oh, definnitely.  actually 
                
+[23:40] * sisr has never seen the interface but imagines it like the textbox
                
+[23:40]  Maybe someone can screencap the I2P tunnel for tutorial
                
+[23:41]  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]  What should we be working on for I2P now
                
+[23:42]  thats a big question.  short answer is "whatever you can" 
                
+[23:43]  if someone were to go ahead and update the installer to build those .sh and .bat scripts, that would rule 
                
+[23:43]  if anyone has time to work on some of the things on the i2proadmap, that would also rule :) 
                
+[23:44]  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]  How will the Installer be? Install shield or Java?
                
+[23:44]  the current installer is a single "install.jar" which prompts the user through a few questions 
                
+[23:45]  its a really crappy installer 
                
+[23:45]  but its as platform independent as it gets 
                
+[23:48]  ok cool, the routers are still working, I think this bugfix may have done it. 
                
+[23:48]  oh yeah.  
                
+[23:48]  the mailing list will be back sometime 
                
+[23:48]  if it isn't back by the time 0.2 is ready, I'll create a new mailing list 
                
+[23:49]  I have one other question.
                
+[23:49]  fire away 
                
+[23:50]  Is there a list available of I2P nodes running right now?
                
+[23:50]  nope. 
                
+[23:50]  no public i2p nodes are open 
                
+[23:50]  I see.
                
+[23:50]  however, one of them will make its list of peers available via http once 0.2 is released 
                
+[23:50]  (and the URL to that list will be in the installer) 
                
+[23:50]  s/will be/is/ 
                
+[23:52]  it's in my bookmarks as well...
                
+[23:52]  heh bastard 
                
+[23:52]  btw: size=777 is 111 bytes too large ;)
                
+[23:53]  rofl 
                
+[23:53]  I totally didn't notice that. 
                
+[23:53]  they used to be 384 
                
+[23:53]  but then I added some router sw version info to the routerInfo 
                
+[23:53]  I think nop can use the I2P tunnel to set up a test IRC server with the 0.2 router?
                
+[23:54]  that'd be really cool 
                
+[23:54]  I wonder how the latency comparing to this IIP if nop does that
                
+[23:54]  though we wouldn't be able to dcc 
                
+[23:54]  i2p would be a lot higher latency 
                
+[23:54]  (as each send would be a few seconds, since we don't have AES+SessionTag yet) 
                
+[23:57]  ok, if anyone has anything to say before the list is back, either talk here or toss stuff up on the wiki 
                
+[23:57]  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/i2p2www/meetings/64.log b/i2p2www/meetings/64.log
new file mode 100644
index 00000000..f9ac4807
--- /dev/null
+++ b/i2p2www/meetings/64.log
@@ -0,0 +1,196 @@
+{% 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]  agenda 
                
+[22:02]  0) welcome 
                
+[22:02]  1) i2p router  
                
+[22:02]  1.1) status 
                
+[22:02]  1.2) roadmap changes 
                
+[22:02]  1.3) open subprojects 
                
+[22:02]  2) native modPow 
                
+[22:03]  2) gui installer 
                
+[22:03]  3) IM 
                
+[22:03]  4) naming service 
                
+[22:03]  i saw that .c code
                
+[22:03]  5) licensing 
                
+[22:03]  6) other? 
                
+[22:03]  0) welcome 
                
+[22:03]  hi. 
                
+[22:03]  hi
                
+[22:03]  meeting 2^6 
                
+[22:04]  got any agenda items to add to there nop? 
                
+[22:04]  ok, 1.1) router status 
                
+[22:04]  we're 0.2.0.3 and last I heard, its functional 
                
+[22:04]  > 0.2.0.3
                
+[22:04]  right?
                
+[22:05]  im running it .. seems fine
                
+[22:05]  no
                
+[22:05]  there have been minor commits after the 0.2.0.3 release, nothing release worthy 
                
+[22:05]  I am jus trying to catch up
                
+[22:05]  coo' 
                
+[22:06]  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]  (aka so people can run webservers / etc and it won't eat up their CPU) 
                
+[22:06]  specifically (moving to agenda 1.2): http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
                
+[22:06]  what ive noticed is that most routers use: TransportStyle: PHTTP   
                
+[22:07]  does it auto go to phttp or does it even try tcp first
                
+[22:07]  hmm, most routers should support PHTTP, and if they can accept incomming connections, should support TCP as well 
                
+[22:07]  if at all possible it uses TCP 
                
+[22:07]  PHTTP is weighted about 1000 times more expensive than TCP 
                
+[22:08]  (see GetBidsJob, which asks each transport how much it thinks it'd cost to send a message to a peer) 
                
+[22:08]  (and see TCPTransport.getBid and PHTTPTransport.getBid for the values used) 
                
+[22:08]  ok
                
+[22:08]  are you using PHTTP often to send and receive messages? 
                
+[22:09]  (that might be a sign that your TCP listener isn't reachable) 
                
+[22:09]  i didnt put in the urls on my side
                
+[22:09]  ah 'k.  
                
+[22:09]  ohh it is
                
+[22:10]  ok, yeah, my routers have open TCP connections to you 
                
+[22:10]  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]  is there a timeout thing if it doesnt connect to the tcp it goes phttp? and whatz the timing on it
                
+[22:11]  but anyway, the big change to the roadmap is that 0.2.1 will implement the AES+SessionTag stuff 
                
+[22:11]  or could we have that in a setting?
                
+[22:11]  if it gets a TCP connection refused / host not found /etc, it fails that attempt immediately, and tries the next available bid 
                
+[22:12]  so no retrys
                
+[22:12]  phttp has a 30 sec timeout iirc 
                
+[22:12]  no need to retry.  you either have an open TCP connection and can send the data or you don't :) 
                
+[22:12]  lol ok
                
+[22:13]  will it try tcp everytime after that or skip that and just go phttp for the next connection?
                
+[22:13]  it'll try tcp each time at the moment. 
                
+[22:13]  the transports don't keep histories yet 
                
+[22:13]  ok cool
                
+[22:14]  (but if a peer fails 4 times they get shitlisted for 8 minutes) 
                
+[22:14]  well once the otherside gets the phttp msg it should connect to the router that sent the msg via tcp right?
                
+[22:14]  correct.  once any tcp connection is established, it can use it. 
                
+[22:14]  (but if both peers only have phttp, they'll obviously only use phttp) 
                
+[22:15]  that would mean that it couldnt est. a tcp connection to anything
                
+[22:15]  .. but ya
                
+[22:16]  i wish there was a way around that
                
+[22:16]  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]  (and then they can send back messages along that TCP connection instead of sending me slower PHTTP messages) 
                
+[22:17]  or is that not what you mean? 
                
+[22:17]  ya i got mixed up
                
+[22:17]  word, np 
                
+[22:18]  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]  ok, 1.3) open subprojects 
                
+[22:19]  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]  so if you're bored and looking for code projects... :) 
                
+[22:19]  gezz
                
+[22:20]  already got 2
                
+[22:20]  You have a palmpilot this is elite
                
+[22:20]  mine died
                
+[22:20]  mihi> there's a line item in there wrt the I2PTunnel describing a thought I had a lil while ago 
                
+[22:20]  dont know whatz up wit hit
                
+[22:21]  yeah, I used to have palms but just recently had this one donated to the cause ;) 
                
+[22:21]  Could there be an agenda item at the meeting to discuss when the last time userX typed something was
                
+[22:21]  damm thing doesnt even turn on anymore
                
+[22:21]  lol
                
+[22:22]  I don't think UserX has said anything in 4 or 5 months ;) 
                
+[22:22]  is that a bot or something?
                
+[22:22]  What did they say 5 months ago?
                
+[22:22]  i bet its a bitchx running on some box he use to have access to .. and forgot about it
                
+[22:22]  that they'd get back with comments about the anonCommFramework (i2p's old name) next week ;) 
                
+[22:23]  haha
                
+[22:23]  but I suppose he's busy.  so is life 
                
+[22:23]  ok, 2) native modPow 
                
+[22:23]  i saw that c code
                
+[22:24]  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]  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]  last thing i saw was: [13:25] <jrand0m> ok, 2) native modPow
                
+[22:38]  hi MrEcho 
                
+[22:38]  yeah, looks like a main proxy crashed 
                
+[22:39]  I'm giving it another 2 mins before restarting 
                
+[22:39]  k
                
+[22:39]  for $25 1 time i can get full on java on thenidus.net ... one of my sites
                
+[22:40]  $25?  they charge you to install software? 
                
+[22:40]  no idea really .. its a package
                
+[22:40]  talking to my friend right now
                
+[22:40]  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]  package of what?
                
+[22:41]  java - jsp
                
+[22:41]  ok, resending what I sent before: 
                
+[22:41]  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]  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]  however with the new roadmap placing AES+SessionTag as my current action item, this isn't quite as critical as it was. 
                
+[22:42]  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]  frazaa?
                
+[22:43]  heh, in a way ;) 
                
+[22:44]  ok, 3) gui installer 
                
+[22:44]  MrEcho> hi 
                
+[22:44]  :)
                
+[22:44]  hehe
                
+[22:44]  its comming alog
                
+[22:44]  cool 
                
+[22:44]  nothing fancy
                
+[22:45]  ive got some really cool ideas to make it really fancy .. but thatz a way off
                
+[22:45]  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]  word 
                
+[22:46]  yeah, we want the installer to be as simple as possible - what fancy stuff were you thinking of? 
                
+[22:46]  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]  how are we going to make it to were you dbl click the jar file and it loads the gui
                
+[22:47]  install.jar <-- nongui,  installgui.jar <-- gui 
                
+[22:47]  seperate code, seperate packages 
                
+[22:47]  fancy as in things you might not notice .. but its goingto be nice and clean
                
+[22:47]  cool 
                
+[22:47]  aww ok
                
+[22:48]  (or install <-- gui installcli <-- cli.  we'll see how things progress) 
                
+[22:49]  anything else on the gui, or do we jump off to item 4)? 
                
+[22:49]  (any time frame you're thinking?  no pressure, just wondering) 
                
+[22:51]  no idea right now
                
+[22:51]  coo' 
                
+[22:51]  ok, 4) IM 
                
+[22:51]  thecrypto aint here, so..... 
                
+[22:51]  5) naming service 
                
+[22:51]  wiht isn't here either... 
                
+[22:51]  ping 
                
+[22:52]  you're off on the number agenda count
                
+[22:52]  3) IM
                
+[22:52]  yeah, I used to have 2 agenda item 2's 
                
+[22:52]  4) Naming
                
+[22:52]  ;)
                
+[22:52]  (native modPow and gui installer) 
                
+[22:52]  see, we're dynamic and stuff 
                
+[22:59]  ok, for the logs I suppose I'll continue 
                
+[22:59]  6) licensing 
                
+[23:00]  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]  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]  (but i2ptunnel is essentially a third party app and can license how it wants) 
                
+[23:02]  (though since the i2p sdk is gpl, he's been forced to be gpl) 
                
+[23:02]  damm about time
                
+[23:02]  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]  hehe :) 
                
+[23:06]  anyway, 7) other?   
                
+[23:07]  anyone have any questions / concerns / ideas wrt i2p? 
                
+[23:07]  Let me ask
                
+[23:07]  Does the I2P have any group name feature?
                
+[23:07]  group name feature? 
                
+[23:07]  team discovery channel!
                
+[23:07]  lol
                
+[23:08]  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]  hes thinking of waste
                
+[23:08]  ah 
                
+[23:08]  I don't know why you would want that, but I am just ask in case
                
+[23:08]  yes, early on in the network design I was playing with that 
                
+[23:09]  its more advanced than we need for now (or for the relatively near future [6-12 months]) but may be integrated later  
                
+[23:09]  Or is that a bad idea because it is better to keep it one large network
                
+[23:09]  i2pisdead
                
+[23:09]  heh dm 
                
+[23:10]  shad up
                
+[23:10]  no dish, its a good idea 
                
+[23:10]  nop: tough guy?
                
+[23:10]  its essentially what release 0.2.3 is -- restricted routes 
                
+[23:10]  (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]  ok, anything else? 
                
+[23:15]  nah, I'm just being funny
                
+[23:18]  funny guy?
                
+[23:20]  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/i2p2www/meetings/65.log b/i2p2www/meetings/65.log
new file mode 100644
index 00000000..5ee5fe8d
--- /dev/null
+++ b/i2p2www/meetings/65.log
@@ -0,0 +1,623 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 65{% endblock %}
+{% block content %}
                Tuesday, November 18, 2003 21:02:50 UTC
                
+
                
+[22:02]  agenda: 
                
+[22:02]  0) welcome 
                
+[22:02]  1) i2p dev status 
                
+[22:02]   - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense)  
                
+[22:02]   - don't use bw limiting (still some debugging) 
                
+[22:02]   - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics] 
                
+[22:02]  2) kademlia, 0.3, and idn 
                
+[22:02]  3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? 
                
+[22:02]  4) app status [ppp2p, i2ptunnel, im, ns, squid] 
                
+[22:02]  5) why does jrand0m drink cheap local beer?
                
+[22:02]  5) comments / questions / etc 
                
+[22:02]  heh 
                
+[22:02]  so yeah, basically that fits under 5 :) 
                
+[22:02]  double 5 ;)
                
+[22:03]  oops...
                
+[22:03]  0) welcome 
                
+[22:03] * mihi_ did not look 2 the left column
                
+[22:03]  hi.  65th meeting I suppose. 
                
+[22:03]  hehe 
                
+[22:03]  1) that code stuff 
                
+[22:04]  0.2.1.1 came out last night 
                
+[22:04]  lots of goodness in there. 
                
+[22:04] * mihi tests it atm.
                
+[22:04]  tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild 
                
+[22:05]  messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness) 
                
+[22:05]  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]  (i2p doesn't have enough traffic on it to cause real load atm anyway) 
                
+[22:06]  (but bw limiting will be unit tested and fixed for 0.2.1.2) 
                
+[22:07]  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]  we may be able to work out a way to not require semi-sync'ed clocks, but its delicate. 
                
+[22:07]  2) fun stuff 
                
+[22:08]  a lot of the bugs being worked out in the last few releases are related to the crappy kludge of a BroadcastNetworkDB. 
                
+[22:08]  since its planned for replacement in 0.3, might as well at least mention what its being replaced with 
                
+[22:09]  kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed 
                
+[22:09]  [with one small caveat thats still being worked out] 
                
+[22:10]  that kademlia code needs to get written for 0.3 so we can do insert and fetch of RouterInfo and LeaseSet structures. 
                
+[22:10]  however, things would be simpler if it were implemented seperately - and hence testable seperately. 
                
+[22:10]  (unit testing == good) 
                
+[22:11]  so, whats a simple way to unit test a dht?  to write a simple file store/lookup service on it. 
                
+[22:11]  insert fetch? are we talking about content?
                
+[22:11]  enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN 
                
+[22:11]  dm: No, only routerinfo and leaseset structures.
                
+[22:12]  dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said 
                
+[22:12]  okay, thanks.
                
+[22:12]  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]  one question: which protocol is used now for networkDatabase?
                
+[22:13]  sorry, phone. 
                
+[22:13] *** Signoff: godmode0 (Ping timeout)
                
+[22:13]  correct, kademlia is not anonymous, but not non-anonymous either 
                
+[22:13]  modified kademlia will scale. random will not.
                
+[22:13]  tusko> currently we do a flooded broadcast 
                
+[22:13]  what about kademlia getting splitted?
                
+[22:13]  no cell phones allowed into meeting.
                
+[22:13]  <insert zooko comments>
                
+[22:13]  flooded broadcast aka gnutella method definitely won't ;)
                
+[22:13]  Ophite1> right, kademlia doesn't use random ones :) 
                
+[22:13]  Ophite1: works better as freenet routing :)
                
+[22:14]  duck> exactly (<jrand0m> [with one small caveat thats still being worked out] ) 
                
+[22:14]  duck: i rest my case... ;)
                
+[22:14] *** Signoff: mihi (Ping timeout)
                
+[22:14]  is kademlia some sort of hypercube?
                
+[22:14]  no, a circle.
                
+[22:14] *** Signoff: mihi_ (Ping timeout)
                
+[22:14]  and/or a xor tree :) 
                
+[22:15]  splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :)
                
+[22:15]  its a fairly easy protocol, but we can definnitely look around. 
                
+[22:16]  icepick has implemented kademlia in python too, for ent (as kashmir) 
                
+[22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
                
+[22:16]  consider also malicious nodes deliberately fragmenting the tree.
                
+[22:16]  absolutely.  but its fairly attack resistant 
                
+[22:16]  256 bit keyspace is more resistant to that though.
                
+[22:17]  plus would have to make a lot of routeridentity structures = hard.
                
+[22:17]  i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/
                
+[22:17]  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]  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]  look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php
                
+[22:18]  though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it.
                
+[22:18]  interesting tusko, I think their economic model might require some revision, as with their sybyl defenses 
                
+[22:19]  (you may already; haven't ready that part)
                
+[22:19]  absolutely Ophite1.  I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included) 
                
+[22:20]  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]  well, hashcash verification should be near instantaneous 
                
+[22:21]  and hashcash generation shouldn't be able to be precompiled 
                
+[22:21]  er, precomputed 
                
+[22:21]  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]  lol 
                
+[22:22] * dm is not fooled.
                
+[22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev
                
+[22:22]  one way of preventing that is to use derivatives of session keys as part of the hashcash..
                
+[22:22]  right.  and/or put in a nonce and the date 
                
+[22:22]  date leads to those troublesome timing problems though. that could be a real issue.
                
+[22:22]  unless you feel like rewriting ntp as well ;-)
                
+[22:22] *** Signoff: mihi (Ping timeout)
                
+[22:23]  heh 
                
+[22:23]  well, we've already run into that a little bit 
                
+[22:23]  (hence the 30 minute fudge factor) 
                
+[22:23]  a session hash may be workable though.  good idea. 
                
+[22:24]  and no, i'm not jrand0m's clone ;)
                
+[22:24]  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]  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]  also, I had some ideas about a search network built in parallel as well 
                
+[22:26]  but, well, its probably more useful to i2p that I focus my time on the router 
                
+[22:26]  it runs on top of i2p?
                
+[22:26]  (making it functional, scalable, and secure) 
                
+[22:26]  yes 
                
+[22:26]  i2p lets idn be anonymous 
                
+[22:27]  what were your search network ideas?
                
+[22:27]  note: its not written yet, but its looking like its #2 on my task list 
                
+[22:27]  can another dht be built through tunnels?
                
+[22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev
                
+[22:27]  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]  hmm, yes, certainly.  but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP) 
                
+[22:28]  if ~all node participate = very useful for "discovering" other protocols.
                
+[22:28]  definitely 
                
+[22:28]  so, should be standard.
                
+[22:28]  dhcp/zeroconf for the i2p? :)
                
+[22:28]  idn would be a very good app to bundle with i2p to let people have an 'out of box experience' 
                
+[22:29]  If it's meant to be a fully featured communication/file transfer/storage application, I'd like to propose the name "Darknet".
                
+[22:29]  :) 
                
+[22:29]  You, of course, probably already know where that comes from. :)
                
+[22:30]  Where does it come from?
                
+[22:30]  MS Research's paper: The Darknet and the Future of Content Distribution.
                
+[22:30] *** Signoff: godmode0 (Ping timeout)
                
+[22:30]  link?
                
+[22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
                
+[22:30]  well, tim may says he invented the term ~11 years ago ;) 
                
+[22:30]  where is the I2PIDN wiki page?
                
+[22:30]  (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc
                
+[22:30]  tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN 
                
+[22:30]  also implies that the network works "in the dark" - noone knows who anyone is ;)
                
+[22:30]  exactly. 
                
+[22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev
                
+[22:31]  well, i2p itself is a darknet in that sense, but its generic messaging - it is the IP layer for such a darknet. 
                
+[22:31]  i2ptunnel is the TCP layer, and idn is NFS :) 
                
+[22:31]  i2p is the protocol that allows such a network to be created from something broadly like overnet.
                
+[22:31]  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]  funny that you mention that :) 
                
+[22:32] *** nickthief76430 is now known as mihi_backup
                
+[22:32]  oops...
                
+[22:32]  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]  would a bulk/low-latency bit compromise anonymity slightly (intersection attack?) by allowing traffic linkage? well, even if it were sometimes flips?
                
+[22:33]  ah, well that might work better of course =)
                
+[22:33]  Don't worry about local plausible denability.
                
+[22:33]  right, i2p assumes the local machine is trusted 
                
+[22:33] *** Signoff: dm (Ping timeout)
                
+[22:33]  That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P.
                
+[22:34]  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]  heh 
                
+[22:34]  TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-)
                
+[22:34]  lol 
                
+[22:34]  done and done
                
+[22:34] *** Signoff: tonious (Ping timeout)
                
+[22:34]  hah! 
                
+[22:35] * jrand0m watches my squid proxy get taken down by the fbi
                
+[22:35]  its a trap!
                
+[22:35]  get an axe! 
                
+[22:35]  :) 
                
+[22:35]  anybody play uplink?
                
+[22:35]  completed it. cracked it. released it.
                
+[22:35]  trained it too ;)
                
+[22:36] * jrand0m takes that as a "yes"
                
+[22:36] *** dm (~as@anon.iip) has joined channel #iip-dev
                
+[22:37]  there may be some dos possibilities in caching, in memory stuff...
                
+[22:37]  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]  oh certainly.  the todo list has 'sync pending and large messages to disk' :) 
                
+[22:37]  shouldn't IDN be implemented after I2P is tested and mature?
                
+[22:38]  thats one of the problems we ran into testing a large file of TC's eepsite 
                
+[22:38]  dm: not given as it's a testbed for the fancy db.
                
+[22:38]  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]  I do like the hybrid dht nature such a network would provide though.
                
+[22:39]  aha... 
                
+[22:39]  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]  dht node discovery + ngr-like routing = scalability capable of handling critical mass
                
+[22:39]  what happened to that original milestone list. secure-->anonymous-->not harvestable, etc...
                
+[22:39]  jrand0m: I will refrain from advertising it to pirates until it's ready. that enough?
                
+[22:39]  well, minus the ngr-like routing :) we tunnel :) 
                
+[22:39]  as long as we keep the cli
                
+[22:39]  ah scalable was one of the items in that chain.
                
+[22:39]  dm> 0.3 is necessary for scalable.  which is before not harvestable 
                
+[22:39]  thanks Ophite1 :) 
                
+[22:40]  definitely TC.  I'll need the cli to test it 
                
+[22:40]  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]  (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]  alrighty... sounds okay then.
                
+[22:40]  absolutely ophite. 
                
+[22:40]  suggestion: maximum message size?
                
+[22:40]  thats the Hard problem 
                
+[22:41]  max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k 
                
+[22:41]  but I don't want to resort to that yet 
                
+[22:41] * Ophite1 goes digging in notes
                
+[22:41]  BitTorrent/Scone scalability notes indicate 512K.
                
+[22:42]  heh ok cool.  (any refs I can dig into?) 
                
+[22:42]  but, think of it like tcp window size.
                
+[22:42]  right 
                
+[22:42]  not for scone, sorry - friend's research project.
                
+[22:42]  coo', no worry 
                
+[22:42] *** Signoff: mihi_backup (Ping timeout)
                
+[22:42]  fwiw, your kademlia is about as good as his though :)
                
+[22:42]  hehe 
                
+[22:42]  (well, I haven't implemented it yet ;) 
                
+[22:42]  uh, hers I mean :/
                
+[22:42]  oh wikked 
                
+[22:43]  boner..
                
+[22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev
                
+[22:43]  heh 
                
+[22:43]  so, thats 2) kademlia, 0.3, and idn 
                
+[22:43]  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]  haha 
                
+[22:45]  she's a math.
                
+[22:45]  even better 
                
+[22:45]  there's a lot of stats gathering / analysis that will be coming up for advanced peer selection 
                
+[22:45]  but I'll see if I can bounce stuff past her. scalability from i2np 0.9 was from her - she likes it.
                
+[22:45]  (unfortunately we can't cheat like mnet, mixminion, and tor) 
                
+[22:46]  great to hear 
                
+[22:46]  one comment - dsa?
                
+[22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev
                
+[22:46]  dsa 1024 bit, as in SHA-1?
                
+[22:46]  yea 
                
+[22:47]  'spose it is tried and tested.
                
+[22:47]  also small.
                
+[22:47]  right.  but I'm not 100% tied to our particular crypto impls 
                
+[22:47]  anyway. to roadmap.
                
+[22:47]  haha, lets name a windows version 'Microsoft Darknet (r)'
                
+[22:47]  heh tc 
                
+[22:48]  ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? 
                
+[22:48]  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]  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]  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]  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]  trusted peers is an area that needs some revision imho.
                
+[22:50]  agreed. 
                
+[22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev
                
+[22:50]  only area that doesn't give me warm fuzzies.
                
+[22:50]  though that may just be the word "trusted". :)
                
+[22:50]  basically my current thoughts are to publish tunnels to routers 
                
+[22:50]  heh 
                
+[22:51]  (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]  need to analyse anonymity implications of that.
                
+[22:51]  but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers. 
                
+[22:52]  don't think that is truly possible...
                
+[22:52]  certainly.  yet another reason it should get 0.4 
                
+[22:52]  Ophite1> trusted nodes with timed / triggered self destruct. 
                
+[22:52]  set up a patsy, route through it, kill it 
                
+[22:52]  exactly, if patsies delete their logs after N hours / N bytes / N messages 
                
+[22:52]  I mean if you want me to release a worm that sets up a couple of million...
                
+[22:53]  logs? what logs?
                
+[22:53]  :) 
                
+[22:53]  ok, format the disks ;) 
                
+[22:53] * Ophite1 wrote kernel-level stealth trojan
                
+[22:53]  nice 
                
+[22:53] * dm wrote kernel level outlook calendar plugin.
                
+[22:53]  ...when I was 19 :)
                
+[22:53]  still works. :)
                
+[22:54]  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]  when I was 12.
                
+[22:54]  I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed 
                
+[22:54]  heh Ophite1 
                
+[22:54]  heh dm 
                
+[22:54]  frankly, think that is a fluff feature.
                
+[22:54]  perhaps. 
                
+[22:55]  restricted routes is a necessity though 
                
+[22:55]  its basic functionality for people behind firewalls 
                
+[22:55]  (very restrictive firewalls) 
                
+[22:55]  hello, transports.
                
+[22:55]  we'll get to that.
                
+[22:55]  or is now the appropriate time to discuss them?
                
+[22:55]  sure, lets dig in :) 
                
+[22:56]  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]  even though it was due to misconfiguration, it could be more common 
                
+[22:57]  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]  You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound.
                
+[22:57]  definitely 
                
+[22:57]  forged IP addresses?!?
                
+[22:58]  believe me, firewalls are a VERY common problem.
                
+[22:58]  sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :)
                
+[22:58]  I2P is gonna use IP spoofing? :)
                
+[22:58]  definitely.  if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue. 
                
+[22:59]  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]  dm> transport options 
                
+[22:59]  absolutely Ophite1 
                
+[22:59]  dm: I have a working implementation - in the Direct Connect protocol.
                
+[22:59]  i2p wants to be the battleground for that code. 
                
+[22:59]  dm: If *that* can handle it, i2p can.
                
+[22:59] *** Signoff: tonious (Ping timeout)
                
+[23:00]  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]  you can't spoof IPs without native code can you?
                
+[23:00]  the advantage is that they don't have to route *through*, just help the setup.
                
+[23:00]  = massive speed boost.
                
+[23:01]  definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for 
                
+[23:01]  dm: yeah, like this isn't going to be rewritten?
                
+[23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev
                
+[23:01]  okay, just checking...
                
+[23:01]  right dm, I have no qualms whatsoever with including native code in i2p 
                
+[23:01]  I would like to state that I don't think java is a permanent solution.
                
+[23:01]  And that I regard java router as testbed/prototype.
                
+[23:01]  thats fine.  if it gets us to 1.0, works out the protocol, etc, good enough. 
                
+[23:02]  ...and hope it doesn't get stuck there as freenet has ;)
                
+[23:02]  IPAddress.Spoof(192.168.32.1);
                
+[23:02] *** alient (alient@anon.iip) has joined channel #iip-dev
                
+[23:02]  lol dm 
                
+[23:02]  import IPSpoofing;
                
+[23:02]  mmm... raw sockets in java ;)
                
+[23:02]  fcntl / ioctl in java... mmMMmm 
                
+[23:02]  hmm, raw sockets require root on unix, don't they?
                
+[23:02]  women with large breasts lickig my penis.. mmMMmmm
                
+[23:02]  so we include a rootkit 
                
+[23:03]  ;) 
                
+[23:03]  jrand0m: got it covered =)
                
+[23:03]  heh 
                
+[23:03]  besides as I said; only a few need it.
                
+[23:03]  right 
                
+[23:04]  and only for legitimate reasons, of course. 
                
+[23:04]  on my dc hub, only one (bot) had the capability, and the hub told it when passives wanted to connect to passives.
                
+[23:04]  caused a bit of amazement that did.
                
+[23:04]  hehe 
                
+[23:04]  also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :)
                
+[23:04]  thats definitely a good feature to have avail 
                
+[23:04]  lol 
                
+[23:05] *** Signoff: nickthief54450 (Excess Flood)
                
+[23:05]  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]  any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc? 
                
+[23:06]  I say push it to 0.4 definitely. It will cause firewall issues at the moment but we are still in testing...
                
+[23:06]  ...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]  right.  and even with firewalls, PHTTP lets them through. 
                
+[23:07]  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]  hax0r
                
+[23:07]  well, yes, hostile proxies can fake confirm, but its all signed, so the message can't go to the wrong place / etc 
                
+[23:08]  but the phttp relay and transport does have a lot of features needed 
                
+[23:08]  in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol.
                
+[23:08]  hm? 
                
+[23:08]  have some experience with firewall tunnelling though.
                
+[23:08]  might want to include a GET fallback.
                
+[23:09]  hmm.  GET goes into logs.  but perhaps as a fallback 
                
+[23:09]  (POST can be to /index.html) 
                
+[23:09]  jrand0m: but it's all signed/encrypted if noderefs are cool...?
                
+[23:10]  unless the proxy becomes an active attacker too, that's going to be quite hard for it.
                
+[23:10]  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]  right.  phttp proxy as is certainly isn't strong enough to go against an active attacker 
                
+[23:11] *** Signoff: grimps (Leaving)
                
+[23:12]  I think it'd be great if people posted some alternate transport ideas to the wiki :) 
                
+[23:12]  ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid] 
                
+[23:12]  damn, tusko left 
                
+[23:12]  tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel 
                
+[23:13]  Told you someone would do that :)
                
+[23:13]  ppp over i2p?
                
+[23:13]  I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times 
                
+[23:13]  heh yeah 
                
+[23:13]  dm: of course.
                
+[23:13]  when could you use that?
                
+[23:13]  could/would
                
+[23:13]  dm> anonymous outproxy 
                
+[23:13]  dm: anonymous ANYTHING.
                
+[23:13]  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]  ah, I understand.
                
+[23:13]  definitely Ophite1 
                
+[23:14]  so right now, its only for trusted peers.   
                
+[23:14]  see also: the dresden JAP cascade... :)
                
+[23:14]  which, well, doesnt really make sense for anonymity... 
                
+[23:14]  heh 
                
+[23:14]  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]  jrand0m: why not i2p over ppp over i2p?
                
+[23:15]  definitely doable.  aint recursion fun? 
                
+[23:15]  i2p over i2p  :-o
                
+[23:15]  or i2p over ppp over i2p over i2p over freenet over kazaa 
                
+[23:15]  now that's just silly. Freenet wouldn't possibly work ;)
                
+[23:16]  over slow connect :)
                
+[23:16]  heh it'd have latency issues, certainly :) 
                
+[23:16]  ... over an icmp tunnel over ...
                
+[23:16]  ooh yes, loki :)
                
+[23:16]  0ldsk00l :)
                
+[23:17]  I2P addresses, being the public keys, are ... rather long.
                
+[23:17]  yes. 
                
+[23:17]  actually, since we're on agenda item 4: ns 
                
+[23:17]  As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!)
                
+[23:17]  co promised to write a naming service...
                
+[23:17]  yeah. 
                
+[23:17]  I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns  
                
+[23:17]  Ophite1: post them to the eepsite forum.
                
+[23:18]  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]  (just toss on a CA or WoT CAs, and voila.  (Link: www.mihi.i2p)www.mihi.i2p) 
                
+[23:18]  not necessarily. 
                
+[23:18]  please enlighten me with your better ideas then.
                
+[23:18]  Ophite1> check out co/wiht's specs on the iip-dev list.   
                
+[23:19]  best I could come up with is root key creates signed namespaces. dnssec stylee.
                
+[23:19]  he doesn't go the full route with a dht, but he manages groups 
                
+[23:19]  just like how we do now - we /all/ can choose who our root dns servers are. 
                
+[23:19]  in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is 
                
+[23:20]  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]  agreed 
                
+[23:20]  you either trust the root CA or you don't.
                
+[23:20]  and if you don't trust the root, you create your own 
                
+[23:21]  (or find another) 
                
+[23:21]  and if you don't trust the root CA it's for a reason, a reason that will rapidly get around.
                
+[23:21]  exactly 
                
+[23:21]  especially when there's anonymous publishing :) 
                
+[23:21]  being as CA's only real purpose is to insure anti-collision - like Trent...
                
+[23:21]  right 
                
+[23:22]  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]  self signed certs+++ 
                
+[23:24]  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]  It's for servers, really.
                
+[23:24]  heh 
                
+[23:24]  right 
                
+[23:24]  Servers don't scale. That problem will be in i2p as much as in IP.
                
+[23:24]  so, I think that the usage in practice will actually be surprisingly limited.
                
+[23:24]  the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name 
                
+[23:24]  agreed. 
                
+[23:25]  except / until someone writes a distributed outproxy system 
                
+[23:25]  aka o-r / freedom  over i2p 
                
+[23:25]  how many diffrent keys can we have?
                
+[23:25] * jrand0m looks forward to that day
                
+[23:25]  tc> 2^2048 
                
+[23:25]  jrand0m: at which point the root key signs them a namespace: .proxy.i2p
                
+[23:26]  This must be the most hypothetical/megalomaniac open source development meeting ever :)
                
+[23:26]  aint subspaces grand :) 
                
+[23:26]  lol dm 
                
+[23:26]  hey, we're alowed to aim high, aint we? 
                
+[23:26]  I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?"
                
+[23:26]  jrand0m: oddly as it may seem, not every number works for elgamal ;-)
                
+[23:26]  dm, youve seen debian meetings right?
                
+[23:26]  awww c'mon, 000000000000000000000000000 is a secure key 
                
+[23:26] * Ophite1 hands out Chocolate Digestives
                
+[23:26]  TC: no, what are the like?
                
+[23:26]  jrand0m: ooh, identity.
                
+[23:26]  dm, i dont know, i was asking
                
+[23:27]  ok.  thecrypto isn't here either... anyone have im thoughts? 
                
+[23:27]  damn, I was about to ask about that.
                
+[23:27]  quite an important app.
                
+[23:27]  Anyway, this type of meeting is more lurker-friendly, so I'm all for it.
                
+[23:27] * dm is entertained.
                
+[23:27]  heh 
                
+[23:27]  where is co?
                
+[23:27]  as many people will expect i2p to be iip's successor.
                
+[23:28]  iip over i2p is fairly easy, if we don't want dcc 
                
+[23:28]  (I guess it could be, if we just run an iip irc server over i2p...)
                
+[23:28]  iip over i2p with dcc requires a new app 
                
+[23:28]  exactly Ophite1 
                
+[23:28]  0 coding 
                
+[23:28]  cant we just run irc over i2p?
                
+[23:28]  I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :)
                
+[23:28]  but last I heard, thecrypto was doing some work on an IM app 
                
+[23:28]  certainly tc 
                
+[23:29]  right Ophite1, and it doesn't scale 
                
+[23:29]  (all the traffic gets funneled to the ircd) 
                
+[23:29]  Also the IRCd can spy on traffic.
                
+[23:29]  ah, goodpoint
                
+[23:29]  (this would be when UserX should show up and discuss his ideas for iip2.0) 
                
+[23:29]  right Ophite1 
                
+[23:29]  all the problems of the current iip 
                
+[23:29]  jrand0m: And absolutely nothing different.
                
+[23:29]  more lag. 
                
+[23:30]  except it's in java. lovely. :)
                
+[23:30]  heh 
                
+[23:30]  Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications.
                
+[23:30]  ok, so someone should either help thecrypto out or push him along some more :) 
                
+[23:30] * Ophite1 points out IRC3
                
+[23:30]  yeah, its a perfect school project 
                
+[23:30]  ..and SILC...
                
+[23:30]  ...and...
                
+[23:31]  well about a gazillion others.
                
+[23:31]  'zactly 
                
+[23:31]  Literally all of these, I might add, are pre-DHT as far as I can tell.
                
+[23:31]  yup 
                
+[23:31]  That's disappointing 'cause that's a freakishly useful structure.
                
+[23:31]  a DHT for lookup / P3P, and then direct con for IM 
                
+[23:31]  group chat is harder though, but not too hard 
                
+[23:31]  well, direct in the i2p sense :)
                
+[23:31]  heh right 
                
+[23:32]  what about darkmail/i2pmail?
                
+[23:32]  group sex too
                
+[23:32]  soros: agreed.
                
+[23:32]  group sex isn't that hard soros ;) 
                
+[23:32]  lol 
                
+[23:32]  email over i2p is easy.  someone just needs to run a pop server 
                
+[23:32]  or webmail 
                
+[23:32]  hahah 
                
+[23:33]  jrand0m: sure, as long as literally everyone is okay with bloody pgp :)
                
+[23:33] * Ophite1 gets CKT nightmares again
                
+[23:33]  oh, true.  that'd expose the contents to hte server ;) 
                
+[23:33]  Also... spam.
                
+[23:33]  yup 
                
+[23:33]  We have this thing called hashcash.
                
+[23:33]  They sort of fit together, no?
                
+[23:34]  ok, so yeah, someone should get working on an i2p specific email app :) 
                
+[23:34]  obviously that would work best as part of the im.
                
+[23:34]  What, after all, is the distinction between irc and email?
                
+[23:34]  true, like an IM VMB 
                
+[23:34]  Whether or not you can page up and see what you missed after you rejoin...
                
+[23:34]  placed into the dht 
                
+[23:34]  good point 
                
+[23:35] * jrand0m wishes we had a team of a dozen coders
                
+[23:35]  note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication.
                
+[23:35]  also email has a lot more penis enlargement adverts.
                
+[23:35]  jrand0m: ask around for funding.
                
+[23:35]  dm: see above re: hashcash.
                
+[23:35]  right, the P3P could contain pending messages 
                
+[23:36]  dm: A primitive that was not available to the bloke who hacked up email in a night.
                
+[23:36]  (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]  jrandom%ophite!dm!mihi 
                
+[23:37]  no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;)
                
+[23:37]  haha 
                
+[23:37]  several of these things *are* sort of related.
                
+[23:37]  true, 387 bytes base64 encoded... 
                
+[23:38]  or to put it another way, ELONGURL :)
                
+[23:38]  heh 
                
+[23:38]  [does IE chop at 512?]
                
+[23:38]  naw, works fine 
                
+[23:38]  you admit to using IE?
                
+[23:38]  To browse anonymously?!
                
+[23:38]  ;) 
                
+[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]  what item are we now?
                
+[23:39]  4?
                
+[23:39]  yeah, ok ok 
                
+[23:39]  still 4 I think.
                
+[23:39]  i2ptunnel.  still kicks ass. 
                
+[23:39]  any thoughts?  any comments mihi? 
                
+[23:40]  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]  mihi (or someone else)> it'd be really easy to bootstrap such a naming service with an /etc/hosts style i2p ns 
                
+[23:41]  btw: are there any other public dests except your squid and tc's eepsite?
                
+[23:41]  i2pcvs.dest 
                
+[23:41]  (points at the i2p cvs pserver) 
                
+[23:41]  (but isn't always up) 
                
+[23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev
                
+[23:41]  hola yodel 
                
+[23:41]  hela
                
+[23:42]  ok, I think thats it for 4) apps 
                
+[23:42]  5) comments / questions / etc 
                
+[23:42]  gui installer?
                
+[23:42]  hi yodel
                
+[23:43]  I have to start experimenting putting the xml-rpc over i2p
                
+[23:43]  should work with httptunnel
                
+[23:43]  good question mihi.  last I heard MrEcho had some of it working 
                
+[23:43]  awesome yodel 
                
+[23:43]  definitely. 
                
+[23:43]  how large are the streams? 
                
+[23:43]  (aka how chatty is the protocol?) 
                
+[23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test
                
+[23:44]  xml over http
                
+[23:44]  the ssl layer wont be needed with i2p
                
+[23:44]  so, uh, very chatty? :)
                
+[23:44]  ah cool, large POST or large replies? 
                
+[23:44]  (or just small and small?) 
                
+[23:45]  damn you Ophite1 :) 
                
+[23:45]  equal sizes
                
+[23:45]  does httptunnel support gzipped http?
                
+[23:45]  but doesn't bt use IP addresses? 
                
+[23:45]  hmm, httptunnel doesn't have any inherent compression, its just a bitstream 
                
+[23:45]  hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares
                
+[23:45]  so should work...
                
+[23:45]  jrand0m> you test i2p in nntp news server ?
                
+[23:45]  yup yodel 
                
+[23:45]  500-1000 byte send, same for reply
                
+[23:46]  hmm I haven't tested that yet godmode0 
                
+[23:46]  much less when zipped
                
+[23:46]  oh cool yodel, that'll work without any problem 
                
+[23:46]  what is the latency for a single msg/package/whatever?
                
+[23:46]  2-5s, sometimes up to 10s 
                
+[23:46]  (currently) 
                
+[23:46]  not bad for a pre-dht :)
                
+[23:46]  so 20s roundtime?
                
+[23:47]  I usually pull up a web page in 5-10s 
                
+[23:47]  ah
                
+[23:47]  goo
                
+[23:47]  +d
                
+[23:48]  damn, we're coming up to the 2 hour mark.  anyone have any other questions / thoughts? 
                
+[23:48]  Pie is good.
                
+[23:48]  jrand0m: why do you drink cheap local beer?
                
+[23:48]  Orgy and pie is better.
                
+[23:48]  rofl duck 
                
+[23:49]  duck: It's better than Tesco Value Lager?
                
+[23:49] * Ophite1 spits from reflex
                
+[23:49]  heh 
                
+[23:49] * duck is concerned about jrand0m's health
                
+[23:49]  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]  do you eat well?
                
+[23:50]  corona
                
+[23:50]  do you do your daily exercises?
                
+[23:50]  well, i'm one of those veggies 
                
+[23:50]  Isn't that a personal question, duck?
                
+[23:50]  does typing count? 
                
+[23:50]  you did drink that much already?
                
+[23:50]  that you became a veggie
                
+[23:50]  heh 
                
+[23:50]  cheap beer will do that.
                
+[23:51]  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]  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/i2p2www/meetings/66.log b/i2p2www/meetings/66.log
new file mode 100644
index 00000000..acb50913
--- /dev/null
+++ b/i2p2www/meetings/66.log
@@ -0,0 +1,477 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 66{% endblock %}
+{% block content %}
                Tuesday, November 26, 2003 22:00:00 CET
                
+
                
+[22:04]  agenda: 
                
+[22:04]  0) welcome 
                
+[22:04]  1) status 
                
+[22:04]  2) transport futures 
                
+[22:05]  3) peer stats for selection 
                
+[22:05]  4) apps 
                
+[22:05]  5) ...? 
                
+[22:05]  0) 
                
+[22:05]  hi. 
                
+[22:05]  66 is it? 
                
+[22:05]  7) what brand of whiskey does jrand0m drink?
                
+[22:06]  bushmills, glenlivit 
                
+[22:06]  (for whiskey and whisky, respectively) 
                
+[22:06]  yey, i made the meating
                
+[22:06]  woot 
                
+[22:06]  ok, 1) status 
                
+[22:06]  the kademlia stuff is coming along very well. 
                
+[22:07]  I've build a little simulator that runs a network of five nodes and puts them through the basic tests 
                
+[22:07]  also the idn stuff is implemented with some tests as well 
                
+[22:08]  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]  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]  idn right now is kind of functional, except for inter-node comm (which will be replaced with comm over i2p, of course ;) 
                
+[22:10]  idn is the stuff for the distributed storage?
                
+[22:10]  roadmap has been updated as well - http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap 
                
+[22:10]  yes 
                
+[22:10]  idn = Invisible Distribution Network 
                
+[22:10]  (free open source anonymous akamai, basically) 
                
+[22:11]  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]  mnet is probably up that alley 
                
+[22:12] *** Signoff: nickthief60934 (Excess Flood)
                
+[22:12]  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]  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]  would it be posible do image grabs do idn from an i2ptunnel eepsite?
                
+[22:15]  hmm? 
                
+[22:15]  oh, like <img src="idn:blah">? 
                
+[22:15]  i was just thinking of bandwidth saving, yes
                
+[22:15]  protocol would be the obvious way to go, yes.
                
+[22:16]  hmm Ophite1? 
                
+[22:17]  (sorry, I'm sick again so might not be quite on top of my game today) 
                
+[22:17]  how many LOC have you written jr?
                
+[22:17]  Ophite1, could i2p tunnel be modified to redirect?
                
+[22:18]  or could the browser do it on its own somehow?
                
+[22:18]  dm> "find . -exec grep \\\; {} \; | wc -l" currently puts the sdk ~8kloc, the router ~11kloc 
                
+[22:18]  okay thanks.
                
+[22:19]  idn would want to support receiving requests from browsers. 
                
+[22:19]  would mean integrating idn into i2ptunnel. very ugly.
                
+[22:19]  currently idn has a so-god-damn-easy api. 
                
+[22:19]  the api is the file system. 
                
+[22:19]  aka:  
                
+[22:19]  command=get 
                
+[22:19]  key=zGb1tPM6ARNRTWZLCWK4XXco2Ngk8ccx-ciDUCom~9U 
                
+[22:19]  saveAs=testGetOutput.txt 
                
+[22:20]  place that in a file in a directory, and voila. 
                
+[22:20]  (that was the easiest possible for me to implement and test with.  certainly better ones can be found and made) 
                
+[22:21]  ok, so, yeah.  thats the status.  I'm hoping for a 0.2.2 release by this time next week, at least. 
                
+[22:22]  that'll include the first integration of the kademlia stuff, tunnel fixes, and i2cp updates. 
                
+[22:23]  ok, 2) transport futures 
                
+[22:23]  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]  link-level encryption is a requirement?
                
+[22:24]  absolutely. 
                
+[22:25]  tls is _hell_ though. ask openssl.
                
+[22:25]  ssh?
                
+[22:25]  that, too.
                
+[22:25]  yeah, I followed the nasty discussions on the cryptography list last month, with interest. 
                
+[22:25]  ssh is definitely a possibility. 
                
+[22:26]  safe, too, since we already essentially have the certificates (in the RouterInfo.publicKey) 
                
+[22:26]  but we're in java. we'd have to code it ourselves? :/
                
+[22:26]  naw, there are ssl, tls, and ssh java libs 
                
+[22:26] *** Signoff: nickthief60934 (Ping timeout)
                
+[22:26]  There's already at least one java ssh client.  Dunno about servers.
                
+[22:26]  re: security of such libs, given numerous high profile holes in openssl, openssh, et al?
                
+[22:27]  Ophite1> most likely better than custom built code. 
                
+[22:27]  not that I have any reason to think there are exploits in the tcp transport as written. 
                
+[22:27]  but it has not been reviewed. 
                
+[22:28] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
                
+[22:28]  in any case, updating the transports isn't really on deck until january (after the 0.3 release goes out) 
                
+[22:28]  but if anyone wants to look into it and do some research, that'd be great 
                
+[22:29]  how many devs do we have activly coding?
                
+[22:29]  1! :)
                
+[22:29]  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]  But he's got the strength of ten men....
                
+[22:30]  mihi has been cleaning up some of my messes, thankfully :) 
                
+[22:30]  haha, it's all jrandom :)
                
+[22:30]  nice way of saying "just me"
                
+[22:31]  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]  heh 
                
+[22:31]  people like that are very, very useful :)
                
+[22:32]  quite 
                
+[22:32]  "who's writing all these catch statements who do nothing ;)" -mihi
                
+[22:32]  d'oooh 
                
+[22:33]  it's cause of reminders like that the code won't get as bad as freenet (we hope?) :)
                
+[22:33]  if in 5 years any of the current i2p code is still in use, I'll be shocked. 
                
+[22:34]  (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]  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]  heh, comment it out and leave it in place
                
+[22:35]  is there a link to see the source on the web? not just the changes.
                
+[22:35]  yes dm, http://i2p.dnsalias.net/ 
                
+[22:35]  nm, found it.
                
+[22:35]  :) 
                
+[22:35]  ok, 4) peer stats for selection 
                
+[22:36]  calling this a nebulus topic is one hell of an understatement. 
                
+[22:36]  doctoral theses could be written (and some have been) on how to choose what peers to use in an untrusted environment. 
                
+[22:36]  public interface Job
                
+[22:36]  oops, meeting. Sorry didn't realize.
                
+[22:37]  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]  (thats the kademlia stuff) 
                
+[22:38]  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]  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]  stats revolving around  latency and uptime 
                
+[22:39] *** Signoff: soros (Client exiting)
                
+[22:39]  suggest you be wary of including accurate information about bandwidth usage and latency in that stats.
                
+[22:40]  as per my drunken questions.
                
+[22:40]  perhaps a more indirect route, but it's an area that needs very careful, well considered attention.
                
+[22:40]  hmm, with the intent of keeping the accurate info unknown, or to defeat predictabilities? 
                
+[22:40]  right 
                
+[22:41]  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]  but I think we want to gather and use as accurate info as we can, /then/ adjust for entropy 
                
+[22:42]  mere entropy alone may not be enough.
                
+[22:43]  but, I need more research on this :/
                
+[22:43]  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]  no rush, just wanted to plant the subject in the minds of those out there :) 
                
+[22:44]  ok, 4) apps 
                
+[22:45]  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]  w00t :) 
                
+[22:45]  inclusion of accurate or accurate+some%entropy statistics may make some attacks work though.
                
+[22:46]  oh, before apps i have a question
                
+[22:46]  well, its always easy enough to simply discard accurate info as necessary 
                
+[22:46] *** Signoff: nickthief60934 (Excess Flood)
                
+[22:46]  sure tc, whats up? 
                
+[22:46]  (stats will also (hopefully) make it easier to debug the network's operation while in development) 
                
+[22:46]  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]  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]  which is okay as long as the non-local hop doesn't KNOW it's the only non-local hop.
                
+[22:48]  that will be up'ed to 2-4 once things are more reliable 
                
+[22:48]  right Ophite1 
                
+[22:48]  still one better than a gnunet shortcut, so it's cool :)
                
+[22:48]  oh, and how do speed improvements look?
                
+[22:48] * jrand0m is basing that 2-4 # on o-r comments
                
+[22:49]  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]  hmm, speed improvements will come through more reliable and faster peer selections, which is the 0.3 release 
                
+[22:49]  jeez, I forgot how jr's code looks like it was written by a robot.
                
+[22:49]  Hmmm, that would explain a lot.
                
+[22:50]  and through more scalable routing, which is next weeks' :)
                
+[22:50]  heh sorry dm, I'll try to be more inconsistent ;) 
                
+[22:50]  (did I just mean discovery?)
                
+[22:50]  right, its discovery, not routing, really. 
                
+[22:51]  i2p is scale free for normal comm. 
                
+[22:51]  (and o(log(n)) for discovery) 
                
+[22:51]  i think your average ai who lives on the net would be pro i2p, what do you think dm?
                
+[22:52]  I think the average method size in this code is the smallest I've ever seen is what I think.
                
+[22:53]  dm: clean. very good for a proto :)
                
+[22:53]  Do you comment as you go or do you go back and put those descriptions?
                
+[22:53]  I comment when I get confused 
                
+[22:54]  (I really can't wait until collections are typesafe) 
                
+[22:54]  but, yeah, 4) apps :) 
                
+[22:54]  (unless anyone else has router / network questions?) 
                
+[22:55]  pnope
                
+[22:55]  ok, wiht isn't here, anyone else have any naming service thoughts / comments (mrecho?) 
                
+[22:55]  a distributed naming server?
                
+[22:56]  is wiht ever here?
                
+[22:56]  It could probably just sit on top of IDN.
                
+[22:56]  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]  did co die?
                
+[22:56]  exactly tonious 
                
+[22:57]  perhaps you're right, it could be an app that /uses/ idn, not just uses the code.  hmmm... 
                
+[22:57]  that'd be Good. 
                
+[22:57]  Mebbe have a key fingerprint associated in case of collisions.
                
+[22:57]  naw, co/wiht is around every few days 
                
+[22:57]  Wouldn't even necessarily need a centralized CA?
                
+[22:57]  we'd need a CA if nyms are unique. 
                
+[22:58]  The CA signing chain should elminiate collisions.
                
+[22:58]  (and we need nyms to be unique to do naming, really) 
                
+[22:58]  of course this makes CA key very important.
                
+[22:58]  how about dys dns? can i make my host file redirect to a eepsite?
                
+[22:59]  TC: Not really.  The OS doesn't even see i2p.
                
+[22:59]  though we could have $nym.$ca be the thing looked up for 
                
+[22:59]  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]  right, though with tusko's ppp2p we can get i2p to IP mappings 
                
+[23:00]  I dunno.  The idea of a CA in an essentially distributed system disagrees with me.
                
+[23:00]  Not bein' a developer though I'm not gonna make a fuss :)
                
+[23:01]  dns really isnt that importent
                
+[23:01]  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]  if you can think of a better way?
                
+[23:02]  i have another question - its sort of spans the network-application area.
                
+[23:02]  (thats really the degenerate case of a WoT) 
                
+[23:02]  what I said, sort of - get a root key to sign domains...
                
+[23:02]  agreed tc 
                
+[23:02]  fire away Nostradumbass 
                
+[23:02]  someone gets com.i2p or nym.i2p...
                
+[23:02]  has any thought been goven to guaranteed latency?
                
+[23:02]  allow them to sign jrand0m.nym.i2p, or whatever.
                
+[23:02]  i'm thinking of VoIP.
                
+[23:03]  Ophite1> we wouldn't even need a .i2p key with that 
                
+[23:03]  Ophite1: What if the com ca gets taken out by an RIAA hitsquad or something?
                
+[23:03]  Nostradumbass> you mean VoI2P?  :) 
                
+[23:03]  then once you're done, destroy the master CA.
                
+[23:03]  yes
                
+[23:03]  tonious: then there's still the others.
                
+[23:04]  or some system that requires conspiring groups to get the nym signing key?
                
+[23:04]  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]  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]  and a really freakin' big hashcash?
                
+[23:04]  definitely Nostradumbass 
                
+[23:04]  Ophite1: Mebbe a majority signing protocol?
                
+[23:04] *** Signoff: dm (Ping timeout)
                
+[23:04]  tonious> majority is dangerous with sybil 
                
+[23:05]  tonious: otoh, it HAS to be non-repudiatory, and has to be able to guarantee non-collision.
                
+[23:05]  and majority couldn't do that.
                
+[23:05]  a majority of well known users maybe.
                
+[23:05]  if it's a consolation, the internet has problems with this too (think Verisign).
                
+[23:05]  right, WoT :) 
                
+[23:06]  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]  Nostradumbass> now if we could get some coders to work on a high performance RTSP over i2p tunnel... ;) 
                
+[23:06]  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]  Nostradumbass: not guaranteed.
                
+[23:07]  so how do we secure alias identification (important for commerce and seting up multiple eepsites)?
                
+[23:07]  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]  yes Nostradumbass, QoS can be done transparently within i2p, but unfortunately thats (I hate saying this) > 1.0 
                
+[23:07]  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]  Nostradumbass: also, troublesome re some potential attacks?
                
+[23:08]  You also specify who's keys you trust, ala PGP.  I think redundancy is more important than collision.
                
+[23:08]  tonious: so which jrand0m.nym.i2p did you want again?
                
+[23:08] * jrand0m attacks the ns dht to get my nym back
                
+[23:08]  if everyone doesn't trust the same, we might not be referring to the same thing when we use the same name.
                
+[23:09]  and it would probably allow freenet-KSK-style collision wars.
                
+[23:09]  right.  either the naming service has CA signed nyms, or it just distributes H(destination) --> destination mappings 
                
+[23:09]  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]  (and H(destination) == 42 chars as opposed to ~500 chars for a destination) 
                
+[23:10]  tonious: if you're going to give it public keys, you might as well just sling around I2P addresses.
                
+[23:10]  now that's an interesting ideal
                
+[23:10]  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]  I smell kademlia again.
                
+[23:11]  :) 
                
+[23:11]  It can also be simply checked.
                
+[23:11]  and there's existing code to reuse. 
                
+[23:11]  somehow, that makes sense. why weren't we doing this already? :)
                
+[23:11]  because we want nyms 
                
+[23:12]  nyms for hosts?
                
+[23:12]  but, I suppose, 42 chars is a good enough starting point 
                
+[23:12]  need a root CA for that :/
                
+[23:12]  right 
                
+[23:12]  in the case where you don't want to trust a root ca?
                
+[23:12]  42 chars is short enough to paste.
                
+[23:12]  you don't need a root CA, you can have a forest instead of a tree 
                
+[23:12]  520 chars isn't :)
                
+[23:12]  heh 
                
+[23:13]  but if you have a forest, how does anyone know which tree you're talking about?
                
+[23:13]  you could slap a key in there, but then, ooh, we've got huge strings of random garbage again.
                
+[23:13]  common suffix.  $nym.$ca 
                
+[23:13]  well, I'd like $nym.$ca.i2p :)
                
+[23:13]  avoid confusion :)
                
+[23:13]  right.  I mean, there are possible attacks.  I dunno.  I'm with TC though  
                
+[23:13]  good 'nuff for me  
                
+[23:14]  ok, /other/ apps :) 
                
+[23:14]  how do you know which ca is which?
                
+[23:14]  you have a list? what signs the list?
                
+[23:14]  i2pns.config 
                
+[23:14] *** Signoff: Drak0h (Ping timeout)
                
+[23:14]  how're you going to get that?
                
+[23:14]  if i could make my own dns list, hostfile style i would be happy
                
+[23:14]  on install 
                
+[23:15]  how are you going to verify those are the "right" keys?
                
+[23:15]  ca substitution?
                
+[23:15]  right tc, we can even do that without any distributed naming service 
                
+[23:15]  because i say they are Ophite1
                
+[23:15]  Ophite1> you aren't, any more than you're verifying that the source code is running the "real" i2p 
                
+[23:15]  and if you trust me, you can download them off my eepsite
                
+[23:16]  I suppose at the end of the day you can only reduce that to trust in one key being right, so :)
                
+[23:16]  works for me, yeah.
                
+[23:16]  as long as I get o1.i2p ;)
                
+[23:16]  heh 
                
+[23:17]  Hmm.  Revised threshold scheme:  Each CA works the entire namespace, but a majority of CAs must agree before handing out subspace?
                
+[23:17]  ok, last I heard tusko had found a way to get the ppp2p to run off windows machines as well as *nix 
                
+[23:17]  it would make the i2p\internet doman system much more community based if we all passed around a huge hostfile\cheat sheet
                
+[23:17]  tonious: back to majority again...
                
+[23:17]  scary for attacks tonious 
                
+[23:17]  thats true TC 
                
+[23:17]  (and the value of such a community should not be underestimated) 
                
+[23:18]  tc: arpanet stylee?
                
+[23:18]  Sigh. :)
                
+[23:18]  I guess seeds have gotta come from somewhere, so yeah ;)
                
+[23:18]  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]  sounds like that'd be a heavily retrieved key from idn :) 
                
+[23:19]  smells vaguely ca-like too :)
                
+[23:19]  you could even have a fight, with more then one file
                
+[23:19]  the fidonet nodelist!
                
+[23:19]  And in case of a netsplit there'd be multiple patchfiles.
                
+[23:19]  ...doesn't scale.
                
+[23:19]  with under a few hundred domains, its maintainable manually 
                
+[23:20]  after a few hundred you go trusted
                
+[23:20]  right Ophite1.  this would just be until we argue out the Right Way. 
                
+[23:20]  It might be enough to jumpstart a WoT.
                
+[23:20]  (or we convince people that CAs aren't that bad ;) 
                
+[23:20]  true tonious 
                
+[23:20]  if you're trusting someone to agree that someone is someone else, that's a CA, not just a nodelist :)
                
+[23:21]  Heh.  Sorry for bein' the skeptic.
                
+[23:21]  jrand0m, in the end i dont whant to be dependent on CA's
                
+[23:21]  just allow people to give space below theirs...
                
+[23:21]  castyle -- and those on the nodelist to be the cas.
                
+[23:21]  course then it's all "which ca is jrand0m on?"
                
+[23:21]  CA's aren't necessarily choke points.  if they're unsatisfactory, we replace them.   
                
+[23:22]  Ophite1: I like that.
                
+[23:22]  point. CA being crapped out would be Big Enough News for someone to simply replace them.
                
+[23:22]  tonious: so is it slashdot.org or slashdot.com? goatse.cx? :)
                
+[23:22]  what does CA stand for? :)
                
+[23:22]  certification authority.
                
+[23:23]  k, thanks.
                
+[23:23]  Heh.  That's where your own WoT comes in, Ophite1.
                
+[23:23]  tonious: yes, but I still have to see goatse once before I realise it's the wrong bloody one. :)
                
+[23:23]  'I trust Ophite1 not to show that horrible asshole, and he signed slashdot.org'
                
+[23:23]  lol 
                
+[23:24]  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]  and to hand out domains to the rest.
                
+[23:24]  at least one of which ought, really, to be a trent-style first-comes-first-served bot.
                
+[23:24]  (with.. yes... hashcash.)
                
+[23:24]  Yeah.  And there may be namespace collisions by people who are outside my WoT...
                
+[23:25]  yup, and another should be something like thetower's tfee/subpage redirects 
                
+[23:25]  tonious: something that you can actually USE might be appreciated. it's just a naming system. :)
                
+[23:25]  Heh.
                
+[23:25]  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]  ok, other apps... 
                
+[23:26]  IM? 
                
+[23:26]  finally :)
                
+[23:26]  signed nyms! :)
                
+[23:26]  Sorry Ophite1 :)
                
+[23:26]  !thwap Ophite1 
                
+[23:27]  what, what are you all looking at? :)
                
+[23:27]  yes, WoT would be appropriate for _that_ :)
                
+[23:27]  I think I remember who was doing IM... thecrypto?
                
+[23:27]  in fact... elgamal 2048-bit... dsa 1024-bit... sha-256... sounds kind of familiar. openpgp?
                
+[23:27]  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]  I've managed to get SOAP going on mine, too.
                
+[23:28]  yup dm 
                
+[23:28]  No useful apps, beyond 'Yep, it works' so far.
                
+[23:28]  hehe 
                
+[23:29] *** Signoff: nickthief60934 (Excess Flood)
                
+[23:29]  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]  lol Nostradumbass 
                
+[23:29]  nicename :)
                
+[23:29]  Nostradumbass: Yep, you got it.
                
+[23:30]  Now I can set up my own I2P casino. w00t!
                
+[23:30] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev
                
+[23:30]  w33wt 
                
+[23:30]  ok, I think thats 'bout it for the apps 
                
+[23:30]  5) ...? 
                
+[23:31]  hi 
                
+[23:31]  tonious: cool. we could use a few of those. donate a percentage to the i2p project? :)
                
+[23:31]  merchandising
                
+[23:31]  Has anybody thought of a C implementation of I2P?
                
+[23:31]  yeah, rent out colo boxes and run routers :) 
                
+[23:32]  tonious> lets wait until we get the router protocol implemented and thoroughly reviewed before porting ;) 
                
+[23:32]  Or anonymous colo: Behind an I2P router and no internet routing :)
                
+[23:32]  merchandising = logo.
                
+[23:32]  stickers, t-shirts, hats, we need the logo
                
+[23:32]  tonious: after it's working and anonymous and stuff? of course.
                
+[23:32]  Yeah, but I'm still running my P2 and I'm a poor guy.
                
+[23:32]  :(
                
+[23:32]  i2p needs a good logo.
                
+[23:32]  yes
                
+[23:32]  I mean, the internet doesn't have a logo, but that's just bad marketing. :)
                
+[23:32]  I like the one on the WIKI.
                
+[23:32]  also, each made-for-i2p program needs its own tweeked version, or take off of the logo
                
+[23:32]  how about a transparent logo... it'd, be, like, everywhere, dood 
                
+[23:33]  an invisible logo. heh.
                
+[23:33]  A 1 pixel by 1 pixel blank gif?
                
+[23:33]  definnitely 
                
+[23:33]  tonious: we'd be sued for copyright infringment? :)
                
+[23:33]  Ha!
                
+[23:33]  ("Hey, that's OUR blank gif!")
                
+[23:33]  lol 
                
+[23:33]  Hey, if John Cage can do it...
                
+[23:33]  So we leave our names in the comments field :)
                
+[23:33]  Ophite1: how about a stream roller paving over the Internet?
                
+[23:33]  heh we're just rendering his audio 
                
+[23:34]  that one on the bottom looks the best imho.
                
+[23:34]  I like the one on the top.  It's simple.  Like me.
                
+[23:34]  with the arc design.
                
+[23:35]  something that is small, very simple, and above all would work well as an icon, or in the system tray :)
                
+[23:35]  and yes, which can be customised and used as a basis for logos of apps.
                
+[23:35]  right 
                
+[23:35]  How about a black circle with white fill.
                
+[23:35]  that arc would be a good start (colour changes?)
                
+[23:35]  or a triangle, maybe a square!
                
+[23:35]  a parallelogram!
                
+[23:37]  Heh.  Open up a cafepress store...
                
+[23:37]  god no, not cafepress.
                
+[23:37]  a white cloud!
                
+[23:37]  we demand class.   ... thinkgeek. ;-)
                
+[23:37]  little fluffy cloud.
                
+[23:38]  it would look toomuch like a cumpuddle in minature
                
+[23:38] * jrand0m associates clouds with the sky, thankyouverymuch
                
+[23:38]  Ophite1: First we've gotta convince 'em that we're whitehat.
                
+[23:39]  no, lets be black hat
                
+[23:39]  tonious> can militant anarchists be whitehats too? 
                
+[23:39] * TC doesnt like ppl in hats
                
+[23:39]  Dunno.
                
+[23:39] * tonious wears a grey fedora FWIW.
                
+[23:39]  how about a white and a black hat?
                
+[23:39]  and modulus would say somthing about class distinction or something
                
+[23:40]  a small picture of uncle sam's face?
                
+[23:40]  checkered hat?
                
+[23:40]  heh tc 
                
+[23:40]  or white and a black wizzard hats
                
+[23:40]  I am NOT a white hat. How dare you insinuate that. I want an apology.
                
+[23:41]  or a black dunce hat
                
+[23:41]  well, anyway... 
                
+[23:42]  "i2p inside"?
                
+[23:42]  heh 
                
+[23:42]  I, too, pee...
                
+[23:42]  dm> on a calvin sticker! 
                
+[23:42]  "i2p ... somewhere"
                
+[23:42]  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]  dm: yeah, make it a "Concentration" style chrade logo-gram.
                
+[23:43]  <eye> 2 and a pee-ing penis.
                
+[23:44]  Let's set a date.
                
+[23:44]  heh, yeah, and you'll have your mother click on that icon? 
                
+[23:44]  March 1st.
                
+[23:44]  grab it, in fact :)
                
+[23:44]  My mother disapproves of encryption :)
                
+[23:44] *** UserX (~User@anon.iip) has joined channel #iip-dev
                
+[23:44]  Slashdot article! No matter how far (or not) jrand0m has gotten!
                
+[23:44]  Let's pile on the pressure.
                
+[23:44]  nooooooo.
                
+[23:44]  not yet!
                
+[23:45]  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]  i said march 1st.
                
+[23:45]  the appropriate time to promote is when we have a cool shiny thing to wave at them.
                
+[23:45]  please, no slashdot till the network is ready for the onslaught.
                
+[23:45]  right 
                
+[23:45]  I'm good, what can I say.
                
+[23:45]  I call launch date April 4th.
                
+[23:45]  04/04/04 ;)
                
+[23:45]  no PR until AFTER 1.0 comes out. 
                
+[23:45]  Mojo was almost destroyed by /.
                
+[23:46]  no, none of this rational thinking. March 1st, end of story.
                
+[23:46]  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]  no, don't do that. malda doesn't give a shit, and he'll post THAT :)
                
+[23:46]  heh 
                
+[23:47]  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]  anyway, as things progress, http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap will be updated 
                
+[23:48]  time to pack.
                
+[23:49]  (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]  yeah, we're about the 2hour mark. 
                
+[23:49]  time to... 
                
+[23:49] * jrand0m *baf*'s the meeting closed.
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/68.log b/i2p2www/meetings/68.log
new file mode 100644
index 00000000..74b73af0
--- /dev/null
+++ b/i2p2www/meetings/68.log
@@ -0,0 +1,281 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 68{% endblock %}
+{% block content %}
                Tuesday, December 9, 2003 22:00:00 CET
                
+
                
+[22:02]  0) welcome to $num 
                
+[22:02]  1) iip status 
                
+[22:02]  2) kademlia stuff + idn 
                
+[22:02]  3) peer profiling stuff 
                
+[22:02]  4) i2p services  
                
+[22:02]  5) stuff 
                
+[22:02]  0) welcome  
                
+[22:02]  hi 
                
+[22:03]  this is meeting 67 or 68...  
                
+[22:03]  1) iip status 
                
+[22:03]  I dunno.  anyone know what the situation has been as of late? 
                
+[22:04]  the iip devs aren't here, so... dunno. 
                
+[22:04]  [ping] 
                
+[22:04]  (last week I typed for probably 10 minutes before my client pinged me out...) 
                
+[22:05]  (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]  'lo Nostradumbass 
                
+[22:06]  hi :)
                
+[22:06]  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]  how's i2p coming?
                
+[22:06]  sorry?
                
+[22:06]  good lead in ;) 
                
+[22:07]  agenda item 3) i2p 0.2.3 status :) 
                
+[22:07] *** nerox (~nerox@anon.iip) has joined channel #iip-dev
                
+[22:07]  there's been a lot of progress, even though I'm offline.  commited a truckload of code a few hours ago 
                
+[22:07]  that includes an implementation of the kademlia netDb 
                
+[22:08]  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]  there have been a few more variations on the kademlia proto though to make things more relevent for i2p 
                
+[22:09]  we will always have a very, very, /very/ sparse kademlia tree. 
                
+[22:09]  2^256 possible slots, and 1-10 values per peer in the network. 
                
+[22:09]  so, thinking insanely overzealous, we still wont be using jack shit, and everything will be in the furthest out kbucket 
                
+[22:10]  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]  idn, however, is dead in the water. 
                
+[22:11]  the idea that i2p's netDb code could run off the same code as a publishing DHT was a silly little idea 
                
+[22:11]  and has been promptly abandonded. 
                
+[22:11]  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]  but part of the 0.2.3 changes include a dramatic revamp of how we choose peers and organize router stats 
                
+[22:12]  heya tusko 
                
+[22:12]  that brings us to agenda item 3) peer profiling 
                
+[22:12]  I've been pretty silly...and finally did some of the math 
                
+[22:13]  the stats being gathered now are immense. 
                
+[22:13]  about 6000 data points /per peer/ 
                
+[22:13]  what is peer profiling?
                
+[22:13]  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]  ah
                
+[22:13]  (aka fast routers, reliable routers, etc) 
                
+[22:13]  the process that eats up my memory :)
                
+[22:14]  heh actually that part isn't toooo bad 
                
+[22:14]  though 6000 data points won't scale. 
                
+[22:14]  1000 routers @ 6000 data points each @ 4 bytes / data point = 24Mb 
                
+[22:15]  though keeping detailed stats on a few hundred peers is probably fine, even as the net grows beyond that 
                
+[22:15]  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]  we could probably get away in the long term with just keeping track of a hundred or so peers. 
                
+[22:16]  but, for now, I'm going to say fuckit. 
                
+[22:16]  keep stats on all peers 
                
+[22:16]  ping
                
+[22:16]  p0ng 
                
+[22:17]  will it try to learn about all peers?
                
+[22:17]  right now, yes 
                
+[22:17]  oh wait, your last lines covered that
                
+[22:17]  we also have some code for coallescing and running calculations on the peer profiles 
                
+[22:18]  so one of those calculators will determine what peers to drop 
                
+[22:18]  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]  (you'll notice lots of 0s :) 
                
+[22:19]  I've written up a rough manifesto for peer selection and profiling, but need to get that onto the wiki 
                
+[22:20]  but thats all 0.3 stuff, really.  0.2.3 just uses a little of it 
                
+[22:21]  ok, thats it for the peer profiling.  lots more later, just giving a lil view into whats up 
                
+[22:21]  (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]  ok, 4) i2p services 
                
+[22:23]  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]  there's also duck's jabber server, which works fairly easily with the instructions posted to tc's board 
                
+[22:24]  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]  the squid proxy is generally offline, since I'm offline too much to babysit my kaffe routers :/ 
                
+[22:25]  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]  what services would be cool to show up next? 
                
+[22:25]  I did try to run an ircd over i2ptunnel
                
+[22:25]  but before it got the full MOTD after logging in, I got ping timeouted already
                
+[22:26]  d'oh 
                
+[22:26]  and that was on the same router
                
+[22:26]  so in the wild performance will be even worse
                
+[22:26]  on the local router it pinged out?! 
                
+[22:26]  local router should never ping anything out 
                
+[22:26]  oh, except for that race bug 
                
+[22:26]  (which is probably what it was, since it was local and the race is faster there) 
                
+[22:26]  irc client pinged out for not responding in time
                
+[22:27]  I'll retry with 0.2.3
                
+[22:27]  word 
                
+[22:27]  though jabber is nice for now
                
+[22:27]  totally 
                
+[22:27]  and long term, irc is not the way to go 
                
+[22:27]  tc, jrandom and me are there to chat with!
                
+[22:27]  hehe :) 
                
+[22:28]  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]  (aka iip 2.0) 
                
+[22:28]  now would be a nice time for userx to come back into the fold ;) 
                
+[22:29] * jrand0m stops holding breath
                
+[22:29]  an nntp server would /also/ really really rule. 
                
+[22:29]  I'll try that tomorrow
                
+[22:29]  r0x0r 
                
+[22:30]  jabber is really nice to run other things over
                
+[22:30]  check out the jabber rpc specs
                
+[22:30]  (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/
                
+[22:30]  other services?
                
+[22:30]  thats interesting - doing jabber as a naming service, essentially 
                
+[22:31]  you mean:
                
+[22:31]  there will always be more services to add - with mail (usenet), chat (jabber) and publishing/browsing (eepsites), there's good coverage 
                
+[22:31]  name server has a jabber client through which you can register names (provided token)
                
+[22:31]  also use it to query?
                
+[22:31]  naw 
                
+[22:32]  jabber's registry being the naming service 
                
+[22:32]  ok
                
+[22:32]  its centralized but it works 
                
+[22:32]  just like hosts.txt :) 
                
+[22:33]  are there mail solutions that are better suited for there environments than smtp and pop/imap ?
                
+[22:33]  thats a really good question 
                
+[22:33]  cause I dont think that it will just work when you hook up mail servers
                
+[22:34]  yeah, it'd probably need either a gateway (ala freemail) or the naming service doing some interesting tap dancing 
                
+[22:34]  or it reverts back to centralized single POP3/IMAP server with everyone on the same server 
                
+[22:35]  I spoke with aum (author of freemail) yesterday
                
+[22:35]  he was talking about reimplementing fred in python
                
+[22:35]  lol nice 
                
+[22:35] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev
                
+[22:35]  so I did suggest him to work on the python routers for i2p instead
                
+[22:35]  ooh that would TOTALLY rule! 
                
+[22:35]  then he got totally upset about the pdf documents
                
+[22:36]  hey, if he wants the openOffice originals, or even a txt export I'll export 
                
+[22:36]  and I lost my patience and told him that you would also have the m$word docs if he did ask nicely
                
+[22:36]  well, you were a fuckhead for not doing a html export or something
                
+[22:36]  naw, I tried that ;) 
                
+[22:36]  I lost my patience and told him to talk to you
                
+[22:36]  the openOffice html export SUCKS 
                
+[22:37]  hm
                
+[22:37]  true jr
                
+[22:37]  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]  wiki has most info though
                
+[22:37]  exactly 
                
+[22:37]  i tried using that for that kevin mitnick book. it was worse than ms office
                
+[22:37]  oh well
                
+[22:37]  zactly. 
                
+[22:37]  he might appear here once
                
+[22:37]  that'd be awesome 
                
+[22:38]  but maybe it is better with his attitude to join the freenet gang
                
+[22:38]  ...
                
+[22:38]  well, effort on freenet is always a good thing 
                
+[22:38] * duck goes back to beeing friendly
                
+[22:38]  :) 
                
+[22:38]  aums work rocks
                
+[22:38]  hopefully he'll rock on i2p
                
+[22:39]  yeah whenever someone talked about searching on freenet, I always just said "well just do a McNabb" 
                
+[22:39]  we need the help, certainly 
                
+[22:39]  which brings me to the following question:
                
+[22:39]  are the changes to I2P that you do specced?
                
+[22:39]  or is the java source the documentation for the latest info
                
+[22:40]  there are notes taken in my palmpilot, filesystem, and notebook, but unfortunately I haven't updated the openoffice docs in a while 
                
+[22:40]  feb is doc-month for jrandom. 
                
+[22:40]  (and qa, and bugfixing) 
                
+[22:41]  ((and benders ;)) 
                
+[22:41]  the specs are still pretty much correct, there are just more details. 
                
+[22:41]  awesome
                
+[22:41]  but the datastructures have had more changes 
                
+[22:42]  ok, anything else for services?   
                
+[22:43]  ok, 5) stuff 
                
+[22:43]  hi 
                
+[22:43]  hi!
                
+[22:43]  how's tricks? 
                
+[22:43]  [any questions / thoughts / issues / etc go here] 
                
+[22:43]  the base64 tricks should be added to the i2ptricks pages
                
+[22:44]  ooh good point 
                
+[22:44]  might be some other tricks too that I dont know yet
                
+[22:44]  will grep the sources for 'main'
                
+[22:44]  I feel guilty for not having the installer let someoene automatically fetch hosts.txt and reseed 
                
+[22:44]  lol 
                
+[22:44]  there are lots and lots of main() methods, but they're mostly test functions 
                
+[22:45]  oh! 
                
+[22:45]  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]  hi
                
+[22:45]  the db messages changed :) 
                
+[22:45]  hi joda 
                
+[22:45]  sorry, if I interrupt something
                
+[22:45]  I got a bit upset that I couldnt get cvs to work
                
+[22:45]  but then I did remember that this isnt freenet
                
+[22:45]  I was just wondering what happend to "anonymail" ?
                
+[22:46]  so you dont need latest cvs to be able to use it
                
+[22:46]  joda> the user who runs it doesn't seem to be online at the moment.  should be back soon 
                
+[22:46]  hehe duck - did it fail for you today after I committed, or do you mean from before today? 
                
+[22:46]  last week somewhere
                
+[22:46]  jrand> thx :)
                
+[22:46]  cu :)
                
+[22:46]  ah 'k duck 
                
+[22:46]  l8r joda 
                
+[22:47]  yeah, I only endorse running the released code 
                
+[22:47]  will 0.2.3 put the version files in a directory? :)
                
+[22:47]  0.2.3 gets rid of the version files :) 
                
+[22:47]  (lots and lots and lots of changes) 
                
+[22:47]  but that means 0.2.3 (and beyond) will require g enerally correct clocks 
                
+[22:48]  (current Router.CLOCK_FUDGE_FACTOR = 30 minutes) 
                
+[22:48]  what will the fudge facter be for 0.2.3?
                
+[22:48]  probably the same 
                
+[22:49] *** joda has left #iip-dev
                
+[22:49]  oh, current = your code
                
+[22:49]  that time will be used to expire db entries 
                
+[22:49]  k
                
+[22:49]  ah, right, yeah :) 
                
+[22:49]  (in 0.2.2 that clock_fudge_factor is spread out throughout half a dozen files) 
                
+[22:49]  maybe the installer could be a bit more userfriendly
                
+[22:49]  as in less questions
                
+[22:49] *** Signoff: nickthief66282 (Excess Flood)
                
+[22:50]  default phttp urls included, no bandwidth limiting etc
                
+[22:50]  I guess we could autoguess random ports too 
                
+[22:50]  you're right 
                
+[22:50]  want commit privs?  :) 
                
+[22:50] *** Signoff: nerox (EOF From client)
                
+[22:50]  (if not I can update it for 0.2.3) 
                
+[22:51]  an argument against it can be that users will take settings too easily for granted
                
+[22:51]  and everybody uses the same phttp relay
                
+[22:51] *** nickthief24373 (~chatzilla@anon.iip) has joined channel #iip-dev
                
+[22:51]  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]  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]  (though thats because i know what all the text says and didn't read it...) 
                
+[22:52]  I dont like the long keys
                
+[22:53]  especially not if you have to copy&paste them
                
+[22:53]  better use them as file
                
+[22:53]  hmm? 
                
+[22:53]  but distributing the binary files are a pain
                
+[22:53]  so you have to do the base64 trick..
                
+[22:53]  could the i2ptunnel read base64 destination keys too?
                
+[22:53]  from a file that is
                
+[22:53]  I was just typing that ;) 
                
+[22:53]  yeah, that wouldnt be much work 
                
+[22:54]  perhaps even 1 line 
                
+[22:54]  also, what about armouring?
                
+[22:54]  with a header&footer
                
+[22:54]  like pgp etc
                
+[22:55]  true, it would be useful to have that sort of validation 
                
+[22:55]  ofcourse that is a gadget
                
+[22:55]  but it could be helpful for those who want to use the tunnel
                
+[22:55]  though the Destination structure itself is pretty picky 
                
+[22:55]  but you're right, a raw base64 isn't the most intuitive or safe thing to pass around 
                
+[22:56]  we need a bugzilla 
                
+[22:56]  so things like this can get posted as todo 
                
+[22:56]  i'd move off my palm's todo list for that 
                
+[22:56]  bugzilla has nazi registration requirements
                
+[22:56]  with emails etc..
                
+[22:56]  true 
                
+[22:57]  but better as nothing
                
+[22:57]  other bugtrackers all have their shortcomings
                
+[22:57]  yeah, every company i've worked at has pretty much ended building their own 
                
+[22:58]  we'll see.  we need a bugtracker by the time we start doing full on qa (once 0.3 comes out) 
                
+[22:58]  so we've got a few weeks ;) 
                
+[22:58]  but if someone did some research and found a really nice one, that'd be great 
                
+[22:59]  [not you specifically duck, anyone who's reading these meeting logs at home ;)] 
                
+[22:59]  so far phpBugTrackers has been okay for me
                
+[22:59]  hmm haven't used that 
                
+[22:59]  yes, I am not talking to jrandom either
                
+[22:59]  lol 
                
+[22:59]  but to the group of I2P code developers :)
                
+[22:59] * jrand0m is actually 12 people acting under a single nym
                
+[23:00]  ok, 1 hour, on the dot 
                
+[23:00]  anyone else have anything before I get the *baf*er out? 
                
+[23:01] * duck demands 1 more minute
                
+[23:01]  since we did start on 21:02
                
+[23:01]  yeah yeah 
                
+[23:01]  la la la 
                
+[23:01]  what should i have for dinner? 
                
+[23:01]  there's a nice falafel place next door... 
                
+[23:01]  had gnocci for lunch too 
                
+[23:01]  hmm... 
                
+[23:01]  maybe a liquid dinner 
                
+[23:02]  soup?
                
+[23:02]  ooOooo whiskey soup! 
                
+[23:02] * jrand0m *baf*'s the meeting closed on that note
                
+
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/69.log b/i2p2www/meetings/69.log
new file mode 100644
index 00000000..1c9c109f
--- /dev/null
+++ b/i2p2www/meetings/69.log
@@ -0,0 +1,250 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 69{% endblock %}
+{% block content %}
                Tuesday, December 16, 2003 22:00:00 CET
                
+
                
+[22:04]  0) hi 
                
+[22:04]  1) iip 
                
+[22:04]  2) 0.2.3 & 0.2.3.1 
                
+[22:04]  3) hi 
                
+[22:04]  0) hi 
                
+[22:04]  welcome to the ... something'th meeting 
                
+[22:05]  (68?  69?) 
                
+[22:05]  damm its 1pm here
                
+[22:05]  GMT-8? 
                
+[22:05]  69
                
+[22:05]  h0t. 
                
+[22:06]  ok, 1) iip 
                
+[22:06] *** Signoff: tusko (EOF From client)
                
+[22:06] * MrEcho compiles a kernel for the meeting
                
+[22:06]  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]  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]  no info from nop
                
+[22:07]  this morning I was told that I could start Trent again
                
+[22:07]  (I did do so already last night)
                
+[22:07]  wikked 
                
+[22:07]  gracias 
                
+[22:07]  so that indicates that nop believes that IIP is more stable again
                
+[22:07]  if that is worth anything...
                
+[22:07]  *cough*
                
+[22:07]  ok cool 
                
+[22:08]  [woot roommate just handed me a glass of wine for the meeting] 
                
+[22:08]  lol
                
+[22:08]  ok, since nop is online and won't come to hte meeting, we'll have to save the lynch mob for later 
                
+[22:09]  2) 0.2.3 & 0.2.3.1 
                
+[22:09]  what specific question do you want to ask him?
                
+[22:09]  when is the meeting
                
+[22:09]  specific question> when will he make an official announcement describing the past problems and how the future ones will be addressed? 
                
+[22:09]  the meeting is now 
                
+[22:10]  (aka, at what point should we explore non-iip means of communication) 
                
+[22:10]  if I get an answer I'll let you know.
                
+[22:10]  thanks 
                
+[22:11]  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]  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]  there is also a new persistent sessionKeyManager that will make it so restarts won't totally b0rk a router for 15 minutes 
                
+[22:12]  what about client connect times to routers?
                
+[22:12]  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]  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]  ok cool
                
+[22:13]  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]  its hard to work on the dns with that damm bug .. i have to restrt the dns server alot
                
+[22:14]  MrEcho> with local only routers i have not been able to reproduce the bugs - does it work for you w/ local only? 
                
+[22:15]  no
                
+[22:15]  could you send me debug logs for that? 
                
+[22:15]  already deleted
                
+[22:16]  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]  its doing the samething as before .. client gets msg that its sent .. but never makes it to the client
                
+[22:16]  to the other client
                
+[22:17]  ya .. ill see what i can do
                
+[22:17]  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]  gracias 
                
+[22:17]  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]  shine on you crazy diamond
                
+[22:18]  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]  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]  right now i've got to battle with kaffe & jetty for updates on i2p.dnsalias.net 
                
+[22:20]  what species?
                
+[22:20] * MrEcho already is
                
+[22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev
                
+[22:20]  y'all already are insane (and very helpful) volunteers :) 
                
+[22:20]  thank you!
                
+[22:20]  :)
                
+[22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev
                
+[22:21]  hey if it aint tc 
                
+[22:21] * MrEcho wips TC .. your late
                
+[22:21]  hey
                
+[22:21]  we back up and running?
                
+[22:21]  ya i can type todya...
                
+[22:22]  iip seems up... 
                
+[22:22]  yay
                
+[22:22]  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]  what was the cause?
                
+[22:23]  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]  FireRabbit, how much memmory do you have?
                
+[22:24]  that computer has 128 i believe
                
+[22:24]  you think it could be the paging file?
                
+[22:24]  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]  because i have 512 and i2p gave me an 'out of memmory' error last night
                
+[22:24]  really?  shite 
                
+[22:24]  oh, intresting
                
+[22:25]  wow
                
+[22:25]  yeah, thats #3 on the list of bugs left to crack (though thats not a 0.2.3.1 showstopper) 
                
+[22:25]  OOMs don't use all 512 
                
+[22:25]  but it seems to be running fine now
                
+[22:25]  they only use what java's given (e.g. 64M) 
                
+[22:26]  yes
                
+[22:26]  Memory: In use: 8187KB
                
+[22:26]  word 
                
+[22:26]  that is not much!
                
+[22:26]  yet
                
+[22:26]  Memory: In use: 8908KB Free: 4088KB 
                
+[22:27]  right, there is something growing in there, i hope to have it tracked down by 0.3  
                
+[22:27]  cool, free means it used to use 12.9M, now it only uses 8.9 
                
+[22:27]  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]  yeah, kaffe does that for me tc 
                
+[22:28]  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]  sigh
                
+[22:28]  ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) 
                
+[22:28]  d'oh FireRabbit 
                
+[22:28]  this thing is never going to gte done
                
+[22:28]  yah, and memory is no biggy for the most part
                
+[22:28]  heh, no project goes as easily as one hopes 
                
+[22:28]  nope
                
+[22:28]  jrand0m: the maillist triggers Yahoo! spam protection
                
+[22:28]  just a heads up
                
+[22:28]  really protocol? 
                
+[22:29]  yeah
                
+[22:29]  perhaps thats what triggered the spam guard when i cc'ed iip-dev 
                
+[22:29] * jrand0m will write my isp
                
+[22:29]  (or perhaps its the .dnsalias.net thing) 
                
+[22:30]  i didn't get any mailings so far, and i emptied my bulk mail b4 i could check
                
+[22:30]  or the jrandom nicknam
                
+[22:30]  lol duck 
                
+[22:30]  :)
                
+[22:30]  that'd be awesome if my nick was filtered :) 
                
+[22:30]  hehe
                
+[22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev
                
+[22:30]  wb wiht 
                
+[22:30]  speaking of which, I suppose I should inject 3.1) apps :) 
                
+[22:31]  hey MrEcho, how goes the battle? 
                
+[22:31]  jrand0m: Hello.
                
+[22:31]  the day somone writes a autodetect program for the linux compile config
                
+[22:31]  well its on its way
                
+[22:31]  knoppix uses some autodetect thing, isnt it?
                
+[22:31]  ./configure ; make ; make check ; make install ; reboot 
                
+[22:31]  </offtopic>
                
+[22:31]  ive pritty much maped out how i want to do everything
                
+[22:31]  word 
                
+[22:32]  do you have a clear view on how i2ptunnel could be updated to make use of what you're doing MrEcho? 
                
+[22:32]  i think knoppix uses hotplug
                
+[22:32]  0.1 wont be/might be locked down .. dont know yet
                
+[22:32]  coo' 
                
+[22:33]  oh jrand0m, i have a question about the cvs
                
+[22:33]  que tal? 
                
+[22:33]  for dns querys im going to have a server port on the Client and RS side for Names querys
                
+[22:33]  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]  and im going to build a lib for any app to use
                
+[22:33]  FireRabbit> src, dest 
                
+[22:34]  humm
                
+[22:34]  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]  definitely tc 
                
+[22:34]  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]  im just wondering how to connect to it
                
+[22:34]  TC: you want (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/
                
+[22:34]  easiest CVS client for windows that I know
                
+[22:35] * MrEcho uses the dos ver :)
                
+[22:35]  duck: for windows != win9x ;)
                
+[22:35] * FireRabbit uses the cvs command line port
                
+[22:35]  mihi: I did test it with win9x
                
+[22:35]  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]  ok, so i use that client and set up the proxy?
                
+[22:35]  no, ive never used cvs before
                
+[22:35]  ok, i'll walk you through the setup after the meeting 
                
+[22:36]  sure, thanks
                
+[22:36]  about cvs-ing through the tunnel:
                
+[22:36]  wouldnt the double messages be a big problem?
                
+[22:36] *** Signoff: wiht (Ping timeout)
                
+[22:37]  especially for commits
                
+[22:37]  yes duck, but I haven't run into that problem (cvs messages are typically small) 
                
+[22:37]  >64k messages (e.g. the specs .pdf or .sxw) should for now be done through the normal internet 
                
+[22:38]  jabber msges get also duplicated quite often
                
+[22:38]  you're right though, in that its not a rock solid solution for cvs yet 
                
+[22:38]  even though they are XML, they are not that big
                
+[22:40]  right, lost acks are one of the bitches of the current lost i2psessionimpl2 bugs :/ 
                
+[22:40]  k
                
+[22:41]  (that was a partly lost ack)
                
+[22:41]  (with the network this size, there should be no resends ever, unless that the peer is offline) 
                
+[22:42]  hmm ok, any other i2p stuff? 
                
+[22:42]  jrand0m: how about adding some kinda sequence number into the i2p packets?
                
+[22:43]  i2ptunnel packets? 
                
+[22:43]  this would help with the doubling things.
                
+[22:43]  no, i2pnp packets
                
+[22:43]  okay, one could do it on i2ptunnel level as well.
                
+[22:43]  so jrand0m did you get your conncetion back or are you still at a cafe?
                
+[22:43]  just if you get twice the same number, disregard the second one.
                
+[22:44]  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]  right, currently we keep a history of the last 1000 msgIds to drop dups 
                
+[22:44]  okay, if anyone volunteers to write a good tcp impl for i2p, that would be better ;)
                
+[22:44]  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]  win a 1 hour private chat session with UserX!
                
+[22:45]  lol 
                
+[22:45]  lol
                
+[22:46]  ok, any other i2p things, or iip things, or anything else for this, the 69th iip-dev meeting? 
                
+[22:46]  (other than userx pinup girl comments) 
                
+[22:47]  any other apps that duck inc. should run?
                
+[22:47]  bluebeep! 
                
+[22:47]  1. jrand0m did you fix your connection issues? 2. what do you think of my new eepsite?
                
+[22:47]  bluebeep?
                
+[22:47]  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]  TC: I like the new design
                
+[22:48]  hmm, i should change the board as well to cut down on the load time
                
+[22:48]  only think you should try to disable the email function in the phpboard, now you get an error each time
                
+[22:48]  thanks duck
                
+[22:48]  dropping images would be a plus 
                
+[22:49]  good idea
                
+[22:49]  (bluebeep is an old wardialer) 
                
+[22:49]  ya
                
+[22:49]  (and all around fun toy) 
                
+[22:49]  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]  lol
                
+[22:50] * TC built a blackbox once
                
+[22:50]  w3wt 
                
+[22:50]  is the meeting already over?
                
+[22:50]  last Q:
                
+[22:50] *** protocol is now known as proto_afk
                
+[22:51]  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]  just so that we understand what routerConsole.html dumps
                
+[22:51]  im getting pissed
                
+[22:51]  ok, the JobQueue stats I assume you mean? 
                
+[22:52] * duck guesses that it is all obvious probably
                
+[22:52]  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]  (those are the jobs that usually take the longest, and when the pending side of things gets large, everything suffers) 
                
+[22:53]  (actually, i better read the logs first)
                
+[22:53]  gotcha
                
+[22:53]  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]  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]  (we resend randomly if it isn't local) 
                
+[22:54]  (no more than once every 5 minutes though) 
                
+[22:55]  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]  thanks
                
+[22:57]  any other comments / questions / concerns / frisbees? 
                
+[22:59]  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/i2p2www/meetings/7.log b/i2p2www/meetings/7.log
new file mode 100644
index 00000000..11767d08
--- /dev/null
+++ b/i2p2www/meetings/7.log
@@ -0,0 +1,458 @@
+{% 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/i2p2www/meetings/70.log b/i2p2www/meetings/70.log
new file mode 100644
index 00000000..b1dda7c8
--- /dev/null
+++ b/i2p2www/meetings/70.log
@@ -0,0 +1,164 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 70{% endblock %}
+{% block content %}
                Tuesday, December 23, 2003 22:00:00 CET
                
+
                
+[22:01]  0) hi 
                
+[22:01]  1) administravia 
                
+[22:01]  2) dev status 
                
+[22:02]  3) services on i2p 
                
+[22:02]  4) app status [ns, im, i2ptunnel, ...] 
                
+[22:02]  5) ??? 
                
+[22:02]  wow, i picked a good time
                
+[22:02]  0) hi 
                
+[22:02]  yes you did thecrypto :) 
                
+[22:02]  hi 
                
+[22:02]  welcome to meeting 70 
                
+[22:02]  woot
                
+[22:03]  1) administravia 
                
+[22:03]  w00t!
                
+[22:03]  mailing list, get on it for announcements / discussion / etc: (Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/ 
                
+[22:04]  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]  i think thats it for administravia 
                
+[22:05]  (note that i'm just talking i2p stuff here, i don't see any iip things on the agenda) 
                
+[22:05]  2) dev status 
                
+[22:05]  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]  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]  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]  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]  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]  y'all rule, I really appreciate the help 
                
+[22:09] * thecrypto pulls out the "APPLAUSE" sign
                
+[22:09]  ;) 
                
+[22:09]  the # of routers have also been increasing... on avg we're at around 9-12 
                
+[22:09]  (up from 3-5 a week ago, and 6-8 in 0.2.2 times) 
                
+[22:10]  the next release will improve the reliability dramatically 
                
+[22:10]  (aka it won't get out the door until it does) 
                
+[22:10]  ok, 3) services on i2p 
                
+[22:11]  fillament started hosting his flog on i2p :) 
                
+[22:12]  and I've got another trick up my sleeve =)
                
+[22:12]  ooOOoo :) 
                
+[22:12]  tw
                
+[22:12]  hm
                
+[22:12]  hello.
                
+[22:12]  Does it work yet?
                
+[22:12]  duck started a new irc server on i2p with dcc disabled (for security reasons) plus some ident-ish features 
                
+[22:13]  lol
                
+[22:13]  luckypunk> people with 350Mhz machines will need to wait until 0.3 is out before being able to use it effectively ;) 
                
+[22:13]  yes, but is i2p reliable enough for that?
                
+[22:13]  (but subscribe to the i2p mailing list so you can get announcements) 
                
+[22:13]  i overclocked to 377
                
+[22:13]  does that help?
                
+[22:13]  lol
                
+[22:13]  i was chatting on that irc server the other day, until my irc client b0rked 
                
+[22:14]  but yes, things are a bit unreliable at the moment while the tunnel management subsystem is rebuilt 
                
+[22:14]  well, im happy my computer didn't molassify overnight again.
                
+[22:15]  any other new services i've missed?   
                
+[22:15]  well, when .3 comes out...t here'll be a yahooish service.
                
+[22:15]  ;)
                
+[22:15]  cool 
                
+[22:15]  i should run somthing else
                
+[22:16]  whats a service we need that doesnt require messing with apache?
                
+[22:16]  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]  you could run a telnet based games server (e.g. adventure, etc) 
                
+[22:16]  lol
                
+[22:16]  hah
                
+[22:16]  MUSH
                
+[22:17]  i'll do that... it's low demand.
                
+[22:17]  and i already had about 300k of tinymush code.
                
+[22:17]  yeah, the whole mush/mud/moo/ style thaang 
                
+[22:17]  heh
                
+[22:17]  what about ultima online?
                
+[22:18]  ooh that's be fun
                
+[22:18]  "Slay FreeNet Databugs!"
                
+[22:18]  TC: =|
                
+[22:18]  we need to get a telnet client then
                
+[22:18]  maybe if we all obtained 6 ghz computers with oc-128 lines. :D
                
+[22:18]  thecrypto> /bin/telnet + i2ptunnel 
                
+[22:18]  ...yeah
                
+[22:18]  i'm sloew
                
+[22:19]  :)
                
+[22:19]  any other low hanging fruit for services?  a mail server (pop3/imap without internet mail) would rule 
                
+[22:19]  (and if it could /receive/ internet email that'd rule too) 
                
+[22:21]  ok, 4) app status 
                
+[22:21]  naming service 
                
+[22:21]  wiht / co was here earlier, but not now 
                
+[22:21]  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]  ok, perhaps we'll get back to that 
                
+[22:23]  hosts.txt has been growing as destinations have come online 
                
+[22:23]  there's a bot on the jabber server that will let you register / fetch entries 
                
+[22:24]  (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]  next up, IM 
                
+[22:24]  hi thecrypto :) 
                
+[22:24]  welcome back 
                
+[22:25]  hi
                
+[22:25]  i2pim is being started from scratch
                
+[22:25]  i need to figure out how this network works but tearing apart ATalk and slowly putting it back together
                
+[22:25]  so it's slowly coming along
                
+[22:25]  word 
                
+[22:25]  i don't know if i can get group chat working
                
+[22:25]  but it's an idea
                
+[22:26]  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]  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]  hehe 
                
+[22:26]  cool 
                
+[22:27]  yeah, starting off with one on one (perhaps with send/receive file) would probably be prudent 
                
+[22:27]  yeah, the only problem would be syncronizing the baton will be difficult
                
+[22:27]  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]  nety
                
+[22:27]  token-ring-chat?
                
+[22:27]  yup, voting systems are a pain.   
                
+[22:28]  right, good ol' 2phaseCommit 
                
+[22:28]  TC: no, basically the IM network has no central presence server
                
+[22:28]  so what i'm thinking about doing is have a virtual server baton
                
+[22:29]  ok, using a bootdisk from now on...
                
+[22:29]  the other option is to do group chat fully distributed: "group" just being "send these messages to peer X, Y, Z" 
                
+[22:29]  d'oh duck 
                
+[22:29]  yeah, but that's network by broadcast
                
+[22:29]  not really 
                
+[22:29]  which is usually the stupidest idea
                
+[22:29]  the messages have to get sent to peer X, Y, Z from someone sometime 
                
+[22:30]  its actually 1 less message than the (temporary) server based model 
                
+[22:30]  yes, but then each person has to keep track of the group
                
+[22:30]  (and the UI can make the group 'pretty') 
                
+[22:30]  and now there has to be messages passed around about what the group is current
                
+[22:30]  right, perhaps a control message stating "I think group A is X, Y, Z" 
                
+[22:31]  instead of the voting protocol 
                
+[22:31]  right, I'm not sure what way is best 
                
+[22:31]  just saying there's an option 
                
+[22:31]  no lo se  
                
+[22:31]  yeah
                
+[22:32]  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]   well, i need code for there to be bugs in first
                
+[22:32]  ;) 
                
+[22:33]  so wait a bit and i'll have something to put on bugzilla
                
+[22:34]  cool, whenever, its trivial to add 
                
+[22:35]  ok, i2ptunnel 
                
+[22:35]  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]  plus there's a thing wrt some browsers b0rking on missing trailing / 
                
+[22:37]  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]  other than that, the things are minor, i2ptunnel is behaving a lot better than the router :) 
                
+[22:38]  ok, any other apps? 
                
+[22:39]  there was some discussion about NAT/SOCKS the last few days on the channel 
                
+[22:39]  a socks enabled proxy that would let people ftp, bittorrent, etc would be really great 
                
+[22:39]  plus there's the discussion aum started on the i2p list wrt file sharing / cdn 
                
+[22:40]  (i swear i didn't tell him to make that post ;) 
                
+[22:41]  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]  ok, thats it for apps 
                
+[22:44]  5) ??? 
                
+[22:44]  hi 
                
+[22:44]  any comments / questions / concerns / etc? 
                
+[22:45]  I think everyone fell asleep ;)
                
+[22:46]  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]  oh, meeting
                
+[22:46]  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]  hehe 
                
+[22:47]  ok, thats about it. 
                
+[22:48] * jrand0m *baf*s the meeting to a close
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/71.log b/i2p2www/meetings/71.log
new file mode 100644
index 00000000..10593a29
--- /dev/null
+++ b/i2p2www/meetings/71.log
@@ -0,0 +1,336 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 71{% endblock %}
+{% block content %}
                Tuesday, December 30, 2003 22:00:00 CET
                
+
                
+ 0) hi
                
+ 1) router status
                
+ 2) i2ptunnel
                
+ 3) im
                
+ 4) 0.3 plans
                
+ 5) time synchronization
                
+ 6) ???
                
+ hello mihi, polo
                
+ hello !
                
+ hi jrandom
                
+ 0) hi
                
+ :)
                
+ hi
                
+ <duck> hi
                
+ 1) router status
                
+ 0.2.3.3 is out, and it seems to be working
                
+ still lots to do, of course
                
+ but this should be the last 0.2 release
                
+ 0.3 is going to add the peer profiling to allow routers to avoid bad routers
                
+ (and 0.3.1 is a revamp of the transports)
                
+ hola Ophite1
                
+ Heya.
                
+ so more overhead for 0.3?
                
+ yes and no
                
+ it will have peer testing, but its going to be more focused
                
+ will we see a speed up with path selection?
                
+ yes
                
+ there are those 'liveliness' calculators, and there will be new latency and throughput calculators added
                
+ plus people will be able to tweak their own preferences for particular peers
                
+ 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
                
+ will there be a clean shutdown? *g*
                
+ thats actually a good question mihi
                
+ i2p is getting to the point where it needs an admin interface.
                
+ the longest Job thats holding up its operation is the GenerateStatusConsoleJob
                
+ which can now take up to 4-6 seconds
                
+ (holding everything else up)
                
+ that needs to go async and on demand.
                
+ but i dont want to write a web listener / etc.
                
+ perhaps the reverse - a servlet that starts the router and communicates with it
                
+ you don't need a full web server. just when you see GET, return your data.
                
+ right
                
+ you're right, that stuff should be in 0.3 as well.
                
+ and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)
                
+ aww c'mon
                
+ then someone can make a nice admin program
                
+ right
                
+ 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
                
+ those were in IDN, not the router itself
                
+ but that might be a good way to go
                
+ its a trivially easy system
                
+ good idea, lets go that way
                
+ (and i can just reuse that code :)
                
+ <duck> this magical filestuff starts to look like plan9
                
+ lol
                
+ but file triggers require polling
                
+ right mihi, reading a directory every 30s aint that bad
                
+ but a ServerSocket#accept is cheaper.
                
+ as it won't eat any time. (provided a good OS)
                
+ okay, file triggers are better than nothing, sure.
                
+ server socket would allow remote admin
                
+ (when appropriate)
                
+ dunno.
                
+ something to be worked out.
                
+ (or if someone wants to jump on it and code... :)
                
+ and server socket could deliver the routerConsole as well.
                
+ right
                
+ ok, 2) i2ptunnel
                
+ :)
                
+ i2ptunnel still rules, and its looking like we want to add a socket based API to control it
                
+ <anon> aum's ic2cp2pc plans are off for now?
                
+ yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel
                
+ I think I may be able to throw on that API in the next few days, so he can get churning on the impl
                
+ just use a socket, make in.readLine() and feed that line to runCommand() ;)
                
+ what does the api give i2p?
                
+ pretty much mihi (except it formats the results and send them back in a standard way)
                
+ with an appropriate "logger" to send the commands back.
                
+ s/commands/results/
                
+ rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's
                
+          encryption needs
                
+ right right
                
+ i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels
                
+ regardless of the JVM
                
+ i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as
                
+          the number of local destinations grows.
                
+ ah
                
+ this is due to the anonymity needs of the network tied to how our encryption works
                
+ for applications who just want to open a tunnel or two to a peer, this new api will RULE
                
+ but for applications that need to talk to lots of other peers, I2CP is the way to go.
                
+ (since that is a single destination, multiplexed by i2cp)
                
+ I suppose its the old TCP vs UDP balance, in a way
                
+ mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?
                
+ hows the work on the ip over i2p, or the vpn stuff going?
                
+ jrandom: someone write a good streaming api, and then lets i2ptunnel use it.
                
+ same for naming server.
                
+ perhaps add some sequence numbers if no one does the things above.
                
+ which will mean an incompatible change.
                
+ incompatible changes aren't bad, we're early in dev
                
+ (if we could increase the size of of the IDs too to two or four bytes per side as well?)
                
+ the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence
                
+          numbers.
                
+ rsk> on hold, until someone has time to run with it?
                
+≡ rsk/#i2p thinks incompatible chages are the best kind
                
+ right mihi
                
+ ID should be 3 byte atm, so why *increase* to 2 bytes?
                
+ mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api
                
+≡ mihi/#i2p too
                
+ leaving i2p = IP, not TCP or UDP
                
+ damnit I wish I had another 14 hours in the day.
                
+ only 14? ;)
                
+ ;)
                
+ aren't the 3 byte ids derived by both sides of the con?  or maybe i'm just confused
                
+ each side has an ID of 3 bytes, hovever, only one must be sent at a time.
                
+ perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.
                
+ ah ok
                
+ see /apps/i2p/i2ptunnel/java/src/protocol.txt
                
+ right right
                
+ btw, who misplaced that file *there*?
                
+≡ jrandom blames eco ;)
                
+ wait, naw, you put 'em there
                
+ didnt you?
                
+ oh wait, no I imported them
                
+≡ jrandom blames self for being stupid.
                
+ (la la la)
                
+ damn.  ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer
                
+          testing / profiling / selection manifesto
                
+ I'll post that in a few days for comment
                
+ (and it'll get my head out of the router.  variety++)
                
+ mihi> anything else on i2ptunnel?
                
+ not that i know
                
+ coo'
                
+ (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)
                
+ ok, thecrypto isn't here, but he's making progress on the IM app.
                
+ (thats agenda item 3)
                
+ 4) 0.3 plans
                
+ 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for
                
+          i2ptunnel
                
+ but, if you couldn't guess, its not going to be released on jan 1
                
+ jan 15 is an outside possibility.  we'll see how things go.
                
+ 0.3.1 isn't a full month of work, so it may not need to get bumped.
                
+ other than that, the roadmap is still pretty much on track and representative of where we're moving
                
+ 5) time synchronization
                
+ a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming
                
+ mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?
                
+ hi brawl
                
+ yep.
                
+∙φ∙ brawl is now known as eco_
                
+ hi guys
                
+ oh heya eco
                
+ you should connect 3 random nodes and remember the diff between the avg time and local time.
                
+ we just discussed the streaming API / tunnel api
                
+ and then hack up your own getTimeMillis that corrects that.
                
+ mihi: No, you shouldn't.
                
+ mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed
                
+ (since avg would skew randomly in between)
                
+ if an attacker creates 1000 nodes, everyone gets screwed anyway...?
                
+ wouldnt that be self corecting?
                
+ mihi: OK, 3.
                
+ no, we should be able to handle that mihi.
                
+ okay, then only use avg, if standard deviation is lower than 1sec or so.
                
+ if everyone has the same time your ok, even if that time is wrong, right?
                
+ rsk> if all 1000 nodes were in sync, but what if they're all random
                
+ only use times that are close enough together. if not, take 3 new nodes.
                
+ 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
                
+ but we need not care of everything (like ping latencies), as ntp does.
                
+ if we did not, mihi, time would slowly creep backwards.
                
+≡ mihi/#i2p thinks that is better than let users set their time individually.
                
+ so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?
                
+ what about that third option -
                
+ i2p has a component that checks with a real NTP server via NTP or SNTP
                
+ if you have only skewed notes in your netDB, you are on that private net as well...
                
+ rather than reimplementing the wheel
                
+ while I partially like that one...
                
+ NTP isn't signed, it's subject to an MITM attack.
                
+ or dns cache poisoning for, say, time.nist.gov
                
+ right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.
                
+ we would definitely not sync of time.nist.gov.
                
+ connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)
                
+ and if an attacker goes after time.nist.gov, everyone everywhere is affected
                
+ heh
                
+ then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.
                
+ so even /more/ code ;)
                
+ but yeah, thats reasonable.
                
+ That's interesting. And if they don't?
                
+ pick another ntp server?
                
+ refuse the peer.
                
+ try other ntp server and another peer.
                
+ until you have a match. then refuse all prev peers.
                
+≡ mihi/#i2p types slower than jrandom :(
                
+ match within a certain threshold, say 1sec?
                
+ 1s would be good.
                
+ accepting peers up to 30s or so (to deal with lag)
                
+ is 1 sec okay on HEAVILY LADEN connections?
                
+ 1s for syncing, 30s for comm.
                
+ I've seen latency on DSL get to 5 seconds when doing evil things to it.
                
+ with tcp or udp?
                
+ but then, in that case, that host might not be the one you want to sync time to anyway ;)
                
+ right
                
+ udp.
                
+ hmm 'k
                
+ you'd have thought it'd get dropped :)
                
+ <duck> I think that the problem is more letting the user know that there is a problem
                
+ duck> that is true.
                
+ <duck> only after walking through big logs they see that their clock is off (if they find it)
                
+ Maybe. Sort of.
                
+ <duck> or that the port is already bound
                
+ an admin interface would be nice.
                
+ <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server
                
+CTCP Cloaking is now [On]
                
+ perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?
                
+ right (stratum)
                
+ <duck> only windows clients are not likely to have that
                
+ <duck> but they are also not likely to be stable
                
+ windows has NTP
                
+ <duck> so who cares
                
+ duck: Windows XP and Windows Server 2003 include NTP.
                
+ a shitload easier than with unix too
                
+ sync'ed by default to time.windows.com iirc.
                
+ with drop down options for others
                
+ It's an essential part of Windows Product Activation.
                
+ can't expire if you don't know the time :)
                
+ heh
                
+ 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...
                
+ mihi: i2p should try especially hard to work in such a situation...
                
+ mihi> awesome!  you can help test out the hidden operation :)
                
+ as an aside, I'm going to be doing some traveling this summer
                
+ i'll likely be offline, without my laptop.
                
+ <duck> sidethought: ntp.duck.i2p :)
                
+ 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?
                
+ but I'm going to make sure I can still be on I2P with just public terminals.
                
+CTCP Cloaking is now [Off]
                
+ no brainer Ophite1.  just work (with docs for geeks)
                
+ duck> bootstrap ;)
                
+ and i2p will /not/ require root.
                
+ That's my point.
                
+ jrandom: would you run a router on a box you didn't have root to?
                
+ so yeah, a mix between option 3 and 4
                
+ option 3.5 sounds cool to me ;)
                
+ Ophite1> i'd run a hundred of them :)
                
+ option 3.1415926...
                
+ (and move on to the next lab, run a hundred more)
                
+ Ooh. Pie. Tasty.;)
                
+ jrandom: I said you didn't have root on. Amateur. :)
                
+ lol
                
+ so thats basically where we're looking.
                
+ until the time stuff is implemented, everyone should use option 1 or 2.
                
+ for option 2, if someone could write up some docs, I'd appreciate it
                
+ that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)
                
+ jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it
                
+          another time blocked...
                
+ mihi: You are the best test we could possibly have.
                
+ Ophite1 > not for test.
                
+ 'k mihi, we'll find a way, and once its ready you'll be able to use it.
                
+ OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.
                
+ I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.
                
+ lol nice
                
+ I appreciate that very, very few people are this ballsy.
                
+ ok, thats it for time synchronization.
                
+ eco_> hi.  any bt stuff you want to talk about?  {or save till next week}
                
+ 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.
                
+ I have a few interesting ideas along that angle I will present at a future date.
                
+ word
                
+ (transport)
                
+ i2p is considered abuse by major ISPs, read your contract
                
+ rsk: running a distributed proxy cache?
                
+ running any 'server'
                
+ rsk: Not unless it relays to SMTP or WWW.
                
+ running services of any time
                
+ right
                
+ rsk: Hehe, I have a solution to that ;)
                
+ jrandom: can give a brief update
                
+ floor is yours :)
                
+ i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p
                
+ first port runs on top of i2ptunnel, directly calling the java classes
                
+ current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting
                
+          is painful
                
+ eta: this weekend
                
+≡ eco_/#i2p realises that this might be considered > 2003
                
+ w00t!
                
+≡ jrandom hacks time.nist.gov
                
+ a "real" port would probably cut the overhead of the tunnels, but that's a next step
                
+ cool
                
+≡ eco_/#i2p gives floor back to mc jrandom
                
+ 'k, I think that was it
                
+ 6) ???
                
+ anyone have anything else?
                
+≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now
                
+ and that sleep has some use for home sapiens, though jrandom seems to prove this false
                
+ ;)
                
+ what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?
                
+ personally, I'm tired of meetings being cut to shreds every week.
                
+ <anon> lilo sucks!
                
+ we might be shutting people out by going here
                
+ we are, I know.
                
+ if we can get an iip<-->here bridge
                
+ <duck> IIP is shutting ppl out each day
                
+ that'd be good.
                
+ right.
                
+ iip is, unfortunately, unusable for a reliable development community.
                
+ <duck> http://banaan.zeelandnet.nl/open/changate.html
                
+ <duck> that is the code where eyeKon etc is based on
                
+ 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
                
+ <duck> theoretically it could connect to 3 servers and mirror each of them
                
+ word duck, perhaps I'll try to get one running on i2p.dnsalias.net
                
+ ping flood from hell ;)
                
+ irc at duck.i2p was pretty good today, beat iip
                
+ agreed
                
+ dropped me a few times though.
                
+ perhaps it'll be more reliable next week
                
+ it's in your hands :-)
                
+ reliability probably won't improve until 0.3, which is ~2 weeks out
                
+ (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)
                
+ then there'll be whatever bugs that introduces :)
                
+ though I should say I was really excited to stream audio from aum last night
                
+ and ardvark was able to stream for 42 minutes without buffering!
                
+ so perhaps we can be reliable enough
                
+ (my local router is phttp only, which is probably a slight cause)
                
+ ok, anyone have anything else?
                
+ <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/i2p2www/meetings/72.log b/i2p2www/meetings/72.log
new file mode 100644
index 00000000..fee4905e
--- /dev/null
+++ b/i2p2www/meetings/72.log
@@ -0,0 +1,659 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 72{% endblock %}
+{% block content %}
                Tuesday, Jan 6, 2004 22:00:00 CET
                
+
                
+[22:02]  agenda:
                
+[22:02]  0) hi
                
+[22:02]  1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html
                
+[22:02]  2) [discussion]
                
+[22:02]  Can I add installer to agenda?
                
+[22:02]  0) hi
                
+[22:02]  oh yes, certainly!
                
+[22:02]  we're trying something new this week
                
+[22:03]  You can put it at the end of the agenda.
                
+[22:03]  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]  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]  such as a new installer
                
+[22:05]  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]  27 users with only one dup!  w0w
                
+[22:07] * dm is now known as dup
                
+[22:07]  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]  jrand0m: where do you know from that there are no more dupes?
                
+[22:07]  heh thanks dm
                
+[22:07]  mihi> I installed keyloggers on everyone's computers (bwhahahaha)
                
+[22:07]  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]  good call wiht
                
+[22:09]  mrecho's new dns is in the works
                
+[22:09]  cool mihi, yeah I was wondering ;)
                
+[22:09]  how is dns coming along? - ah
                
+[22:09]  MrEcho> your post, right?
                
+[22:09]  working on the post
                
+[22:10]  ok, in the meantime, anyone have anything on 1) streaming? or should we jump to 2) I2PTunnel, TunnelManager, and i2pmgr?
                
+[22:10]  good lord... i could spend the rest of my life attempting to figure out these dependecnies.
                
+[22:10]  So let's say DNS/NS as topic 11.
                
+[22:10]  sounds good wiht
                
+[22:10] * duck walks in
                
+[22:11]  ev'nin duck
                
+[22:11]  ad 1, i committed code for i2ptunnel using the streaming api
                
+[22:11]  ah right, awesome mihi :) 
                
+[22:11]  hi duck
                
+[22:11] * twosandals has quit IRC (Leaving)
                
+[22:11]  jrand0m can several sevices use the same key if they are on diffrent ports?
                
+[22:11]  no kaji
                
+[22:11]  btw: why do your ant files always delete the jar before rebuilding it?
                
+[22:11]  mihi> paranoia
                
+[22:12]  stealing me time with debugging, i'd say ;)
                
+[22:12]  kaji> in i2p, a key /is/ a port, essentially
                
+[22:12]  heh
                
+[22:12]  ah
                
+[22:13]  mihi> if you want to update that, as long as it'll build the jar if the class files change thats fine
                
+[22:13]  if the file is newer than all files in it, and could skip it otherwise.
                
+[22:13]  right
                
+[22:13]  and for paranoia it is better to add a <depends> task
                
+[22:13]  agreed
                
+[22:13]  yo yo
                
+[22:13]  'lo FillaMent
                
+[22:14]  ok, 2) i2ptunnel / tunnelmanager / i2pmgr
                
+[22:14] * TC has joined #i2p
                
+[22:15]  i did a little hacking to make the TunnelManager return the job ids when "openclient" or "openserver" commands are called
                
+[22:16]  kickass :)
                
+[22:16]  this way, apps using the TunnelManager know which job to close later, without parsing the "list" output
                
+[22:16]  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]  we'll get that patch in there right after the meeting.  gracias human :)
                
+[22:17]  it involved making I2PTunnel.runCommand return some stuff (currently a Property)
                
+[22:17]  s/Property/Properties/
                
+[22:17]  oh right, there's some things to modify in that before getting it into the code
                
+[22:18]  but mihi would prefer to add some asynchronous callbacks to the Logging clas, as far as i understand...
                
+[22:19]  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]  jrand0m: the idea is: let's I2PTunnel.runCommand() return immediately, and eventually use callbacks to get more info, right?
                
+[22:21]  right
                
+[22:21]  so the tasks fire callbacks whenever there is data to distribute
                
+[22:21] * mihi has joined #i2p
                
+[22:21]  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]  (well, "all" means the TunnelManager and apps parsing the Tunnel manager output)
                
+[22:22]  right, the gui will hang while the command is executed
                
+[22:22]  and entering the next 3 tunnel open commands is blocked while the first is running
                
+[22:23]  mihi: ok, i didn't know about your app... then we need some solution :-)
                
+[22:24]  mihi: asynchronous .runCommand() behaviour would require to revise the TunnelManager
                
+[22:24]  human: when (iyo) should runCommand terminate? when the tunnel is built, when the connection got through?
                
+[22:25]  "destination unreachable" will be known *after* the first connection attempt was made.
                
+[22:25]  the command pattern would have the execute() return only after it was complete.
                
+[22:26]  what does *complete* mean?
                
+[22:26]  (so if we're following the command pattern, runCommand would block until everything required to do that command was complete)
                
+[22:26]  mihi:  eheh, that's the question :-)
                
+[22:26]  complete for "server 1234 privkeys" would be when the server can accept connections on port 1234
                
+[22:26]  mihi: well, for TunnelServer's IMHO it should return after tunnel creation
                
+[22:27]  complete for "client 234 peer" would be complete when a connection to port 234 would successfully reach peer
                
+[22:27]  at least, thats my take
                
+[22:27]  how can you determint the latter?
                
+[22:27]  I really don't feel strongly either way
                
+[22:27]  perhaps a ping?
                
+[22:27] * Sciatica has joined #i2p
                
+[22:28]  and if the peer goes down just after the ping?
                
+[22:28]  imo it is impossible to do network apps without callbacks
                
+[22:28]  right
                
+[22:28]  or lotsa threads, and i prefer callback on threads synchronized to death
                
+[22:29]  perhaps it should only return after its able to /attempt/ to connect?  
                
+[22:29]  or maybe the command pattern isn't the desired pattern
                
+[22:29]  that's what it's doing now. and what result should it return then?
                
+[22:30]  the point is that you want to have a result (different from an int for the connection id)
                
+[22:30]  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]  agreed, me neither.
                
+[22:31]  0!
                
+[22:31]  and genkey should wait? okay, if you think so.
                
+[22:31]  mihi: well, something like a status ("ok" or "error") and error messages...
                
+[22:31]  human: error messages will be "too late" imo
                
+[22:31]  but do what you want...
                
+[22:32]  as long as you make it work with the streaming api afterwards as well...
                
+[22:32]  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]  mihi is wise.
                
+[22:32]  human: some can be communicated immediately (e. g. when the tunnel port is still in use)
                
+[22:32]  human is talking to himself ;)
                
+[22:32]  oops! :-)
                
+[22:35]  maybe we should see what kind of applications are being built upon I2PTunnel
                
+[22:35]  the asynchronous interface is the Right Thing(TM), but it's more complicated to use
                
+[22:35]  I think it would be best if we could keep the same functionality for the current software - including the gui.
                
+[22:35]  maybe I'm jumping in ignorantly, but perhaps a method like one might find many that deal with HTTP: getHeader(String headerName)
                
+[22:35]  smake me as needed
                
+[22:35]  smack
                
+[22:36] * jrand0m smake's FillaMent
                
+[22:36]  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]  but if mihi application needs to monitor the tunnels state, then the asynchronous interface is a Must(TM)
                
+[22:37]  human> java -jar lib/I2PTunnel.jar\n.  We need to support async.
                
+[22:37]  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]  jrand0m: yes, then we must rework the TunnelManager :-)
                
+[22:37]  kaji> i2p 3.0 :)
                
+[22:38]  agreed human, the tunnelmanager implementation was a quick and dirty impl
                
+[22:38]  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]  w00t :)
                
+[22:40]  ok, are we ready for agenda item 3) I2COCP
                
+[22:40]  otherwise, it would be possible to create sync and async methods for I2PTunnel
                
+[22:40]  true
                
+[22:40]  but duplication might be overkill when a little refactoring would serve the purpose
                
+[22:41] * baffled has quit IRC (Leaving)
                
+[22:41]  personal concern about the tunnels: apps not closing them, so your whole tunnelmanager becomes flooded
                
+[22:41]  jrand0m: yes, we should choose the easiest solution between reworking the TunnelManager or adding new APIs to I2PTunnel :-)
                
+[22:42]  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]  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]  mihi> I think the streaming ones will want to replace, since once the streaming api is solid mode=GUARANTEED will go away
                
+[22:43]  (and hence the old ones wont work)
                
+[22:44] * MrEcho 's email sent
                
+[22:46]  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]  ok, I2COCP
                
+[22:47]  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]  That is a somewhat long name, even abbreviated.
                
+[22:48] * jrand0m now calls I2COCP "Wilma"
                
+[22:48]  jrand0m: well, i was going to write the same words :-)
                
+[22:48]  heh cool
                
+[22:49]  ok, jumping on to 4) roadmap
                
+[22:49]  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]  agreed
                
+[22:49]  the intent is that they'd use I2CP
                
+[22:50]  (as all java apps, i2ptunnel and the streaming library included, use that)
                
+[22:50]  jrand0m: yes
                
+[22:50]  I2PDNS "Janessa"
                
+[22:50]  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]  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]  jrand0m: yeah, there should be "TCP" and "UDP"-like protocols for I2P, with complete protocol event reporting, accessible from non-java apps
                
+[22:52]  human, sounds good
                
+[22:52]  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]  word.  that'd be best for now
                
+[22:54]  ok, any comments on the roadmap?  
                
+[22:55]  [nothing to see here, la la]
                
+[22:55]  ok, 5) i2pIM
                
+[22:55]  thecrypto isn't here, so we can just wait for a post to i2p@ with updates :)
                
+[22:55]  We have Jabber now, if I am not mistaken. Do we still need i2pIM?
                
+[22:55]  yes
                
+[22:55]  jabber has a server that gets cleartext.
                
+[22:56]  Oh. Very well, then; I was not aware of this.
                
+[22:56]  thats two strikes (a server, and cleartext)
                
+[22:56]  its a good solution for some things though, certainly
                
+[22:56]  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]  (but once thing at a time)
                
+[22:57]  actually, speaking of the devil, 6) i2psnark :)
                
+[22:57]  jrand0m: i sometimes used jabber with gnupg...
                
+[22:57]  for >2 person chats?
                
+[22:58]  for one on one, I totally agree there are existing solutions
                
+[23:01]  ok, on to a fun one, 7) introducing I.Toopie :)
                
+[23:01]  how would you implement encrypted >2 people chats? a shared private key?
                
+[23:01]  yes human
                
+[23:01]  or through n! shared keys in the group
                
+[23:02]  well, maybe it could be done above the existing jabber protocol...
                
+[23:02]  human: a shared symmetric key sent to all participants
                
+[23:02]  the hard part is dealing with joins & leaves - key rotation /etc
                
+[23:03] * Sciatica has quit IRC (Ping timeout)
                
+[23:03]  its in no way a trivial issue.  its really really really hard.
                
+[23:03] * mihi acks
                
+[23:03] * human agrees
                
+[23:04]  (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]  but thecrypto can best describe his plans
                
+[23:04]  (though its my understanding he's still open to ideas for how to deal with groups)
                
+[23:05] * Sciatica has joined #i2p
                
+[23:06]  ok, moving on :)  [further discussion on i2p@, etc]
                
+[23:06]  What is I.Toopee, though?
                
+[23:06]  the mascot...
                
+[23:06]  I.Toopie is a guy holding a yellow mask in front of his face
                
+[23:06] * lucky shudders.
                
+[23:07]  uh huh.
                
+[23:07]  can i see it?
                
+[23:07]  http://wiki.invisiblenet.net/iip-wiki?I2PLogo
                
+[23:07] * mihi_backup has quit IRC (EOF From client)
                
+[23:07]  i have added java to my compile queue...
                
+[23:07]  but.. lol
                
+[23:07]  i already have 7 things running
                
+[23:07]  it'll be a while.
                
+[23:08]  aw, cute :P
                
+[23:08]  lol
                
+[23:08]  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]  and, yeah, its cute ;)
                
+[23:08]  are some imgs broken or is my browser buggy?
                
+[23:08]  yeah, some are broken
                
+[23:09]  (they were put on temporary hosting sites 3 months ago)
                
+[23:09]  I.Toopie's stick is now all yellow ... 
                
+[23:09]  changed lastnight
                
+[23:09]  it is?
                
+[23:09]  people should UPDATE THE WIKI then 
                
+[23:09]  ;)
                
+[23:09]  hehe
                
+[23:09]  i dont have the pic anymore .. sorry
                
+[23:10]  I see the pictures with Opera, but not with Mozilla somewhy.
                
+[23:10]  you can see http://img.villagephotos.com/p/2003-10/437060/badass.jpg ?
                
+[23:10]  (thats one of the images on that page)
                
+[23:11]  Access Denied (User Account Disabled)
                
+[23:11]  yeah, same here.
                
+[23:11]  i can see it
                
+[23:11]  but yes, DrWoo has done some kickass stuff with I.Toopie
                
+[23:11]  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]  same here MrEcho.   strange.
                
+[23:12]  MrEcho: I am using Mozilla 1.4.
                
+[23:12]  (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]  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]  the latest hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contains the reference for chess.fillament.i2p
                
+[23:14]  you can use any old FICS client or just telnet to that and play away :)
                
+[23:14]  (yay)
                
+[23:15]  is there a goog fics client for windows?
                
+[23:15]  dunno, I ended up using telnet
                
+[23:15]  Does eboard work?
                
+[23:15]  (which had some fairly tough rampup to learn the commands)
                
+[23:15] * ion has joined #i2p
                
+[23:16]  dunno
                
+[23:16] * BpX has joined #i2p
                
+[23:16]  I will try it later.
                
+[23:16]  cool, if you could post up what you find, that'd be great
                
+[23:17]  ok, 9) DHT
                
+[23:17] * wilde has quit IRC (Ping timeout)
                
+[23:17]  we still don't have a dht, but perhaps this is a lead for something we can start to port
                
+[23:18]  (it uses UDP so getting it to use I2CP wouldn't be hard)
                
+[23:18]  dht???
                
+[23:18]  im blanking on that one
                
+[23:18]  MrEcho> see [10] in the email ;)
                
+[23:18]  http://wiki.invisiblenet.net/iip-wiki?DHT
                
+[23:18]  entropy is a good enough temporary solution
                
+[23:18]  agreed
                
+[23:19]  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]  yeah, bamboo is 1.4
                
+[23:20]  afk
                
+[23:20]  thats the glory of i2cp though - the router & tunnels can be gcj'ed, while things that access them can be whatever
                
+[23:21]  it /is/ purely for an app though - not as part of the core
                
+[23:21]  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]  (being able to post uncensorable content anonymously would be a good useful thing)
                
+[23:22]  s/uncensorable/very censorship resistant/
                
+[23:23]  jrand0m: ah, ok - i thought that bamboo was going to replace Kademlia for the NetworkDB :-)
                
+[23:23]  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]  Nightblade> right, but the squid isn't scalable
                
+[23:24]  yeah i think it would be interesting to have a kind of distributed JAP
                
+[23:24]  agreed
                
+[23:24]  so that's also another thing that would be great if people could check into :)
                
+[23:24]  Nightblade: the prob is abuse handling - i won't open my box for any outgoing http
                
+[23:24]  I'm sure some people will though
                
+[23:25]  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]  yeah i think it would have to have some kind of access controls
                
+[23:25]  blacklist or whitelist
                
+[23:25]  right
                
+[23:25]  of domain names
                
+[23:26]  its the "exit policy" system.  though this is a whole project in and of itself
                
+[23:27]  it could ride on the DNS system... i guess
                
+[23:27]  certainly
                
+[23:27]  mihi: What if you limit the bandwidth used? Or is it the websites accessed that could get you in trouble?
                
+[23:27]  at a very later date lol
                
+[23:27]  wiht> many providers explicitly disallow running servers of any kind
                
+[23:28]  verizon fucks with port 21 for sure...
                
+[23:28]  jrand0m: Oh. Yes, that is a problem.
                
+[23:28]  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]  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]  agreed.  though broadcast isn't possible without brute forcing a ~2^2300 keyspace ;)
                
+[23:30]  right mihi, people in oppresive regimes would not be able to safely run outproxies
                
+[23:30]  mihi: What was the lawsuit? I do not remember.
                
+[23:30] * dm has quit IRC (Ping timeout)
                
+[23:30]  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]  right Nightblade
                
+[23:30]  request broadcast i mean
                
+[23:31]  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]  people may want to check out crowds or rewebber to see other projects that worked on this same task
                
+[23:31]  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]  and made that change to the jap software that makes it possible to catch people. which was removed later
                
+[23:32]  Er, I understand why you are concerned.
                
+[23:32]  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]  yeah but didn't the police seize the information anyway?
                
+[23:32]  yes
                
+[23:33]  they did...
                
+[23:33]  but anyway, yes, both a scalable DHT and a scalable web proxy would be Really Good Things to have by 1.0
                
+[23:34]  and they cannot give it backk, can they?
                
+[23:34] * BpX has quit IRC (Ping timeout)
                
+[23:36] * Sciatica has joined #i2p
                
+[23:36]  ok, anything else for point 9? or are we on to 10/11) NS/DNS?
                
+[23:36]  I would like to make a brief comment about the installer after topic 10.
                
+[23:37]  'k perhaps lets hit that now, since NS/DNS might not be uber-brief? ;)
                
+[23:37]  All right. The router has a start script and a stop script.
                
+[23:37]  right
                
+[23:37]  I would like all of the services to be done that way--to have both a start and a stop script.
                
+[23:37]  most of them do
                
+[23:37]  don't they?
                
+[23:38]  oh, not stop scripts
                
+[23:38]  No, just the router.
                
+[23:38]  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]  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]  Let's say I want to start the eep and nntp on bootup. Currently, I can't do that.
                
+[23:39]  right, you'd need to nohup startEepProxy.sh &
                
+[23:39]  All right. By the way, where are these scripts in CVS?
                
+[23:39]  k im back
                
+[23:39] * mihi_away has joined #i2p
                
+[23:39]  wiht> the scripts are in the Install.java (aka hacked)
                
+[23:39]  jrand0m: Thanks./
                
+[23:40]  but good point, we want it to be as simple as possible to start on boot, as well as start on demand
                
+[23:41]  ok, on to 10/11) ns/dns
                
+[23:41]  well check my email
                
+[23:41]  theres a few things i forgot about putting in there
                
+[23:41]  unfortunately your email didn't really go through to the web interface well :/
                
+[23:41]  like "temp" names
                
+[23:41]  ??
                
+[23:42] * Sciatica has quit IRC (Ping timeout)
                
+[23:42] * ion has quit IRC (Ping timeout)
                
+[23:42]  MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html
                
+[23:42]  because of the gif or something
                
+[23:42]  shit .. i singed it
                
+[23:43]  sorry
                
+[23:43]  the mailing list is really intended to be text only.  pgp sigs are fine (others have posted signed things)
                
+[23:43]  whats a good free small antivirus?
                
+[23:43] * ion has joined #i2p
                
+[23:43]  kaji> linux
                
+[23:43] * Sciatica has joined #i2p
                
+[23:43]  LOL.
                
+[23:43]  that runs with my hardware
                
+[23:43]  kaji: Try AVG Antivirus for Windows.
                
+[23:44] * MrEcho_ has joined #i2p
                
+[23:44] * MrEcho has quit IRC (EOF From client)
                
+[23:44]  fuckign iip
                
+[23:44]  MrEcho / (and anyone else interested in the NS/DNS issue)> have you read http://zooko.com/distnames.html ?
                
+[23:44]  j, should i resend the email?
                
+[23:44]  it went through to the list fine, it just didn't get web archived correctly
                
+[23:44]  ya
                
+[23:45]  jrand0m: I did not read it yet.
                
+[23:45]  ill take a look at it later
                
+[23:45] * mrflibble has joined #i2p
                
+[23:45]  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]  thanks J
                
+[23:46]  its gay, it wants an email adress
                
+[23:46]  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]  kaji> email lists usually want an email address, yeah ;)
                
+[23:47]  i mean AVG Antivirus
                
+[23:47]  oh ;)
                
+[23:48]  MrEcho has several good ideas that I did not have in my specification, such as a ban list for bad clients.
                
+[23:49]  not really a ban list
                
+[23:49]  once there are 1000 clients, does that mean that it would take 125 lookups to find a value?
                
+[23:49]  no
                
+[23:49]  Not a list, but banning bad clients is something I did not have.
                
+[23:50]  2-4 clients for checking
                
+[23:50]  so every client will have 250 entries?
                
+[23:50] * mihi_away is now known as mihi_backup
                
+[23:50]  no
                
+[23:50]  With what I have, it would be one lookup, possibly forwarded a couple of times to reach an authoritative server.
                
+[23:50]  clients will only have what they need
                
+[23:51]  it will keep querying other Clients untill they get data that matches for the check
                
+[23:51]  so with 4 peers, it'd do a random search and on average it'd take 125 lookups
                
+[23:51]  (1000/4/2)
                
+[23:51]  or are the peers a DHT?
                
+[23:52]  (with some maintenance protocol?)
                
+[23:52]  or a search tree?
                
+[23:52]  in a way yes
                
+[23:52]  ill have a cut off on client searches, it will just query the MS
                
+[23:53]  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]  if it doesnt find / or get enough data from Clients within a set range it will then just query the MS.
                
+[23:54]  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]  cany u stop typing for a sec
                
+[23:54] * jrand0m stops typing.
                
+[23:55]  its going to work .. it will have scalability, it will have security
                
+[23:56]  the more users the better it will get
                
+[23:56]  so "trust me", 'eh?
                
+[23:56]  do you trust the Internet DNS system?
                
+[23:56]  for some tasks.
                
+[23:57]  for many, no.
                
+[23:57]  (its quite easy for govts / etc to get records changed - court cases order registrars to update all the time)
                
+[23:58]  only other way of doing it is having big ass lists of Names and lots of crypto on every client
                
+[23:58]  and being dynamic .. forget about it
                
+[23:59] * mrflibble has quit IRC (EOF From client)
                
+[23:59]  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]  ok, thats probably about it for point 10/11 (lots of future discussion still left on that, of course)
                
+[00:02]  anyone have any other thoughts, etc?
                
+[00:02]  Yes.
                
+[00:03]  care to share with the class?  :)
                
+[00:03]  I will be rewriting the specification I wrote. I would like to use a local SQL server to store data, not files.
                
+[00:03]  ah cool
                
+[00:03]  (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]  Let MySQL or a similar server manage data storage, and let Java query that server.
                
+[00:04]  huh ? zooko specs?
                
+[00:04]  I think that will be easier to implement.
                
+[00:04]  duck> naw, I'm just pointing people at his old article "Names: Decentralized, Secure, Human-Meaningful: Choose Two"
                
+[00:04]  ah that
                
+[00:04]  wiht: what specification is that (i missed a lot of the meeting)?
                
+[00:04] * MrEcho has joined #i2p
                
+[00:04]  (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]  something longer ;)
                
+[00:05]  *** I2Ping results:
                
+[00:05]  + + +   eco.i2p
                
+[00:05]  + - -   jabber.duck.i2p
                
+[00:05]  - + +   i2pcvs.i2p
                
+[00:05]  - + +   duck.i2p
                
+[00:05]  - + -   jap.eco.i2p
                
+[00:05]  Nightblade> it was posted to iip-dev back in... august?
                
+[00:05]  - + +   irc.duck.i2p
                
+[00:05]  - + +   human.i2p
                
+[00:06]  - - +   nntp.duck.i2p
                
+[00:06]  - - -   tc.i2p
                
+[00:06]  - - -   dyad.i2p
                
+[00:06]  - - -   bozo.i2p
                
+[00:06]  - - -   ogg.aum.i2p
                
+[00:06]  - - -   fcp.entropy.i2p
                
+[00:06]  - - -   http.entropy.i2p
                
+[00:06]  jrandom: oh, before my time.. :)
                
+[00:06]  - - -   www.mail.i2p
                
+[00:06]  - - -   mp3.aum.i2p
                
+[00:06]  - - -   smtp.mail.i2p
                
+[00:06]  Nightblade: I posted it on September 15th.
                
+[00:06]  - - -   pop.mail.i2p
                
+[00:06]  - - -   mp3.tc.i2p
                
+[00:06]  - - -   lp.i2p
                
+[00:06]  - - -   kaji.i2p
                
+[00:06]  - - -   nm.i2p
                
+[00:06]  - - -   squid.i2p
                
+[00:06]  - - -   chess.fillament.i2p
                
+[00:06]  - - -   mesh.firerabbit.i2p
                
+[00:06]  - - -   nightblade.i2p
                
+[00:06]  - - -   aum.i2p
                
+[00:06]  gezz is anyone up and running?
                
+[00:06]  - - -   fillament.i2p
                
+[00:06]  *** Finished.
                
+[00:06]  why are so many hosts down...?
                
+[00:06] * jrand0m isn't running my servers atm
                
+[00:07]  I can connect to myself on both eep and chess
                
+[00:07] * mrflibble has quit IRC (Ping timeout)
                
+[00:07]  oh wait, i2pcvs is up, neat
                
+[00:07]  mihi: mine isn't up because the i2ptunnel crashes for me after a few hours
                
+[00:07]  so my router is broken (or it's usual I2P problems...)
                
+[00:08]  really Nightblade?  please report i2ptunnel crashes (bugzilla would be nice)
                
+[00:08]  it is in the bugzilla
                
+[00:08]  hi
                
+[00:08]  hold..
                
+[00:08]  Nightblade: what JVM?
                
+[00:08]  #39
                
+[00:08]  My router has been running for more than 12 hours now, although it had a problem in registering itself.
                
+[00:09]  java version "1.4.2-p5"
                
+[00:09]  on freebsd...  it could be a jvm problem, i don't know. java support isn't too good on freebsd
                
+[00:09]  you're right Nightblade, my bad
                
+[00:09]  thats the fairly infrequent i2cp bug 
                
+[00:09]  is that consistent for you?
                
+[00:09]  the router is very stable for me, just the i2ptunnel server tunnel gives me problems
                
+[00:09]  yeas it happened several times
                
+[00:10]  i haven't tried it recently though
                
+[00:10] * jrand0m just pulled fillament's eepsite
                
+[00:10]  (first try, just noticed the window was complete)
                
+[00:10]  Yeah,, I just jabbered with duck, wiht's trying to hit chess
                
+[00:10]  ah cool
                
+[00:10]  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]  I just successfully connected to chess server.
                
+[00:10]  yeah?
                
+[00:11]  lol FillaMent
                
+[00:11] * mrflibble has joined #i2p
                
+[00:12]  is it safe to run the cvs version of i2p
                
+[00:12]  /me succesfully fetches human's 1984-2004: twenty years of GNU! :-) 
                
+[00:12]  yes Nightblade
                
+[00:12]  could not get eco...
                
+[00:12]  ok maybe i'll give that a try
                
+[00:12]  with freenet you should always run the latest cvs version!
                
+[00:13]  only then it is bugfree
                
+[00:13]  s/freenet/i2p/
                
+[00:13] * jrand0m pulled eco.i2p
                
+[00:13]  just got duck
                
+[00:13]  "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]  d'oh
                
+[00:13]  well, it worked actually
                
+[00:13]  ardvark could snark something from me
                
+[00:14]  bt precreates the files - were the files actually valid?
                
+[00:14]  but ze did find out the next day
                
+[00:14]  because it was obscured in the logs
                
+[00:14]  what, you mean the logs i2p generates are fairly insane?  nawwwwww
                
+[00:14]  no
                
+[00:14]  the i2psnark output
                
+[00:14]  ah
                
+[00:15]  additionally, I suspect that snark does too much churning (sp?)
                
+[00:15]  the normal bittorrent client seems to be more easy
                
+[00:15]  also the high delays on i2p might cause premature blocks
                
+[00:16] * mrflibble has quit IRC (Ping timeout)
                
+[00:16]  last thing is that we had to restart i2ptunnel a few times :/
                
+[00:16]  agreed
                
+[00:16]  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]  so, yeah, lots of work to do
                
+[00:16]  1. let's accept it to make the TunnelManager work until the new asynchronous architecture will be roxoring
                
+[00:17]  2. your patch plain sucks, fuck off, and fuck the TunnelManager
                
+[00:17]  3. ...
                
+[00:17] * MrEcho_ has joined #i2p
                
+[00:17] * mihi is for 3 ;)
                
+[00:17] * MrEcho has quit IRC (EOF From client)
                
+[00:17]  4. lets see how we can update the tunnel manager to go async?  shouldn't be too hard
                
+[00:17]  the patch is good, but mihi has a point
                
+[00:18]  jrand0m: yes, i agree
                
+[00:18]  we still have 1+ weeks until 0.3, so we've got time until the next full release
                
+[00:18]  jrand0m: but my doubt is: how long will it take to have the async interface to be implemented in the TunnelManager?
                
+[00:18]  tunnelmanager itself was 2 hours, I could add async tonight
                
+[00:19]  (all that needs to happen is an update to the BufferedLogging to accept .set calls)
                
+[00:19]  jrand0m: (with "to have" i also mean "to have it implemented even in I2PTunnel)
                
+[00:19]  (or .nofity/etc)
                
+[00:19]  right
                
+[00:19] * mrflibble has joined #i2p
                
+[00:20]  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]  jrand0m: i could add the async interface to TunnelManager myself, but the interface still doesn't exist :-)
                
+[00:22]  right, just add public void notifyEvent(String eventName, Object value); to Logging.java
                
+[00:22]  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]  0.3 is still a ways off
                
+[00:23]  0.3 should have the streaming api anyway, shouldn't it?
                
+[00:23]  jrand0m: i'm talking about the worst case
                
+[00:23]  jrand0m: Maybe there should be another version before 3.0 to settle these issues?
                
+[00:23]  yes mihi
                
+[00:23]  human: the worst case is "cvs rollback && patch -p0 your.patch"
                
+[00:24]  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]  jrand0m: do you have a job?
                
+[00:27]  i2p
                
+[00:27]  get 1.0 done!
                
+[00:27]  I mean a source of income
                
+[00:27]  :)
                
+[00:27]  that you have to work for
                
+[00:27]  income is overrated.
                
+[00:27] * jrand0m fired my boss
                
+[00:27]  "will code for food"  - that's my motto
                
+[00:27]  lol
                
+[00:27]  mihi: well, but i and aum (who is working on a python app for the TunnelManager) would like to have jobIds ASAP...
                
+[00:28]  jrand0m: ok, i'll work on your changes later/tomorrow
                
+[00:28]  Job/Money, sleep/hygiene, food, side projects, social life: Choose any 3
                
+[00:29] * jrand0m only choses one.
                
+[00:29]  word human
                
+[00:30]  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]  or a waffle bbs
                
+[00:30] * duck is now known as enduser
                
+[00:30] * jrand0m kicks enduser
                
+[00:31]  (damn, no ops)
                
+[00:31]  For OS/2 there was a comm driver that could map a comm port to a TCP port =)
                
+[00:31]  what difference will I see as enduser when I2PTunnel uses the SteamingAPI?
                
+[00:31] * enduser is now known as duck
                
+[00:31]  none
                
+[00:31]  lol
                
+[00:31]  FillaMent: friend of mine ran a BBS that way for a while
                
+[00:31]  performance, and perhaps anonymity
                
+[00:31] * human would like a I2P tunnel to a rootshell
                
+[00:32]  any volunteer? :-)
                
+[00:32]  rootshell on a UML
                
+[00:32]  chroot'ed rootshells would be good
                
+[00:32]  or UML'ed :)
                
+[00:32]  human: had I a spare boxen, I'd do it
                
+[00:32]  hehe FillaMent
                
+[00:32]  vnc connection to my vmware win98?
                
+[00:32]  seriously though guys...
                
+[00:32]  E-mail server would be a good one as well. Or do we have that already?
                
+[00:32]  wiht: think TC has pop and SMTP
                
+[00:33]  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]  ooOOoo
                
+[00:33]  well, I'm not too keen on setting up open SMTP access yet
                
+[00:33]  understandable
                
+[00:34]  maybe when the network is more stable and I've got money to up my bandwidth
                
+[00:34]  How about a PGP keyserver?
                
+[00:34]  FillaMent: you could set up a tunnel pointing to a cleartext remailer
                
+[00:34]  wiht: now THAT's a great idea =)
                
+[00:35]  mihi heh... I could just point the tunnel to my ISP SMTP box =)
                
+[00:35]  FillaMent: this would make *you* be resposible for abuse...
                
+[00:35]  s/be//
                
+[00:35]  http://www.mit.edu/people/marc/pks/pks.html
                
+[00:36]  seriously, should duck enterprises consider running a pgp keyserver?
                
+[00:37]  duck: I was poking into that myself... you want to handle it?
                
+[00:37]  we have been one of the most stable service providers according to mihi's independent ping logs
                
+[00:37]  hehe
                
+[00:37]  duck: Yes, please consider it.
                
+[00:37]  btw duck, how do you do that?  do you restart periodically or just run on a reliable OS and JVM?
                
+[00:38]  question: does the JVM cache DNS resolves?
                
+[00:38]  restarting is for kernel updates
                
+[00:38]  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]  oh yeah,
                
+[00:39] * mrflibble sticks his hand up
                
+[00:39]  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]  sup mrflibble?
                
+[00:39]  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]  how would that affect my router's presence on the network?
                
+[00:40]  my box could be availalbe for some kind of demony thing
                
+[00:40]  cool FillaMent, shouldn't be much of a problem, as long as you point to your dyndns
                
+[00:40]  mrflibble: demony?
                
+[00:40]  i guess it depends how much bandwidth the thing would use
                
+[00:40]  daemony
                
+[00:40]  w3rd mrflibble - has the router been working reliably for you, or are you just being a good sameritan?  :)
                
+[00:41]  not really, but that's because my local bw is saturated atm
                
+[00:41]  im not running it on my colo yet
                
+[00:41]  want to play around with it locally first
                
+[00:41]  ah cool.  yeah, i2p isn't really ready for wide deployment, still for testing mainly
                
+[00:42]  Heh.. I'll point a tunnel to my CUPS server and you can have anonymous printing =)
                
+[00:42]  rofl
                
+[00:42]  if there's something that u want me to run that would use <40gb bw a month, lmk
                
+[00:42]  just include a banner page so I know where to mail the hardcopy =)
                
+[00:42]  hehe
                
+[00:43]  wikked mrflibble, I'm sure we'll take you up on that :)
                
+[00:43]  banner | lpr ? ;)
                
+[00:43]  mihi you cah set up CUPS with a banner page
                
+[00:43]  oky doky!
                
+[00:43]  banner will most likely create lots of pages ;)
                
+[00:43]  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/i2p2www/meetings/73.log b/i2p2www/meetings/73.log
new file mode 100644
index 00000000..49234fac
--- /dev/null
+++ b/i2p2www/meetings/73.log
@@ -0,0 +1,143 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 73{% endblock %}
+{% block content %}
                Tuesday, Jan 13, 2004 22:00:00 CET
                
+
                
+[22:01]  0) hi
                
+[22:01]  1) 0.2.3.4
                
+[22:01]  2) 0.3
                
+[22:01]  3) streaming library, I2COCP, CI2CP
                
+[22:01]  4) apps
                
+[22:01]  5) ???
                
+[22:01]  0) hi
                
+[22:01]  hi everyone
                
+[22:01]  y'all seen http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html?
                
+[22:01]  if not, now's your chance :)
                
+[22:02]  iip has been acting up a bit, so if someone could say something every once in a while, that'd be swell 
                
+[22:02]  .
                
+[22:02]  w3rd
                
+[22:02]  ok, moving on, 1) 0.2.3.4
                
+[22:03]  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]  e.g. tunnelmanager isn't in 0.2.3.3 yet
                
+[22:03]  col
                
+[22:03]  it'll be backwards incompatible, because i'm mean
                
+[22:04]  jumping onto 2) 0.3
                
+[22:04]  :P
                
+[22:04]  that'll be out fairly soon, but obviously not on thursday
                
+[22:04]  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]  cool
                
+[22:05]  well, moving right along to 3) streaming lib / etc
                
+[22:05]  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]  if anyone wants to get involved in it, please let me know
                
+[22:06] * ion has joined #i2p
                
+[22:06]  'lo eco, mihi, ion
                
+[22:06]  ok, moving on to 4) apps 
                
+[22:06]  anyone working on an app that will run over i2p that has anything to add?
                
+[22:07] * wiht has joined #i2p
                
+[22:07]  re ask the quest j
                
+[22:07]  well, we're at the last agenda item, so might as well :)
                
+[22:08]  wiht .. get my email?
                
+[22:08]  anyone have anything to bring up outside the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html post?
                
+[22:08]  Yes, let me read it.
                
+[22:08]  MrEcho> have you read zooko's naming page yet?
                
+[22:08] * jar has joined #i2p
                
+[22:08]  no .. lost the link
                
+[22:09]  (from the logs last week, http://zooko.com/distnames.html)
                
+[22:10]  anyone have anything to add, or are we at a record breaking 10 minute meeting?
                
+[22:10]  still working on my dns idea
                
+[22:10]  coo'
                
+[22:10]  MrEcho: Yes, I would like to work together on naming service.
                
+[22:10]  sweet
                
+[22:11]  But I will not have time until next Wednesday.
                
+[22:11]  ok
                
+[22:11]  will give me some time to finish up on a few things
                
+[22:11]  how long till the meet?
                
+[22:11]  -11 minutes
                
+[22:11]  oops
                
+[22:11] * mrflibble is v late
                
+[22:11]  :)
                
+[22:12]  (we've gone through the 5 agenda items very very quicky :)
                
+[22:12] * mrflibble goes back to lurking and the backscroll
                
+[22:12]  heh
                
+[22:12]  jrand0m: Have you measured how much CPU is used per tunnel by the server?
                
+[22:14]  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]  they shouldn't consume 20% of the cpu, or even 1%
                
+[22:15]  (for client tunnels - server tunnels may consume more)
                
+[22:15]  Server tunnels.
                
+[22:16] * eco has quit IRC (Ping timeout)
                
+[22:16]  But that will probably be dependent on your CPU speed, so that was a badly stated question.
                
+[22:16]  server tunnels before the streaming lib will require cpu load whenever a new peer connects 
                
+[22:18]  All right.
                
+[22:19]  are we at #5 already?
                
+[22:19] * ion has quit IRC (Ping timeout)
                
+[22:19]  yup
                
+[22:20] * duck mentions the hosting options that home.duck.i2p provides
                
+[22:20]  ooOOoo
                
+[22:20]  it hasnt been tested by anybody besides me though
                
+[22:20]  waiting for betatester Ardvark to show up
                
+[22:20]  so the hosting lets someone run apache / etc?
                
+[22:21]  (or do they have to run the i2p router?
                
+[22:21]  neither
                
+[22:21]  they can put their html files on /home/username/public_html/
                
+[22:21]  and it will show up on http://home.duck.i2p/~username/
                
+[22:21]  ah nice
                
+[22:21]  php support?  cgi / .pl / etc?  or just html?
                
+[22:22]  (thats kick fucking ass, in any case)
                
+[22:22]  php and html
                
+[22:22]  wwwwwwwwwicked
                
+[22:22]  duck: won't that compromize your anonymity?
                
+[22:22]  how?
                
+[22:22]  phpshell?
                
+[22:22]  or is the full apache in a vmware/UML box?
                
+[22:22]  system, exec, etc are disabled
                
+[22:23]  plus the host cant connect to the outsite
                
+[22:23] * wilde has joined #i2p
                
+[22:23]  (it is inside an UML box)
                
+[22:23]  (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]  jsp access?  :)
                
+[22:23] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))
                
+[22:23]  ofcourse not
                
+[22:24]  and why not ssh access as well, when it's an UML box?
                
+[22:24]  because the average IIP user will start running forkbombs
                
+[22:24]  with ssh access, they could traceroute i2p.dnsalias.net
                
+[22:24]  man ulimit
                
+[22:24]  ah true
                
+[22:24]  man limiting cpu time on uml boxes.
                
+[22:25]  (okay, it will crash apache, shit...)
                
+[22:25]  man run your own host :)
                
+[22:25]  hehe
                
+[22:25]  hi
                
+[22:25]  I'll add it on the todo
                
+[22:25]  a reliable hosting service provider will RULE
                
+[22:25]  now all we need is a wiki
                
+[22:25] * wiht has left #i2p (wiht)
                
+[22:26] * lucky has a reliable net connection...
                
+[22:26]  you already have a wiki
                
+[22:26]  kaji> duck.i2p has one
                
+[22:26]  wiki.invisiblenet.net
                
+[22:26]  that too
                
+[22:26]  oh sweet then
                
+[22:26]  (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]  'k, anything else before we close out the meeting?
                
+[22:29]  doh, i missed the meeting?
                
+[22:29]  we're not quite done yet, but about it
                
+[22:29]  meeting?
                
+[22:29]  Oh, thats so not fair
                
+[22:29]  i just got home.
                
+[22:29]  are there logs anywhere?
                
+[22:29]  meeting log
                
+[22:30] * lucky has a log...
                
+[22:30]  can some one write a howto for using wget over i2p in windows?
                
+[22:30]  meeting logs at http://wiki.invisiblenet.net/iip-wiki?Meetings
                
+[22:30]  kaji you'll probably need to add the http_proxy to the environment
                
+[22:32]  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]  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]  word kaji!
                
+[22:32] * jrand0m *baf*s the meeting closed on that note
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/74.log b/i2p2www/meetings/74.log
new file mode 100644
index 00000000..f715f41d
--- /dev/null
+++ b/i2p2www/meetings/74.log
@@ -0,0 +1,190 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 74{% endblock %}
+{% block content %}
                Tuesday, Jan 20, 2004 22:00:00 CET
                
+
                
+[22:07]  agenda:
                
+[22:07]  0) hi (read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html)
                
+[22:07]  1) router dev status
                
+[22:07]  2) twisted-i2p
                
+[22:07]  3) unit tests
                
+[22:07]  4) network testing / monitoring
                
+[22:07]  5) ???
                
+[22:07]  0) hi
                
+[22:07]  hi
                
+[22:07] * jrand0m waves
                
+[22:07]  ohhhh meeting!
                
+[22:07] * dm waves back.
                
+[22:07]  9p gmt every tuesday :)
                
+[22:08]  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]  1) router dev status
                
+[22:09]  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]  reading...
                
+[22:10]  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]  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]  ok, moving on
                
+[22:12]  2) twisted+i2p
                
+[22:12]  I do have errors
                
+[22:12]  but probably due to others
                
+[22:12]  dropped messages and unknown tunnels, right?
                
+[22:12]  checking
                
+[22:13]  (those are the errors I see with one of my 'live' routers but not on the test network)
                
+[22:13]  22:13:15.371 ERROR [ Sender 1148] er.transport.phttp.PHTTPSender: Error sending the message
                
+[22:13]  ah ok, yeah, i've been smacking around the phttp relay too
                
+[22:13]  21:01:01.509 ERROR [JobQueue28  ] eDatabaseSearchReplyMessageJob: Invalid router info returned from [Rout
                
+[22:14]  hmm that one is funky - could you bounce me the stacktrace?
                
+[22:14]  I'll put it up.
                
+[22:14]  .
                
+[22:14]  gracias
                
+[22:15]  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]  ok, back to 2)
                
+[22:16]  human has put together a way to use i2p via python and the twisted framework (yay!)
                
+[22:17]  see his email for more info (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000100.html) 
                
+[22:17]  anything to add human?  (if you're here)
                
+[22:17]  it is _so_ cool
                
+[22:17]  yeah, the sample code for the echo server and client look kick-ass
                
+[22:18]  ok, moving on to 3) unit tests
                
+[22:19]  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]  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]  probably it is difficult to test more complex things
                
+[22:21]  thats going to come up to be on the critical path sooner rather than later, depending on where the debugging leads us
                
+[22:21]  right, the unit tests as is just test the basics
                
+[22:21]  like routing, tcp stuff etc
                
+[22:21]  right
                
+[22:21] * dm sees a debate on value of unit testing coming.
                
+[22:21]  but things like the AESInputStream can be tested in collaboration with AESOutputStream
                
+[22:22]  unit test = kickass
                
+[22:22]  (and for those watching their logs closely, there's been some funky "pushed back" behavior during decrypt streaming)
                
+[22:22]  definitely.
                
+[22:23]  unit tests are just for the, er, units.  not for the larger components (which is what agenda item 4 is about ;)
                
+[22:24]  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]  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]  wikked!
                
+[22:25]  No promises though.
                
+[22:25]  right right
                
+[22:25]  ok, moving on to 4) network testing / monitoring
                
+[22:26]  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]  digest wat?
                
+[22:28]  C) but not with automatic sending.
                
+[22:28]  i.e. you type emaillogstojrandom.sh (.bat)
                
+[22:28]  email or post, or whatever.
                
+[22:29]  and when it does that it clears you log, or moves it somewhere, so you don't submit the same data twice.
                
+[22:29]  so basically B
                
+[22:29]  (or A)
                
+[22:29]  Yeah, user-friendly B) :)
                
+[22:29]  thats one of the tricks wrt the data... that log grows to tens of megs per night
                
+[22:29]  right 
                
+[22:30]  sorry, didn't see history=false for C.
                
+[22:30]  Frontier) we're discussing section 4 of http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html?
                
+[22:30]  jrand0m: man bzip2
                
+[22:30]  So history=false with a script to post on command.
                
+[22:30]  sorry, history=true :)
                
+[22:30]  god, I've made a mess of it.
                
+[22:31]  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]  I wouldn't worry about the size, 10s of megs for the small group of people you have here is fine.
                
+[22:32]  I vote C.
                
+[22:32]  As long as it gets archived when you run the script to submit.
                
+[22:32]  This is a debug client.
                
+[22:32]  A in a production client of course :)
                
+[22:32]  jrand0m: then use GZipOutputStream
                
+[22:32]  right right Ophite1 ;)
                
+[22:33]  mihi> people might like to read these files ;)
                
+[22:33]  yeah, opt-in for debugging participation, but once you join, make it as easy as possible for the user (so C)
                
+[22:33]  man zcat ;)
                
+[22:33]  jrandom: gzcat | less ;-)
                
+[22:33]  Ophite1: zless ;)
                
+[22:33]  C:\Documents and Settings\dev>man
                
+[22:33]  'man' is not recognized as an internal or external command,
                
+[22:33]  operable program or batch file.
                
+[22:33]  ;)
                
+[22:34]  cd \cygwin <Ctrl+T> call cygwin.bat
                
+[22:34] * dm twiddles his thumbs.
                
+[22:34]  double-click -> winrar -> view
                
+[22:34]  ok, so we have one B, two C, whats your take mihi?
                
+[22:34]  (and anyone else?)
                
+[22:34]  twiddle thumbs, pick nose, click click.
                
+[22:34]  double-click - 7zop - view. I'd say C.
                
+[22:35]  s/7zop/7zip/
                
+[22:35]  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]  i'll see if i can implement both c and b
                
+[22:36]  Looks like C it is.
                
+[22:36]  Don't waste your time, the B person is on dialup and would offer very little data anyway ;)
                
+[22:36]  hehe
                
+[22:36]  well, c is probably going to be implemented on top of b, so it won't take any more work
                
+[22:37]  for me : just like Ophite1 said ! A for prod client, C for debug ...
                
+[22:37]  word jar
                
+[22:37]  just like Ophite1 said ! A for prod client, C for debug ...
                
+[22:37]  obviously not anything other than A for prod client...
                
+[22:37]  just like Ophite1 said ! A for prod client, C for debug ...
                
+[22:37]  that's a no-brainer :)
                
+[22:37]  sorry ... :(
                
+[22:37]  s'all good jar, we won't kickban you (... this time ;)
                
+[22:38]  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]  ok, moving on to 5) ???
                
+[22:39]  anyone have anything else?  questions, thoughts, concerns?
                
+[22:39] * duck offers free hosting
                
+[22:39] * dm accepts free hosting
                
+[22:39]  oh word.  yeah, people should host sites on host.duck.i2p, its nice having reachable pages 
                
+[22:39]  (of course people should also feel free to host for themselves too ;)
                
+[22:40]  sure, just for those who can't stay online 24/7
                
+[22:40]  right
                
+[22:40]  what happened (will happen?) to the streaming api?
                
+[22:40]  mihi> its in the task list, but getting the network functioning reliably is higher priority at the moment :/
                
+[22:41]  but it is not dropped completely? (that's what i wanna know...)
                
+[22:41]  i'll get back to the streaming api for the 0.3.1 release (perhaps sooner, but not sure)
                
+[22:41]  its definitely NOT dropped completely.
                
+[22:41]  it will be done.
                
+[22:41]  What's this streaming API? A different way of exposing the network to clients?
                
+[22:42]  dm> http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary
                
+[22:43]  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]  (the insanely awesome benefit of that mistake was mihi coming along and writing i2ptunnel :)
                
+[22:44] * wn-user has joined #i2p
                
+[22:44]  anyone else have anything?
                
+[22:44] * dm gets it.
                
+[22:45]  w3rd
                
+[22:45]  Hmmm, too early to end meeting, ain't it?
                
+[22:45]  what about the hosts.txt
                
+[22:45]  it is growing and growing
                
+[22:45]  well, 45 mins.  two weeks ago we had 20 mins
                
+[22:45]  ah, true that
                
+[22:45]  but 75% is offline
                
+[22:45]  and it looks like 50% is permanently offline
                
+[22:45]  prolly
                
+[22:46]  I dunno
                
+[22:46]  just keep it growing, to raise the incentive for a DNS solution :)
                
+[22:46]  heh exactly
                
+[22:46]  I'm all for a little delay, I'm having a lot of fun with all kinds of Windows problems...
                
+[22:46]  Ophite1: windows is the devil!
                
+[22:46]  You never really understand just how awful Windows is, until you write software for it.
                
+[22:47]  reason #941 to use java 
                
+[22:47]  Unless you're using .NET.
                
+[22:47]  also known as java++
                
+[22:47]  dm/jrand0m: it's still running *on* Windows, and there are still some things you just keep running into.
                
+[22:47]  jrand0m: those last patches, would they solve disconnects? or more connection problems
                
+[22:47]  Path lengths for example. Bloody unicode.
                
+[22:48]  Or not to use \n in file names ;)
                
+[22:48]  which will crash cvs anyway (on *nix, BTDT)
                
+[22:48]  duck> no patches today are critical
                
+[22:48]  from yesterday I mean
                
+[22:49]  What happens if you use \n in a filenamE? :)
                
+[22:49]  dm: try it ;) on *nix, nothing happens, as long as you don't try to run cvs update afterwards.
                
+[22:49]  oh, yesterday there were Good patches that would solve some (most? all?) i2ptunnel Peer unreachable messages.  not i2cp disconnects though
                
+[22:50]  I think it would throw an exception.
                
+[22:50]  (which is one of the reasons 0.2.3.5 is coming out)
                
+[22:51]  dm: it works w/ local repository, but not w/ pserver or ssh.
                
+[22:51]  something like 'protocol error'.
                
+[22:51]  (the protocol terminates file names by \n ;) )
                
+[22:51]  sort of like what happens with direct connect if you have filenames with $ and | in them. I hate DC.
                
+[22:51]  .
                
+[22:52]  No matter what I code, ever, it could never be that bad :)
                
+[22:52]  naw, you c devs just treat \0 as special instead of $ ;)
                
+[22:52]  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]  'k thazzit
                
+[22:54] * jrand0m *baf*s the meeting to a close
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/75.log b/i2p2www/meetings/75.log
new file mode 100644
index 00000000..0715ceb3
--- /dev/null
+++ b/i2p2www/meetings/75.log
@@ -0,0 +1,104 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 75{% endblock %}
+{% block content %}
                Tuesday, Jan 27, 2004 22:00:00 CET
                
+
                
+[22:03]  0) hi
                
+[22:03]  1) router dev status (0.2.4)
                
+[22:03]  2) RTCP
                
+[22:03]  3) i2p.net
                
+[22:03]  4) ???
                
+[22:03]  0) hi
                
+[22:03] * jrand0m waves
                
+[22:03]  this is meeting $num
                
+[22:03]  .
                
+[22:03] * mihi_backup has joined #i2p
                
+[22:03]  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]  ok, moving on (hopefully battling ping timeouts)... 1) router dev status
                
+[22:04] * baffled has joined #i2p
                
+[22:05]  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]  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]  yes
                
+[22:06]  sup?
                
+[22:06]  seems that still after a while the whole tunnel thing locks up
                
+[22:07]  then madman2003 and human have to shout at me
                
+[22:07]  and restart everything
                
+[22:08]  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]  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]  that means that whenever you build a tunnel through them, your tunnel is unreachable
                
+[22:09] * DrWoo has quit IRC (Ping timeout)
                
+[22:09]  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]  ok, so that is phttp part?
                
+[22:09]  (the 'con' camp being led by "upgrading sucks")
                
+[22:10]  hmm?  the phttp code has been patched in cvs
                
+[22:10]  what con camp?
                
+[22:10]  madman2003> I think baffled might be looking at that :)
                
+[22:10]  upgrading is easy :)
                
+[22:10]  upgrading rox
                
+[22:10]  with i2pmgr it's even easier
                
+[22:11]  just a touch of a button :)
                
+[22:11] * Robert has joined #i2p
                
+[22:11]  I'm looking at it madman might be a while!
                
+[22:11]  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]  if thats fine, i can wrap up a 0.2.3.6 quite easily
                
+[22:11]  updating makes me happy
                
+[22:12]  what does .6 fix?
                
+[22:12]  I'd say go for it most of us don't have any problem with upgrading regularly.
                
+[22:12]  i'd upgrade every 24 hours if that does it
                
+[22:12]  0.2.3.6 fixes PHTTP to be, er, functional
                
+[22:12]  ok cool
                
+[22:13]  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]  (as well as here)
                
+[22:13] * Masterboy has quit IRC (Ping timeout)
                
+[22:14]  ok, anything else for the dev status, or shall we jump to 2) RTCP
                
+[22:15] * jrand0m jmp 2
                
+[22:15]  you can always get back to it
                
+[22:15]  right right
                
+[22:15]  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]  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]  but, well, that essentially grows into IRC, or another full on anon network
                
+[22:17]  you mean totally eliminating PHTTP?
                
+[22:17]  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]  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]  (i'd intergrate in the router, because that would spread the load of the relaying)
                
+[22:18]  agreed
                
+[22:19]  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]  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]  or use multiple relays if the there are more relays then people who need relays
                
+[22:20]  How would folks find the various rtcp relays?
                
+[22:20]  phttp :)
                
+[22:20]  right, thats a good point - routers can create targets on multiple relays
                
+[22:20]  baffled> rtcp relays will be listed in a router's RouterInfo (published in the networkDb)
                
+[22:21]  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]  something i just thought off: auto restart of tunnels every 12 or 24 hours
                
+[22:23]  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]  one of my routers on a linux box has been up without interruption for several days
                
+[22:24]  madman2003: you can add your own threads to the jvm to quit it after 12 hours
                
+[22:24]  (and it only went offline when I upgraded it)
                
+[22:24] * madman2003 has to go
                
+[22:25]  l8r madman2003
                
+[22:25]  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]  ok, anything else on rtcp?
                
+[22:26]  no, sounds good
                
+[22:26]  ok, moving on to a brief one
                
+[22:26]  3) i2p.net.  
                
+[22:26]  nuff said
                
+[22:26]  4) ???
                
+[22:26]  anyone have anything else?
                
+[22:28]  .
                
+[22:28] * jrand0m senses a record breaking 26 minute meeting
                
+[22:29]  lol
                
+[22:29] * Reskill ambles in
                
+[22:29]  'mornin Reskill
                
+[22:29]  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]  if there is nothing further...
                
+[22:30]  Oo...
                
+[22:30]  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/i2p2www/meetings/76.log b/i2p2www/meetings/76.log
new file mode 100644
index 00000000..eb3b265a
--- /dev/null
+++ b/i2p2www/meetings/76.log
@@ -0,0 +1,520 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 76{% endblock %}
+{% block content %}
                Tuesday, Feb 3, 2004 22:00:00 CET
                
+
                
+[22:01]  0) hi
                
+[22:01]  1) testnet
                
+[22:01]  2) updated roadmap
                
+[22:01]  3) updated application list
                
+[22:01]  4) volunteers needed
                
+[22:01]  5) ???
                
+[22:01]  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]  but anyway, as we proceed, everyone should read (or have read) http://i2p.dnsalias.net/pipermail/i2p/2004-February/000132.html
                
+[22:02]  lets jump right into 1) testnet
                
+[22:03]  you should change the subject for each mail... they all get sorted into one thread here
                
+[22:03]  hah nice
                
+[22:03] * jrand0m tried for consistency (for ease of filtering)
                
+[22:03]  would you like me to add the date to it?
                
+[22:03]  how is the testent really doing?(pessimistic opnion please)
                
+[22:03]  madman2003> poorly, but better than before
                
+[22:04]  jrand0m: date (or meeting number) would be great
                
+[22:04]  'k mihi, consider it done
                
+[22:04]  (anyone other than me want to give some feedback to madman2003's question?)
                
+[22:04]  madman2004: baffled and me have been connected for 4h now
                
+[22:04]  Really that long?
                
+[22:04]  before test3 the maximum time was 10 min
                
+[22:05]  w00t
                
+[22:05]  baffled: since 18:15:07 CET
                
+[22:05]  yeah i had a 90m session the other day too
                
+[22:05]  but maybe we are directly hopped
                
+[22:05]  and you're sure the link is intact?
                
+[22:05]  duck> all tunnels are 2 hop (unless your router is failing, in which case your tunnels will break at least once)
                
+[22:06]  madman2003> when the tunnels fail, they fail hard
                
+[22:06]  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]  5-20s latency through irc
                
+[22:07]  is the 30 secs delay on local sites fixed yet?
                
+[22:07]  duck> can you /ping duck on your ircd?  how long does it take to reply with a CTCP refused error?
                
+[22:07]  (or baffled>)
                
+[22:08]  madman2003> there have been significant bugfixes that would account for 30s+ delays locally
                
+[22:08]  (jobs got locked up causing insane delays)
                
+[22:08]  response to admin request to baffleds ircd is ~8s
                
+[22:08]  duck> to local?
                
+[22:09]  fido ping/pong is 3 seconds, which is local
                
+[22:09]  coo'
                
+[22:09]  for local eepsites it also seems to be ~3s
                
+[22:09]  (still much higher than i'd like, but <<30s)
                
+[22:09]  initial request longer, might be ~30s
                
+[22:10]  interesting
                
+[22:10]  ,
                
+[22:10]  ok, so there's definitely still work to be done on the testnet, but there's been progress
                
+[22:10]  is the testnet going to run until poor performance becomes perfect, what is the exact requirement of succes?
                
+[22:11]  (i know about 3 days of working good)
                
+[22:11]  success == 3 consecutive days of things that should succeed succeeding.
                
+[22:11]  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]  basically a way we can just leave a pair of bots connected to the two ircds and measure our progress and failures
                
+[22:12]  (yay human!)
                
+[22:12]  hmm, if there is no netsplit, i2p is working, but you cannot make the other way conclusion...
                
+[22:13]  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]  why don't you focus on making local delay <1s?
                
+[22:13]  that i will.
                
+[22:13]  good chance that will solve some other problems too
                
+[22:13]  the cause of >1s delay is likely the load
                
+[22:14]  for routers with no peers, local only requests are near instantaneous
                
+[22:14]  (but as the testnet is actually showing some load, we're stressing different things)
                
+[22:15]  baffled and me also had a little chat about making statsbots, but if human wants to do it; cool for me
                
+[22:15]  maybe delays have to do with requests being send to other routers
                
+[22:15]  before it see that it's local
                
+[22:15]  oh word duck
                
+[22:15]  naw, doesn't work that way madman2003
                
+[22:16]  (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]  france.
                
+[22:16]  er, germany.
                
+[22:16]  (since *someone* is pinging everyone ;)
                
+[22:17]  kuala lumpur
                
+[22:17] * duck hopes nobody gets that joke
                
+[22:17] * jrand0m is pleased to meet duck's hopes
                
+[22:17]  all that pings made my local box thrashing as well... (with no router!)
                
+[22:18]  mihi> the i2cp lib does the crypto ;)
                
+[22:18] * wiht has joined #i2p
                
+[22:18]  doesn't i2p protect from ping floods?
                
+[22:19]  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]  grain sync?
                
+[22:19]  jrand0m: congrats: seems that ping -ns does not only produce - - - now
                
+[22:20]  lol mihi :)
                
+[22:20]  why lol? ping -ns never worked for me. (only the synchronized one)
                
+[22:20]  synchronized one never worked for me...
                
+[22:20]  oh really?  word, -ns has been working well for me
                
+[22:21]  madman2003> its a tradeoff of memory and CPU vs concurrency
                
+[22:22]  (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]  bah.
                
+[22:23]  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]  miserably day.
                
+[22:23]  stupid capitalist pigs
                
+[22:23]  taking all my money..
                
+[22:24]  looks like there a are new goodies in cvs, how long before test4?
                
+[22:24]  not today, hopefully tomorrow
                
+[22:24] * jrand0m is going to bed after the meeting :)
                
+[22:25]  cool.
                
+[22:26]  bye everyone
                
+[22:26]  later madman2003
                
+[22:26]  don't forget the other points of the meeting :)
                
+[22:26]  ok, so thats testnet.  anything else on that, or shall we move to 2) updated roadmap?
                
+[22:26]  hehe
                
+[22:26]  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]  what date is it?
                
+[22:27]  Feb 3
                
+[22:27]  3rd here.
                
+[22:27]  2004-02-03
                
+[22:27] * leenookx has joined #i2p
                
+[22:27]  ah, thanks
                
+[22:27]  baffled> actually, has anyone tried out i2psnark on testnet?
                
+[22:27]  baffled: What do you mean by stressers?
                
+[22:28]  wiht: i guess people stressing the testnet
                
+[22:28]  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]  so those two items I guess.
                
+[22:28]  we've had a good crew hitting the squid
                
+[22:28]  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]  agreed mihi
                
+[22:29] * jrand0m checks what port 'echo' is
                
+[22:29]  7
                
+[22:29]  afaik 9
                
+[22:29]  oops ;)
                
+[22:29]  You may been frazelled about something else at the time.
                
+[22:30]  Port 7.
                
+[22:30]  4
                
+[22:30] * ion has joined #i2p
                
+[22:30]  prolly baffled ;)
                
+[22:30]  echo            4/ddp                           # AppleTalk Echo Protocol
                
+[22:30]  echo            7/tcp
                
+[22:30]  echo            7/udp
                
+[22:30]  echo            4/ddp                           # AppleTalk Echo Protocol
                
+[22:30]  Port 7 for TCP and UDP.
                
+[22:30]  duck: we want [0-9]*/tcp
                
+[22:30] * duck ducks
                
+[22:31] * Synonymous has joined #i2p
                
+[22:31]  so, anyone want to wrap up human's test app (the echo server and client)?
                
+[22:32]  (though running twisted does seem a bit much for that ;)
                
+[22:32]  the non-twisted one would work
                
+[22:33]  .
                
+[22:33] * jrand0m didn't realize his i2p code could work w/out twisted
                
+[22:33]  but anyway, anyone wnat to volunteer to run point on getting an echo service up?
                
+[22:33] * duck sits on his hands
                
+[22:33]  Reachable through I2P, or reachable through regular Internet?
                
+[22:34]  through i2p
                
+[22:34]  I can look into it with some specific specs.
                
+[22:34]  duck: do ducks have hands? i thougt wings ;)
                
+[22:34]  spec: receive a line of text and echo it back :)
                
+[22:34]  oh, okay no prob.
                
+[22:34]  bah... i have to start filing taxes next year!
                
+[22:34]  jrand0m: s/line/byte chunk/
                
+[22:34]  Stupid, damn government...
                
+[22:35]  mihi> line is so much easier to parse ;)
                
+[22:35]  lucky: hush
                
+[22:35]  baffled++
                
+[22:35]  ok, moving on to 2) updated roadmap
                
+[22:35] * jrand0m directs people's attention to http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap
                
+[22:36]  jrand0m: why? while (len=in.read(b) != -1) {o.write(b,0,len);}
                
+[22:36]  (which, of course, y'all have already read)
                
+[22:36] * MrEcho has joined #i2p
                
+[22:36]  mihi> single byte messages vs nagle, etc
                
+[22:37]  but anyway, whatever baffled implements to do echoing to support testing is Good 
                
+[22:37]  (or you and he can work out what works best for you)
                
+[22:37] * wiht has quit IRC (Ping timeout)
                
+[22:37]  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]  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]  (netsplit after 4:20)
                
+[22:38]  heh
                
+[22:39]  not good :/
                
+[22:39]  well, iterative and incremental.
                
+[22:39]  22:38:09.430 ERROR [WrC1->Pz83  ] .i2p.i2ptunnel.I2PTunnelRunner: Error sending
                
+[22:39]  message to peer.  Killing tunnel runner
                
+[22:39]  are all 9/10 routers up atm?
                
+[22:39]  (or did one go down?)
                
+[22:40]  i only see 8
                
+[22:40]  22:41:02.758 ERROR [TCP Read [9]] er.transport.tcp.TCPConnection: Error reading from stream to [RouterIdentity:
                
+[22:40]          Hash: 4Sb3aJoFusrhpHgYA2xCZCkn0P5jBo822qu9C0wsE1w=
                
+[22:40] * duck did just update
                
+[22:40]  where goes the i2cp admin stuff fit in the roadmap?
                
+[22:41]  afaik that isnt implemented, but 0.2.5 talks about finalizing the spec
                
+[22:41]  current plan is to make I2CP the plain client protocol, leaving admin functionality seperate
                
+[22:41]  (e.g. through the :7655 admin web port)
                
+[22:41]  ok
                
+[22:42]  (and rip out all that other crap)
                
+[22:42] * jar_ has joined #i2p
                
+[22:42] * ion has joined #i2p
                
+[22:42]  ((shrinkingCodebase)++)
                
+[22:43]  does anyone have any thoughts on the two Big Issues?
                
+[22:43]  = aborting the current PHTTP transport (until 2.0)
                
+[22:43]  = keeping support for a restricted route topology at 2.0
                
+[22:43]  Well gang, gotta boogie so I'll have to read the logs later.
                
+[22:43]  cool, glad you could make it, l8r
                
+[22:43] * baffled has quit IRC (Leaving)
                
+[22:44]  secure i2cp would lower the direct need for restricted route topology a bit
                
+[22:44]  so thats fine
                
+[22:45]  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]  the only difference from the current i2cp is a little update to the authentication protocol / structure
                
+[22:46]  ((well, the $client can't detect $n, since messages are padded randomly.  nm)
                
+[22:46]  er, $sniffer, not $client
                
+[22:47] * wiht has joined #i2p
                
+[22:47]  (of course that doesn't defeat a global passive adversary)
                
+[22:48]  anyone have any other concerns / suggestions / ideas / comments?
                
+[22:48]  (on the roadmap)
                
+[22:49]  no
                
+[22:49]  nor do i
                
+[22:49] * jrand0m hops on to 3) updated application list
                
+[22:49]  [insert "mihi rules" rant here]
                
+[22:50]  help jrand0m to say no!
                
+[22:50]  mihi> any thoughts on the muffin thing?  http://wiki.invisiblenet.net/iip-wiki?I2PApplications
                
+[22:50]  heh
                
+[22:51]  jrand0m: you know what i think about that...
                
+[22:51]  (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]  httpclient has to get out of i2ptunnel, since i2ptunnel is for stream forwarding and httpclient does content forwarding
                
+[22:52]  hacking that into i2ptunnel would be just more hackish.
                
+[22:52]  word, so the app down below [Scalable web proxies]
                
+[22:52]  that makes sense
                
+[22:53]  (apps that do One Thing and One Thing Well)++
                
+[22:53]  jrand0m: you misunderstood me...
                
+[22:53]  whaddimiss?
                
+[22:54]  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]  httptunnel forwards everything except the first few lines.
                
+[22:54]  ah you're right
                
+[22:55] * jrand0m doesn't quite have head screwed on correctly
                
+[22:55]  it would be hard to build effective filtering into it (if it should filter html and not text or sth like that)
                
+[22:55]  right - perhaps just have MUFFIN as a standalone 
                
+[22:55]  (filtering whatever comes out of the httpclient)
                
+[22:55]  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]  jrand0m: I did not see an entry for "muffin" on the list of applications.
                
+[22:56]  wiht> http://muffin.doit.org/
                
+[22:56]  muffin is a http content filter
                
+[22:57]  if we have a content filter, we could drop that shitty "proxy" thingy.
                
+[22:57]  duck> hopefully the muffin filter would be set to pass through xmlrpc/soap, only filtering things like VBScript / etc
                
+[22:57]  I see.
                
+[22:57]  hm, mihi?
                
+[22:57]  ah wait, xmlrpc/soap would be content type xml
                
+[22:57]  mihi> wouldn't it still need to do the name translation, at the least?
                
+[22:58]  sure, but not as a proxy. http://localhost:12345/duck.i2p/ would work much better.
                
+[22:58]  muffin is gpl, u have to be careful in a public domain project to use gpl code, its still copyrighted ;)
                
+[22:58]  since you can link to that from the regular web
                
+[22:58]  hrm mihi.
                
+[22:58]  Synonymous: i2ptunnel is gpl anyway
                
+[22:58]  Synonymous> I2PTunnel is GPL
                
+[22:58]  ya
                
+[22:59] * jrand0m is well aware of the fact that some people consider copyrights valid, and tries to accomodate them.
                
+[22:59]  make sure to put that up where it is visible (if you use muffin) it already says that iptunnel is gpl
                
+[22:59]  of course, if we use muffin it'd get attributed and marked as gpl.
                
+[22:59]  ya thats what i said, becareful about it
                
+[23:00]  (we're not going to get into the copyright discussion here)
                
+[23:00]  ok, any other thoughts on the apps listed?
                
+[23:00]  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]  what do y'all think will be necessary app functionality for 1.0?
                
+[23:01]  heh duck
                
+[23:01]  (or are we already there, and 1.0 app functionality == things proxied through i2ptunnel :)
                
+[23:02]  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]  an IM and a naming service are still missing
                
+[23:02]  mihi> irc over i2p?
                
+[23:02]  Yes, naming service should be in place by 1.0 version of I2P.
                
+[23:03]  eep
                
+[23:03]  jrand0m: irc over i2p would be okay as well, but a naming service ;)
                
+[23:03]  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]  (all we *need* is a way to easily update a hosts.txt file)
                
+[23:04]  or a distributed vpn layer
                
+[23:04]  heh
                
+[23:04]  jrand0m: for me even that (if automated) is a naming service
                
+[23:04]  jrand0m: Probably by the middle of April.
                
+[23:05]  kaji> a distributed vpn layer is a solid month of 1-2 devs ;)
                
+[23:05]  I want to make it scalable for accomodating many more entries than we have in hosts.txt now.
                
+[23:05]  1.0-->3.0 wont have millions of entries
                
+[23:05]  MrEcho: Do you have any thoughts on this?
                
+[23:05]  thousands, yeah
                
+[23:06]  Synonymous> freenet like app would be cool, but then we need to recruit someone to implement :)
                
+[23:07]  Synonymous> tools to set up services - definitely.  hopefully i2pmanager or i2pmole will do
                
+[23:07]  that might be hard, esp since freenet doesnt work hehe
                
+[23:07]  Speaking of which, what is the progress of I2PManager?
                
+[23:07]  aparently its coming along, the console / cli mode is making progress (aum now uses it to manage his services via init scripts)
                
+[23:08]  i've used the gui, and aum's logged a few bugs on the tunnelmanager that are still outstanding
                
+[23:08]  (due to large #s of tunnels being created, not due to a small #)
                
+[23:08]  I think I2PManager should be an application for 1.0.
                
+[23:09]  i hope so too
                
+[23:09]  (especially since that would mean we can throw out the kludged installer, since i2pmanager has that built in)
                
+[23:09]  so, people with python experience should get in touch with aum to see how they can help :)
                
+[23:09]  re
                
+[23:09]  wb human
                
+[23:10] * human read about the muffin proxy
                
+[23:10]  i know about another privacy-oriented personal proxy called privoxy
                
+[23:11]  yeah, privoxy was another one i had been looking at.  good potential as well
                
+[23:11]  (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]  agreed
                
+[23:13]  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]  the channel would be the 'board' ?
                
+[23:13]  Synonymous> duck has actually done some neat stuff
                
+[23:13]  kool
                
+[23:14]  which is: users login with a secret password to the ircd, the ircd publishes the sha1 of the password
                
+[23:14]  Synonymous> in his modified ircd, you can provide a password that has its hash shown in the ident 
                
+[23:14]  it would also be like waste i guess, even though I didnt usei t
                
+[23:14]  duck> though if anyone else creates their own ircd, they can spoof that :/
                
+[23:14]  so others can check the sha1 against a local list, without requiring a centralized database
                
+[23:15]  sure
                
+[23:15]  but people could just remember what ircd someone usually connects from, i suppose
                
+[23:15]  would it be possible to have a nickserv?
                
+[23:15] * jrand0m doesn't know much about how irc nets work
                
+[23:16]  yes, but I didnt want that
                
+[23:16]  because Trent was made as a temporary hack
                
+[23:16]  right, it'd be Good if we could do without
                
+[23:16]  hehe
                
+[23:16]  until iip 2.0, right?  ;)
                
+[23:16]  now it is the longest running joke in the world
                
+[23:17]  .
                
+[23:18]  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]  (obviously it'd be fantastic if we could include i2psnark, naming, I2PIM, and the other apps)
                
+[23:19]  with irc you mean native i2pirc?
                
+[23:19]  or if not, why not nntp etc too
                
+[23:19]  oh, right
                
+[23:19]  of course
                
+[23:20] * jrand0m !thwaps self.
                
+[23:20]  not too much ofcourse
                
+[23:20] * duck thinks that the pgp keyserver is silly
                
+[23:20]  i just meant that its easy to overwhelm people with options
                
+[23:20]  ah, sure
                
+[23:20]  as in officially bundeled stuff
                
+[23:20]  "why should I use I2P" "well you can [.............]"
                
+[23:20]  right
                
+[23:20] * duck agrees
                
+[23:21]  with i2ptunnel, we can support all that we've seen (and more :)
                
+[23:21]  ok, in that case, I don't think we need to worry too much about the i2papps
                
+[23:21]  btw: we should deprecate the -nogui option of I2PTunnel...
                
+[23:22]  to default to -nogui?
                
+[23:22]  (or you trying to get us all to use awt?  ;)
                
+[23:22]  no. not to use -nogui at all. -cli and -nocli are more "transparent"
                
+[23:22]  you should also package all these options in 1 distro if you can
                
+[23:22]  ah ok mihi
                
+[23:22]  unlike freenet, which mentions no otehr utilities and its up to you to go find them out
                
+[23:22]  Synonymous> definitely
                
+[23:22]  Synonymous> have you used i2pmgr yet?
                
+[23:23]  -nogui acts differently whether you use -e "run configfile" or use "configfile"
                
+[23:23]  no, i couldnt get it working :)
                
+[23:23]  (its still pre-alpha, but functional)
                
+[23:23]  ah ok
                
+[23:23]  from before but it didnt try the gui
                
+[23:23]  i might try now that it has one
                
+[23:23]  :)
                
+[23:23]  word, its been makin progress
                
+[23:23] * duck suppresses a yawn
                
+[23:24]  yeah yeah yeah duck, ok ;)
                
+[23:24]  i think thats it for apps - unless someone else has something?
                
+[23:24]  moving on to 4) Volunteers needed
                
+[23:25]  we're making good progress, and the pace is fine and imho sustainable
                
+[23:25]  but we've all been talking about some really neat things that we'd like added on
                
+[23:25]  if there were another N hours in the day, yadda yadda yadda
                
+[23:26]  what do you mean with 'development bandwidth'?
                
+[23:26]  more hours of developer activity
                
+[23:26]  aye
                
+[23:27]  (e.g. 2 developers == 16/20 hours/day)
                
+[23:27]  my gut feeling is of the 'if you build it, they will come' variety
                
+[23:28]  (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]  heh
                
+[23:29]  product marketing != developer marketing
                
+[23:29]  right, i agree
                
+[23:29]  i just meant as an analogy
                
+[23:30]  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]  agreed Nightblade
                
+[23:31] * greasyaxelsex__ has joined #I2P
                
+[23:31]  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]  we currently have a generally up to date wiki providing an overview of the java impl
                
+[23:32]  hi dm
                
+[23:32]  but i will definintely need help with the documentation
                
+[23:32]  hello mihi.
                
+[23:33]  (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]  occationally ;)
                
+[23:34]  i will help wtih the webpage if u want
                
+[23:34]  (though the only thing i knowingly have coined wrt i2p is 'militant grade anonymity' ;)
                
+[23:34]  i already have a template
                
+[23:34]  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]  the website needs major owkr
                
+[23:34]  im working on my own anonymous p2p website, but you can borrow mine :)
                
+[23:35]  hehe
                
+[23:35]  its modeled after freenet's
                
+[23:35]  but better
                
+[23:35]  :P
                
+[23:35]  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]  Synonymous: are you building a p2p app, or just the website?
                
+[23:35]  just the website
                
+[23:35]  (and if that traffic grows, we'll move to something like i2p-www@)
                
+[23:36]  ROFL at anonymous p2p website boilerplates
                
+[23:36]  dm> roadmap updated at http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap with 0.2.4 slated for February 14
                
+[23:36]  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]  dm> bugless sw does not exist
                
+[23:36]  duck> gotta keep the anonymity set large ;)
                
+[23:36]  also links to the other website that does that
                
+[23:37]  mihi: does too!
                
+[23:37]  mihi> i worked on one project a few years ago that actually shipped with 0 bugs.  no p1 or even p5s
                
+[23:37]  func addints(int a, int b) { return a + b; }
                
+[23:37]  jrand0m: they just did not find them...
                
+[23:37]  dm: which language?
                
+[23:37]  mihi> then its not a bug ;)
                
+[23:37] * greasyaxelsex__ has left #I2P (greasyaxelsex__)
                
+[23:37]  pseudo-language
                
+[23:38]  and how does this pseudo-language react on an overflow?
                
+[23:38]  dm: In a project with thousands of lines of code, having no bugs is much less likely.
                
+[23:38]  .
                
+[23:38]  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]  input is never over max_value /2
                
+[23:39]  (we're currently ~20KLOC, using the "grep \; | wc -l" algorithm)
                
+[23:39]  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]  that's a lotta lines.
                
+[23:40]  Java bloat!
                
+[23:40]  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]  java bloat is when the jvm uses ram.  you're suggesting OO bloat
                
+[23:40]  What a project leader jrand0m is.
                
+[23:40]  well, how will u know if ppl are interested if there is no knowledge of it, thats a contradiction
                
+[23:41]  and by 'recruit' i mean email them, not pubically anounce on say, zeropaid, about i2p
                
+[23:41]  like someone did ;)
                
+[23:41]  Synonymous> what are your thoughts on the explanation of that issue from the email?
                
+[23:41]  Right OO bloat.
                
+[23:41]  yeah, I was pissed when someone told me about that zp article
                
+[23:41]  ya your the one that did the interview
                
+[23:41]  (you can read the august iip-dev messages)
                
+[23:41]  they just quoted you?
                
+[23:41]  "interview"?  more like some random person on iip asking me questions
                
+[23:42]  mihi: are you working on the streaming lib?
                
+[23:42]  ah :)
                
+[23:42]  dm:no
                
+[23:42]  Standard@laptop /cygdrive/c/eigenes/notback/cvsprojects/i2p/i2p/code
                
+[23:42]  $ grep \; `find . -name "*.java"` | wc -l
                
+[23:42]    30593
                
+[23:42]  ah.
                
+[23:42]  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]  30kLOC ;)
                
+[23:42]  grep -v \^import
                
+[23:43]  Synonymous> stealing project leads == bad form ;)
                
+[23:43]  (there are many good projects, and while I obviously think i2p is important, others are too)
                
+[23:44]  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]  heh
                
+[23:46]  ok, moving on to 5) ???
                
+[23:46]  2 eepsite proposals, for those who dont know what to do: 1) meshmx FE tunnel (with stunnel) 2) pastebin.de site
                
+[23:46]  anyone have anything else to discuss / bring up?
                
+[23:46]  oh word duck
                
+[23:46]  whats pastebin.de?
                
+[23:46]  (similar?)
                
+[23:47]  site where you can paste code/logs/stuff publically
                
+[23:47]  for irc debugging
                
+[23:47]  http://pastebin.de/
                
+[23:47]  interesting
                
+[23:47] * @Nightblade just prefers flooding channels with code
                
+[23:48]  wow that is one hell of an innovative idea
                
+[23:48]  insanely simple.
                
+[23:48]  focused.
                
+[23:48]  practical.
                
+[23:48]  Only python though?
                
+[23:48]  oh reall?
                
+[23:48]  :/
                
+[23:48]  I think this one has python highlighting
                
+[23:48] * jrand0m takes back 'practical' ;)
                
+[23:48]  but I have also seen php ones etc
                
+[23:48]  and you might have a general approach
                
+[23:48]  I think I've seen one which accepts any language.
                
+[23:49]  Good idea, mind you.
                
+[23:49]  anyway, just something simple
                
+[23:49]  you dont need highlighting at all
                
+[23:49]  online linenrs would be useful
                
+[23:49] * dm looks at python code.
                
+[23:49]  What's so special about this again?
                
+[23:50]  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]  there is nothing special about it,
                
+[23:51]  A lot of people really like it, I think.
                
+[23:51]  oh, you mean about python
                
+[23:51]  yes, sorry.
                
+[23:52] * duck moves that to 6) offtopic
                
+[23:52]  :)
                
+[23:52] <@jrand0m> heh
                
+[23:52] <@jrand0m> [beuler, beuler]
                
+[23:52]  Sorry, didn't realize you guys were having a meeting.
                
+[23:52] <@jrand0m> every tuesday 9p gmt :)
                
+[23:53]  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]  don't baf
                
+[23:56] * @jrand0m isn't going to try to drag it out 4 more minutes to reach 2 hours
                
+[23:57]  do not baf
                
+[23:57] * @jrand0m denies dm and *baf*'s the meeting closed
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/77.log b/i2p2www/meetings/77.log
new file mode 100644
index 00000000..a10534c3
--- /dev/null
+++ b/i2p2www/meetings/77.log
@@ -0,0 +1,502 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 77{% endblock %}
+{% block content %}
                Tuesday, Feb 10, 2004 22:00:00 CET
                
+
                
+[22:00]  <incoming>
                
+[22:00]  0) hi
                
+[22:00]  1) testnet status
                
+[22:00]  2) naming in i2p
                
+[22:00]  3) minwww and i2cp
                
+[22:00]  4) i2p.net website
                
+[22:00]  5) ???
                
+[22:00]  I was thinking the other day, that we could make a .NET interface to I2P. Anyway.. 
                
+[22:00]  well there will be one
                
+[22:00]  hello
                
+[22:00]  -1) .net interface would be cool
                
+[22:00]  0) hi
                
+[22:00] * madman-away is now known as madman2003
                
+[22:00]  hey y'all
                
+[22:00]  hi
                
+[22:00]  <-- will write a .net interface
                
+[22:00]  anyway hi
                
+[22:00]  r0x0r.
                
+[22:00]  awesome
                
+[22:01]  welcome to the 70somethingth meeting
                
+[22:01]  <-- needs that URL with the client protocol
                
+[22:01] * ion has joined #i2p
                
+[22:01]  i2p.net/ has links to the wiki, you'll probably want to use the tunnelManager
                
+[22:01]  ok
                
+[22:01]  (people should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html for this weeks status update)
                
+[22:01]  and that works good in the latest release?
                
+[22:02]  yup, aum uses it (and i just fixed a bug he was running into a few hours ago)
                
+[22:02]  (specs @ http://wiki.invisiblenet.net/iip-wiki?I2PTunnelManager)
                
+[22:02]  ok, movin' on
                
+[22:02]  1) testnet status
                
+[22:02]  okc ool yes,
                
+[22:03]  i hate sounding like a broken record here, but... testnet is making progress.  
                
+[22:04]  we're still not there, but we have multihour sessions without hiccup on the latest build
                
+[22:04]  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]  excellent
                
+[22:04]  We're at least populating the net with animals
                
+[22:05]  hehe
                
+[22:05]  dog, cat, mouse, duck...
                
+[22:05] * wiht has joined #i2p
                
+[22:05]  rabbit!
                
+[22:05]  maybe I should become a bafflo
                
+[22:05]  human!
                
+[22:05]  !!
                
+[22:05]  #animalfarm
                
+[22:06]  dm
                
+[22:06]  but, yeah, thats basically what i've got to say about the testnet status (beyond whats in that status email)
                
+[22:06]  people will read the logs offline so stay on topic please
                
+[22:06]  heh sorry dad ;)
                
+[22:07]  i think we're still on track for the roadmap
                
+[22:07]  How many more testnet releases do you plan to distribute?
                
+[22:07]  (plus i've been getting some future things done while running tests, such as the >2 hop tunnels)
                
+[22:07]  wiht> as many as it takes
                
+[22:08]  we're quite close to being done with this round of the testnet though, in my opinion
                
+[22:08]  isn't >2 hop tunnels just a setting?
                
+[22:08]  yes
                
+[22:08]  but in the past it wasn't well tested
                
+[22:08]  cool
                
+[22:09]  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]  <dreaming>an http listener to render .png on demand?</dreaming>
                
+[22:09]  (or just a /msg cat renderPNG)
                
+[22:10]  jrand0m: ok, it should be feasible
                
+[22:10]  I'd still like to see text summaries.
                
+[22:10]  human++
                
+[22:10]  on the ircmonitor.
                
+[22:10]  yes, (text summaries)++ too
                
+[22:10]  jrand0m: i was still thinking to make it use gnuplot to generate graphs (instead of gnu plotutils)
                
+[22:11]  potato, potato
                
+[22:11]  (ah, the glory of accents on irc)
                
+[22:11]  lol
                
+[22:11]  jrand0m, baffled: could you give me an example of a text summary?
                
+[22:11]  If you leave it with me a bit.
                
+[22:11] * dm read that as "potato, potato"
                
+[22:12]  period: 4 hours avg latency: 5.3s missed messages: 95 missed message frequency: 1 every 49 seconds
                
+[22:12]  (perhaps max & min latency)
                
+[22:12]  jrand0m: oh, ok
                
+[22:12]  if thats possible / not too much trouble
                
+[22:13]  (at least thats what i think of when i hear text summary)
                
+[22:13]  max latency, min latency
                
+[22:13]  human: look @ the summary i give for the ping tester
                
+[22:13]  hmm, anyone running an echo server this week?
                
+[22:13]  not to my knowledge
                
+[22:14]  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]  kickass
                
+[22:14]  Sorry mihi, I've been meaning to set yours up but keep forgetting.
                
+[22:14]  i think this will be a good part of the overall functional testing that will grow with us
                
+[22:15]  ok, do we have anything else for the testnet discussion?
                
+[22:16] * jrand0m moves on to 2) naming in i2p
                
+[22:16]  what's the biggest issue with testnet right now?
                
+[22:16]  biggest issue in testnet is two fold -
                
+[22:16]  1) finding and fixing the cause of router disconnect
                
+[22:17]  2) determining the cause of the frequent inter-ircd disconnects
                
+[22:17]  1b) coping w/ the fact that routers may disconnect sometimes
                
+[22:17]  right
                
+[22:17]  well, thats not really part of this testnet.
                
+[22:17]  0.3.x is a series of updates to deal with unreliable routers
                
+[22:18]  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]  So you are assuming reliable routers for now, right?
                
+[22:18]  in the 0.2.3.6 testnet, yes
                
+[22:18]  (it recovers from failure, but not quickly enough)
                
+[22:19]  (more graceful recovery will be with multiple leases per destination, increased peer profiling, replay prevention, and retries on alternate lease targets)
                
+[22:20]  ok, moving towards 2) naming in i2p
                
+[22:21]  wiht brings up the core of the issue - global names are really useful, and people like them
                
+[22:21]  (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]  People are used to them, perhaps more than to local names (such as your ICQ analogy).
                
+[22:22]  i'm not sure.
                
+[22:22]  lets say for instance that my name is John.
                
+[22:22]  John isn't global.
                
+[22:22]  not even John Q. Random is global.
                
+[22:22]  nor is John Q. Random born in 1942 in Argentina.
                
+[22:23]  well, it has been said that the naming system could have more than one flavor
                
+[22:23]  thats true 
                
+[22:23]  people could choose a trusted "registration authority" to pick unique names from
                
+[22:23]  absolutely.
                
+[22:24]  though there is the danger there
                
+[22:24]  The scheme I originally proposed allows for multiple certification authorities, as I recall.
                
+[22:24]  jrand0m: of course, it's the tradeoff between comfort and security
                
+[22:24]  i think someone should write up a quick "centrlized" dns system for the time being then worry about security
                
+[22:24]  jrand0m: :-)
                
+[22:24]  just to make testing easyer
                
+[22:25]  multiple CAs works more easily without the global naming
                
+[22:25]  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]  There isn't really any problem until a conflict occures right?
                
+[22:25]  FireRabbit> I have a strong feeling that what we start with will stay in place for 12+ months.
                
+[22:25]  correct baffled, in any of the plans
                
+[22:25]  baffled: That is the problem, yes.
                
+[22:25]  wiht> not if there are multiple CAs
                
+[22:25]  suppose
                
+[22:25]  eepsites will be a mess if there is local naming, links will not work
                
+[22:25]  so you only need an authority in the case of conflict resolution.
                
+[22:26]  yes they will wilde
                
+[22:26]  names to be shared and used by others should be fully qualified - self certified - names
                
+[22:26]  jrand0m: Could you give an example of a self-certified name?
                
+[22:27]  from my email -   http://i2pref/[base64 of the NameReference]
                
+[22:27]  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]  you link with the fully qualified name - which includes the actual Destination *in it*.
                
+[22:28]  (the NameReference structure from my email)
                
+[22:28]  so it's like base64 linking
                
+[22:28]  right human - it gets rid of that attack point
                
+[22:28]  So people will have to type many characters again? That seems self-defeating.
                
+[22:28] * madman2003 has quit IRC (EOF From client)
                
+[22:29]  no one types base64 names
                
+[22:29]  (well, maybe mihi does)
                
+[22:29]  <a href="http://i2pref/[base64 of the NameReference]">jrandom's page</a>
                
+[22:29]  Oh. That makes sense.
                
+[22:30] * mihi does not *type* anything he can copy&paste
                
+[22:30]  :)
                
+[22:30]  ok but basically it's long URLS
                
+[22:30]  within eepsites, yes
                
+[22:30] * dm has quit IRC (Ping timeout)
                
+[22:30]  k that was the question
                
+[22:30]  there are several other scenarios worth looking at though
                
+[22:31]  such as when people want to browse or search for new sites
                
+[22:31]  those are situations where having servers that contain a lot of name references is useful
                
+[22:31]  Could I propose the idea of a history server rather than an authority.
                
+[22:31]  history server?
                
+[22:32]  ah, so whoever was first "gets it"?
                
+[22:32]  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]  maybe an archive to see how a domain name changed during time?
                
+[22:32]  The conflict can then be resolved by the two parties providing they are both available.
                
+[22:33]  baffled: What if the new domain's operator is sleazy and continues to hold that already-taken domain name?
                
+[22:33]  If one party is not available the the conflict goes o the available party in some amount of time.
                
+[22:33]  of course it implies to give some trust to the server operator
                
+[22:33]  that's just authority but in another way
                
+[22:33]  right
                
+[22:34]  Any arbitrator is either going to act as an authority.
                
+[22:34]  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]  right, right
                
+[22:34]  I don't expect it will become a major problem.
                
+[22:34]  (but why do we need an arbitrator?  can't there be two johns in the world?)
                
+[22:35]  if i2p is used for commerce or other such activities, I expect the names to be heavily attacked
                
+[22:35]  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]  I vote for the cryptic nameref solution´
                
+[22:35]  Again, that would be fine, as long as _new_ users would understand the implications and which John they want to contact.
                
+[22:35]  (since someone would be able to hijack and get money, etc)
                
+[22:36]  right - its likely we're always going to bundle some name references with the software
                
+[22:36]  (ala the current hosts.txt)
                
+[22:36]  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]  why would domain names want to expire again?
                
+[22:37]  They're tired of life?
                
+[22:37]  oh, to replace the Destination included?
                
+[22:37]  heh
                
+[22:38]  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]  hmm, but without uniqueness, there really isnt such a thing as ownership
                
+[22:38]  its not scarce
                
+[22:38]  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]  so the nameref is protected by one key, the destination is another
                
+[22:39]  the nameref is signed by the destination's signing key
                
+[22:40]  you may want another key just for namerefs if possible
                
+[22:40]  hm, i understand and agree, but that'd mean Destination gets yet another 1024bit segment
                
+[22:40]  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]  (and Destination is used all over the place)
                
+[22:41]  hmm not sure I follow the compromised part?
                
+[22:42]  the destination privkey is on the machine all the time
                
+[22:42]  ah right right
                
+[22:42]  the nameref private key doesn't to be, they can be kept on paper in the wallet
                
+[22:43]  thats a good point.  perhaps the comment block could be used for that (containing a PGP signature surrounding the Destination's hash)?
                
+[22:43]  but that maybe overkill
                
+[22:43]  i just don't like keeping the most valuable keys on the machine if isn't necessary
                
+[22:44]  right - we need the Destination signing key and the destination decryption key, but nothing else, functionally.
                
+[22:44]  hmm
                
+[22:45]  perhaps the name reference could have a 1024bit public key on it as well
                
+[22:45]  and we'd use that to verify via DSA
                
+[22:45]  rather than the destination's public key
                
+[22:45]  yeah, that'd fly
                
+[22:45]  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]  lots of keys :) but extra security and flexibility
                
+[22:46]  right
                
+[22:46]  (though, c'mon, we know everyone is going to keep their key in the same dir)
                
+[22:46]  ((but maybe commerce shops wont))
                
+[22:47]  you can hand over a "domain" but not the destination, or change to someone elses destination
                
+[22:47]  well, ok.  i wish MrEcho and wiht were here
                
+[22:47]  right
                
+[22:48]  well, this is all fine and good, and I think it'll fly
                
+[22:48]  but it needs to get coded :)
                
+[22:49]  so, well, perhaps we'll have additional discussions about it later, but until that time, hosts.txt it is
                
+[22:49]  hire some indians
                
+[22:50] * jrand0m /dcc gets a grant to hire a team of 80 to work on i2p
                
+[22:51]  :)
                
+[22:51]  ok, do we have anything else for naming, or for the time being are we covered?
                
+[22:51]  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]  d'oh, wb wiht
                
+[22:52]  1, 2, 5 uh 3 sitr.
                
+[22:52]  I had trouble getting back on IIP network. I will read logs later.
                
+[22:53]  cool wiht, and we can continue later on the list, etc
                
+[22:54]  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]  (reference the wiki at http://wiki.invisiblenet.net/iip-wiki?MinWWW )
                
+[22:56]  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]  did the meeting already start?
                
+[22:57]  yeah, 56 mins ago
                
+[22:57] * jrand0m sends duck to the corner
                
+[22:57]  so I am right on time
                
+[22:57] * wilde has quit IRC (Ping timeout)
                
+[22:57]  heh
                
+[22:57]  No doubt about it, he's gotta get a new clock.
                
+[22:58]  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]  that'd increase the number of outproxies available, decreasing the load
                
+[22:59]  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]  or should we just have something like a small set list of outproxies (thats periodically updated)?
                
+[23:01]  (or is the idea not worth looking too much into?)
                
+[23:01] * wilde has joined #i2p
                
+[23:02]  (or i've timed out and no one can read anything i've said)
                
+[23:02]  jrand0m: can see
                
+[23:02]  'k coo'
                
+[23:02]  I'll need to understand it better but for now I have another appointment in ten minutes so I'll bbl.
                
+[23:02]  word, l8r
                
+[23:03]  yeah, there's still the absolutely key functionality of i2ptunnel to handle 8bit clean streams
                
+[23:03]  thats necessary for e.g. irc over i2p and such
                
+[23:03]  jrand0m: don't forget ss[lh]
                
+[23:04]  but for message oriented protocols, such as http, smtp, bittorrent, etc, i2cp may be more appropriate
                
+[23:04]  right, absolutely
                
+[23:04]  (well, more like 'telnet', since ssh over i2p is a bit of an overkill)
                
+[23:04]  ssh -X
                
+[23:05]  true
                
+[23:05]  (plus certs, etc)
                
+[23:05]  there is never too much crypto
                
+[23:05]  but if we're pulling web pages through squid in 5-10s, using i2cp would drop that to .5-2s
                
+[23:06]  (without any subsequent tuning of the network, and would reduce overal network load)
                
+[23:06]  how many man hours does it take to make i2cp?
                
+[23:07]  imho, i2cp has a fairly simple API, bundled into the java i2p SDK
                
+[23:07]  mihi can more fairly say how much effort it is to use / learn it
                
+[23:08] * wiht has quit IRC (Ping timeout)
                
+[23:08]  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]  we can obviously improve upon the sdk, i just based it off the JMS api
                
+[23:10]  (and i'd be more than willing to help out anyone who wanted to hack around with it to get familiar)
                
+[23:11]  ok, do we have anything else on the minwww/i2cp?
                
+[23:11]  if not, moving on to 4) i2p.net website
                
+[23:11]  (and there was much rejoicing)
                
+[23:11]  ok
                
+[23:12]  about search functionality
                
+[23:12]  wikipedia uses google for search functionality
                
+[23:12]  thats true. and we're already the #1 result for i2p :)
                
+[23:13]  so a nifty thing might not be needed for searching.
                
+[23:13]  duck: atm yes ;)
                
+[23:13]  I mean for internal searching
                
+[23:13]  #1 is www.crestron.com/company_info/i2p/ 
                
+[23:13]  ah yeah, i forgot to bribe the pigeons this week
                
+[23:14]  LeaseSet site:wiki.invisiblenet.net
                
+[23:14]  nice
                
+[23:14]  yeah, absolutely.
                
+[23:14]  drupal has internal search, and you can filter on content types
                
+[23:15]  it's also VERY google friendly with the clean urls, no index.php?Zillions of arguments
                
+[23:15]  everything looks like directories
                
+[23:16] * ion has joined #i2p
                
+[23:16]  ok I've played around with different CMS:s so far and Drupal is my current favourite
                
+[23:16]  I prefer Ian's home-baked solution
                
+[23:16]  :)
                
+[23:16]  what does it use for a backend?  mysql/bdb/txt/?
                
+[23:16]  it's used by http://kerneltrap.org/ http://www.debianplanet.org/ http://www.linuxgazette.com/
                
+[23:16]  for example
                
+[23:17]  it can take heavy loads
                
+[23:17]  their designs sucks though
                
+[23:17]  but a nice CSS stylesheet fixes that
                
+[23:17]  here some other somewhat better looking ones:
                
+[23:17]  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]  http://www.sudden-thoughts.com/
                
+[23:17]  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]  http://www.codemonkeyx.net/
                
+[23:18]  http://www.disguast.org/index.php
                
+[23:18]  http://trip.ee/
                
+[23:18]  http://www.blainepeterson.com/image
                
+[23:18]  .
                
+[23:19] * jrand0m gets the feeling wilde is a raving drupal fan :)
                
+[23:19]  I'm starting to become that yes, as I like the information management ideas behind it
                
+[23:19]  everything is a node
                
+[23:20]  great taxonomy system
                
+[23:20]  you can create vocabularies for Geographic location, content type, language, etc
                
+[23:20]  and create custom urls that filters on content those
                
+[23:21]  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]  and it's updated often and the changes are good
                
+[23:21]  in other words we are stupid that we dont have drupal already
                
+[23:21]  we have duck
                
+[23:21]  drupal.i2p.net
                
+[23:21]  :)
                
+[23:21]  you're so in the 90:s duck
                
+[23:22]  that is good
                
+[23:22]  the design sucks of course
                
+[23:22]  cause that design is so in the 80:s
                
+[23:22]  lol
                
+[23:22] * wilde mud wrestles with duck
                
+[23:22]  right, there are 3 different things that need to get worked out - the tech, the IA, and the graphic design
                
+[23:23]  you could try the user interface
                
+[23:23]  login: test pw: test
                
+[23:23]  warning: Bad arguments to implode() in /var/www/html/i2p/modules/project/issue.inc on line 360.
                
+[23:23]  user error: You have an error in your SQL syntax near ') AND (p.state = 1 OR p.state = 2) ' at line 1
                
+[23:23]  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]  search still doesn't work wilde, right?
                
+[23:24]  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]  oh nice1 duck
                
+[23:24]  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]  sucky
                
+[23:24]   AND () AND
                
+[23:24]  whoops, i had some problems with search i must admint
                
+[23:25]  .
                
+[23:25]  there is some full text indexing cron script not yet configured
                
+[23:25]  2 minutes and duck crashed my life work
                
+[23:25]  (!hi5 duck)
                
+[23:26]  but i do think its worth looking at
                
+[23:26]  what did you do duck?
                
+[23:26]  i don't know if we're at the point where we want to commit to some CMS yet
                
+[23:26]  no
                
+[23:26]  (s/some/some specific/)
                
+[23:27]  jrand0m did already make an overview of the requires features didnt he
                
+[23:27]  http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html
                
+[23:27]  so now all parties should come with proposals and the price
                
+[23:28]  ofcourse the winning solution will be paid in i2p stocks
                
+[23:28]  which, let me tell you, is quite valuable
                
+[23:28]  *cough*
                
+[23:29]  you'll get your own @i2p.net email
                
+[23:29]  and chicks will love you
                
+[23:29]  (or guys, whatever)
                
+[23:30]  we had some CMS options
                
+[23:30]  we should go for some CMS
                
+[23:30]  and wiki isn't really a long term solution
                
+[23:30]  yeah some listed in point 4 @ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html
                
+[23:30]  agreed, for the website itself
                
+[23:31]  a wiki based section of the site might be good though, perhaps for the user guide / hackers guides
                
+[23:31]  (but not for everything)
                
+[23:32]  what about the hosting?
                
+[23:32]  there's always the 53 entries at http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/Open_Source/
                
+[23:32]  it should survive a slashdot
                
+[23:32]  hosting?  
                
+[23:32]  ah, right.
                
+[23:33]  thats actually a really huge draw of plain HTML in and of itself
                
+[23:33]  (dirt easy to mirror)
                
+[23:33]  and on
                
+[23:33]  http://www.oscom.org/
                
+[23:33]  i2p.net is at a colo that is used by several large sites
                
+[23:34]  ah right
                
+[23:34] * jrand0m would love if people would keep at it and find the Right solution
                
+[23:35]  http://www.opencms.org/ is interesting
                
+[23:35]  but's maybe too corporate
                
+[23:35]  with workflows, projects, etc
                
+[23:35]  I really liked, used it for one project
                
+[23:36]  interesting
                
+[23:36]  but its java ;)
                
+[23:36]  hmm, and xml
                
+[23:36]  jsp templates etc
                
+[23:36]  tomcat
                
+[23:36]  (or jetty)
                
+[23:36]  ((or resin))
                
+[23:37]  (((lisp)))
                
+[23:37]  I would never use if for this project, it's really too heavy
                
+[23:37]  wilde> would you be willing to look over the main CMSes and map out pros and cons?
                
+[23:38]  i have :), and chose Drupal ;)
                
+[23:38] * jrand0m should have known
                
+[23:38]  I've tried about ten of the major ones
                
+[23:38]  for some earlier projects
                
+[23:38]  different CMS works for different projects
                
+[23:39]  so say drupal is used
                
+[23:39]  Zope and friends are nice too
                
+[23:39]  is the structure clear?
                
+[23:39]  is the next step doing the gui?
                
+[23:40]  it's really just a CSS template that's needed for the gui, some changes to the xtemplate to prettify things
                
+[23:41]  www.csszengarden.com could be an inspiration
                
+[23:41]  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]  basically I want to avoid dev blog entries pushing news & announcements off the main stage
                
+[23:42]  jrand0m: don't know, gonna check, blogs doesn't have to go front page, i configured it that way
                
+[23:42]  ah cool
                
+[23:42]  we can change to just stories go front page
                
+[23:42]  everything that is a node could be frontpage, polls, stories, book pages, articles etc,
                
+[23:43]  would it be possible to have stories at the top, with latest N blog entries below?
                
+[23:43] * jrand0m stops micromanaging
                
+[23:43]  blogs are linked to the bottom left right now,
                
+[23:44] * godmode0 has joined #i2p
                
+[23:44]  there are nice galleries as plugin, good for screenshots
                
+[23:44]  word
                
+[23:44]  the filestore plugin would be nice too
                
+[23:45]  and more cvs, developer plugins too
                
+[23:45]  and mailinglist
                
+[23:45]  I'm no CMS expert, and it sounds like you've done your homework and are enthusiastic about it
                
+[23:45]  w0ah nice
                
+[23:45]  jrand0m: i need people pulling the brake for me sometimes :)
                
+[23:46]  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]  anyone here now?
                
+[23:47]  no, I left
                
+[23:47] * jrand0m stares at the lurkers
                
+[23:47]  so what should the site communicate?
                
+[23:47]  http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html
                
+[23:47]  this is a bit broader, we have marketing and donations to think of
                
+[23:48]  (what duck said)
                
+[23:48]  yeah i've read that, but we are more people here :)
                
+[23:48]  :)
                
+[23:48]  but the puny humans dont matter!
                
+[23:48] * wilde attaches to the borg collective
                
+[23:49]  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]  ok; I am falling asleep
                
+[23:49]  enjoy
                
+[23:49]  heh cool duck, g'night
                
+[23:49]  wilde: cool work on the CMS stuff
                
+[23:49] * wilde remembers the thing about 80:s design, 5 months of work!
                
+[23:50]  well, good thing we have 2 months then ;)
                
+[23:50]  night duck
                
+[23:50]  oh yes, the design should BEG for peer reviews and useful comment
                
+[23:50] * ion has quit IRC (Ping timeout)
                
+[23:50]  agreed
                
+[23:50]  about the toopie
                
+[23:51]  i like 'im, he's humorous, simple, and topical
                
+[23:51]  doesn't toopie look a bit ... hmm... stupid 
                
+[23:51]  (and he can serve as an icon with nearly any purpose)
                
+[23:51] * ion has joined #i2p
                
+[23:51]  he squints
                
+[23:52]  heh i think we can wrestle up a top-left-logo-quality toopie
                
+[23:52]  there've been a lot of revs going around for different purposes
                
+[23:53]  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]  agreed
                
+[23:54]  ok maybe we should leave it there
                
+[23:54]  there's no rush, lots to digest and churn through
                
+[23:54]  but please it you find this new kickass CMS, scream out
                
+[23:54]  can we have this as background: http://www.artchive.com/artchive/B/bruegel/death.jpg
                
+[23:55]  but I agree with duck, nice work setting up a drupal to work off
                
+[23:55]  that is so going straight to my desktop
                
+[23:55]  wow I wonder what text over that would look like
                
+[23:55]  cool picture
                
+[23:55]  actually, on that note, 5) ???
                
+[23:56]  anyone have anything else to add?
                
+[23:56] * jrand0m prods the peanut gallery
                
+[23:56]  it's been very quiet in here today
                
+[23:56]  everyone comes here to listen to messiah Jrandom
                
+[23:57]  2h is a bit longish
                
+[23:57]  *ggg*
                
+[23:57] * jrand0m is just here for the beer
                
+[23:57]  maybe you could try 2 weekly meetings of 30 min each
                
+[23:57]  nah
                
+[23:57]  and then the layoffs at friday afternoon
                
+[23:57]  that's too often
                
+[23:58]  i do think 2h meetings are very excessive
                
+[23:58]  (unless they're specifically topical.  e.g. a meeting discussing the web page design, or some router functionality, etc)
                
+[23:58]  (hey look, we're meta)
                
+[23:59]  perhaps I should shut up more and limit it to 1h?
                
+[23:59]  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]  the mailinglist could be used more for discussions
                
+Session Time: Wed Feb 11 00:00:00 2004
                
+[00:00]  I think that the heavy email pre-logs are already good
                
+[00:01]  so maybe the weekly meetings turn more into "ok guys, whats up?  anyone have anything to discuss?"
                
+[00:01]  (but open ended meetings like that are a danger in and of themselves)
                
+[00:01] * godmode0 has joined #i2p
                
+[00:02]  ok, maybe we can move this meta to the list or to later
                
+[00:02]  we've already broken the 2h mark
                
+[00:02]  so...
                
+[00:02] * jrand0m winds up...
                
+[00:02]  :)
                
+[00:02] * jrand0m *baf*s the meeting closed
                
+
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/78.log b/i2p2www/meetings/78.log
new file mode 100644
index 00000000..83e4c0dc
--- /dev/null
+++ b/i2p2www/meetings/78.log
@@ -0,0 +1,290 @@
+{% 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)
                
+
+ baffled: we're experimenting a psychic communication towards jrand0m, to ask him to be here for the meeting
                
+ baffled: just focus your mind on him, and help us
                
+> Don't we have to hold hands or something like that?
                
+ 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.
                  
+
                
+?> human: doesn't he make up a pre meeting agenda, you can grab that and direct the meeting
                
+ DrWoo?: er... why me?
                
+Rain (Rain@anon.iip) has joined channel #i2p
                
+ DrWoo?: (i didn't see any meeting agenda, though)
                
+?> human: why not, you're sober
                
+ let's make an agenda ourselves
                
+?> yeah you guys know the general issues
                
+ there are many topics to discuss
                
+
                  
+
                •  human will direct the meeting in exchange of the sacrifice of the first daughter of every participant
                  
+
                
+ funding, strategy, marketing, website, recruiting more developers and powerusers, etc
                
+ wilde: i agree, we could informally talk about the recent history of I2P
                
+?> 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
                
+ back
                
+> you're the first to say anything your in charge.
                
+ who? me?
                
+jar (jar@anon.iip) has joined channel #i2p
                
+> quit looking surprised.
                
+?> you guys are funny :)
                
+> hey jar.
                
+ 'lo baffled :)
                
+ '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.
                
+ ok
                
+jrand0m (jrand0m@anon.iip) has joined channel #i2p
                
+ 1. Hello
                
+ 2. Status I2P
                
+ 3. How to help I2P Project
                
+ 4. Recruiting more developers
                
+ 5. Raising money (donations, selling t-shirts)
                
+ 6. General discussion
                
+ jrand0m: has appeared!!!
                
+ hey jrand0m!
                
+> I'll take a t-shirt.
                
+ our experiment succeeded!!!
                
+ shit thought I missed it :)
                
+
                  
+
                •  jrand0m leaves the floor to wilde ;)
                  
+
                
+> You better look back through the log jrandom.
                
+ ok boss you could modify the agenda as you like
                
+ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html
                
+
                  
+
                •  jrand0m just posted
                  
+
                
+> Are the t-shirts good?
                
+ they had better be
                
+
                  
+
                •  jrand0m apologizes for being late, been avoiding looking at the monitor today (killer headache)
                  
+
                
+> No apology necessary or expected.
                
+ np, we prepared an emergency plan
                
+ everyone taking a job at McDonalds? and hiring indian programmers for the money
                
+Signoff: ion (Ping timeout)
                
+ hah nice
                
+ perhaps we can jump into that agenda, or are we on 1, 2, 3, 6?
                
+ 0.
                
+ 1. Hello
                
+ Hello I2P
                
+ hi
                
+ hi
                
+ hi
                
+ ah, i made it
                
+ last hellos? going once, going twice...
                
+ hi
                
+> Which agenda the one you posted or the oone wild posted?
                
+ perhaps I can help out with agenda 2) status
                
+ 2. Status I2P
                
+ the router, as is, is nonfunctional
                
+ so how are we post-testnet?
                
+> can we cote on that?
                
+ post testnet, yes, but I introduced two bugs in the process
                
+> vote.
                
+ vote on whether its nonfunctional?
                
+> Right.
                
+
                  
+
                •  jrand0m wonders if we vote hard enough it'll be functional again
                  
+
                
+ its dead for me
                
+> oh, nevermind.
                
+> well, we held hands and you appeared.
                
+ 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!
                
+ 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
                
+ so there's a short i2p vacation
                
+ none, I use that build on xp
                
+ the bug is programmer error, probably a trivial one too
                
+ (but quite fatal)
                
+ right wilde
                
+ but after that, I've been making a bunch of progress on the docs for 0.2.5 and 0.3
                
+ so I don't think they'll be a full two weeks out
                
+ but we'll cross that bridge when we come to it.
                
+ nice, any application improvments anyone?
                
+ 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.
                
+ 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
                
+ 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?
                
+ I dont know, I would like once 0.2.4.x is out and usable that we can use both IRC and eepsites
                
+ that depends on the computer
                
+ so what's best for now? eepsites or irc?
                
+
                  
+
                •  jrand0m wants both, and we will have both functional in the mid and long run
                  
+
                
+ anyway, we can see as 0.2.4.x comes out.  perhaps both will be fine again.
                
+ yeah but what's most useful for debugging? continous connections or sporadic ones?
                
+ both ;)
                
+ lighweight irc, or eep graphics?
                
+ i2p needs to support long term streaming connections and short term bursty ones
                
+ what about heavy long downloads?
                
+ right, long term streaming connections
                
+ (though I do think filesharing over i2p would best be served with i2psnark via messages, ala udp)
                
+ the question really is: you suggested narrowing the test scope, was that to IRC or EEP?
                
+ (or something else)
                
+ 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
                
+ ok, that's probably wise
                
+ anyone have any dev status for client apps?
                
+ so the focus should be on services that can us some statistics, like the irc scripts
                
+ that is definitely key.
                
+Newsbyte (~fredisdea@anon.iip) has joined channel #i2p
                
+ woah
                
+ hi Newsbyte
                
+ ah, jran
                
+
                  
+
                •  wilde looks at the clock and at Newsbyte, late arrival, that will cost you an apple
                  
+
                
+ huh?
                
+ I never come here
                
+ also, the echo server and client app is great at gathering stats, and doesn't have any irc-specific dependencies. 
                
+ nothing
                
+ besides, what's an I2P meeting without nop? ;-)
                
+?> wilde: heh somehow I dont think hes here for the meeting :)
                
+ would an eepsite monitoring tool be useful?
                
+ no nop, no meeting
                
+
                  
+
                •  Newsbyte can summarise
                  
+
                
+ jrand0m: is there something else you'd like to have statistics in the network?
                
+ human> certainly - perhaps some way to do periodic pings of eepsites, maybe keeping track of changes even?
                
+ jrand0m: keeping track of what changes?
                
+ 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
                
+ content on the page changing 
                
+ yes, and use more then one server
                
+ a kb/s meter, I2P Pirate Radio someone?
                
+ hmm?  right, when the net is up we usually have between 4-10 servers
                
+ jrand0m: it's doable but... how would you use the content change information?
                
+ i ran a shoutcast stream for a while
                
+ 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])
                
+ nice kaji
                
+ yeah, aum's streams were up periodically as well
                
+ jrand0m: oh, ok, now i understand
                
+ jrand0m: a chargen service? ;)
                
+ bye everyone, good luck with i2p
                
+ so throuhput is one stat that would be interesting/useful
                
+ later madman2003
                
+ 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.
                
+ 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)
                
+ hey
                
+ is the network unstable?
                
+ I just couldn't get back on
                
+Signoff: thecrypto (Leaving)
                
+ yea
                
+ its a bit... ugh.
                
+ recently.
                
+ what happened to the meeting?
                
+ probably got decimated
                
+ ok lucky what was the last thing you saw from the meeting? (msg me)
                
+ <wilde> cya madman2003
                
+ <-- madman2003 has quit (( www.nnscript.de :: NoNameScript? 3.8 :: www.XLhost.de ))
                
+ <jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler)
                
+Galaxy (yogi@anon.iip) has joined channel #i2p
                
+ ok that's where it ended for me too
                
+ me2
                
+Signoff: Sonax (EOF From client)
                
+Sonax (~Sonax@anon.iip) has joined channel #i2p
                
+ the meeting got nuked
                
+kaji has changed the topic on channel #i2p to nuked
                
+ ping?
                
+ pong!
                
+ ok
                
+ ithough it crashed again
                
+ yep :(
                
+Signoff: wilde ()
                
+ so... meeting?
                
+ ending brutaly ...
                
+ more signs of jrandom, it seems it's all for the moment
                
+ next move on 0.2.4.2 in few days ....
                
+ (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
                
+ 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
                
+ hmm, what happened to the meeting?
                
+
                  
+
                •  mihi has an idea
                  
+
                
+ ;)
                
+Mode change "+o mihi" on channel #i2p by Trent@anon.iip
                
+Mode change "-o duck" on channel #i2p by 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)
                
+ mihi, we lall got kicked for the meoeting
                
+hacktic4ever (~hacktic4e@anon.iip) has joined channel #i2p
                
+Signoff: hacktic4ever ()
                
+ ok, nite
                
+ hello
                
+Signoff: sheer (EOF From client)
                
+Signoff: mihi (let's have more luck next week...)
                
+ did I miss anything?
                
+Signoff: jnk (Ping timeout)
                
+{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/79.log b/i2p2www/meetings/79.log
new file mode 100644
index 00000000..640658db
--- /dev/null
+++ b/i2p2www/meetings/79.log
@@ -0,0 +1,187 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 79{% endblock %}
+{% block content %}
                Tuesday, Feb 24, 2004 22:00:00 CET
                
+
                
+[22:00]  0) hi
                
+[22:00]  1) 0.2.4.2/0.2.5
                
+[22:00]  2) docs
                
+[22:00]  3) ???
                
+[22:00]  0) hi
                
+[22:00]  hi
                
+[22:00] * jrand0m waves to the newly-restarted iip-ircd :)
                
+[22:01]  (and, uh, to you :)
                
+[22:01]  weekly status notes (that we're running off) located at http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html
                
+[22:01]  (and posted to the mailing list, obviously)
                
+[22:01]  1) 0.2.4.2/0.2.5
                
+[22:02]  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]  the key functionality that will provide will be increased reliability and functional anonymity
                
+[22:04]  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]  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]  (bugfixes underway)
                
+[22:07]  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]  heya mihi
                
+[22:07] * protocol has quit IRC (Ping timeout)
                
+[22:07]  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]  hm
                
+[22:08]  maybe we could talk about it after the meeting...
                
+[22:08]  in reliability terms, latency, CPU, bandwidth?
                
+[22:08] * protocol has joined #i2p
                
+[22:08]  hi jrand0m, hi all
                
+[22:08]  jrand0m: i can't reach any eepsite or I2P service (with few temporary exceptions)
                
+[22:08] * mihi seconds human
                
+[22:09]  most eepsites are down - duck, baffled, madman2003 are the most consistently up lately
                
+[22:09]  jrand0m: i can't reach them, nor irc.*.i2p
                
+[22:09]  squid I use constantly for all my web browsing - are you unable to use that?
                
+[22:09]  jrand0m: nope
                
+[22:09]  hm
                
+[22:10]  well an uptime of about 8 hours daily for my i2p site
                
+[22:10]  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]  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]  me too
                
+[22:10]  jrand0m: just to point out that some problems seems to exist (that weren't shown before)
                
+[22:10]  mine should be up now
                
+[22:11]  what destination?
                
+[22:11]  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]  heh
                
+[22:12]  (well, it got the Thank you for your understanding. sentence correct at least...)
                
+[22:12]  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]  0.2.4.0 was shit, as was 0.2.4.1
                
+[22:12] * wilde has joined #i2p
                
+[22:13]  jrand0m: i know, and it worries me...
                
+[22:13]  hey i2p
                
+[22:13]  heya wilde
                
+[22:13]  one thing i noticed is that tunnels tend to get unstable more often
                
+[22:13]  jrand0m: i didn't change too much with 0.2.4.2 (at least for me)
                
+[22:13]  jrand0m: s/ i / it /
                
+[22:14]  madman2003> thats easily due to routers going on and offline (which will be a big problem until 0.3)
                
+[22:14]  hmm ok
                
+[22:14]  jrand0m: does that mean we should avoid running transients for now?
                
+[22:15] * mihi has quit IRC (Ping timeout)
                
+[22:15]  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]  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]  but as long as routers generally stay up or generally down, they're fine
                
+[22:17]  (just not up 10 minutes, down 10 minutes, up 30, down 30, etc)
                
+[22:17]  i do have one request: an option for the router(and tunnels) to be reastablished
                
+[22:17]  i2p is an equal router opertunity organization?
                
+[22:17]  heh baffled
                
+[22:18]  madman2003> router to be reestablished?  your router is shutting down still?
                
+[22:18]  i mean reconnecting everything
                
+[22:18]  sort of a warm restart of the router
                
+[22:18]  without pissing of the other routers
                
+[22:18]  (i have to restart router and tunnels a lot)
                
+[22:18]  you can safely restart your client apps (e.g. i2ptunnel eepproxy, etc) without touching the rotuer
                
+[22:19]  you should /never/ need to restart your router.
                
+[22:19]  (almost all config settings are updated dynamically)
                
+[22:19] * Trix has joined #i2p
                
+[22:19]  hi Trix
                
+[22:19]  hi
                
+[22:19]  usually restarting the tunnels does the trick
                
+[22:21]  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]  (in fact, restarting tunnels can cause temporary problems, depending on the type of tunnel)
                
+[22:22]  sometimes i just don't know if i'm causing problems or if someone else is
                
+[22:22]  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]  patience fixes more of the current i2p bugs than restarts do ;)
                
+[22:24]  but we'll have another series of bugfix releases after 0.2.5
                
+[22:24]  (like testnet, except without the restrictions on the userbase)
                
+[22:25]  (and, as always, whenever things break, logs are appreciated :)
                
+[22:25]  anyway, moving on to 2) docs
                
+[22:26]  as posted in http://i2p.net/pipermail/i2p/2004-February/000147.html there've been some new overview docs
                
+[22:27]  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]  i read them and i hope you were right about the possibilty to safely reduce the amount of crypto
                
+[22:29]  layers of crypto or # of bits?
                
+[22:29]  I'm not convinced that the crypto is the bottleneck, but its a possibility
                
+[22:30]  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]  the problem is finding your way
                
+[22:30]  hmm?
                
+[22:31]  a static path is usually well found
                
+[22:31]  a more dynamic one is more difficult to establish
                
+[22:32]  (i'm talking about the inability to properly handle routers going offline)
                
+[22:32]  ah, thought you were talking about crypto
                
+[22:32]  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]  maybe an idea to have backup routes ready
                
+[22:34]  tunnel redundancy
                
+[22:34]  right, thats 0.2.5 - multiple leases
                
+[22:35]  (lease == declaration that a destination can be reached through a specific tunnel)
                
+[22:35]  i'll be awaiting that :)
                
+[22:36]  w3rd
                
+[22:37]  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]  ok, moving on at a rapid pace to 3) ???
                
+[22:38]  anything people want to bring up and discuss?
                
+[22:39]  potatoes are fucking cheap yet potatoe chips are expensive, what's up with that?
                
+[22:39]  :)
                
+[22:39]  its a conspiracy!
                
+[22:40] * DrWoo thinks jrand0m has the answer for most anything :)
                
+[22:40]  of course, you can blame anything on conspiracies.
                
+[22:40]  ok
                
+[22:40]  Stego ?
                
+[22:40] * human accepts suggestions about how to expose I2CP-like message-oriented functionality to non-java apps
                
+[22:41]  how I2P will implement Stego so an ordinary portscan will reveal nothing 
                
+[22:41]  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]  well, for one, PHTTP.
                
+[22:42]  openvpn does look very interesting - I hadn't realized tun/tap had windows ports
                
+[22:42]  a simple message oriented socket bridge for I2CP should be very easy
                
+[22:43]  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]  okay as usual I have another appointment in 15m so I'll catch up later.
                
+[22:43]  right, if we wanted to integrate with a webserver/etc to silent bob, we could
                
+[22:43]  cool, later baffled
                
+[22:44]  (but silent bob doesnt prevent portscan detection, it just makes it look like another service)
                
+[22:44]  I rather not have random people or ISP:s portscan me and find ports open
                
+[22:44]  ok
                
+[22:44]  jrand0m: ok, i'll work on it when I2P will work again on my PC :-)
                
+[22:44]  UDP would work as well
                
+[22:44]  :) human
                
+[22:45] * kaji has joined #i2p
                
+[22:46]  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]  is there a way of hiding an open port from java program, without messing with the OS or firewall
                
+[22:46]  w00t!
                
+[22:47]  you mean to have a listening TCP socket that can't be portscanned?  no, not directly from Java.
                
+[22:47]  ok
                
+[22:48]  (i dont even know how to do that in other langs)
                
+[22:48]  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]  that would be a little C program filtering and forwarding to another port maybe
                
+[22:49] * kaji_ has joined #i2p
                
+[22:49]  if it accepts TCP connections, its already too late, if I understand your concern correctly.
                
+[22:49]  how do you telnet?
                
+[22:49]  finaly
                
+[22:50]  that took forever, iip usability sucks dick atm
                
+[22:50] * kaji has quit IRC (Ping timeout)
                
+[22:51]  if you are concerned about open ports, you could use rTCP / PHTTP / whatever couldnt you?
                
+[22:51]  damn...  hey, jr, are those new docs accessable from the main i2p page?
                
+[22:51]  Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p"
                
+[22:51]  no Janonymous, just from the links on that email
                
+[22:51]  Janonymous: then telnet localhost 12221
                
+[22:51]  duck> right
                
+[22:52]  k
                
+[22:52]  (ofcourse whatever can be a silentbob/stealth/stego transport)
                
+[22:52]  human> Message send failed after 61226ms with 391 bytes
                
+[22:53]  jrand0m: and it means that...?
                
+[22:53]  that means I cant reach your echo
                
+[22:53]  -nogui is depricated :)
                
+[22:53]  can you reach duck.i2p?
                
+[22:54]  scary, i googled for rtcp: http://dret.net/glossary/rtcp
                
+[22:54]  right, rtcp is taken :/
                
+[22:54]  jrand0m: i'm trying, but i can't reach duck.i2p since a looong time ago...
                
+[22:54]  wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP
                
+[22:54]  "Wilde's WWW Online Glossary"
                
+[22:55]  hehe oh yeah :)
                
+[22:55]  human> thats a definite Bad Thing, as its up almost always - could you bounce me your log-*.txt?
                
+[22:56]  Started on:  Tue Feb 24 10:21:22 GMT 2004
                
+[22:56]  Version: Router: 0.2.4.2 / SDK: 0.2.4.2
                
+[22:56]  Bandwidth used: 56096295 bytes sent, 34308394 bytes received (avg 1.44KBps sent 0.88KBps received)
                
+[22:56]  jrand0m: ok, logs coming on meshmx
                
+[22:56]  gracias
                
+[22:56]  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/i2p2www/meetings/8.log b/i2p2www/meetings/8.log
new file mode 100644
index 00000000..cece81c3
--- /dev/null
+++ b/i2p2www/meetings/8.log
@@ -0,0 +1,149 @@
+{% 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/i2p2www/meetings/80.log b/i2p2www/meetings/80.log
new file mode 100644
index 00000000..3e3cb91c
--- /dev/null
+++ b/i2p2www/meetings/80.log
@@ -0,0 +1,358 @@
+{% 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/i2p2www/meetings/81.log b/i2p2www/meetings/81.log
new file mode 100644
index 00000000..2a32609b
--- /dev/null
+++ b/i2p2www/meetings/81.log
@@ -0,0 +1,405 @@
+{% 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/i2p2www/meetings/82.log b/i2p2www/meetings/82.log
new file mode 100644
index 00000000..2646ab08
--- /dev/null
+++ b/i2p2www/meetings/82.log
@@ -0,0 +1,470 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 82{% endblock %}
+{% block content %}
                Tuesday, Mar 23, 2004 13:00:00 PST
                
+
                
+[22:01:22]  agenda:
                
+[22:01:22]  0) Hi
                
+[22:01:22]  1) Network status
                
+[22:01:28]  2) 0.3.1 plan
                
+[22:01:28]  3) Web architecture
                
+[22:01:28]  4) Administravia
                
+[22:01:34]  5) ???
                
+[22:01:38]  0) hi
                
+[22:01:39]  of yourse
                
+[22:01:43]  Oh, cool, the meeting. :)
                
+[22:01:51]  hi, welcome to the weekly dev meeting, number $something
                
+[22:01:56]  Hi.
                
+[22:02:02]  weekly status notes up at http://i2p.net/pipermail/i2p/2004-March/000180.html
                
+[22:02:09] * mihi has joined #i2p
                
+[22:02:13]  howdy
                
+[22:02:32]  we'll see if we can avoid a 2 hour session today ;)
                
+[22:02:39]  ok, jumping to 1) network status
                
+[22:02:43]  :P
                
+[22:02:56]  we got 0.3.0 out on sunday, and its generally functional
                
+[22:03:12]  yes it is:)
                
+[22:03:23]  * jrandom waves from i2p#i2p to prove it ;)
                
+[22:03:43]  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]  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]  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]  (basically it visualizes the result of the 0.3 peer profiling and selection process)
                
+[22:05:50]  <duck> nice!
                
+[22:06:22]  yeah, its nice to see the visual feedback on the algorithms, rather than manually going through the networkDb
                
+[22:06:37]  <Masterboy> there's a need of cpu usage decreasing..
                
+[22:06:38]  :)
                
+[22:06:48] * jrand0m gives the eepSiteAppOfTheWeek award to duck for dot.png
                
+[22:06:54]  Yeah, I wonder what would we be doing without duck?
                
+[22:07:08]  <duck> maybe we can make an audio version too
                
+[22:07:17]  haha
                
+[22:07:20]  :)
                
+[22:07:22]  heheh
                
+[22:07:34]  or a smell-one
                
+[22:07:47]  Yeah, and stream it over jnon's icecast every hour.
                
+[22:07:51]  how do I understand the speed column in #transport?
                
+[22:08:00]  I mean peer profiles
                
+[22:08:25]  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]  ok :)
                
+[22:09:15]  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]  the network has also grown to a steady 18-22 routers, which is a good size for the moment
                
+[22:10:31]  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]  re
                
+[22:10:45]  wb KyroxX
                
+[22:11:03]  ok, that leads us into 2) 0.3.1 plan
                
+[22:11:16]  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]  cool no_dammagE, thats fine
                
+[22:11:33] * fR has quit IRC (Ping timeout)
                
+[22:12:01]  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]  roadmap hasn't yet been updated, but things are pretty much the same
                
+[22:12:45] * fR has joined #i2p
                
+[22:13:17]  Are you going to release 0.3.0.1?
                
+[22:13:18]  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]  perhaps, though currently the roadmap lists 0.3.1 as next week
                
+[22:13:54]  sunday, even.
                
+[22:14:01]  <baffled> I knew you was in collusion with somebody.
                
+[22:14:02]  so i'm not sure
                
+[22:14:03] * Rom|Away|3h has quit IRC (Ping timeout)
                
+[22:14:04]  how can i limit the cpu usageof my router? why not make : "low" - "normal" - "high" - so you could choose?
                
+[22:14:10]  heh baff
                
+[22:14:11]  why is that critical?:
                
+[22:14:11]  21:55:36.249 CRIT  [I2CP Reader ] et.invisiblenet.i2p.util.Clock: Updating clock
                
+[22:14:12]   offset to 105791ms from 0ms
                
+[22:14:16] * Romster has joined #i2p
                
+[22:14:24] * jar has quit IRC (Ping timeout)
                
+[22:14:38]  Masterboy> the code to work along those lines is planned for the 1.0rc1 release
                
+[22:14:43]  (router throttling)
                
+[22:14:48] * KyroxX has joined #i2p
                
+[22:14:50]  we've got some basics, but its not ready yet.
                
+[22:15:08]  re
                
+[22:15:13]  no_dammagE> because it should only occur at most once - if you see it happening a lot, its an issue
                
+[22:15:14]  oki
                
+[22:15:21]  (a critical issue)
                
+[22:15:48]  any other questions / concerns on the 0.3.1 release?
                
+[22:15:55]  then it should be debug the first time and then crit...
                
+[22:16:06]  you're right
                
+[22:16:09]  whats the topic?
                
+[22:16:17]  jrand0m: Err.. How can this occur on I2P? Closing Link: [unknown@192.168.0.2] (Ping timeout)
                
+[22:16:31]  KyroxX> the weekly dev meeting, item 2) 2) 0.3.1 plan
                
+[22:16:35]  Ah, never mind.
                
+[22:16:40]  ughabugha> ircd patch
                
+[22:16:49]  ah
                
+[22:17:02]  <duck> my ircd is running on nsa.localdomain
                
+[22:17:06]  hmm
                
+[22:17:08]  <duck> which has 192.168.0.2 as IP
                
+[22:17:12]  ah
                
+[22:17:30] * Romster has quit IRC (Ping timeout)
                
+[22:17:32]  ok, moving on to 3) Web architecture
                
+[22:17:49] * ion has quit IRC (Ping timeout)
                
+[22:17:58]  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]  how can i make an account on drupal.i2p.net?
                
+[22:18:15] * mihi is too stupid for that...
                
+[22:18:16]  wilde> can you add one for mihi?
                
+[22:18:31]  (there's no way to register normally)
                
+[22:18:35]  jrand0m: you could simply say no, then i know i can stop trying ;)
                
+[22:18:42]  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]  i'd like one too if its ok :)
                
+[22:21:05]  <jmand> /ping jmand
                
+[22:21:12]  ok, back to the web arch stuff
                
+[22:22:06]  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]  mihi brought up some good points that I hadn't been looking at, some valuable features that we'll certainly want
                
+[22:23:03]  jrand0m: Are you talking about the separation of Squid and I2P web?
                
+[22:23:11]  Or something deeper?
                
+[22:23:24]  the 'HTTPTunnel vs. {privoxy,muffin} + HTTPClient' thread
                
+[22:23:30]  (http://i2p.dnsalias.net/pipermail/i2p/2004-March/)
                
+[22:23:48]  the seperation of squid and eepsites, as well as the seperation of browser proxies vs. (essentially) cgis
                
+[22:23:49]  Right.
                
+[22:24:00]  and, of course, the filters
                
+[22:24:48]  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]  I tend to agree with human's latest post
                
+[22:25:13]  plus, with mihi's new streaming I2PTunnel api, its fairly easy to build off
                
+[22:26:42]  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]  mihi> any thoughts?
                
+[22:28:26]  ok or anyone else?  :)
                
+[22:28:47]  http://i2p.i2p/ looks ugly to me
                
+[22:28:55]  but even that could be survived
                
+[22:28:59]  i2p.i2p?
                
+[22:29:05]  ?
                
+[22:29:27] * ion has quit IRC (Ping timeout)
                
+[22:29:28]  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]  I think I did see i2p.i2p mentioned somewhere as replacement for the current http://i2p/keybla
                
+[22:30:35]  yours was the latest human
                
+[22:30:54]  oh, right, yeah on irc last night i think jnano was discussing it
                
+[22:30:55]  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]  duck: you have good eyes. i did this to prevent netbios lookups in Opera.
                
+[22:31:21]  ah yeah "code/apps/i2ptunnel/java/src/net/invisiblenet/i2p/httptunnel/handler/RootHandler.java"
                
+[22:31:21]  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]  it is a shame that some browsers need such workarounds
                
+[22:31:55]  wew
                
+[22:32:15]  human mentioned something about socks4 not requiring that?
                
+[22:32:15] * KyroxX is now known as wbk
                
+[22:32:23]  socks4a
                
+[22:32:29]  ah ok
                
+[22:32:39]  (socks4 does DNS)
                
+[22:32:49]  do all browsers support socks4a?
                
+[22:32:59]  jrand0m: socks4 is Evil(TM), but socks4a and socks5 delegate name resolution to the server
                
+[22:33:00]  s/socks4 does DNS/with socks4 the client does DNS/
                
+[22:33:06]  some browsers don't even support socks proxies...
                
+[22:33:08]  jrand0m: yes, AFAIK
                
+[22:33:27]  right, plus the kiosk issue mihi, certainly
                
+[22:33:52]  it could be an alternative
                
+[22:34:04]  httpclient + socksclient + etc
                
+[22:34:29]  jrand0m, mihi: programs that don's support socks could be tsocks'ed
                
+[22:34:53]  human> unless its a kiosk, where people can't run apps
                
+[22:35:00]  (or change settings, etc)
                
+[22:35:19]  jrand0m: yes, of course socks tunnels aren't suited for these tasks
                
+[22:35:31]  (human: though then they'd still call gethostbyname)
                
+[22:35:39]  would they duck?
                
+[22:35:55]  duck: no, tsocks even inhibits them and forwards them to the proxy server
                
+[22:36:16]  duck: (dunno what happens in the windows world, though)
                
+[22:36:30]  they BSOD
                
+[22:36:32]  er..
                
+[22:36:57]  (not according to /usr/share/doc/tor-0.0.2_pre27/CLIENTS.gz)
                
+[22:36:57]  heheheh
                
+[22:37:07]  heh duck
                
+[22:37:18]  socks tunnels, however, will not replace www proxies :-)
                
+[22:37:24]  (( </tortechnotalk> ))
                
+[22:38:25]  mihi> whats your take on the highest priority use case for httptunnel?  if there's something we can help with?
                
+[22:38:31]  http://home.arcor.de/mschierlm/test/nosocks.png (which browser is that?)
                
+[22:38:31]  it's just an add-on to do some neat stuff with tunnelling, chaining etc.
                
+[22:38:31]  I2P is the ircd of iip right?
                
+[22:38:31]  anyway, all solutions need a clientside filter
                
+[22:38:47]  duck: yes, according to man 8 tsocks :-)
                
+[22:39:14]  dunno mihi, opera?
                
+[22:39:19] * fR has joined #i2p
                
+[22:39:19]  wbk: no private msg
                
+[22:39:19]  wbk> no
                
+[22:39:30]  jrand0m: make it work perfectly with post requests && make it do everything httpclient does
                
+[22:39:45]  word
                
+[22:40:08]  mihi: That's Opera.
                
+[22:40:14]  mihi: dunno, but as i wrote above: socks tunnels, however, will not replace www proxies :-)
                
+[22:40:18]  If you ment that as a question. :)
                
+[22:41:13]  ok, cool, anyone have anything else to bring up for web stuff, or are we ready for 4) Administravia?
                
+[22:42:23]  ok, just some notes -
                
+[22:42:24] * Rom|Away|3h is now known as Rom|Away|4h
                
+[22:42:51]  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]  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]  I was looking at the license policy...
                
+[22:44:35]  AFAIK Cryptix == BSD
                
+[22:44:43]  right
                
+[22:44:52]  (but with Cryptix team as copyrightor instead of regents of massachusets or something)
                
+[22:44:52]  but, strictly, its the Cryptix license ;)
                
+[22:45:05]  what is MIT?
                
+[22:45:13]  mit is == bsd 2 clause
                
+[22:45:16]  == x
                
+[22:45:19]  what code is MIT I mean
                
+[22:45:25]  nothing
                
+[22:45:29]  == x < 4.4.0
                
+[22:45:36]  i just list it as "if you want to use MIT, great"
                
+[22:45:42]  right human :/
                
+[22:45:49]  the amount of licenses is already quite a few
                
+[22:45:56]  I was wondering if that could be restricted
                
+[22:46:07]  for example changing the GPL code into BSD or even pubdomain
                
+[22:46:31]  was wondering what the author(s) of that part(s) did think about that
                
+[22:46:32]  <no_dammagE> so, chatroom, ill go sleep now. Good code @ Devteam, good time of day to all others. Till tomorrow.
                
+[22:46:40]  bye no_dammagE 
                
+[22:46:41]  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]  later no_dammagE
                
+[22:46:55]  cu
                
+[22:46:58] * no_dammagE has quit IRC
                
+[22:47:19] * jar_backup has joined #i2p
                
+[22:47:50]  but, of course, GPL is fine, t'is mihi's right :)
                
+[22:48:06]  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]  Well, whatever the license is, it should be GPL-compatible.
                
+[22:48:36]  (Ie, it shouldn't be more restrictive than GPL)
                
+[22:48:42]  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]  mihi> the streaming and naming lib are funcional without dependency upon i2ptunnel itself, right?
                
+[22:49:14]  Yeah, reference implementation shouldn't be GPL.
                
+[22:49:25]  they should be. if not, it's a bug.
                
+[22:49:30]  BSD 2 clause on those would be fantastic
                
+[22:49:40]  yup!
                
+[22:49:45]  you can have naming lib public domain if you include it into core ;)
                
+[22:50:02] * ion has joined #i2p
                
+[22:50:03]  absolutely, I'd love to include them in the core sdk
                
+[22:50:42]  them? ;) (including streaming lib into core would be a bad idea imho, since it is too less open for other impls)
                
+[22:51:09]  well, the sdk impl itself makes some nontrivial design assumptions - its just a ref impl
                
+[22:51:22]  i'd love if people could take i2p.jar and write a streaming app
                
+[22:51:28]  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]  human: that brings up the "have to hire a lawyer before I can use it"-problem
                
+[22:52:01]  (perhaps we can split the current i2ptunnel into i2ptunnel and i2pstreaming, if you'd prefer?)
                
+[22:52:32]  jrand0m: that would be okay for me. just change the ant task to build 2 jars ;)
                
+[22:52:35]  duck: i suggest to add the exception just to avoid it
                
+[22:52:39]  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]  and better make i2pministreaming instead of i2pstreaming
                
+[22:53:41]  mihistreaming :)
                
+[22:53:48]  (note the n in mi4ni)
                
+[22:54:02]  duck: that was exactly what i thought ;)
                
+[22:54:03]  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]  hehe
                
+[22:54:10]  i2pmihistreaming is good too :)
                
+[22:55:25]  ok
                
+[22:55:40]  next week I'll try to convince you all to move totally to publicdomain
                
+[22:55:45]  but this is enough for now :)
                
+[22:55:48]  :)
                
+[22:55:50]  hehe
                
+[22:56:06]  mihi*=5
                
+[22:56:14]  jrandom**=5;
                
+[22:56:21]  wbk did just offer to help with the webdesign
                
+[22:56:36]  oh awesome duck
                
+[22:56:45]  well, briefly before we jump to 5)
                
+[22:56:58]  do any devs have any qualms with the /policy/ in http://drupal.i2p.net/node/view/85?
                
+[22:57:05]  so I did do a bureaucratic team-table lookup and delegate him to wilde
                
+[22:57:25]  before jumping... what about the GPL + exception suggestion?
                
+[22:57:29]  aka "implicitly under $primaryLicense" or "explicitly under $alternate"?
                
+[22:57:47]  duck++ :)
                
+[22:58:02]  human: I'm adding it atm
                
+[22:58:07] * human agrees with jrand0m's policy
                
+[22:58:25]  what about copyright owner
                
+[22:58:28]  mihi: ok, thanks
                
+[22:58:30] * duck did see human adding some new files as GPL
                
+[22:58:36]  and putting mihi's name on that
                
+[22:58:45]  Err... I don't think drupal likes passwords which are 32 characters long.
                
+[22:58:51]  duck: i just cut'n'pasted existing files
                
+[22:59:18]  ok, but what if we have 50 ppl working on it and each putting their own name on the copyrights
                
+[22:59:20]  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]  duck: (well, even if i'm forgetting to put copyrights into files...)
                
+[22:59:25]  then you cant switch license at a later point
                
+[22:59:29]  thats fine duck, in my opinion
                
+[22:59:53]  e.g. thecrypto should be the copyright owner of his encryption and SHA routines
                
+[23:00:03]  (i was still observing jrand0m's policy to stick with module licenses, btw)
                
+[23:00:05]  though since he's released it under BSD 2 clause, we will use it
                
+[23:00:38]  oh, maybe i'm missing the point - you want to make sure everyone puts their own name on it?
                
+[23:00:44]  no
                
+[23:00:49] * jrand0m assigns copyright to richard nixon
                
+[23:00:56]  heheh
                
+[23:01:34]  btw: in my country, "public domain" is just another kind of copyright
                
+[23:01:46]  hmm.  i2p doesn't have any legal entity to receive copyright (and *never* will)
                
+[23:02:02]  i.e. you (the author) distribute your works without any restrictions
                
+[23:02:18]  right, a lot of countries have fucked up IP laws
                
+[23:02:59]  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]  that i think is a good idea
                
+[23:03:47]  jrand0m: (it's still happening, of course, but i think it should be a requirement :-)
                
+[23:03:55]  thats why i included the "jrandom wrote this in $year and releases it into the public domain" ;)
                
+[23:04:08]  jrand0m: yeah :-)
                
+[23:04:27]  so i'm missing ducks point
                
+[23:04:37]  and that thing abouth eating children
                
+[23:04:37]  I lost it too
                
+[23:04:43]  :)
                
+[23:04:44]  heheh
                
+[23:04:47]  lets forget it
                
+[23:04:58] * lucky has joined #i2p
                
+[23:05:13]  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]  (even if they dont copyright it?)
                
+[23:05:24]  hi
                
+[23:05:25]  :D
                
+[23:05:39]  s/suggestion/<i>suggestion</i>/
                
+[23:05:42]  hi lucky
                
+[23:05:50]  [damn i borked my regexp]
                
+[23:05:57]  want me to PGP sign a statement?
                
+[23:06:09]  i'm going to, yes
                
+[23:06:30]  once the policy is ready and revised, i'll be contacting all prior committers for PGP/GPG auth 
                
+[23:06:33]  jrand0m: yes (in my country it's impossible to refuse copyright, it's seen as an inalienable author's right)
                
+[23:06:52]  yes, your country is fucked
                
+[23:06:53]  NEXT
                
+[23:06:56]  (oops)
                
+[23:06:58]  :)
                
+[23:07:19]  human, what country?
                
+[23:07:39]  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]  fidd: somewhere near Europe :-)
                
+[23:07:54]  heh, ok
                
+[23:07:59]  human: you can later say you don't want the copyright
                
+[23:08:03]  and put it in the public domain.
                
+[23:08:19]  human> with the "implicit release under $primaryLicense", that should address the issue though, right?
                
+[23:08:24]  human means that that doesnt mean anything in $fuckedcountry
                
+[23:08:42]  human> since that implicitly means commit == release as $primaryLicense
                
+[23:08:50]  duck: yup, exactly
                
+[23:09:07]  (so no comment == implicit license by $author, per `cvs log`)
                
+[23:09:28]  (ah, legalese in code ;)
                
+[23:09:36]  jrand0m: well, i'm not a lawyer... but i think it should work
                
+[23:09:43] * kaji has joined #i2p
                
+[23:09:48]  * wilde agrees with the last proposal
                
+[23:09:57]  w3rd.
                
+[23:10:05]  ok, i'll see if i can get the eff to review
                
+[23:10:19]  moving on to 5) ???
                
+[23:10:21]  jrand0m: maybe it's better to have some sort of agreement when ppl are given CVS access
                
+[23:10:46]  <wilde> when will we see, net.i2p.legal.LicenseManager?
                
+[23:10:47]  agreed human> explicit agreement with $policy will be a prerequisit for getting commit privs
                
+[23:10:50]  heh
                
+[23:10:52]  jrand0m: (for example, GPG signing the your policy, and hosting it on the I2P site?)
                
+[23:11:00]  heheh
                
+[23:11:04]  reasonable enough human.
                
+[23:11:13]  jrand0m prefers PGP8 ;)
                
+[23:11:23]  damn straight.  pgpdisk++
                
+[23:12:06] * wilde has joined #i2p
                
+[23:12:14]  hi wilde
                
+[23:12:36]  ok, does anyone have anything they want to bring up for 5) ??? 
                
+[23:13:27]  just an invitation one more time for people to visit drupal and comment, modify, etc
                
+[23:13:37]  word, yes, thats a good point
                
+[23:13:41]  http://drupal.i2p.net/
                
+[23:13:41]  so we can have good docs for 1.0
                
+[23:13:41]  human, jrand0m: is the license in CVS okay now? ;)
                
+[23:13:55]  on http://drupal.i2p.net/team there are a lot of [vacant] roles.  volunteer!
                
+[23:14:02]  i cant get drupal thru squuid :/
                
+[23:14:17] * mihi volunteers for QS guy cuz of echo server ;)
                
+[23:14:29]  s/QS/QA/
                
+[23:14:33]  woot!
                
+[23:15:01]  unit tests for echo server
                
+[23:15:12]  wilde rofl no
                
+[23:15:17]  mihi: maybe you should s/XXXX/mihi/ in the GPL exception :-)
                
+[23:15:20]  jrand0m: Heh, what do you mean by stress testing? :)
                
+[23:15:34]  echo server is system test for i2p ;)
                
+[23:15:38]  human: oops ;)
                
+[23:15:56] * Rom|Away|4h has quit IRC (Ping timeout)
                
+[23:16:08]  ughabugha> it means you smash (aka use) the router and have patience with me to debug it, submitting reports and logs
                
+[23:16:35]  <wilde> thus stress testing poor jrandom...
                
+[23:16:40]  jrand0m: Oh, okay. :)
                
+[23:16:44]  wow, mihi is fast
                
+[23:16:47]  Hehe.
                
+[23:17:30] * Romster has joined #i2p
                
+[23:17:40]  duck: editor still open and the CVS comment was fast to type as well ;)
                
+[23:17:40]  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]  (or you can just add that copyright text into the source)
                
+[23:19:24]  hmm, what does idented mean? (yes to your second subclause)
                
+[23:19:42]  means you've proven to trent that you're mihi :)
                
+[23:19:50]  authenticated
                
+[23:19:54]  ok, identified ;)
                
+[23:20:01]  w3rd
                
+[23:20:06]  let's try identicated
                
+[23:20:14]  it looked to me like "indented" and i thought that my white space was incorrect ;)
                
+[23:20:20]  hehe
                
+[23:20:43]  * wilde thinks launches word for find yet another synonym
                
+[23:21:07]  authentified?
                
+[23:21:22]  anyway...
                
+[23:21:28]  ok, r0x0r, anyone have anything else to bring up?
                
+[23:21:44]  <wilde> yeah
                
+[23:21:50]  <wilde> eep naming 
                
+[23:22:00]  heh you don't like my pronounciation?
                
+[23:22:12] * kaji has quit IRC (Ping timeout)
                
+[23:22:14]  <wilde> of i2p -> eep
                
+[23:22:14] * Rom|Away|4h has quit IRC (Ping timeout)
                
+[23:22:21]  oh
                
+[23:22:30]  you want to rename the whole project "eep" ?
                
+[23:22:39]  lol
                
+[23:22:48]  * wilde mutters
                
+[23:22:48]  envisible enternet project ;)
                
+[23:23:08]  envisible
                
+[23:23:09]  extrordinarily excellent people
                
+[23:23:15]  connotates something for me.
                
+[23:23:46]  even easier publishing ;)
                
+[23:23:51]  ooOOoo
                
+[23:23:51]  As in its going to be visable, therefore possible. envision maybe?
                
+[23:23:53]  Come on, stop picking on wilde. :)
                
+[23:23:54]  <wilde> seriously, do you like the name then it's fun?
                
+[23:24:06]  <wilde> fine i mean, getting tired
                
+[23:24:44]  <wilde> new users will not have it easy
                
+[23:25:03]  oh, i'm not a marketeer.  we went under "eep" because its all i could think of
                
+[23:25:23]  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]  what should we call websites that people both host and access through i2p?
                
+[23:25:38]  hehe
                
+[23:25:42]  i2psites?
                
+[23:25:44]  <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]  we got one?
                
+[23:26:38]  no
                
+[23:26:43]  ;)
                
+[23:26:52]  heh
                
+[23:26:55]  anyway... you can change all the naming, as long as the "Shitlist" keeps its current name
                
+[23:26:56]  * wilde rushes to the browser
                
+[23:27:01]  heh
                
+[23:27:06]  lol human
                
+[23:27:07]  oh, shitlist is going to stay, for sure ;)
                
+[23:27:21]  <wilde> i take the role, it should be i2p sites, i resign
                
+[23:27:21]  I bet that shitlist is a proper english word
                
+[23:27:24]  i mean, "blacklist" just isn't as fun
                
+[23:27:26]  hah wilde
                
+[23:27:29]  jrand0m: cool!
                
+[23:27:56]  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]  ok, i don't really care either way, i2psite is fine, eepsite is fine
                
+[23:28:09]  I mean we have enough time to consider it on the mailing list until 1.0.
                
+[23:28:09]  jrand0m: and the elephants on the moon have to stay too ;)
                
+[23:28:22]  so is kaji.i2p up for anyone. i kinda just started it up without testing anything and left it running
                
+[23:28:31]  human> i think we don't have to worry about that one ;)
                
+[23:28:35]  kaji: It worked for me.
                
+[23:28:48]  we have to keep moving the easter eggs mihi :)
                
+[23:28:48]  <wilde> i don't really care, eepsite is just as boring as i2psite
                
+[23:29:05]  we can consider them synonyms
                
+[23:29:23]  <wilde> that the worst decision ;)
                
+[23:29:44]  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]  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]  <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]  lol
                
+[23:32:37]  lets quickly baff the meeting closed
                
+[23:32:40]  oh, too late
                
+[23:32:42]  heh
                
+[23:32:48]  heheh
                
+[23:32:56]  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/i2p2www/meetings/9.log b/i2p2www/meetings/9.log
new file mode 100644
index 00000000..db4e13ef
--- /dev/null
+++ b/i2p2www/meetings/9.log
@@ -0,0 +1,98 @@
+{% 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/i2p2www/meetings/90.log b/i2p2www/meetings/90.log
new file mode 100644
index 00000000..e31c593d
--- /dev/null
+++ b/i2p2www/meetings/90.log
@@ -0,0 +1,203 @@
+{% 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/i2p2www/meetings/92.log b/i2p2www/meetings/92.log
new file mode 100644
index 00000000..c6011847
--- /dev/null
+++ b/i2p2www/meetings/92.log
@@ -0,0 +1,341 @@
+{% 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/i2p2www/meetings/93.log b/i2p2www/meetings/93.log
new file mode 100644
index 00000000..215a8f9a
--- /dev/null
+++ b/i2p2www/meetings/93.log
@@ -0,0 +1,280 @@
+{% extends "_layout.html" %}
+{% block title %}I2P Development Meeting 93{% endblock %}
+{% block content %}
                
+21:02:08  Tue Jun  8 21:02:08 UTC 2004
                
+21:02:21  meeting time
                
+21:02:33  writeup is at http://dev.i2p.net/pipermail/i2p/2004-June/000268.html
                
+21:02:39  but I did make a mistake in the numbering
                
+21:02:45  so the first item 5 will be skipped
                
+21:02:53  yay!
                
+21:03:03  * duck puts some ice in his beer
                
+21:03:14  * mihi 'd rename first #5 to #4 ;)
                
+21:03:27  nah, let's just have two item 4's next week ;-)
                
+21:03:37  * duck renames 'hypercubus' to 'mihi'
                
+21:03:48  yay!
                
+21:03:49  ok
                
+21:03:53  * 1) libsam
                
+21:04:02  is there a Nightblade in the channel?
                
+21:04:39  (idle     : 0 days 0 hours 0 mins 58 secs)
                
+21:05:03  ;-)
                
+21:05:53  * duck reclaims the microphone
                
+21:06:15  Nightblade wrote a SAM lib for C / C++
                
+21:06:23  it compiles for me.. but that is all I can say :)
                
+21:06:37  no test cases? ;)
                
+21:07:06  if there are any rFfreebsd users Nightblade might be interested in you
                
+21:07:08  The strstr calls really annoyed me in the code. ;)
                
+21:07:27  duck: What's a rFfreebsd?
                
+21:07:42  how I did type freebsd
                
+21:08:00  rm -rF freebsd?
                
+21:08:29  Too bad -F doesn't work with rm.
                
+21:08:30  ugha_node: its bsd licensed; so fix it
                
+21:08:41  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  duck: I might. :)
                
+21:08:50  (damn BSD hippies)
                
+21:09:09  oh, nice and short frank
                
+21:09:17  mo libsam comments?
                
+21:09:49  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  but since his email was a week old be might have found something
                
+21:10:17  fvw: ?
                
+21:10:24  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  uhm, to where? ;-)
                
+21:10:54  2) browse i2p and normal web with one browser
                
+21:10:57  fresh install, haven't yet told my zsh not to hup stuff in the bacgrkground. 
                
+                
                
+
+21:11:09  hypercubus: I'm on the public mailinglist user list I think. fvw.i2p@var.cx
                
+21:12:11  there was some stuff about adding all TLDs to your brower proxy ignore list
                
+21:12:23  does that require discussion? I think it was pretty much handled on the 
                
+                mailinglist.
                
+21:12:24  I think it is a dirty hack
                
+21:12:36  yes, that was mentioned. Welcome back.
                
+21:12:47  fvw: I didnt read the thread :)
                
+21:13:12  okay, if you dont want to discuss it, move to #3
                
+21:13:19  * 3) chat channel
                
+21:13:23  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  #i2p-chat is an alternative channel here for offtopic chat and light support
                
+21:14:08  I dont know who did regg it
                
+21:14:12  i did
                
+21:14:17  so better be careful :)
                
+21:14:22  ehm, there is no #4, just two #5's :)
                
+21:14:33  i'll be lucky if i can remember the password when i need it ;-)
                
+21:14:33  [22:27] -ChanServ-      Channel: #i2p-chat
                
+21:14:33  [22:27] -ChanServ-      Contact: hypercubus <<ONLINE >>
                
+
+21:14:33  [22:27] -ChanServ-    Alternate: cervantes <<ONLINE >>
                
+21:14:37  [22:27] -ChanServ-   Registered: 4 days (0h 2m 41s) ago
                
+21:15:12  i gave a few trusted peeps op powers for whenver i'm not around and 
                
+                       there's trouble
                
+21:15:24  sounds good
                
+21:15:39  it might be a bit overkill
                
+21:15:51  you never know on IRC ;-)
                
+21:15:55  but after this protogirl did join here I thought it would be good to clean up 
                
+                 this chan
                
+21:16:03  heh
                
+21:16:27  we'll need it for sure sometime in the next few months anyhow
                
+21:16:34  jups
                
+21:16:48  and then the freenode ppl will kick us out 
                
+21:16:55  ;-)
                
+21:17:13  they dont like anything that isnt written in their kampf
                
+21:17:16  err
                
+21:17:44  * duck moves to $nextitem and triggers mihi's breakpoint
                
+21:17:47  i figured tying the new channel in with support would legitimize it for 
                
+                       freenode
                
+21:18:47  hypercubus: you might be surprised
                
+21:19:04  *cough* i admittedly didn't read all the policies...
                
+21:19:24  it is russian roullete
                
+21:19:39  hmm, didn't think it would be quite that dire
                
+21:19:52  * duck is being negative
                
+21:19:54  well i'll look into what we can do
                
+21:20:09  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  fvw: they focus on development channels
                
+21:20:35  ?
                
+21:20:53  duck: the breakpoint triggers on /^4).*/
                
+21:21:01  mihi: but there is no #4
                
+21:21:06  so? i2p is soo alpha that right now even support is development.
                
+21:21:11  (and no, you may not quote me on that)
                
+21:21:36  fvw: you might not be familiar with the types of discussion that did happen 
                
+                 on IIP
                
+21:21:38  yeah but we have *2* channels for it
                
+21:21:45  and which will likely happen in #i2p channels
                
+21:22:04  I am pretty sure that freenode does not appreciate it.
                
+21:22:10  i'm here now
                
+21:22:49  we'll donate a margarita machine to them or something
                
+21:22:49  duck: what do you refer to? the floods? or #cl? or what?
                
+21:23:08  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  all kinds of non political correct talk
                
+21:23:36  there's margarita machines? Ooh, me want.
                
+21:23:54  oh well
                
+21:24:38  shall we revisit 2)?
                
+21:24:58  hypercubus: what do you have to add about the browser proxy?
                
+21:25:18  oops, number 1... since nightblade just graced us with his presence ;-)
                
+21:25:33  Nightblade: we took the freedom to 'discuss' libsam
                
+21:25:42  Ok, i'll say a few lines
                
+21:25:48  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  Nightblade: fvw told us that he might be able to help with some freebsd 
                
+                 testing
                
+21:26:20  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  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  in the process i found a couple minor bugs in libsam
                
+21:27:18  which i will post a new version of sometime in the future
                
+21:27:51  Nightblade: Could you please remove those 'strstr' calls from libsam? :)
                
+21:27:52  the test case is: try to compile it and report the errors to me
                
+21:28:01  what is wrong with strstr
                
+21:28:21  It's not meant to be used instead of strcmp.
                
+21:28:38  oh yeah, also I am going to port libsam to windows, but that is not in 
                
+                       any near future
                
+21:29:07  is there anything wrong with the way i am using it, besides aesthetics?
                
+21:29:15  you can send me changes or tell me what you'd rather do
                
+21:29:19  that just seemed the easiest way
                
+21:29:21  Nightblade: I didn't notice any.
                
+21:29:32  strcmp is more efficient than strstr ofcourse.
                
+21:29:36  But I just skimmed through it.
                
+21:30:20  fvw: You can occasionally exploit stuff which uses strstr instead of 
                
+                      strcmp, but that's not the case.
                
+21:31:22  yeah now i see some places where i can change it
                
+21:31:28  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  i don't remember why i did it that way
                
+21:31:57  fvw: I agree.
                
+21:32:27  oh now i remember why
                
+21:32:40  it is a lazy way of not having to figure the length for strncmp
                
+21:32:49  heh
                
+21:32:52  Nightblade: Heheh.
                
+21:33:01  use min(strlen(foo), sizeof(*foo))
                
+21:33:04  shall the spanking commence?
                
+21:33:15  I thought the oral sex came first? *ducks*
                
+21:33:32  right, next point I think. Hypercube had a comment about proxying?
                
+21:33:38  heh
                
+21:33:54  bring it on!
                
+21:34:03  i will make the changes for the next version - change some of them at 
                
+                       least
                
+21:34:25  ok, well this had been discussed briefly in channel a few weeks back, 
                
+                       but i think it bears revisiting
                
+21:34:48  * Sugadude volunteers to perform the oral sex.
                
+21:34:59  rather than adding TLD's to your browser's block list, or using the 
                
+                       proxy script, there's a third way
                
+21:35:29  which shouldn't have the same drawbacks as the other two approaches 
                
+                       anonymity-wise
                
+21:36:17  which I'll tell you for the cheap cheap price of $29.99? Spill it already!
                
+21:36:27  and that would be to have the eeproxy re-write incoming html pages to 
                
+                       embed the page in a frameset... 
                
+21:36:58  the main frame would contain the requested HTTP content, the other 
                
+                       frame would serve as a control bar
                
+21:37:13  and would allow you to turn on/off proxying at will
                
+21:37:40  and will also alert you, perhaps via colored borders or some other kind 
                
+                       of alert, that you're browsing non-anonymously
                
+21:37:54  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  or that a link in an eepsite page leads to the RealWeb(tm)
                
+21:38:04  cool! make it!
                
+21:38:16  you'll still have to do something fproxy-like, or make something 
                
+                non-browser-controlled for switching.
                
+21:38:29  fvw: Right.
                
+21:39:10  that's why i'm throwing this out here again, perhaps someone might have
                
+                        some ideas about how to secure this
                
+21:39:31  but imo this is something that will be sorely needed for most i2p end 
                
+                       usrers
                
+21:39:33  *users
                
+21:40:04  because the TLD/proxy script/dedicated browser approaches are too much 
                
+                       to ask of your general net user
                
+21:40:29  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  What is the netDb anyway?
                
+21:40:59  Sonium: database of known routers
                
+21:41:10  fproxy is too cumbersome for most users
                
+21:41:32  doesn't such a database compromise annonymity?
                
+21:41:39  imo it's part of the reason freenet never caught on in the non-dev 
                
+                       community
                
+21:41:41  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  Sonium: No, 'bad guys' could collect that information manually anyway.
                
+21:42:21  but if NetDb is down i2p is down, right?
                
+21:42:29  hypercubus: Not really, I think the fact that it hasn't worked at all since 
                
+                early 0.5 is more to blame for that. 
                
+
+21:42:44  Sonium: you can have more than one netdb (anyone can run one)
                
+21:42:58  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  *avg. joe
                
+21:43:22  fvw: Err.. Every router has its own netDb.
                
+21:43:42  ok. I am about to pass out. be sure to *baff* the meeting closed after you 
                
+                 are done
                
+21:43:52  I2P has no central dependencies anymore.
                
+21:44:07  ok, well i just wanted to get this idea formally in the logs ;-)
                
+21:44:30  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  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  no :)
                
+21:45:21  is duck a network device? ;)
                
+21:45:25  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  in swedish
                
+21:45:52  ugha_node: what bounty?
                
+21:46:00  okay, then on to 5), rant-a-rama? ;-)
                
+21:46:13  mihi: http://www.i2p.net/node/view/224
                
+21:46:27  * duck eats some of fvw's chocolate
                
+21:47:16  ugha_node: definitely no; sorry
                
+21:47:36  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  but it would imho be easier to fix that one instead of fixing mine...
                
+21:49:21  Heh.
                
+21:49:42  so modest
                
+21:49:46  since it already has some (broken) "reordering" support in it
                
+21:50:49  is there a way to ask deer how many people are on the i2p-#i2p channel?
                
+21:51:01  no
                
+21:51:08  nope, but i can add that to bogobot
                
+21:51:08  :/
                
+21:51:11  !list
                
+21:51:13  <duck> 10 ppl
                
+21:51:13  after i finish the installer ;-)
                
+21:51:24  !list
                
+21:51:32  o_O
                
+21:51:35  Sonium ;)
                
+21:51:38  This is not an fserv channel!
                
+21:51:39  that was a trick!
                
+21:51:40  :)
                
+21:51:41  should be !who
                
+21:51:44  <duck> ant duck identiguy Pseudonym ugha2p bogobot hirvox jrandom Sugadude 
                
+                 unknown
                
+21:51:48  oop missed the meeting
                
+21:51:57  !list
                
+21:52:01  !who
                
+21:52:11  <duck> !who-your-mom
                
+21:52:17  !who !has !the !list ?
                
+21:52:21  !yesletsallspamthechannelwithinoperativecommands
                
+21:52:33  !ban fvw!*@*
                
+21:52:42  !ban *!*@*
                
+21:52:50  i sense a gavel coming down
                
+21:52:51  sounds like a good time to close it down
                
+21:52:55  btw, you should also implement an !8 command like chanserv has
                
+21:52:59  right, now we have that settled, let's clo.. yes. that.
                
+21:53:00  * hypercubus is psychic
                
+21:53:05  *BAFF*
                
+21:53:11  !baff
                
+21:53:12  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/i2p2www/meetings/95.log b/i2p2www/meetings/95.log
new file mode 100644
index 00000000..3f07bbeb
--- /dev/null
+++ b/i2p2www/meetings/95.log
@@ -0,0 +1,287 @@
+{% 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/i2p2www/meetings/99.log b/i2p2www/meetings/99.log
new file mode 100644
index 00000000..24d48f39
--- /dev/null
+++ b/i2p2www/meetings/99.log
@@ -0,0 +1,203 @@
+{% 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/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

From da424479f734e47e359f1530e58a8b832bb71c32 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Wed, 12 Sep 2012 22:59:02 +0000
Subject: [PATCH 32/75] Cleanup after merge

---
 {wblog => i2p2www/pages/blog}/entry.html |  0
 wblog/index.html                         | 10 ----------
 2 files changed, 10 deletions(-)
 rename {wblog => i2p2www/pages/blog}/entry.html (100%)
 delete mode 100644 wblog/index.html

diff --git a/wblog/entry.html b/i2p2www/pages/blog/entry.html
similarity index 100%
rename from wblog/entry.html
rename to i2p2www/pages/blog/entry.html
diff --git a/wblog/index.html b/wblog/index.html
deleted file mode 100644
index da883323..00000000
--- a/wblog/index.html
+++ /dev/null
@@ -1,10 +0,0 @@
-{% extends "global/layout.html" %}
-{% block title %}Blog Index{% endblock %}
-{% block content %}
-
                Some descriptive text.
                
-
                  
-{% for entry in entries -%}
-  
                • {{ entry }}
                  • 
-{%- endfor %}
-
                
-{% endblock %}

From 51f3228d40de47cb248c82b8590d641fb620a9c3 Mon Sep 17 00:00:00 2001
From: str4d 
Date: Thu, 13 Sep 2012 02:52:36 +0000
Subject: [PATCH 33/75] Finished migration of meeting logs

---
 i2p2www/meetings/1.log   |    9 -
 i2p2www/meetings/1.rst   |   10 +
 i2p2www/meetings/10.log  |    9 -
 i2p2www/meetings/10.rst  |   10 +
 i2p2www/meetings/100.log |  384 ++++----
 i2p2www/meetings/100.rst |   10 +
 i2p2www/meetings/101.log |  436 +++++----
 i2p2www/meetings/101.rst |   10 +
 i2p2www/meetings/102.log |  234 +++--
 i2p2www/meetings/102.rst |   10 +
 i2p2www/meetings/103.log |  428 +++++----
 i2p2www/meetings/103.rst |   10 +
 i2p2www/meetings/104.log |  838 +++++++++---------
 i2p2www/meetings/104.rst |   10 +
 i2p2www/meetings/105.log |  444 +++++-----
 i2p2www/meetings/105.rst |   10 +
 i2p2www/meetings/106.log |  946 ++++++++++----------
 i2p2www/meetings/106.rst |   10 +
 i2p2www/meetings/107.log |  994 +++++++++++----------
 i2p2www/meetings/107.rst |   10 +
 i2p2www/meetings/108.log |   74 +-
 i2p2www/meetings/108.rst |   10 +
 i2p2www/meetings/109.log |  232 +++--
 i2p2www/meetings/109.rst |   10 +
 i2p2www/meetings/11.log  |    9 -
 i2p2www/meetings/11.rst  |   10 +
 i2p2www/meetings/110.log |  366 ++++----
 i2p2www/meetings/110.rst |   10 +
 i2p2www/meetings/111.log |  396 ++++-----
 i2p2www/meetings/111.rst |   10 +
 i2p2www/meetings/112.log |  538 ++++++-----
 i2p2www/meetings/112.rst |   10 +
 i2p2www/meetings/113.log |  540 ++++++-----
 i2p2www/meetings/113.rst |   10 +
 i2p2www/meetings/114.log |  802 +++++++++--------
 i2p2www/meetings/114.rst |   10 +
 i2p2www/meetings/115.log | 1040 +++++++++++-----------
 i2p2www/meetings/115.rst |   10 +
 i2p2www/meetings/116.log |  360 ++++----
 i2p2www/meetings/116.rst |   10 +
 i2p2www/meetings/117.log |  134 ++-
 i2p2www/meetings/117.rst |   10 +
 i2p2www/meetings/118.log |  642 +++++++-------
 i2p2www/meetings/118.rst |   10 +
 i2p2www/meetings/119.log |  342 ++++---
 i2p2www/meetings/119.rst |   10 +
 i2p2www/meetings/12.log  |   17 +-
 i2p2www/meetings/12.rst  |   10 +
 i2p2www/meetings/120.log |  974 ++++++++++----------
 i2p2www/meetings/120.rst |   10 +
 i2p2www/meetings/121.log |  652 +++++++-------
 i2p2www/meetings/121.rst |   10 +
 i2p2www/meetings/122.log |  396 ++++-----
 i2p2www/meetings/122.rst |   10 +
 i2p2www/meetings/123.log |  314 ++++---
 i2p2www/meetings/123.rst |   10 +
 i2p2www/meetings/124.log |  762 ++++++++--------
 i2p2www/meetings/124.rst |   10 +
 i2p2www/meetings/125.log |  562 ++++++------
 i2p2www/meetings/125.rst |   10 +
 i2p2www/meetings/126.log |  350 ++++----
 i2p2www/meetings/126.rst |   10 +
 i2p2www/meetings/127.log |  312 ++++---
 i2p2www/meetings/127.rst |   10 +
 i2p2www/meetings/128.log |  576 ++++++------
 i2p2www/meetings/128.rst |   10 +
 i2p2www/meetings/129.log |  500 ++++++-----
 i2p2www/meetings/129.rst |   10 +
 i2p2www/meetings/130.log |  570 ++++++------
 i2p2www/meetings/130.rst |   10 +
 i2p2www/meetings/131.log |  738 ++++++++--------
 i2p2www/meetings/131.rst |   10 +
 i2p2www/meetings/132.log |  724 ++++++++-------
 i2p2www/meetings/132.rst |   10 +
 i2p2www/meetings/133.log |  640 +++++++-------
 i2p2www/meetings/133.rst |   10 +
 i2p2www/meetings/134.log |  348 ++++----
 i2p2www/meetings/134.rst |   10 +
 i2p2www/meetings/135.log |  244 +++--
 i2p2www/meetings/135.rst |   10 +
 i2p2www/meetings/136.log |  200 ++---
 i2p2www/meetings/136.rst |   10 +
 i2p2www/meetings/137.log |  566 ++++++------
 i2p2www/meetings/137.rst |   10 +
 i2p2www/meetings/138.log |  206 +++--
 i2p2www/meetings/138.rst |   10 +
 i2p2www/meetings/139.log |  122 ++-
 i2p2www/meetings/139.rst |   10 +
 i2p2www/meetings/140.log |  392 ++++----
 i2p2www/meetings/140.rst |   10 +
 i2p2www/meetings/141.log |  264 +++---
 i2p2www/meetings/141.rst |   10 +
 i2p2www/meetings/142.log |  182 ++--
 i2p2www/meetings/142.rst |   10 +
 i2p2www/meetings/143.log |  106 ++-
 i2p2www/meetings/143.rst |   10 +
 i2p2www/meetings/144.log |  292 +++---
 i2p2www/meetings/144.rst |   10 +
 i2p2www/meetings/145.log |  262 +++---
 i2p2www/meetings/145.rst |   10 +
 i2p2www/meetings/146.log |  430 +++++----
 i2p2www/meetings/146.rst |   10 +
 i2p2www/meetings/147.log |   88 +-
 i2p2www/meetings/147.rst |   10 +
 i2p2www/meetings/148.log |  200 ++---
 i2p2www/meetings/148.rst |   10 +
 i2p2www/meetings/149.log |  510 ++++++-----
 i2p2www/meetings/149.rst |   10 +
 i2p2www/meetings/15.log  |   19 +-
 i2p2www/meetings/15.rst  |   10 +
 i2p2www/meetings/150.log |  290 +++---
 i2p2www/meetings/150.rst |   10 +
 i2p2www/meetings/151.log |  474 +++++-----
 i2p2www/meetings/151.rst |   10 +
 i2p2www/meetings/152.log |  546 ++++++------
 i2p2www/meetings/152.rst |   10 +
 i2p2www/meetings/153.log |  886 +++++++++----------
 i2p2www/meetings/153.rst |   10 +
 i2p2www/meetings/154.log |  358 ++++----
 i2p2www/meetings/154.rst |   10 +
 i2p2www/meetings/155.log |  126 ++-
 i2p2www/meetings/155.rst |   10 +
 i2p2www/meetings/156.log |  696 ++++++++-------
 i2p2www/meetings/156.rst |   10 +
 i2p2www/meetings/157.log |  282 +++---
 i2p2www/meetings/157.rst |   10 +
 i2p2www/meetings/158.log |  450 +++++-----
 i2p2www/meetings/158.rst |   10 +
 i2p2www/meetings/159.log |  526 ++++++-----
 i2p2www/meetings/159.rst |   10 +
 i2p2www/meetings/160.log |  104 +--
 i2p2www/meetings/160.rst |   10 +
 i2p2www/meetings/161.log |  238 +++--
 i2p2www/meetings/161.rst |   10 +
 i2p2www/meetings/162.log |  180 ++--
 i2p2www/meetings/162.rst |   10 +
 i2p2www/meetings/163.log |  346 ++++----
 i2p2www/meetings/163.rst |   10 +
 i2p2www/meetings/164.log |  528 ++++++-----
 i2p2www/meetings/164.rst |   10 +
 i2p2www/meetings/165.log |  222 +++--
 i2p2www/meetings/165.rst |   10 +
 i2p2www/meetings/166.log |  278 +++---
 i2p2www/meetings/166.rst |   10 +
 i2p2www/meetings/167.log |  296 +++----
 i2p2www/meetings/167.rst |   10 +
 i2p2www/meetings/168.log |  142 ++-
 i2p2www/meetings/168.rst |   10 +
 i2p2www/meetings/170.log |  238 +++--
 i2p2www/meetings/170.rst |   10 +
 i2p2www/meetings/171.log |  150 ++--
 i2p2www/meetings/171.rst |   10 +
 i2p2www/meetings/172.log |  124 ++-
 i2p2www/meetings/172.rst |   10 +
 i2p2www/meetings/173.log |  238 +++--
 i2p2www/meetings/173.rst |   10 +
 i2p2www/meetings/174.log |  150 ++--
 i2p2www/meetings/174.rst |   10 +
 i2p2www/meetings/175.log |  258 +++---
 i2p2www/meetings/175.rst |   10 +
 i2p2www/meetings/176.log |  354 ++++----
 i2p2www/meetings/176.rst |   10 +
 i2p2www/meetings/177.log |  302 ++++---
 i2p2www/meetings/177.rst |   10 +
 i2p2www/meetings/178.log |   76 +-
 i2p2www/meetings/178.rst |   10 +
 i2p2www/meetings/179.log |  128 ++-
 i2p2www/meetings/179.rst |   10 +
 i2p2www/meetings/18.log  |   17 +-
 i2p2www/meetings/18.rst  |   10 +
 i2p2www/meetings/180.log |   22 +-
 i2p2www/meetings/180.rst |   10 +
 i2p2www/meetings/181.log |  110 ++-
 i2p2www/meetings/181.rst |   10 +
 i2p2www/meetings/182.log |  120 ++-
 i2p2www/meetings/182.rst |   10 +
 i2p2www/meetings/183.log |  376 ++++----
 i2p2www/meetings/183.rst |   10 +
 i2p2www/meetings/184.log |  530 ++++++-----
 i2p2www/meetings/184.rst |   10 +
 i2p2www/meetings/185.log |  164 ++--
 i2p2www/meetings/185.rst |   10 +
 i2p2www/meetings/186.log |  200 ++---
 i2p2www/meetings/186.rst |   10 +
 i2p2www/meetings/187.log |  146 ++-
 i2p2www/meetings/187.rst |   10 +
 i2p2www/meetings/188.log |  180 ++--
 i2p2www/meetings/188.rst |   10 +
 i2p2www/meetings/189.log |  186 ++--
 i2p2www/meetings/189.rst |   10 +
 i2p2www/meetings/190.log |  234 +++--
 i2p2www/meetings/190.rst |   10 +
 i2p2www/meetings/191.log |  110 ++-
 i2p2www/meetings/191.rst |   10 +
 i2p2www/meetings/192.log |  110 ++-
 i2p2www/meetings/192.rst |   10 +
 i2p2www/meetings/193.log |   47 +-
 i2p2www/meetings/193.rst |   10 +
 i2p2www/meetings/194.log |  314 ++++---
 i2p2www/meetings/194.rst |   10 +
 i2p2www/meetings/195.log |  150 ++--
 i2p2www/meetings/195.rst |   10 +
 i2p2www/meetings/196.log |  228 +++--
 i2p2www/meetings/196.rst |   10 +
 i2p2www/meetings/197.log |   72 +-
 i2p2www/meetings/197.rst |   10 +
 i2p2www/meetings/198.log |   10 +-
 i2p2www/meetings/198.rst |   10 +
 i2p2www/meetings/199.log |  476 +++++-----
 i2p2www/meetings/199.rst |   10 +
 i2p2www/meetings/2.log   |   15 +-
 i2p2www/meetings/2.rst   |   10 +
 i2p2www/meetings/20.log  |    9 -
 i2p2www/meetings/20.rst  |   10 +
 i2p2www/meetings/200.log |  152 ++--
 i2p2www/meetings/200.rst |   10 +
 i2p2www/meetings/201.log |   74 +-
 i2p2www/meetings/201.rst |   10 +
 i2p2www/meetings/202.log |  168 ++--
 i2p2www/meetings/202.rst |   10 +
 i2p2www/meetings/203.log |  216 +++--
 i2p2www/meetings/203.rst |   10 +
 i2p2www/meetings/204.log |  156 ++--
 i2p2www/meetings/204.rst |   10 +
 i2p2www/meetings/205.log |  170 ++--
 i2p2www/meetings/205.rst |   10 +
 i2p2www/meetings/206.log |   84 +-
 i2p2www/meetings/206.rst |   10 +
 i2p2www/meetings/207.log |   11 -
 i2p2www/meetings/207.rst |   10 +
 i2p2www/meetings/21.log  |   13 +-
 i2p2www/meetings/21.rst  |   10 +
 i2p2www/meetings/22.log  |    9 -
 i2p2www/meetings/22.rst  |   10 +
 i2p2www/meetings/23.log  |   13 +-
 i2p2www/meetings/23.rst  |   10 +
 i2p2www/meetings/25.log  |    9 -
 i2p2www/meetings/25.rst  |   10 +
 i2p2www/meetings/26.log  |   25 +-
 i2p2www/meetings/26.rst  |   10 +
 i2p2www/meetings/28.log  |    9 -
 i2p2www/meetings/28.rst  |   10 +
 i2p2www/meetings/29.log  |   11 +-
 i2p2www/meetings/29.rst  |   10 +
 i2p2www/meetings/3.log   |   13 +-
 i2p2www/meetings/3.rst   |   10 +
 i2p2www/meetings/30.log  |   19 +-
 i2p2www/meetings/30.rst  |   10 +
 i2p2www/meetings/31.log  |   17 +-
 i2p2www/meetings/31.rst  |   10 +
 i2p2www/meetings/32.log  |   15 +-
 i2p2www/meetings/32.rst  |   10 +
 i2p2www/meetings/33.log  |    9 -
 i2p2www/meetings/33.rst  |   10 +
 i2p2www/meetings/34.log  |    9 -
 i2p2www/meetings/34.rst  |   10 +
 i2p2www/meetings/35.log  |    9 -
 i2p2www/meetings/35.rst  |   10 +
 i2p2www/meetings/4.log   |   13 +-
 i2p2www/meetings/4.rst   |   10 +
 i2p2www/meetings/47.log  | 1819 +++++++++++++++++++-------------------
 i2p2www/meetings/47.rst  |   10 +
 i2p2www/meetings/49.log  | 1481 ++++++++++++++++---------------
 i2p2www/meetings/49.rst  |   10 +
 i2p2www/meetings/50.log  | 1191 +++++++++++++------------
 i2p2www/meetings/50.rst  |   10 +
 i2p2www/meetings/51.log  | 1765 ++++++++++++++++++------------------
 i2p2www/meetings/51.rst  |   10 +
 i2p2www/meetings/52.log  |  751 ++++++++--------
 i2p2www/meetings/52.rst  |   10 +
 i2p2www/meetings/53.log  |  221 +++--
 i2p2www/meetings/53.rst  |   10 +
 i2p2www/meetings/54.log  |  875 +++++++++---------
 i2p2www/meetings/54.rst  |   10 +
 i2p2www/meetings/55.log  |  423 +++++----
 i2p2www/meetings/55.rst  |   10 +
 i2p2www/meetings/56.log  |  425 +++++----
 i2p2www/meetings/56.rst  |   10 +
 i2p2www/meetings/57.log  |  335 ++++---
 i2p2www/meetings/57.rst  |   10 +
 i2p2www/meetings/58.log  |  623 +++++++------
 i2p2www/meetings/58.rst  |   10 +
 i2p2www/meetings/59.log  | 1464 +++++++++++++++---------------
 i2p2www/meetings/59.rst  |   10 +
 i2p2www/meetings/60.log  |  553 ++++++------
 i2p2www/meetings/60.rst  |   10 +
 i2p2www/meetings/61.log  |  159 ++--
 i2p2www/meetings/61.rst  |   10 +
 i2p2www/meetings/62.log  |  572 ++++++------
 i2p2www/meetings/62.rst  |   10 +
 i2p2www/meetings/63.log  |  360 ++++----
 i2p2www/meetings/63.rst  |   10 +
 i2p2www/meetings/64.log  |  381 ++++----
 i2p2www/meetings/64.rst  |   11 +
 i2p2www/meetings/65.log  | 1240 +++++++++++++-------------
 i2p2www/meetings/65.rst  |   10 +
 i2p2www/meetings/66.log  |  948 ++++++++++----------
 i2p2www/meetings/66.rst  |   10 +
 i2p2www/meetings/68.log  |  555 ++++++------
 i2p2www/meetings/68.rst  |   10 +
 i2p2www/meetings/69.log  |  494 +++++------
 i2p2www/meetings/69.rst  |   10 +
 i2p2www/meetings/7.log   |    9 -
 i2p2www/meetings/7.rst   |   10 +
 i2p2www/meetings/70.log  |  322 ++++---
 i2p2www/meetings/70.rst  |   10 +
 i2p2www/meetings/71.log  |  666 +++++++-------
 i2p2www/meetings/71.rst  |   10 +
 i2p2www/meetings/72.log  | 1312 ++++++++++++++-------------
 i2p2www/meetings/72.rst  |   10 +
 i2p2www/meetings/73.log  |  280 +++---
 i2p2www/meetings/73.rst  |   10 +
 i2p2www/meetings/74.log  |  374 ++++----
 i2p2www/meetings/74.rst  |   10 +
 i2p2www/meetings/75.log  |  202 ++---
 i2p2www/meetings/75.rst  |   10 +
 i2p2www/meetings/76.log  | 1034 +++++++++++-----------
 i2p2www/meetings/76.rst  |   10 +
 i2p2www/meetings/77.log  |  998 +++++++++++----------
 i2p2www/meetings/77.rst  |   10 +
 i2p2www/meetings/78.log  |  574 ++++++------
 i2p2www/meetings/78.rst  |   10 +
 i2p2www/meetings/79.log  |  368 ++++----
 i2p2www/meetings/79.rst  |   10 +
 i2p2www/meetings/8.log   |    9 -
 i2p2www/meetings/8.rst   |   10 +
 i2p2www/meetings/80.log  |  710 ++++++++-------
 i2p2www/meetings/80.rst  |   10 +
 i2p2www/meetings/81.log  |  804 +++++++++--------
 i2p2www/meetings/81.rst  |   10 +
 i2p2www/meetings/82.log  |  934 ++++++++++---------
 i2p2www/meetings/82.rst  |   10 +
 i2p2www/meetings/9.log   |    9 -
 i2p2www/meetings/9.rst   |   10 +
 i2p2www/meetings/90.log  |  400 +++++----
 i2p2www/meetings/90.rst  |   10 +
 i2p2www/meetings/92.log  |  663 +++++++-------
 i2p2www/meetings/92.rst  |   10 +
 i2p2www/meetings/93.log  |  549 ++++++------
 i2p2www/meetings/93.rst  |   10 +
 i2p2www/meetings/95.log  |  567 ++++++------
 i2p2www/meetings/95.rst  |   10 +
 i2p2www/meetings/99.log  |  400 +++++----
 i2p2www/meetings/99.rst  |   10 +
 344 files changed, 33461 insertions(+), 32830 deletions(-)
 create mode 100644 i2p2www/meetings/1.rst
 create mode 100644 i2p2www/meetings/10.rst
 create mode 100644 i2p2www/meetings/100.rst
 create mode 100644 i2p2www/meetings/101.rst
 create mode 100644 i2p2www/meetings/102.rst
 create mode 100644 i2p2www/meetings/103.rst
 create mode 100644 i2p2www/meetings/104.rst
 create mode 100644 i2p2www/meetings/105.rst
 create mode 100644 i2p2www/meetings/106.rst
 create mode 100644 i2p2www/meetings/107.rst
 create mode 100644 i2p2www/meetings/108.rst
 create mode 100644 i2p2www/meetings/109.rst
 create mode 100644 i2p2www/meetings/11.rst
 create mode 100644 i2p2www/meetings/110.rst
 create mode 100644 i2p2www/meetings/111.rst
 create mode 100644 i2p2www/meetings/112.rst
 create mode 100644 i2p2www/meetings/113.rst
 create mode 100644 i2p2www/meetings/114.rst
 create mode 100644 i2p2www/meetings/115.rst
 create mode 100644 i2p2www/meetings/116.rst
 create mode 100644 i2p2www/meetings/117.rst
 create mode 100644 i2p2www/meetings/118.rst
 create mode 100644 i2p2www/meetings/119.rst
 create mode 100644 i2p2www/meetings/12.rst
 create mode 100644 i2p2www/meetings/120.rst
 create mode 100644 i2p2www/meetings/121.rst
 create mode 100644 i2p2www/meetings/122.rst
 create mode 100644 i2p2www/meetings/123.rst
 create mode 100644 i2p2www/meetings/124.rst
 create mode 100644 i2p2www/meetings/125.rst
 create mode 100644 i2p2www/meetings/126.rst
 create mode 100644 i2p2www/meetings/127.rst
 create mode 100644 i2p2www/meetings/128.rst
 create mode 100644 i2p2www/meetings/129.rst
 create mode 100644 i2p2www/meetings/130.rst
 create mode 100644 i2p2www/meetings/131.rst
 create mode 100644 i2p2www/meetings/132.rst
 create mode 100644 i2p2www/meetings/133.rst
 create mode 100644 i2p2www/meetings/134.rst
 create mode 100644 i2p2www/meetings/135.rst
 create mode 100644 i2p2www/meetings/136.rst
 create mode 100644 i2p2www/meetings/137.rst
 create mode 100644 i2p2www/meetings/138.rst
 create mode 100644 i2p2www/meetings/139.rst
 create mode 100644 i2p2www/meetings/140.rst
 create mode 100644 i2p2www/meetings/141.rst
 create mode 100644 i2p2www/meetings/142.rst
 create mode 100644 i2p2www/meetings/143.rst
 create mode 100644 i2p2www/meetings/144.rst
 create mode 100644 i2p2www/meetings/145.rst
 create mode 100644 i2p2www/meetings/146.rst
 create mode 100644 i2p2www/meetings/147.rst
 create mode 100644 i2p2www/meetings/148.rst
 create mode 100644 i2p2www/meetings/149.rst
 create mode 100644 i2p2www/meetings/15.rst
 create mode 100644 i2p2www/meetings/150.rst
 create mode 100644 i2p2www/meetings/151.rst
 create mode 100644 i2p2www/meetings/152.rst
 create mode 100644 i2p2www/meetings/153.rst
 create mode 100644 i2p2www/meetings/154.rst
 create mode 100644 i2p2www/meetings/155.rst
 create mode 100644 i2p2www/meetings/156.rst
 create mode 100644 i2p2www/meetings/157.rst
 create mode 100644 i2p2www/meetings/158.rst
 create mode 100644 i2p2www/meetings/159.rst
 create mode 100644 i2p2www/meetings/160.rst
 create mode 100644 i2p2www/meetings/161.rst
 create mode 100644 i2p2www/meetings/162.rst
 create mode 100644 i2p2www/meetings/163.rst
 create mode 100644 i2p2www/meetings/164.rst
 create mode 100644 i2p2www/meetings/165.rst
 create mode 100644 i2p2www/meetings/166.rst
 create mode 100644 i2p2www/meetings/167.rst
 create mode 100644 i2p2www/meetings/168.rst
 create mode 100644 i2p2www/meetings/170.rst
 create mode 100644 i2p2www/meetings/171.rst
 create mode 100644 i2p2www/meetings/172.rst
 create mode 100644 i2p2www/meetings/173.rst
 create mode 100644 i2p2www/meetings/174.rst
 create mode 100644 i2p2www/meetings/175.rst
 create mode 100644 i2p2www/meetings/176.rst
 create mode 100644 i2p2www/meetings/177.rst
 create mode 100644 i2p2www/meetings/178.rst
 create mode 100644 i2p2www/meetings/179.rst
 create mode 100644 i2p2www/meetings/18.rst
 create mode 100644 i2p2www/meetings/180.rst
 create mode 100644 i2p2www/meetings/181.rst
 create mode 100644 i2p2www/meetings/182.rst
 create mode 100644 i2p2www/meetings/183.rst
 create mode 100644 i2p2www/meetings/184.rst
 create mode 100644 i2p2www/meetings/185.rst
 create mode 100644 i2p2www/meetings/186.rst
 create mode 100644 i2p2www/meetings/187.rst
 create mode 100644 i2p2www/meetings/188.rst
 create mode 100644 i2p2www/meetings/189.rst
 create mode 100644 i2p2www/meetings/190.rst
 create mode 100644 i2p2www/meetings/191.rst
 create mode 100644 i2p2www/meetings/192.rst
 create mode 100644 i2p2www/meetings/193.rst
 create mode 100644 i2p2www/meetings/194.rst
 create mode 100644 i2p2www/meetings/195.rst
 create mode 100644 i2p2www/meetings/196.rst
 create mode 100644 i2p2www/meetings/197.rst
 create mode 100644 i2p2www/meetings/198.rst
 create mode 100644 i2p2www/meetings/199.rst
 create mode 100644 i2p2www/meetings/2.rst
 create mode 100644 i2p2www/meetings/20.rst
 create mode 100644 i2p2www/meetings/200.rst
 create mode 100644 i2p2www/meetings/201.rst
 create mode 100644 i2p2www/meetings/202.rst
 create mode 100644 i2p2www/meetings/203.rst
 create mode 100644 i2p2www/meetings/204.rst
 create mode 100644 i2p2www/meetings/205.rst
 create mode 100644 i2p2www/meetings/206.rst
 create mode 100644 i2p2www/meetings/207.rst
 create mode 100644 i2p2www/meetings/21.rst
 create mode 100644 i2p2www/meetings/22.rst
 create mode 100644 i2p2www/meetings/23.rst
 create mode 100644 i2p2www/meetings/25.rst
 create mode 100644 i2p2www/meetings/26.rst
 create mode 100644 i2p2www/meetings/28.rst
 create mode 100644 i2p2www/meetings/29.rst
 create mode 100644 i2p2www/meetings/3.rst
 create mode 100644 i2p2www/meetings/30.rst
 create mode 100644 i2p2www/meetings/31.rst
 create mode 100644 i2p2www/meetings/32.rst
 create mode 100644 i2p2www/meetings/33.rst
 create mode 100644 i2p2www/meetings/34.rst
 create mode 100644 i2p2www/meetings/35.rst
 create mode 100644 i2p2www/meetings/4.rst
 create mode 100644 i2p2www/meetings/47.rst
 create mode 100644 i2p2www/meetings/49.rst
 create mode 100644 i2p2www/meetings/50.rst
 create mode 100644 i2p2www/meetings/51.rst
 create mode 100644 i2p2www/meetings/52.rst
 create mode 100644 i2p2www/meetings/53.rst
 create mode 100644 i2p2www/meetings/54.rst
 create mode 100644 i2p2www/meetings/55.rst
 create mode 100644 i2p2www/meetings/56.rst
 create mode 100644 i2p2www/meetings/57.rst
 create mode 100644 i2p2www/meetings/58.rst
 create mode 100644 i2p2www/meetings/59.rst
 create mode 100644 i2p2www/meetings/60.rst
 create mode 100644 i2p2www/meetings/61.rst
 create mode 100644 i2p2www/meetings/62.rst
 create mode 100644 i2p2www/meetings/63.rst
 create mode 100644 i2p2www/meetings/64.rst
 create mode 100644 i2p2www/meetings/65.rst
 create mode 100644 i2p2www/meetings/66.rst
 create mode 100644 i2p2www/meetings/68.rst
 create mode 100644 i2p2www/meetings/69.rst
 create mode 100644 i2p2www/meetings/7.rst
 create mode 100644 i2p2www/meetings/70.rst
 create mode 100644 i2p2www/meetings/71.rst
 create mode 100644 i2p2www/meetings/72.rst
 create mode 100644 i2p2www/meetings/73.rst
 create mode 100644 i2p2www/meetings/74.rst
 create mode 100644 i2p2www/meetings/75.rst
 create mode 100644 i2p2www/meetings/76.rst
 create mode 100644 i2p2www/meetings/77.rst
 create mode 100644 i2p2www/meetings/78.rst
 create mode 100644 i2p2www/meetings/79.rst
 create mode 100644 i2p2www/meetings/8.rst
 create mode 100644 i2p2www/meetings/80.rst
 create mode 100644 i2p2www/meetings/81.rst
 create mode 100644 i2p2www/meetings/82.rst
 create mode 100644 i2p2www/meetings/9.rst
 create mode 100644 i2p2www/meetings/90.rst
 create mode 100644 i2p2www/meetings/92.rst
 create mode 100644 i2p2www/meetings/93.rst
 create mode 100644 i2p2www/meetings/95.rst
 create mode 100644 i2p2www/meetings/99.rst

diff --git a/i2p2www/meetings/1.log b/i2p2www/meetings/1.log
index d352999f..fcd913ca 100644
--- a/i2p2www/meetings/1.log
+++ b/i2p2www/meetings/1.log
@@ -1,10 +1,3 @@
-{% 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
@@ -700,5 +693,3 @@ Courtesy of the wayback machine.
 03:46 <@nop> night
 03:47 <+logger> Ended logging
 --- Log closed Wed May 22 03:47:55 2002
-
                
-{% endblock %}
diff --git a/i2p2www/meetings/1.rst b/i2p2www/meetings/1.rst
new file mode 100644
index 00000000..975ded3d
--- /dev/null
+++ b/i2p2www/meetings/1.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 22, 2002
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of the wayback machine)
+------------
diff --git a/i2p2www/meetings/10.log b/i2p2www/meetings/10.log
index 56e5cf6c..50b97044 100644
--- a/i2p2www/meetings/10.log
+++ b/i2p2www/meetings/10.log
@@ -1,10 +1,3 @@
-{% 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
@@ -167,5 +160,3 @@ Courtesy of the wayback machine.
 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/i2p2www/meetings/10.rst b/i2p2www/meetings/10.rst
new file mode 100644
index 00000000..e8ce32d4
--- /dev/null
+++ b/i2p2www/meetings/10.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 4 2002
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/100.log b/i2p2www/meetings/100.log
index 4a658280..951c09e1 100644
--- a/i2p2www/meetings/100.log
+++ b/i2p2www/meetings/100.log
@@ -1,195 +1,189 @@
-{% 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
+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/100.rst b/i2p2www/meetings/100.rst
new file mode 100644
index 00000000..15e2aa57
--- /dev/null
+++ b/i2p2www/meetings/100.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 27, XXXX
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/101.log b/i2p2www/meetings/101.log
index b772578e..45a0748f 100644
--- a/i2p2www/meetings/101.log
+++ b/i2p2www/meetings/101.log
@@ -1,221 +1,215 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 101{% endblock %}
-{% block content %}
                I2P dev meeting, August 3 @ 21:00 GMT
                
-
                
-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  <hypercubus> 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
                
-
                
-{% endblock %}
\ No newline at end of file
+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/101.rst b/i2p2www/meetings/101.rst
new file mode 100644
index 00000000..46a71aa5
--- /dev/null
+++ b/i2p2www/meetings/101.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 3, XXXX @ 21:00 GMT
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/102.log b/i2p2www/meetings/102.log
index 328aea2b..67af773f 100644
--- a/i2p2www/meetings/102.log
+++ b/i2p2www/meetings/102.log
@@ -1,120 +1,114 @@
-{% 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
+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/102.rst b/i2p2www/meetings/102.rst
new file mode 100644
index 00000000..e3ed8e15
--- /dev/null
+++ b/i2p2www/meetings/102.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 10, XXXX @ 21:00 GMT
+============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/103.log b/i2p2www/meetings/103.log
index 0df1096b..3a79f77f 100644
--- a/i2p2www/meetings/103.log
+++ b/i2p2www/meetings/103.log
@@ -1,217 +1,211 @@
-{% 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
+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/103.rst b/i2p2www/meetings/103.rst
new file mode 100644
index 00000000..0f36b80a
--- /dev/null
+++ b/i2p2www/meetings/103.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 17, 2004
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/104.log b/i2p2www/meetings/104.log
index 7ef7c3a3..9cd04a32 100644
--- a/i2p2www/meetings/104.log
+++ b/i2p2www/meetings/104.log
@@ -1,422 +1,416 @@
-{% 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
+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/104.rst b/i2p2www/meetings/104.rst
new file mode 100644
index 00000000..eb78c051
--- /dev/null
+++ b/i2p2www/meetings/104.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 24, 2004
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/105.log b/i2p2www/meetings/105.log
index ddec83da..8bca0dc2 100644
--- a/i2p2www/meetings/105.log
+++ b/i2p2www/meetings/105.log
@@ -1,225 +1,219 @@
-{% 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
+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/105.rst b/i2p2www/meetings/105.rst
new file mode 100644
index 00000000..124fc96c
--- /dev/null
+++ b/i2p2www/meetings/105.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 31, 2004
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/106.log b/i2p2www/meetings/106.log
index d9a9c279..be47c299 100644
--- a/i2p2www/meetings/106.log
+++ b/i2p2www/meetings/106.log
@@ -1,476 +1,470 @@
-{% 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
+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/106.rst b/i2p2www/meetings/106.rst
new file mode 100644
index 00000000..7cd2616d
--- /dev/null
+++ b/i2p2www/meetings/106.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 7, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/107.log b/i2p2www/meetings/107.log
index 71ed965c..18f3f3e5 100644
--- a/i2p2www/meetings/107.log
+++ b/i2p2www/meetings/107.log
@@ -1,500 +1,494 @@
-{% 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
+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/107.rst b/i2p2www/meetings/107.rst
new file mode 100644
index 00000000..b48a9668
--- /dev/null
+++ b/i2p2www/meetings/107.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 14, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/108.log b/i2p2www/meetings/108.log
index 5a140d76..506eb87a 100644
--- a/i2p2www/meetings/108.log
+++ b/i2p2www/meetings/108.log
@@ -1,40 +1,34 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 108{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 21, 2004</h3>
-<div class="irclog">
-14:06 < jrandom> 0) hi</p>
-14:06 < jrandom> 1) Dev status</p>
-14:06 < jrandom> 2) New userhosts.txt vs. hosts.txt</p>
-14:06 < jrandom> 3) ???</p>
-14:06 < jrandom> 0) hi</p>
-14:06  * jrandom waves</p>
-14:06 < jrandom> brief weekly status notes @ http://dev.i2p.net/pipermail/i2p/2004-September/000449.html</p>
-14:06 < jrandom> (and probably brief meeting logs to be posted once this is over ;)</p>
-14:07  * jrandom gives y'all a good 30s to read those notes</p>
-14:07 < jrandom> anyway, moving on to 1) dev status</p>
-14:07 < jrandom> basic overview of whats up is in that email</p>
-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</p>
-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)</p>
-14:09 < jrandom> thats all i've got to say on that front</p>
-14:10 < jrandom> anyone have anything they want to bring up wrt 0.4.0.1 or the dev activity?</p>
-14:11 < deer> <jrandom> no jrandom, we're just lurking</p>
-14:11 < jrandom> ok, moving on to 2) new userhosts.txt vs. hosts.txt</p>
-14:11 < protok0l> yey!</p>
-14:11 < jrandom> minor new feature so people can modify their local naming while still pulling down hosts.txt</p>
-14:12 < protok0l> which file has priority if they conflict? user i would assume</p>
-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</p>
-14:13 < jrandom> userhosts.txt has first preference</p>
-14:15 < jrandom> ok, thats all i've got for 2, so moving on quickly to our last point- 3) ???</p>
-14:15 < jrandom> anyone have anything else they want to discuss?</p>
-14:16 < deer> <Pseudonym> timetable for 0.4.1?</p>
-14:17 < jrandom> should be out this week, but maybe not until the weekend.</p>
-14:17 < deer> <Pseudonym> cool</p>
-14:17 < jrandom> i finally gave up the battle with my laptop after the spacebar died</p>
-14:17 < jrandom> (codingWithoutSpaces==lame;)</p>
-14:18 < jrandom> ok, anyone else have anything they want to bring up?  i think we're going for a record meeting time here</p>
-14:18 < jrandom> (not that thats a problem)</p>
-14:19 < jrandom> ok, if not</p>
-14:19  * jrandom winds up</p>
-14:19  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/108.rst b/i2p2www/meetings/108.rst
new file mode 100644
index 00000000..eb9b4c2a
--- /dev/null
+++ b/i2p2www/meetings/108.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 21, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/109.log b/i2p2www/meetings/109.log
index 50a8ad8a..8333232e 100644
--- a/i2p2www/meetings/109.log
+++ b/i2p2www/meetings/109.log
@@ -1,119 +1,113 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 109{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 28, 2004</h3>
-<div class="irclog">
-14:08 < jrandom> 0) hi</p>
-14:08 < jrandom> 1) New transport</p>
-14:08 < jrandom> 2) 0.4.1 status</p>
-14:08 < jrandom> 3) ???</p>
-14:08 < jrandom> 0) hi</p>
-14:08 < duck> hi</p>
-14:09 < jrandom> heya</p>
-14:09 < deer> <ugha2p> Hi.</p>
-14:09 < deer> <pseudonym> hi</p>
-14:09 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-September/000454.html</p>
-14:09 < deer> * ugha2p is looking for the weekly status notes.</p>
-14:09 < jrandom> (hey, i'm psychic)</p>
-14:10 < jrandom> ok, jumping in to 1) New transport</p>
-14:10 < jrandom> the message pretty much covers the main bits</p>
-14:11 < jrandom> its all working atm, but obviously wont talk to anyone else until the new release is out</p>
-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</p>
-14:12 < deer> <pseudonym> does it include windowsize?</p>
-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).</p>
-14:12 < deer> <ugha2p> Sounds like a potential security hole.</p>
-14:12 < jrandom> oh, no, this is just the inter-router transport, not the streaming lib, unfortunately</p>
-14:12 < deer> <pseudonym> ok</p>
-14:12 < jrandom> in a way ugha, yes</p>
-14:12 < jrandom> (which is why if people *can* set their IP, they should)</p>
-14:13 < jrandom> ugha: however, it only 'believes' someone if they have NO connections that work</p>
-14:13 < deer> <ugha2p> Shouldn't the router listen on 0.0.0.0 in any case?</p>
-14:13 < jrandom> but someone pretty smart could probabalistically do some evil things</p>
-14:14 < jrandom> ugha: it does that (almost always)</p>
-14:14 < jrandom> however, we need to know our IP address so we can put it in our RouterInfo</p>
-14:14 < jrandom> (since our RouterInfo is verified whenever we contact someone)</p>
-14:14 < deer> <ugha2p> Ah, ok.</p>
-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.</p>
-14:15 < jrandom> yeah ugha, there's trouble down that path, but its a numbers game</p>
-14:16 < deer> <ugha2p> Anyhow, that was just a suggestion. We can move on.</p>
-14:16 < jrandom> (however, they could just sybil you and mess up whatever #s you're trying)</p>
-14:16 < deer> <ugha2p> Right.</p>
-14:17 < deer> <ugha2p> What if the router loses all connections (eg, network failure)?</p>
-14:17 < deer> <ugha2p> Does it redetect its IP?</p>
-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</p>
-14:18 < deer> <ugha2p> (This would be the case with dynamic IPs)</p>
-14:18 < jrandom> right, it'll work fine with that</p>
-14:18 < deer> <ugha2p> Ah, ok.</p>
-14:19 < jrandom> (see ourAddressReceived(String addr) in TCPTransport.java for the details)</p>
-14:19 < deer> <pseudonym> what happens when reported IPs don't match?</p>
-14:19 < jrandom> pseudonym: if you already have active TCP connections, you ignore what other people tell you</p>
-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</p>
-14:20 < jrandom> (updating your routerInfo)</p>
-14:22 < deer> <pseudonym> if there are active conns, it seems like a mismatch should be a red flag</p>
-14:22 < deer> <pseudonym> (I'm not sure what to do with it)</p>
-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</p>
-14:23 < deer> <ugha2p> Too bad we can no longer reduce the router's reliability ranking.</p>
-14:23 < jrandom> we can add that to the list of connection errors though</p>
-14:24 < jrandom> ugha: but we can shitlist 'em ;)</p>
-14:24 < jrandom> (and we do)</p>
-14:24 < deer> <pseudonym> how do we know the one we already have is "right"?  maybe the existing conns are from black hats</p>
-14:24 < deer> <pseudonym> especially if we have few or only recent conns</p>
-14:24 < jrandom> pseudonym: the existing connections are "right" in that they can send and receive data</p>
-14:24 < deer> <ugha2p> pseudonym: We can be sure when we get new inbound connections, although those can be spoofed as well.</p>
-14:25 < jrandom> right, if we're talking about someone concerned with an active IP spoofing attack in addition to sybil...</p>
-14:25 < jrandom> well, that person can simply set their IP address ;)</p>
-14:25 < deer> <ugha2p> :)</p>
-14:26 < deer> <pseudonym> but what's the likelyhood that the operator will even know what's happening</p>
-14:26 < deer> <pseudonym> if we get a lot of mismatches there should be some active alert</p>
-14:27 < deer> <pseudonym> (this may be something to worry about in a later release, but since it came up...)</p>
-14:27 < jrandom> we can add an explicit message to the list of connection errors</p>
-14:27 < jrandom> the only real concern here is that we're trying to prevent a restricted route from being formed</p>
-14:27 < jrandom> (and the extreme of that being a full network partition)</p>
-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</p>
-14:30 < jrandom> ok, anyone else have anything wrt the new transport?</p>
-14:31 < jrandom> if not, moving on to 2) 0.4.1 status</p>
-14:31 < jrandom> all the "necessary" stuff is done, but theres still some debugging and minor updates to get in</p>
-14:32 < jrandom> current target is a thursday release, but we'll see what gets added or removed from the rev ;)</p>
-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</p>
-14:33 < deer> <ugha2p> Does 0.4.1 include other updates than the new TCP transport?</p>
-14:33 < jrandom> not really ugha :)</p>
-14:34 < deer> <pseudonym> is it backward compatible?</p>
-14:34 < jrandom> (see: www.i2p.net/roadmap )</p>
-14:34 < jrandom> no, it is not backwards compatible</p>
-14:34 < deer> <ugha2p> :)</p>
-14:36 < jrandom> ok, thats all ive got to mention wrt 0.4.1.. anything else on that?</p>
-14:36 < jrandom> if not, we're on to ol' faithful: 3) ???</p>
-14:36 < deer> <ugha2p> *silence*</p>
-14:37 < jrandom> anyone have anything else (i2p related) they want to bring up?</p>
-14:37 < jrandom> we're already twice as long as last week's meeting ;)</p>
-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/</p>
-14:38 < deer> * pseudonym is a troublemaker</p>
-14:38 < jrandom> ooh right, v.cool</p>
-14:38 < jrandom> s/outproxy/inproxy/ :)</p>
-14:38  * jrandom sends the troublemaker to the corner</p>
-14:38 < deer> <ugha2p> Right, inproxy. :)</p>
-14:40 < jrandom> ok, if there's nothing else</p>
-14:40 < deer> <pseudonym> I think the new mail service from the postmaster is pretty cool</p>
-14:40 < jrandom> oh, definitely agreed</p>
-14:40 < deer> <pseudonym> er, postman</p>
-14:41 < deer> * ugha2p has yet to sign up.</p>
-14:41 < deer> <baffled> has anyone heard anything of stasher recently?</p>
-14:41 < jrandom> its nice that it works with both telnet and kmail:)</p>
-14:41 < jrandom> naw baffled, havent heard a peep</p>
-14:42 < deer> <baffled> I guess aum needs a boot to the head.</p>
-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.</p>
-14:42 < jrandom> not the head, the butt ;)</p>
-14:43 < jrandom> ugha: www.postman.i2p has a few pages about that</p>
-14:43 < deer> <ugha2p> Ah.</p>
-14:43 < deer> <baffled> they may be the same.</p>
-14:45 < deer> * ugha2p taps his fingers waiting for the baf.</p>
-14:45 < jrandom> sorry, nearly passed out here (loong day)</p>
-14:46 < jrandom> anything else?  if not, we've got the forum and the list</p>
-14:46 < duck> thanks to Mi-Go we have an updated i2ptunnel page</p>
-14:46 < duck> it is almost perfect</p>
-14:46 < jrandom> ooh nice</p>
-14:46 < duck> but if someone has some improvements, you know where to find me</p>
-14:47  * jrandom traceroutes</p>
-14:47  * jrandom winds up</p>
-14:47  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/109.rst b/i2p2www/meetings/109.rst
new file mode 100644
index 00000000..124a0569
--- /dev/null
+++ b/i2p2www/meetings/109.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 28, 2004
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/11.log b/i2p2www/meetings/11.log
index 5964e32e..431a1946 100644
--- a/i2p2www/meetings/11.log
+++ b/i2p2www/meetings/11.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 11{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 11</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Sep 17 22:59:26 2002
 23:01 -!- mode/#iip-dev [+v logger] by mids
 23:54  * Roto waves
@@ -157,5 +150,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/11.rst b/i2p2www/meetings/11.rst
new file mode 100644
index 00000000..02ca2140
--- /dev/null
+++ b/i2p2www/meetings/11.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 18, 2002
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/110.log b/i2p2www/meetings/110.log
index 46845697..39e99f72 100644
--- a/i2p2www/meetings/110.log
+++ b/i2p2www/meetings/110.log
@@ -1,186 +1,180 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 110{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 5, 2004</h3>
-<div class="irclog">
-14:05 < jrandom> 0) hi</p>
-14:05 < jrandom> 1) 0.4.1.1 status</p>
-14:05 < jrandom> 2) Pretty pictures</p>
-14:05 < jrandom> 3) 0.4.1.2 and 0.4.2</p>
-14:05 < jrandom> 4) Bundled eepserver</p>
-14:05 < jrandom> 5) ???</p>
-14:05 < jrandom> 0) hi</p>
-14:05  * jrandom waves</p>
-14:05 < jrandom> weekly status notes are available at http://dev.i2p.net/pipermail/i2p/2004-October/000461.html</p>
-14:06 < jrandom> (i cant believe its october)</p>
-14:06 < cervantes> it's december</p>
-14:06  * jrandom disconnects from cervantes.  excess clock skew</p>
-14:06 < deer> <baffled> could we have summer back now?</p>
-14:07 < cervantes> damn...lost your pr0n feed</p>
-14:07 < jrandom> sure. its a few thousand KM south of you baffled</p>
-14:07 < jrandom> ok, jumping into 1) 0.4.1.1 status</p>
-14:07 < deer> <baffled> will you let me know when I get there?</p>
-14:07 < cervantes> heh</p>
-14:07 < jrandom> click your heels three times...</p>
-14:08 < jrandom> ok, the 0.4.1 and 0.4.1.1 revs are out, and things are pretty much working again</p>
-14:08 < deer> <baffled> no, no, I don't want to go home it's cold there.</p>
-14:08 < jrandom> ;)</p>
-14:08 < jrandom> the autodetection of the external IP address seems to be working for the most part</p>
-14:09 < jrandom> (there have been a few quirks though, due to b0rked connections that don't hang up properly)</p>
-14:09 < jrandom> have people been using that, or had good/bad experiences with the autodetection?</p>
-14:10 < jrandom> guess not</p>
-14:10 < jrandom> ok, anyone have any comments/questions/concerns wrt 0.4.1.1?</p>
-14:11 < cervantes> no complaints here....</p>
-14:11 < dm> Haven't tried it yet, but it's on my agenda!</p>
-14:11 < jrandom> if not, swingin on to 2) pretty pictures</p>
-14:11 < jrandom> !thwap dm</p>
-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</p>
-14:12 < jrandom> ah ok, naw, the 'guess' button just tries to guess your IP by querying www.whatismyip.com</p>
-14:13 < jrandom> the autodetection is where you leave the IP address field blank and it figures it out by itself</p>
-14:13 < jrandom> most existing I2P users won't need it, since we're all used to either dyndns or static IPs anyway</p>
-14:13 < jrandom> it'll probably only matter for new users</p>
-14:14 < deer> <demonic_1> yea that worked a little slow for me</p>
-14:14 < deer> <demonic_1> but it did work</p>
-14:15 < jrandom> ok cool</p>
-14:15 < jrandom> anyway, i dont want to rehash what i posed in this weeks email wrt the stats gathered</p>
-14:16 < jrandom> instead, does anyone have any questions/comments/concerns about them?</p>
-14:17 < jrandom> i was pretty glad to see the 20h summary had only 500-something send failures out of 30,000-ish</p>
-14:17 < cervantes> how much load does the stats collecting generate?</p>
-14:17 < cervantes> I know the filesizes...but will it impact on performance having it ticking in the background</p>
-14:18 < jrandom> should be ~= 0.  there's no memory allocation in the stat gathering (as we use preallocated events) and everything is async</p>
-14:18 < cervantes> cool</p>
-14:18 -!- Sugadude [random@badfish.securityminded.net] has joined #i2p</p>
-14:18 -!- cat-a-puss [~tom@152.228.242.159] has joined #i2p</p>
-14:19 < jrandom> once 0.4.1.2 is outi'll probably nag some more people to gather various stats at times</p>
-14:19 < deer> <mule_iip> you're welcome</p>
-14:19 < cervantes> I'm happy to start collecting now... I'm already on 0.4.1.1-6</p>
-14:20 < jrandom> w3wt</p>
-14:21 < jrandom> ok, thats all i've got for the stats, unless anyone has anything to add?</p>
-14:21 < jrandom> if not, 3) 0.4.1.2 and 0.4.2</p>
-14:21 < deer> <baffled> You have my vote for streaming first.</p>
-14:22 < jrandom> cool</p>
-14:22 < jrandom> does anyone think we should keep the tunnel mods first?</p>
-14:22 < deer> <mule_iip> streaming first</p>
-14:23 < cervantes> doing the tunnel stuff now would likely cause more network distruption....it's probably good to have a breather ;-)</p>
-14:23 < jrandom> true</p>
-14:23 < deer> <mule_iip> all of those here today have been identified by the black hats anyhow :)</p>
-14:23 < jrandom> though i was thinking the other day about how we could do the tunnel mods without incompatabilities</p>
-14:23 < deer> <baffled> Comeon admit it, you just want to get your audio p0rn faster.</p>
-14:23 < duck> (me too on streaming first)</p>
-14:23 < jrandom> hehe</p>
-14:24 < cervantes> hehe</p>
-14:24 < cervantes> baffled: only if you source more of it ;-)</p>
-14:24 < dm> I think we should stick to the tunnel stuff first</p>
-14:24 < dm> get it out of the way...</p>
-14:24 < cat-a-puss> how is the new encryption stuff going to be different?</p>
-14:24  * jrandom kicks dm</p>
-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</p>
-14:25 < deer> <baffled> I think I can get a bit more.</p>
-14:25 < cat-a-puss> oh!</p>
-14:26 < cervantes> http://www.i2p.net/todo#tunnelId</p>
-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</p>
-14:27 < jrandom> the per-hop tunnelId stuff is also necessary to keep harvesting from messing with predecessors (/etc)</p>
-14:27 < dm> Yeah, we should definitely fix that first.</p>
-14:27 < deer> <mule_iip> i vote for dm to do it</p>
-14:28 < deer> <fidd> did i miss the meeting? ;)</p>
-14:28 < jrandom> i was just about to suggest that mule :)</p>
-14:28 < cervantes> I vote for dm not to have anything to do with it</p>
-14:28 < jrandom> heh</p>
-14:28 < jrandom> nope fidd, we're on item 3 of the agenda</p>
-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 </p>
-14:29 < dm> sweet</p>
-14:30 < jrandom> ok, moving on to 4) Bundled eepserver</p>
-14:30 < jrandom> if you haven't noticed, there's a bundled eepserver.</p>
-14:30 < cervantes> "just put the war files in the webapps directory and you're ready to go"</p>
-14:30 < jrandom> heh</p>
-14:30 < jrandom> for sufficiently well coded .war files :)</p>
-14:31 < cervantes> ooh does such a think exist?</p>
-14:31 < cervantes> *thing</p>
-14:31 < jrandom> but from a practical perspective, "just edit ./eepsite/docroot/index.html"</p>
-14:31 < deer> <baffled> One question I have is are you wishing people would use the eepserver or use a standard httpd server?</p>
-14:31 < cat-a-puss> do the ones generated by kde work?</p>
-14:31 < jrandom> cervantes: phttprelay.war, i2ptunnel.war, routerconsole.war :)</p>
-14:31 < dm> ah yes.. war. One of those J2EE things that requires 20 years experience at manually editing xml files.</p>
-14:31 < cervantes> touche</p>
-14:32 < jrandom> baffled: i really don't care.  if people have a webserver installed that can accept requests from kooky Host: lines, great</p>
-14:32 < jrandom> the eepserver is just for convenience</p>
-14:32 < jrandom> cat-a-puss: hmm, kde .war files?</p>
-14:32 < protok0l> monoculture... monoculture...</p>
-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</p>
-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</p>
-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</p>
-14:34 < jrandom> (with the same classpath as the router)</p>
-14:34 < dm> can we integrate i2p into jboss and bundle that before 1.0?</p>
-14:34 < jrandom> ooh, cool cat-a-puss </p>
-14:35 < cervantes> I take it the missing webdefault.xml has been fixed in cvs?</p>
-14:35 < deer> <detonate> actually, jetty.xml has</p>
-14:35 < jrandom> find us a compelling .ear dm :)</p>
-14:35 < jrandom> cervantes: what detonate said.  (i messed up the jetty.xml)</p>
-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</p>
-14:36 < jrandom> wr0d</p>
-14:37 < cervantes> just wanted to check that's been fixed in cvs ;-)</p>
-14:37 < jrandom> si sr</p>
-14:37 < cervantes> cool</p>
-14:37 < jrandom> (though the 0.4.1.2 release update will not overwrite people's eepsite)</p>
-14:37 < jrandom> ((0.4.1.2+ clean installs will of course include it though))</p>
-14:38 < cervantes> oh and did we discover the cause of DrWoo's missing eepsite keys?</p>
-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</p>
-14:38 < jrandom> no cervantes, nor a reproducable bug :/</p>
-14:39 < cervantes> ah good we can blame user error ;-)</p>
-14:39 < deer> <DrWoo> cervantes: almost certainly something klutzy I did</p>
-14:39 < cervantes> :o)</p>
-14:39  * jrandom blames the gremlins</p>
-14:40 < deer> <Jake> http://en.wikipedia.org/wiki/User:Kmweber/List_of_Everyone_Who_Has_Ever_Lived</p>
-14:40 < jrandom> ok, moving on to 5) ???</p>
-14:40 < jrandom> heh</p>
-14:40 < jrandom> well, yes, that certainly qualifies as "other"</p>
-14:40 < jrandom> anyone have anything they want to bring up?</p>
-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.</p>
-14:41 < dm> Kind Regards</p>
-14:41 < cat-a-puss> oh oh pick me! I have the base code for a distrubuted search.</p>
-14:41 < deer> <demonic_1> yea why do i2p after running 30 + hours go up to 100% cpu</p>
-14:41 < dm> dm</p>
-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</p>
-14:41 < deer> <demonic_1> and most of it system?</p>
-14:41 < jrandom> ooh kickass cat-a-puss!</p>
-14:41 < cat-a-puss> I anounced it here the other day, nobody noticed</p>
-14:41 < deer> <baffled> only tangentially jake.</p>
-14:42 < cat-a-puss> anyway, could use come cvs space</p>
-14:42 < deer> <DrWoo> cat-a-puss: do you have an eepsite for that?</p>
-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?</p>
-14:42 < cat-a-puss> and I can start testing in about 2 weeks</p>
-14:42 < cat-a-puss> DrWoo: nope</p>
-14:42 < deer> <Jake> baffled, HaH !</p>
-14:43 < deer> <demonic_1> 0.4.1.1-3</p>
-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</p>
-14:44 < cat-a-puss> jrandom: alright</p>
-14:44 < jrandom> cat-a-puss: what sort of searching does it do?</p>
-14:44 < jrandom> demonic_1: did it consume that much CPU prior to 0.4.1?</p>
-14:44 < cervantes> (proxies to MSN)</p>
-14:44 < deer> <mule_iip> demonic_1: and you get 1 meg of log every minute? sounds familiar.</p>
-14:45 < deer> <demonic_1> no</p>
-14:45 < jrandom> heh mule, yeah the bug you found was a nasty fast-busy</p>
-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</p>
-14:45 < jrandom> demonic is more likely being hit by one of the NPEs in the tcp.ConnectionBuilder</p>
-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.</p>
-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</p>
-14:46 < jrandom> ah cool, does it work with a distributed db, or is it more of a search-against-spidered?</p>
-14:47 < jrandom> ok cool</p>
-14:47 < cervantes> later baffled</p>
-14:47 < jrandom> lol, ttyl baffled</p>
-14:47 < cervantes> baffled: how do we know they're slut sounds, and not you on the end of your microphone?</p>
-14:47 < protok0l> ALL RIGHT!</p>
-14:47 < protok0l> i2p works again</p>
-14:47 < jrandom> w3wt</p>
-14:48 < jrandom> what was wrong?</p>
-14:49 < jrandom> ok, anyone else have anything they want to bring up for the meeting?</p>
-14:49 < deer> <Jake> can announce i2p to slashdot after the new streaming protocol is implemented ?</p>
-14:49 < dm> preferably before</p>
-14:49 < dm> but after will do</p>
-14:49 < jrandom> !thwap^2</p>
-14:50 < protok0l> POSTMAN!</p>
-14:50 < jrandom> ok, if there's nothing else..</p>
-14:50  * jrandom winds up</p>
-14:51 < deer> * Jake kisses jrandom </p>
-14:51  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/110.rst b/i2p2www/meetings/110.rst
new file mode 100644
index 00000000..b2f5bbd6
--- /dev/null
+++ b/i2p2www/meetings/110.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 5, 2004
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/111.log b/i2p2www/meetings/111.log
index 650459d6..04dcb2c9 100644
--- a/i2p2www/meetings/111.log
+++ b/i2p2www/meetings/111.log
@@ -1,201 +1,195 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 111{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 12, 2004</h3>
-<div class="irclog">
-14:04 < jrandom> 0) hi</p>
-14:04 < jrandom> 1) 0.4.1.2</p>
-14:04 < jrandom> 2) 0.4.1.3</p>
-14:05 < jrandom> 3) 0.4.2</p>
-14:05 < jrandom> 4) mail discussions</p>
-14:05 < jrandom> 5) ???</p>
-14:05 < jrandom> 0) hi</p>
-14:05  * jrandom waves</p>
-14:05 < Janonymous> hello</p>
-14:05 < jrandom> lots of #s in our agenda this week</p>
-14:05 < jrandom> weekly status notes up @ http://i2p.net/pipermail/i2p/2004-October/000466.html</p>
-14:05 < jrandom> (posted a min or three ago)</p>
-14:05 < deer> * cervantes has brought a pillow</p>
-14:06 < jrandom> oh i hope it won't be that boring ;)</p>
-14:06 < jrandom> anyway, jumping on in to the good stuff: 1) 0.4.1.2</p>
-14:06 < deer> <cervantes> make me up after the statistal analysis section</p>
-14:06 < jrandom> the release is out and everyone should upgrade</p>
-14:06 < jrandom> heh</p>
-14:06 < deer> <cervantes> eerm wake</p>
-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)</p>
-14:07 < jrandom> but hopefully those situations are few and far between</p>
-14:07 < deer> <mule_iip> nope :(</p>
-14:08 < jrandom> well, it varies by the user</p>
-14:08 < jrandom> i'm trying to find the cause, as its been around forever and its pretty annoying</p>
-14:08 < jrandom> (the actual hang, not the watchdog code that detects the hang)</p>
-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</p>
-14:10 < jrandom> but 0.4.1.2 should be fine for everyone (except mule ;)</p>
-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</p>
-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)</p>
-14:11 < jrandom> ok, moving on to 2) 0.4.1.3</p>
-14:12 < jrandom> well, there's not really anything i want to mention beyond wahts in the email</p>
-14:12 < jrandom> anyone have anything they want to say re: 0.4.1.3?</p>
-14:12 < Janonymous> nah</p>
-14:13 < deer> <postman> no</p>
-14:13 < Janonymous> backwards compatable?</p>
-14:13 < jrandom> certainly</p>
-14:13 < jrandom> ok, moving on to * 3) 0.4.2</p>
-14:14 < jrandom> again, another "see the email" :)</p>
-14:14 < Janonymous> xpc vs. tcp ??</p>
-14:14 < jrandom> i've never implemented a tcp stack before, so any guidance would be appreciated</p>
-14:15 < jrandom> xcp has better handling in networks with high delays</p>
-14:15 < jrandom> (for congestion control)</p>
-14:15 < Janonymous> does that include fec?</p>
-14:15 < jrandom> no</p>
-14:16 < Janonymous> k, cause I've been researching that some</p>
-14:17 < jrandom> cool</p>
-14:17 < jrandom> anything good you've found?</p>
-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?</p>
-14:17 < Janonymous> fec is used a lot for high latency/high throughput networks</p>
-14:18 < deer> <mule_iip> jrandom: nor have i, but i could tell a folk here to support you</p>
-14:18 < Janonymous> jrandom: some.. I'll report back</p>
-14:18 < deer> <mule_iip> at least it would be a good learning experience for him and another pair of eyes</p>
-14:18 < jrandom> great Janonymous </p>
-14:18 < jrandom> oh kickass mule</p>
-14:18 < jrandom> cervantes: per-tunnel throughput would improve with >1 message windows</p>
-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)</p>
-14:19 < jrandom> ((ecn++))</p>
-14:19 < deer> <cervantes> grand</p>
-14:20 < jrandom> ok, anything else on 0.4.2 stuff?</p>
-14:20 < Janonymous> fresh stack.. fresh laptop.. *drools*</p>
-14:21 < jrandom> heh</p>
-14:21 < Janonymous> yea</p>
-14:21 < Janonymous> one thing</p>
-14:22 < Janonymous> this will implement the new short handshake?</p>
-14:22 < jrandom> hmm?</p>
-14:22 < jrandom> we have the low-cpu TCP reconnection code in the 0.4.1 transport</p>
-14:22 < Janonymous> ah, in the email, you mention the alice-> bob handshake</p>
-14:23 < Janonymous> ah</p>
-14:23 < Janonymous> still catching up</p>
-14:23 < jrandom> oh.  yeah, whatever 0.4.2 comes up with, it'll support a packet sequence like the one in the email</p>
-14:24 < Janonymous> k</p>
-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])</p>
-14:25 < jrandom> ok, swinging on to 4) mail discussion</p>
-14:25 < jrandom> postman - you 'round?</p>
-14:26 < deer> <postman> ya</p>
-14:26 < jrandom> word, wanna give us a run down / update wrt the mail stuff?</p>
-14:27 < deer> <postman> hmm, ok tho i am quite shy talking in front of that many ppl :)</p>
-14:27 < jrandom> heh just imagine we're all nak^H^H^Her... nm</p>
-14:28  * Janonymous gets popcorn out</p>
-14:28 < deer> <postman> since the 20th od september there is a SMTP/POP Service running - accessible with normal smtp/pop3 MUAs</p>
-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</p>
-14:29 < Janonymous> what about inproxies/outproxies?</p>
-14:29 < deer> <postman> put it all together on a website </p>
-14:29 < deer> <postman> for those who haven't done so: www.postman.i2p</p>
-14:29  * Janonymous has not access to the network currently</p>
-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</p>
-14:30 < deer> <postman> out/inproxy does not run yet but is in the planning</p>
-14:30 < Janonymous> I think I caught some of the discussion on the maillist or the forum</p>
-14:30 < Janonymous> out would be more dangerous than in, right?</p>
-14:31 < deer> <postman> first i want a commonly accepted concept</p>
-14:31 < deer> <postman> generally YES, but i think we found a way that spam and the likes won't be sent outward</p>
-14:31 < jrandom> what'd be neat is if the mx.postman.i2p in/outproxy could dispatch to different (or multiple redundant) pop3 accts</p>
-14:31 < deer> <postman> simply by putting a quota on every user trying to send mails out</p>
-14:32 < jrandom> (that way it wouldn't be tied to a particular mailhost)</p>
-14:32 < deer> <postman> jrandom2p: please explain further</p>
-14:33 < Janonymous> could the seperate mailhosts be syncronized too?</p>
-14:33 < deer> <postman> jrandom2p: it's a question of account based routing</p>
-14:33 < jrandom> right postman</p>
-14:33 < jrandom> probably lots of work, i dont know much about the MTAs you're working on</p>
-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 </p>
-14:34 < jrandom> 'k, great</p>
-14:34 < Janonymous> Q wrt in/out</p>
-14:34 < deer> <postman> janonymous: i did not understand your question - please explain</p>
-14:34  * jrandom dreams up uucp-style offline fetch from mx.postman :)</p>
-14:35 < Janonymous> would mandatory mailbox to mailbox encryption make in/out sending less dangerous?</p>
-14:35 < deer> <postman> jrandom: haha, uucp is not needed i think - maybe ETRN is sexier :)</p>
-14:35 < deer> <postman> janonymous: right now the system works only internaly - everyone is free to apply PGP or sth similiar</p>
-14:36 < jrandom> Janonymous: you should swing by www.postman.i2p - he's put up a chunk of ideas / issues on there</p>
-14:36 < Janonymous> mandatory encryption/signatures is also an antispam method I believe</p>
-14:36 < deer> <Ragnarok> would it be possible to serve the postman.i2p address book using LDAP?</p>
-14:36 < Janonymous> I will once my laptop comes in</p>
-14:37 < deer> <postman> rag: there's an addressbook already - it is based on SQL tho - a transfer to LDAP os possible</p>
-14:38 < Janonymous> = server hosted address book?</p>
-14:38 < deer> * postman invites everybody to contribute own ideas to the ideas/concepts html document</p>
-14:38 < Janonymous> will do postman</p>
-14:38 < deer> * cervantes spiders the address book and starts writing penis enlargement pharmacutical mails </p>
-14:39 < deer> <postman> janonymous: well, ALL mailusers are SQL based - thus the "addressbook" is just a view on that table</p>
-14:39 < deer> <postman> cervantes: btw, every user can chose whether he wants to be visible or not</p>
-14:39 < Janonymous> ah</p>
-14:40 < Janonymous> how about selective groups ;)</p>
-14:40 < deer> <cervantes> postman: yup I've signed up already ;-)</p>
-14:40 < deer> <postman> cervantes: and since we HAVE a mailidentidy system , you cannot forge your senderaddress - we know it has been YOU :)</p>
-14:40 < deer> <postman> janonymous: yeah, it's planned for version 2.0 :)</p>
-14:41 < deer> <cervantes> postman: but I'll just spam every ircnym@postman.i2p ;-)</p>
-14:41 < deer> <postman> cervantes: this is technically possible, yes :)</p>
-14:42 < deer> <postman> cervantes: i hope you're able to deliver those pills too :)</p>
-14:42 < Janonymous> sounds like a much needed and long expected development for i2p</p>
-14:42 < Janonymous> the new email system</p>
-14:42 < deer> <cervantes> postman: and on the sender thing..the "Cervantes' penis enlargement elixir" would indicate the sender too :)</p>
-14:42 < deer> <postman> janonyous: i cannot tell about every detail implemented</p>
-14:43 < deer> <postman> jan: the website is best suited for this</p>
-14:43 < deer> <postman> cervantes: indeed - but this could be forged :)</p>
-14:43 < Janonymous> alrighty.. I'll get there asap</p>
-14:43 < jrandom> ok, great.  so, yeah, y'all should review whats up on www.postman.i2p and send in your ideas/comments</p>
-14:43 < deer> * postman nods and sits down again</p>
-14:44 < jrandom> (postman++)</p>
-14:44 < jrandom> ok that brings us to 5) ???</p>
-14:44 < jrandom> anyone have anything else they want to bring up?</p>
-14:44 < jrandom> (i2p related)</p>
-14:44 < deer> <postman> :)</p>
-14:44 < Janonymous> just a thought</p>
-14:45 < Janonymous> possible uses for I2P.. we know its a "distributed anonymous network layer"</p>
-14:45 < deer> <Jake> my node is down :( moving equipment to a different part of the house</p>
-14:46 < Janonymous> but what can that be used for.. particularly, those "common good" issues</p>
-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</p>
-14:47 < Janonymous> and freenet for that matter</p>
-14:47 < deer> <Jake> oppressed 1st world countries like the u.s.</p>
-14:47 < Janonymous> so, I thought maybe some extrapolation on those issues, maybe starting on the forum, then some words on the site</p>
-14:48 < jrandom> we've got a lot of work to do before we can claim any relevence for people in china</p>
-14:48 < Janonymous> heh, yea, wouldn't want to make any false promises, but..</p>
-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)</p>
-14:49 < deer> <fidd> how hard will it be for china to censor i2p?</p>
-14:49 < deer> <cervantes> I think applications will begin to surface more readily once the underlying network has stopped "shapeshifting"</p>
-14:49 < Janonymous> but those issues to me are one of the main things that makes i2p so exciting</p>
-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</p>
-14:50 < Janonymous> how about, "detect i2p on networks in china"</p>
-14:50 < Janonymous> stego?</p>
-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.</p>
-14:51 < Janonymous> my bad :) </p>
-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</p>
-14:52 < jrandom> its always important to keep your eyes on the real goals Janonymous, and i appreciate that</p>
-14:52 < Janonymous> yea, numbers of nodes has a lot to do with it</p>
-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.</p>
-14:53 < deer> <cervantes> no..they should stay here and help :)</p>
-14:53 < modulus> :-)</p>
-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 :)</p>
-14:53 < modulus> 3.0? sounds long-term ;-)</p>
-14:53 < jrandom> i have ~= 0 faith in stego transports for public networks</p>
-14:54 < jrandom> it aint tomorrow, thats for sure.</p>
-14:54 < Janonymous> word? huh</p>
-14:54 < Janonymous> jrandom: whys that (wrt stego)?</p>
-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.</p>
-14:56 < jrandom> how to defeat stego on public networks with closed source software: kidnap the dev's family, subvert the code.  deploy.</p>
-14:56 < Janonymous> ah.. yea.. random inputs? eh.. I just read this article talking like it was the future or something</p>
-14:56 < jrandom> how to defeat stego on private networks:  laugh at the 5 people using it, and arrest 'em all.</p>
-14:56 < modulus> well, what about anonymous closed-source software? of course it could be a trojan ;-)</p>
-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"</p>
-14:57 < deer> <Jake> that will be the giveaway and we'll know</p>
-14:57 < deer> <cervantes> %s!dev's family!jrandom</p>
-14:57 < jrandom> heh jake</p>
-14:58 < Janonymous> whens the eta for 4.2?</p>
-14:58 < jrandom> Janonymous: the #1 feature of anonymity or security software: snake oil.</p>
-14:58 < jrandom> 0.4.2?  sometime this month</p>
-14:58 < jrandom> prolly near the end</p>
-14:58 < Janonymous> heheh. </p>
-14:58 < jrandom> 0.4.1.3 will prolly be out later this week or the weekend</p>
-14:58 < deer> <cervantes> Jake: that would never work, we'll juist think you've poisoned his dog</p>
-14:58 < deer> <cervantes> *just</p>
-14:58 < Janonymous> I should be back on the net in a week or two</p>
-14:59 < jrandom> r0x0r</p>
-14:59 < jrandom> ok, anyone else have something to bring up?</p>
-14:59 < deer> <Jake> cervantes :)</p>
-15:00 < jrandom> if not..</p>
-15:00  * jrandom winds up</p>
-15:00  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/111.rst b/i2p2www/meetings/111.rst
new file mode 100644
index 00000000..95d56aac
--- /dev/null
+++ b/i2p2www/meetings/111.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 12, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/112.log b/i2p2www/meetings/112.log
index 5acac7a0..5ce2381e 100644
--- a/i2p2www/meetings/112.log
+++ b/i2p2www/meetings/112.log
@@ -1,272 +1,268 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 112{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 19, 2004</h3>
-<div class="irclog">
-14:03 < jrandom> 1) 0.4.1.3</p>
-14:03 < jrandom> 2) Tunnel test time, and send processing time</p>
-14:03 < jrandom> 3) Streaming lib</p>
-14:03 < jrandom> 4) files.i2p</p>
-14:03 < jrandom> 5) ???</p>
-14:03 < jrandom> 0) hi</p>
-14:03  * jrandom waves</p>
-14:04 < modulus> hi hi</p>
-14:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-October/000469.html</p>
-14:04 < deer_> <fidd> howdy</p>
-14:04 < jrandom> i didn't spend much time on the notes, so they're pretty brief</p>
-14:05 < jrandom> but, c'est la vie</p>
-14:05 < jrandom> moving on to 1) 0.4.1.3</p>
-14:05 < jrandom> the release came out the other day and its been.. well... largely like before</p>
-14:05 < jrandom> working good enough for most things, but not as reliable as we'd like</p>
-14:06 < jrandom> throughput is still low, but thats a know issue to be dealt with in 0.4.2</p>
-14:06 < jrandom> as mentioned in the email, I dont expect there to be any more 0.4.1.* releases</p>
-14:07 < jrandom> I dont have much more to say on that - anyone have any comments / concerns?</p>
-14:07 < deer_> <newsbyte> yes: what about the freeze-up?</p>
-14:09 < jrandom> I'm not going to discount the possibility that your machine hung due to I2P, but I severely doubt it</p>
-14:09 < jrandom> no one else has ever reported that happening on any platform</p>
-14:09 < deer_> <newsbyte> well...it must be related to it somehow, if not directly, IMHO</p>
-14:09 < deer_> <newsbyte> maybe the java?</p>
-14:10 < jrandom> you're on 1.5 on w2k?</p>
-14:10 < jrandom> or 1.4.2_05?</p>
-14:10 < deer_> <newsbyte> nope, 1.5</p>
-14:10 < jrandom> ok</p>
-14:10 < deer_> <newsbyte> I can't exclude it's something else, ofcourse</p>
-14:11 < deer_> <newsbyte> could be coincidence it happend two times</p>
-14:11 < jrandom> well, we can discuss further how to find out the cause after the meeting if you'd like</p>
-14:11 < deer_> <newsbyte> but the last time..I dunno...nothing much else was running, then</p>
-14:11 < deer_> <dinoman> 1.5 on w2k works good for me :)</p>
-14:11 < deer_> <newsbyte> indeed, though</p>
-14:11 < deer_> <newsbyte> isn't there a simple debug log or something?</p>
-14:11 < jrandom> if it happens again, please send me wrapper.log and logs/log-router-*.txt</p>
-14:11 < deer_> <newsbyte> that might be usefull when it freezes</p>
-14:11 < jrandom> there are more logs than dirt ;)</p>
-14:12 < jrandom> ok cool dinoman</p>
-14:12 < jrandom> perhaps it was some interaction with your software firewall</p>
-14:12 < deer_> <newsbyte> maybe</p>
-14:12 < jrandom> but, yeah,bounce me logs if it happens again</p>
-14:12 < jrandom> (please :)</p>
-14:12 < deer_> <newsbyte> well, that  it would get blocked, I would understand</p>
-14:12 < deer_> <newsbyte> but a total freeze...dunno...was creepy</p>
-14:13 < deer_> <newsbyte> on the bright side: I've 27/63 now</p>
-14:13 < jrandom> great</p>
-14:13 < jrandom> ok, anyone else have any questions/comments/concerns with 0.4.1.3?</p>
-14:13 < deer_> <newsbyte> I'll guees I'll ask Whoo to guide my through the eep thingy</p>
-14:13 < deer_> <dinoman> just don't use it with Sygate Personal Firewall bad bad</p>
-14:13 < deer_> <newsbyte> why?</p>
-14:14 < deer_> <dinoman> crash</p>
-14:14 < deer_> <newsbyte> yes; you forgot 6) profit!!</p>
-14:14 < deer_> <newsbyte> ;-)</p>
-14:14 < deer_> <newsbyte> crash?</p>
-14:14 < deer_> <newsbyte> ermm</p>
-14:14 < jrandom> dinoman: it crashes your OS?  the firewall?  I2P?</p>
-14:14 < deer_> <newsbyte> well, wouldn't that explain it, then? ;-)</p>
-14:15 < jrandom> newsbyte: are you running Sygate Personal Firewall?</p>
-14:15 < deer_> <newsbyte> indeed</p>
-14:15 < deer_> <newsbyte> well, not on my router</p>
-14:15 < deer_> <newsbyte> but on the puter, yes</p>
-14:15 < deer_> <newsbyte> seems we're on to something</p>
-14:16 < deer_> <DrWoo> newsbyte: /join #i2p-chat so jrandom can get through his meeting</p>
-14:16 < deer_> <newsbyte> though it doesn't crash/freeze immediately, apperently</p>
-14:16 < deer_> <dinoman> os it crashes windows</p>
-14:16 < deer_> <newsbyte> ?</p>
-14:16 < deer_> <newsbyte> jrand is already here</p>
-14:16 < deer_> <dinoman> sorry looked away</p>
-14:16 < jrandom> ok, perhaps we can look into what SPF is b0rking on</p>
-14:16 < jrandom> if there's nothing else on 0.4.1.3, moving on to 2) Tunnel test time, and send processing time</p>
-14:17 < jrandom> there was some discussion yesterday exploring some of the timeouts, and basically things just occationally take too long</p>
-14:17 < jrandom> i dont think the spikes you can see in http://dev.i2p.net/~jrandom/processingTime.png are legitimate though</p>
-14:18 < jrandom> well, they're real - it really does take that long</p>
-14:18 < jrandom> what i mean is, we should be able to get rid of them</p>
-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</p>
-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</p>
-14:20 < jrandom> in general though, the message queueing seems all right, even if it spikes up some tunnel tests</p>
-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</p>
-14:20 < deer_> <Ragnarok> yeah, I don't see why fsck would be useful for jon processing :)</p>
-14:20 < deer_> <Ragnarok> s/jon/job/</p>
-14:21 < jrandom> there is much potential for collaboration, but the two projects have very different aims</p>
-14:21 < jrandom> !thwap Ragnarok</p>
-14:21 < deer_> <newsbyte> ermm</p>
-14:21 < jrandom> oh, one thing I mentioned yesterday </p>
-14:21 < deer_> <newsbyte> I don't think the projects' goals, however, are all that different...</p>
-14:22 < deer_> <DrWoo> jrandom: technical goals</p>
-14:22 < jrandom> newsbyte: we can discuss that in 5) ??? or later if you prefer, we're on 2) right now</p>
-14:22 < deer_> <DrWoo> oops newsbyte: technical goals</p>
-14:22 < deer_> <Ragnarok> hehe</p>
-14:22 < deer_> <newsbyte> yes, and 3)profit! according to /. traditions!</p>
-14:22 < deer_> <newsbyte> :-)</p>
-14:22 < deer_> <Demokritos> I can't believe Tor is not backwards compatible from 0.0.8 to 0.0.8.1</p>
-14:23 < jrandom> with the tunnel testing, there is a floor to the test period - currently set to 5 seconds by default</p>
-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)</p>
-14:23 < deer_> <newsbyte> those seconds, are they alchimagical?</p>
-14:24 < jrandom> the 5s default should be fine though</p>
-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.. </p>
-14:24 < deer_> <Demokritos> oh... hello everyone :)</p>
-14:24 < jrandom> newsbyte: the tunnel test time is MAX(avgTunnelTestTime*2, minTunnelTestTime)</p>
-14:25 < jrandom> (we have the minTunnelTestTime because otherwise a series of fast tests could cause a cascading failure)</p>
-14:26 < jrandom> more details can be found in http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</p>
-14:26 < deer_> <newsbyte> hmm</p>
-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</p>
-14:27 < jrandom> *cough* y'all realize these meeting logs go on the web, right?  :)</p>
-14:27 < deer_> <Demokritos> <-- not too good in english</p>
-14:27 < deer_> <newsbyte> they do?!</p>
-14:27 < deer_> <newsbyte> Hi mum!</p>
-14:27 < deer_> <newsbyte> ;-)</p>
-14:27 < deer_> <Demokritos> um, sorry. .I'm disturbing the meeting.. I'm off</p>
-14:28 < jrandom> naw, please stay, but discuss i2p stuff ;)</p>
-14:28 < deer_> <newsbyte> don't worry; disturbing is an art, just keep an eye on me, and you'll learn</p>
-14:28 < deer_> <newsbyte> ;-)</p>
-14:28 < jrandom> ok, anything else on 2) Tunnel test time, and send processing time ?</p>
-14:28 < deer_> <Ragnarok> focus people</p>
-14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has quit [Read error: 60 (Operation timed out)]</p>
-14:29 < jrandom> if not, moving on to 3) Streaming lib</p>
-14:29 < jrandom> as mentioned in the status notes, lots of progress</p>
-14:29 -!- znation [~znation@ip68-226-31-250.tc.ph.cox.net] has joined #i2p</p>
-14:29 < deer_> <newsbyte> done by you?</p>
-14:29 < jrandom> still not there yet, but I hope to be doing some live tests in the next week</p>
-14:30 < jrandom> i've been working on the streaming lib, yeah</p>
-14:30 < jrandom> i finally got it ping()ing earlier today ;)</p>
-14:30 < deer_> <Ragnarok> nice :)</p>
-14:31 < jrandom> ok, i dont really have anything else to add about that</p>
-14:31 < jrandom> anyone have any questions / comments / concerns?</p>
-14:31 < deer_> <newsbyte> ermm...speed?</p>
-14:31 < jrandom> speed is fine</p>
-14:31 < deer_> <baffled> what type of speed up/through put do you expect?</p>
-14:31 < jrandom> i expect significant throughput improvements</p>
-14:32 < deer_> <newsbyte> he expects a fine, he said</p>
-14:32 < deer_> <newsbyte> for speeding</p>
-14:32 < deer_> <newsbyte> ;-)</p>
-14:32 < jrandom> in addition, for small request/response connections, the latency will be dramatically reduced</p>
-14:32 < jrandom> (cut in half)</p>
-14:32 < deer_> <dinoman> wow</p>
-14:32 < deer_> <dinoman> is that using udp?</p>
-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</p>
-14:33 < jrandom> no dinoman, this works on top of i2p's I2CP</p>
-14:33 < deer_> <dinoman> wow x2</p>
-14:33 < jrandom> (though we'll be writing similar code in a month or so to get the UDP transport..)</p>
-14:34 < jrandom> but, well, we'll see.</p>
-14:34 < deer_> <newsbyte> because...?</p>
-14:34 < jrandom> there's still a lot of work to do</p>
-14:34 < jrandom> because what?</p>
-14:34 < deer_> <newsbyte> well, can't tcp do it as well?</p>
-14:35 < jrandom> oh, why we're going to go UDP?  http://www.i2p.net/todo#transport</p>
-14:35 < deer_> <newsbyte> I remember the same discussion on freenet too, but they sticked to tcp as yet</p>
-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</p>
-14:35 < deer_> <newsbyte> not that all decisions they make are good ;-)</p>
-14:36 < jrandom> newsbyte: i've followed those discussions and we're going to go udp</p>
-14:36 < jrandom> (that doesnt mean freenet is wrong - they've got different constraints)</p>
-14:37 < deer_> <Ragnarok> i2p should not be compared too closely to freenet.  They're very different technically.</p>
-14:37 < deer_> <newsbyte> (or: they ARE wrong ;-)</p>
-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</p>
-14:38 < deer_> <mule_iip> newsbyte makes sure the meetings don't get too short</p>
-14:38 < jrandom> heh</p>
-14:38 < deer_> <newsbyte> yeah, nothing worse then short meetings</p>
-14:38 < deer_> <newsbyte> you can't eat all the popcorn and drink all the beer, then</p>
-14:38 < jrandom> ok, anything else on 3) Streaming lib ?</p>
-14:39 < jrandom> if not, 4) files.i2p</p>
-14:39 < deer_> <Ragnarok> I think we're cool</p>
-14:39 < deer_> <newsbyte> well, I know I am</p>
-14:39 < deer_> <newsbyte> ;-)</p>
-14:39 < deer_> <newsbyte> and funny too</p>
-14:39 < deer_> <newsbyte> most of the time</p>
-14:39 < deer_> <newsbyte> and also annoying</p>
-14:39 < deer_> <newsbyte> ;-)</p>
-14:39 < jrandom> well, i just wanted to point out files.i2p - a new search engine on i2p</p>
-14:40 < deer_> <newsbyte> ah, I see</p>
-14:40 < deer_> <newsbyte> I was hoping it would be about putting eepsites up</p>
-14:40 < jrandom> one interesting thing to note is that you can reach eepsites that aren't up anymore with it, since it caches</p>
-14:41 < deer_> <baffled> does it cache everything?</p>
-14:41 < deer_> <newsbyte> all searchengines thusfar are server-side?</p>
-14:41 < deer_> <Ragnarok> interesting.  Shouldn't be too hard, these days :).</p>
-14:41 < jrandom> baffled: caches text/html from what i can tell</p>
-14:42 < deer_> <mule_iip> at least it has limits on file size and types, so won't cache movies</p>
-14:42 < deer_> <baffled> Auh, that's what I thought not binary.</p>
-14:42 < deer_> <newsbyte> I mean, they are not in js, I suppose?</p>
-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 ;)</p>
-14:43 < jrandom> newsbyte: correct, this is just a normal website hosted anonymously</p>
-14:43 < jrandom> the site contains a search engine (like google)</p>
-14:44 < jrandom> anyway, i just wanted to mention it</p>
-14:44 < jrandom> there have also been a lot of blogs popping up lately, which imho is really cool</p>
-14:44 < jrandom> my 'eep' bookmark folder almost fills a screen :)</p>
-14:44 < deer_> <Ragnarok> hehe, myi2p is happening all by itself :)</p>
-14:45 < jrandom> you just have to bring up the sore points, dont ya ragnarok?  ;)</p>
-14:45 < deer_> <Ragnarok> sorry :)</p>
-14:46 < jrandom> ok, anyone have any questions/comments/concerns wrt files.i2p?</p>
-14:46 < jrandom> if not, let me move on to 4.1) biff</p>
-14:46  * jrandom almost forgot biff</p>
-14:46 < jrandom> postman, you arond?</p>
-14:47 < deer_> <newsbyte> I think he's biffed up</p>
-14:47 < jrandom> well, if not, biff is this new kickass mail notification bot</p>
-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</p>
-14:47 < deer_> <newsbyte> does it has archives?</p>
-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)</p>
-14:48 < jrandom> see http://www.postman.i2p/</p>
-14:49 < jrandom> ok, so, yeah, go to the eepsite or check out #mail.i2p over there</p>
-14:49 < deer_> <newsbyte> I will, as soon as I get my eepsite on</p>
-14:49  * jrandom doesnt really know much more wrt biff - redirect any questions to postman</p>
-14:50 < jrandom> instead, we can move on to 5) ???</p>
-14:50 < deer_> <newsbyte> indeed</p>
-14:50 < jrandom> does anyone have anything else they want to bring up?</p>
-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.</p>
-14:50 < deer_> <newsbyte> yes, and the freeze</p>
-14:50 < jrandom> i hope so mule_iip</p>
-14:50 < deer_> <mule_iip> ok, will be your test platform :)</p>
-14:50 < jrandom> newsbyte: is there anything we need to discuss about it?  could you just email me your logs if it happens again?</p>
-14:51 < jrandom> ooh mule, that'd rule</p>
-14:51  * jrandom will definitelytake you up on that</p>
-14:51 < deer_> <newsbyte> well...can i still send those, if everything is frozen?</p>
-14:51 < jrandom> the files are written to disk.  </p>
-14:51 < jrandom> when you restart, send me the logs</p>
-14:51 < deer_> <newsbyte> I mean, in that case, I could send it now, since they should be somewhere </p>
-14:51 < jrandom> (please)</p>
-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?</p>
-14:51 < jrandom> the files rotate though newsbyte</p>
-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</p>
-14:52 < deer_> <newsbyte> the files rotate? surely it stores quite some data before it starts deleting?</p>
-14:53 < jrandom> newsbyte: ok, send me your logs, maybe it has something in it</p>
-14:53 < deer_> <newsbyte> good</p>
-14:53 < deer_> <newsbyte> ermm</p>
-14:54 < deer_> <newsbyte> darn</p>
-14:54 < deer_> <newsbyte> a lot of .logs</p>
-14:54 < deer_> <dinoman> ok</p>
-14:54 < deer_> <newsbyte> a noob is never gonna follow this</p>
-14:54 < deer_> <newsbyte> I guess you're right in not making a /. article yet</p>
-14:55 < jrandom> we're in no rush</p>
-14:55 < deer_> <newsbyte> log-router.txt?</p>
-14:55 < jrandom> wrapper.log and logs/log-router-*.txt</p>
-14:56 < deer_> <newsbyte> and the mailaddy to use would be...?</p>
-14:56 < deer_> <fidd> dinoman, a jabber server would be cool imo</p>
-14:56 < jrandom> jrandom@i2p.net</p>
-14:56 < deer_> <newsbyte> accessible by i2p, I hope?</p>
-14:56 < deer_> <newsbyte> ;-)</p>
-14:56 < jrandom> newsbyte: you can put your logs on your eepsite and msg me the url</p>
-14:57 < jrandom> or you can send mail to jrandom@mail.i2p</p>
-14:57 < deer_> <newsbyte> indeed!</p>
-14:57 < deer_> <newsbyte> a good idea!</p>
-14:57 < deer_> <newsbyte> there is only one little problem with it: It's not up yet</p>
-14:57 < jrandom> ok, anyone else have anything they want to bring up?</p>
-14:57 < jrandom> well, we can work on that newsbyte</p>
-14:57 < jrandom> (after the meeting)</p>
-14:59 < deer_> <newsbyte> thnks, but whoo is already helping</p>
-14:59 < jrandom> if there's nothing else...</p>
-14:59 < deer_> <newsbyte> we need a detailed howto/wiki/helpsite/something, though</p>
-14:59  * jrandom winds up</p>
-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 </p>
-14:59 < deer_> <newsbyte> what about 6)?</p>
-14:59 < jrandom> newsbyte: would you like to work on that?</p>
-15:00 < jrandom> newsbyte: i do agree it'd be great to get some more howtos and help info</p>
-15:00 < deer_> <Ragnarok> 6) There is no.... number 6</p>
-15:00 < deer_> <newsbyte> well, yeah, sort of, but it's a strange thing, with me</p>
-15:00 < deer_> <newsbyte> I'm pro-wiki and public thingy and free for everyone and all that</p>
-15:00 < deer_> <newsbyte> but my ego protests and wants minimal control</p>
-15:00 < jrandom> great</p>
-15:00 < deer_> <newsbyte> go figger</p>
-15:00 < jrandom> heh</p>
-15:01 < jrandom> well, if you'd like to make your own eepsite into a wiki you control, that'd be great too</p>
-15:01 < deer_> <newsbyte> indeed</p>
-15:01 < jrandom> though ugha.i2p has a pretty good uptime</p>
-15:01 < deer_> <newsbyte> I'll think about it</p>
-15:01 < jrandom> cool</p>
-15:02 < deer_> <newsbyte> 6 would be the freenet-i2p thingy</p>
-15:02  * jrandom winds up </p>
-15:02  * jrandom *baf*s the meeting closed </p>
+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 %}
\ No newline at end of file
+{% endblock %}
diff --git a/i2p2www/meetings/112.rst b/i2p2www/meetings/112.rst
new file mode 100644
index 00000000..810979ca
--- /dev/null
+++ b/i2p2www/meetings/112.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 19, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/113.log b/i2p2www/meetings/113.log
index 08d574f7..28317f3a 100644
--- a/i2p2www/meetings/113.log
+++ b/i2p2www/meetings/113.log
@@ -1,273 +1,267 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 113{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 26, 2004</h3>
-<div class="irclog">
-14:04 < jrandom> 0) hi</p>
-14:04 < jrandom> 1) Net status</p>
-14:04 < jrandom> 2) Streaming lib</p>
-14:04 < jrandom> 3) mail.i2p progress</p>
-14:05 < jrandom> 4) ???</p>
-14:05 < jrandom> 0) hi</p>
-14:05  * jrandom waves</p>
-14:05 < jrandom> weekly status notes posted to http://dev.i2p.net/pipermail/i2p/2004-October/000474.html</p>
-14:06  * jrandom will let y'all read ahead (damn you, read ahead!)</p>
-14:06 < jrandom> jumping in to 1) net status</p>
-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!</p>
-14:07 < jrandom> does anyone have anything they want to bring up about the network status?</p>
-14:08 < modulus> it rules.</p>
-14:08 < deer> <postman> hi</p>
-14:08 < jrandom> w3wt</p>
-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</p>
-14:09 < jrandom> (especially since i haven't done any work on the core since then)</p>
-14:09 < deer> <clayboy> i think everybody agrees that it has been stable and usable.</p>
-14:09 < deer> <clayboy> i miss my 10-16 hours connected time on irc though, not important</p>
-14:10 < deer> <jrandom2p> i'm on for 20h here</p>
-14:10 < deer> <jrandom2p> but yeah, it varies (which hopefully agenda item 2) will help with)</p>
-14:10 < deer> <clayboy> i can hardly get > 2h, but i always reconnect in an instant, so it's still usable</p>
-14:11 < jrandom> cool</p>
-14:11 < jrandom> still not good enough, but sufficient</p>
-14:11 < jrandom> (for the time being)</p>
-14:11 < deer> <clayboy> agreed</p>
-14:12 < jrandom> ok, anyone have anything else, or shall we move on to 2) streaming lib?</p>
-14:13 < jrandom> [consider us moved]</p>
-14:13 < jrandom> the email gives a rundown of how the progress is coming</p>
-14:14 < jrandom> the message sequences are 'correct' in most cases (matching the ones discussed before)</p>
-14:14 < jrandom> e.g. short request/response gets the requestee a response in a single round trip</p>
-14:15 < jrandom> i'm working on the profile=bulk right now, going through the sliding windows under lag and failure conditions</p>
-14:15 < jrandom> still some things to clean up, and nothing ready for use, but its progress</p>
-14:16 < deer> <clayboy> so is 0.4.2 with streaming lib en route for october? it seems like an unnecessary rush.</p>
-14:16 < jrandom> i dont think we'll have the streaming lib ready for final deployment by next week, no</p>
-14:17 < jrandom> so there'll be some schedule slippage, i'm not sure to what extent yet</p>
-14:17 < deer> <duck> any test classes we can run for kicks?</p>
-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</p>
-14:19 < deer> <duck> h0t</p>
-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</p>
-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</p>
-14:21 < jrandom> we don't actually have to fix that right away though - the bandwidth usage on that DeliveryStatusMessage is... trivial</p>
-14:21 < jrandom> but we'll want to sooner rather than later</p>
-14:22 < jrandom> ok, thats all i've got to say on that</p>
-14:22 < jrandom> anyone have anything to bring up wrt the streaming lib?</p>
-14:23 < jrandom> if not, 3) mail.i2p progress</p>
-14:23 < jrandom> postman, you 'round?</p>
-14:23 < deer> <postman> ya</p>
-14:24 < jrandom> any update for us, or shall we wait until there's more news?</p>
-14:24 < deer> <postman> ok</p>
-14:24 < deer> <postman> shall i?</p>
-14:24 < jrandom> the mic is yours</p>
-14:24 < deer> * gott awakens.</p>
-14:24 < deer> <postman> 1.) the in/out proxy facility is being installed/tested atm </p>
-14:25 < deer> <postman> 2.) within the next 10 days we'll have a gateway service from and to the internet for emails</p>
-14:25 < modulus> cool!</p>
-14:25 < jrandom> cool^2!</p>
-14:25 < deer> <clayboy> indeed</p>
-14:25 < deer> <postman> 3.) the implementation will follow the ideas/concepts of the ideas.html document on my websote</p>
-14:25 < deer> <gott> bravo !</p>
-14:26 < deer> <postman> means: hashcash/recipient based quotas and all the fancy stuff</p>
-14:26 < deer> <postman> the service should not be abused by its fellow anonymous users</p>
-14:26 < deer> <postman> :)</p>
-14:26 < deer> <postman> well there'e another point</p>
-14:26 < deer> <postman> the question for webmail interfaces</p>
-14:26 < deer> <postman> right now i don't want to host itz on my servers</p>
-14:27 < deer> <postman> since i don't know about potential security problems</p>
-14:27 < deer> <postman> the system that runs now is verified by me - i know the source and the security risks</p>
-14:28 < deer> <postman> adding php and dynamic stuff and a webmail application FOR ALL users makes it much more difficult </p>
-14:28 < deer> <postman> the idea ( thanks jr) is:</p>
-14:28 < deer> <postman> what if the user got his own webmail interface installed as aonthr optional jetty or whatever instance?</p>
-14:29 < modulus> like a pop3 -> webmail thing?</p>
-14:29 < jrandom> 'zactly</p>
-14:29 < deer> <postman> and this local webmail application uses the postman.i2p tunnels to do smtp and pop3</p>
-14:29 < modulus> sounds good.</p>
-14:29 < deer> <postman> but i need help in evaluating</p>
-14:30 < deer> <postman> right now i am quite busy with real life stuff and the in/out proxies</p>
-14:30 < jrandom> (eww, real life!)</p>
-14:30 < deer> <postman> and i got a peanut sized brain - so i am not good in java at all</p>
-14:31 < deer> <postman> i need sbdy helping how this can be done as a local/optional service </p>
-14:31 < modulus> may there be something that does this already on tcp? if so it could be used.</p>
-14:31 < deer> <DrWoo> postman: I doubt it's peanut sized, I think it takes walnut sized just to breath ;)</p>
-14:32 < jrandom> after a quick glance through hotscripts, i saw one that did pop3, though i dont know if it did authenticated smtp</p>
-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</p>
-14:32 < jrandom> i'm sure there is something out there, we just need an adventurous soul to go find it :)</p>
-14:32 < deer> <postman> jrandom2p: this can be hacked quite easily i think</p>
-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/</p>
-14:33 < deer> <postman> well, i leave this issue to you to think about it :)</p>
-14:33 < modulus> even if it's a stand-alone app, it should be fine, with i2ptunel</p>
-14:33 < jrandom> right modulus </p>
-14:33 < deer> <postman> yep :)</p>
-14:34 < jrandom> and local >> remote, as the local side can do things like access your GPG keyrings or whatever</p>
-14:34 < deer> <postman> i will do anything thats needed to support such a system on the server side</p>
-14:34 < modulus> which hopefully would be very little.</p>
-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</p>
-14:36 < deer> <postman> so much for my department</p>
-14:36 < deer> * postman sits down again and sips on his coffee</p>
-14:36 < modulus> could you do something about filtering anon-revealing data?</p>
-14:36 < jrandom> kickass, thanks postman!  sounds exciting</p>
-14:36 < modulus> some MUAs are very misbehaved in this way.</p>
-14:37 < deer> <postman> modules: please look at the webpage - there is a multipage sermon about that</p>
-14:37 < jrandom> :)</p>
-14:37 < modulus> ok</p>
-14:37 < jrandom> http://www.postman.i2p/sec.html to start</p>
-14:37 < modulus> i read that, i just thought maybe some fields could be filtered.</p>
-14:37 < modulus> maybe i trust postman but not other ppl.</p>
-14:38 < deer> <postman> modulus: They ARE filtred</p>
-14:38 < modulus> ok, last time i treid it they weren't.</p>
-14:38 < modulus> sorry about that.</p>
-14:38 < deer> <postman> modulus: sec2.html describes WHAT headerlines are filtered or changed</p>
-14:38 < deer> <postman> modulus: what headerlines are you refrring to?</p>
-14:38 < modulus> from domain (IP) kind of thing</p>
-14:39 < jrandom> it would be good if a local webmail script did the filtering locally</p>
-14:39 < jrandom> (in addition to any filtering done @ smtp.postman.i2p)</p>
-14:39 < deer> <postman> modulus: lets talk about that in pm, ok? :)</p>
-14:40 < deer> <postman> jrandom2p: of course - i am happy about every client doing its homework</p>
-14:40 < modulus> sure, sorry.</p>
-14:41 < jrandom> ok, do we have anything else for mail.i2p discussions?</p>
-14:41 < jrandom> if not, 4) ???</p>
-14:41 < deer> * duck has something for #4</p>
-14:42 < jrandom> sup duck?</p>
-14:42 < deer> <duck> the HD of home.duck.i2p blew up</p>
-14:42 < jrandom> (d'oh)</p>
-14:42 < deer> <duck> luckily the hosting accounts were not really used, except for alexandria</p>
-14:42 < deer> <duck> did anybody here leach all the ebooks? :)</p>
-14:43 < deer> <duck> if so, I got some missing so msg me please</p>
-14:43 < jrandom> actually, i think thetower did</p>
-14:43 < deer> <duck> I know that hypercubus also has them</p>
-14:43 < deer> <postman> damn</p>
-14:43 < jrandom> i saw a mirror on his site a while back</p>
-14:43 < deer> <postman> :/</p>
-14:43 < deer> <duck> cool</p>
-14:43 < jrandom> i dont know if it has everything though, or how up to date it was</p>
-14:43 < deer> <duck> alexandria is now on http://duck.i2p/alexandria/</p>
-14:44 < deer> <duck> and I am going back to being ashamed</p>
-14:44 < deer> <duck> .</p>
-14:44 < jrandom> no need to be ashamed, you've provided a kickass free service!</p>
-14:45 < jrandom> perhaps now is the chance for some geocities.i2p site ;)</p>
-14:46 < deer> <duck> oh, I made a yodel webfrontend @ http://duck.i2p/yodel/</p>
-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?</p>
-14:46 < jrandom> ah nice</p>
-14:48  * jrandom notes that thetower's alexandria mirror link 404s</p>
-14:48 < deer> <gott> I have something to suggest.</p>
-14:48 < jrandom> sup gott?</p>
-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.</p>
-14:49 < jrandom> thats a good idea</p>
-14:49 < jrandom> perhaps all three</p>
-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</p>
-14:49 < jrandom> yours is nice w/ the links to the eepsites too</p>
-14:49 < deer> <gott> the one located at http://gott.i2p/sites.html is being kept up-to-date </p>
-14:49 < deer> <gott> and the script is run every day</p>
-14:49 < deer> <gott> I can add optional descriptions to the links ( thanx to baffled's script )</p>
-14:50 < deer> <gott> which would make it an index</p>
-14:50 < jrandom> perhaps it'd be neat to have a "recently added" or "recently removed" marker too?</p>
-14:50 < jrandom> word</p>
-14:51 < deer> <gott> quite good.</p>
-14:51 < deer> <gott> that's all I had to say for now.</p>
-14:51 < deer> <gott> oh, another thing</p>
-14:51 < deer> <gott> snipsnap works well under i2p</p>
-14:52 < deer> <gott> so we might see kuro5hin-style eepsites being brought up sometime a la SCUM</p>
-14:52 < jrandom> kickass</p>
-14:52 < deer> <gott> *except more devious a la SCUM</p>
-14:52 < jrandom> a howto for setting that up would be great</p>
-14:52 < deer> <gott> you put the .war in webapps</p>
-14:52 < deer> <gott> it's pretty straightforward ;-)</p>
-14:53 < deer> <polecat> snipsnap...SCUM...?</p>
-14:53 < jrandom> its really that easy?  booyeah!</p>
-14:53 < jrandom> polecat - http://snipsnap.org/space/start</p>
-14:53 < deer> <gott> I have finished my discourse.</p>
-14:53 < deer> * gott retires.</p>
-14:53 < jrandom> thanks gott</p>
-14:54 < jrandom> nickster was using snipsnap for a while</p>
-14:54 < jrandom> ok, anyone have anything else to bring up?</p>
-14:55  * jrandom notes that we're near the hour mark even *without* newsbyte ;)</p>
-14:55 < deer> <polecat> I like pie!</p>
-14:55 < deer> <gott> I have another thing.</p>
-14:55 < deer> <duck> oh, orz is awake</p>
-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.</p>
-14:55 < deer> <polecat> I wasn't aware this a formal meeting.  Might mention my ideas about name servers...</p>
-14:56 < deer> <duck> I suggest all japanese ppl to check out his eepsite/ircserver</p>
-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.</p>
-14:56 < deer> <gott> it will be on my eeplog and if jrandom thinks good enough, probably featured somewhere on i2p.net</p>
-14:57 < deer> * gott retires again.</p>
-14:57 < deer> <postman> modulus: </p>
-14:57 < jrandom> yeah, orz's site and irc server work great, i just dont know what it says :)</p>
-14:58 < modulus> YES?</p>
-14:58 < modulus> sorry for caps.</p>
-14:58 < deer> <DrWoo> polecat: so about nameserver?</p>
-14:58 < deer> * gott unretires</p>
-14:58 < deer> <gott> duck: does he speak english ?</p>
-14:59 < jrandom> oh polecat, whats up?</p>
-14:59 < jrandom> polecat: we have our weekly meting every tuesday at 9p GMT</p>
-14:59 < deer> <gott> I assume he does to have set everything up so well.</p>
-14:59 < jrandom> (logs posted @ http://www.i2p/meetings once they're done ;)</p>
-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.</p>
-15:00 < jrandom> so a URI-->URL resolver, kinda?</p>
-15:01 < deer> <polecat> That would replace hosts.txt, and eventually replace DNS itself once it supports ipv4 and ipv6.</p>
-15:01 < deer> <polecat> name => hash in the case of i2p.  Like duck.i2p => gobbledygook</p>
-15:02 < jrandom> right right</p>
-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.</p>
-15:03 < deer> <polecat> I was talking about this earlier, and someone mentioned http://distributeddns.sourceforge.net/</p>
-15:03 < deer> <polecat> I haven't had a chance to look at that site though.</p>
-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</p>
-15:05 < deer> <gott> quite good, quite good.</p>
-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</p>
-15:08 < jrandom> i know nano is working on something too - there's some entries @ nano.i2p, though i dont know how thats progressing</p>
-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</p>
-15:08 < deer> <gott> jrandom: I dread the day when hosts.txt or equivalent naming system begins to show << enlarge.your.penis.i2p >></p>
-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.</p>
-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</p>
-15:10 < jrandom> (and that includes I2PTunnel and SAM)</p>
-15:10 < deer> <polecat> Really?  I'll have to look at that too...</p>
-15:11 < jrandom> well, they trade off functionality for security and identity</p>
-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.</p>
-15:11 < jrandom> e.g. the jackboots can kick down $domainOwner's door</p>
-15:11 < jrandom> (and someone can spoof dns without much trouble)</p>
-15:12 < jrandom> but having some sort of name --> location resolution functionality is definitely important</p>
-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.</p>
-15:14 < lucky> ugh.</p>
-15:14 < lucky> Why don't you have deer block gott out?</p>
-15:14 < jrandom> there are many tradeoffs</p>
-15:14 < jrandom> i've outlined my preference at http://dev.i2p.net/pipermail/i2p/2004-February/000135.html</p>
-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 :)</p>
-15:15 < lucky> heh.  I thought that was in response to the Gott question.</p>
-15:15 < jrandom> heh</p>
-15:15 < jrandom> naw, gott has been contributing positively as of late</p>
-15:16 < jrandom> ok, in any case polecat, you should put up an eepsite with your ideas</p>
-15:16 < lucky> god, what is the world coming to?</p>
-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.</p>
-15:16 < lucky> Oh, how can i contribute?</p>
-15:16 < lucky> I know some java know.  Like variable assigning.</p>
-15:16 < lucky> And what ++j means</p>
-15:17 < deer> <polecat> Ugh... an eepsite...</p>
-15:17 < deer> <polecat> ++j is the post-increment operator on variable j?</p>
-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?</p>
-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.</p>
-15:19 < jrandom> 'k, then its prolly best to have the naming stuff on the forum instead of an eepsite :)</p>
-15:20 < deer> <polecat> Where's the forum again...?</p>
-15:20 < jrandom> http://forum.i2p/</p>
-15:20 < jrandom> and http://forum.i2p.net/</p>
-15:20 < jrandom> (isnt naming wonderful?  :)</p>
-15:21 < deer> <gott> I have always contributed positively.</p>
-15:21 < deer> <polecat> Yes, except we all still wget the hosts.txt file from a centralized sources.  ;3</p>
-15:22  * jrandom uses cp, not wget ;)</p>
-15:22 < jrandom> ok, anyone have anything else to bring up?</p>
-15:23  * jrandom doesnt mean to shut down the naming discussion, its just that we can discuss that for weeks on end</p>
-15:23 < deer> <DrWoo> dinoman is working on a cvs server in i2p?</p>
-15:23 < jrandom> well, there already *is* a cvs server in i2p (cvs.i2p)</p>
-15:24 < jrandom> but thats right - dinoman was working on a full blown gforge in i2p iirc</p>
-15:24 < deer> <DrWoo> jrandom: sorryt,I mean a fully anonymous cvs ;)</p>
-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</p>
-15:25 < jrandom> (and having a gforge on i2p would Kick Ass)</p>
-15:26 < deer> <DrWoo> jrandom: doesn't cvs.i2p run on the public server?</p>
-15:26 < deer> <polecat> gforge... dunno that...</p>
-15:27 < jrandom> DrWoo: maaaybe ;)</p>
-15:27 < jrandom> DrWoo: but the key is that developers can be anonymous and develop for i2p through i2p</p>
-15:27 < jrandom> if the machine that cvs.i2p is physically located on is under attack, we can just move the destination somewhere else</p>
-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.</p>
-15:28 < jrandom> let 'em have the source, its free!  :)</p>
-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</p>
-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 </p>
-15:30 < jrandom> (and *not* tell peole that cvs.i2p == cvs.i2p.net ;)</p>
-15:32 < jrandom> ok, anyone else have soemthing to bring up for the meeting?</p>
-15:32 < deer> <polecat> Hee, that's pretty cool.</p>
-15:33 < jrandom> if not</p>
-15:33  * jrandom winds up</p>
-15:34  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/113.rst b/i2p2www/meetings/113.rst
new file mode 100644
index 00000000..dd1384d0
--- /dev/null
+++ b/i2p2www/meetings/113.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 26, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/114.log b/i2p2www/meetings/114.log
index fe3717ad..a54d7eb0 100644
--- a/i2p2www/meetings/114.log
+++ b/i2p2www/meetings/114.log
@@ -1,404 +1,398 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 114{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 2, 2004</h3>
-<div class="irclog">
-13:37 < jrandom> 0) hi</p>
-13:37 < jrandom> 1) Net status</p>
-13:37 < jrandom> 2) Core updates</p>
-13:37 < jrandom> 3) Streaming lib</p>
-13:37 < jrandom> 4) mail.i2p progress</p>
-13:38 < jrandom> 5) BT progress</p>
-13:38 < jrandom> 6) ???</p>
-13:38 < jrandom> 0) hi</p>
-13:38 < jrandom> sorry for the delay, weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2004-November/000477.html</p>
-13:38 < dm> meeting in 24 or 84?</p>
-13:38 < jrandom> 0</p>
-13:38 < dm> oh.. -36?</p>
-13:39 < jrandom> yup, 9p GMT</p>
-13:39 < jrandom> but i forgot that, so we're starting... now ;)</p>
-13:39 < jrandom> 1) net status</p>
-13:39 < dm> good timing</p>
-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?</p>
-13:41 < jrandom> if not, might as well move on to 2) core updates</p>
-13:41 < jrandom> i dont really have anything to add beyond whats in the email, so i'll give people a min to digest</p>
-13:42 < deer> <postman> arg</p>
-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</p>
-13:43 < deer> <jrandom> wb, its looking a bit bumpy over here</p>
-13:43 < deer> <postman> np, i am back :)</p>
-13:43 < protok0l> any word on aum's disappearance? i want stasher!</p>
-13:44  * dm likes knowing that stuff is being done under the hood to optimize I2P</p>
-13:44 < jrandom> as gott quoted, diy, do or die</p>
-13:45 < jrandom> yeah, the memory churn was getting to be a substantial portion of the CPU time</p>
-13:45 < jrandom> so it was finally worth the effort to optimize</p>
-13:45 < deer> <baffled> Sorry, have to catch a bus I'll read the logs later night.</p>
-13:45 < deer> <peer> hi just a bug report</p>
-13:45 < jrandom> (as its cut down streaming lib test time by a factor of 5)</p>
-13:45 < jrandom> cool baffled, ttyl</p>
-13:46 < deer> <peer> when your net connection goes down, i2p dies</p>
-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.</p>
-13:46 < deer> * postman noticed this too a few days ago</p>
-13:46 < deer> <postman> one of my servers lost its link</p>
-13:46 < deer> <postman> for a few mins - after that i2p was good for a complete restart</p>
-13:46 < jrandom> dies, as in, the JVM stops, or the router stops talking to peers?</p>
-13:47 < jrandom> (it obviously stops talking to peers, i mean, after the net is back up, does it recover?)</p>
-13:47 < deer> <postman> jrandom: in my case jvm was still running - but no connection lead to success for about 15 minutes</p>
-13:47 < deer> <postman> jrandom: after that i restarted</p>
-13:47 < jrandom> hmm, ok, cool</p>
-13:48 < jrandom> thanks peer, postman.  i'll do some debugging down there</p>
-13:48 < jrandom> what OSes, btw?</p>
-13:48 < deer> <postman> jrandom: np - wanted to write you a mail  but forgeot</p>
-13:49 < deer> <postman> jrandom: Linux 2.4.recent - glibc2.3.recent jvm 1.4.05</p>
-13:49  * jrandom suspects that this week will be the week of "break shit and make i2p handle it better"</p>
-13:49 < jrandom> word</p>
-13:50 < deer> <peer> jrandom: in my case the jvm went completely</p>
-13:50 < jrandom> did it say OutOfMemory or have any CRIT messages?  or did it create a hs_* file inyour i2p install dir?</p>
-13:52 < jrandom> perhaps we could dig through the details later, after the meeting</p>
-13:52 < jrandom> does anyone have anything else on 2) core updates?</p>
-13:52 < jrandom> if not, on to 3) streaming lib</p>
-13:53 < dm> yeah</p>
-13:53 < dm> this increased latency</p>
-13:53 < dm> do you have an estimated % increase per hop?</p>
-13:53 < dm> we talking a couple % points or 30-40%?</p>
-13:53 < jrandom> none, its just some situations it didn't send through an outbound tunnel</p>
-13:54 < dm> so negligeable... 'kay</p>
-13:54 < dm> (on average)</p>
-13:54 < dm> 3)</p>
-13:54 < jrandom> 0% per hop, but its as if the peer you talk to has tunnels 1 hop longer than before (on average)</p>
-13:55 < jrandom> not many real visible updates for the streaming lib so far</p>
-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</p>
-13:55 < dm> oh throughput numbers!!!</p>
-13:57 < dm> ping</p>
-13:57 < deer> <Natalia> .</p>
-13:57 < jrandom> well, it varied on the message size and per-hop latency injected, but preliminary throughput has been 2-5x faster</p>
-13:57 < jrandom> it has been CPU bound though</p>
-13:57 < dm> hmmm, not bad.</p>
-13:58 < dm> cpu at which end?</p>
-13:58 < jrandom> the big benefit is in the reduction of data retransmission and the virtual elimination of failure ;)</p>
-13:59 < jrandom> dm: these tests were done with the sim, injecting random delays per hop</p>
-13:59 < jrandom> (e.g. 400ms each time, or 1000ms, or 2000ms)</p>
-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?</p>
-13:59 < jrandom> (well, the *big* benefit is the sliding window and reordering, but reduction of retransmit is good)</p>
-14:00 < jrandom> not sure i understand</p>
-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.</p>
-14:00 < jrandom> (and the transfer rates were much higher than 30KBps, but again, this was local-only with random injected delays)</p>
-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.</p>
-14:01 < dm> I guess it's not specific to abusing the streaming lib.</p>
-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</p>
-14:02 < dm> ah alright, I thought the cpu was maxed with one router trying to encrypt all the bits going down the pipe.</p>
-14:02 < jrandom> nah, encryption is ReallyReallyFast</p>
-14:03 < dm> coo'</p>
-14:03 < jrandom> ok, anyone else have any questions wrt the streaming lib progress?</p>
-14:03 < jrandom> if not, 4) mail.i2p progress</p>
-14:04 < deer> <jrandom> postman, you 'round?</p>
-14:04 < deer> <postman> yo :)</p>
-14:04 < deer> <postman> ok</p>
-14:04 < deer> * postman waves</p>
-14:05 < deer> <postman> well, gentlemen. Some of you may have noticed that we have finally implemented in/out services</p>
-14:05 < jrandom> [w00t!]</p>
-14:05 < deer> <postman> please reas www.postman.i2p/inout.html</p>
-14:05 < deer> <postman> please test the system out</p>
-14:06 < deer> <postman> baffled will deliver the 2nd official mx</p>
-14:06 < jrandom> word</p>
-14:06 < deer> <postman> right now i am working on IMAP implementation</p>
-14:07 < deer> <postman> this means a switch to maildir format soon</p>
-14:07 < jrandom> we'll need to recheck various clients for that though, right?</p>
-14:07 < deer> <postman> right now i am evaluating/testing</p>
-14:07 < jrandom> cool</p>
-14:07 < deer> <Natalia> why IMAP and not pop3 ?</p>
-14:07 < deer> <postman> yeah, and the serverside as well</p>
-14:08 < deer> <postman> Natalia: we have pop3 already</p>
-14:08 < deer> <postman> pop3 can be used of course </p>
-14:08 < deer> <postman> IMAP4 will make us more flexible for webmail systems (hopefully)</p>
-14:10 < deer> <postman> this is still open issue</p>
-14:10 < deer> <Natalia> okay.</p>
-14:10 < deer> <Natalia> you sounded like you were going to switch from pop3 to IMAP</p>
-14:11 < deer> <postman> no, of course not</p>
-14:11 < deer> <postman> jrandom: are there any news concerning locally run webmail?</p>
-14:12 < jrandom> not to my knowledge.  i havent had time to look into it at all</p>
-14:12 < deer> * postman neither</p>
-14:12 < jrandom> there were those discussions of atmail, but they're closed source</p>
-14:12 < deer> <postman> mmh, yes</p>
-14:13 < deer> <postman> but something jspish ?</p>
-14:13 < jrandom> 'twould be a really great way for a volunteer to jump in and do some legword :)</p>
-14:13 < deer> <Natalia> well, I've added this description to gott.i2p/sites.html</p>
-14:13 < deer> * postman is completely unable to do research on that matter</p>
-14:13 < deer> <Natalia> for www.postman.i2p</p>
-14:13 < deer> <Natalia> postman runs i2p's first mail-service, providing free and anonymous pop3 and SMTP </p>
-14:13 < deer> <Natalia> accounts over i2p. Recently implemented is the ability to send and receive e-mails to and </p>
-14:13 < deer> <Natalia> from outside of the i2p network, marking the services of www.postman.i2p as a nifty </p>
-14:13 < deer> <Natalia> destination for any concerned e-mailer and soon a must-have, as mail.i2p e-mail accounts </p>
-14:13 < deer> <Natalia> become the norm for eepsite-authors.</p>
-14:14 < deer> <Natalia> sound good ?</p>
-14:14 < deer> <postman> thanks Natalia :)</p>
-14:14 < deer> <postman> jrandom: i think it's not a urgent issue</p>
-14:14 < deer> * Natalia curtsies :)</p>
-14:15 < deer> <postman> jrandom: maybe we pick up the webmail issue later again :)</p>
-14:15 < jrandom> agreed postman</p>
-14:15 < deer> <postman> that's all from my side , thanks :)</p>
-14:15 < jrandom> word, thanks postman</p>
-14:15 < deer> * postman curtsie too and sits down again</p>
-14:15 < jrandom> ok, anything else on that, or shall we move on to 5) BT progress?</p>
-14:16 < deer> <jrandom> dinoman: you 'round?</p>
-14:16 < dm> Yeah, I'm still waiting for BT to reactivate my ADSL</p>
-14:16 < jrandom> !thwap</p>
-14:17 < deer> <duck> dino has done some good work</p>
-14:17 < deer> <duck> with Ragnarok to fix some ends</p>
-14:17 < deer> <duck> so far it looks like the current problems are:</p>
-14:17 < deer> <duck> - SAM unreliability</p>
-14:17 < deer> <duck> - Python SAM library issues</p>
-14:17 < deer> <duck> - Incorrect usage of the Python SAM lib</p>
-14:18 < deer> <duck> - Correct handleing of destination instead of host/ip/port</p>
-14:18 < deer> <duck> once those are fixed it should work</p>
-14:18 < jrandom> cool</p>
-14:19 < deer> <duck> I think it is needed to take a little step back though</p>
-14:19 < deer> <duck> and agree on how to modify the protocol to properly handle destinations</p>
-14:19 < deer> <duck> it will be incompatible anyway, so better break it good</p>
-14:19 < jrandom> i concur</p>
-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</p>
-14:20 < deer> <duck> each peer has an unique peer_id of 20 bytes</p>
-14:20 < deer> <duck> it is normally derived from the host/ip</p>
-14:21 < deer> <duck> I think that using the full destination is a bit much</p>
-14:21 < deer> <duck> what globally unique thing should we use?</p>
-14:21 < jrandom> SHA1(destination)[0:19]</p>
-14:21 < jrandom> perhaps?</p>
-14:21 < deer> <Ragnarok> first twenty bytes of the dest? :)</p>
-14:22 < deer> <duck> a sha1 hash is 20 bytes</p>
-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</p>
-14:22 < jrandom> even better </p>
-14:22 < deer> <dinoman> if you lose the key how do peers find one another</p>
-14:22 < jrandom> a peer *is* a key</p>
-14:23 < jrandom> oh</p>
-14:23  * jrandom misinterpreted</p>
-14:23 < jrandom> the tracker must give peers the full destination, not the SHA1(destination)</p>
-14:24 < jrandom> is that the same peer_id in question?</p>
-14:24 < deer> <dinoman> i have fixed the php tracker to send the full key as the ip</p>
-14:24 < deer> <duck> actually the client generates the peer_id</p>
-14:24 < deer> <duck> (what do you mean with 'key'?)</p>
-14:25 < deer> <dinoman> destination</p>
-14:25 < dm> Sounds like a who's on first skit.</p>
-14:25 < dm> Use full sentences people!</p>
-14:26 < deer> <dinoman> ok fine :/ the tracker sends the Full destination as the ip</p>
-14:27 < jrandom> heh dont mind dm.  sounds great</p>
-14:27 < deer> <dinoman> peer id is just for the trackers</p>
-14:27 < deer> <duck> maybe we could use #i2p-bt</p>
-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</p>
-14:28 < deer> <duck> so no religious wars start each time the name of the snake is dropped</p>
-14:29 < deer> <dinoman> works for me</p>
-14:29 < deer> <dinoman> i don't war if it works it works</p>
-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)</p>
-14:29 < deer> <duck> definitly</p>
-14:30 < deer> <dinoman> jrandom you got it</p>
-14:31 < deer> <dinoman> this is the sample output of the tracker 8:intervali300e12:min intervali30e5:peersld2:ip50:klkjlkfsdjfkljkfdhjkddfsjkldsfjlkjfdlkjsfdl;kj;sdf7:peer</p>
-14:31 < dm> copy/pastes jrandom's sentence into notepad and saves as "draft.txt"</p>
-14:31 < cat-a-puss> will bt over i2p be intercompatible with other clients that are not over i2p?</p>
-14:31 < jrandom> cool dinoman</p>
-14:31 < deer> <dinoman> at ip50 you will see a junk key</p>
-14:32 < jrandom> cat-a-puss: yes</p>
-14:32 < deer> <dinoman> yes</p>
-14:32 < cat-a-puss> then we should talk</p>
-14:32 < jrandom> welcome to the weekly meeting!  :)</p>
-14:32 < deer> <dinoman> it will need to be something like .i2ptorrent to make it live togeter</p>
-14:32 < deer> <dinoman> for filenames and links and what not</p>
-14:33 < jrandom> are you working on something similar cat-a-puss, or have some ideas for improvements?</p>
-14:33 < cat-a-puss> working on something similar</p>
-14:33 < cat-a-puss> in java</p>
-14:33 < jrandom> cool</p>
-14:34 < jrandom> is it necessarily java specific, or can some peers be in other langs?</p>
-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</p>
-14:35 < deer> <duck> right</p>
-14:35 < deer> <duck> lets use ugha.i2p to write up some specs</p>
-14:35 < deer> <duck> .</p>
-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?</p>
-14:35 < jrandom> or ugha.i2p, of course</p>
-14:36 < jrandom> (while we work through some bugs in the sam impl and libs :)</p>
-14:36 < deer> <duck> makes it all a challenge</p>
-14:37 < deer> <dinoman> hehe ok</p>
-14:38 < deer> <duck> ...</p>
-14:38 < deer> <duck> mo bt?</p>
-14:38 < deer> * dinoman gets back to work on Savane</p>
-14:39 < jrandom> http://ugha.i2p/SwarmingTransfer / http://ugha.ath.cx/SwarmingTransfer</p>
-14:39 < jrandom> word</p>
-14:39 < jrandom> ok, anything else on 5) BT progress?</p>
-14:39 < jrandom> or shall we hit 6) ???</p>
-14:39 < jrandom> and ask dinoman how the Savane progress is coming?  :)</p>
-14:40 < deer> * jrandom cracks whip</p>
-14:40 < deer> <dinoman> mail i am stuck on using the i2p mail system</p>
-14:40 < deer> <dinoman> i think i should just take the mail out</p>
-14:40 < jrandom> is there any way to tell it to use the SMTP server at a different port?</p>
-14:40 < jrandom> or is the problem authenticated SMTP?</p>
-14:41 < deer> <dinoman> auth</p>
-14:41 < protok0l> Uptime: 5d</p>
-14:41 < protok0l> ii own</p>
-14:41 < deer> <dinoman> it is not in the class Savane uses</p>
-14:42 < deer> <dinoman> i can put it in </p>
-14:42 < protok0l> i'm "Ident: pxEI" can someone tell me my rating</p>
-14:42 < jrandom> ok, i bet we can just get postman to set you up with a custom SMTP destination that doesnt require authentication</p>
-14:42 < dm> I give you a 6/10</p>
-14:42 < dm> You could work on your ass a bit</p>
-14:42 < janonymous1> Whats savana</p>
-14:43 < jrandom> janonymous1: its like sourceforge</p>
-14:43 < deer> <dinoman> because i am looking at the I2P Public Domain Software Homepage in my browser now</p>
-14:43 < jrandom> w00t</p>
-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</p>
-14:45 < deer> <dinoman> that is what bugs me</p>
-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</p>
-14:45 < janonymous1> Cool</p>
-14:46 < jrandom> but yeah, it'd be great to have authenticated SMTP support to prevent that</p>
-14:46 < jrandom> i dont know how much work that'd be though</p>
-14:46 < protok0l> well im glad i left my mailserver idea to postman</p>
-14:46 < protok0l> it seem more difficult than i imagined</p>
-14:47 < deer> <Ch0Hag> I wouldn't mind helping with that</p>
-14:47 < dm> protocol</p>
-14:47 < deer> <Ch0Hag> Got to do something. :-)</p>
-14:47 < deer> <dinoman> i will do auth :( it will take a little time but i will do it</p>
-14:47 < deer> <protokol> yes dm</p>
-14:48 < jrandom> see, you've got a volunteer already dinoman!  :)</p>
-14:48 < deer> <protokol> maybe i could host a nessus server</p>
-14:48 < deer> <protokol> and tunnel it through TOR on my side</p>
-14:49 < deer> <Ch0Hag> Plus I need a  good excuse to work on the rest of  my network.</p>
-14:49 < deer> <protokol> and i shall dedicate myself to learning python</p>
-14:49 < janonymous1> 'the i2p software foundation'.  I can see it now</p>
-14:49 < deer> <protokol> and how to correctly type</p>
-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.</p>
-14:50 < jrandom> ok, anyone else have anything to bring up for 6) ??? </p>
-14:50 < dm> 7) $$$</p>
-14:51 < duck> Roger Dingledine (arma @ freenode) published a draft for a chapter of an upcoming O'Reilly book</p>
-14:51 < duck> http://freehaven.net/doc/wupss04/usability.pdf</p>
-14:51 < jrandom> ah, yeah, its pretty good</p>
-14:51 < duck> it is about anonymity and usability</p>
-14:51 < dm> chapter on usability?</p>
-14:51 < deer> <protokol> i can run the i2p software foundation</p>
-14:51 < deer> <protokol> lol</p>
-14:51 < duck> some interesting parts about negative imago</p>
-14:52 < deer> <protokol> give me the keys the the treasury</p>
-14:52 < duck> having good default</p>
-14:52 < deer> <protokol> NOW!</p>
-14:52 < duck> etc</p>
-14:52 < duck> .</p>
-14:52 < jrandom> and the importance of usability, even over security at times</p>
-14:52 < dm> protok0l: you're the user advocate aren't you? You should read that document.</p>
-14:52 < jrandom> 'k, anything else for the meeting?</p>
-14:52 < deer> <protokol> wow, im seeing 83 peers</p>
-14:52 < duck> now we know why there are so few known hidden sides on tor</p>
-14:53 < deer> <protokol> dm: i shall</p>
-14:53 < duck> arma is affraid for negative imago</p>
-14:53 < duck> .</p>
-14:53 < dm> "imago" ?</p>
-14:53 < duck> image</p>
-14:53 < deer> <duck> (psychoanalysis) an idealized image of someone</p>
-14:53 < dm> No mention of I2P in there :(</p>
-14:53 < duck> jrandom: aint we?</p>
-14:54 < jrandom> hm?</p>
-14:54 < dm> he means aren't we. He's dutch.</p>
-14:54 < duck> if some specific group now moves to i2p,</p>
-14:54 < duck> they could keep away much needed other users</p>
-14:55 < jrandom> oh, thats in there?  i didnt see that</p>
-14:55 < duck> no, I am saying that</p>
-14:55 < duck> but it is in there too, more or less</p>
-14:55 < duck> ofcourse andy anarchist doesnt give a fuck</p>
-14:56 < jrandom> well, i do think there is room for both i2p and tor</p>
-14:56 < duck> yes</p>
-14:56 < duck> but what about early negative image on I2P</p>
-14:56 < deer> <Natalia> this is the reason I am forced to be a somewhat mundane female on this IRC channel</p>
-14:56 < protok0l> haha, when i get the word every major anarchist listserv and forum will hear about i2p within a day or 2</p>
-14:56 < jrandom> oh, i dont give a flying fuck about that duck ;)</p>
-14:56 < deer> <Natalia> jrandom doesn't approve of got</p>
-14:56 < deer> <Natalia> *gott</p>
-14:57 < duck> jrandom: yeah, but well</p>
-14:57  * duck counts the amount of anarchy friendly regions on the globe</p>
-14:57 < deer> <Natalia> so I have to be Natalia, the loved female of the channel</p>
-14:57 < deer> <Natalia> ( lame )</p>
-14:57 < duck> somalia?</p>
-14:57 < duck> I bet they have flying fucks there</p>
-14:57 < protok0l> Chiapas, mexica</p>
-14:57 < duck> but not friendly ones</p>
-14:57 < protok0l> mexiico</p>
-14:58 < deer> <Ragnarok> bah, you want to be feminized</p>
-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</p>
-14:58 < duck> k</p>
-14:58 < jrandom> will people do "bad" things with i2p?  yeah</p>
-14:58 < dm> I think we should target joe beergut</p>
-14:58 < protok0l> good luck, i know gott is planning something</p>
-14:58 < protok0l> gott will destroy us</p>
-14:58 < duck> ok</p>
-14:58 < duck> .</p>
-14:58 < jrandom> the only way any worthwhile anonymity or security system can survive is to be content neutral</p>
-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.</p>
-14:59 < duck> just saying that some links placed on http://127.0.0.1:7657/index.jsp could be bad</p>
-14:59 < dm> I2P is about technology.</p>
-14:59 < deer> <Natalia> yes</p>
-14:59 < jrandom> true enough duck</p>
-15:00 < duck> and yes, the sitelist.html will turn into a TFE discussion thing all over</p>
-15:00 < jrandom> well, mmhmm</p>
-15:00 < deer> <Natalia> content neutrality is something I write about in the latest eeplog entry</p>
-15:00 < deer> <Natalia> http://gott.i2p/eeplog.html</p>
-15:01 < jrandom> this is, however, the power of interactive eepsites, like wikis</p>
-15:01 < jrandom> (e.g. having people register their site with a sitelist.py or whatever)</p>
-15:01 < deer> <Natalia> jrandom: do you support not support the idea of eepsite crawlers linking to illegal material, being linked from the frontpage ?</p>
-15:01 < deer> <Natalia> +or</p>
-15:01 < deer> <Natalia> if you were going to link to the sitelist</p>
-15:02 < duck> from a moral point I dont give a flying fuck either</p>
-15:02 < deer> <Natalia> jrandom: none of these are registered</p>
-15:02 < duck> but from an usability point I might</p>
-15:02 < deer> <Natalia> the script checks host.txt</p>
-15:02 < deer> <Natalia> *hosts.txt</p>
-15:02 < jrandom> from a nontechnical perspective, i support whatever the user community requires</p>
-15:02 < deer> <Natalia> so everyone gets added to the list if they have a domain</p>
-15:03 < deer> <Natalia> ugh, bras are so uncomfortable.</p>
-15:03 < protok0l> yup, creepy</p>
-15:03 < deer> <cervantes> have you _seen_ the user community?</p>
-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.</p>
-15:04 < deer> <cervantes> :)</p>
-15:04 < protok0l> gott is a serial killer, i know it. he will be the first to offer live murders via webcam on i2p</p>
-15:04 < deer> <Natalia> the user community consists of rather strange people.</p>
-15:04 < jrandom> good point cat-a-puss, we could just link to files.i2p </p>
-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.</p>
-15:04 < duck> cat-a-puss++</p>
-15:04 < deer> <Natalia> we are united through common adventure.</p>
-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</p>
-15:06 < deer> <Natalia> well.</p>
-15:06 < deer> <cervantes> lets hope DrWoo can keep his indices free of corruption</p>
-15:06 < jrandom> certainly BS314159 </p>
-15:06 < BS314159> not versions. distributions.</p>
-15:06 < deer> <Natalia> files.i2p should be one link</p>
-15:06 < jrandom> BS314159: people can even edit their own local link page</p>
-15:06 < deer> <Natalia> and then there should be a yahoo-style internet directory link</p>
-15:06 < protok0l> most people will be wise enuf to use the official version</p>
-15:06 < jrandom> (in docs/readme.html)</p>
-15:07 < deer> <Natalia> search engines and internet directories serve different roles</p>
-15:07 < deer> <Natalia> this is why the directory is there in the first place</p>
-15:07 < deer> <Natalia> it has been requested as independent of a search engine</p>
-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</p>
-15:07 < protok0l> unless they are willing to search for backdoors in third-party versions</p>
-15:07 < deer> <Natalia> by people</p>
-15:07 < deer> <Natalia> so I think the search-engine is good</p>
-15:07 < jrandom> right BS314159 </p>
-15:07 < deer> <Natalia> but should not be the limit</p>
-15:07 < deer> <Natalia> search engine, internet directory, wiki, help page</p>
-15:07 < deer> <Natalia> perhaps.</p>
-15:08 < jrandom> we already link to fproxy.i2p, and we know what scary evil content they have on that site ;)</p>
-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?</p>
-15:08 < BS314159> I have a feeling I'm not on topic</p>
-15:08 < protok0l> is the meeting still on?</p>
-15:08 < jrandom> yes protok0l </p>
-15:08 < BS314159> sorry. (silences self)</p>
-15:08 < deer> <Natalia> jrandom: perhaps you shouldn't link to fproxy.i2p</p>
-15:08 < deer> <Natalia> it is almost always down</p>
-15:08 < jrandom> BS314159: i think a cntent filter in the search engine is excessive</p>
-15:08 < deer> <Natalia> it is down right now, it seems</p>
-15:09 < protok0l> it is</p>
-15:09 < deer> <Natalia> according to the recent run of the site-checking script</p>
-15:09 < jrandom> 'k</p>
-15:09 < jrandom> well, this has been a good discussion, lots of good ideas</p>
-15:09 < BS314159> not _the_ search engine. _someone_'s search engine</p>
-15:10 < deer> * Natalia smiles.</p>
-15:10 < deer> <cervantes> BS3: aol.i2p ;-)</p>
-15:10 < jrandom> ok, is there anything else for the meeting?</p>
-15:10 < deer> <cervantes> whoa...still in the meeting...</p>
-15:11 < deer> <cervantes> thought I'd missed that by an hour</p>
-15:11 < jrandom> nope, i was late</p>
-15:11 < jrandom> ok, if not..</p>
-15:11  * jrandom winds up</p>
-15:11  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/114.rst b/i2p2www/meetings/114.rst
new file mode 100644
index 00000000..7379c2f0
--- /dev/null
+++ b/i2p2www/meetings/114.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 2, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/115.log b/i2p2www/meetings/115.log
index 42b035e2..bdd3fa46 100644
--- a/i2p2www/meetings/115.log
+++ b/i2p2www/meetings/115.log
@@ -1,523 +1,517 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 115{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 9, 2004</h3>
-<div class="irclog">
-13:26 < jrandom> 0) hi</p>
-13:26 < cervantes> lets see the menu before we order :P</p>
-13:26 < jrandom> 1) 0.4.1.4</p>
-13:26 < jrandom> 2) Streaming lib</p>
-13:26 < jrandom> 3) BT progress</p>
-13:26 < jrandom> 4) addressbook.py</p>
-13:26 < jrandom> 5) ???</p>
-13:26 < jrandom> 0) hi</p>
-13:27  * jrandom waves</p>
-13:27 < Ragnarok> hi</p>
-13:27  * cervantes waves</p>
-13:27 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000485.html</p>
-13:27 < keysersoze> hi</p>
-13:27 <+polecat> 5) can be DHTs, like that bamboo thing?</p>
-13:27 < jrandom> (yeah, i'm late)</p>
-13:27 < jrandom> cool polecat </p>
-13:27  * polecat nips at fingers again!</p>
-13:27 < jrandom> ok, jumping into 1) 0.4.1.4</p>
-13:28 <+Ch0Hag> 0.4.1.4 seems to die more than it should</p>
-13:28 <+Ch0Hag> like - at all</p>
-13:28 < jrandom> die?</p>
-13:28 <+Ch0Hag> Though there's a chance that's kaffe's fault.</p>
-13:28 < jrandom> drop your irc connection, or restart the router?</p>
-13:28 < jrandom> ah, you're on kaffe?</p>
-13:29 <+Ch0Hag> the router</p>
-13:29 <+Ch0Hag> I am.</p>
-13:29 <+Ch0Hag> Someone has to be :)</p>
-13:29 < jrandom> on kaffe i've had to double the defaul mem usage (give 'er a -mx128m on startup)</p>
-13:29 <+polecat> GAH!  No wonder!  I had hawk on ignore.</p>
-13:29 < jrandom> well, we've got at least 3 people on kaffe these days</p>
-13:30 < jrandom> other than that, though, how is 0.4.1.4 going for y'all?</p>
-13:30  * polecat is on kaffe... doesn't know of a better JVM at the moment.</p>
-13:30 < jrandom> early reports were good, but i havent heard much lately</p>
-13:30 <+Ch0Hag> I had 64, shall try 128</p>
-13:30 < Ragnarok> seems good</p>
-13:30 < keysersoze> jrandom: No major problems here</p>
-13:30 <@duck> latest major irc outage was mine</p>
-13:30 <+Ch0Hag> And yes, much of it was OOMing</p>
-13:31 <@duck> otherwise I think it is a bit unstable (since my bw enabling), but I dont have proof</p>
-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</p>
-13:32 <@duck> ah</p>
-13:32 < jrandom> but i agree, irc has been bumpy </p>
-13:32 < cervantes> 0.4.1.3 has always been rock solid on my ibm jvm, so I've avoided upgrading at this stage</p>
-13:32 < cervantes> (22 days uptime)</p>
-13:32 < jrandom> nice cervantes </p>
-13:32 < jrandom> duck: [insert comment describing hopes for new streaming lib here]</p>
-13:33 < cervantes> baffled's irc server has been a little less bumpy</p>
-13:33 < jrandom> word, thats a good metric</p>
-13:33 < keysersoze> cervantes:  What version does he run? (Do you know?)</p>
-13:33 < ant> <dm> will streaming lib have an effect on IRC, or are the messages too small anyway?</p>
-13:33 <@duck> I have been a good duck this week, so I'll up the limit a bit</p>
-13:33 < jrandom> lemmie check keysersoze </p>
-13:33 < jrandom> :)</p>
-13:33 <+polecat> I've got 11 hours uptime.  ;.;</p>
-13:34 < jrandom> keysersoze: 0.4.1.4</p>
-13:34 < keysersoze> jrandom: ;) But one could ask him here when he's around</p>
-13:34 < keysersoze> ok</p>
-13:34 < jrandom> dm: the new streaming lib will improve resiliance and address failures, but obviously won't improve irc throughput</p>
-13:34 < jrandom> (router versions are published in the netDb, and i know which routers are his)</p>
-13:34 < ant> <dm> that's good</p>
-13:35 < jrandom> ok, do we have anythingelse for 0.4.1.4?</p>
-13:35 < jrandom> if not, swinging briefly over to 2) streaming lib progress</p>
-13:36 < keysersoze> no</p>
-13:36 < jrandom> as mentioned in the notes, more news when its available :)</p>
-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?</p>
-13:36 < Ragnarok> download large files quickly</p>
-13:36 < Ragnarok> and DOS the network :)</p>
-13:36 < jrandom> polecat: transfer arbitrarily large files, transfer at > 4KBps</p>
-13:37 <+Ch0Hag> and/or reliably?</p>
-13:37 < jrandom> Ragnarok: *not* dos'ing the network is what i'm working on now ;)</p>
-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</p>
-13:37 <+polecat> It would increase the transfer rate?  o.O</p>
-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</p>
-13:37  * polecat nods to protokol, seems so.</p>
-13:38 < ant> <dm> The streaming lib will allow a new class of TCP-based applications to be usable on I2P. </p>
-13:38 < Ragnarok> jrandom: ah, good.  I've been a little concerned about that :)</p>
-13:38 < ant> <dm> That's the marketing version.</p>
-13:38 < jrandom> let me just say that throughput looks promising with the new lib.</p>
-13:39 < jrandom> heh dm</p>
-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?</p>
-13:39 <+polecat> jrandom: Ah, I see how that could be compromising...</p>
-13:39 < jrandom> right keysersoze, up to a (sliding) window size</p>
-13:39 < jrandom> (doing all that congestion control / avoidance stuff) [/arm waving]</p>
-13:40 <+polecat> I also see how it might have congestion problems.  If many packets are sent after a connection is dropped.</p>
-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</p>
-13:40 < jrandom> aye cervantes </p>
-13:41 < jrandom> polecat: thats the biggest danger, preventing a network flood, which is why we're deploying cautiously</p>
-13:41 < ant> <dm> I have a bug to report. Someone remind me when we hit 5.</p>
-13:41 < cervantes> jrandom: from an application point of view, how transparent will the switch over be?</p>
-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?</p>
-13:42 <+polecat> Does 0.4.1.4 use the streaming lib, or has it not yet been deployed?</p>
-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 :)</p>
-13:42 < cervantes> polecat: that will be with us on 0.4.2</p>
-13:42 < ant> * dm everyone rushes towards jrandom.</p>
-13:42 < jrandom> its with you now - see streaming.jar</p>
-13:42 < jrandom> but disabled by default</p>
-13:42 < ant> <dm> "flag! flag! flag!"</p>
-13:43 < keysersoze> jrandom: Ow come on, spoil us and tell which env var ;)</p>
-13:43 < jrandom> however, the streaming lib is *NOT BACKWARDS COMPATIBLE*</p>
-13:43 < jrandom> aka you can't use IRC with it</p>
-13:43 < cervantes> I have an early .1.3 remember ;-)</p>
-13:43 < jrandom> unless duck runs a seperate newStreamingLib destination</p>
-13:43 <+polecat> Yeah... probably best to switch in sync then, not individually.</p>
-13:43 < jrandom> yup</p>
-13:43 <+Ch0Hag> I think this flag is one of those "if you can't find it, you don't need it" ones.</p>
-13:43 < ant> <dm> duck: for the love of god, do as you're told!!!</p>
-13:43 <+Ch0Hag> Like most of GCCs...</p>
-13:43 < jrandom> right Ch0Hag :)</p>
-13:44 < jrandom> dm: still some other things to be tested</p>
-13:44 < jrandom> e.g. this morning mule was helping out test with FUQID</p>
-13:44 < keysersoze> jrandom: Does that influence any of the hosts.txt keys for existing I2P destinations?</p>
-13:44 < mule> missed the meeting. end of daylight savings :(.</p>
-13:44 < jrandom> (and FUQID does eeevil things :)</p>
-13:45 < jrandom> heya mule, me too :)  you're just in time</p>
-13:45 < ant> <dm> mule: you haven't missed section 5) ?????</p>
-13:45 <+Ch0Hag> Oh speaking of fuqid, is there news on stasher?</p>
-13:45 < ant> <dm> for all you know, ???? might be: GOTO 1</p>
-13:45 < jrandom> keysersoze: no, the streaming lib isn't involved in that part of things</p>
-13:45 <+Ch0Hag> Or is  that a big enough topic to wait until 5?</p>
-13:45 < jrandom> Ch0Hag: no one has heard anything from aum since september, and no one else is doing anything on stasher.</p>
-13:46 < jrandom> (but there is other DHT stuff to discuss in 5)??? i hear)</p>
-13:46 <+Ch0Hag> Oh.</p>
-13:46 <+Ch0Hag> Bummer.</p>
-13:46 <+Ch0Hag> The freenet devs didn't have their competition ... removed did they?</p>
-13:46 <+Ch0Hag> :)</p>
-13:46 < jrandom> heh</p>
-13:47 <+polecat> The first application of assassination politics.   x3</p>
-13:47 <+Ch0Hag> Anyway I have nothing else, so I shan't butt in again until 5</p>
-13:47 < jrandom> ok, there's lots going on in the streaming lib, but discussion will have to wait for later</p>
-13:47 < jrandom> unless there's somethingelse, we can move to 3) BT progress</p>
-13:47 < cervantes> </evasion></p>
-13:48 < ant> <dm> Doesn't everyone wish jrandom adopted the toad deployment process?</p>
-13:48 < ant> <dm> Build 3435: streaming lib attempt</p>
-13:48 < jrandom> duck: ping?</p>
-13:48 < ant> <dm> Build 3436: streaming lib attempt 2</p>
-13:48 <@duck> pong</p>
-13:48 < ant> <dm> Build 3436: streaming lib attempt 3</p>
-13:48 < jrandom> be nice</p>
-13:48  * duck takes the mike</p>
-13:48 < Ragnarok> no, no we don't</p>
-13:48 <@duck> dinoman, Ragnarok and me have been working on the BT client.</p>
-13:48 <@duck> - BT protocol analysed and changes specified on http://duck.i2p/i2p-bt/txt/i2p-bt_protocol.txt</p>
-13:48 <@duck> - dino modified phpbt, info at http://duck.i2p/i2p-bt/txt/tracker.txt</p>
-13:48 <@duck> dino got the client to talk with the tracker, R and me have improved it a bit.</p>
-13:48 <@duck> the whole tracker <-> client stuff worked</p>
-13:48 <@duck> but we got stuck at the python sam library...</p>
-13:49 <@duck> Connelly has been helping, but also busy</p>
-13:49 <@duck> and aum is missing</p>
-13:49 <+polecat> I'm still stunned BT can work at all on i2p...</p>
-13:49 <@duck> so I threw out pysam, reimplemented BT's RawServer.py and now it kinda works.</p>
-13:49 < jrandom> (w00t!)</p>
-13:49 <@duck> hot news: channel #i2p-bt (especially topic with latest release info)</p>
-13:49 <@duck> now I am working at adding a lot of logging support, to catch some little flaws</p>
-13:50 < Ragnarok> it's much nicer than the original RawServer.py</p>
-13:50 < peer> duck: so is it ready for beta testing?</p>
-13:50 <@duck> (for example during the EndGame it has to timeout and retry to get the last bits)</p>
-13:50 <@duck> peer: yup</p>
-13:50 <@duck> a little point of discussion:</p>
-13:51 <@duck> so far it is python 2.2 (and up) compatible</p>
-13:51 <@duck> (seems to be the same for bittorrent itself)</p>
-13:51 <@duck> the logging stuff needs 2.3 though...</p>
-13:51 < cervantes> yus indeed</p>
-13:51 <@duck> how bad do you think that is?</p>
-13:51 < jrandom> my freebsd and linux boxen have 2.3</p>
-13:51 < ant> <dm> bad?</p>
-13:52 < jrandom> (though they were installed within the last year)</p>
-13:52 < Ragnarok> are there any major distros still shipping 2.2?</p>
-13:52 <@duck> debian-stable still seems to ship 2.2, last time I checked</p>
-13:52 < jrandom> ah, i'm on debian unstable</p>
-13:52 <@duck> but then again that is hardly a surprise</p>
-13:52 <+Ch0Hag> Debian ships 2.3, 2.2, 2.1 and possibly 2.0</p>
-13:52 <+Ch0Hag> Together.</p>
-13:52 < Ragnarok> except Debian stable, I think...</p>
-13:53 <+Ch0Hag> That's what I'm unsure about.</p>
-13:53 < jrandom> it'd be nice to have 2.2 support - are there no good logging libs for it?</p>
-13:53 < Ragnarok> silly debian</p>
-13:53 <@duck> jrandom: you could bundle the 2.3 lib</p>
-13:54 < Ragnarok> can logging simply be made optional?</p>
-13:54 <@duck> I guess</p>
-13:55 < jrandom> well, its really a coder-productivity-tool, so whatever works best for the people coding</p>
-13:55 < ant> <dm> we can worry about this when I2P + BT becomes popular.</p>
-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?</p>
-13:55 < ant> <dm> by then maybe 2.3 is standard</p>
-13:55 < jrandom> 2.2 support would be nice, but i dont think it'd be that bad if 2.3 were required</p>
-13:55 < cervantes> duck: so the tracker's peer announce list can be made to spew out i2p destinations instead of machine ips?</p>
-13:56 <@duck> ok, we'll try to abstract the logging lib, with 2.2 use stdout</p>
-13:56 <@duck> cervantes: http://duck.i2p/i2p-bt/diffs/phpbt-i2p.diff</p>
-13:56 < jrandom> keysersoze: you want logging deployed on the clients machines so that if/when bugs arise, the dev can get detailed logs</p>
-13:56 < jrandom> word duck</p>
-13:56 < cervantes> ta</p>
-13:56 <+Ch0Hag> heh if anyone's still interested, Woody has python 1.5, 2.0 and 2.1</p>
-13:56 <+Ch0Hag> :)</p>
-13:57 <@duck> heh</p>
-13:57 <@duck> ok, in that case I say require 2.3</p>
-13:57 <@duck> and fuck woody</p>
-13:57 < cervantes> think mine is tuck on 1.5 and 2.2</p>
-13:57 < jrandom> yeah, no need to deal with 2.1</p>
-13:57 < cervantes> (upgrade time)</p>
-13:57 < jrandom> heh</p>
-13:57 <+Ch0Hag> That's the opinion of most Debian users, too</p>
-13:58 < Ragnarok> addressbook.py requires 2.3</p>
-13:58 <@duck> there are some interesting sub projects:</p>
-13:58 < jrandom> ah ok cool Ragnarok </p>
-13:58 <@duck> researching the optimal settings for i2p</p>
-13:58 <+polecat> That little thing requires 2.3?</p>
-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 ;)</p>
-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...</p>
-13:58 <+polecat> Weird... 2.2 must be practically crippled then.</p>
-13:58 < Ragnarok> 2.3 has better urllib proxy support</p>
-13:58 <@duck> porting the standard bt tracker too</p>
-13:58 < cervantes> I mean the seed</p>
-13:59 < Ragnarok> it could work on 2.2, but it'd be too much effort :)</p>
-13:59 <+polecat> Ah that would be important, right.</p>
-13:59 < jrandom> duck: researching the optimal settings will be tough until 0.4.2 comes out</p>
-13:59 <@duck> right</p>
-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?</p>
-14:00 <@duck> whut?</p>
-14:00 < cervantes> the client has tons of nice tweaks for peer takeup rates, timeouts, min/max peers etc</p>
-14:01 < cervantes> jrandom: that shouldn't need any modification I think</p>
-14:01 < jrandom> duck: the .torrent references the i2p destination of the tracker, right?</p>
-14:01 <@duck> right now we ship: btdownloadheadless.py + btmakemetafile.py + btshowmetainfo.py</p>
-14:01 < jrandom> or does it reference the name?</p>
-14:01 < cervantes> it's just a url and a bunch of sha1 hashes</p>
-14:01 <@duck> though btmakemetafile.py and btshowmetainfo.py are not modified</p>
-14:01 < jrandom> "a url" is the tough part :)</p>
-14:02 <@duck> so you can use other tools</p>
-14:02 <@duck> its http://duck.i2p/phpbt/announce.php now</p>
-14:02 < jrandom> ok, cool</p>
-14:02 <@duck> guess you can use http://i2p/bigbase64/announce.php</p>
-14:02 <+protokol> are their plans for other clients to support eepTorrent? i like azureus</p>
-14:02 <@duck> plenty</p>
-14:02 < cervantes> jrandom: the early version I looked at did no url validation on the announce string</p>
-14:03 < ant> <dm> what does eep stand for again?</p>
-14:03 < cervantes> you could put anything in there</p>
-14:03 < jrandom> hmm, worth checking to see if that works duck ( in case phpbt does stupid url rewriting, etc)</p>
-14:03 < cervantes> dm: look in the forum glossary</p>
-14:03 <@duck> maybe its time for an i2p-bt forum?</p>
-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</p>
-14:03 <+Ch0Hag> Eye Eye Pee?</p>
-14:03 < jrandom> that'd be cool duck</p>
-14:03 <@duck> (forum section on forum.i2p)</p>
-14:04 < ant> <dm> cervantes: that was helpful!</p>
-14:04 < cervantes> duck: yeah no probs</p>
-14:04 <@duck> keysersoze: it will be investigated</p>
-14:04 < jrandom> still, as is its pretty bloody cool</p>
-14:05 < jrandom> the 4KBps per peer isn't really that much of a problem either</p>
-14:05 < ant> <dm> what time is it? "There's a clock just two blocks down the road"</p>
-14:05 < cervantes> moving forward oerhaps we should set up a seperate forum space so people can publish files alla suprnova</p>
-14:05 <@duck> eeprnova</p>
-14:05 < jrandom> cervantes: with reviews, etc :)</p>
-14:05 < keysersoze> jrandom: Will the transition to streaminglib require large changes to the current python I2P-BT code?</p>
-14:05 <+polecat> I sure never get more than 4KBps even on IPv4 bittorrent streams...</p>
-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</p>
-14:05 < jrandom> (but i think that'd be best left outside of the forum.i2p, perhaps)</p>
-14:06 < jrandom> keysersoze: 0 changes</p>
-14:06 <@duck> mind you that i2p-bt trackers will scale a lot worse</p>
-14:06 <@duck> since they have to send bloaty big keys</p>
-14:06 < Ragnarok> polecat: you must be natted</p>
-14:06 < keysersoze> polecat: ((OT) try the firefox torrent of today ;))</p>
-14:06 < cervantes> jrandom: yup.</p>
-14:06 <@duck> where the normal trackers are recently modified to only send 6 bytes / peer</p>
-14:06 < jrandom> peer: i2p server address?</p>
-14:07 < jrandom> peer: i use the i2p-bt with my SAM bridge locally accessing a remote router</p>
-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</p>
-14:07 < peer> jrandom: yep</p>
-14:07 < keysersoze> duck: Can we compress the host-key? (Just asking...)</p>
-14:08 < peer> with one cli arg</p>
-14:08 < jrandom> (rather than remodifying the code after every release :)</p>
-14:08 <@duck> keysersoze: using binary instead of base64 will shrink it a bit</p>
-14:08 <@duck> like 15% </p>
-14:08 <@duck> no worth it</p>
-14:08 < keysersoze> duck: I agree.</p>
-14:09 < ant> <dm> cervantes: where is this forum glossary? I don't see anything at http://forum.i2p.net/</p>
-14:09 < Ragnarok> could hostnames be used?</p>
-14:09 < jrandom> Ragnarok: hostnames are not globally unique</p>
-14:09 <@duck> Ragnarok: dont want to go there</p>
-14:09 < cervantes> dm: only shows up for reg'd users</p>
-14:10 < ant> <dm> cervantes: oh excellent! I'll look for eep on google then!</p>
-14:10 < Ragnarok> fair enough</p>
-14:11 < cervantes> dm: it's a phoneme for IIP</p>
-14:11 < cervantes> is the word on the street</p>
-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 :)</p>
-14:11 < ant> <dm> cervantes: not an acronym?</p>
-14:12  * cervantes has 1/2 of a terabyte of movies and tv shows to share</p>
-14:12 < jrandom> do we have anything else wrt i2p-bt to discuss?</p>
-14:12 < cervantes> dm: not that I've heard</p>
-14:12 <@duck> (dont forget #i2p-bt)</p>
-14:12 < jrandom> yeah, #i2p-bt, finally an incentive for people to move from freenode :)</p>
-14:12 < ant> <dm> alrighty. Thank you sir.</p>
-14:13 <+Ch0Hag> As if this Great network wasn't incentive enough already...</p>
-14:13 < jrandom> ok if not, shall we move on to 4) addressbook.py</p>
-14:13 < jrandom> Ragnarok: wanna give us the run down?</p>
-14:13 < Ragnarok> whee</p>
-14:14 < Ragnarok> hm, ok.  addressbook.py is a first stab at a subscribable address book system.</p>
-14:14 < Ragnarok> It's pretty ugly at the moment, but it works</p>
-14:14 < Ragnarok> you can get it at ragnarok.i2p</p>
-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</p>
-14:14 < Ragnarok> um...</p>
-14:14 < Ragnarok> any questions?</p>
-14:15 <+postman> Ragnarok: define ugly :)</p>
-14:15 < jrandom> Ragnarok: kickass</p>
-14:15 < ant> <dm> jrandom: not a question</p>
-14:15 <+polecat> What were we talking about again?  @.@</p>
-14:15 < peer> sort of like the bookmarks on the front page of the freenet web interface, but instead with urls</p>
-14:15 < cervantes> Ragnarok: is it all command line, or is there a gui?</p>
-14:15 < Ragnarok> read it, it's ugly :)</p>
-14:15 < jrandom> peer: agreed, though we need author tools</p>
-14:15 < cervantes> there weren't any screenies so I lost interest and went away ;-)</p>
-14:15 < jrandom> peer: though the ?i2paddresshelper helps</p>
-14:15 <+postman> Ragnarok: ok, thanks - i will check it out</p>
-14:16 <+polecat> Bah, GUIs are for soccer moms!</p>
-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.</p>
-14:16 < Ragnarok> aside from the cli tool, all interactions are through config files.</p>
-14:17 < jrandom> perhaps the next step in the namign field is a web interface for managing the entries and subscriptions?</p>
-14:17 < cervantes> are you basically syndicating your hosts file then?</p>
-14:17 < Ragnarok> yes</p>
-14:17 < cervantes> right...cool</p>
-14:17 < Ragnarok> web interface would be great.  I'm not writing it, though :)</p>
-14:17 < jrandom> with merges and conflict management</p>
-14:18 <+polecat> What is the conflict management, besides yelping about it in the log?</p>
-14:18 < jrandom> yeah, the engine itself is Good Stuff, maybe we can get someone else to jump on the web side of it :)</p>
-14:19 < Ragnarok> none.  If you want to resolve a conflict, you do it by hand :).  Though, it is a bit easier now.</p>
-14:19 < jrandom> polecat: yelp & never overwrite an existing entry afaik</p>
-14:19 < jrandom> (er, what he said)</p>
-14:19 < cervantes> it would be nice as a sidebar plugin for firefox...</p>
-14:19 <+polecat> Yes, that's what I had thought.</p>
-14:19 < cervantes> that's something I could work into my i2p toolbar</p>
-14:20 < Ragnarok> user changes are never overwritten, so it's reasonably secure against attack</p>
-14:20 < jrandom> and you should only subscribe to relatively trustworthy peers</p>
-14:20 < Ragnarok> indeed</p>
-14:20 < cervantes> maybe a feature to lock entries?</p>
-14:20 < cervantes> (ie move them to userhosts)</p>
-14:21 < Ragnarok> entries are are never modified</p>
-14:21 <+polecat> I like the concept of a myhosts.txt file for entries you want to endorse yourself.</p>
-14:21 < cervantes> Ragnarok: ah sorry, so you said</p>
-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 :)</p>
-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</p>
-14:22 < jrandom> (but only if there's a good solid reason to do so)</p>
-14:22 < cervantes> Ragnarok: you were meant to pretend that was intentional ;-)</p>
-14:23  * duck suggest abstracting away from hosts.txt / userhosts.txt</p>
-14:23 <+polecat> My perl version of addressbook.pl supports the myhosts.txt thing.</p>
-14:23 < Ragnarok> yeah, that will be part of the big rewrite :)</p>
-14:23  * polecat notes to duck, you'd have to modify i2ptunnel and sam to do that.</p>
-14:23 < Ragnarok> first, I want to get feature parity on windows, though.</p>
-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)</p>
-14:24 <@duck> polecat: you could write the final result to something called 'hosts.txt'</p>
-14:24 < cervantes> ideally you want a hierachical mini-database of local addresses you can catagorise </p>
-14:24 <@duck> but use some other structure towards the user</p>
-14:24 <+polecat> The final result goes to userhosts.txt</p>
-14:24 <+polecat> And also a file called "hosts.txt" on the eepsite that is not the system hosts.txt.</p>
-14:24 <@duck> which is confusing :)</p>
-14:25 < Ragnarok> I like to be as confusing as possible :)</p>
-14:25 < MrEcho> hope to have the dns done by the end of the month</p>
-14:25 <@duck> ok, then let the name depend on the checksum of the content</p>
-14:25 < cervantes> addressbook.txt? :)</p>
-14:25 < Ragnarok> the published address book is just called hosts.txt, because that's what it is on dev.i2p</p>
-14:25 <+polecat> It's possible to call Ragnarok's hosts.txt file something else.  People just have to subscribe to that other filename.</p>
-14:26 < Ragnarok> true, it's a configuration option</p>
-14:26 <+polecat> i.e. like going http://polecat.i2p/addressbook instead of http://polecat.i2p/hosts.txt</p>
-14:26 < MrEcho> fyi, my dns doesnt touch the hosts file .. just like a real dns</p>
-14:27 <+polecat> Oh yeah, there's that too.  >.<</p>
-14:27 <@duck> my dns causes world peace</p>
-14:27 < jrandom> MrEcho: it might be worthwhile to explore interoperability</p>
-14:27 <+polecat> There's /etc/hosts, jrandom's hosts.txt that i2ptunnel and sam use, and now the hosts.txt published by Ragnarok.</p>
-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 :) </p>
-14:28 < mule> hostile environment :)</p>
-14:28 < MrEcho> i could make it update the hosts text, but i was hoping to add something in other code</p>
-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 ;)</p>
-14:29 <+polecat> ?</p>
-14:29 < MrEcho> already took a look jr</p>
-14:30 < jrandom> polecat: http://forum.i2p.net/viewtopic.php?t=141#419</p>
-14:30 <+polecat> You mean under apps/myi2p/java/src/net/i2p/myi2p</p>
-14:30 < jrandom> well, yeah, if you want to get specific ;)</p>
-14:30 <+polecat> More like hideously redundant.  ;3</p>
-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</p>
-14:31 < jrandom> polecat: with good reason (and imho there's no redundancy in that pathname ;)</p>
-14:31 < Ragnarok> cool.  I'll have a look</p>
-14:32 < ant> <dm> at least it doesn't say internet three times in there anymore</p>
-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</p>
-14:33 <+polecat> Eek!  No, no noo MX records... no CNAME... </p>
-14:33 < jrandom> having multiple destinations per name is a good idea though</p>
-14:33 < ant> <janonymous2> Im partial to an address book/ dns hybrid</p>
-14:34 < jrandom> an address book is a domain name system :)</p>
-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?</p>
-14:34 < jrandom> polecat: not all myi2p code will be in java.</p>
-14:34 <@duck> go back to your cave you perl troll :)</p>
-14:34 <+polecat> I agree that it's all necessary, not blaming you jrandom, but blaming java and ant.</p>
-14:35 < jrandom> polecat: and i2p's codebase is unique under the net.i2p namespace, as we don't control the net.myi2p namespace :)</p>
-14:35  * polecat grunts and crouches under the bridge.</p>
-14:35 < ant> <dm> polecat: it's called OCD</p>
-14:35 < jrandom> heh</p>
-14:35 < jrandom> its called software engineering ;)</p>
-14:36 <+polecat> Yes, but why put everything in a directory structure parroting the namespace?</p>
-14:36 <+polecat> Just specify like... in the file "This file is namespace net.i2p"</p>
-14:36 < jrandom> but anyway, anything else on Ragnarok's kickass naming system?  :)</p>
-14:36 <@duck> it kicks ass</p>
-14:36 < Ragnarok> thank you :)</p>
-14:36 <+polecat> Asseth Kickius.</p>
-14:36 < jrandom> polecat: there are 1340 java files in i2p</p>
-14:37 <@duck> I was _shocked_ when I wanted to visit an eepsite and the host was already propagated</p>
-14:37 < Ragnarok> hehe</p>
-14:37 < jrandom> :)</p>
-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</p>
-14:38 < Ragnarok> does anyone know a command to kill a windows process by pid?</p>
-14:38 <@duck> like TCP stack reimplementations? :)</p>
-14:38 <+polecat> Not to mention fully functional web servers.  c.c</p>
-14:38 < jrandom> heh</p>
-14:38 < jrandom> oh, lemmie skip the jetty code..</p>
-14:39 < keysersoze> (91 peers on the net now!)</p>
-14:39 < ant> <dm> ragnarok: kill</p>
-14:39 < jrandom> ok, 389 in router/ and core/ </p>
-14:39 < Ragnarok> what versions does that exist on?</p>
-14:39 <+polecat> That's still a lot for a lousy router... but considering the all and everything not too bad.</p>
-14:39 < ant> <dm> not sure... Running XP here.</p>
-14:39 < cervantes> Ragnarook: only if you have the support cd files installed</p>
-14:40 < Ragnarok> ah</p>
-14:40  * duck refocuses</p>
-14:40 < cervantes> Ragnarok: otherwise download sysinternals pskill</p>
-14:40 < jrandom> ok, anything else for 4) addressbook.py, or shall we move on to 5) ???</p>
-14:41 < cervantes> Ragnarok: http://www.sysinternals.com/ntw2k/freeware/pstools.shtml</p>
-14:41 < jrandom> ok, 5) it is</p>
-14:41 < Ragnarok> neat, thanks :)</p>
-14:41 < jrandom> polecat: iirc you wanted to bring up bamboo-dht?</p>
-14:41 < MrEcho> ? meeting right now</p>
-14:41 <+polecat> :chants: DHT DHT USA USA~/o</p>
-14:42 <+polecat> Yes indeed.  I'm just looking something up...</p>
-14:42 < jrandom> yes MrEcho </p>
-14:43 <+Ch0Hag> 5?</p>
-14:43 < jrandom> 5) ???</p>
-14:43 < MrEcho> heh</p>
-14:43 <+Ch0Hag> ooh yes, I've found an irrelevant semantic bug</p>
-14:43 < jrandom> sup Ch0Hag?</p>
-14:43 <+polecat> There are 79 java files in bamboo source.  There are 253 files total.</p>
-14:44 <+polecat> The entire project takes 4.6 megabytes in source and support files, before building.</p>
-14:44 < jrandom> yikes</p>
-14:44 <+Ch0Hag> in /netdb.jsp, 'our' information is given port first, whereas other peers are given host first</p>
-14:44 <+Ch0Hag> On the Addresses line</p>
-14:44 < jrandom> have  you played around with it polecat?</p>
-14:44 < jrandom> Ch0Hag: the ordering is arbitrary</p>
-14:45 <+Ch0Hag> And 0.4.1.4 has been up for an hour with 128MB under Kaffe</p>
-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.</p>
-14:45 < ant> <dm> ah yes, ch0hag's insignificant bug report reminded me!</p>
-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"</p>
-14:45 <+Ch0Hag> It seems to be host/port on all of them</p>
-14:45 < MrEcho> Uptime: 54h Memory: 23,506KB</p>
-14:45 <+Ch0Hag> But hey</p>
-14:45 <+Ch0Hag> It's not like it really matters.</p>
-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</p>
-14:46 < cervantes> polecat: do you have a url?</p>
-14:46 < ant> <dm> Cheers!</p>
-14:47 < jrandom> hmm dm, it doesnt honor you setting it to empty?  </p>
-14:47 < jrandom> thats definitely a substantial bug</p>
-14:47 <+polecat> Yes, moment please.</p>
-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...</p>
-14:47 < jrandom> Ch0Hag: kaffe typically keeps a steady size</p>
-14:47 <+polecat> http://bamboo-dht.org/</p>
-14:48 < jrandom> Ragnarok: i'm considering removing that box altogether, leaving it for the hackers to add on /configadvanced.jsp</p>
-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 ;)</p>
-14:48 < cervantes> polecat: ta</p>
-14:48 <+Ch0Hag> dm: It's clearly an intelligence test.</p>
-14:48 <+Ch0Hag> If you can make it stay blank, you pass.</p>
-14:48 <+polecat> I also notice bamboo seems to compile with jikes and the kaffe jar in approximately 30 seconds.</p>
-14:48 <+polecat> Uses some weird variables though, JAVAC and JAVAHOME instead of JAVA_HOME</p>
-14:49 < Ragnarok> jr: I think that's a great idea.  At this point, it's a bit like a newbie trap.</p>
-14:50 < cervantes> dm: do you click the save button, or hit enter?</p>
-14:50 < ant> <dm> click save</p>
-14:50 < ant> <dm>     * Updated bandwidth limits</p>
-14:50 < ant> <dm>     * Configuration saved successfully</p>
-14:50 <@duck> polecat: do you plan to take a closer look at it?</p>
-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.</p>
-14:52 <+polecat> The important thing is whether it "works" or not of course.</p>
-14:52 < jrandom> bah, who needs functionality, its all about buzzword compatability!</p>
-14:53 < jrandom> please keep us updated on how it goes</p>
-14:53 < jrandom> (as i agree, the project does look promising)</p>
-14:53 <@duck> probably most important is what it offers for transport level modifications</p>
-14:54 < ant> <janonymous2> Whats the shtick on bamboo?</p>
-14:54 < jrandom> aye, whether it requires NIO channels or uses plain sockets</p>
-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""</p>
-14:54 < jrandom> (though we /could/ write NIO channels for i2psocket, it'd take some work)</p>
-14:54 <+polecat> jrandom: Go back to your cathedral, java gargoyle!  X3</p>
-14:54 <+polecat> Indeed.  If it requires TCP or UDP, or worse... DNS, then we might be hosed.</p>
-14:54 <+polecat> NIO/</p>
-14:54 <+polecat> NIO?</p>
-14:55 <+polecat> All I know is ni'o means change the subject in lojban.</p>
-14:55 < jrandom> NIO is a New I/O library in java, added in 1.4</p>
-14:55 <+polecat> I see.  Even plain sockets though, doesn't SAM have analog objects for sockets, and analog read() and write() functions?</p>
-14:55 < jrandom> yes</p>
-14:56 < jrandom> if they use plain sockets, its easy as shit</p>
-14:56 < jrandom> (...whatever that means)</p>
-14:56 < ant> <janonymous2> Whats bamboo?</p>
-14:56 < jrandom> bamboo-dht.org</p>
-14:57 < cervantes> what were the problems with pysam btw?</p>
-14:57  * polecat nods.</p>
-14:58 <@duck> cervantes: sending / receiving data</p>
-14:58 < cervantes> duck: oh is that all? :)</p>
-14:58 < ant> * janonymous2 /me coweres on his inadequate phone</p>
-14:58 <@duck> and making / detecting connections</p>
-14:58 <+Nightblade> it didn't send?</p>
-14:59 < Ragnarok> oy</p>
-14:59 <@duck> Nightblade: it probably did something</p>
-14:59 <+Nightblade> does it work at all?</p>
-15:00 < cervantes> duck: any thoughts on i2p-bt forum section naming?</p>
-15:00 < cervantes> d'you want you're own top level, with some subs?</p>
-15:01 < Ragnarok> hm, I've got to hit the road.  Have a good rest-of-meeting :)</p>
-15:01 < jrandom> Nightblade: aum was using it, so i'm sure it worked</p>
-15:01 < jrandom> l8r Ragnarok </p>
-15:01 < cervantes> you're = your</p>
-15:01 < cervantes> cya ragnarok</p>
-15:02 < ant> <janonymous2> Status on bt?</p>
-15:02 < jrandom> janonymous: see the meeting logs (once they come out)</p>
-15:03 < jrandom> speaking of which, is there anything else people would like to bring up in the meeting?</p>
-15:03 < ant> <janonymous2> Oh, my bad</p>
-15:04  * cervantes hands jr the egold plated baffer</p>
-15:04  * jrandom winds up</p>
-15:04 < jrandom> ...</p>
-15:04 < jrandom> ...</p>
-15:04  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/115.rst b/i2p2www/meetings/115.rst
new file mode 100644
index 00000000..385adb87
--- /dev/null
+++ b/i2p2www/meetings/115.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 9, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/116.log b/i2p2www/meetings/116.log
index 2a28fe98..b3056828 100644
--- a/i2p2www/meetings/116.log
+++ b/i2p2www/meetings/116.log
@@ -1,183 +1,177 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 116{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 16, 2004</h3>
-<div class="irclog">
-13:05 < jrandom> 0) hi</p>
-13:05 < jrandom> 1) Congestion</p>
-13:05 < jrandom> 2) Streaming</p>
-13:05 <+dinoman> pgforge's key has changed :/ sorry</p>
-13:05 < jrandom> 3) BT</p>
-13:05 < jrandom> 4) ???</p>
-13:05 < jrandom> ah cool, we can do some magic for that</p>
-13:05 < jrandom> 0) hi</p>
-13:05  * jrandom waves</p>
-13:05 < ant> <lucky> hi</p>
-13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000489.html</p>
-13:05 < wiht> Hello.</p>
-13:06 < jrandom> (and we got the notes posted *before* the meeting.  w00t)</p>
-13:06 < jrandom> might as well jump on in to 1) Congestion</p>
-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</p>
-13:07 < jrandom> that said, does anyone have any questions / comments / concerns that they'd like to raise/discuss?</p>
-13:09 < wiht> What do you mean by "wild peer selection"?</p>
-13:10 < jrandom> the way our current tunnel building works unfortunately lets things stabalize around the fast peers</p>
-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</p>
-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</p>
-13:11 <+DrWoo> jrandom: what is in the pipeline to use the capacity better?</p>
-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)</p>
-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)</p>
-13:14 < ant> <Connelly> bleh</p>
-13:14 < ant> <Connelly> no meeting yet?</p>
-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)</p>
-13:15 < jrandom> Connelly: started 10m ago, status notes posted on the list ;)</p>
-13:15 <+DrWoo> jrandom: what impact will that have on performance?</p>
-13:15 <+DrWoo> local pc performance</p>
-13:15  * wiht wonders how many different protocols are being used on the I2P network besides HTTP, IRC, and BT.</p>
-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)</p>
-13:16 < jrandom> neither of those are particularly latency based though</p>
-13:17 < jrandom> wiht: those three are the main ones used to my knowledge, though some ugly stuff is done over HTTP</p>
-13:17 < jrandom> thats actually an interesting issue, wrt irc and congestion</p>
-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</p>
-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 ;)</p>
-13:19 < jrandom> basically what i'm saying is, a decentralized chat protocol would be Good ;)</p>
-13:19 <+DrWoo> is there such a beast?</p>
-13:20 < jrandom> (though the new streaming lib will get rid of that 6x overhead)</p>
-13:20 <+dinoman> is there a good one</p>
-13:20 < jrandom> i dont know if anyone has evaluated something ala SILC for i2p within the last year</p>
-13:20 < susi23> pop3 and smtp are _awfully_ slow on i2p</p>
-13:21 < ant> <duck> silc == irc+somecrypto</p>
-13:21 < susi23> (as answer on the question, which protocols are used too)</p>
-13:21 < jrandom> ah, i thought silc got away from the ircd concept</p>
-13:21 < jrandom> oh, shit, right, i forgot about those two :)</p>
-13:21 < wiht> susi23: Yes, I forgot that we have mail on I2P now.</p>
-13:21 < ant> <duck> not far atleast</p>
-13:21 < jrandom> 'k</p>
-13:21 < ant> <protok0l> meeting?</p>
-13:22 < ant> <lucky> rite now protok0l </p>
-13:22 < ant> <protok0l> k</p>
-13:22 < jrandom> ok, do we have anything else for 1) congestion?</p>
-13:23 < jrandom> if not, moving on to 2) streaming</p>
-13:23 < jrandom> [see the email]</p>
-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</p>
-13:24 < jrandom> (if you're crazy)</p>
-13:24 < jrandom> i dont really have anythign else to add though.  so, any questions/comments/concerns?  </p>
-13:25 <+postman> just one</p>
-13:25 <+postman> thanks :)</p>
-13:25 < ant> <protok0l> what speed increase will there be</p>
-13:25 < jrandom> hehe you're supposed to wait until you *get* the software postman ;)</p>
-13:25 < jrandom> protokol: some.  varies.  </p>
-13:25 <+postman> jrandom: i would bet on you blindfold</p>
-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?</p>
-13:27 < jrandom> if tests this week go well, we can pencil in next week</p>
-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</p>
-13:28 < wiht> As I recall, you are using a simulated network for the tests. Is that still true?</p>
-13:29 < jrandom> for some of them, yeah</p>
-13:29 < jrandom> when i dont use the sim, i just run it on the live net</p>
-13:30 < jrandom> (because i like to abuse your bandwdith ;)</p>
-13:30 < susi23> you're welcome ;)</p>
-13:30 <+dinoman> hehe turn it on a see if it blows up?</p>
-13:31 -!- x is now known as fidd</p>
-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</p>
-13:32 < jrandom> the sim'ed tests are more involved though, with perhaps a half dozen unit tests w/ various runtime params</p>
-13:33 < wiht> How well do the simulation tests reflect observed network usage?</p>
-13:33 < jrandom> pretty well, as the simulation code is the same as the live network code</p>
-13:34 < jrandom> i dont have the lag and drop injection perfect in the sim though, but its in the ballpark</p>
-13:35 < ant> <cat-a-puss> will the new streaming lib use the same interface? Or will Java apps have to do something new?</p>
-13:35 < wiht> Thanks for clarifying that.</p>
-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</p>
-13:36 < ant> <cat-a-puss> k</p>
-13:37 < jrandom> k, anything else, or shall we jump to 3) BT?</p>
-13:38 < jrandom> duck: ping</p>
-13:38 <@duck> *quack</p>
-13:38 <@duck> Last week I reported that we had BitTorrent on I2P working. There has been some </p>
-13:38 <@duck> confusion but it is anonymous both for trackers and for clients (seeders and leechers).</p>
-13:38 <@duck> Updates since last week:</p>
-13:38 <@duck> GUI work (wxPython), included tracker, bugfixes.</p>
-13:39 <@duck> full list at http://dev.i2p/cgi-bin/cvsweb.cgi/~checkout~/i2p-bt/CHANGES.txt?rev=HEAD</p>
-13:39 <@duck> also the code is at the CVS on cvs.i2p</p>
-13:39 <@duck> and got a dedicated eepsite: http://duck.i2p/i2p-bt/</p>
-13:39 <@duck> The included tracker is very spartanic and you still have to provide the</p>
-13:39 <@duck> torrents themself somewhere; so DrWoo, thetower and me have been looking at </p>
-13:39 <@duck> several alternatives which offer features like suprnova, until I got nuts.</p>
-13:39 <@duck> *flierp*</p>
-13:40 < jrandom> w00t</p>
-13:40 <@duck> Finally bytemonsoon is selected, the original is ugly, but DrWoo has been fixing that,</p>
-13:40 <@duck> The idea is to improve it some more and release it as an I2P ready tracker solution,</p>
-13:40 <@duck> see: http://brittanyworld.i2p/bittorrent/</p>
-13:40 <@duck> meeting the requirements at: http://duck.i2p/i2p-bt/txt/bytemonsoon.txt</p>
-13:40 <@duck> .</p>
-13:40 < jrandom> kickass</p>
-13:40 <+DrWoo> you can check out a couple of small test files on a the nice tracker duck fixed up</p>
-13:41 <+DrWoo> there's nothing big to gum up the net heh</p>
-13:41 < jrandom> what, you dont want us to download more episodes of Lost?  :)</p>
-13:41 <@duck> if thetower's is up..</p>
-13:42 < jrandom> the bytemonsoon port is looking really nice.</p>
-13:42 <+DrWoo> I can't get thetower right now here</p>
-13:42 <+DrWoo> jrandom: it really seems to provide most anything you'd need</p>
-13:42 <+dinoman> what kind of speed r ppl seeing?</p>
-13:43 <@duck> ~5kb/s per peer</p>
-13:43 <+DrWoo> dino: from this side it looks like 4-10K per peer</p>
-13:43 <@duck> (optimistically, ofcourse there are those shitty adsl folks)</p>
-13:44 <+dinoman> wow better then i thought</p>
-13:44 <@duck> til i2p crashes; see 1)</p>
-13:44 < jrandom> heh</p>
-13:44 <+DrWoo> dinoman: in other works, it should look pretty impressive with a swarm</p>
-13:44 <@duck> there have been various calls for improving the GUI</p>
-13:45 <+DrWoo> dinoman: and some 0 hop peers ;)</p>
-13:45 <@duck> not many takers on it though</p>
-13:45 < jrandom> duck (& gang): what can we do to help?</p>
-13:45 <@duck> you: get the new streaming lib ready</p>
-13:46 <@duck> gang: look at the todo: http://duck.i2p/i2p-bt/txt/todo.txt</p>
-13:46 <@duck> lucky is working on a howto</p>
-13:47 <@duck> DrWoo: anything else?</p>
-13:47 < jrandom> nice</p>
-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.</p>
-13:47 < ant> <lucky> i am?</p>
-13:48 < ant> <lucky> oh</p>
-13:48 < ant> <lucky> i am</p>
-13:48 < ant> <lucky> :)</p>
-13:48 <+DrWoo> duck: there's always something else heh</p>
-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</p>
-13:49 < ant> <lucky> uh oh.</p>
-13:49 < ant> <lucky> So that means i should really, really, work on that howto then.</p>
-13:49 < jrandom> without a viable large-file-transfer system, we've got to do some wonders for engaging user apps</p>
-13:50 < jrandom> which we are doing - susi's and postman's work is quite promising</p>
-13:50 < jrandom> but the market for anonymous email is much less than the market for safe file transfer</p>
-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 </p>
-13:51 < jrandom> </my $0.02></p>
-13:52 <@duck> what do you think about default settings for those filesharing apps?</p>
-13:52 < jrandom> that i dont know</p>
-13:53 <@duck> or isn't that really relevant yet giving todays possibilities</p>
-13:54 <+DrWoo> duck: there may be some 'thinking outside the box' needed to get over some bumps along the way?</p>
-13:54 < jrandom> 1 hop tunnels may be relevent for the BT-ers, prior to 0.4.3</p>
-13:57 < jrandom> ok, do we have anything else for 3) BT?</p>
-13:57 <@duck> notme</p>
-13:57 <+DrWoo> thanks to duck and the dudes</p>
-13:58 <+DrWoo> that was pretty awesome work</p>
-13:58 < jrandom> aye, y'all are doing a kickass job</p>
-13:58 <+dinoman> i did not do it</p>
-13:58 < jrandom> (i love watching the --spew 1 on the btdownloadheadless :)</p>
-13:58 <@duck> dinoman: you started it</p>
-13:58 <+Ragnarok> headless spew... sounds dirty</p>
-13:59 <+DrWoo> dino: pushing the effort along is a real contribution</p>
-13:59  * Ragnarok will put together a patch for the command line option stuff on the todo list</p>
-13:59 < jrandom> w00t</p>
-14:00 < ant> <dm> Don't forget anonymous WWW, that's a big one as well.</p>
-14:00 < jrandom> dm: yeah, perhaps thousands or tens of thousands, but not the draw of millions</p>
-14:01 < jrandom> (for outproxy stuff, imho)</p>
-14:01 < jrandom> ok, if there's nothing else, moving on to good ol' fashioned 4) ???</p>
-14:01 < jrandom> anything not yet raised that should be?</p>
-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?</p>
-14:02 <+DrWoo> dm: it's all part of life's rich pageant :)</p>
-14:03 < ant> <dm> a lotta people use da web</p>
-14:03 < ant> <dm> (they just installed surfcontrol at my workplace) ;)</p>
-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 </p>
-14:03 < jrandom> ah, lame</p>
-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</p>
-14:04 < jrandom> (and checking my mail takes a few seconds, but biff tells me when i need to anyway)</p>
-14:05 < jrandom> ok, is there anything else?</p>
-14:06 < ant> <dm> are you baffing the meeting?</p>
-14:07 < jrandom> seems like it</p>
-14:07  * jrandom winds up</p>
-14:07  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/116.rst b/i2p2www/meetings/116.rst
new file mode 100644
index 00000000..54ad051c
--- /dev/null
+++ b/i2p2www/meetings/116.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 16, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/117.log b/i2p2www/meetings/117.log
index 1772cdb4..eae2dd49 100644
--- a/i2p2www/meetings/117.log
+++ b/i2p2www/meetings/117.log
@@ -1,70 +1,64 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 117{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 23, 2004</h3>
-<div class="irclog">
-13:03 < jrandom> 0) hi</p>
-13:03 < jrandom> 1) Net status</p>
-13:03 < jrandom> 2) Streaming lib</p>
-13:04 < jrandom> 3) 0.4.2</p>
-13:04 < jrandom> 4) Addressbook.py 0.3.1</p>
-13:04 < jrandom> 5) ??? </p>
-13:04 < jrandom> 0) hi</p>
-13:04  * jrandom waves</p>
-13:04 <+postman> hi :)</p>
-13:04 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-November/000490.html</p>
-13:05 < jrandom> well, might as well jump on in to 1) net status</p>
-13:05 < jrandom> i dont have much to add to this that wasn't in the email</p>
-13:05 < jrandom> anyone have anything they want to bring up wrt the network status over the last week?</p>
-13:06 < jrandom> if not, we can jump on down to 2) streaming lib</p>
-13:06 < jrandom> there's lots of info in the mail about this, so i'll let y'all digest a bit</p>
-13:07 < jrandom> while the new lib will improve lots of things, the most important (imho) is its resiliance and handling of congestion</p>
-13:08 < jrandom> especially the latter, as we've seen how things get funky with the old lib under heavy congestion</p>
-13:08 < jrandom> there's also a lot of things left out of the lib though, places for people to experiment and optimize further</p>
-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?  ;)</p>
-13:10 <+Ragnarok> we'll call that a yes</p>
-13:10 < jrandom> heh</p>
-13:10 < jrandom> ok, moving on to 3) 0.4.2</p>
-13:10 < jrandom> out real soon, just doing some minor updates to the install process at the moment</p>
-13:11 <+postman> yesss</p>
-13:11 <+postman> :)</p>
-13:11 < jrandom> the updated install proc will be a bit nicer for people, addressing the most common user errors</p>
-13:12 < jrandom> (since no one ever reads the text on the router console ;)</p>
-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</p>
-13:12 < jrandom> (if not sooner)</p>
-13:13 < jrandom> as i mentioned in the mail though, its both backwards compatbile and /not/ backwards compatible</p>
-13:13 <+Ragnarok> awesome</p>
-13:13 < jrandom> does anyone have any strong preferences as to how we should do that tap dance?</p>
-13:13 < jrandom> should we just push out 0.4.2 and let people upgrade when they notice they cant reach any eepsites?</p>
-13:14 < jrandom> (or will they uninstall it and say "dood i2p sux0rz")</p>
-13:14  * jrandom neither</p>
-13:15 <+Ragnarok> I'd say mark it as not compatible.  It's always better to be explicit.</p>
-13:15 < jrandom> well, the docs and announcement will say not compatible, mandatory upgrade in big bold letters</p>
-13:16 <+Ragnarok> no reason to send mixed messages, then</p>
-13:16 < jrandom> aye</p>
-13:16 < jrandom> though we would be able to tunnel route through those old peers</p>
-13:16 < jrandom> i dunno, we've got a few days to finalize the decision anyway</p>
-13:17 < jrandom> just something to think about, and a WARNING to people that they'll NEED TO UPGRADE TO 0.4.2 </p>
-13:17 < jrandom> :)</p>
-13:18 < jrandom> ok, anyone have any questions/comments/concerns wrt 0.4.2, or shall we move on to 4) addressbook.py?</p>
-13:18 < jrandom> consider us moved</p>
-13:18 < jrandom> Ragnarok: wanna give us an update?</p>
-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.</p>
-13:20 < jrandom> ok cool</p>
-13:21 < jrandom> avoiding violent death is always a nice feature to have</p>
-13:21 < lba> hi folks</p>
-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.</p>
-13:21 < jrandom> wikked :)</p>
-13:21 < jrandom> 'lo lba</p>
-13:22 <+Ragnarok> well, that's all.  Carry on.</p>
-13:22 < jrandom> cool, thanks for the update</p>
-13:22 < jrandom> ok if there's nothing else on that, we can move on at a blazing pace to 5) ???</p>
-13:22 < jrandom> anyone else have something they want to bring up?</p>
-13:23 <+Ragnarok> anyone else here?</p>
-13:23 < jrandom> heh, yeah, we dont have our usual malcontents ;)</p>
-13:24 < jrandom> then again, they'll show up to read the logs on the site later [yeah, i mean *YOU*]</p>
-13:24 < jrandom> ok, i think thats probably the shortest meeting we've had in over a year</p>
-13:25 < jrandom> might as well wraper 'er up</p>
-13:25  * jrandom winds up</p>
-13:25  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/117.rst b/i2p2www/meetings/117.rst
new file mode 100644
index 00000000..2e6ea4d8
--- /dev/null
+++ b/i2p2www/meetings/117.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 23, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/118.log b/i2p2www/meetings/118.log
index fb4644b2..ec12d381 100644
--- a/i2p2www/meetings/118.log
+++ b/i2p2www/meetings/118.log
@@ -1,324 +1,318 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 118{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 30, 2004</h3>
-<div class="irclog">
-13:08 < jrandom> 0) hi</p>
-13:08 < jrandom> 1) 0.4.2 and 0.4.2.1</p>
-13:08 < jrandom> 2) mail.i2p</p>
-13:08 < jrandom> 3) i2p-bt</p>
-13:08 < jrandom> 4) eepsites</p>
-13:08 < jrandom> 5) ???</p>
-13:09 < jrandom> 0) hi</p>
-13:09 < jrandom> sorry to interrupt dm's agenda</p>
-13:09 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2004-November/000492.html</p>
-13:09 < jrandom> [hi]</p>
-13:10 <+postman> ((hi))</p>
-13:10 <+postman> :)</p>
-13:10 < jrandom> so, as y'all read through that overwhelmingly interesting email, we might as well get the meeting underway</p>
-13:10 < jrandom> 1) 0.4.2 and 0.4.2.1</p>
-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 ;)</p>
-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</p>
-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</p>
-13:12 <+postman> jrandom: what do the bugfixes address - all errors in the new streaminglib or other stuff as well?</p>
-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</p>
-13:14 < jrandom> dev.i2p.net/cgi-bin/cvsweb.cgi/~checkout~/i2p/history.txt?rev=HEAD has the full list</p>
-13:14 <+postman> k</p>
-13:14 <+postman> thx</p>
-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 :)</p>
-13:15 < jrandom> does anyone have any questions/comments/concerns about 0.4.2?</p>
-13:15 < jrandom> (/0.4.2.1)</p>
-13:16 < clayboy> been working great here, have been tracking cvs too, always smooth</p>
-13:16 < jrandom> wikked</p>
-13:17 < bla> It's table (0.4.2): up for days already</p>
-13:17 < bla> s/table/stable/</p>
-13:17 < jrandom> ah nice, yeah, the bugs havent been hitting everyone</p>
-13:17 < jrandom> ok, if there's nothing else on that, lets jump on to 2) mail.i2p</p>
-13:18 < jrandom> i hear postman has some things to discuss</p>
-13:18 <+postman> hello</p>
-13:18 < jrandom> hi postman, you're up :)</p>
-13:18 <+postman> weeks ago i conducted a poll regarding IMAP</p>
-13:19 <+postman> since a few weeks passed now i decided to close the polls and to count the vote</p>
-13:19 <+postman> result is: not needed - won't be done. period</p>
-13:19 <+postman> after talking to susi - she was quite fine wioth pop3 on her webmail interface</p>
-13:19 < clayboy> reason wins! :)</p>
-13:19 < jrandom> w3wt</p>
-13:20 <+postman> so let's just stick to the pop3 end bury any silly imap ideas</p>
-13:20 <+postman> :)</p>
-13:20  * jrandom gets the shovel</p>
-13:20 <+postman> 2.) we're close to 100 registered users</p>
-13:21 < clayboy> wow</p>
-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 </p>
-13:21 <+Ragnarok> so... how about that LDAP address book? :)</p>
-13:21 < jrandom> nice</p>
-13:21 <+postman> 3. a feature to upload/share you public pgp key is active since weekend</p>
-13:21 <+postman> please use it </p>
-13:21 <+postman> www.postman.i2p/user/acc.html</p>
-13:22 < clayboy> i'm not taking any credit for that idea :></p>
-13:22 <+postman> the public keys can easily be downloaded with the help of the addressbook</p>
-13:22 <+postman> or direct as www.postman.i2p/public/accountname.pub</p>
-13:22 < jrandom> ooh cool</p>
-13:22 <+postman> the system works quite fine</p>
-13:22 <+postman> thanks to duck for pointing at a few bugs</p>
-13:23 <+postman> 4.) i think about offering accountbased routing</p>
-13:23 <+postman> like ppl say</p>
-13:23 < jrandom> account based routing?</p>
-13:23 <+postman> all mail for foo@mail.i2p gets transported to the following destination </p>
-13:23 <+postman> and user presents a valid destination key for it</p>
-13:24 <+postman> postman.i2p will then manually route mail to those accounts to mailsystems</p>
-13:24 <+postman> just an idea(tm)</p>
-13:24 < jrandom> ah nice</p>
-13:24 <+postman> i am looking forward to develop and discuss the whole matter</p>
-13:25 <+postman> that's it for now</p>
-13:25 <+postman> more follows next week</p>
-13:25 <+postman> thanks</p>
-13:25 < nmi> postman: sorry, transported to a particular i2p destination you mean?</p>
-13:25  * postman hands the mike back to jrandom </p>
-13:25 <+postman> nmi: yes</p>
-13:25 < ant> <Nightblade> am SMTP i2p destination?</p>
-13:25 < ant> <Nightblade> an</p>
-13:25 <+postman> nmi: provided the destination accepts smtp and mail for that account</p>
-13:25 < jrandom> that sounds very cool, gets rid of the trust aspect of the mail fiiltering</p>
-13:26 < nmi> ah, ok. clever. i had thought of doing something similar using mixminion single-use-reply-blocks but your idea is better...</p>
-13:26 < jrandom> its probably a lot of work to set up on the client side, but perhaps someone could do some hacking</p>
-13:26 <+postman> jrandom: i am working on it</p>
-13:26 < jrandom> w00t</p>
-13:26 <+postman> jrandom: the user will have the usual webinterface ( acc.html...)</p>
-13:27 <+postman> jrandom: and inserts the destinationkey</p>
-13:27 < jrandom> well, right, but then there's the MTA configuration</p>
-13:27 <+postman> the rest will be done automatigally</p>
-13:27 <+postman> yes, on the postman.i2p AND the receiving sinde</p>
-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</p>
-13:28 < jrandom> right right</p>
-13:28 <+postman> jrandom: i will provide a simple setup config for ppl interested</p>
-13:28 <+postman> jrandom: for postfix, exim and sendmail</p>
-13:28 <+postman> jrandom: those can be stripped down to BARE necessities</p>
-13:28 <@duck> seriously, do you think that there are many users for that?</p>
-13:28 < jrandom> postman: this all sounds pretty kickass.  i look forward to hearing more when you're ready</p>
-13:29 <+postman> jrandom: no idea about windows smtp servers tho</p>
-13:29 <+postman> duck: well</p>
-13:29 <+postman> duck: 8 weeks ago there was no need for a mailsystem and no users either</p>
-13:29 <+postman> duck: it's investment</p>
-13:29 <@duck> true</p>
-13:29 <+postman> duck: in 6 months we'll be happy to have it</p>
-13:29 < jrandom> duck: the potential comes with moving away from a trusted SMTP filter</p>
-13:29 <+postman> :)</p>
-13:30 < jrandom> er, perhaps i should say, moving /to/ a trusted smtp filter (no offense postman ;)</p>
-13:30 <+postman> and there will be a few ones</p>
-13:30 <+postman> AND</p>
-13:30 <+postman> (now the punchline)</p>
-13:30 <+postman> we could easily create maildomains :)</p>
-13:30 <+postman> like duck@duck.i2p and other stuff</p>
-13:30 <+postman> :)</p>
-13:30 <@duck> ah</p>
-13:31 <+postman> the only problem would be the official/private mapping</p>
-13:31 < jrandom> hosts.txt!</p>
-13:31  * jrandom ducks</p>
-13:31 <+postman> but this is another thing for the webmanagement console :)</p>
-13:31 <+postman> LOL</p>
-13:31 <+postman> jrandom: i rely on shaky sql databases :)</p>
-13:31 <@duck> ok; I see it fitting in</p>
-13:32 <+postman> ok</p>
-13:32 <+postman> then i will work it out and present an concept soon</p>
-13:32 <+postman> yess, yet more work</p>
-13:32  * postman leans back relaxed</p>
-13:32 <+postman> :)</p>
-13:32 < jrandom> kickass, thanks postman </p>
-13:33 < jrandom> ok, unless other people have further mail.i2p related questions, shall we move on to 3) i2p-bt?</p>
-13:33 < jrandom> consider us moved</p>
-13:34 < jrandom> ok, as the email mentioned, i broke the i2p-bt port</p>
-13:34  * jrandom hangs head in shame</p>
-13:34 < jrandom> in other news, duck, do you have anything wrt i2p-bt you want to discuss?</p>
-13:34 <@duck> as a result of jrandom's work not much has been done :)</p>
-13:35 <+Ragnarok> booo, hissss</p>
-13:35 <@duck> oh Ragnarok had some patches</p>
-13:35  * jrandom2p pelts jrandom with tomatoes</p>
-13:35 <@duck> I think, see the history file :)</p>
-13:35 < jrandom> oh cool</p>
-13:35 <@duck> we got some things in the queue too</p>
-13:35 <+Ragnarok> well, I was hissing at jr, but ok :)</p>
-13:36 <@duck> but I dont want to change (too) much on the unstable ground</p>
-13:36 <@duck> (like breaking bt while i2p is getting fixed)</p>
-13:36 < jrandom> aye, good plan</p>
-13:36 <@duck> .</p>
-13:37 < jrandom> ok cool, anyone else have anything on i2p-bt?</p>
-13:37 < jrandom> if not, moving us along to 4) eepsites</p>
-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</p>
-13:39 < bla> yes...</p>
-13:39 < jrandom> what we have now for browsing eepsites and normal websites anonymously just plain isn't safe</p>
-13:39 < clayboy> disabling java, javascript, cookies and flash helps, though</p>
-13:39 < jrandom> DrWoo has done a great job with his page describing the dangers and how you can protect yourself</p>
-13:40 < jrandom> right clayboy, definitely</p>
-13:40 < clayboy> url?</p>
-13:40 < bla> clayboy: Yes, on the HTML side, but not on the HTTP side</p>
-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 ;)</p>
-13:40 < clayboy> bla: good point</p>
-13:40 < jrandom> clayboy: http://brittanyworld.i2p/browsing/</p>
-13:41 < bla> I've done some experiments here: http://forum.i2p/viewtopic.php?t=182</p>
-13:41 < bla> Doesn't look good as it is</p>
-13:42 <@duck> who has the evil applets?</p>
-13:42 < ant> <Nightblade> there was a security exploit found in java</p>
-13:43 < ant> <Nightblade> for some older 1.4.x vers</p>
-13:43 < ant> <Nightblade> not 1.5</p>
-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</p>
-13:44 < ant> <Nightblade> hmm</p>
-13:44 < jrandom> (download a .exe, run the .exe)</p>
-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)</p>
-13:45  * jrandom stops handing out hand grenades</p>
-13:46 < jrandom> (i havent verified their code, but did see much of it)</p>
-13:46 < jrandom> but anyway, eepsites</p>
-13:47 < jrandom> well, i dont think it would be prudent to remove the eepproxy altogether</p>
-13:47 < jrandom> but i dont really have time right now to implement any of the solutions listed</p>
-13:48 < bla> jrandom: Stripping out all Accept* headers would be a good thing, for now</p>
-13:48 < jrandom> what do y'all think?  any volunteers?  shall we wing it until we do get time?</p>
-13:48 < ant> <Nightblade> bla: I don't think it is a big deal that people can see some browser headers</p>
-13:49 < ant> <Nightblade> millions of people use those browsers</p>
-13:49 < bla> And always adding a User-Agent: header, even if the client didn't send one. I makes requests homogeneous</p>
-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</p>
-13:50 < bla> The Accept-Language: header is there though, in some browsers. And we can't rely on it always being "en"</p>
-13:50 < ant> <Nightblade> ok but what if removing some of those headers violates the HTTP spec?</p>
-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</p>
-13:50 < jrandom> nightblade: we break so many aspects of the HTTP spec it hurts</p>
-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</p>
-13:51 < ant> <Connelly> HTTP was not designed for anonymity</p>
-13:51 < jrandom> the eepproxy is duct tape and shoe polish</p>
-13:51 < bla> jrandom: Why isn't that filttering safe?</p>
-13:52 < bla> jrandom: We could even consider stripping _all_ headeers, except for the Host: header and the GET header</p>
-13:52 < jrandom> bla: stripping all headers except the host would be safer, yes</p>
-13:52 < bla> jrandom: After all, what do we need more for an anonymous HTTP?</p>
-13:52 < jrandom> but thats beyond the amount of time i can put into it</p>
-13:52 < jrandom> i can add the Accept and user-agent filters in ~ 30s</p>
-13:53 < jrandom> much beyond that and i throw my hands in the air and rewrite the http proxy ;)</p>
-13:53 < bla> jrandom: How come stripping all of them is more difficult?</p>
-13:53 < jrandom> read the code.  </p>
-13:54 < jrandom> (patches welcome)</p>
-13:54 < jrandom> but what we're looking at here is still just a short term solution</p>
-13:54 < bla> jrandom: Point well taken ;)  But seriously: I think the Accept* and User-Agent fixes would do really fine for now</p>
-13:54 < jrandom> we need someone to work on something that will last us long term</p>
-13:55 < ant> * dm just ate 20 slices of cheese... drool.</p>
-13:55 < jrandom> bla: i heard that last time someone asked us to filter the User-agent and referrer headers ;)</p>
-13:55 < jrandom> (but yeah, i'll get those two into the next rev)</p>
-13:56 < ant> <dm> those headers are usefl</p>
-13:56 < ant> <dm> useful</p>
-13:56 < ant> <dm> For service providers.</p>
-13:56 < jrandom> yes, they are</p>
-13:57 < jrandom> we've already had some apps break because we filter referrer too</p>
-13:57 < bla> dmm: Yes, indeed. However, they also provide a browser or OS fingerprint</p>
-13:57 < ant> <dm> I have an idea!</p>
-13:57  * jrandom takes cover</p>
-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 </p>
-13:58 < ant> <dm> eh? eh?</p>
-13:58 < jrandom> we already hard code the user agent header</p>
-13:59 < ant> <Nightblade> I2P-enabled cell phones</p>
-13:59  * jrandom mounts a DoS on that phone</p>
-13:59 < ant> <dm> To what?</p>
-13:59 < ant> <dm> My poor phone!!!</p>
-13:59 < jrandom> ok, anyone else have any thoughts on the eepproxy/eepsite stuff?</p>
-14:00 < bla> MYOB/6.ss (AN/ON)</p>
-14:00 < bla> no\</p>
-14:00 <+Ragnarok> we should reinvent html using s-expressions!</p>
-14:01 < jrandom> (i really do think using a bbcode style macro language is the way to go, at least for some things ;)</p>
-14:01 < jrandom> ((or xml for you geeks))</p>
-14:02 < ant> <dm> Microsoft endorses use of XML</p>
-14:02 < ant> <dm> So I'm all for it.</p>
-14:02 <+Ragnarok> xml is just excessively wordy s-expressions :)</p>
-14:03 < ant> <dm> Is this a good time for me to aplaud jrandom for his work on this project?</p>
-14:03  * jrandom volunteers Ragnarok to work on it, after getting the next gen address book ;)</p>
-14:03 <@duck> I dont think that 'invent your own markup language' will work for general browsers</p>
-14:04 <@duck> maybe for the blog thing inside myi2p</p>
-14:04 <+Ragnarok> it's always a good time :)</p>
-14:04 < ant> <dm> applaud even</p>
-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</p>
-14:05 < ant> * dm tips his hat to jr.</p>
-14:05 < jrandom> gracias dm et al</p>
-14:05 < ant> <Nightblade> something like PDF would be safer than HTML</p>
-14:05 < jrandom> lol</p>
-14:05 <@duck> .txt files!</p>
-14:06 < ant> <Nightblade> i've seem PDF files with clickable links, but the files themselves are huge</p>
-14:06 < ant> <Nightblade> seen</p>
-14:06 < ant> <dm> Uncompressed Bitmaps?</p>
-14:06 < jrandom> yes, lets all write in pdf</p>
-14:07 <+Ragnarok> erg, postscript is fugly</p>
-14:07 < ant> <cat-a-puss> how is html insecure?</p>
-14:07 <@duck> anyway</p>
-14:07 < ant> <Nightblade> cat: with javascript, activex, applets,...</p>
-14:07 < jrandom> cat-a-puss: all the different ways to encode dangerous data</p>
-14:08 < ant> <dm> languages aren't secure or insecure, clients are.</p>
-14:08 <+Ragnarok> the realy problem is how to do anon dhtml...</p>
-14:08 < jrandom> (and we'll never, /never/ be ahead of the game as long as we explicitly filter)</p>
-14:08 < ant> <cat-a-puss> Java/javascript are enclosed in tags. So strip those out, plain html is not harmful right?</p>
-14:08 < ant> <dm> We need to use a data format that is parsed by a client made by a company that we trust.</p>
-14:08 < jrandom> Ragnarok: macros, and/or reference known safe and locally installed javascript</p>
-14:08 < ant> <dm> I trust Microsoft, therefore I suggest Internet Explorer, Microsoft Word, or Notepad</p>
-14:09 < ant> <dm> Flight Simulator 2002 is acceptable as well.</p>
-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.</p>
-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</p>
-14:10 < ant> <Nightblade> the eepproxy would have to run as a separate process, because of licensing</p>
-14:11 < jrandom> that still leaves us a heavily crippled html</p>
-14:11 < jrandom> (with no css)</p>
-14:11 < ant> <dm> Okay, how about Flash?</p>
-14:11 < jrandom> nightblade: we can work around that (same way we work around i2ptunnel being GPL)</p>
-14:11 < ant> <dm> Imagine a world wide web with only flash.</p>
-14:11 < ant> <dm> What a rich and wonderful world that would be.</p>
-14:12 < ant> <Nightblade> well Just create a warning: "Eepsite browsing is hazardous to your anonymity.  Please use Gopher."</p>
-14:12 < ant> <Nightblade> actually gopher is not a bad idea</p>
-14:12  * jrandom ports archie</p>
-14:12 <+Ragnarok> gopher!</p>
-14:12 < ant> <dm> There was Betty as well, wasn't there...</p>
-14:12 <+Ragnarok> I remember gopher :)</p>
-14:13 <+Ragnarok> man, those were the good old days.  I think I had a screaming 14.4 baud at the time... <sigh></p>
-14:13 < ant> <Nightblade> I only browsed gopher in text mode, and I don't know if it supported graphics</p>
-14:13 < jrandom> they didnt have gui browsers last time i used gopher ;)</p>
-14:14 < jrandom> anyway, there are lots of options</p>
-14:14 < ant> <Nightblade> what was that browser called back then?  the one before Netscape...</p>
-14:14 < ant> <Nightblade> i forget</p>
-14:14 < jrandom> mosaic</p>
-14:15 < ant> <Nightblade> yeah</p>
-14:15 < ant> <dm> Mosaic 2.0</p>
-14:15 < ant> <Nightblade> "Welcome to I2P, please wait while we install Gopher and Mosaic."</p>
-14:15 < jrandom> heh</p>
-14:15 < jrandom> yeah, probably no javascript exploits in those</p>
-14:16 < jrandom> ok, anyway, thats that, i suppose</p>
-14:16 < jrandom> moving on to 5) ???</p>
-14:16 <+Ragnarok> there's still a gopher package in debian</p>
-14:16 < jrandom> anyone have anything else (not gopher related)?</p>
-14:17 < ant> <dm> What will happen to I2P when you need to start working again?</p>
-14:18 < jrandom> i'll be on i2p fulltime through the spring, at least.  we can discuss things beyond then as that time approaches</p>
-14:19 < ant> <dm> o k</p>
-14:19 < jrandom> in any case, if i got hit by a bus tomorrow, everything is in cvs and all code is free</p>
-14:19 <+Ragnarok> I assume you're planning to have a 1.0 before then.  What do you think the odds are?</p>
-14:19 <+Ragnarok> before spring, not your untimely demise...</p>
-14:20 < jrandom> certainty.</p>
-14:20 < ant> <dm> ahaha.. yes, what are the odds of 1.0 before tomorrow when you get hit by that bus?</p>
-14:20 < jrandom> (assuming no buses ;)</p>
-14:20 < ant> <dm> I just had a very sad thought.</p>
-14:20 < ant> <dm> Depressing really, but... If you were to get hit by a bus, no one here would know of it.</p>
-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.</p>
-14:21 < ant> <dm> You would just die, and we wouldn't know what happened :(</p>
-14:21 < ant> <dm> God why did he have to die?!?!? why?!?!</p>
-14:22 < ant> <dm> Can you put a clause in your will to email the mailing list if you die?</p>
-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</p>
-14:22 < jrandom> dm: people who know me irl know i'm involved in i2p.  enough of this morbid shit</p>
-14:23 < ant> <dm> ah cool.</p>
-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.</p>
-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?</p>
-14:26 < ant> <cat-a-puss> jrandom: yeah, as long as there is no buffer overflows etc.</p>
-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.  </p>
-14:27 < jrandom> the data available to javascript includes your IP address, as well as your bookmarks and all sorts of other things</p>
-14:27 < jrandom> so even though the connection to cia.i2p was anonymous, the content exposes you</p>
-14:31 < jrandom> ok, anyone else have something to bring up for the meeting?</p>
-14:31 <@duck> yes:</p>
-14:31 <@duck> what does the new 'active peers' counter mean</p>
-14:31 < jrandom> ah</p>
-14:31 < jrandom> yeah, that changed</p>
-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</p>
-14:32 < jrandom> this is part of the code to deal with some peers giving out bad info in the IP autodetection phase</p>
-14:33  * duck will try to remember it</p>
-14:33 < jrandom> so it'll vary much more than before</p>
-14:33 < jrandom> heh so dont worry when the value is lower than you're used to ;)</p>
-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</p>
-14:34 < jrandom> it'll be backwards compatible, blah blah blah</p>
-14:34 < jrandom> in any case</p>
-14:34  * jrandom winds up</p>
-14:35  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/118.rst b/i2p2www/meetings/118.rst
new file mode 100644
index 00000000..42a38a20
--- /dev/null
+++ b/i2p2www/meetings/118.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 30, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/119.log b/i2p2www/meetings/119.log
index f7ebefc4..6d5539f0 100644
--- a/i2p2www/meetings/119.log
+++ b/i2p2www/meetings/119.log
@@ -1,174 +1,168 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 119{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 7, 2004</h3>
-<div class="irclog">
-22:00:00 <@duck> Tue Dec  7 21:00:00 UTC 2004</p>
-22:00:04 <@duck> I2P meeting time</p>
-22:00:05 < Frooze> i just made Frooze up for i2p.  i don't even know what a 'frooze' is.</p>
-22:00:21 <@duck> as announced on http://dev.i2p.net/pipermail/i2p/2004-December/000509.html</p>
-22:00:29 <@duck> Agenda:</p>
-22:00:29 <@duck> 0) hi</p>
-22:00:29 <@duck> 1) 0.4.2.3</p>
-22:00:29 <@duck> 2) i2p-bt</p>
-22:00:29 <@duck> 3) #idlerpg</p>
-22:00:29 <@duck> 4) ???</p>
-22:00:32 <@duck> .</p>
-22:01:09 <@duck> 0) hi</p>
-22:01:15 < clayboy> hi</p>
-22:01:16 <@duck> jrandom called in sick</p>
-22:01:20 <+ugha2p> Hi.</p>
-22:01:30 <@duck> plus msged me that he'd probably not make it</p>
-22:01:39 <+protokol> http://www.google.com/search?q=frooze</p>
-22:01:41 <@duck> so we'll see and just start</p>
-22:01:46 < clayboy> hope he gets better quick</p>
-22:02:06 <@duck> 1) 0.4.2.3</p>
-22:02:16 <@duck> new release will be out Real Soon</p>
-22:02:31 <@duck> so tomorrow or thursday.</p>
-22:02:41 <@duck> there has been quite a few bugfixes</p>
-22:03:24 <+ugha2p> Do newer CVS revisions also fix the memory/CPU issues?</p>
-22:03:29 < clayboy> a few of us have been following the cvs builds, it's working very nicely</p>
-22:03:33 <@duck> most streaming lib, sam bridge, etc</p>
-22:04:17 <+ugha2p> I've been experiencing some uncommon loads from I2P.</p>
-22:04:23 < clayboy> i think those were fixed many revisions ago, ugha2p</p>
-22:04:41 <+ugha2p> (Running -7)</p>
-22:04:51 < clayboy> oh, hm</p>
-22:04:52 <@duck> ugha2p: dont see anything about that in the history</p>
-22:05:48 <+protokol> you know what would be nice (if not feasable/worth it) is an RSS feed of the changelog</p>
-22:05:48 <@duck> ok</p>
-22:05:49 <+ugha2p> That's strange.</p>
-22:06:01 <+protokol> ;-)</p>
-22:06:17 <@duck> maybe file a bugzilla item</p>
-22:06:25 <@duck> or dunno</p>
-22:06:34 <+ugha2p> The Java process consumes 100% of CPU for about half of the time.</p>
-22:07:18 <+ugha2p> So, you don't know anything about the issue? Do your routers behave OK?</p>
-22:07:24 < dinoman> yea it is high for me to -6</p>
-22:08:24 <@duck> top/uptime info is behaving weird for me since my nptl upgrade, so cant say</p>
-22:09:03 <+ugha2p> Ok, maybe we should move on?</p>
-22:09:07 <@duck> ok</p>
-22:09:14 <@duck> 2) i2p-bt</p>
-22:09:24 <+ugha2p> And ask jrandom when he is about to release 0.4.2.3</p>
-22:09:40 <+ugha2p> It has worked fine for me with NPTL.</p>
-22:09:45 <@duck> ugha2p: he said tomorrow or thursday</p>
-22:09:58 <+ugha2p> Right.</p>
-22:09:59 <@duck> yesterday I released a new i2p-bt</p>
-22:10:23 <@duck> I gained some new understanding of the whole 'buffer' concept</p>
-22:10:42 <@duck> plus there were some previous pending patches from Ragnarok</p>
-22:11:13 < mule> duck: congratulations, good work!</p>
-22:11:15 <@duck> also the slice size is increased, which means that instead of sending 32KB each time, it sends 128KB</p>
-22:11:29 <@duck> which should keep the queue filled</p>
-22:11:47 <+ugha2p> Yeah, thanks, duck. :)</p>
-22:11:56 <@duck> DrWoo and others filed some GUI feature requests</p>
-22:12:23 <@duck> but I never use the GUI myself, wouldnt know wxpython and probably dont care too much :)</p>
-22:12:31 <+Ragnarok> fitting each slice into a single message didn't work as well as expected?</p>
-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)</p>
-22:13:10 <@duck> Ragnarok: it is a bit of a guess</p>
-22:13:27 <@duck> it gives much higher throughput values on local transfers</p>
-22:13:51 <+ugha2p> Maybe we should wait for someone to port a full-featured client instead?</p>
-22:14:10 <+Ragnarok> hm, ok</p>
-22:14:13 <@duck> we can all wait :)</p>
-22:14:37 < clayboy> BitTorrent _is_ "full featured", it's the only client i use for bt (also off i2p) :)</p>
-22:15:15 <+ugha2p> clayboy: Not really. :)</p>
-22:16:02 <@duck> personally I prefer things with sound defaults</p>
-22:16:17 <@duck> take mldonkey, you can change 1 million things and most users have no idea what they do</p>
-22:16:50 <@duck> this leads to user-myths, like i2p users hitting 'Reseed' all the time, or reinstalling if it doesnt work</p>
-22:17:01 <+ugha2p> If you aren't willing to find out, then you shouldn't be using Linux anyway. :)</p>
-22:17:04 <@duck> which kills kittens</p>
-22:17:28 < slart> what about bittornado?</p>
-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</p>
-22:17:45 <+protokol> azureus?</p>
-22:17:57 <@duck> part of me is ofcourse making up excuses not to do things</p>
-22:18:03 <+protokol> azureus supports plugins</p>
-22:18:10 <@duck> protokol: well, write a plugin</p>
-22:18:32 <+protokol> heh</p>
-22:18:40 < slart> bittornado is based off the offical bt isnt it?</p>
-22:18:50 <+protokol> easier said than done</p>
-22:18:52 <@duck> slart: I have looked at it and wept</p>
-22:19:07 <@duck> it has some improvements, which might be useful</p>
-22:19:17 <@duck> but on the other hand it made the whole thing way more complex</p>
-22:19:22 <@duck> without cleaning up the original code</p>
-22:19:36 <+Ragnarok> gah</p>
-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</p>
-22:20:11 < clayboy> let's get the basic bittorrent working excellently before worrying about these fluffy gui things :)</p>
-22:20:46 <@duck> slart: probably some other things can be used too; someone just has to do it (properly)</p>
-22:21:23 <+ugha2p> clayboy: Well, I think it already does work excellently. :)</p>
-22:21:53 < slart> the abc client uses tornado (i think)</p>
-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</p>
-22:22:21 < bushka> yes it does slart.</p>
-22:23:49 <@duck> depending on how those work, you might be able to port the i2p-bt changes to them quite easily</p>
-22:24:41 <@duck> please give it a try and report back</p>
-22:25:47 <@duck> .</p>
-22:25:55 <@duck> any other i2p-bt / bittorrent comments?</p>
-22:26:08 < slart> python :S</p>
-22:26:41 <+ugha2p> .</p>
-22:26:51 <@duck> slart: if you dont like python, you can give porting azureus a try</p>
-22:27:00 <+ugha2p> slart: What about it?</p>
-22:27:06 < slart> how many people could we get seeding somthing like a linux is for speed testing?</p>
-22:27:15 < slart> *iso</p>
-22:27:34 <@duck> lets try that after the new i2p release</p>
-22:27:57 <@duck> (since pulling an i2p router build from cvs is quite a challenge for most)</p>
-22:28:17 <+protokol> eh</p>
-22:28:54 <@duck> pl</p>
-22:28:57 <@duck> err, ok</p>
-22:29:10 <@duck> 3) #idlerpg</p>
-22:29:22 <@duck> found this funny irc rpg game</p>
-22:29:36 <@duck> you dont have to do anything for it, just idle </p>
-22:29:56 <+ugha2p> Well, you do have to LOGIN. ;)</p>
-22:30:04 <@duck> ah ;)</p>
-22:30:18 < mule> cvs update -dP :)</p>
-22:30:18 < mule> ant dist updater :)</p>
-22:30:20 <+postman> it's the most hilarious thing i've ever seen, but i LIKE it :)</p>
-22:30:30 <+protokol> there should be prizes</p>
-22:30:45 <@duck> on ircnet it has 779 online players </p>
-22:30:46 <+ugha2p> duck: I was thinking, that it could potentially be a reason not to upgrade.</p>
-22:30:52 <+protokol> give yodels for winning stuff or reaching levels</p>
-22:31:03 <+ugha2p> Although I'm not sure if people on I2P could be that childish. :)</p>
-22:31:14 <+protokol> i know duck has like $10000 in yodels</p>
-22:31:18 <@duck> protokol: yeah, I have to see how those quests work</p>
-22:31:39 <@duck> maybe we can do some fun stuff with it</p>
-22:31:42 <@duck> ugha2p: what do you mean?</p>
-22:31:49 < ant> * cervantes is not going to do another 40 days without restarting his router</p>
-22:32:08 <@duck> ugha2p: oh, not update because of the game :)</p>
-22:32:18 <+protokol> Linux: If you can't fix it without restarting, you can't fix it.</p>
-22:32:20 <@duck> well, I'll put it on pause while my router restarts</p>
-22:32:24 <+ugha2p> :)</p>
-22:32:33 <@duck> so if you sync it well, you wont lose</p>
-22:32:35 <@duck> hehe</p>
-22:32:55 < ant> <cervantes> thats good... since your router restarts all the time :P</p>
-22:33:16 <@duck> thats called dedicated testing :)</p>
-22:33:20 < ant> <cervantes> I guess that throws roulette into the equation too</p>
-22:33:23 <@duck> ok</p>
-22:33:38 <@duck> .</p>
-22:33:49 <+ugha2p> .</p>
-22:34:05 <@duck> 5) ???</p>
-22:34:08 <@duck> s/5/4/</p>
-22:34:12 <@duck> open mike!</p>
-22:34:23 <+postman> .</p>
-22:34:53 < mule> with a bit of tweaking you can two routers. one for the game only, which you upgrade only every year</p>
-22:34:53 <@duck> questions? comments? suggestions?</p>
-22:35:38 < ant> <mahes> Hi, i have a general non-dev question</p>
-22:36:08 <@duck> shoot</p>
-22:36:08 <+ugha2p> Thanks for holding the meeting, duck.</p>
-22:36:50 < ant> <mahes> if i set up an eepsite , how can be reached with an address like i.e mahes.i2p</p>
-22:36:59 <+protokol> i have a consern</p>
-22:37:44 <+protokol> (start the battle) i think .i2p is a shitty TLD for many reasons</p>
-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.</p>
-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'</p>
-22:38:46 <+ugha2p> protokol: Like .eep?</p>
-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</p>
-22:39:37 <+protokol> ugha2p: sure</p>
-22:40:01 <+ugha2p> protokol: You can make a proposal on the mailing list.</p>
-22:40:03 <@duck> you can post it on the eepsite announcement forum so others can get it too</p>
-22:40:09 <+ugha2p> It'll probably be considered once we have MyI2P.</p>
-22:40:35 <+protokol> heh, ill try but jr shot it down for some reason already</p>
-22:41:06 < ant> <mahes> well. i am just a user...  ok, so i just publish mahes.i2p=hhfbwer8328... and it will just spread</p>
-22:41:32 <@duck> it doesnt spread automatically, ppl need to get it into their hosts.txt somehow</p>
-22:41:39 < ant> <mahes> ok</p>
-22:41:52 <@duck> but announce it on the forum and it is more likely to :)</p>
-22:42:34 <@duck> .</p>
-22:43:18 <@duck> lets give it a *baf*</p>
-22:43:20 <+ugha2p> .</p>
-22:43:30  * ugha2p is waiting for the baffer.</p>
-22:43:38  * duck winds up</p>
-22:43:45  * duck *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/119.rst b/i2p2www/meetings/119.rst
new file mode 100644
index 00000000..f81381df
--- /dev/null
+++ b/i2p2www/meetings/119.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 7, 2004
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/12.log b/i2p2www/meetings/12.log
index ee8c39a5..0726cb69 100644
--- a/i2p2www/meetings/12.log
+++ b/i2p2www/meetings/12.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 12{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 12</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -89,7 +82,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> 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
@@ -313,7 +306,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> 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
@@ -533,7 +526,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 < 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
@@ -545,7 +538,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 < 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?
@@ -615,5 +608,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 08:05 < nop> sheesh
 08:05 < nop> still here
 --- Log closed Wed Sep 25 10:20:49 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/12.rst b/i2p2www/meetings/12.rst
new file mode 100644
index 00000000..40223df2
--- /dev/null
+++ b/i2p2www/meetings/12.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 24, 2002 @ 23:00 UTC
+===============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/120.log b/i2p2www/meetings/120.log
index 346d123c..87ebb10c 100644
--- a/i2p2www/meetings/120.log
+++ b/i2p2www/meetings/120.log
@@ -1,490 +1,484 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 120{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 14, 2004</h3>
-<div class="irclog">
-13:08 < jrandom> 0) hi</p>
-13:08 < jrandom> 1) Net status</p>
-13:08 < jrandom> 2) mail.i2p</p>
-13:08 < jrandom> 3) roadmap</p>
-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.</p>
-13:09 < jrandom> 4) i2pcontent</p>
-13:09 < jrandom> 5) i2p-bt</p>
-13:09 < jrandom> 6) ???</p>
-13:09 < jrandom> 0) hi</p>
-13:09 < jrandom> weekly status notes posted a few minutes back to http://dev.i2p.net/pipermail/i2p/2004-December/000522.html</p>
-13:09  * Pseudonym waves</p>
-13:10 < cervantes> thanks for waiting.... just got back from work ;-)</p>
-13:10 < jrandom> polecat: it isnt exactly 5m (but we can discuss further after the meeting or in it)</p>
-13:10  * polecat nod</p>
-13:10 < jrandom> w3rd, well, i'll give you a moment to jump into the status notes then :)</p>
-13:11 < jrandom> in the meantime, 1) Net status</p>
-13:11  * postman waves</p>
-13:11 < jrandom> the other day, as mentioned on the list, it was pretty turbulent on irc</p>
-13:12 < jrandom> we've made some adjustments though and the bugfixes have gone pretty well</p>
-13:12  * dm waves</p>
-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</p>
-13:13 < Pseudonym> are they related?</p>
-13:13 <+protokol> (for months)</p>
-13:13 < Pseudonym> (the issues, not the people)</p>
-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</p>
-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</p>
-13:14 < jrandom> the solution is to make sure we can build new tunnels that meet the client's needs</p>
-13:15 < Pseudonym> and if we can't?</p>
-13:15 < jrandom> if we can't, the leases will stay expired until we can</p>
-13:16 < Pseudonym> so, how is that different?</p>
-13:16 < jrandom> it isn't :)  </p>
-13:16 < jrandom> we need to be able to build tunnels, period.</p>
-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)</p>
-13:17 < jrandom> the only legitimate cause for not being able to build tunnels is if the entire net is completely saturated</p>
-13:17 <+polecat> or you're cut off from it</p>
-13:17 < jrandom> right</p>
-13:17 < bla> jrandom: Can this be because the net has grown to ~110 peers?</p>
-13:18 < dm> or its cut off from you</p>
-13:18 < jrandom> nah, we've seen this before too bla</p>
-13:18 < Pseudonym> are the "cvs fixes for a long standing profiling bug" in 0.4.2.3 or just CVS?</p>
-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</p>
-13:18 < jrandom> Pseudonym: CVS</p>
-13:19 <+polecat> By profiling you mean ranking peers according to how helpful they are?</p>
-13:19 < jrandom> yeah</p>
-13:19  * Pseudonym wants 0.4.2.4 ;-)</p>
-13:19 <+polecat> Phew.</p>
-13:19 <+polecat> Thought it was some weird kinda function tracing like gprof or something.</p>
-13:20  * orion wants 2.0 :)</p>
-13:20 < jrandom> hehe naw, the profiling bug was in part due to some stupid code that was ignoring daily stats</p>
-13:20  * jrandom too</p>
-13:20  * polecat wants the larval form of a large dog.</p>
-13:20 < jrandom> ok, well, thats about all i've got to bring up for 1) net status - anyone else have anything to add?</p>
-13:21 < jrandom> if not, moving on to 2) mail.i2p</p>
-13:21 < jrandom> postman: you've got the floor</p>
-13:22 <+postman> ok</p>
-13:22 <+postman> sorry</p>
-13:22 <+postman> :)</p>
-13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual</p>
-13:23 <+postman> there's a description for a complete handling of virtual maildomains on www.postman.i2p/user/virtual.html</p>
-13:23 <+postman> (too much red wine)</p>
-13:23 < dm> this is a very unprofessional presentation!</p>
-13:23 <+postman> it tries to explain a system how to handle maildomains other than @mail.i2p addresses</p>
-13:23 < frosk> :D</p>
-13:24  * orion smacks dm in the head with the chalkboard eraser.</p>
-13:24 < frosk> does that i can have frosk@frosk.i2p?</p>
-13:24 <+postman> frosk: indeed</p>
-13:24 < jrandom> v.cool</p>
-13:24 <+polecat> The question is, why?  :3</p>
-13:24 <+postman> it's quite complex, still i ask for comments and ideas for this one</p>
-13:24 < cervantes> s/eraser/</p>
-13:24 < frosk> froody cool</p>
-13:25 <+postman> it might not be a needed feature for a few ppl but the future is bright and shiny</p>
-13:25 < jrandom> there are lots of reasons why - e.g. giving each user @ forum.i2p a mail address, etc</p>
-13:25 < susi23> its a central system bound to postman.i2p</p>
-13:25 <+polecat> Yes, that much seems clear.</p>
-13:25 < susi23> if that machine fails, we're all upset :)</p>
-13:25 <+polecat> jrandom: But if it all has to go through mail.i2p in the first place...</p>
-13:25  * postman is VERY aware of this problem </p>
-13:26 <+postman> :/</p>
-13:26 < jrandom> polecat: perhaps, but perhaps not</p>
-13:26 <+polecat> susi23: exactly!</p>
-13:26 <+postman> the recent implementation is indeed quite single point of failure </p>
-13:26 <+postman> but this applys to the internet bridge as well</p>
-13:27 < jrandom> oh, the second gateway isn't in place yet?</p>
-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.</p>
-13:27 <+postman> jrandom: no baffled has not setup yet</p>
-13:27 < jrandom> ah ok</p>
-13:27 <+postman> polecat: and on WHAT pop3 server should YOUR mailbox reside</p>
-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.</p>
-13:27 < orion> s/usable/identical/</p>
-13:28 <+postman> polecat: who wants to transfer 100MBs of mailbox data every day in 1 year for all 10000 users?</p>
-13:28 <+postman> orion: they will be usable</p>
-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.</p>
-13:29 <+postman> i ask all ppl interested to contribute some ideas</p>
-13:29 <+postman> still the virtual domains is a feature that appears useful and can be implemented regardless of the state of the network</p>
-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.</p>
-13:30 <+postman> polecat: still there is the question of your mailbox </p>
-13:30 <+postman> polecat: your mailbox data must be moved as well and kept synchronized between ALL possible location</p>
-13:30 <+polecat> Ugh... yeah that's true...</p>
-13:30 <+postman> polecat: just consider this for 1000 users in the future</p>
-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</p>
-13:30 <+postman> it's not THAT easy</p>
-13:30 <+polecat> Oh!  But this would work though...</p>
-13:30 <+postman> indeed</p>
-13:31 <+postman> otoh the problem of relaying from and to the internet is still there</p>
-13:31 < dm> jrandom: you're enjoying this, aren't you?</p>
-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.</p>
-13:31 <+postman> polecat: what if THIS server fails?</p>
-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.</p>
-13:32 <+postman> a real redundant system will require a mailbox sync</p>
-13:32 < susi23> yeah, but with such a system everybody could deliver mails within i2p, even if postman.i2p would not be there</p>
-13:32 <+polecat> postman: Then they have to change servers.  -.-</p>
-13:32 < dm> Students having an intelligent conversation between each other. A professor's dream :)</p>
-13:32 <+postman> well, the meeting is hardly the place to DISCUSS all those things</p>
-13:33 <+postman> i am just here to trigger the discussion</p>
-13:33 <+postman> read the document first please and AFTER THAT i am ready to hear your comments</p>
-13:33 <+postman> 2.</p>
-13:33 <+polecat> Alright, so mail.i2p is in the works, and attempting to become less centralized and single point failurey.</p>
-13:33 <+postman> we officially crossed the 100 users with 110 registered accounts</p>
-13:33 <+postman> just FYI</p>
-13:33 < jrandom> w00t</p>
-13:34 <+postman> thats all for today :)</p>
-13:34 <+postman> thanks </p>
-13:34  * dm applauds</p>
-13:34 < jrandom> kickass, thanks postman.  it all looks promising</p>
-13:34 <+postman> :)</p>
-13:35 < mule2> i'd like to bring up a topic on mail, but after the meeting</p>
-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</p>
-13:35 <+postman> there's even a channel for it</p>
-13:35 <+postman> :)</p>
-13:35 < jrandom> heh good point </p>
-13:35 < frosk> which one?</p>
-13:36 < jrandom> #mail.i2p</p>
-13:36 <+postman> frosk: #mail.i2p</p>
-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.</p>
-13:36 < frosk> ok</p>
-13:36 <+polecat> I might post some code later, if it works like, really well.</p>
-13:36 < jrandom> oh, kickass polecat </p>
-13:36 < cervantes> postman: you're welcome to have a dedicated section on the forum</p>
-13:37 <+postman> cervantes: ohh thanks</p>
-13:37  * postman feels honoured :)</p>
-13:37 < dm> You deserve it</p>
-13:38  * postman hands the mike back to hr</p>
-13:38  * postman hands the mike back to jr</p>
-13:38 <+postman> damn</p>
-13:38 <+postman> :)</p>
-13:38 < jrandom> ok, if there's nothing else on 2) mail.i2p, lets jump on over to 3) roadmap</p>
-13:38 <+polecat> vroom vroom!</p>
-13:38 < jrandom> the old roadmap was looking a little... out of date</p>
-13:39 < jrandom> the new one reflects the current view of things</p>
-13:39 < jrandom> hopefully the schedule listed has enough padding, though if more people jump on board perhaps we can beat those estimates :)</p>
-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</p>
-13:41 < frosk> what do you think is a realistic node limit for < 0.6?</p>
-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</p>
-13:41 < jrandom> with some care, i think we'll be able to get up to 3-500</p>
-13:42 < mule2> so no slashdotting please</p>
-13:42 < jrandom> we'd have connection churn at that point, but our low-cost tcp transport shouldn't hurt too much</p>
-13:42 < Pseudonym> the roadmap for 0.6 doesn't mention that. just udp and content dist</p>
-13:42 < Pseudonym> or is it the udp that fixes it?</p>
-13:42  * orion votes for no slashdotting ever</p>
-13:43 < jrandom> Pseudonym: udp fixes it (http://www.i2p.net/todo#transport )</p>
-13:43 < cervantes> postman: http://forum.i2p/viewforum.php?f=22</p>
-13:44 < Pseudonym> orion: I disagree. to get real anonymity we're going to need LOTS of nodes eventually</p>
-13:44 < Pseudonym> at some point we have to tell people about it</p>
-13:44 < jrandom> agreed.  when we need 'em, we'll definitely want to do all sorts of PR</p>
-13:44 < jrandom> the geek crowd will likely be a large part of the userbase</p>
-13:44 < Pseudonym> when do we announce to the geek community? not as a finished product but as a beta for tire-kicking</p>
-13:44 < Frooze> Ask JRandom</p>
-13:45 <+polecat> I think we should be very careful about making this network too popular.</p>
-13:45 < jrandom> Pseudonym: when we've done the best tire kicking we can without them</p>
-13:45 <+polecat> Because one of these days someone is going to use it to do something horrible and illegal.</p>
-13:45 <+polecat> And if we can be tracked down at that point, we will be persecuted right along with the criminal.</p>
-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</p>
-13:47 < mule2> you have to kick me off before :9</p>
-13:47 < Pseudonym> just don't fall into the same trend as Toad with freenet</p>
-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.</p>
-13:47 < orion> speaking of b0rking... was that time-skew bug ever identified?</p>
-13:47 < jrandom> Pseudonym: i believe our roadmap is realistic</p>
-13:48 < jrandom> polecat: agreed, people shouldn't use i2p for things that are 'dangerous' yet</p>
-13:48 < jrandom> orion: no</p>
-13:48 < Pseudonym> jr: I'm not complaining about the roadmap. but it doesn't address announcements</p>
-13:48 < jrandom> true</p>
-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 :)</p>
-13:49 < Pseudonym> perhaps add slashdotting to 0.6? :-)</p>
-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.</p>
-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</p>
-13:49 < dm> as opposed the usual level of maturity when things go big</p>
-13:50 < ant> <jnymo> i think jrandom should write the slashdot article.. he's best at describing i2p, i think</p>
-13:50  * Pseudonym agrees</p>
-13:51 < dm> I'm sure something will go on there before jrandom is comfortable to do it himself ;)</p>
-13:51 < Pseudonym> I'm just trying to nudge him a bit</p>
-13:51 < jrandom> heh</p>
-13:51 < jrandom> well, with 0.6 we'll want to attract a larger user base in any case</p>
-13:51 < Pseudonym> I figure if I can't code, I can at least pester the people who can</p>
-13:51  * jrandom flings mud</p>
-13:52 <+polecat> dm: I'm sure the Second Coming will pass before jrandom is comfortable enough to /. i2p  ;3</p>
-13:52  * Pseudonym ducks. quack</p>
-13:52 < jrandom> ok, in any case, anyone have anything else to discuss wrt the roadmap?</p>
-13:52 < jrandom> or shall we move on to 4) I2PContent ?</p>
-13:53 -!- Irssi: #i2p: Total of 36 nicks [1 ops, 0 halfops, 3 voices, 32 normal]</p>
-13:53 < jrandom> frosk: ping</p>
-13:53  * frosk grabs the wireless mic</p>
-13:54 < cervantes> *zzzzzZzzzzttt*</p>
-13:54  * orion plugs in his RF jammer. ;)</p>
-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.</p>
-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 ;)</p>
-13:54  * dm looks at polecat</p>
-13:54 <+polecat> *shakes head*  Just no luck whatsoever.  No where to be FOUND.  Maybe frosk is invisible!</p>
-13:55 < frosk> "i2pcontent" is so far a document at frosk.i2p</p>
-13:55 < Pseudonym> how is I2PContent different from i2p-bt?</p>
-13:55  * polecat is on 4.4 atm.</p>
-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 :)</p>
-13:55 < ant> * jnymo tries to find a postscript viewer to see these ideas.. :/</p>
-13:56 < dm> what is it, I can't get to frosk.i2p. Executive summary?</p>
-13:56 <+polecat> Pseudonym: i2p-bt only applies to 1 file at a time, and is a swarming download.</p>
-13:56 < frosk> Pseudonym: i2pcontent is a lot like Usenet</p>
-13:56 < frosk> it merges concepts from usenet and freenet. i shall refrain from calling it "frusenet".</p>
-13:56 < jrandom> lol</p>
-13:56 <+polecat> Did you get my suggestion on i2pcontent?</p>
-13:56 < jrandom> frusenet has a ring to it...</p>
-13:56 < frosk> i2pcontent lets you post messages to your blog or to public forums, and publish your address book for others to import</p>
-13:56  * dm did not refrain from calling it frazaa</p>
-13:56 <+polecat> It merges usenet, freenet and livejournal.  So.... Fusejournal?</p>
-13:56 < jrandom> rofl</p>
-13:57 < frosk> hm, yeah, LJ too ;)</p>
-13:57 <+polecat> Lj is the closest parallel I've found.</p>
-13:57 <+polecat> But here's one thing I didn't read in your i2pcontent document.</p>
-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</p>
-13:57 < orion> LiveFuseNet.</p>
-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.</p>
-13:58 < dm> How about: Contnet? ContNet</p>
-13:58 < dm> Content, Contnet... get it? eh???</p>
-13:58 < susi23> jnymo: regarding postscript, I kindly asked frosk to supply us with pdf *blush*</p>
-13:58 < frosk> polecat: that may be interesting, yeah. it's hard to fit into the current design, though</p>
-13:58 < jrandom> i'm not sure, it sounds pretty doable</p>
-13:59 <+polecat> I want HTML or plain text myself.  -.-  Don't like bitmap ps readers. -.-</p>
-13:59 < jrandom> rather than offering a group for syndication, only trusted/known users can get the group</p>
-13:59 < jrandom> (off trusted/known syndication nodes)</p>
-13:59 < frosk> polecat: http://frosk.i2p/i2pcontent-3.pdf if you can handle pdf's :)</p>
-13:59 < jrandom> kind of like usenet's "Distribution:" header</p>
-13:59 < susi23> polecat: ps is not bitmap :P</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.</p>
-13:59 < frosk> hm, yeah</p>
-14:00 < frosk> polecat: blocking to all but friends can be handled with encryption</p>
-14:00 <+polecat> frosk: My PDF reader is this: $ pdf2ps file.pdf > file.ps; gs file.ps</p>
-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</p>
-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.  >.<</p>
-14:01 <+polecat> jrandom: Yes, but ideally the submission queue should be invisible to all but the moderators.</p>
-14:01 < frosk> polecat: oh, transparency is an important keyword in the whole thing :)</p>
-14:01 < jrandom> polecat: you'd lose 99% of the target audience if you say "xterm"</p>
-14:02 <+polecat> jrandom: Heathens!  A grep on them!</p>
-14:02 < ant> <jnymo> mmmmm.. what's usenet?</p>
-14:02 < ant> <jnymo> I mean i've heard of it.. but</p>
-14:02 < susi23> jnymo: news, nntp, google -> groups</p>
-14:02 < frosk> http://en.wikipedia.org/Usenet :)</p>
-14:03 <+polecat> jnymo: newsgroups, eh?</p>
-14:03 < dm> It's good for random porn downloads.</p>
-14:03 < frosk> it's basically the world's oldest and most proven p2p net, as jrandom wrote today</p>
-14:03 < ant> <jnymo> so you can post files up? or links to files?</p>
-14:03 < jrandom> and its bloody resiliant</p>
-14:03 < susi23> dm: its 'use'ful for random porn downloads :P</p>
-14:03 <+polecat> dm: I suppose, if you can find the porn around all the spam.</p>
-14:04 < frosk> it's first and foremost for discussion groups, but it's widely used for files too</p>
-14:04 <+polecat> There's another issue actually.  Spam and all..</p>
-14:04  * dm used to run a 'porn downloader'. It worked well.</p>
-14:04 < ant> <jnymo> so its like the forum format of irc?</p>
-14:04 < frosk> i have thought about spam on i2pcontent, and i don't look forward to it ;)</p>
-14:04  * susi23 points back to topic *blush*</p>
-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.</p>
-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?</p>
-14:05 < frosk> polecat: i2pcontent has that (groups of users editing one blog)</p>
-14:05 < dm> It's amazing usenet is so big considering how few people actually use it.</p>
-14:05 < dm> Average Joe doesn't know what usenet is.</p>
-14:05 < jrandom> dinoman: its an application, definitely not required</p>
-14:06 <+dinoman> :)</p>
-14:06 < ant> <jnymo> yea.. i'm average joe</p>
-14:06 < frosk> but hopefully distributed with i2p ;)</p>
-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...</p>
-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 :)</p>
-14:07 < jrandom> frosk: definitely </p>
-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.</p>
-14:07 <+polecat> jrandom: Why would you say *no* overhead?  c.c</p>
-14:07 <+polecat> Just because you have to select syndicates and blogs to read, before you will download them?</p>
-14:07 < jrandom> jnymo: a usenet-like itnerface to the i2p mailing list: http://news.gmane.org/gmane.network.i2p</p>
-14:08 < jrandom> polecat: no, 0 overhead if you don't use it</p>
-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 :)</p>
-14:08 < jrandom> (as in, just having it installed doesnt make your machine a public data store, etc)</p>
-14:08 -!- ]Replica[ is now known as ]Replica|zZz[</p>
-14:08 < jrandom> and there will probably be i2p announcements done over secure blogs in i2p, worth reading, etc</p>
-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.</p>
-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?</p>
-14:09 <+dinoman> oh so it is not freenet over i2p!</p>
-14:09 < frosk> (i have quite a lag here right now)</p>
-14:09 < jrandom> right dinoman, definitely not</p>
-14:09 < susi23> data organized in "newsgroups" would be great...simply delete/unsubscribe i2p.childporn.* ...</p>
-14:09 <+polecat> dinoman: En. Oh.</p>
-14:10 < ant> <jnymo> jrandom: ah.. that's cool</p>
-14:10 < jrandom> word frosk.  this is definitely some cool shit, and people should throw tons of email at you, and read your blog :)</p>
-14:10 < ant> <jnymo> useful ;)</p>
-14:10 <+polecat> susi23: Right, and if nobody wants to syndicate it, then nobody has to help move it around.</p>
-14:10 < frosk> polecat: yeah, though it adds a bit of complexity, and i'm a simplicity freak ;)</p>
-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</p>
-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</p>
-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 :)</p>
-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.</p>
-14:12 < frosk> jrandom: yes, extensionability is king</p>
-14:12 < frosk> which is why a sound design from the start is important</p>
-14:13 <+dinoman> so let me see if i get this to me (end user) this is going to work like newsgroups.</p>
-14:13 < frosk> polecat: agree</p>
-14:13 <+polecat> dinoman: More like Livejournal, but yes.</p>
-14:14 <+dinoman> well i could learn to like this idea!</p>
-14:14 < frosk> technically it's like newsgroups (on speed), but on the surface it can be like livejournal</p>
-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.</p>
-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</p>
-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.</p>
-14:17 < jrandom> polecat: syndicate(s) used are included in the meta.* post</p>
-14:17 < frosk> polecat: yes, i2pcontent comes with a few "seed syndicates", and the user asks them for more</p>
-14:17 < ant> <Asciiwhite> frost, livejournal?, sounds brillient...</p>
-14:17 <+polecat> jrandom: You need a syndicate to get a meta.* post.  8)  frosk: yeah something like that, cool.</p>
-14:17 < frosk> ah yes, frost people will love i2pcontent ;)</p>
-14:18 < jrandom> heh true</p>
-14:18 < frosk> jrandom: that wasn't my plan, but it sounds very smart, actually :)</p>
-14:18 < frosk> the current syndicate database is a sore point in some ways</p>
-14:18 < jrandom> i thought i saw it in one of your .ps files, perhaps it was just in a conversation though</p>
-14:19 <+polecat> Make it a kademelia DHT!  X3</p>
-14:19  * jrandom groans</p>
-14:19 < jrandom> but yeah, there are lots of optimizations on the syndicate database that can be done</p>
-14:19 < frosk> perhaps you're just thinking smart thoughts and exchange what you read with that ;)</p>
-14:19 < jrandom> lol</p>
-14:19 < ant> <jnymo> so can you embed html?</p>
-14:19 <+polecat> *chants*  DHT DHT DHT USA US--</p>
-14:19 < jrandom> jnym: any content</p>
-14:20 <+polecat> jnymo: Either that or some sort of bbcode type thing.</p>
-14:20 < jrandom> yeah, rendering would be safest with a bbcode-like syntax</p>
-14:20 < dm> frosk: would you like a dedicated section on cervantes' forum?</p>
-14:20 < frosk> blogs and forums will expect text with some markup like bbcode</p>
-14:20 < frosk> dm: i think it's kind of early yet :)</p>
-14:21 < dm> frosk: consider it done!</p>
-14:21 < cervantes> dm: would you like a private sound proof section on my forum?</p>
-14:21 < dm> cervantes: make it so.</p>
-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</p>
-14:21 < dm> how about... contnet?</p>
-14:22 < jrandom> frusejournalrent</p>
-14:22 < frosk> i like!</p>
-14:22  * dm rubs his hands in excitement</p>
-14:22 < jrandom> </fark></p>
-14:22 < dm> </stupid jrandom tag></p>
-14:22 <+polecat> usejournalforrent?</p>
-14:22 < ant> <jnymo> fusenet sounded pretty cool</p>
-14:22 <+protokol> eepnet</p>
-14:22 <+postman> uupnet :)</p>
-14:22 < lurk> froops</p>
-14:23 <+postman> LOL</p>
-14:23 < dm> nnnnnnnnnnnntp</p>
-14:23 <+postman> silly persons</p>
-14:23 <+polecat> "frosk's catchy name for a content distribution syndicate network." We could say "Fcnfacdsn was inspired by Usenet..."</p>
-14:23 < ant> <Asciiwhite> yeah i thought frusenet was good.</p>
-14:23 < frosk> :D</p>
-14:23 < jrandom> ok, please direct all silly names to frosk@mail.i2p :)</p>
-14:23 <+polecat> frootloops!</p>
-14:23 < frosk> i tried frusenet on a friend, he said "... or not."</p>
-14:23 < jrandom> (along with any comments/concerns/etc)</p>
-14:24 < frosk> although fusenet has a cool ring to it :)</p>
-14:24 < dm> How about just 'Content' ?</p>
-14:24 <+polecat> I like fusenet, it sounds... volatile.</p>
-14:24 <+polecat> So yes.  Quieting down now.</p>
-14:24 < Pseudonym> nn2p</p>
-14:24 < dm> Nice and dinstinguished</p>
-14:24 < jrandom> ooOOo</p>
-14:24 < frosk> anyway, i'm not last on the agenda, we might want to move on ;)</p>
-14:24 <+postman> NN2P is COOL</p>
-14:24 < ant> <jnymo> if you had html.. you could have what looks like the net... inside froozlednet</p>
-14:24 < jrandom> ok, moving on to 5) i2p-bt</p>
-14:24 < jrandom> duck: you 'round?</p>
-14:24 <@duck> meep</p>
-14:24 < frosk> dm: "Content" is probably trademarked by Apple or whatever ;)</p>
-14:25 < ant> <Asciiwhite> owww, is this a minutes ?</p>
-14:25 <@duck> i2p-bt events this week:</p>
-14:25 < dm> speeddating!@</p>
-14:26 <@duck> - rss available on the trackers</p>
-14:26 <@duck> - silly attempts to make a metatracker in #eeprnova</p>
-14:26 < ant> <jnymo> noice</p>
-14:26 < ant> <Asciiwhite> yeah, great idea.</p>
-14:26 <+polecat> I still wish we could find a better codebase than that blasted bittorrent python source...</p>
-14:26 < ant> <Asciiwhite> What about support for say samplers(i.e video/pics)</p>
-14:26 <@duck> - some detailed code review leading to not finding bugs</p>
-14:26 <@duck> most of the scary looking errors are pretty harmless</p>
-14:27 <@duck> - I forgot</p>
-14:27 <@duck> .</p>
-14:27 < jrandom> word</p>
-14:27 < jrandom> i've been watching the streaming lib activity while swarming, and there have been some improvements in cvs</p>
-14:28 <+polecat> A metatracker lets you find trackers for files...?</p>
-14:28 < ant> <Asciiwhite> so people can upload a small sample of video quality, or a thumbnail etc.</p>
-14:28 < jrandom> (to keep up with the bt setup)</p>
-14:28 <+polecat> jrandom: Improvements as of what date, this morning?  :3</p>
-14:28 <@duck> polecat: yeah, well this one just announces new files into a channel; but it could be enhanced</p>
-14:28 < jrandom> a day or two ago</p>
-14:29 <+polecat> Just checking, because last time I got CVS Head, you updated to 0.4.3 a few hours later.</p>
-14:29 < ant> <jnymo> yea.. is there some idea for i2ptorrent search some where down the eschelons?</p>
-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</p>
-14:30 <+polecat> Someone'd have to write a searching server, maybe by keyword and such.</p>
-14:30 <@duck> or an irc bot</p>
-14:30 < jrandom> jnymo: http://brittneyworld.i2p/bittorrent/</p>
-14:30 < jrandom> polecat: files.i2p/</p>
-14:30 < ant> <jnymo> hmm</p>
-14:30 < ant> <jnymo> mmhmm.. yea. mk</p>
-14:30 <+polecat> duck: Well a server to search, whether a bot or a eepsite like files.i2p...</p>
-14:31 <@duck> if someone needs rss etc enhancements on the tracker for their bots etc, let me know</p>
-14:31 < ant> <jnymo> hmm.. seems brittanyworld.i2p is down at the moment</p>
-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</p>
-14:32 < jrandom> (yay!)</p>
-14:32 < ant> <jnymo> anyhoo</p>
-14:32 < ant> * jnymo tips his hat</p>
-14:32 < frosk> congrats to all involved, you rock</p>
-14:33 < jrandom> aye, thanks to all the hard work of duck, ragnarok, dinoman, connelly, and drwoo</p>
-14:33 <+polecat> ragnaroks! dinoman's da man!  Um...</p>
-14:33 < ant> <Asciiwhite> nice work duck.</p>
-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.</p>
-14:34 < dm> good work</p>
-14:35 <+polecat> Anyone know where the info about SAM proxies is?</p>
-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!]]</p>
-14:36 < jrandom> polecat: http://www.i2p.net/sam</p>
-14:37 <+polecat> jrandom: Doing a swarming file transfer cost like, money?  o.O</p>
-14:37 <+polecat> Ohh right the reward.</p>
-14:37 < Pseudonym> it'd be kinda cool to have the general fund balance on the website</p>
-14:37 < jrandom> right polecat :)</p>
-14:37 < jrandom> thats a good idea Pseudonym </p>
-14:38 < Pseudonym> doesn't have to be updated daily, just occasionally</p>
-14:38 < jrandom> i'll add it on to /bounties (sound good?)</p>
-14:38 < Pseudonym> sure</p>
-14:38 <+protokol> dont tell me they are keeping the hello chat room</p>
-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 </p>
-14:39 < jrandom> heh cervantes </p>
-14:39 < Pseudonym> didn't somebody donate money for jrandom's beer?</p>
-14:40 < cervantes> enough for half a pint at todays rates :)</p>
-14:40 < jrandom> yeah we've had a few beer donations :)</p>
-14:40 < jrandom> (list of donations up @ http://www.i2p.net/halloffame )</p>
-14:40 < Pseudonym> are you spending them?</p>
-14:41 < cervantes> nice...someone has money to burn I see ;-)</p>
-14:41 < ant> <Asciiwhite> anonymous</p>
-14:41 < ant> <Asciiwhite> $5.00 USD</p>
-14:41 < ant> <Asciiwhite> buy jrandom a beer fund</p>
-14:41 < ant> <Asciiwhite> lol</p>
-14:42 < jrandom> it would be nice if we can grow the bounties on the CDN, as thats a truckload of work</p>
-14:42 < jrandom> but we'll see how it goes over time</p>
-14:42 < jrandom> ok, i think we're pretty off track for 5) i2p-bt</p>
-14:42 < jrandom> so i suppose we should move to 6) ???</p>
-14:42 <@duck> nothing to add here.</p>
-14:43 < jrandom> is there anything else people would like to bring up?</p>
-14:43 <@duck> - why do so many ppl have problems when they specify a hostname?</p>
-14:43 < jrandom> not sure</p>
-14:43 < jrandom> both of my routers use an explicit hostname</p>
-14:43 <@duck> mine too, np</p>
-14:44 <@duck> maybe the warning text should be more negative</p>
-14:44 < jdot_> do we have a way to change keys on hostnames in hosts.txt?</p>
-14:44 < jrandom> sounds good duck </p>
-14:44 <+polecat> Regarding addressbook...</p>
-14:44 < jrandom> jdot_: no, not really, especially in light of the addressbook</p>
-14:44 < jdot_> like, if I lost my previous eepsite key.  :(</p>
-14:44 < mule2> same here - but i have problems :)</p>
-14:44 <+polecat> Addressbook is going to be fused with i2pcontent, right?</p>
-14:45 < mule2> but don't think these result from the hostname</p>
-14:45 < Pseudonym> do we have a working addressbook?</p>
-14:45 <+polecat> You subscribe to an addressbook just like you subscribe to a blog... except it overwrites userhosts.txt and such.</p>
-14:45 < jrandom> polecat: distributing addressbooks through i2pcontent makes sense, yeah</p>
-14:45 < jrandom> Pseudonym: http://ragnarok.i2p/</p>
-14:45 <+polecat> Pseudonym: http://polecat.i2p/addressbook.pl.zip</p>
-14:45 < jrandom> and http://pole...er, what he said</p>
-14:45 < Pseudonym> thanks</p>
-14:46 < jrandom> i think there's also another one at http://orion.i2p too</p>
-14:46 < frosk> polecat: "overwrite" sounds dramatic. it "merges" ;)</p>
-14:47 <+polecat> Yeah... I saw orion's too.</p>
-14:47 < jdot_> dang</p>
-14:47 < jrandom> jdot_: so it looks like you're outa luck :/</p>
-14:47 < jrandom> ok, anyone else have anything for the meeting?</p>
-14:48 < dm> merry xmas</p>
-14:48 <+polecat> jdot: Thankfully when we've got fusenet working, you can update your i2p key with that eventually.</p>
-14:49 < ant> <Asciiwhite> dm, 15th of december here :)</p>
-14:49 < jrandom> and a happy Chanukah</p>
-14:49 <+polecat> Christ was born in September, what's everyone all celebrating about?</p>
-14:49 <+polecat> I'll stick with Yule thanks muchly.</p>
-14:49 < jrandom> ok if thats it...</p>
-14:49  * jrandom winds up</p>
-14:50  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/120.rst b/i2p2www/meetings/120.rst
new file mode 100644
index 00000000..acb82958
--- /dev/null
+++ b/i2p2www/meetings/120.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 14, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/121.log b/i2p2www/meetings/121.log
index 9e7740c0..52e18f21 100644
--- a/i2p2www/meetings/121.log
+++ b/i2p2www/meetings/121.log
@@ -1,329 +1,323 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 121{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 21, 2004</h3>
-<div class="irclog">
-13:05 <@jrandom> 0) hi</p>
-13:05 <@jrandom> 1) 0.4.2.4 & 0.4.2.5</p>
-13:05 <@jrandom> 2) 0.5 strategy</p>
-13:05 <@jrandom> 3) naming</p>
-13:05 <@jrandom> 4) eepsite roundup</p>
-13:05 <@jrandom> 5) ???</p>
-13:06 <@jrandom> 0) hi</p>
-13:06  * jrandom waves</p>
-13:06 <@jrandom> weekly status notes posted a lil while ago @ http://dev.i2p.net/pipermail/i2p/2004-December/000528.html</p>
-13:07 <@jrandom> lets jump on in to 1) 0.4.2.4 & 0.4.2.5</p>
-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!</p>
-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</p>
-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</p>
-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</p>
-13:10 <@jrandom> ah great Madman2003 </p>
-13:10 <@jrandom> yeah, its definitely too early to tell about 0.4.2.5</p>
-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</p>
-13:11 < frosk> (i'm talking about irc lag, of course)</p>
-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</p>
-13:12 <@duck> is that related with the failures on those manually entering a hostname?</p>
-13:12 <@jrandom> yep</p>
-13:12 < dm> how useless is the windows system tray I2P icon!?!?</p>
-13:12 <@duck> ah, so that is why config.jsp is still friendly</p>
-13:13 < Madman2003> anyone have a clue why some still run pre 0.4.2.4 routers?(it's been out a while)</p>
-13:13 <@jrandom> dm: its more of a placeholder right now, plus a status icon saying "i2p is running"</p>
-13:13 < dm> They have a life? :)</p>
-13:13  * jrandom should resent that...</p>
-13:14 < redzog> is there a way to do soft-restarts from the command line?</p>
-13:14 <@jrandom> redzog: unfortunately not</p>
-13:14 < redzog> hmm, pity</p>
-13:14 <@jrandom> other than with wget, perhaps</p>
-13:14 < redzog> would make it easier to do automatic updates</p>
-13:14 <+detonate> i2prouter stop && i2prouter start :)</p>
-13:14 <@jrandom> no, nm, wget wouldnt work either</p>
-13:14 <@jrandom> (as the form requires interaction)</p>
-13:14 < Madman2003> i generally update trough cvs several times in between releases(at best once a day), only takes a few minutes</p>
-13:15 < redzog> lwp::simple could manage it</p>
-13:15 < redzog> just a POST</p>
-13:15 <@jrandom> redzog: support for that would be pretty cool</p>
-13:15 < redzog> I'll try to whip something up</p>
-13:15 <@jrandom> well, its more than just a post, you need to read the form presented to you then post those fields back</p>
-13:16 <+detonate> eventually releases will be further spaced though.. right?</p>
-13:16 <@jrandom> (there's a hidden flag to prevent people from doing things like <img src="/configservice.jsp?action=restart"></p>
-13:16 < redzog> heh, right</p>
-13:16 <@jrandom> right detonate, t'wasn't planned to be this rapid, once a week at most</p>
-13:16 < redzog> does the nonce value change?</p>
-13:17 <@jrandom> if it didn't, it wouldnt be a nonce ;)</p>
-13:17 < redzog> hmm, seems so</p>
-13:17 < redzog> well, between sessions, between pageloads... ;)</p>
-13:17 < redzog> pageloads it is</p>
-13:17 <@jrandom> right</p>
-13:17 <@jrandom> ok, anyone have anything else wrt 0.4.2.4/0.4.2.5?</p>
-13:18 <@jrandom> i'm sur there'll be more discussion later after we've burnt in the new release more</p>
-13:18 < dm> oh, is this a meeting?</p>
-13:18 <+detonate> starting up seems to be a lot less smooth</p>
-13:18 <+detonate> than 2.3</p>
-13:18 <@jrandom> oh?  in what way detonate - cpu, lag, memory, time?</p>
-13:19 <+detonate> the list of peers takes forever to populate</p>
-13:19 <+detonate> and i get a huge number of shitlisted peers</p>
-13:19 <+detonate> also the i2ptunnel stuff sometimes hangs, but generally seems to take at least 2x as long to actually start up</p>
-13:19 <+detonate> once it's started things smooth out</p>
-13:19 <+detonate> it's odd</p>
-13:19 <@jrandom> hmm, what does it list for the cause on /logs.jsp#connectionlogs ?</p>
-13:20 < ant> <BS314159> I just did a graceful restart into 0.4.2.5. It took 120s to have Local Destinations</p>
-13:20 < ant> <BS314159> seems good</p>
-13:20 <@jrandom> cool BS314159 - thats pretty much the bare minimum, as we don't start i2ptunnel until 2 minutes after startup :)</p>
-13:20 <+detonate> there's nothing out of the ordinary</p>
-13:20 <+detonate> a shutdown exception</p>
-13:21 <+detonate> but i think i caused that</p>
-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.</p>
-13:21 <@jrandom> wow, nice mule!</p>
-13:21 < mule> however i still have serious trouble with recovering from an IP change</p>
-13:21 <@jrandom> detonate: hmm, ok, i'd love to debug this further after the meeting or another time you have available</p>
-13:22 <+detonate> yeah</p>
-13:22 <+detonate> ok</p>
-13:22 < dm> tunnel lag: 364ms. What the fuck is going on , the tunnel lag is dropping 100-200ms on each release!</p>
-13:22 <@jrandom> ah mule, ok</p>
-13:22 <@jrandom> i've got an idea for how we could deal with those hung tcp connections - just toss on a 5m keepalive</p>
-13:23 <@jrandom> heh dm, dont worry, it'll get back up again ;)</p>
-13:23 < frosk> wow, i only have 261ms here :)</p>
-13:24 <@jrandom> ok, if there's nothing else, lets jump on to 2) 0.5 strategy</p>
-13:24 < dm> That can't be right...</p>
-13:25 <+ugha2p> Looks like I'm late for the meeting again.</p>
-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</p>
-13:26  * jrandom sends ugha2p to the principal's office</p>
-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</p>
-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</p>
-13:28 <@jrandom> (currently its taking up ~8 pages in the notebook, should compress well though)</p>
-13:29 < kaji> has the meeting started yet?</p>
-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</p>
-13:29 <@jrandom> yes kaji, we're on 2) 0.5 strategy</p>
-13:30 <@jrandom> well, thats all i have to say about that at the moment, unless anyone has any questions/comments/concerns?</p>
-13:31 <+ugha2p> Wow, most of the routers have already upgraded.</p>
-13:31 <+detonate> is filtering http traffic to strip out javascript/etc in the roadmap?</p>
-13:31 <+detonate> for 0.5</p>
-13:31 <+ugha2p> detonate: No.</p>
-13:31 <@jrandom> detonate: 0.6</p>
-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?</p>
-13:32 <@jrandom> cat-a-puss: yes, definitely.  thats one of the big parts of the 0.5 release</p>
-13:32 <+ugha2p> detonate: Unless you implement it first. ;)</p>
-13:32 <+detonate> i was thinking about it</p>
-13:33 < ant> <cat-a-puss> will html filtering be conducted in a seperate process?</p>
-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</p>
-13:33 <+detonate> ok</p>
-13:33 <@jrandom> cat-a-puss: i know not.  </p>
-13:34 <+ugha2p> cat-a-puss: Why should it?</p>
-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.</p>
-13:35 <@jrandom> cool cat-a-puss!</p>
-13:35 <+ugha2p> Some people already use Privoxy for I2P.</p>
-13:36 < bens> in general, I'm anti-including-stuff</p>
-13:36 < susi23> I would rather see people configuring their browsers right than promising to protect them from malicious code.</p>
-13:36 <@jrandom> susi23: no one configures their browser properly</p>
-13:36 <@jrandom> especially not joe sixpack</p>
-13:37 < frosk> one can wonder if Joe is even able to set a proxy for his browser</p>
-13:37 <@jrandom> my personal view is that something cgi-proxy like would be ideal</p>
-13:37 <@jrandom> exactly frosk</p>
-13:37 <@jrandom> with a cgi-proxy like interface (filtering according to their preferences, safe by default), even a drooling moron could use it</p>
-13:38 < bens> I suppose I2P needs multiple versions for multiple markets even more than MS Office</p>
-13:38 <@jrandom> 'tis why we have small components and push this stuff out of the router bens ;)  </p>
-13:38 < Ragnarok> a proxy auto config file would help</p>
-13:39 <@jrandom> Ragnarok: we have one, but there are still dangerous things that can be done with it</p>
-13:39 < frosk> maybe a specialized i2p browser even (if someone is drowning in free time ;)</p>
-13:39 < susi23> ragnarok: that one? http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/apps/proxyscript/i2pProxy.pac</p>
-13:39 <@jrandom> frosk: on the specialized i2p OS and hardware too, i suppose</p>
-13:40 < frosk> hehe, perfect</p>
-13:40 < Ragnarok> that's not in the install, though</p>
-13:40  * jrandom implements those in the specialized i2p universe</p>
-13:40 < susi23> . o O ( perhaps we should try to find a dedicated i2p planet too )</p>
-13:40 < susi23> . o O ( damn, too slow )</p>
-13:40 < mule> ok, we'll sell the hardware :)</p>
-13:40 < frosk> you know what they say, to create something from scratch, first create the universe</p>
-13:41 <@jrandom> w00t, now all we need are some investors..</p>
-13:41 < bens> seriously, a firefox autoconfigurator might be reasonable</p>
-13:41 <@jrandom> bens: the .pac susi linked to above should do the trick</p>
-13:41 < bens> not just for proxy; also for the security settings, homepage, etc.</p>
-13:41 <@jrandom> we can ship that with the install too, but its insufficient for people who need anonymity (and are not ubergeeks already)</p>
-13:42 <@jrandom> hmm, perhaps that sort of thing could go into cervantes' i2p xul app</p>
-13:43 <@jrandom> but thats getting further off topic from the 2) 0.5 strategy</p>
-13:43 <@jrandom> anyone else have anything for that, or shall we move on to 3) naming?</p>
-13:44 -!- Irssi: #i2p: Total of 40 nicks [2 ops, 0 halfops, 6 voices, 32 normal]</p>
-13:44 <@jrandom> consider us moved</p>
-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?</p>
-13:44 <+ugha2p> jrandom: Can we expect the dates on the roadmap to be correct?</p>
-13:45 <@jrandom> ugha2p: they currently reflect my best estimate</p>
-13:45 <+ugha2p> jrandom: Ok, right.</p>
-13:45 < Ragnarok> it's released now</p>
-13:45 <@jrandom> w00t</p>
-13:45 < Ragnarok> check ragnarok.i2p</p>
-13:45 < Ragnarok> I wasn't planning on releasing it yet, but jrandom forced my hand :)</p>
-13:46 <@jrandom> hehe</p>
-13:46 <+ugha2p> Ragnarok: Btw, you're missing a link from the homepage. :)</p>
-13:46 < Ragnarok> it's just a few bug fixes, nothing major, but it should deal better with some corner cases</p>
-13:46 <@jrandom> its on the top right ugha2p </p>
-13:47 < Ragnarok> ugha2p: it's on the sidebar</p>
-13:47 < Ragnarok> I'll add links to the post as well, though :)</p>
-13:47 < mule2> "that'll be the day when i die". daily IP change to set the clock after.</p>
-13:48 < Ragnarok> anyway, if everyone could try it out, that'd be nice.  Bug reports are always appreciated</p>
-13:48 <+ugha2p> Ragnarok: Oh, that sidebar is seriously fucked in Opera.</p>
-13:48 < mule2> Lease expired 12773d ago</p>
-13:49 <+ugha2p> Ragnarok: Well, not really fucked, but just located at the end of the page.</p>
-13:49 <@jrandom> cool Ragnarok, thanks</p>
-13:49 < Ragnarok> your window's probably not wide enough</p>
-13:49 <+ugha2p> Ragnarok: Right, but it should work with any window size.</p>
-13:50 <+ugha2p> So you might want to fix it in the future. :)</p>
-13:50 < Ragnarok> ugha2p: should is an interesting choice of words :)</p>
-13:50 < Frooze> ah, wrong in mozilla 1.7 too.  my window is small though.</p>
-13:50 <+ugha2p> Why's that?</p>
-13:50 < Frooze> thanks ragnarok.  cool stuff.</p>
-13:51 < Ragnarok> I may fix it in the future, but it's really low on my priorities</p>
-13:51  * jrandom prefers addressbook updates to html fixes</p>
-13:52 < Ragnarok> anyhoo, any questions?</p>
-13:53 < frosk> thanks for addressbook, Ragnarok, sounds very useful</p>
-13:54 <+ugha2p> Is the documented way of loading addressbook the only way, or are there any less intrusive ones?</p>
-13:54 < kaji> i just installed it, it rocks</p>
-13:54 < Ragnarok> you can start it by hand using "java -jar addresbook.jar <path to i2p/addressbook>"</p>
-13:54 < Ragnarok> thank you :)</p>
-13:55 < kaji> oh, and i dled version 2.0.0 is there an update someware?</p>
-13:55 < Ragnarok> ok, I fixed the column, it was just a stupid mix of absolute and realitive sizes</p>
-13:56 < Ragnarok> yep, there's 2.0.1 up now on ragnarok.i2p</p>
-13:57 <+ugha2p> I'm getting "Failed to load Main-Class manifest attribute from" now, but never mind, I'll do a restart later.</p>
-13:57 < Ragnarok> whoops</p>
-13:58 < Ragnarok> that's my bad</p>
-13:58 < Ragnarok> I'll try to fix that soon</p>
-13:58 <+ugha2p> Ah, okay. :)</p>
-13:58 < Ragnarok> there will also be an easy to install .war version soon</p>
-13:59 < dm> jrandom: you are a machine</p>
-14:00 <@jrandom> wikked, thanks Ragnarok </p>
-14:00 <@jrandom> susi23: ping?</p>
-14:00 < susi23> 1200ms</p>
-14:01 <@jrandom> !thwap</p>
-14:01 <@jrandom> anyway, wanna give us a rundown on whats up w/ susidns?</p>
-14:01 <@jrandom> or should that wait for later?</p>
-14:01 < susi23> do we have time for a more general discussion about naming stuff?</p>
-14:02 < susi23> what features we want in the future?</p>
-14:03 <@jrandom> some of my thoughts are posted up on http://dev.i2p.net/pipermail/i2p/2004-February/000135.html</p>
-14:03 <@jrandom> (for what general features)</p>
-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</p>
-14:04 < Ragnarok> implementing the data structures you outlined in xml is one of my next goals</p>
-14:04 < susi23> ok, there is a small writing about attributes at http://susi.i2p/removablekeys.html</p>
-14:05 < ant> <Jnymo> wow.. pretty crowded in here tonight</p>
-14:05 < bens> ragnarok: have you checked out YAML? Might be easier</p>
-14:05 <+ugha2p> Jnymo: Yeah, we're trying to hold a meeting here.</p>
-14:05 < Ragnarok> YAML's name is far too apt</p>
-14:05 <@jrandom> cool susi23, though i think we'll definitely want to migrate away from the plain hosts.txt format</p>
-14:05 < ant> <Quadn-werk> addition of a command line graceful restart?</p>
-14:06 < ant> <Jnymo> ugha2p: ah</p>
-14:06 < susi23> are there any ideas how to keep names unique in the long run?</p>
-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)</p>
-14:07 <@jrandom> i dont believe in globally unique human, human readable, and secure names.</p>
-14:07 <@jrandom> (i bundle centralized & secure together)</p>
-14:07 <@jrandom> susi23: have you seen http://zooko.com/distnames.html ?</p>
-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</p>
-14:08 <@jrandom> Ragnarok: we'll see.  perhaps</p>
-14:08 < susi23> i'll check this out</p>
-14:08 < bens> I suspect trusted authorities will emerge</p>
-14:08 < Ragnarok> well, there already is one</p>
-14:08 < frosk> hosts.txt? :)</p>
-14:09 < Ragnarok> jrandom's, yeah</p>
-14:09 <@jrandom> or if not trusted authorities, names that include the path to uniquely identify it</p>
-14:09 <@jrandom> (e.g. "the site orion.i2p calls 'frosk.i2p'")</p>
-14:10 <@jrandom> Derek Eddington had some posts along those lines in september - http://dev.i2p.net/pipermail/i2p/2004-September/000432.html</p>
-14:10 < bens> frosk.orion.i2p</p>
-14:10 <@jrandom> smtp.frosk.ns.orion.i2p</p>
-14:11  * jrandom starts building uucp bang paths</p>
-14:11 < frosk> hah</p>
-14:12 < susi23> ok, what now... how about a "naming roadmap"? :)</p>
-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</p>
-14:12 < susi23> once we agreed what to do</p>
-14:12 <@jrandom> thats a good idea susi23, wanna write one up?</p>
-14:13 <@jrandom> trusting other people's trust has potential, but needs to be done very carefully</p>
-14:13 < susi23> I could do this, but I still have no idea WHAT we want to do. There are some decisions to make.</p>
-14:14 <@jrandom> (aka only according to the terms that you trust the peers along the chain to the trust author)</p>
-14:14 < modulus> there is or there should not be a "network trust" of a site, trust has to be user-centric always</p>
-14:14 <@jrandom> susi23: roadmap step 1: decide among $featureset</p>
-14:14 < susi23> Or at least we have to develop all ideas into a more precise concept.</p>
-14:14 < ant> <Jnymo> well, if it was explicitly simple.. like, if files i2p listed how many sites linked to siteinquestion.i2p</p>
-14:15 < Ragnarok> ok, the I've updated the addressbook package with an executable jar.</p>
-14:15 < ant> <Jnymo> er, files.i2p</p>
-14:15 <@jrandom> jnymo: that turns into a centralized authority - files.i2p</p>
-14:15 < modulus> not to say that you could poison the pool of links by establishing a shitload of sites.</p>
-14:16 < modulus> googlebombing on i2p</p>
-14:16 < ant> <Jnymo> true.. but files i2p could be decentralized</p>
-14:16 < susi23> ok, how about collection ideas/information/concepts until, lets say january</p>
-14:16 < orion> 'lo all. I see naming is on the table.. *again* :)</p>
-14:16 < susi23> then comes the decision phase, ok?</p>
-14:16 <@jrandom> sounds good - will you be the point of contact to gather that together?</p>
-14:16 < Ragnarok> sure</p>
-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.</p>
-14:17 < susi23> can't we take the mailinglist for this?</p>
-14:17 < bob> or perhaps ugha's wiki?</p>
-14:17 < ant> <Jnymo> agreed.. but what how to do that? put a little trust meter bar at the top of the web browser?</p>
-14:18 <@jrandom> the wiki would be good, we can gather links to all the previous discussions there</p>
-14:18 < modulus> jnyo: probably the most feasible solution is to bind to the first name encountered or something.</p>
-14:18 < dm> let's all give a hand of applause to jrandom for his wonderful project management</p>
-14:18 < susi23> fine</p>
-14:18 < modulus> but there are more ways than sausages.</p>
-14:19 < susi23> url to the wiki? (for the records)</p>
-14:19 < ant> * Jnymo claps</p>
-14:19 <@jrandom> ugha.i2p</p>
-14:19  * dm claps</p>
-14:19 < susi23> ok</p>
-14:19 < susi23> then I'm done and ping jrandom back ;)</p>
-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.. </p>
-14:20 <+ugha2p> Looks like jrandom has ping timeouted.</p>
-14:20 <@jrandom> ok cool, anything else on nami^W nm, no more on naming.  on to the wiki</p>
-14:20 < modulus> anyway, if you're linking you'll probably want to put an absolute path in the link, not just a name</p>
-14:21 <@jrandom> moving forward to 4) eepsite roundup</p>
-14:21 < dm> dm.i2p is up and running</p>
-14:21 <@jrandom> cool</p>
-14:22 <@jrandom> ok, i dont really have much to add beyond whats mentioned in the mail</p>
-14:22 < bob> nice to see an influx of sites!  all speedy to access as well!</p>
-14:22 <@jrandom> aye, agreed bob</p>
-14:22 < bob> orion, thanks for your work.. I use your site daily.</p>
-14:22  * jrandom too, the 'last updated' is especially helpful</p>
-14:23 < bob> dm: :-)</p>
-14:24 <@jrandom> ok, if there's nothing more on that, we can jump to 5) ???</p>
-14:24 <@jrandom> is there anything else people want to bring up for the meeting?</p>
-14:24 < ant> <Jnymo> hows the net status?</p>
-14:24 < ant> <Jnymo> wrt 4.2.5?</p>
-14:25 <@jrandom> its looking good, but the release is only a few hours old, so too soon to tell</p>
-14:25 < ant> <Jnymo> oh, heh</p>
-14:25 < ant> <Jnymo> any fusenet news?</p>
-14:26 <@jrandom> (http://piespy.i2p/i2p/i2p-current.png heh)</p>
-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)</p>
-14:26 < frosk> i2pcontent/fusenet/anything ;)</p>
-14:26 < ant> <Jnymo> wordicus</p>
-14:28 <@jrandom> ok, if there's nothing else...</p>
-14:28 < mule2> tons of applause for all the excellent contributions</p>
-14:29 <@jrandom> aye, y'all are doing some kickass shit</p>
-14:29 < frosk> you too, jrandom :)</p>
-14:29 < orion> word.</p>
-14:29 < orion> yes, very much so, you too jrandom.</p>
-14:29 < scintilla> hear hear!</p>
-14:29 < ant> <Jnymo> yea, i noticed on the site, theres less info on how to help out</p>
-14:29 <@jrandom> sometimes kickass, sometimes ass kicked ;)</p>
-14:29 < orion> HIP HIP</p>
-14:30 < ant> <Jnymo> HORRAY</p>
-14:30  * orion smiles</p>
-14:30 < Frooze> downloaded eclipse today, to learn java over holiday, because y'all are so impressive.</p>
-14:30 <@jrandom> jnymo: many of the small easy-to-accomplish tasks have been done</p>
-14:30 <@jrandom> ooh wikked Frooze </p>
-14:31 < Frooze> so, trouble on horizon.  heh</p>
-14:31 <@jrandom> jnymo: i really should collect some more of them though and post 'em</p>
-14:31 < ant> <Jnymo> jrandom: You still looking for someone to help out on alexandria.i2p?</p>
-14:31 <@jrandom> (take cover arizona!)</p>
-14:31  * jrandom is not involved in alexandria, but yes, i believe they are still looking for a librarian</p>
-14:31 < ant> <Jnymo> learn to swim, folks ;)</p>
-14:31  * orion loves pump up the volume references. Vague though they may be.</p>
-14:31 <@duck> yes we do</p>
-14:31 <@jrandom> :)</p>
-14:31 < Ragnarok> jrandom: where is the war actually supposed to go?</p>
-14:31 <@jrandom> (orion++)</p>
-14:32 <@jrandom> Ragnarok: i2p/webapps/addressbook.war</p>
-14:32 <@jrandom> (then restart the router)</p>
-14:32 < ant> <Jnymo> duck, you talkint to me?</p>
-14:32 < Ragnarok> cool.  I shall commence testing</p>
-14:32 <@jrandom> r0x0r</p>
-14:32 < ant> <Jnymo> duck: is alexandria on your site?</p>
-14:33 <@duck> duck.i2p/alexandria/</p>
-14:33 < ant> <Jnymo> word</p>
-14:34 <@jrandom> ok, if thats all, we can slide out of here @ the 90m mark..</p>
-14:34  * jrandom winds up</p>
-14:34  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/121.rst b/i2p2www/meetings/121.rst
new file mode 100644
index 00000000..fe8bd9b8
--- /dev/null
+++ b/i2p2www/meetings/121.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 21, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/122.log b/i2p2www/meetings/122.log
index 87e5162e..02a3e125 100644
--- a/i2p2www/meetings/122.log
+++ b/i2p2www/meetings/122.log
@@ -1,201 +1,195 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 122{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 28, 2004</h3>
-<div class="irclog">
-13:06 <@jrandom> 0) hi</p>
-13:06 <@jrandom> 1) 0.4.2.5</p>
-13:06 <@jrandom> 2) 0.5</p>
-13:06 <@jrandom> 3) ???</p>
-13:06 <@jrandom> 0) hi</p>
-13:06  * jrandom waves</p>
-13:06 <+postman> *wave*</p>
-13:06 < ant> <jnymo> hello</p>
-13:06 <@jrandom> brief status notes posted up @ http://dev.i2p.net/pipermail/i2p/2004-December/000535.html</p>
-13:07 <@jrandom> jumping in to 1) 0.4.2.5</p>
-13:07 <@jrandom> as mentioned, things are pretty much working</p>
-13:08 <+postman> yeah, quite impressive</p>
-13:08 <+postman> no more lease timouts on my systems at all</p>
-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 ;)</p>
-13:08 < ant> <jnymo> me too</p>
-13:08 <@jrandom> nice</p>
-13:08 < ant> <jnymo> and eepsites are snappy</p>
-13:09 <+postman> :)</p>
-13:09 < ant> <jnymo> thanks postman :)</p>
-13:09 <+postman> totsl bw is 29kb / 30.1kb/s</p>
-13:09 < frosk> everybody feels less loved, but in reality the love is just being put more efficiently to work</p>
-13:10 < ant> <jnymo> wow</p>
-13:10 <@jrandom> b1tchin postman </p>
-13:10 < mule2> i don't think that is the preferred ideal. we'd better have some traffic through all nodes</p>
-13:10 < ant> <jnymo> i could handle that if people just loved me :(</p>
-13:10 <+postman> yep</p>
-13:10 < mule2> as kind of cover traffic</p>
-13:10 <@jrandom> mule2: its a matter of our load being much less than our network capacity</p>
-13:11 <@jrandom> i dont think we'll be able to keep the capacity greater than the load for long</p>
-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</p>
-13:11 <@jrandom> so i'm not too worried about not pushing any data through slower peers</p>
-13:12 < mule2> probably less perfect optimization would be good for anonymity</p>
-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 ;)</p>
-13:12 < jdot__> i it a security issue that one router handles all(ish) tunnels?</p>
-13:13 <@jrandom> mule2: lets first get it as good as we can get it, then we can discuss proactively making it worse</p>
-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</p>
-13:14 <@jrandom> plus the reduced tunnel failures means we're shifting & exploring less</p>
-13:14 < mule2> perhaps some traffic distribution would be possible, as long as we are far from the routers limits</p>
-13:14 <@jrandom> right, probabalistic tunnel rejection is in the router and can be enabled based on the router's bandwidth limits</p>
-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..</p>
-13:15 <@jrandom> (but if postman doesnt set any limits, we can't reject based on a % of that ;)</p>
-13:15 < ant> <jnymo> groupings of faster nodes cause something of a mix cascade structure, no?</p>
-13:15 <@jrandom> aye, that is one way to look at it</p>
-13:15 < lektriK> can I close the Start I2P window?</p>
-13:15  * postman is very sorry NOT to restrict his bandwidth</p>
-13:16 <@jrandom> lektriK: unfortunately, not really, unless you start i2p as a service (See http://localhost:7657/configservice.jsp)</p>
-13:16 <@jrandom> heh postman dont worry, we'll back off your router if/when we reach your router's capacity</p>
-13:17 < lektriK> Ok, it sais service started</p>
-13:17 < lektriK> can I close it now?</p>
-13:17 <@jrandom> lektriK: no/yes - you can shut down your router then start it again via start->run->"net start i2p"</p>
-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.</p>
-13:18 < mule2> don't want to complain about the network behaving to good :)</p>
-13:18 <@jrandom> hehe</p>
-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)</p>
-13:21 <@jrandom> anyway, anyone else have something to bring up for 0.4.2.5?  </p>
-13:21 <@jrandom> or shall we move on briefly to 2) 0.5?</p>
-13:21 <+postman> move</p>
-13:21 < ant> <jnymo> very stable... move</p>
-13:21 <@jrandom> consider us moved</p>
-13:22 <@jrandom> 2) 0.5</p>
-13:22 <@jrandom> yeah.  still work in progress.  more info when its ready.</p>
-13:22 < ant> <Quadn-werk> Sir Arthur C. Clarke is alive :P</p>
-13:22 < ant> <Quadn-werk> http://slashdot.org/articles/04/12/28/0120240.shtml?tid=99&tid=1</p>
-13:22 < ant> <jnymo> .5 is exciting</p>
-13:22 <@jrandom> ok, thats all i have to say on that - anyone have any questions / things to discuss about it?</p>
-13:23 <@jrandom> aye, there are definitely some important revamping going on, based on what we've learned over the last 16 months</p>
-13:23 <@jrandom> (or shit, 18)</p>
-13:23 <+postman> jrandom: so 0.5 will emnploy a new tunnel management system mostly?</p>
-13:23 < ant> <Quadn-werk> arg, i hope i didnt interrupt the meeting :/</p>
-13:23 <+postman> wow</p>
-13:23 < ant> <Quadn-werk> sorry heh</p>
-13:23 < ant> <jnymo> heh. i had a suggestion</p>
-13:24 <@jrandom> yeah postman, new management, pooling, and building</p>
-13:24 <+postman> quadn: look what you've done - your paste caused a netsplit :)</p>
-13:24 <@jrandom> you bastard!</p>
-13:24 < ant> <Quadn-werk> !</p>
-13:24 <@jrandom> sup jnymo?</p>
-13:24 <+postman> jrandom: will every tunnel be a separate local destination still?</p>
-13:25 <@jrandom> huzzawuzzah?</p>
-13:25 <@jrandom> there won't be any change to i2ptunnel in 0.5</p>
-13:25 <+postman> jrandom: ok</p>
-13:25 <@jrandom> (at least, i dont plan on any)</p>
-13:26 < mule> postman mounting an intersection attack?</p>
-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</p>
-13:26 <+postman> mule: no, it was quadn's fault :)</p>
-13:26 < ant> <jnymo> and that would be a dummy tunnel</p>
-13:27 <@jrandom> jnymo: advertising a router as saying "hey i have excess bandwidth, use me" is a dangerous game</p>
-13:27 <+postman> jrandom: what issues will then be addressed by the redesign  ( in a nutshell )</p>
-13:27 < ant> <jnymo> not sure i meant that, jrandom</p>
-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</p>
-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</p>
-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)</p>
-13:29 <@jrandom> (oh, and improving performance by getting rid of a lot of modPow calls)</p>
-13:29 <+postman> ok thanks</p>
-13:29 < ant> <jnymo> postman: and per hop tunnel ids is a big one</p>
-13:30 <+postman> modpow?</p>
-13:30 <@jrandom> ah jnymo.  yeah, there's a lot of potential for various chaff traffic generation</p>
-13:30 < ant> <jnymo> that way, no two non-neighboring nodes can know there on the same tunnel, postman</p>
-13:30 <@jrandom> postman: modular exponentiation, heavy cpu usage & memory waste</p>
-13:31 < ant> <jnymo> jrandom: k cool</p>
-13:31 <+postman> k</p>
-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)?</p>
-13:31 < ant> <jnymo> cpu power</p>
-13:32 <@jrandom> when necessary we can add hashcash, but excessively long tunnels will just end up failing anyway</p>
-13:32 < scintilla> ah good point</p>
-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'</p>
-13:33 <@jrandom> (so if the tunnel was 20 hops long, it'd take them too long to build all those hops)</p>
-13:33 < scintilla> that's a great idea - that'll keep any such ridiculousness from lingering for very long</p>
-13:33 <@jrandom> but thats all vs the hackers.  normal users will just use the exposed interface</p>
-13:34 < ant> <jnymo> right, which you'll cap off somewhere right?</p>
-13:34 < ant> <jnymo> we'll get higher than the maximum 2 as it is now, right?</p>
-13:34 <@jrandom> right, like the # hops drop down on /configclients.jsp or /i2ptunnel/edit.jsp</p>
-13:35 <@jrandom> oh i thought the max was 3 now?  ok, but yeah, higher than 2 will be available</p>
-13:35 < ant> <jnymo> 3 tunnels, 2 hops</p>
-13:35 <@jrandom> ah 'k</p>
-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</p>
-13:36 < frosk> the max is indeed 3</p>
-13:36 < ant> <jnymo> hmm</p>
-13:37 <@jrandom> ah its 3 on /configclients 2 on i2ptunnel</p>
-13:37 < frosk> is 0.5 still on track for january?</p>
-13:37 < ant> <jnymo> ah</p>
-13:37 <@jrandom> yeah frosk</p>
-13:37 < frosk> goodie</p>
-13:37 <@jrandom> i wont dawdle too much longer on the streaming lib, i promise ;)</p>
-13:37 < frosk> it just sounds like a lot of work :)</p>
-13:38 <@jrandom> its actually not so bad, the hard part is getting the algorithms right</p>
-13:38 <@jrandom> (details schmetails ;)</p>
-13:39 <+postman> frosk: and it's all on paper already</p>
-13:39 <+postman> :)</p>
-13:39 < ant> <jnymo> heh</p>
-13:39 < frosk> true :)</p>
-13:39 <@jrandom> mostly yeah ;)</p>
-13:39 <@jrandom> ok, anyone have anything else for 2) 0.5?</p>
-13:39 < ant> <jnymo> nada</p>
-13:39 < frosk> el zilcho</p>
-13:40 <@jrandom> 'k, swingin on to good old fashioned 3) ???</p>
-13:40 <@jrandom> hi</p>
-13:40 <@jrandom> anyone have anything else they want to bring up?</p>
-13:41 < ant> <jnymo> postman: there arent smtp/pop3 inproxies on i2pmail.org are there?</p>
-13:41 < cat-a-puss> I am still seeing weird delays on the client end...</p>
-13:41 <+postman> hrm no</p>
-13:41 < frosk> this is where i'd hand over the congratulatory bottle of wine for a fine year of development ;)</p>
-13:41 <+postman> jnymo: POP3 is only available for i2p users</p>
-13:41 <@jrandom> cat-a-puss: ah i missed those messages when you were around earlier</p>
-13:41 <+postman> jnymo: there IS a SMTP inproxy as MX for the domain i2pmail.org</p>
-13:42 <@jrandom> frosk: cheers</p>
-13:42 < ant> <jnymo> right right.. that's coo'..</p>
-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</p>
-13:42 < mule> cat-a-puss: do you also hand over the bonus cheque ?</p>
-13:42  * postman donates a good whiskey </p>
-13:42 <@jrandom> cat-a-puss: right, you saw a .5-1.0s delay right?</p>
-13:42 < cat-a-puss> mule: what?</p>
-13:42 < cat-a-puss> jrandom: yeah</p>
-13:43 <@jrandom> cat-a-puss: perfectly normal, part of the deferred syn</p>
-13:43 < mule> sorry, the comment was from frosk</p>
-13:43 < ant> * jnymo pulles out that crappy box wine</p>
-13:43 < mule> frosk: do you also hand over the bonus cheque ?</p>
-13:43 <@jrandom> (it waits a bit to send the SYN and the related ACK in case there is more data to bundle)</p>
-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</p>
-13:44 <@jrandom> ah kickass</p>
-13:44 < ant> <jnymo> mmm, someone was wanting to mount some attacks on i2p</p>
-13:44 < ant> <jnymo> who was that?</p>
-13:44 <@jrandom> connelly</p>
-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?</p>
-13:45 < ant> <jnymo> any word on that, jr?</p>
-13:45 <@jrandom> cat-a-puss: yeah there are some options you can pass when creating the I2PSocketManager, lemmie pull 'em up</p>
-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</p>
-13:46 < ant> <jnymo> scintalla: what's the fortuna algorithm?</p>
-13:46 < ant> <jnymo> jrandom: aight</p>
-13:48 <@jrandom> cat-a-puss: i2p.streaming.initialResendDelay=50 i2p.streaming.connectDelay=100</p>
-13:48 < scintilla> it's a cryptographically secure pseudo-random number generator... something which is absolutely essential for trustworthy encryption</p>
-13:48 < jdot__> anyone volunteer for that attack yet?</p>
-13:48 <@jrandom> cat-a-puss: then be sure to flush() after write()ing to the I2PSocket</p>
-13:48 <@jrandom> jdot__: yeah, he has 7 volutneered sites</p>
-13:48 < cat-a-puss> jrandom: ok</p>
-13:49 < ant> <jnymo> wrt the great naming debate.. </p>
-13:49 < ant> * jnymo snickers</p>
-13:49 <@jrandom> oh and i2p.streaming.initialAckDelay=1000</p>
-13:49 <@jrandom> or even =100</p>
-13:49  * jrandom flings mud at jnymo</p>
-13:50 < ant> <jnymo> i actually do work with x500 and my job lets me have free winSevers</p>
-13:50 < ant> <jnymo> so, perhaps i'll just set up a central DNS for testing purposes in a month or two</p>
-13:51 <@jrandom> heh, having a centralized naming server hosted on a .mil would be bloody hilarious </p>
-13:51 < ant> <jnymo> though hacking i2p addresses into winserver may be non-trivial.. dunno</p>
-13:51 < ant> <jnymo> heh.. dnsalias is the ticket</p>
-13:52 <@jrandom> nano has done some really cool work, integrating dnsjava with i2p</p>
-13:52 < ant> <jnymo> ooooh</p>
-13:53 <@jrandom> check out nano.i2p for more details</p>
-13:53 < ant> <jnymo> and no one was going to tell me.. ah, thanks</p>
-13:53 <@jrandom> but, as mentioned last time, people should post up their thoughts and ideas about naming to the wiki</p>
-13:54 <@jrandom> ok, anyone else have something to bring up for the meeting?</p>
-13:55 < ant> <jnymo> nope</p>
-13:57 <@jrandom> ok in that case</p>
-13:57  * jrandom winds up</p>
-13:57  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/122.rst b/i2p2www/meetings/122.rst
new file mode 100644
index 00000000..86fe2f26
--- /dev/null
+++ b/i2p2www/meetings/122.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 28, 2004
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/123.log b/i2p2www/meetings/123.log
index 076d9577..dba2ec01 100644
--- a/i2p2www/meetings/123.log
+++ b/i2p2www/meetings/123.log
@@ -1,160 +1,154 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 123{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 4, 2005</h3>
-<div class="irclog">
-13:09 <@jrandom> 0) hi</p>
-13:09 <@jrandom> 1) Net status</p>
-13:09 <@jrandom> 2) 0.4.2.6</p>
-13:09 < ant> <DrVince> It says that it can't find tools.jar but doesn't stop</p>
-13:10 <@jrandom> 3) 0.5</p>
-13:10 <@jrandom> 4) jabber @ chat.i2p</p>
-13:10 <@jrandom> 5) ???</p>
-13:10 <@jrandom> 0) hi</p>
-13:10  * jrandom waves</p>
-13:10 < eco> hi</p>
-13:10 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-January/000541.html</p>
-13:10 <@jrandom> DrVince: if you can hang around, we can hack through that after the meeting</p>
-13:10 < ant> <DrVince> Cool</p>
-13:11 <@jrandom> jumping on into 1) Net status</p>
-13:11 <@jrandom> (as i'm sure y'all have read the weekly status notes already *cough*)</p>
-13:11 <@jrandom> basically, the net seems to be working well</p>
-13:11 <@jrandom> we still do have more irc disconnects than usual though, but not a horrid amount</p>
-13:12 <@jrandom> hopefully the next release (with the streaming lib improvements) will help out, as will further load balancing off duck's server</p>
-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)</p>
-13:13 <+protokol> yeah</p>
-13:13 <@jrandom> a fully distributed chat system would be neat, but i'm not holding my breath.  plus, irc works good enough</p>
-13:14 <@jrandom> ok, thats all i have wrt 1) net status</p>
-13:14 <@jrandom> does anyone have anything to add, comment, etc?</p>
-13:14  * eco has been away for a while (what's new)</p>
-13:15 < eco> and was happily surprised by the state of things. very good progress</p>
-13:15 < Myo9> Wasn't the meeting at 10?</p>
-13:15 < eco> both performance and usability wise</p>
-13:15 < eco> Myo9 10GMT (general meeting time)</p>
-13:16 <@jrandom> 9p GMT</p>
-13:16 <@jrandom> the last year has definitely brought a lot of progress</p>
-13:17  * eco hands out cookies to all devs and then shuts up</p>
-13:17 <@jrandom> *munch*</p>
-13:17 <@jrandom> ok, jumping on to 2) 0.4.2.6</p>
-13:18 <@jrandom> new release coming with bugfixes, improvements, and the addressbook bundled in</p>
-13:18 <@jrandom> i dont know exactly when it'll be out, maybe end of the week</p>
-13:18 <@jrandom> it'll be announced on the list and in the channels, of course</p>
-13:19 <@jrandom> thats all i have to say on that - anyone have any questions/comments/concerns wrt 0.4.2.6?</p>
-13:19  * eco recalls someone mentioning Debian packages</p>
-13:20 <@jrandom> os/distro-specific packaging is probably premature at the moment</p>
-13:20 < eco> Burton is willing to give that a try, but that won't be this week i guess</p>
-13:20 <@jrandom> ah cool, i hadn't heard that</p>
-13:21 < eco> agree, though it would be handy</p>
-13:21 <+protokol> hold on, im pretty high</p>
-13:21 <+protokol> oops</p>
-13:21 <+protokol> that was supposed to be a PM</p>
-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</p>
-13:21 <+protokol> i can look into making an ebuild</p>
-13:21 <@jrandom> protokol: if you're nice, i'll cut that out of the logs ;)</p>
-13:21 <+protokol> no guarentees</p>
-13:21 <+protokol> lol</p>
-13:22 <@jrandom> yeah, i wouldn't worry about packages until 0.5, if not 1.0</p>
-13:22 <@jrandom> (i hope to have the auto-updater in 0.5)</p>
-13:22 <+protokol> awesomecore</p>
-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</p>
-13:23 < Myo9> Auto-updater, sounds like a threat.</p>
-13:23 <+protokol> modulus: welsome</p>
-13:23 <+protokol> $200 bounty for it</p>
-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</p>
-13:24 < ant> * DrVince had a problem with i2pupdate.zip</p>
-13:24 < ant> <cervantes> something that can be enabled or disabled would be nice ;)</p>
-13:24  * protokol makes it offical</p>
-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.</p>
-13:24 <@jrandom> protokol: oh cool, send in the $200 and i'll add that to the bounty page </p>
-13:24 < Myo9> ;)</p>
-13:24 < Myo9> I want auto-update turned off by default.</p>
-13:24 <@jrandom> agreed myo9</p>
-13:25 < ant> <cervantes> perhaps the routerconsole can be ammended to notify if a new version is available</p>
-13:25 <@jrandom> right cervantes</p>
-13:25 < Myo9> Great!</p>
-13:25 <@jrandom> it would want to display whether there is a new release, and give the user a one click option to upgrade</p>
-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)</p>
-13:26 <@jrandom> ((or on demand))</p>
-13:26 < Hybrid> yes jrandom. that would be cool.   also on the button a link to 'whats new' html page</p>
-13:26 <@jrandom> Hybrid: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD</p>
-13:26 < ant> <cervantes> yeah...I've got a page on the forum that lets my firefox toolbar know of latest "events"/news</p>
-13:27 <@jrandom> but yeah, a link there too would be nice</p>
-13:27 <@jrandom> ah cool cervantes</p>
-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)</p>
-13:27 < ant> <cervantes> don't count on me releasing anything yet though....</p>
-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</p>
-13:28 < ant> <cervantes> wanted to spend the holidays working on it and have so far done absolutely nothing...</p>
-13:28 <@jrandom> but this won't be bundled into the 0.4.2.6 release, because i havent written any of this code :)</p>
-13:28 <@jrandom> heh cervantes, i hear you.  i do look forward to the xul though!</p>
-13:29 <@jrandom> ok, anyone have anything else wrt 2) 0.4.2.6, or shall we move on to 3) 0.5?</p>
-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</p>
-13:30 < Hybrid> (sorry interrupting dev meeting lol)</p>
-13:30 <@jrandom> Hybrid: not a problem at all - thats what the "graceful restart" button on http://localhost:7657/configservice.jsp does</p>
-13:30 < Hybrid> k</p>
-13:31 < ant> <cervantes> jrandom: does the wrapper re-read the wrapper.config on a restart?</p>
-13:31 <@jrandom> cervantes: no :(</p>
-13:31 <@jrandom> i wish it did</p>
-13:31 < ant> <cervantes> guess we need a wrapper service wrapper</p>
-13:32 <@jrandom> perhaps someone could get a patch in to the java service wrapper folks</p>
-13:32 <@jrandom> heh</p>
-13:32 <@jrandom> ok, jumping to 3) 0.5</p>
-13:32 <@jrandom> well, i dont really have much to say about this beyond whats in the email</p>
-13:33 <@jrandom> lots of progress, many sheets of paper, and some code.  nothing committed or ready for show yet though</p>
-13:33 <@jrandom> thats 'bout all i have to say on that front, unless someone has any questions</p>
-13:34 <@jrandom> if not, we can mosey on over to 4) jabber @ chat.i2p</p>
-13:35 <@jrandom> new jabber server (w00t!).  see the email & the forum for details</p>
-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</p>
-13:35 < frosk> i think it's the third i2p has had. i hope this one sticks around :)</p>
-13:36 < jdot> docs are coming.  its easy a heck w/ Jive Messenger.  Just tunnel the ports properly.</p>
-13:36 <@jrandom> personally, i'm fine with irc for one on one and group chat, but having the option for jabber is cool</p>
-13:36 <@jrandom> ah word jdot</p>
-13:36 <@jrandom> no rush, whenever is great</p>
-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 :)</p>
-13:37 < jdot> also will be looking to changate it with the irc channels .. in the future</p>
-13:37 <@jrandom> nice</p>
-13:38 <@jrandom> ok, thats all i have to say on that.  you have anything you want to add jdot?</p>
-13:39 <+protokol> how does one get on chat.i2p</p>
-13:39 <+protokol> tis not resolve for me</p>
-13:39 <@jrandom> http://forum.i2p.net/viewtopic.php?t=229</p>
-13:40 < jdot> nothing to add.  </p>
-13:40  * eco has peeked at java service wrapper in the mean time</p>
-13:40 < eco> re-reading the config file has been implemented for the upcoming 3.20 release</p>
-13:40 < eco> see http://sourceforge.net/tracker/index.php?func=detail&aid=981060&group_id=39428&atid=425190</p>
-13:41 <@jrandom> ah wikked</p>
-13:41  * eco doesn't know when that's due though</p>
-13:41 <@jrandom> perhaps with 0.5 we'll do a big external-app-upgrade, replacing our aging jetty and java service wrapper code</p>
-13:42 <@jrandom> oh, before i go on, i suppose we should officially move to 5) ???</p>
-13:42 <@jrandom> protokol: i think i remember you saying you got jetty working with CGI?  any docs / info on that?</p>
-13:43 <@jrandom> someone else out there was able to get jetty to do symlinks too, though i dont know who</p>
-13:43 <@jrandom> (you out there, whoever you are?  how'd you do it?  :)</p>
-13:44 <@jrandom> or, i suppose, anyone else have anything they want to bring up?</p>
-13:45  * eco has a public service announcement</p>
-13:45 < eco> there's a bounty for succesfully pulling i2p through gcj</p>
-13:45 < eco> according to jr this will be dead simple, so go get it! :-)</p>
-13:45 <@jrandom> heh, not dead simple, that was just wishful thinking ;)</p>
-13:46 <@jrandom> but it might be</p>
-13:46 <@jrandom> (so go get it :)</p>
-13:46 < cervantes> think I posted links concering jetty symlinks somewhere either in chat or on the forum...can't remember which</p>
-13:46 < cervantes> was a while back now</p>
-13:46 <+protokol> jrandom: it was for the more recent version, i just crashed my jetty</p>
-13:46 < slart> any news on the azureus plugin?</p>
-13:46 <+protokol> i think jetty should be borught up-to-date so the docs on their website are useful</p>
-13:46 < Hybrid> gcj?</p>
-13:46 <+protokol> makes java into a binary</p>
-13:46 <@jrandom> ah cool cervantes, i'll dig around for it</p>
-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</p>
-13:47 <@jrandom> protokol: ah</p>
-13:47 <+protokol> and it needs cgi and symling support as well</p>
-13:47 <@jrandom> slart: the azureus devs are hacking away and making progress, but its not ready yet</p>
-13:47 <+protokol> cervantes: DO IT!</p>
-13:48 <+protokol> it would be like apache built into i2p</p>
-13:48 < frosk> Hybrid: The GNU Compiler for Java, or sumthing</p>
-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</p>
-13:48 < slaw> excellent</p>
-13:48 < frosk> mod_i2p :)</p>
-13:49 <@jrandom> heh</p>
-13:50 <@jrandom> ok, anyone else have anything they want to bring up for the meeting?</p>
-13:51 <@jrandom> if not...</p>
-13:51  * jrandom winds up</p>
-13:51  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/123.rst b/i2p2www/meetings/123.rst
new file mode 100644
index 00000000..837a137b
--- /dev/null
+++ b/i2p2www/meetings/123.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 4, 2005
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/124.log b/i2p2www/meetings/124.log
index a0781999..e54caf72 100644
--- a/i2p2www/meetings/124.log
+++ b/i2p2www/meetings/124.log
@@ -1,384 +1,378 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 124{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 11, 2005</h3>
-<div class="irclog">
-13:10 < jrandom> 0) hi</p>
-13:10 < deer> <Ragnarok> you're fired</p>
-13:10 < jrandom> 1) Net status</p>
-13:10 < jrandom> 2) 0.5 progress</p>
-13:10 < jrandom> 3) 0.6 status</p>
-13:10 < deer> <polecat> bye!</p>
-13:10 < jrandom> 4) azneti2p</p>
-13:10 < jrandom> 5) fbsd</p>
-13:10 < jrandom> 6) hosts.txt as WoT</p>
-13:11 < jrandom> 7) ???</p>
-13:11 < jrandom> 0) hi</p>
-13:11  * jrandom waves</p>
-13:11 < fdr> yo</p>
-13:11 < deer> <Ragnarok> hola</p>
-13:11 < toad_> you just starting? /me will just watch from time to time</p>
-13:11 < deer> <detonate> hi</p>
-13:11 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000551.html</p>
-13:11 < jrandom> cool, all are welcome</p>
-13:11 < deer> <polecat> Oh.  Not your employment.  My bad.  =3</p>
-13:11 < jrandom> the logs of the dev meetings are posted up @ the website (after the meeting, of course)</p>
-13:11 < fdr> I'm starving, so I'll be in and out..</p>
-13:12 < jrandom> ok, swinging on int to 1) Net status</p>
-13:12 < jrandom> things seem to be working fine.  duck is back (yay!)</p>
-13:12 < jrandom> I dont really have much to add beyond whats in the email - anyone else have anything?</p>
-13:13 < deer> <jrandom> nope</p>
-13:13 < jrandom> ok, if not, moving on to 2) 0.5 status</p>
-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</p>
-13:14 < toad_> talking to yourself?</p>
-13:14 < jrandom> heh yeah, until anyone replies ;)</p>
-13:14 < jrandom> (you should have seen these meetings before I posted the weekly status notes beforehand)</p>
-13:14 < toad_> I meant across networks. I talk to myself all the time, but not usually across networks. ;)</p>
-13:15 < deer> <jrandom_> across three networks even [iip here]</p>
-13:15 < deer> <Ragnarok> stop that, it's creepy :)</p>
-13:15 < deer> * postman waves</p>
-13:16 < jrandom> I dont really have anything else to add wrt 0.5, beyond "more info coming soon"</p>
-13:16 < deer> <polecat> Re net performance, my i2p router went down 24h ago, but before that I managed 8 days of uptime.</p>
-13:16 < jrandom> ah ok cool</p>
-13:16 < jrandom> OOMed?  were you running bt or just from activity?</p>
-13:17 < deer> <polecat> Just a heuristic to brag about.  =3</p>
-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 :)</p>
-13:17 < deer> <frosk> 8-9 days, that is</p>
-13:18  * jrandom wishes my kaffe box could do that (oh well)</p>
-13:18 < deer> * orion can crash a router at will by running 40+ local destinations via btlaunchmanycurses.py. ;)</p>
-13:18 < jrandom> heh yes, that would do it orion</p>
-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.</p>
-13:18 < deer> <orion> but, I've had uptime of 15 days before BT storms.</p>
-13:18 < jrandom> oh interesting polecat.  </p>
-13:19 < jrandom> polecat: if you're feeling brave, it might be worth trying the latest java service wrapper</p>
-13:19 < jrandom> (if it gets rid of that we should upgrade)</p>
-13:19 < deer> * laberhorst had uptime 15days with 0.4.2.5 without bt</p>
-13:19 < jrandom> i think cervantes is still the winner w/ 0.4.1.1 @ 41 days</p>
-13:20 < deer> <polecat> Anyone want to PM me on how to get the latest java service wrapper?</p>
-13:20 < jrandom> but anyway, anyone have any comments on 0.5 stuff?</p>
-13:20 < protok0l> is i2p done yet?</p>
-13:20 < jrandom> http://wrapper.tanukisoftware.org/doc/english/</p>
-13:20 < deer> <eco> looking forward to the docs</p>
-13:20 < jrandom> !thwap protok0l </p>
-13:21 < jrandom> ok, moving on to 3) 0.6 status</p>
-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.</p>
-13:21 < deer> <Ragnarok> where are the documents going up?</p>
-13:21 < jrandom> polecat: I'd love it, but I doubt it can be done.  </p>
-13:22 < jrandom> Ragnarok: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel.html?rev=HEAD is the current draft</p>
-13:22 < jrandom> (not updated wrt the first hop issue)</p>
-13:22 < deer> <Ragnarok> thanks</p>
-13:22 < deer> <polecat> "They said it couldn't be done.... they called me mad... but they were fools, FOOLS!</p>
-13:22 < jrandom> heh</p>
-13:22 < jrandom> hey, if you can find a way, I'm all ears</p>
-13:23 < jrandom> (and I have a feeling the mixmaster/mixminion folks will be too)</p>
-13:23 < deer> <jrandom> zounds, 42 usres here</p>
-13:23 < deer> <jrandom> mule: you 'round?</p>
-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.</p>
-13:24  * jrandom flings a small furry animal at polecat</p>
-13:25 -!- dm [mihi@dsl-80-42-80-26.access.uk.tiscali.com] has joined #i2p</p>
-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</p>
-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)</p>
-13:26 < jrandom> (but i'm sure they'll improve in time, of course)</p>
-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</p>
-13:27 < jrandom> (yay zab)</p>
-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 ;)</p>
-13:28 < jrandom> not much else to say on that, unless anyone has anything to bring up?</p>
-13:28 < deer> <polecat> Isn't 0.6 supposed to have preliminary fusenet support?</p>
-13:28 < deer> <frosk> by april, hopefully :)</p>
-13:29 < toad_> fusenet?</p>
-13:29 < deer> <frosk> but with all this work on the udp transport, maybe it'll be ready before fusenet will</p>
-13:29 < jrandom> yeah, the general aim is just to get the ball rolling</p>
-13:29 < deer> <frosk> fusenet is a content-distribution system more or less like usenet on speed</p>
-13:29 < toad_> cool</p>
-13:30 < deer> <frosk> it will initially support blogs, discussion forums and addressbooks for i2p name-destination mappings</p>
-13:30 < jrandom> though of course, if we get the UDP transport implemented next month, we'll probably roll that out with 0.5</p>
-13:31 < deer> <frosk> of course, that would be cool :)</p>
-13:31 < jrandom> and if i had a pony, i'd play with him aaaaalll day</p>
-13:31 < jrandom> ok, thats prolly 'bout it for 0.6 stuff, moving on to 4) azneti2p</p>
-13:31 < deer> <frosk> i'm glad you have no pony, then ;)</p>
-13:31 < jrandom> heh</p>
-13:32 < jrandom> azneti2p == kickass.  </p>
-13:32 < jrandom> parg & the rest of the azureus folks have done some great work, and the integration is really nice</p>
-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</p>
-13:33 < deer> <postman> w00t!</p>
-13:33 < jrandom> there are still further optimizations and simplifications left to do, but all in all, i'm quite impressed</p>
-13:33 < deer> <eco> hurray! enter the masses...</p>
-13:33 < deer> <frosk> i understand you still have to do some manual labour in the router console before you can use it?</p>
-13:33  * jrandom holds the gates closed for just a litttttle wile longer</p>
-13:33 < deer> <eco> is java 1.5 indeed required?</p>
-13:34 < deer> <polecat> Yup.. neat stuff except you can't leave it to daemon out.</p>
-13:34 < deer> <postman> sounds like the invitated for the i2p network to get his ass kicked badly</p>
-13:34 < jrandom> frosk: right - but we're working on patching it up to do the I2PTunnel calls within the plugin itself</p>
-13:34 < deer> <frosk> cool</p>
-13:34 < jrandom> eco: unsure, I only tried it with 1.5, but I believe them when they say it.  </p>
-13:34 < deer> <polecat> eco: I should hope not.  o.O  1.5 is just Sun trying to strongarm the market.</p>
-13:34 < jrandom> worth trying though, i'll do so later</p>
-13:35 < deer> * postman does not care, i got gigabit ethernet interfaces and LOTS of traffic included :)</p>
-13:35 < deer> <polecat> Oh dear... and azareus requires it.  I _really_ have to make my C++ torrent app.</p>
-13:35 < jrandom> polecat: azureus does have a headless mode of operation, and a web console</p>
-13:36 < deer> * polecat blinks.</p>
-13:36 < jrandom> (but its... tough to the uninitiated [like myself])</p>
-13:36 < deer> <polecat> Well okay then... I thought it didn't, like KazAa</p>
-13:36 < jrandom> but i only glanced at it (and ran back to the GUI ;)</p>
-13:36 < deer> <Ragnarok> is duck going to be bringing i2p-bt up to 3.9/4.0?</p>
-13:37 < jrandom> ragnarok: unknown, but duck is currently doing leaps and bounds to keep all the existing stuff compatible with azneti2p</p>
-13:37 < jrandom> (they had to do some... odd changes due to technical requirements)</p>
-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.</p>
-13:38  * jrandom isnt arguing with that point</p>
-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</p>
-13:39 < jrandom> anyone else have anything to bring up wrt azneti2p?</p>
-13:39 < cervantes> are you ready for it... ;-)</p>
-13:40 < jrandom> heh, we're workin' on it</p>
-13:40 < deer> <polecat> Might I note that the source of azareus is totally abysmal...</p>
-13:40 < deer> <polecat> There are 28 main entry points, and it uses at least a namespace depth of 3.</p>
-13:40 < deer> <Ragnarok> does any bt client have nice source?</p>
-13:40 < jrandom> there are some oddities, but i suspect you'll find that in anyone else's source (NIH)</p>
-13:40 < deer> <polecat> Mine will.</p>
-13:40 < jrandom> oh c'mon, net.i2p.router.netdb.kademlia.* :)</p>
-13:41 < deer> <Ragnarok> not if it's in C++ it won't :)</p>
-13:41 < toad_> lol</p>
-13:41 < deer> <polecat> I said at least!</p>
-13:42 < jrandom> ok, anyway, moving us along to 5) fbsd</p>
-13:42 < deer> <polecat> Ragnarok: You've never seen how I *cough*rape*cough* use C++.  n.n</p>
-13:42  * duck looks in</p>
-13:42 < deer> <polecat> Who cares about FreeBSD?  Show of hands?</p>
-13:42 < jrandom> lioux has packaged up the 0.4.2.6 release into ports (w00t!)</p>
-13:42 < deer> * detonate raises his</p>
-13:42 < deer> <polecat> Paws, tentacles, wings, etc?</p>
-13:43  * jrandom raises my hand</p>
-13:43  * [dave] raises</p>
-13:43 < deer> <Ragnarok> duck: 3.9/4.0? :)</p>
-13:43 < deer> <polecat> Woah, i2p is integrated into a distribution?</p>
-13:43 < duck> Ragnarok: the lack of comments / docs / etc on the latest bram-Bittorrent changes were a bit of a setback</p>
-13:43 < fdr> FreeBSD is cool :(</p>
-13:43 < deer> <Ragnarok> I'll bet</p>
-13:43 < fdr> I may be biased though.</p>
-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)</p>
-13:44 < duck> It would require studying what they did, maybe it would be worth the effort</p>
-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... ;)</p>
-13:44 < jrandom> polecat: and very, very w0nky JVMs</p>
-13:45 < duck> though secretly I have been hoping on azneti2p solving all problems</p>
-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... :)</p>
-13:45 < deer> <polecat> Ugh... don't remind me.</p>
-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</p>
-13:46 < jrandom> anyway, so it seems he's tested i2p 0.4.2.6 on fbsd5.3 without problems (w00t)</p>
-13:46 < deer> <Ragnarok> oy, I don't like azureus, I'd much rather use the normal client</p>
-13:46  * jrandom has only done so on 4.8</p>
-13:46 < duck> currently I'd like to do something with kenosis; being a hit-n-run coder</p>
-13:47 < deer> <eco> jrandom: what jvm did he use?</p>
-13:47 < jrandom> kenos2p</p>
-13:47 < jrandom> eco: native compiled sun 1.4</p>
-13:47 < jrandom> (booo hiss)</p>
-13:47 < deer> <eco> ah, illegal!</p>
-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</p>
-13:47 < jrandom> ((but kaffe works))</p>
-13:48 < jrandom> eco: is it illegal?  I thought you could agree to the terms and get the source legit on fbsd</p>
-13:48 < deer> <eco> sun withdrew the license afaik</p>
-13:48 < jrandom> hmm, i think thats just the blackdown license</p>
-13:48 < jrandom> (and, tbh, blackdown sucks)</p>
-13:49 < jrandom> individuals can still license it under SCSL</p>
-13:49 < deer> <polecat> ouch.</p>
-13:49 < jrandom> (first born child, etc)</p>
-13:49 < jrandom> heh, its interesting to hear such license gripes when so few have copyright gripes ;)</p>
-13:50 < jrandom> but this discussion is best for the 7) ??</p>
-13:50 < jrandom> and we're on 5) fbsd</p>
-13:50 < deer> <eco> license stuff on http://www.freebsdfoundation.org/press/20041221-newsletter.shtml , but back to the main thread...</p>
-13:50 < cervantes> first time we've crept above 5) in a long time</p>
-13:51 < jrandom> cervantes: and we had to trim things ;)</p>
-13:51 < jrandom> ok, i think thats it for fbsd stuff (beyond yay!)</p>
-13:51 < jrandom> so jumping into a messy one... 6) hosts.txt as a WoT</p>
-13:51 < deer> <polecat> licensing can get you at the node though, whereas copyright vio can only be tracked to the destination.</p>
-13:51 < deer> <polecat> Which "can't" be found.</p>
-13:52 < jrandom> right right polecat, but once They have physical control of your box, you're in deep shit anyway</p>
-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</p>
-13:53 < jrandom> anyone have any questions/comments/concerns?</p>
-13:53 < jrandom> (was I vague enough?  :)</p>
-13:53 < duck> yes</p>
-13:53 < deer> * eco considers handing hosts.txt management over to the UN</p>
-13:54 < jrandom> heh yeah, because we know nice centralized beurocratic authorities always Do The Right Thing</p>
-13:54 < toad_> lol</p>
-13:55 < jrandom> i suppose the real "big win" will be when the addressbook gets both a web interface and more metadata</p>
-13:55 < jrandom> (and perhaps the fusenet syndication, etc)</p>
-13:55 < deer> <Ragnarok> metadata will be the next thing I work on, using xml name records</p>
-13:56 < jrandom> kickass ragnarok!</p>
-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?</p>
-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</p>
-13:58 < deer> <Ragnarok> so, the WoT is a feature :)</p>
-13:58 < jrandom> Wo0T</p>
-13:58 < lucky> whoa</p>
-13:58 < deer> <eco> but surely you sell premium accounts?</p>
-13:58 < lucky> is that a toad i see?</p>
-13:58 < lucky> a real toad?</p>
-13:58 < lucky> or just a frog.</p>
-13:58 < deer> <frosk> the important point imho, is how to handle collisions</p>
-13:59 < toad_> a toad</p>
-13:59 < deer> <detonate> first come, first serve</p>
-13:59 < jrandom> right frosk, it'd be nice to have an interface to manage those, rather than just "read the log"</p>
-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.</p>
-13:59 < toad_> call my name if it gets close to my area :)</p>
-13:59 < deer> <frosk> Ragnarok: my thinking too</p>
-13:59 < deer> <Ragnarok> anything else can be attacked</p>
-13:59 < lucky> oh, not the freenet toad.</p>
-13:59 < lucky> oh</p>
-13:59 < lucky> it is.</p>
-13:59 < deer> <eco> so the names are simply like aliases in IM?</p>
-14:00 < deer> <frosk> collisions need to be stored so you can switch long after the fact</p>
-14:00 < deer> <Ragnarok> and is probably not provably better in the general case</p>
-14:00 < lucky> we're paying toad now?</p>
-14:00 < jrandom> eco: right - the names are just private local nicknames</p>
-14:00 < deer> <susi23> the addressbook should recognize collisions and notify the user so he can decide</p>
-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</p>
-14:01 < deer> <susi23> until the user made his decision any changes regarding the collision should somehow get "quarantined" :)</p>
-14:01 < deer> <Ragnarok> susi23: that's essentially how it works now</p>
-14:01 < deer> <Ragnarok> it just has a lousy interface</p>
-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?)</p>
-14:02 < deer> <susi23> fine then</p>
-14:02 < deer> <Ragnarok> nope.  I don't do web interfaces :)</p>
-14:02 < deer> <Ragnarok> susi was working on something, I think, but I'm not sure what's happened with that</p>
-14:02 < jrandom> (volunteers?  any chance of reviving susidns to manage the names?)</p>
-14:03 < deer> <susi23> ok, give me a week, I put it on TODO</p>
-14:03 < jrandom> (and after susidns, we need susitorrent and susiirc...)</p>
-14:03 < jrandom> wikked!</p>
-14:04 < jrandom> ok, anyone have anything else to bring up wrt that whole hosts.txt thing?</p>
-14:05 < jrandom> if not, moving on to 7) ???</p>
-14:05 < deer> <Ragnarok> one thing</p>
-14:05 < jrandom> you've got the mic</p>
-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?</p>
-14:06 < jrandom> sounds reasonable.  i'll stop shipping hosts.txt in the i2pupdate.zip (but will include it in i2pinstall.jar)</p>
-14:06 < deer> <Ragnarok> cool.  That's all :).</p>
-14:07 < jrandom> ok, now back to the opne floor</p>
-14:07 < jrandom> anyone else have anything they want to bring up?</p>
-14:07 < deer> <postman> yes</p>
-14:07 < jrandom> hit it postman</p>
-14:07 < deer> * postman raises his hand</p>
-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 )</p>
-14:09 < deer> <postman> if anyone got a stable, fast (dedicated) machine, i would be very happy to accept  help</p>
-14:09 < deer> <postman> configuration / howto will be delivered by me</p>
-14:09 < deer> <eco> how fast is fast?</p>
-14:10 < deer> <postman> eco: static IP wuld be nice - everything else is negotiable</p>
-14:10 < jrandom> how much traffic are you seeing through mail.i2p postman?</p>
-14:10 < jrandom> (external, that is)</p>
-14:10 < deer> <polecat> Stable, fast, dedicated... well 1/3 isn't bad.</p>
-14:10 < deer> <postman> the mailtraffic is VERY low</p>
-14:10 < deer> <postman> in/out is about 500 mails / month</p>
-14:11 < jrandom> ah cool</p>
-14:11 < deer> <Frooze> i have slow (500 MHz), stable, dedicated</p>
-14:11 < deer> <postman> BUT since the inproxy will have a I2P running</p>
-14:11 < jrandom> (that'll probably pick up as more people find out about it though ;)</p>
-14:11 < deer> <eco> the machine would be for incoming mail only?</p>
-14:11 < deer> <postman> most traffic would be I2p i guess</p>
-14:12 < deer> <postman> eco: at least incoming ( it's needed for this ) </p>
-14:12 < deer> <postman> if the operator is ok with that i would like to rotate outgoing over both machines</p>
-14:12 < deer> <postman> Frooze: it's ok, when it's able to run i2p</p>
-14:13 < deer> <postman> just drop me a mail</p>
-14:13  * toad_ wonders if his current issues are AOB business or if they are simply between him and jrandom</p>
-14:13 < deer> <postman> if anyone is interested</p>
-14:14 < deer> * postman hands back the mike</p>
-14:14 < deer> <Frooze> will do.</p>
-14:14 < deer> <postman> thanks jr :)</p>
-14:14 < jrandom> cool, thanks postman</p>
-14:14 < jrandom> toad_: i think there's much to be discussed, though largely a question for the freenet folks</p>
-14:15 < toad_> jrandom: right</p>
-14:15 < toad_> jrandom: talk after meet</p>
-14:15 < jrandom> sounds good</p>
-14:15 < duck> no public mudfight? :/</p>
-14:15 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-14:15 < jrandom> heh duck</p>
-14:15 < deer> * eco points at http://dodo.freenetproject.org/pipermail/tech/2005-January/001224.html</p>
-14:15 < jrandom> (that was on tehc ;)</p>
-14:15 < cervantes> postman: my box has too much shit running on it to be any help I'm afraid ;-)</p>
-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?</p>
-14:15 < deer> <Ragnarok> what does accurate mean?</p>
-14:16 < jrandom> polecat: signing entries would Kick Fucking Ass.</p>
-14:16 < deer> <eco> fyi</p>
-14:16 < deer> <eco> no mud involved.</p>
-14:16 < deer> <Ragnarok> (and signing is planned for name records)</p>
-14:16 < deer> <postman> cervantes: hi, thanks anyway :)</p>
-14:16 < cervantes> you are indeed very welcome</p>
-14:16 < cervantes> :P</p>
-14:17 < jrandom> ok, anything else?</p>
-14:17 < deer> <polecat> Ragnarok: accurate means centered around the correct result.</p>
-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</p>
-14:18 < deer> <Ragnarok> polecat: yes, but what's the correct result?</p>
-14:18 < jrandom> lol cervantes </p>
-14:18 < cervantes> %s/polecat/postman</p>
-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.</p>
-14:19  * duck wonders if updating dot.png is useful?</p>
-14:19 < duck> it got kind of full</p>
-14:19 < deer> <eco> give us a 3d applet</p>
-14:20 < jrandom> duck: its a bit hard to read yeah ;)</p>
-14:20 < jrandom> duck: perhaps only list the blue lines?</p>
-14:20 < jrandom> to me, the value comes from seeing how spread out green is</p>
-14:20 < jrandom> (or whether there are clusters of dark green, etc)</p>
-14:20 < deer> <Ragnarok> polecat: signing will be supported in the xml name record format.</p>
-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.</p>
-14:21 < deer> <polecat> Right.  So... great.  No problem then.</p>
-14:21 < deer> <Ragnarok> polecat: that's what we've got now</p>
-14:22 < deer> <polecat> If the signature of an update matches the original record's public key then you can update automatically, no problem.</p>
-14:24 < jrandom> ok, there's still room left to be hashed out on the Great Naming Debate, of course</p>
-14:24 < jrandom> anyone have anything else for the meeting?</p>
-14:24 < deer> * eco has a UI poll</p>
-14:24  * jrandom has a GUI</p>
-14:25 < deer> <Ragnarok> polecat: that will be supported once we've got signing :)</p>
-14:25 < deer> <eco> the i2ptunnel option in the web ui results in a popup - am i the only one less enthusiastic about that?</p>
-14:25 < jrandom> definitely not the only one eco.  </p>
-14:25 < jrandom> i wrote the i2ptunnel web interface approximately as poorly as i could</p>
-14:25 < jrandom> it really, really sucks</p>
-14:25  * cervantes steals jrandom's "patches welcome" line</p>
-14:26 < jrandom> (what cervantes said :)</p>
-14:26 < jrandom> or even just plain HTML, i can integrate it with the jsp</p>
-14:26 < jrandom> (but of course patches to the jsp would be nice)</p>
-14:27 < cervantes> jrandom: btw I have a patch for what we discussed yesterday...just going to test it a little more first....</p>
-14:27 < jrandom> ah wikked cervantes, thanks!</p>
-14:27 < deer> <eco> why not list that in the main page, like the other pages?</p>
-14:27 < deer> <eco> ok, so no big religious or technical reason behind it?</p>
-14:28 < deer> * polecat has a FUI</p>
-14:28 < jrandom> eco: from a UI perspective, it can be made to look like the other pages, but not technically</p>
-14:28 < jrandom> technically, it needs to stay seperate as a client app deployed as a seperate .war file</p>
-14:28 < deer> <polecat> Ragnarok: I thought you said that's what we've got now?</p>
-14:29  * jrandom appreciates very much mihi's contribution of that code, but I can't let the i2p console depend upon GPL</p>
-14:29 < deer> <Ragnarok> er, sorry, I meant everything but the signing, which obviously we don't do right now.</p>
-14:29 < jrandom> (but we can make it look like the other pages</p>
-14:30 < deer> <eco> ah, license issues. great</p>
-14:30 < jrandom> heh isn't it grand eco?</p>
-14:30 < deer> <Ragnarok> so currently addresses are never updated automatically, changing the destination an address points to always requires user intervention</p>
-14:30 < cervantes> jrandom: iframe :P</p>
-14:30  * jrandom wishes people just saw the IP farse for what it was and released into the public domain</p>
-14:30 < deer> <eco> but in this case a socket connection for example should be okay GPL-wise i'd guess</p>
-14:30 < jrandom> cervantes: not an impossible alternative</p>
-14:30 < jrandom> right eco</p>
-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</p>
-14:33 < deer> <susi23> any wishes, feature requests, and comments regarding the addressbook interface please add to http://susi.i2p/susidns.html</p>
-14:33  * toad_ respects jrandom's extremist licensing views while disagreeing vehemently with them :)</p>
-14:33 < jrandom> oh cool, shall do susi23</p>
-14:34 < jrandom> heh toad_ :)</p>
-14:34 < deer> * eco puts it on his when-i'm-64-to-do-list</p>
-14:34 < toad_> bbiab</p>
-14:34 < jrandom> l8r</p>
-14:34 < toad_> when i get back we need to talk about various technical issues with i2p/freenet integration</p>
-14:34 < jrandom> ok, anyone else have anything for the meeting?</p>
-14:34  * cervantes wheels out the metal gong</p>
-14:34 < toad_> will try to get back quickly</p>
-14:34 < jrandom> cool toad_, i'll be around</p>
-14:34 < jrandom> (it'll give me time to catch up on those threads ;)</p>
-14:35  * jrandom winds up</p>
-14:35  * jrandom *baf*s the gong, closing the meeting</p>
-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,</p>
-14:35 < dm> i2p/freenet integration!?</p>
-14:35  * jrandom de-gongs</p>
-14:35  * cervantes puts the gong away</p>
-14:35 < jrandom> #1: yes, absolutely - I've sent parg a patch to do that</p>
-14:36 < jrandom> #2: [got trimmed @ 'want it or not,']</p>
-14:38  * jrandom watches the irc streaming lib logs -</p>
-14:38 < jrandom> 14:37:55.701: SEND bRC43g==QRnB~Q==: #2          DELAY 1000 MS ACK 1 data: 29 sent 2 times</p>
-14:38 < jrandom> 14:38:20.072: SEND juVFdg==aAUIVw==: #3465       DELAY 1000 MS ACK 5723 data: 43 sent 2 times</p>
-14:40 < deer> * eco grabs a beer</p>
-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?</p>
-14:40 < jrandom> it would not be good to have a large burst of users prior to the UDP transport</p>
-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</p>
-14:41 < deer> <DrWoo> jrandom: cool to see your all over #1 ;)</p>
-14:42 < jrandom> we also will need some docs for #1 too, explaining why 0 hops works for some threat models :)</p>
-14:44 < jrandom> ok, we ready for a re-gong?</p>
-14:45  * jrandom winds up</p>
-14:45  * jrandom *baf*s the meeting closed^2</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/124.rst b/i2p2www/meetings/124.rst
new file mode 100644
index 00000000..c19fe780
--- /dev/null
+++ b/i2p2www/meetings/124.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 11, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/125.log b/i2p2www/meetings/125.log
index e6c7e57e..82dd0477 100644
--- a/i2p2www/meetings/125.log
+++ b/i2p2www/meetings/125.log
@@ -1,284 +1,278 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 125{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 18, 2005</h3>
-<div class="irclog">
-13:04 < jrandom> 0) hi</p>
-13:04 < jrandom> 1) Net status</p>
-13:04 < jrandom> 2) 0.5</p>
-13:04 < jrandom> 3) i2pmail.v2</p>
-13:04 < jrandom> 4) azneti2p_0.2</p>
-13:04 < jrandom> 5) ???</p>
-13:04 < ant> <duck> (the sound of the crypto talk flying past my ears)</p>
-13:04 < jrandom> :)</p>
-13:04  * jrandom waves</p>
-13:04 < cervantes> 'lo</p>
-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</p>
-13:05 < bla> hi</p>
-13:05 < jrandom> jumping on in, since we're cutting into an interesting discussion anyway... 1) net status</p>
-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?</p>
-13:06 < bla> Other that we have, for the first time, seen nodes on *all* continents except Antarctica, no.</p>
-13:06 < jrandom> w00t!</p>
-13:07 < jrandom> ok, moving on to 2) 0.5 stuff</p>
-13:07 < mule> hey, my father is just on his way to antarctica, should have given him a node</p>
-13:07 < ant> <duck> bloody Antarticans</p>
-13:07 < Xan> no antarcticans? :(</p>
-13:07 < jrandom> hah nice</p>
-13:07 < jrandom> though i dont think there's much of an anonymity set up there </p>
-13:07 < Frooze> blame antarctica</p>
-13:08  * cervantes sets up an oil rig in antartica so he can finance a node there</p>
-13:09 < jrandom> ok ok, there's a lot of 0.5 stuff, so we can take it in pieces</p>
-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/</p>
-13:09 < postman> it was a pleasure :)</p>
-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</p>
-13:10 <+protokol> jrandom: LIAR! you said the data was interesting!</p>
-13:10  * jrandom flings mud at protokol </p>
-13:11 < ant> <duck> cervantes: I have also seen reports of ppl able to get it up and running within a couple of minutes</p>
-13:11 < ant> <duck> I think that NAT is causing most problems</p>
-13:11 < cervantes> duck: true...</p>
-13:11 < ant> <dmdm> who is NAT?</p>
-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</p>
-13:12 < cervantes> aye</p>
-13:12 < cervantes> *cough* so... 0.5</p>
-13:13 < Xan> dmdm: network address translation</p>
-13:13 < jrandom> heh, ok.  basically the drive with those message size stats is to explore the padding issues </p>
-13:14 < jrandom> unfortunately, the strategy i built by cherry picking numbers sucked, giving a 25% overhead just with padding data</p>
-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</p>
-13:15 < jrandom> (since it'll force small fixes sizes with fragmentation)</p>
-13:15 < mule> what type of messages do you want to pad, those a router sees or those an external observer sees?</p>
-13:15 < jrandom> mule: important question</p>
-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</p>
-13:16 < Teal`c> http://microsoft.i2p/david_hasselhoff_05_christmas_album__silent_night.mp3</p>
-13:16 < jrandom> otoh, if we're worried about tunnel participants doing flow analysis, we need to worry about padding down the tunnel</p>
-13:16 <@duck> with 5-6 hops, how big is the danger of a router doing traffic analysis?</p>
-13:16 < cervantes> Teal`c: meeting atm... can you use #i2p-chat for mp3 announce ;-)</p>
-13:17 < Teal`c> sorry</p>
-13:17 < cervantes> :) for david hasselhoff?</p>
-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</p>
-13:18 < jrandom> even more than the tunnel padding though is end to end padding, hiding message flow data from gateways and endpoints.</p>
-13:19 < jrandom> if we're crazy/stupid, we could go all the way to a pipenet, using constant bitrate everywhere</p>
-13:19 <+polecat> I got it!</p>
-13:19 < jrandom> (and end up with no users running i2p)</p>
-13:19 <+polecat> What we need to do is tunnel i2p over email!</p>
-13:19 < cervantes> what's the likelyhood of colluding routers ending up in the same tunnel on a sufficiently large network?</p>
-13:19 <+polecat> No ISP would be dumb enough to stop email!</p>
-13:20  * jrandom awaits the net.i2p.router.transport.gmail implementation</p>
-13:20 < postman> polecat: gee , this is silly </p>
-13:20 < postman> :)</p>
-13:20 < bla> cervantes: N^(-h) (N is # of fast nodes, h = # hops). It seems</p>
-13:20 <+polecat> =3   I know.</p>
-13:21 < cervantes> is that a lot? :)</p>
-13:21 < jrandom> not the # of fast nodes, as external people won't know your profiles</p>
-13:21 <+polecat> Seriously though, in shameless abuse of existing IP services, we could tunnel i2p in any number of ingenious ways.</p>
-13:21 < jrandom> c^2/N^h to get two peers into the same tunnel</p>
-13:21 < jrandom> agreed polecat.  thats one of the reasons why we don't have bidirectional tunnels</p>
-13:22 < jrandom> some transports (e.g. email) suck for bidirectional comm</p>
-13:22 < bla> jrandom: c = ?</p>
-13:22 < jrandom> c==# colluding peers</p>
-13:23 <+polecat> Hm, interesting point.</p>
-13:23 < ant> <duck> roadmap wise, what is the impact of i2p going a wrong direction and picking a wrong crypto solution?</p>
-13:23 <+polecat> Or carrier pigeon protocol, not bidi in the slightest.</p>
-13:23 <+polecat> crypto is modular already, isn't it?</p>
-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</p>
-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</p>
-13:24 < jrandom> otoh, the difference between "fixed 1KB blocks" and "0-40KB blocks" has substantial impact</p>
-13:24 <+polecat> I'd hate to see this network go the way of Entropy, stuck in McEliece.</p>
-13:24 < jrandom> polecat: read http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/tunnel-alt.html?rev=HEAD</p>
-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</p>
-13:25 < jrandom> the plan is standard AES256/CBC</p>
-13:25 <+protokol> i hear dns is good for tunneling stuff, most people dont block it</p>
-13:25 < jrandom> certainly bla, though its not quite that direct (for exploratory tunnels it is, but not for client tunnels)</p>
-13:26 <+polecat> And if somehow even AES gets cracked, some equivalent symmetric cipher.</p>
-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</p>
-13:28 < jrandom> (because of the way we do the rest of the tunnel routing)</p>
-13:28 < bla> jrandom: k</p>
-13:28 < jrandom> right polecat </p>
-13:29 < jrandom> duck: if we go w/ the second option, changing to another later will likely be easy.  </p>
-13:29 < jrandom> otoh, the second option will require some hefty performance tuning to Not Suck</p>
-13:29 < jrandom> but i'm sure we can pull it off</p>
-13:31 < jrandom> anyway, I think the above covers where we are right now wrt 0.5 work</p>
-13:31 < jrandom> does anyone have any more questions/comments/concerns?</p>
-13:31 < bla> jrandom: One</p>
-13:32 < bla> jrandom: I think we should values anon. slightly more than performance atm: so yes, the PRNG options sounds good</p>
-13:33 < jrandom> agreed.  performance can be tuned later, "adding in" better anonymity however, is much harder</p>
-13:33 < jrandom> (but, of course, performance /is/ a security parameter.  if it Sucks, no one uses it)</p>
-13:33 < bla> Yes.</p>
-13:33 < bla> jrandom: </p>
-13:33 < bla> sorry</p>
-13:33 <@duck> right, /me flips the magical Freenet-performance bit</p>
-13:33 < cervantes> perhaps it'll deter all those torrent waving leechers to stay away a while longer ;-)</p>
-13:34 < jrandom> heh</p>
-13:34 < cervantes> <-- connection reset</p>
-13:34 < bla> cervantes: No, I'm not! :)</p>
-13:34 < cervantes> :)</p>
-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</p>
-13:36 < jrandom> but, anyway, anything else for 2) 0.5?</p>
-13:36 < ant> <BS314159> could you post an explanation for this loop attack?</p>
-13:37 < ant> <BS314159> it sounds more dangerous than your treatment implies it is</p>
-13:37 < jrandom> loop: build a tunnel containing A-->B-->C-->D-->C, send in 10 messages.</p>
-13:37 < jrandom> without the PRNGs, you can add as many messages to that C<-->D loop as you want</p>
-13:38 < ant> <BS314159> ok</p>
-13:38 < jrandom> effectively DoSing any routers with just a few messages</p>
-13:38 < ant> <BS314159> but only A can do this</p>
-13:38 < jrandom> with the PRNGs, it limits the number of messages that can go into the loop</p>
-13:38 < ant> <BS314159> so there's no danger of an attacker shortening my tunnels by introducing loops</p>
-13:38 < jrandom> no, no one can shorten your tunnels</p>
-13:39 < jrandom> the only thing this is useful for is a DoS</p>
-13:39 < jrandom> (a very cheap DoS)</p>
-13:39 < jrandom> (but when you can selectively DoS peers without much cost, you can do naaaasty stuff)</p>
-13:40 < ant> <BS314159> comprendo</p>
-13:40 <+protokol> and hashcash certs will help this?</p>
-13:40 < jrandom> protokol: hashcash addresses the issue of a peer building too many tunnels, and perhaps building too many hops</p>
-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)</p>
-13:42 < jrandom> verifying at each step has dangers, so the current leaning is towards the PRNGs</p>
-13:42 <+Ragnarok> how effective will the prng method be?</p>
-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?</p>
-13:43 < jrandom> Xan: they do, but without verifying each step, you can't tell whether its bad or not</p>
-13:44 < jrandom> Ragnarok: i think it'll be very effective at minimizing the damage done</p>
-13:45 < jrandom> at least, from what I can see so far</p>
-13:45 < jrandom> if anyone sees any problems/issues with it, or suggestions for improvement, please get in touch :)</p>
-13:46 < Xan> or maybe Im missing the point</p>
-13:46 < Xan> bbl</p>
-13:46 < jrandom> 'k l8r, i'll update the doc to be more clear </p>
-13:47 < jrandom> ok, unless there's something else, shall we move on to 3) i2pmail.v2?</p>
-13:47 < jrandom> postman: you 'round?</p>
-13:48 < postman> yes</p>
-13:49 < postman> :)</p>
-13:49 < jrandom> anything to add from your post on the forum?  it sounds pretty cool</p>
-13:49 < postman> well, a few of you might have read the draft for i2pmail.v2 already</p>
-13:50 < bla> wtf is happening? Massive disconnects. I've got trouble reaching sites (say orion, library) here too</p>
-13:50 < postman> it aims towards a fully decentralized mail infrastructure in the future</p>
-13:50 < postman> but is in need of proxysoftware on the nodes as well as a bunch of dedicated relays</p>
-13:51 < postman> all are invited to contribute ideas / concepts / rants</p>
-13:51 < postman> development already has started - dont expect anything before late spring :)</p>
-13:51 < jrandom> w00t</p>
-13:51 < kaji> hmm, the cops just showed up at my door</p>
-13:52 < bla> kaji: ?</p>
-13:52 < jrandom> quick, blow your hard drive</p>
-13:52 < postman> jrandom: well, this is all i have to say for now :) </p>
-13:52 < cervantes> hide the blackjack table!</p>
-13:52 < jrandom> wikked, thanks postman </p>
-13:52 < kaji> they said i dialed 911, but im quite sure neither i nor my brother did</p>
-13:53 <+protokol> kaji: they're just checking up on i2p</p>
-13:53 < jrandom> ok, unless there's anytihng else on 3) i2pmail, lets move over to 4) azneti2p_0.2</p>
-13:53 <+protokol> <creepy music></p>
-13:53 < jrandom> as mentioned in the email, there's been some important progress lately</p>
-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</p>
-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</p>
-13:55 < jrandom> (if you don't read the i2p mailing list and use azneti2p, read the i2p mailing list)</p>
-13:55 < jrandom> ((or even if yuo dont use azneti2p, read the list, as thats where we announce important things ;)</p>
-13:56 < jrandom> duck and orion have also been making lots of updates to accomodate the new bt client and formatting</p>
-13:56 < jrandom> (yay!)</p>
-13:56  * orion smiles</p>
-13:57 < orion> theres still a ways to go, but for now, it works.</p>
-13:57 < jrandom> (inasmuch as i2p lets it ;)</p>
-13:58 < orion> hehe, yes. ;)</p>
-13:58 < jrandom> does anyone else have anything to bring up wrt azneti2p or i2p-bt?</p>
-13:58 < jrandom> (or bytemonsoon2p ;)</p>
-14:00 < jrandom> ok if not, moving right along to 5) ???</p>
-14:00 < jrandom> open floor - anyone else have anything to bring up? </p>
-14:00 < postman> jrandom: why does the addressbook publich userhosts entries ?</p>
-14:01 < jrandom> postman: bug.  </p>
-14:01 < postman> so this was no planned behaviour and will be changed?</p>
-14:01 < cervantes> just one thing...</p>
-14:01 < jrandom> postman: correct, and will be changed</p>
-14:02 < jrandom> (right Ragnarok?  :)</p>
-14:02 <+Ragnarok> depends on exactly what postman means...</p>
-14:03 < jrandom> Ragnarok: new entries added by the local user to their own private hosts shouldn't be propogated to the hosts published</p>
-14:03 < jrandom> (e.g. userhosts.txt is private, hosts.txt is synchronized with other people and is public)</p>
-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</p>
-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</p>
-14:03 < ant> <BS314159> hmm</p>
-14:04 < postman> Ragnarok: those have been manually added keys, which haven't been supposed to be published</p>
-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</p>
-14:04 < jrandom> w00t!</p>
-14:04 < jrandom> (go duck go, go duck go)</p>
-14:05 < Teal`c> what about domain name hijacking ?</p>
-14:05  * brachtus applauds</p>
-14:05  * orion does a duck waddle as a sign of respect.</p>
-14:05 < cervantes> one important point for the future...you don't have to be a cryptographic genius to get praise!</p>
-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</p>
-14:06 < orion> (but it helps)</p>
-14:06 < cervantes> you might just have contributed a cracking eepsite or something...</p>
-14:06 < cervantes> or been a helpful bod on the forum etc</p>
-14:07 < ant> <BS314159> hmm</p>
-14:07 < cervantes> (otherwise, lets face it, jrandom would win every week)</p>
-14:07 < jrandom> hey, y'all are paying for my beer fund, this stuff aint free ;)</p>
-14:07 < ant> <BS314159> could you just make a new file, "publichosts.txt"?</p>
-14:07 < ant> <BS314159> then have addressbook ignore userhosts.txt, but allowed users to subscribe to their own publichosts.txt?</p>
-14:08 < jrandom> Teal`c: there is no way to hijack a domain name, no entries are overwritten, and userhosts always overrides hosts</p>
-14:09 < jrandom> Ragnarok: perhaps the web interface can address the locking issue, since users won't be adding to the files manually</p>
-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</p>
-14:10 <+Ragnarok> jrandom: well, I was planning on using the java file locking api</p>
-14:10 < jrandom> if you think its necessary, you're the boss :)</p>
-14:10 < ant> <BS314159> it would allow you to kill all the names gotten from other people while keeping the ones you made yourself</p>
-14:10 < ant> <BS314159> simply by clearing hosts.txt and changing your subscriptiong</p>
-14:11 < ant> <BS314159> but I guess that can wait for name-signing</p>
-14:11 < orion> metadata will solve this problem.  Is a spec drafted yet?</p>
-14:11 < jrandom> using just two files should be fine - one managed by the addressbook, one not</p>
-14:12 < jrandom> (you could even have the addressbook ignore userhosts.txt entirely - userhosts.txt overrides hosts.txt anyway)</p>
-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 :)</p>
-14:13 <+Ragnarok> and I'm currently working on learning enough xml schema to write one for the namerecords</p>
-14:13 < ant> <dr_kavra> is this the channel for kenosis? another channel told me to come here :D</p>
-14:13 < jrandom> lol</p>
-14:13 < jrandom> nah, sorry, this is i2p</p>
-14:14 < jrandom> (unless you're looking for an anonymous comm layer)</p>
-14:14 < jrandom> wikked Ragnarok </p>
-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</p>
-14:14 < jrandom> Ragnarok: the tough part will be doing the crypto w/ XML without reverting to ugly CDATA</p>
-14:14 < orion> anybody write a working draft for the metadata spec yet?</p>
-14:15 < jrandom> (i personally think xml sucks, but i'm just a naysayer)</p>
-14:15 < jrandom> orion: http://dev.i2p.net/pipermail/i2p/2004-February/000135.html has a basic setup</p>
-14:15 < orion> (name/key metadata)</p>
-14:15 < dox> has the addressbook and its features been announced somewhere? I didn't know my hosts.txt is published</p>
-14:15 < jrandom> (see NameReference and LocalEntry elements)</p>
-14:16 < jrandom> dox: its written to the location specified in addressbook/config.txt</p>
-14:16 < jrandom> (by default, ./eepsite/docroot/hosts.txt)</p>
-14:17 < orion> is missing a public/private (i.e. distribute, don't) flag.</p>
-14:17 < ant> <cervantes> the only good thing about XML (and this is a large + point) is that it's a widely accepted standard</p>
-14:17 < jrandom> right orion, lots of good ideas have come up since that post</p>
-14:17 <+Ragnarok> xml may suck, but frankly, it better than any of the alternatives for what I'm doing</p>
-14:17 < jrandom> cervantes: so is EDI</p>
-14:17 < orion> is there a place to condense them?  i.e. forum area?</p>
-14:18 < orion> or maybe a wiki page?</p>
-14:18 < jrandom> orion: susi's or ugha's wiki</p>
-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.</p>
-14:18 < BrockSamson> xml + crypto w/o CDATA = mime, no?</p>
-14:19 < jrandom> wikked orion </p>
-14:19 < jrandom> BrockSamson: smime, with different parsers ;)</p>
-14:19 < orion> (also one for name metadata)</p>
-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</p>
-14:21  * jrandom is sure Ragnarok et al will come up with some good stuff :)</p>
-14:21 < orion> thats why I think a public draft is in order.</p>
-14:22 < ant> <cervantes> i2p consortium :P</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</p>
-14:23  * orion promises to have three wikis up within a day and email everyone their locations</p>
-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</p>
-14:23 < jrandom> w00t</p>
-14:23 < jrandom> heh BrockSamson </p>
-14:24 < BrockSamson> Position 10 is ST? oh then position 310 should be name</p>
-14:24 < BrockSamson> duh me</p>
-14:24 < jrandom> BrockSamson: don't think the xml schemas for POs are much better ;)</p>
-14:24 < jrandom> (but yeah, that stuff is just a totally bloody disaster)</p>
-14:25 < BrockSamson> they are at 4:30 in the morning</p>
-14:25 < BrockSamson> unless...</p>
-14:25 < jrandom> heh</p>
-14:25 < BrockSamson> it's written by an ex EDI programmer</p>
-14:25 < BrockSamson> and the xml looks like this: <p1><po><q>1</q></po></p1></p>
-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.</p>
-14:26 < BrockSamson> every project i've ever been part of has had massive debates on it</p>
-14:27 < orion> debates are good for a project, depending on who's debating. ;)</p>
-14:27 < jrandom> eh, it does what it does, but its not a panacea.  it may work well for the naming stuff</p>
-14:28 < BrockSamson> many people are in projects just to debate though.</p>
-14:28 < jrandom> not here.  i'm here for the free beer</p>
-14:28 < ant> <cervantes> that's debatable</p>
-14:28 < orion> the implementation details will be clearer when the draft spec is more tangable.</p>
-14:28 < orion> hence the need for a wiki/peer review.</p>
-14:29 < BrockSamson> I heard this project gave away free Garlic</p>
-14:29 < jrandom> lots of it</p>
-14:30 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-14:30 < ant> * cervantes wheels out the ceremonial call with bell</p>
-14:30 < ant> <cervantes> call =cow</p>
-14:30  * jrandom winds up</p>
-14:31  * jrandom *baf*s the cowbell, closing the meeting</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/125.rst b/i2p2www/meetings/125.rst
new file mode 100644
index 00000000..4495682c
--- /dev/null
+++ b/i2p2www/meetings/125.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 18, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/126.log b/i2p2www/meetings/126.log
index 7083eca0..aed9b818 100644
--- a/i2p2www/meetings/126.log
+++ b/i2p2www/meetings/126.log
@@ -1,178 +1,172 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 126{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 25, 2005</h3>
-<div class="irclog">
-13:50 < jrandom> 0) hi</p>
-13:50 < jrandom> 1) 0.5 status</p>
-13:50 < jrandom> 2) sam.net</p>
-13:50 < jrandom> 3) gcj progress</p>
-13:50 < jrandom> 4) udp</p>
-13:50 < jrandom> 5) ???</p>
-13:50 < jrandom> 0) hi</p>
-13:50  * jrandom waves belatedly</p>
-13:51 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-January/000560.html</p>
-13:51 <+postman> hi</p>
-13:51  * brachtus waves back</p>
-13:52  * cervantes waves a detention slip for tardiness</p>
-13:52 < jrandom> yeah yeah, blame the code for sucking me in</p>
-13:52 < jrandom> ok, jumping into 1) 0.5 status</p>
-13:53 < jrandom> lots of progress since last week - all the messy problems we had with the new crypto are resolved without much trouble</p>
-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</p>
-13:55 < jrandom> not sure if i have anything else to add beyond whats in the email</p>
-13:55 < jrandom> anyone have any questions/concerns?</p>
-13:56 < Ragnarok> what's performance going to be like?</p>
-13:56 < jrandom2p> (not me)</p>
-13:56 < jrandom> Ragnarok: tunnel performance should be much better</p>
-13:56 < frosk> any significant overhead compared to what we have today?</p>
-13:57 < jrandom> frosk: sometimes</p>
-13:57 < jrandom> frosk: when we can coallesce messages in a tunnel, the overhead will be minimal</p>
-13:58 < jrandom> however, when we cannot coallesce or when its not effective, there can be nontrivial waste</p>
-13:58 < frosk> i see</p>
-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)</p>
-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</p>
-14:01 < jrandom> ok, anytihng else on 0.5?</p>
-14:02 < jrandom> if not, moving on to 2) sam.net</p>
-14:02 < jrandom> smeghead has ported the java sam client lib to .net (yay!)</p>
-14:02 < jrandom> smeghead: wanna give us the rundown?</p>
-14:03 < smeghead> sure</p>
-14:03 < smeghead> i'm writing tests for it, should have those in cvs in the next couple of days</p>
-14:04 < smeghead> should work with .net/mono/portable.net</p>
-14:04 < smeghead> and c# and vb.net</p>
-14:05 < frosk> (and all of the other languages that works with .net i suppose)</p>
-14:05 < cervantes> (urgh)</p>
-14:05 < smeghead> the interface is dirt simple</p>
-14:05 < smeghead> just register listener methods with SamReader, or subclass SamBaseEventHandler and override methods as necessary</p>
-14:05 < smeghead> yes, i aim to make it fully CLR compatible</p>
-14:06 < jrandom> wikked</p>
-14:06 < cervantes> cool... smeg.net ;-)</p>
-14:06 < frosk> goodie</p>
-14:06 < smeghead> really not much else to it</p>
-14:06 <+protokol> CLR?</p>
-14:06 < smeghead> common language runtime</p>
-14:06 < smeghead> the .net equivalent of the JRE</p>
-14:07 <+protokol> JRE?</p>
-14:07 <+protokol> just kidding</p>
-14:07 < jrandom> !thwap protokol </p>
-14:07 < Ragnarok> jrandom: how's the sam bridge holding up these days?  were all the bt related issues resolved?</p>
-14:08 < Tracker> I doubt it, i2p-bt can even drive my amd64 3000 mad, cpu-wise...</p>
-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</p>
-14:09 < jrandom> hmm, failed connections will force full ElGamal instead of AES</p>
-14:10 < Ragnarok> ok</p>
-14:10 < jrandom> we should be able to reduce some of that after 0.5, but only partially</p>
-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.</p>
-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 :)</p>
-14:12 < ant> <Evil-Brotten> hello everbody</p>
-14:12 < smeghead> a demo app, yes i'll do that too</p>
-14:13 < smeghead> i've ported yours in fact</p>
-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</p>
-14:13 < smeghead> they're just bug-ridden atm</p>
-14:13 < ant> <Evil-Brotten> deer?</p>
-14:13 < jrandom> hi Evil-Brotten</p>
-14:13 < ant> <Evil-Brotten> hello</p>
-14:14 < jrandom> weekly dev meeting going on, feel free to stick around.  deer is a gateway to i2p/iip</p>
-14:14 < ant> <Evil-Brotten> are you an i2p expert?</p>
-14:14 < ant> <Evil-Brotten> :P</p>
-14:14 < ant> <Evil-Brotten> ow, ok</p>
-14:14 < ant> <cervantes> Evil-Brotten: you can talk in #i2p-chat if you like while the meeting is ongoing</p>
-14:14 < jrandom> Tracker: we've got a lot to do before handling 1k-wide torrents</p>
-14:14 < ant> <Evil-Brotten> i was just trying to install your program, but i am having some problems</p>
-14:14 < ant> <Evil-Brotten> cool, i will ask there</p>
-14:15 < jrandom> wikked smeghead </p>
-14:15 < Tracker> jrandom: I hope so, non-anonymus bt won't survive much longer...</p>
-14:15 < frosk> nonsense</p>
-14:15 < jrandom> "but exeem is anonymous!@#" </snark></p>
-14:15 < Tracker> jrandom: But that's a different story</p>
-14:15 < ant> <MikeW> what?</p>
-14:15 < ant> <MikeW> who said exeem is anonymous?</p>
-14:16 < jrandom> mikew: just the occational fanboy</p>
-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</p>
-14:16  * DrWoo notes that 'people' are fucking morons (sometimes)</p>
-14:16 < Tracker> jrandom: Yeah, installing spy-/adware isn't really what I would do ;)</p>
-14:16 < jrandom> heh</p>
-14:17 < smeghead> i happen to like people</p>
-14:17 < smeghead> they're good on toast</p>
-14:17 < jrandom> *chomp*</p>
-14:17 < smeghead> some need a little more butter than others</p>
-14:18 < jrandom> ok, i think thats 'bout it for 2) sam.net (unless anyone has something else to add?)</p>
-14:18 < jrandom> if not, moving on to 3) gcj progress</p>
-14:19 < ant> <dm> sam.net??</p>
-14:19 < ant> <dm> is it working?/</p>
-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?</p>
-14:19 < smeghead> yes</p>
-14:20 < ant> <dm> cooooooool</p>
-14:20 < smeghead> i modified a few classes so the router compiles with gcj 3.4.3</p>
-14:20 < smeghead> i will submit the patch after the meeting</p>
-14:20 < smeghead> after that i and anyone who would like to help can get to work on making it run</p>
-14:21 < jrandom> nice</p>
-14:21  * frosk decorates smeghead with the Employee of the Week medal for sam.net _and_ gcj work</p>
-14:21 < jrandom> aye, v.cool</p>
-14:21 < smeghead> :)</p>
-14:22 < Tracker> frosk: better forum user of the week ;)</p>
-14:22 < frosk> i haven't read the forum this week, sorry :)</p>
-14:22 < cervantes> duck's glory has not yet expired ;-)</p>
-14:23  * jrandom is very much looking forward to seeing i2p gcj compatible</p>
-14:24 < jrandom> (and there's still that bounty on it, so people should get in touch with smeghead and get involved ;)</p>
-14:24 < smeghead> yes it would expand i2p's portability significantly</p>
-14:24 < cervantes> maybe we'll be able to squeeze something that resembles performance from the router :P</p>
-14:24 < ant> <dm> my 32-week run as hardest I2P worker ends at last...</p>
-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</p>
-14:25 < jrandom> (but if i'm wrong, cool!)</p>
-14:25 < frosk> anything that can make i2p run better without proprietary software is Good</p>
-14:26 < jrandom> agreed.  supporting both kaffe and gcj would be a Good Thing</p>
-14:27 < jrandom> ok, anything else on 3) gcj progress, or shall we move on?</p>
-14:27 < smeghead> installation would be easier too</p>
-14:27 < Teal`c> has gcj worked for anything besides 'hello world' examples ?</p>
-14:27 < Ragnarok> someone built eclipse with it</p>
-14:27 < smeghead> Teal`c: yes, i've used it for .exe's under mingw before in fact</p>
-14:27 < smeghead> yes, eclipse was running under gcj with red hat not to long ago</p>
-14:28 < jrandom> having the option of distributing gcj'ed executables, plain .jar installers, and bundled .jar+jvm will definitely be Good</p>
-14:29 < jrandom> ok, moving on to 4) udp</p>
-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</p>
-14:30 < Tracker> Yuck</p>
-14:30 < jrandom> (see http://forum.i2p.net/viewtopic.php?t=280 and comment if you have any suggestions/questions/concenrs)</p>
-14:31 < jrandom> yuck Tracker?</p>
-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?</p>
-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.</p>
-14:32 < jrandom> hmm</p>
-14:32 < Tracker> Just my experience from 5 years online gaming...</p>
-14:33 < jrandom> we'll certainly need to take into account the congestion and mtu issues as they go out on the net</p>
-14:33 < Tracker> Somehow the two big backbones here don't like to router UPD very well and if only with very low priority.</p>
-14:34 < Tracker> Meaning pings between 5 and 20 seconds.</p>
-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)</p>
-14:34 < Tracker> And high packet loss</p>
-14:34 < jrandom> congestion control is certainly important</p>
-14:35 < Tracker> Why do you think I'm running my own caching dns with a very big cache for years ;)</p>
-14:35 < jrandom> heh</p>
-14:35 < jrandom> well, we will have the fallback of tcp for people who cannot use udp for some reason</p>
-14:36 < jrandom> but udp will be overwhelmingly preferred </p>
-14:36 < Tracker> That's nice.</p>
-14:36 < jrandom> (meaning i hope there will only be perhaps 10 people using tcp out of 1m+ nodes ;)</p>
-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</p>
-14:37 < Tracker> I guess I will be one of them.</p>
-14:37 < jrandom> perhaps.  </p>
-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</p>
-14:38 < jrandom> ok, anything else on udp?  or shall we move on to 5) ???</p>
-14:39 < jrandom> consider us moved</p>
-14:39 < jrandom> 5) ??</p>
-14:39 < jrandom> anyone have anything else to bring up?</p>
-14:40 < Teal`c> is the pizza here yet ?</p>
-14:40 < Jhor> anybody know where i should look to find/debug problems in bittorrent?</p>
-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</p>
-14:41 < jrandom> (assuming you mean i2p-bt and not azneti2p?)</p>
-14:42 < Jhor> yeah, i2p-bt.  what are the different spew levels?</p>
-14:42 < jrandom> no idea, all i know is --spew 1</p>
-14:42 < Jhor> Ok, I'll try that</p>
-14:43  * Jhor prepares for a crash course in python</p>
-14:43 < jrandom> :)</p>
-14:44 < jrandom> ok, anybody else have something to discuss?</p>
-14:44  * cervantes wheels out the Strand Gong</p>
-14:44 < jrandom> we're around the 60m mark, so a pretty good rate</p>
-14:44 < Teal`c> when is udp due for general consumption ?</p>
-14:44 < jrandom> Teal`c: april</p>
-14:44 < jrandom> thats 0.6, we're still working on 0.5</p>
-14:45 < Teal`c> nice work.</p>
-14:46 < jrandom> progress, ever onwards</p>
-14:46  * jrandom winds up</p>
-14:46  * jrandom *baf*s the gong, closing the meeting</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/126.rst b/i2p2www/meetings/126.rst
new file mode 100644
index 00000000..ebc8d954
--- /dev/null
+++ b/i2p2www/meetings/126.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 25, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/127.log b/i2p2www/meetings/127.log
index ada0e44c..124613f1 100644
--- a/i2p2www/meetings/127.log
+++ b/i2p2www/meetings/127.log
@@ -1,159 +1,153 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 127{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 1, 2005</h3>
-<div class="irclog">
-13:06 < jrandom> 0) hi</p>
-13:06 < jrandom> 1) 0.5 status</p>
-13:06 < jrandom> 2) nntp</p>
-13:06 < jrandom> 3) tech proposals</p>
-13:06 < jrandom> 4) ???</p>
-13:06 < jrandom> 0) hi</p>
-13:06  * jrandom waves</p>
-13:06 <+postman> hi jr</p>
-13:07  * postman waves</p>
-13:07 < jrandom> w3wt there is life out there :)</p>
-13:07 < jrandom> weekly status notes posted up @ http://i2p.net/pipermail/i2p/2005-February/000561.html</p>
-13:07 < ant> * dm waves</p>
-13:08 < jrandom> while y'all read that email, we can jump into 1) 0.5 status</p>
-13:08 < MANCOM> hi</p>
-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</p>
-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</p>
-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 </p>
-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.</p>
-13:12 <+protokol> yey</p>
-13:12 <+polecat> I imagine it works very well though.  :)</p>
-13:12 <+protokol> are you throwing in any other cool compatibility-breaking stuff?</p>
-13:13 <+protokol> the tunnel pool has to do with treads, right?</p>
-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)</p>
-13:14 < jrandom> protokol: i'm considering http://www.i2p/todo#sessionTag</p>
-13:14 <+polecat> So how to prevent multiple hops passing around bogus messages, and causing a DoS?</p>
-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</p>
-13:15 < jrandom> polecat: they'll fail at the endpoint, and the creator will detect the failure and move off it</p>
-13:16 <+protokol> jrandom: aside from any difficulty, i think any anon-improving features should go in ASAP</p>
-13:16 <+polecat> w00t!  Synchronized PRNG!  First application I've ever seen of that idea!</p>
-13:17 < ant> <dm> what does PRNG stand for?</p>
-13:17 < ant> <dm> if I may ask :)</p>
-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)</p>
-13:18 < jrandom> dm: PseudoRandom Number Generator</p>
-13:18 < ant> <dm> cool, thanks</p>
-13:20 <+protokol> so youre saying that after this, its mostly speed and reliability tweaking?</p>
-13:21 <+protokol> and why has IRC been sucking lately</p>
-13:21 < jrandom> protokol: prior to 2.0 for the core and router, yes</p>
-13:21 <+protokol> i cant seem to connect to ducks server</p>
-13:21 <+protokol> yey</p>
-13:21  * jrandom doesnt know, we've seen perhaps 5 bulk disconnects in the last day or so, perhaps something on the server side</p>
-13:22 < jrandom> there's lots to be tweaked though, especially in the streaming lib after 0.5 is deployed</p>
-13:23 <+polecat> That whole UDP thing.</p>
-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</p>
-13:25 < jrandom> ok, thats all i have to bring up wrt 0.5 status - anyone have anything else on it?</p>
-13:27 < jrandom> if not, moving on to 2) nntp</p>
-13:27 < jrandom> nntp.fr.i2p is up, check it out :)</p>
-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)</p>
-13:30 < smeghead> LonelyGuy? :)</p>
-13:30 < cervantes> did someone also test Pan?</p>
-13:30 < jrandom> hes been on here occationally</p>
-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.</p>
-13:30 < jrandom> (lonelyguy, not pan ;)</p>
-13:30 < smeghead> i thought his name was LazyGuy</p>
-13:31 < jrandom> is it LazyGuy?</p>
-13:31 < jrandom> i know we've had both...</p>
-13:31 < jrandom> you're right, lazyguy</p>
-13:31  * jrandom !stabs self</p>
-13:31 < jrandom> cervantes: i think LazyGuy tried it out, i dont know the config or result though</p>
-13:32 < cervantes> I thought it was LimeyGuy?</p>
-13:33  * jrandom awaits SnarkeyGuy's comments</p>
-13:33 < smeghead> he's French</p>
-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</p>
-13:35 < cervantes> smeghead: you're thinking of ParesseuxGuy</p>
-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</p>
-13:36 < jrandom> 2) nntp</p>
-13:36 < jrandom> 3) tech proposals</p>
-13:36 < jrandom> erg</p>
-13:36 < jrandom> damn ^C^V</p>
-13:36 < jrandom> up at http://ugha.i2p/I2pRfc that is</p>
-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</p>
-13:39 < jrandom> i dont really have much more to add beyond that. its a wiki, get wikiing :)</p>
-13:39 <+polecat> Yay.</p>
-13:39 <+postman> jrandom: ohh, cool i think i need to add a few ...</p>
-13:40 < jrandom> cool postman, thought you would :)  there's a template up there for new ones</p>
-13:41 <+postman> jrandom: gimme a lil time (first things first) but i will contribute :)</p>
-13:41 < jrandom> w3rd</p>
-13:41 <+polecat> ResourceNameMetadata, forming it is relatively trivial.  The trick is figuring out how to /get/ it from other people.</p>
-13:42 < jrandom> polecat: as postman said, first things first.</p>
-13:42 <+polecat> But if I had a solution, I'd be wikiing now wouldn't I.  :)</p>
-13:42 < jrandom> heh</p>
-13:42 < jrandom> discussion of the tradeoffs of /how/ to distribute prior to deciding /what/ to distribute is premature</p>
-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 ;)</p>
-13:44 < jrandom> ok, unless there's something else on that, perhaps we can swing on to good ol' 4) ???</p>
-13:44 < jrandom> anyone have anything else to bring up?</p>
-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?</p>
-13:46 <+polecat> What to distribute is just a signed dict.  Simple as that.</p>
-13:46 <+polecat> Yeah probably a good idea.</p>
-13:46 <+polecat> I'm STILL working on the skeleton for my i2p bt client, though would very much appreciate advice at any stage.</p>
-13:46 < smeghead> i think i've found a solution</p>
-13:46 < smeghead> in gnu crypto, there's a fortuna impl. since last summer</p>
-13:46 < jrandom> nice polecat </p>
-13:46 < jrandom> oh cool smeghead </p>
-13:46 <+polecat> smeghead: Hee, the $150 is as good as yours.</p>
-13:47 < smeghead> i can whip up a gnu-crypto.jar that contains only the classes needed for Fortuna</p>
-13:47 <+polecat> My working notes so far are at http://polecat.i2p/bittorrent.plan.doc</p>
-13:47 < smeghead> if we shipped the whole gnu-crypto.jar it's about 500 KB, too big really</p>
-13:47 <+polecat> Don't let the .doc scare you, it's in text/plain.</p>
-13:48 <+polecat> Fortuna doesn't use SecureRandom to do random things?</p>
-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)</p>
-13:48 < smeghead> SecureRandom was never the problem</p>
-13:48 < jrandom> polecat: fortuna /feeds/ secureRandom :)</p>
-13:49 < smeghead> jrandom: it would be easy to make a custom .jar, probably around 50KB</p>
-13:49 < smeghead> (rough estimate mind you)</p>
-13:49 < smeghead> i could make an ant build to custom package it on demand even</p>
-13:50 < jrandom> smeghead: wanna dig 'er into i2p/apps/fortuna/ ?</p>
-13:50 < smeghead> will do</p>
-13:50 < jrandom> kickass!</p>
-13:51 < smeghead> after that, assuming gcj will finally be spitting out random numbers, there will probably be more testing of various i2p functionality</p>
-13:51 <+polecat> What's the license?</p>
-13:51 < jrandom> we can then work some voodo in net.i2p.util.RandomSource to either use SecureRandom or fortuna (if its found, etc)</p>
-13:51 < smeghead> lgpl</p>
-13:51 <+polecat> Cool.</p>
-13:51 < smeghead> true, SecureRandom would be unnecessary</p>
-13:52 < jrandom> yeah, there's still lots to do to get it gcjing, but its a great start</p>
-13:52 < jrandom> in the profiles i've done on the live net, reseeding the PRNG takes a good portion of the cpu load</p>
-13:52 < smeghead> if anyone is into writing tests</p>
-13:52 < smeghead> but i probably don't have to finish that sentence</p>
-13:52 < jrandom> hehe</p>
-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</p>
-13:54 < smeghead> and their cvs commit logs aren't too enlightening either</p>
-13:54 < jrandom> 'k good idea</p>
-13:54 < smeghead> i hope it works</p>
-13:54 < smeghead> it's in kaffe cvs btw</p>
-13:54 < smeghead> your version should have it even</p>
-13:55 < jrandom> hmm, ah, yeah from the gnu-crypto import</p>
-13:55 < smeghead> gnu.security.prng.Fortuna</p>
-13:55 < jrandom> the 'kaffe' provider still uses their old sha1prng iirc</p>
-13:55 < jrandom> cool</p>
-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?</p>
-13:56 < smeghead> MANCOM: it needs testing, i'll be writing some unit tests for it soon</p>
-13:56 < smeghead> this gcj thing has kinda put that on hold</p>
-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</p>
-13:58 < smeghead> changes behind the API are likely, but you as a client don't need to know that :)</p>
-13:59 < MANCOM> :)</p>
-13:59 < jrandom> there may be some later updates that are relevent if you build apps that do large bulk transfer</p>
-14:00 < jrandom> but if you're just transferring a 10s of KB at a time, it should be fine</p>
-14:00 < smeghead> ok if the Java client's API changes, then the sam-sharp's will too :)</p>
-14:01 < MANCOM> i can't argue against that</p>
-14:02 < jrandom> ok, does anyone have anytihng else to bring up for the meeting?</p>
-14:02  * cervantes lowers big ben into the channel</p>
-14:03 <+DrWoo> note: nice work jrandom</p>
-14:03 < smeghead> nice pun cervantes</p>
-14:03  * jrandom groans</p>
-14:04 < MANCOM> i read that you don't want to advertise i2p too much before v0.5, is that true?</p>
-14:04 < jrandom> MANCOM: before 0.6.  yes</p>
-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</p>
-14:04 < MANCOM> ah. 0.6. ok.</p>
-14:05 < jrandom> gracias doc, lots of progress :)</p>
-14:05 <+polecat> Whee, here's looking forward to 0.6...</p>
-14:05 <+DrWoo> :)</p>
-14:06 < jrandom> agreed polecat, agreed :)</p>
-14:06  * jrandom winds up</p>
-14:06  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/127.rst b/i2p2www/meetings/127.rst
new file mode 100644
index 00000000..4855f729
--- /dev/null
+++ b/i2p2www/meetings/127.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 1, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/128.log b/i2p2www/meetings/128.log
index 774dbd81..9493fd50 100644
--- a/i2p2www/meetings/128.log
+++ b/i2p2www/meetings/128.log
@@ -1,291 +1,285 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 128{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 8, 2005</h3>
-<div class="irclog">
-13:05 < jrandom> 0) hi</p>
-13:05 < jrandom> 1) 0.4.2.6-*</p>
-13:05 < jrandom> 2) 0.5</p>
-13:05 < jrandom> 3) i2p-bt 0.1.6</p>
-13:05 < jrandom> 4) fortuna</p>
-13:05 < jrandom> 5) ???</p>
-13:06 < jrandom> 0) hi</p>
-13:06  * jrandom waves</p>
-13:06 <@duck> y0</p>
-13:06 < smeghead> hi</p>
-13:06 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000564.html</p>
-13:07 < cervantes> sorry I'm late...I was busy reading the status notes that were posted at the last minute...</p>
-13:07 < jrandom> hey, this week they were /before/ the meeting at least (by 30s or so ;)</p>
-13:08 < jrandom> anyway, while you dig through that oh so exciting email, lets jump on into 1) 0.4.2.6-*</p>
-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.  </p>
-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</p>
-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</p>
-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</p>
-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</p>
-13:12 < jrandom> did i have a convincing argument before?</p>
-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?</p>
-13:13 <+Ragnarok> not really, I just didn't care either way :)</p>
-13:13 < jrandom> oh, cool you're the boss</p>
-13:13 < cervantes> well you convinced me to drop all my work on a multi-tld management system and fire all my employees</p>
-13:13 <+Ragnarok> filtering is already happening, so it's just adding a condition to an if statement</p>
-13:14 < jrandom> cervantes: there's also this beautiful bridge i've got for sale...</p>
-13:14 < cervantes> :)</p>
-13:14 < jrandom> ok word Ragnarok, if you want to send me a .java/.tar/.diff/.whatever, that'd be great</p>
-13:15 <+Ragnarok> I can do cvs now :)</p>
-13:15 < jrandom> :) even better</p>
-13:15  * cervantes backs up cvs head</p>
-13:15 < jrandom> heh</p>
-13:16 <+Ragnarok> *BOOM*</p>
-13:16 <+Ragnarok> ... just kidding :)</p>
-13:17 < jrandom> ok, other than that, anyone have anything else to bring up wrt 0.4.*?</p>
-13:17 < ant> <dm>gt; 0.4.* sucks, give us 0.5</p>
-13:17 < ant> <dm>gt; It's like a gazillion years old!!</p>
-13:18 < ant> <fvw>gt; 0.4.* doesn't suck, give us 0.5 anyway.</p>
-13:18 < jrandom> 2) 0.5 it is then :)</p>
-13:19 < ant> <dm>gt; you guys owe me big time, I brought 0.5</p>
-13:19 < jrandom> we couldn't'a done it without ya dm </p>
-13:19 < ant> <dm>gt; amen</p>
-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</p>
-13:21 < jrandom> (e.g. the next task on my list is a tunnel config page to manage the pools and settings)</p>
-13:22 <@duck> I hope we will have a test-0.5 network before releasing?</p>
-13:22 < jrandom> there have been updates to lots of different components though, so 0.5 might be a bit bumpy</p>
-13:22 < ant> <dm>gt; jrandom HAS a test network already.. duh</p>
-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</p>
-13:24  * postman can offer a dedicated machine</p>
-13:24 < jrandom> wikked.  perhaps we can try something out tomorrow, try to break some things.  </p>
-13:26 < cervantes> as can I</p>
-13:27 < jrandom> word</p>
-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</p>
-13:28 < jrandom> anyone else have any comments/questions/concerns/frisbees wrt 0.5?</p>
-13:29 <+postman> no</p>
-13:29  * postman is looking forward to get the new V8 running :)</p>
-13:30 < jrandom2p> well, 0.5 is more of a new tank - designed to improve security and anonymity, not as a performance tweak ;)</p>
-13:30 < jrandom2p> but i agree, its been too long</p>
-13:30 <@duck> dont forget to add a 0.5 target to bugzilla</p>
-13:30 <@duck> in case there are bugs</p>
-13:30 < jrandom2p> (heh, did i even add a 0.4?)</p>
-13:31 < jrandom2p> but good call</p>
-13:31 <@duck> or would you like bugs elsewhere</p>
-13:31 <@duck> err bugreports :)</p>
-13:31 <@duck> I know that I have been lazy and abuse irc messages for them</p>
-13:31 < jrandom2p> no, bugzilla is great, much better than my notebook</p>
-13:32 < jrandom2p> i don't blame you, as bugzilla is a bit of a pain</p>
-13:32 < jrandom2p> but as bugs pile up, its for the best</p>
-13:32 <@duck> nah</p>
-13:33  * jrandom just noticed i'm switching schitzophrenically between screens</p>
-13:34 < jrandom> ok, anyway, moving on to 3) i2p-bt 0.1.6</p>
-13:34 < jrandom> duck: you've got the mic </p>
-13:34 <@duck> ok</p>
-13:34 <@duck> i2p-bt 0.1.5 had some issues, the two biggest ones:</p>
-13:35 <@duck> - resource temporarily unavailable</p>
-13:35 <@duck> - invalid argument error on windows</p>
-13:35 <@duck> both have been fixed</p>
-13:35 < jrandom> (yay!)</p>
-13:35 <@duck> while I tried to blame the sam protocol, the sam bridge and winsock</p>
-13:35 <@duck> the problem turned out to be related to non-blocking socket code</p>
-13:36 <@duck> I yet have to see 0.1.6 crash</p>
-13:36 <@duck> some other issues are not addressed:</p>
-13:36 <@duck> the GUI users have been complaining about the popups</p>
-13:36 <@duck> you can comment them out, but I didnt like that</p>
-13:37 <@duck> still waiting for someone to implement a better solution</p>
-13:37 <@duck> like showing a status line on the transfer window itself</p>
-13:37  * smeghead hides</p>
-13:37 < smeghead> i looked at that last night actually</p>
-13:37 < smeghead> but it's not at the top of my priority list</p>
-13:37 <@duck> or maybe one day I will look into how wxPython works and do it myself</p>
-13:37 <@duck> but it's not at the top of my priority list</p>
-13:38 <@duck> and I dont use the GUI, so I dont really care :P</p>
-13:38 <+Ragnarok> there's always the new gui from 3.9 :)</p>
-13:38 <@duck> is it any better?</p>
-13:38 < smeghead> yes why did you base i2p bt on such a crusty version in the first place? :)</p>
-13:38 <@duck> because it was the stable release at that moment</p>
-13:39 <@duck> and not as mutilated as clients like bittornado</p>
-13:40 <@duck> Ragnarok: ignoring licensing issues, I think that porting our i2p things to 3.9 might be good</p>
-13:40 <+Ragnarok> the new gui is pretty awsome, imho, and it's written using pygtk, so I can actually hack on it</p>
-13:40 < jrandom> what's 3.9's license?  i thought it was mit-esque?</p>
-13:40 <+protokol> i would love a more recent jetty version</p>
-13:40 < smeghead> protokol: that's coming sooner than you think</p>
-13:41 <@duck> "BitTorrent Open Source License"</p>
-13:41 < smeghead> flavor of the month license</p>
-13:41 <+Ragnarok> I haven't read all of it.. it seems odd</p>
-13:41 <+protokol> licencing does not exist on i2p</p>
-13:41 <@duck> derived from the Jabber Open Source License 1.0</p>
-13:41 <+protokol> if there is source, its PD</p>
-13:41 <@duck> protokol: that is why I said 'ignoring'</p>
-13:42 < smeghead> and the jabber license is based on?</p>
-13:42 < jrandom> (out of date copyright laws?)</p>
-13:42 < smeghead> besides that :)</p>
-13:43 < modulus> Sun's wish to fuck about.</p>
-13:43 <@duck> http://www.opensource.org/licenses/jabberpl.php</p>
-13:43 < smeghead> i move we schedule the licensing issue for the next meeting of the I2P Public Domain Security Council</p>
-13:43 < modulus> ah, that one</p>
-13:43 < modulus> misheard.</p>
-13:45 <@duck> 3.9.0 looks hot</p>
-13:45 <@duck> it is still beta though</p>
-13:47 <@duck> ok, those willing to help, please let me know</p>
-13:47 <@duck> so we can look into using 3.9.x</p>
-13:47 <@duck> .</p>
-13:47 < jrandom> w3rd</p>
-13:47 < smeghead> i'm willing to help out</p>
-13:47 < jrandom> i'm willing to help test</p>
-13:48 <+Ragnarok> I'm willing, but there are likely to be time constraints, as I am currently having the semester from hell.</p>
-13:48 < jrandom> d'oh</p>
-13:48 <@duck> drop out</p>
-13:48 < jrandom> damn, duck beat me</p>
-13:48 < smeghead> yes, everyone does it</p>
-13:49 <+Ragnarok> boo</p>
-13:49 < ant> <jnymo>gt; just join the military ;)</p>
-13:50 < jrandom> yeah, as that'll give you lots of time to code, 'eh?  ;)</p>
-13:50 <+Ragnarok> I've already given up on being a math major, that's as much as you're getting from me :)</p>
-13:50 < jrandom> heh</p>
-13:50 < jrandom> ok, anyone else have anything on 3) i2p-bt?  </p>
-13:51 < ant> <jnymo>gt; just don't sign up for six years</p>
-13:51 <@duck> quite a bit of forum posts on it</p>
-13:51 <@duck> thanks to those who aid the newbies</p>
-13:51 <@duck> s/thanks/my thanks/</p>
-13:51 <@duck> if you have stuff for a FAQ, lemme kno</p>
-13:52 < jrandom> (if we still had drupal, we could just add a new node...)</p>
-13:53 < jrandom> ok, anyway, moving on to 4) fortuna</p>
-13:54 < jrandom> smeghead: wanna give us an update on things?</p>
-13:54 < smeghead> yes, i'm working on pants and fortuna in tandem</p>
-13:55 < smeghead> since i needed to modify fortuna's build to turn it into a pbuild</p>
-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</p>
-13:56 < jrandom> heh</p>
-13:56 <@duck> so you'll get your pants down?</p>
-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</p>
-13:56 < smeghead> well even if i finish it tonight, i would take a conservative stance on deployment</p>
-13:57 < jrandom> reasonable enough</p>
-13:57 < smeghead> until we get some decent testing in</p>
-13:57 < smeghead> since this will be at the heart of most of i2p's crypto</p>
-13:57 < jrandom> aye</p>
-13:57 < ant> <jnymo>gt; will jbigi stay?</p>
-13:57 < smeghead> your new entropy class is cool</p>
-13:58 < jrandom> yeah jnymo, this is just a random # generator</p>
-13:58 < ant> <jnymo>gt; ah</p>
-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.</p>
-14:00 < smeghead> btw if anyone wants to read what this pants thing is about: http://smeghead.i2p/README_pants</p>
-14:00 < jrandom> oh wikked</p>
-14:01 < smeghead> pants is almost done too</p>
-14:01 < brachtus> i know jbigi is kinda hard to get working with OS X/Darwin... will this have the same build problems?</p>
-14:01 < smeghead> what is the issue on osx?</p>
-14:01 < modulus> it's just you have to build the lib</p>
-14:02 < modulus> not a big deal imo, but somewhat troublesome.</p>
-14:02 < jrandom> brachtus: fortuna is in pure java, doesnt use anything native</p>
-14:02 < smeghead> i can put jbigi into pants and that should make building a cinch if we ship pants with i2p</p>
-14:02 < brachtus> nothign terribly difficult, it's like building a shared lib on linux, but harder than just double-click-install</p>
-14:02 < smeghead> you'd need ant of course</p>
-14:02 < brachtus> ok jrandom, that's great :)</p>
-14:03 < jrandom> smeghead: thats actually a good point - jbigi has a pants dependency upon GMP</p>
-14:03 < ant> <jnymo>gt; what is pants?</p>
-14:03 < smeghead> no manual mucking would be necessary</p>
-14:03 < ant> * jnymo doesn't have a router up</p>
-14:03 < smeghead> jnymo: read that link i just posted</p>
-14:04 < jrandom> http://bolas.mine.nu:8080/cgi-bin/nph-proxy/000000A/http/smeghead.i2p/README_pants</p>
-14:04 < smeghead> pants can build gmp too</p>
-14:04 < jrandom> (public inproxy)</p>
-14:04 < smeghead> ah nice</p>
-14:04 < jrandom> yuck, that totally b0rked the text</p>
-14:04 < ant> <jnymo>gt; thanks jr</p>
-14:04 < ant> <fvw>gt; aren't you afraid of legal trouble?</p>
-14:04 < smeghead> jrandom doesn't run the inproxy</p>
-14:04 < jrandom> oh, the inproy is run by someone else, its been posted to the forum</p>
-14:05 < jrandom> (see http://bolas.mine.nu:8080/)</p>
-14:05 < cervantes> jrandom: it shouldn't be viewed as an html file...check the source</p>
-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 :)</p>
-14:05 < jrandom> hehe</p>
-14:05 < jrandom> we're /all/ vital to the project :)</p>
-14:06 < smeghead> fvw: i don't see inproxies as legally precarious as outrpoxies</p>
-14:06 < smeghead> outproxies even</p>
-14:06 < ant> <fvw>gt; Perhaps not, but they can still serve up child porn and such</p>
-14:06 < jrandom> only if there were such things on i2p, which, to my knowledge, there isnt </p>
-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.</p>
-14:07 < jrandom> (but yeah)</p>
-14:07 < modulus> yet</p>
-14:07 < ant> <fvw>gt; yeah, but anyone can put it on at any point.</p>
-14:07 < ant> <fvw>gt; yeah, I wouldn't run a tor outproxy either. Anyway, sorry for drifting offtopic like that</p>
-14:07 < jrandom> legion: yeah, though i tossed up squid.i2p before tor was out</p>
-14:07 < ant> <duck_>gt; to get back on topic; looking forward to pants</p>
-14:08 < jrandom> aye, pants++</p>
-14:08 < smeghead> i'll let you know before i drop pants on CVS</p>
-14:08 < smeghead> it's kinda big</p>
-14:08 < ant> <duck_>gt; folks outside of i2p might be interested in it too</p>
-14:09 < cervantes> yes let us all know before you drop your pants</p>
-14:09 < smeghead> yes, i intend to publicise it outside of i2p also</p>
-14:09 < jrandom> agreed, perhaps we should put it in another module (or on the new fast/large server)?</p>
-14:09 <+Ragnarok> especially if you're a big pants kind of guy</p>
-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</p>
-14:10 < smeghead> :/</p>
-14:10 < smeghead> which i don't have to tell you is total pants</p>
-14:11 < smeghead> so what were we talking about originally?</p>
-14:11 < jrandom> hmm, we can discuss deployment options offline</p>
-14:11 < jrandom> fortuna ;)</p>
-14:11 < smeghead> right</p>
-14:12 < jrandom> smeghead: have you looked at the AES/SHA256 needs of the impl?</p>
-14:12 < jrandom> (as i2p's SHA256 doesn't do partial digests)</p>
-14:13 < smeghead> hm</p>
-14:13 < jrandom> AES we've got perfectly suitable block impl though</p>
-14:13 < smeghead> i guess i'll find out when it blows up</p>
-14:13 < jrandom> anyway, we can work those through too</p>
-14:13 < jrandom> heh</p>
-14:15 < jrandom> ok, anyone have any questions/thoughts/concerns on fortuna?</p>
-14:15 < jrandom> if not, hopping on over to 5) ???</p>
-14:15 < jrandom> cervantes: p1ng</p>
-14:16 < cervantes> http://forum.i2p/viewtopic.php?t=305</p>
-14:16 < cervantes> we have a new forum member of the week</p>
-14:16 < cervantes> I present [drumroll] Sugadude!</p>
-14:16  * brachtus applauds Sugadude</p>
-14:17 < jrandom> yay</p>
-14:17 < cervantes> for generally being a helpful sod to all those i2p n00bs</p>
-14:17 <@duck> nice avatar too</p>
-14:17 < cervantes> avatar(s)</p>
-14:18 < legion> avatars? didn't know that we could have avatars on the i2p forums?</p>
-14:18 < smeghead> only users who are really really bad get them</p>
-14:18 < cervantes> you can't...unless you're a forum person of the week ;-)</p>
-14:18 <@duck> only for the elite</p>
-14:18 < legion> oh, i see...</p>
-14:19 < ant> <jnymo>gt; i know someone was interested in secure financial systems over i2p</p>
-14:19 < legion> makes sense :)</p>
-14:19 < ant> <jnymo>gt; don't know if they're here, but...</p>
-14:19 <@duck> I am a smelly anarcho capitalist</p>
-14:19 <@duck> so try me</p>
-14:20 < ant> <jnymo>gt; i was reading more on threashold cryptography and theres talk about using it for that</p>
-14:20 < ant> <jnymo>gt; as well as securing other functions</p>
-14:21 < ant> <jnymo>gt; everyone familiar with threshold cryptography?</p>
-14:21 < legion> IMO that cryptography and network security should be variable, how much should depend on the feature/task.</p>
-14:21 < ant> <duck_>gt; jnymo: a bit</p>
-14:22 < ant> <jnymo>gt; well, for trustable financial transactions in i2p, we want strong decentralized trust</p>
-14:22 < modulus> is that about the shared keys and shit like that?</p>
-14:23 < ant> <jnymo>gt; yea, keys are shared in pieces</p>
-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?</p>
-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</p>
-14:24 < modulus> afaik it's kind of complicated the issue of distributed key generations though.</p>
-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).</p>
-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</p>
-14:25 < ant> <jnymo>gt; think</p>
-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</p>
-14:26 < jrandom> neat</p>
-14:26 < legion> dunno, maybe</p>
-14:26 < ant> <jnymo>gt; someone has already built a DNSSEC addon with threshold crypto</p>
-14:27 < ant> <jnymo>gt; and a wrapper around bind</p>
-14:27 < jrandom> thresholds work fine when identity is scarce</p>
-14:27 < jrandom> in anonymous networks, however, identity is free</p>
-14:27 < legion> I'd figure at the moment the highest priority is to get it more user friendly and debugged.</p>
-14:27 < jrandom> (want a new destination?  want 100,000?)</p>
-14:28 < legion> granted it's cool whenever a new service/feature is developed.</p>
-14:28 < jrandom> aye, commerce and finance on top of i2p will be nice</p>
-14:28 < ant> <jnymo>gt; yea, and i wouldn't know if atomic commo would work over a 10000 node threshold crypto sys</p>
-14:29 < ant> <jnymo>gt; well, that's all i had to say :)</p>
-14:30 < jrandom> heh cool, definitely feel free to post up neat stuff to the forum or whatnot whenever</p>
-14:30 < jrandom> ok, anyone else have anything for the meeting?</p>
-14:32 <+ugha2p> I suck.</p>
-14:33 < jrandom> whats up ugha2p?</p>
-14:33 < ant> <jnymo>gt; glad you got that off your' chest, ugha ;)</p>
-14:33 <+ugha2p> I never remember the meetings. :)</p>
-14:33 < jrandom> heh</p>
-14:33 < jrandom> well, the logs will be posted soon, 90 minutes of action packed fun</p>
-14:34 < jrandom> well, on that note</p>
-14:34  * jrandom winds up</p>
-14:34  * Curiosity waves to jrandom and stays thank-you! :D</p>
-14:34 < ant> * jnymo pitches the meeting ball</p>
-14:34  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/128.rst b/i2p2www/meetings/128.rst
new file mode 100644
index 00000000..53a36b7b
--- /dev/null
+++ b/i2p2www/meetings/128.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 8, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/129.log b/i2p2www/meetings/129.log
index 8a81ea7a..e6d5cdfb 100644
--- a/i2p2www/meetings/129.log
+++ b/i2p2www/meetings/129.log
@@ -1,253 +1,247 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 129{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 15, 2005</h3>
-<div class="irclog">
-13:07 < jrandom> 0) hi</p>
-13:07 < jrandom> 1) Net status</p>
-13:07 < jrandom> 2) 0.5 status</p>
-13:07 < jrandom> 3) i2p-bt 0.1.7</p>
-13:07 < jrandom> 4) ???</p>
-13:07 < jrandom> 0) hi</p>
-13:07  * jrandom waves</p>
-13:07 <+ugha2p> jrandom: Is irc.duck.i2p also available on the testnet and linked to this network?</p>
-13:07 <+ugha2p> To this IRC network</p>
-13:07 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2005-February/000575.html</p>
-13:07 < ant> <Sonium_> Bonjour, sa cette fois de la semaine encore,</p>
-13:07 < jrandom> no ugha2p </p>
-13:08 < ant> <Sonium_> are you speaking french jrandom ?</p>
-13:08 < jrandom> heh, yeah, proof that babelfish has its limits ;)</p>
-13:08 < jrandom> lol, yeah, people were saying babelfish was turning out ok french before, but aparently not this time ;)</p>
-13:09 <+ugha2p> Hi fellow I2Pers.</p>
-13:09 < ant> <fedo2p> hi </p>
-13:09 < jrandom> anyway, lets get this underway before we netsplit again </p>
-13:09 < jrandom> 1) net status</p>
-13:09 < jrandom> see the email for an update</p>
-13:10 < jrandom> it seems that while irc has been pretty bumpy, as has some outproxy activity, bt has been doing pretty well</p>
-13:11 < jrandom> i don't really have much more to add beyond that though - anyone have any comments/questions/concerns?</p>
-13:12 < ant> <Sonium_> will 0.5 be released this friday?</p>
-13:12 < jrandom> heh good question, I suppose that can bring us on to 2) 0.5 status</p>
-13:12 < jrandom> yes, 0.5 will be released this friday</p>
-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</p>
-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" ?</p>
-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</p>
-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</p>
-13:15 < jrandom> Sonium: the later is more definitive, but same general idea</p>
-13:15 < bla_> smeghead: I'd agree, but 0.5 will not solve the load problem, will it?</p>
-13:15 < smeghead> eepsites are affected too, not just irc</p>
-13:16 < ant> <Sonium_> ok, than it missunderstood the usage till now</p>
-13:16 <+ugha2p> jrandom: Will it be doing a better job with interactive traffic?</p>
-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</p>
-13:16 < ant> <Sonium_> I better would have listened up at school</p>
-13:16 < jrandom> ugha2p: yes, substantially</p>
-13:17 <+ugha2p> Ah, cool.</p>
-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</p>
-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</p>
-13:18 < ant> <BS314159> smeghead: it's three days. I'm sure you can come up with something else to do for three days</p>
-13:19  * jrandom could poke open an inproxy to spaetz's 0.5 ircd :)</p>
-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</p>
-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 )</p>
-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.</p>
-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?</p>
-13:22 < polecat> Does i2p-bt use SAM, or does it use an i2ptunnel session?</p>
-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 </p>
-13:23 < jrandom> polecat: SAM</p>
-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</p>
-13:23 < smeghead> BS314159: is it more important for you to torrent than it is for us to develop</p>
-13:23 < smeghead> ?</p>
-13:23 < smeghead> polecat: sam</p>
-13:23 < cervantes> make 0.1.8 shop all it's users to the mpaa and we'll all stick with 0.1.7</p>
-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</p>
-13:23 < jrandom> heh cervantes </p>
-13:23 < jrandom> ooOOo nice</p>
-13:24 < jrandom> perhaps thats a good segue from 2) 0.5 status to 3) i2p-bt :)</p>
-13:24 < jrandom> smeghead/duck, how goes?  </p>
-13:25 < ant> <Sonium_> google knows 167 links to www.i2p.org</p>
-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</p>
-13:26 < ant> <Sonium_> erm .net</p>
-13:26 < smeghead> all the bt mods in 0.1.7 have been integrated into the new 0.2.0 codebase</p>
-13:26 < smeghead> but we have to write a completely new sam interface, we can't use the one from 0.1.7</p>
-13:27 < jrandom> ah ok</p>
-13:27 < smeghead> if there's anyone with python socket experience that would like to help *cough*connelly</p>
-13:28 < polecat> All that's happening in SAM is the addition of stream level choking, right?</p>
-13:28 < jrandom> polecat: no protocol changes yet (to my knowledge), just porting</p>
-13:28 < smeghead> please get in touch with duck</p>
-13:28 < ant> <MANCOM> anything new on azneti2p?</p>
-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</p>
-13:29 < jrandom> (yay!)</p>
-13:29 < polecat> Reeeally?</p>
-13:29 < smeghead> and hopefully we can get it all working over a single sam session to further reduce network clutterage</p>
-13:29 < bla_> smeghead: Nice! Will you also port the text-onlu bttrackmany?</p>
-13:29 < polecat> Can it run in the background?</p>
-13:29 < jrandom> MANCOM: I haven't heard any news, and unfortunately haven't had time to audit the updates</p>
-13:29 < polecat> How much memory does it sit on?</p>
-13:29 < smeghead> bla_: yes i believe so</p>
-13:30 < smeghead> polecat: using btdownloadheadless.py it's a background process</p>
-13:31 < polecat> A single SAM session is possible: the peerwire and tracker protocol can be divined by both the client and server.</p>
-13:31 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?</p>
-13:32 < smeghead> polecat: and it shouldn't use significantly more memory than the comparable number of 0.1.7 instances do</p>
-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 ;)</p>
-13:36 < bla_> (Connection rollercoaster ride, again...)</p>
-13:36 < jrandom> (this is why I lightly edit the meeting logs ;)</p>
-13:37 < bla_> jrandom: :)</p>
-13:37 < jrandom> wb</p>
-13:37 < polecat> smeghead: Yes, but what if I want to add a torrent to that process?</p>
-13:38 <+ugha2p> jrandom: No, it must be because you're censoring the netsplits.</p>
-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 ;)</p>
-13:38 < jrandom> hey, if i censor the netsplits, they dont happen!  </p>
-13:38  * jrandom buries head in sand</p>
-13:40 < smeghead> but i will use this opportunity to again ask bt users to hold off until friday please</p>
-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 ...</p>
-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.</p>
-13:42 < ant> <dm> I speak french.</p>
-13:43 < ant> <dm> awww shit, I was supposed to not say anything.</p>
-13:43  * jrandom flings mud at dm</p>
-13:43 < bla_> dm: Could you add those messages?</p>
-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</p>
-13:43 <+polecat> Unless someone else had an idea for something better I could waste my time on.  :/</p>
-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.</p>
-13:44 < jrandom> polecat: perhaps help out getting the upcoming i2p-bt to work as you'd like?</p>
-13:44 < jrandom> dm: forum.i2p.net/</p>
-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.</p>
-13:44 <+polecat> Which I might add, mldonkey/mlnet has already done.</p>
-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</p>
-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</p>
-13:45 <+polecat> And I was planning to do with this stupid C++ client thingy o' mine.</p>
-13:45 < jrandom> polecat: so put on a gui, giving you the benefit of the underlying i2p-bt code</p>
-13:45 < ant> <BS314159> but having the use of the MLDonkey interface might be a very good thing</p>
-13:46 <+polecat> Azareus doesn't separate UI from file transfer I dun' think.  :/</p>
-13:46 < smeghead> polecat: you need to try bt 3.9.1, it's a multitorrent client now</p>
-13:48 <+polecat> Does it allow you to quit the UI without quitting swarming your files?</p>
-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</p>
-13:48 < ant> <jnymo> has azureus released a compatable binary for the plugin?</p>
-13:48 < jrandom> polecat: no.  but adding that is trivial compared to writing a new bt client</p>
-13:48 < jrandom> jnymo: yes, they have a beta azneti2p</p>
-13:49 < smeghead> polecat: it could easily be modified to do so, very easily in fact</p>
-13:49 < jrandom> polecat: just modify the existing bt daemon to allow other processes (aka your new GUI) to tell it to do things</p>
-13:49 <+polecat> Well, perhaps...</p>
-13:49 <+polecat> You think so?</p>
-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...</p>
-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</p>
-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!</p>
-13:50 <+polecat> Okay.</p>
-13:50 <+polecat> I have one more question though...</p>
-13:51 < smeghead> polecat: don't reinvent the wheel because something lacks trivial features</p>
-13:51 < smeghead> polecat: you haven't looked at the i2p-bt codebase at all have you? the ui is completely separate</p>
-13:51 <+polecat> If bittorrent 3.9.1 is out, why are we using version 0.2.0 in i2p?  o.o </p>
-13:51 < jrandom> heh</p>
-13:51 < jrandom> i2p-bt 0.2.0 == bt 3.9.1 :)</p>
-13:51 <+polecat> I looked at the codebase a while ago.  It was quite convoluted and obfuscated.</p>
-13:51 < jrandom> (i2p-bt 0.1.* == bt 3.4.something i think)</p>
-13:51 <+polecat> Oh, you have different versioning.</p>
-13:52 <+polecat> Is i2p-bt on CVS?</p>
-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</p>
-13:52 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p-bt/</p>
-13:52 < smeghead> i2p-bt 0.1.7 is bt 3.4.2 based</p>
-13:52 <+polecat> Thanks.</p>
-13:52 <+polecat> Wait.</p>
-13:53 < cervantes> at which point we'll call it version 0.3.0 :P</p>
-13:53 <+polecat> I meant CVS, not the "ooh lookit the pretty website CVS"</p>
-13:53 < jrandom> cvs -d :pserver:anoncvs@cvs.i2p.net/cvsroot co i2p-bt</p>
-13:53 <+polecat> CVSROOT= is noticeably absent on those cvs-cgi thingies I've noticed.</p>
-13:53 < jrandom> or, if you have the CVS proxy locally, cvs -d :pserver:anoncvs@localhost/cvsroot co i2p-bt</p>
-13:54 < smeghead> polecat: convoluted? btdownloadgui.py is all the gui code, how can you get more cleanly separated than that?</p>
-13:54  * polecat whews, and doesn't feel a burning desire to bitch about CVS now.</p>
-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</p>
-13:55 < jrandom> thanks dm</p>
-13:56 < ant> <dm> np</p>
-13:57 < smeghead> it probably says something obscene</p>
-13:58 < ant> <dm> hehehhe</p>
-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.</p>
-13:58 < ant> <BS314159> if it's sufficiently obscene, it may serve our purposes just fine</p>
-13:58 < ant> <fedo2p> good job dm ;)</p>
-13:58 < jrandom> heh</p>
-13:58 < jrandom> r0x0r polecat</p>
-13:59 <+polecat> Sigh, I hate to emerge wxwindows though, it's a big library I don't normally use.  Oh well.</p>
-13:59 < smeghead> polecat: 0.2.0 is gtk based, no more wxwidgets</p>
-13:59 < jrandom> ok, lots of bt work to do, perhaps we can discuss further on the list/forum/wiki/#i2p-bt as necessary?</p>
-13:59 <+polecat> If I'm gonna be hackin', I best get the toolz</p>
-14:00 <+polecat> Oh I forgot about that channel.  :)</p>
-14:00 < smeghead> polecat: get bittorrent 3.9.1 beta and read the docs</p>
-14:01 < smeghead> #i2p-bt, right</p>
-14:01 < smeghead> there's even people there</p>
-14:02 < jrandom> heh ok, lots of exciting bt stuff.  anything else for 3) i2p-bt, or shall we move on to 4) ???</p>
-14:03 < jrandom> ok, moving to 4) ???</p>
-14:03 < jrandom> anyone else have anything else to bring up for the meeting?</p>
-14:03 < ant> <jnymo> threshold crytography rules</p>
-14:04 < cervantes> ??? = http://forum.i2p/viewtopic.php?p=1237</p>
-14:04 < ant> <BS314159> proxies to the web are not cool. What about proxies to new versions of I2P, or other anonymnets?</p>
-14:04 < ant> <BS314159> and by not cool I mean not safe to run</p>
-14:04 < ant> <jnymo> they aren't run by everyone, BS</p>
-14:05 < ant> <BS314159> I know that</p>
-14:05 < cervantes> Forum member of the week is <tadaa!> jrandom</p>
-14:05 < ant> <BS314159> I'm thinking about upgrades</p>
-14:05 < jrandom> lol thanks cervantes </p>
-14:06 < ant> <BS314159> Not now, but eventually, would it be possible to have a large number of routers act as inter-version proxies?</p>
-14:06 < ant> <BS314159> and would that remove the timing attack without downtime?</p>
-14:06 < ant> <jnymo> forced upgrades are necessary</p>
-14:07 < ant> <BS314159> I disagree</p>
-14:07 < jrandom> BS314159: I2NP over i2ptunnel over I2P would be, painful.  though perhaps one of the "outproxies" could point at some inproxy </p>
-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</p>
-14:08 < ant> <BS314159> I'm not saying new versions should be backwards-compatible</p>
-14:08 < cervantes> jrandom: well lets be honest...you're the one that does 98% of the work ;-)</p>
-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</p>
-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.  </p>
-14:10 < ant> <jnymo> automatic update may be better in the future</p>
-14:10 < ant> <BS314159> I'm speaking about the far future.</p>
-14:10 < ant> <jnymo> is auto-update too insecure?</p>
-14:10 < jrandom> cervantes: nah, only 95% of the infrastructure, but there's a lot more goin' on than just i2p/{core,router}/ :)</p>
-14:11 < jrandom> jnymo: 0 click update == insecure.  1 click == safe.</p>
-14:11 < cervantes> jrandom: yes it's begun to pickup over the last couple of months thankfully ;-)</p>
-14:11 < ant> <jnymo> and a line that says "you need to update.. countdown in * days"</p>
-14:12 < jrandom> aye, lots of people [http://www.i2p.net/team] have been doing kickass shit</p>
-14:13 < jrandom> BS314159: definitely lots we can do for later updates, perhaps we can discuss concrete impls as they approach :)</p>
-14:13 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-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?</p>
-14:14 < ant> <MANCOM> it would help keep bandwidth up and latency down</p>
-14:14 < jrandom> oh, interesting</p>
-14:14  * cervantes is working on a 1-2 click update feature for the i2p toolbar</p>
-14:14 < cervantes> although I'm having problems with hashing atm....so it's probably a few weeks away.</p>
-14:15 < ant> <jnymo> cervantes++</p>
-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</p>
-14:15 < cervantes> in which time a dozen people will come up with a glut of better solutions</p>
-14:16 < jrandom> heh</p>
-14:16 < cneal92_> :D</p>
-14:17 < ant> <MANCOM> well, i'll try</p>
-14:17 < ant> <cervantes> but it already detects when there's a new release out, and can point you at the relevant download link...</p>
-14:17 < ant> <cervantes> which I may roll with initially</p>
-14:18 < jrandom> cool cervantes</p>
-14:18 < jrandom> thanks MANCOM</p>
-14:18 < ant> <jnymo> you could just put the "graceful restart" button to upgrade, after the update is already in the directory</p>
-14:19 < ant> <jnymo> or call it "upgrade"</p>
-14:19 < ant> <jnymo> and put the restart function in there</p>
-14:19 < ant> <jnymo> though i'm probably stating the obvious</p>
-14:19 < jrandom> right, we need perhaps a dozen lines of code to fetch http://dev.i2p/i2p/i2pupdate.zip, verify it, then restart</p>
-14:20 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-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</p>
-14:21 < jrandom> cervantes: ah, that part should be easy - at a later date, we'll have the update itself be self-verifying</p>
-14:21 < jrandom> (aka signed, verified by the router before installation)</p>
-14:21 < ant> <cervantes> jrandom: that would be cool.</p>
-14:21 < ant> <jnymo> ooh</p>
-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</p>
-14:22 < ant> <cervantes> so someone can verify manually if desired</p>
-14:23 < ant> <cervantes> (it already displays what the sha1 _should_ be)</p>
-14:23 < jrandom> hehe</p>
-14:23 < ant> <jnymo> how bout, "click here to autodownload on availability"</p>
-14:25 < cervantes> I'd rather avoid auto downloads</p>
-14:25 < ant> <jnymo> hmf.. microsoft does it ;)</p>
-14:26 < cervantes> but by all means alert the user that a download exists and offer a "download now" button</p>
-14:26 < jrandom> right, 1 click at the least.  we can automatically /notify/ on update availability, but autoinstall is not ok</p>
-14:26 < jrandom> (er, what cervantes said)</p>
-14:27 < ant> <jnymo> now, how do 10000 people update? how bout integrating i2p-bt at one point?</p>
-14:27 < jrandom> yes, and flying ponies</p>
-14:28 < ant> <jnymo> good enough for me</p>
-14:29 < jrandom> ok cool... if there's nothing else...</p>
-14:29 <+postman> damn missed the meeting :/</p>
-14:29  * cervantes gets back to coding his vapourware</p>
-14:29 < jrandom> heh you're at the buzzer, in case there's something you want to bring up postman :)</p>
-14:30 <+postman> no thanks</p>
-14:30 <+polecat> Microsoft?  =)  I have gentoo doing it.</p>
-14:30  * jrandom winds up</p>
-14:30 <+postman> ooops</p>
-14:30  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/129.rst b/i2p2www/meetings/129.rst
new file mode 100644
index 00000000..33773fc3
--- /dev/null
+++ b/i2p2www/meetings/129.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 15, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/130.log b/i2p2www/meetings/130.log
index e618b93a..508c5f84 100644
--- a/i2p2www/meetings/130.log
+++ b/i2p2www/meetings/130.log
@@ -1,288 +1,282 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 130{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 22, 2005</h3>
-<div class="irclog">
-13:04 < jrandom> 0) hi</p>
-13:04 < jrandom> 1) 0.5</p>
-13:04 < jrandom> 2) Next steps</p>
-13:04 < jrandom> 3) azneti2p</p>
-13:04 < jrandom> 4) ???</p>
-13:04 < jrandom> 0) hi</p>
-13:04  * jrandom waves</p>
-13:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-February/000595.html</p>
-13:05 < jrandom> (yeah, only a minute or two before the meeting, so lets test your speed reading)</p>
-13:05 <+detonate> i think i'll wait until it's a bit less buggy before i put boondock saints up, in that case</p>
-13:06 < jrandom> why... thats... thats... thats a copyright violation!</p>
-13:06 <+detonate> weird new additions to the azureus beta</p>
-13:06 <+detonate> categories</p>
-13:06 <+detonate> haha</p>
-13:06 <+detonate> a dht tracker</p>
-13:06 <+detonate> sweet</p>
-13:07 < jrandom> aye, it looks v.cool, but lets hit items 1 and 2 before 3, 'eh? ;)</p>
-13:07 <+detonate> hi</p>
-13:07 <+detonate> indeed</p>
-13:07 < jrandom> jumpin into 1) 0.5</p>
-13:07 < jrandom> its, like, out, and stuff</p>
-13:08 < cervantes> yay!</p>
-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)</p>
-13:09 < jrandom> its gone pretty well, but we've hit a few funky bugs along the way.  but c'est la vie</p>
-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)</p>
-13:09 < bla> jrandom: Will the 0.5.0.1 version correct the problem of nor being able to find destinations?</p>
-13:09 < jrandom> ah, well, thats really just a function of other people though, the -0 build actually does build hundreds of tunnels</p>
-13:09 < bla> s/nor/not</p>
-13:10 < jrandom> bla: yes, thats a bug in the netDb</p>
-13:10 < bla> jrandom: Great!</p>
-13:10 < jrandom> (in the leaseSet publishing, specifically)</p>
-13:11 < jrandom> and yes, the 0.5.0.1 rev will get rid of that occational disapearing proxy bug </p>
-13:12 < jrandom> there is still a funky memory leak I haven't tracked down affecting some users</p>
-13:12 < bla> Then, in all, it seems that part from these bugs, the 0.5 net is doing very well. Yay!</p>
-13:12 < jrandom> to my knowledge, its only really hitting two or three I2PTunnel instances though</p>
-13:12 < Meomia> is it a sign of progress when you have gone from 0 to 130 participating tunnels since 0.5 ?</p>
-13:13 < jrandom> w3wt</p>
-13:13 < jrandom> Meomia: bah, I've had over 5000 tunnels ;)</p>
-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</p>
-13:14 < jrandom> (yay)</p>
-13:14 < Meomia> ok</p>
-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?</p>
-13:14 < jrandom> yes, for exploratory tunnels</p>
-13:15 < jrandom> client tunnels will only use peers in the 'fast' tier</p>
-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</p>
-13:16 < jrandom> and performance would suck otherwise ;)</p>
-13:17 < jrandom> actually, that brings us in to 2) Next steps</p>
-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</p>
-13:18 < godmode0> jrandom can use nntp w i2p ?</p>
-13:18 < jrandom> godmode0: there are two NNTP servers on i2p, yes.  see the forum</p>
-13:19 < godmode0> jrandom ok i;m testing</p>
-13:19 < godmode0> i can build my server too ?</p>
-13:20 < jrandom> godmode0: we're in a meeting right now, but yes, you can run a server</p>
-13:20 < godmode0> jrandom ok sorry</p>
-13:20 < jrandom> np</p>
-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</p>
-13:21 < jrandom> perhaps we can find a way to integrate some of the AS paths into the selection, as bla suggested</p>
-13:22 < jrandom> that can both improve (jurisdictional) anonymity, or if we try to stay within an AS (or two), that can improve performance</p>
-13:22 < bla> jrandom: This basically is related to a paper by the Tor creators: http://theland.i2p/files/routing-zones.pdf</p>
-13:22 < jrandom> aye</p>
-13:23 < jrandom> there are a whole slew of different strategies people can use, and trying out new ones should be pretty easy</p>
-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</p>
-13:25 < jrandom> anyway, once the basics are in place, we'll be moving on to focus on the UDP transport for 0.6</p>
-13:26 < jrandom> thats about all I have for 2) next steps, anyone have any comments/questions/concerns?</p>
-13:26 < bla> Who where the ppl that started looking into I2P, again?</p>
-13:26 < bla> It seems we haven't heard much from them, lately.</p>
-13:27 < bla> s/into I2P/into UDP/</p>
-13:27 < bla> sorry</p>
-13:27 < jrandom> ah, mule has been sick, thogh I think detonate is making progress</p>
-13:28 < jrandom> detonate: any news?</p>
-13:29 < jrandom> or perhaps not ;)  </p>
-13:30 < jrandom> ok, moving on to 3) azneti2p</p>
-13:30 <+detonate> sorry</p>
-13:30 <+detonate> i'm making progress</p>
-13:30 <+detonate> i still need to finish the re-assembly side of things</p>
-13:31 <+detonate> as far as splitting data into packets and sending it across in an orderly fashion, that works</p>
-13:31 <+detonate> on to 3)</p>
-13:31 < jrandom> wikked</p>
-13:31 < godmode0> sorry step 2) i2p  has any problem with attacks ?</p>
-13:31 < bla> detonate: Cool! Can you keep all of us posted on the forum?</p>
-13:32 <+detonate> bla: sure</p>
-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.</p>
-13:32 < jrandom> godmode0: the different ordering strategies should let the user choose the impact of predecessor attacks</p>
-13:33 < microsoft> whoever runs i2p.net should add more Enterprise Class Solutions buzzwords to the page.</p>
-13:33 <+detonate> someone needs to make sure that new dht tracker isn't misbehaving as well, with respect to the azureus plugin</p>
-13:33 < tracker> My local tests seem to prove this, I can download with azureus but not seed.</p>
-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</p>
-13:34 < jrandom> detonate: good point</p>
-13:35 < tracker> Good point detonate, I have DHT disabled as azureus dies after some hours whit 100% CPU usage when it's active.</p>
-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</p>
-13:36 < jrandom> while I'm sure they love having people test it out, those who need anonymity may want to be cautious </p>
-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.</p>
-13:37 < jrandom> oh, thats still happening with you tracker?  i havent been able to reproduce that</p>
-13:37 < jrandom> you're on the 0.1.7 rev, right?</p>
-13:37 < tracker> Yes, I'm.</p>
-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</p>
-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.</p>
-13:39 < jrandom> hmm right, i2p-bt uses SAM, while azureus uses the i2p SDK directly</p>
-13:40 < tracker> Btw. I send you a bug-report on the forum. The timestamper is dies on the latest cvs-builds of I2P.</p>
-13:40 < jrandom> ah cool, thanks, havent checked my PMs over there today</p>
-13:41 < jrandom> on -5 or -4?  or earlier?</p>
-13:42 < jrandom> ah, -4.  ok cool</p>
-13:42 < jrandom> thanks, I'll get that fixed for 0.5.0.1</p>
-13:42 < jrandom> ok, anyone have anything else for 3) azneti2p?</p>
-13:43 < tracker> It's also happening on -5</p>
-13:43 < jrandom> you have sntp server defined explicitly, right?</p>
-13:44 < tracker> Yes. The 2 ones from our country.</p>
-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)</p>
-13:44 < jrandom> ok cool, its a trivial fix to % # servers</p>
-13:45 < jrandom> ok, if there's nothing else for azneti2p, moving on to good ol' fashioned 4) ???</p>
-13:46 < jrandom> anyone else have something to bring up for the meeting?</p>
-13:46 < tracker> Nice. I've just send you the log errors from the router when closing i2p-bt on the forum.</p>
-13:47 < jrandom> 'k cool, thanks</p>
-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</p>
-13:48 < tracker> Yep, the latest CVS builds are really performin good over here.</p>
-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</p>
-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</p>
-13:49 < cervantes> strangely the pre version were more stable...for me, but then, I was running them on a different machine ;-)</p>
-13:49 < jrandom> (and these damn bugs to get reliability where it should be)</p>
-13:50 < jrandom> heh well, yeah, but the -pre network was 5-7 routers, all insanely reliable on really really fast connections</p>
-13:50 < cervantes> :)</p>
-13:51 < cervantes> sign me up for the 0.6 pre test then :)</p>
-13:51 < jrandom> heh</p>
-13:51 < tracker> Maybe I should take part in the next pre network then. Providing a very unreliable and slow connection ;).</p>
-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)</p>
-13:51 < jrandom> heh word</p>
-13:51 < cervantes> I can put my 1TB file share online...</p>
-13:52 < jrandom> we'll definitely need lots of help with the 0.6 testing, pulling in a whole variety of network setups</p>
-13:52 < hobbs> ssh '~C' command is nifty</p>
-13:52 < laberhorst> will this e another non comnpatible step?</p>
-13:53 < Myo9> Anyone knows what nntp servers are up?</p>
-13:53 < jrandom> laberhorst: no, 0.6 will be backwards compatible</p>
-13:53 < jrandom> Myo9: dunno, they might be up and just be bitten by the 0.5-0 bugs</p>
-13:54 < jrandom> the 0.5.0.1 rev should fix a lot of issues, and once its out, upgrading will be highly recommended</p>
-13:54 < laberhorst> so just built a test 0.6 and put it to testers</p>
-13:54 < cervantes> we can make BT traffic use only outdated routers...that will encourage people to upgrade ;-)</p>
-13:54 < laberhorst> so big upgrade party tomorrow</p>
-13:54 < jrandom> there'll be an announcement on the forum and the list when its ready</p>
-13:54 < jrandom> right laberhorst </p>
-13:54 < jrandom> heh cervantes ;)</p>
-13:55 < laberhorst> *being keen on testing for you*</p>
-13:55 < jrandom> BT performance has been pretty good on 0.5, I've seen lots of successful large file transfers on the trackers</p>
-13:55 < laberhorst> pload rate:    8.85 kB/s</p>
-13:55 < jrandom> (and irc hasn't been affected as it was before, beyond the problems we've been having with duck's tunnel)</p>
-13:55 < tracker> Depends on what you call large ;)</p>
-13:56 < jrandom> tracker: i'm thinking of a particular 874MB file that has a bunch of successful downloads ;)</p>
-13:56 < jrandom> but its true, thats small to some </p>
-13:56 < laberhorst> just good old porn</p>
-13:56 < laberhorst> i assume ;-)</p>
-13:57 < laberhorst> lets hope from tomorrow on, my router won't participate in >3000 tunnels</p>
-13:57 < tracker> Ok, that's large.</p>
-13:57 < laberhorst> or, if so, the network IS large</p>
-13:57 < jrandom> heh laberhorst </p>
-13:58 < jrandom> ok, anyone have anything else for the meeting?</p>
-13:58 < laberhorst> btw, if participate in >3000 a synonym for a good reliable router in i2p with fast connection?</p>
-13:58 <+detonate> i'm putting boondock saints up after i grab house tonight :)</p>
-13:59 <+detonate> that'll be a good 4.1gb :)</p>
-13:59  * laberhorst just wants to thank the developers for fast bug squashing</p>
-13:59 <+detonate> there seems to be lots of demand</p>
-13:59 < laberhorst> oh, some DVD images are here, to</p>
-13:59 < hobbs> detonate: ooh, right. House. :)</p>
-13:59 < tracker> cervantes, did you already upgrade to phpBB 2.0.12</p>
-13:59 < laberhorst> but wait till 0.5.0.1 is out</p>
-13:59 <+detonate> should give 0.5.0.1 a good shakedown too</p>
-14:00 <+detonate> yeah</p>
-14:00 <+detonate> i intend to</p>
-14:00 < jrandom> only people who already own legal copies of those files should download them, of course.  thats just for testing</p>
-14:00 < jrandom> *cough*</p>
-14:00 < tracker> rofl</p>
-14:01  * jrandom notes mpaa.i2p</p>
-14:01 <+detonate> heh</p>
-14:01 < laberhorst> oh, i can built iso images from debian, fedora, suse, pictures I made,...</p>
-14:01 < laberhorst> so a lot of legal material</p>
-14:01 < laberhorst> if you just want to test, /dev/random is VERY large</p>
-14:01 < Ragnarok> not always</p>
-14:02 < laberhorst> btw, for lonely weekends: cat /dev/random | grep linux :-)</p>
-14:02 < jrandom> heh</p>
-14:02 < frosk> /dev/random runs empty all the time, i prefer /dev/urandom :)</p>
-14:02 < frosk> or the new, improved /dev/jrandom</p>
-14:02 < jrandom> nah, that dumps core all the time</p>
-14:03 < jrandom> and needs its nightly rest</p>
-14:03 < Ragnarok> what's the best way to generate entropy for /dev/random?</p>
-14:03 < laberhorst> we should really built the "get jrandom a few beers" fund</p>
-14:03 < frosk> call it rest or entropy gathering :)</p>
-14:03 < hobbs> Ragnarok: Depends on what you really mean. Getting a hardware RNG would be more or less the "best" way :)</p>
-14:03 < jrandom> Ragnarok: depends on your OS (and whether you have hardware ;)</p>
-14:04 < tracker> dd if=/dev/urandom of=/dev/hda bs=1M count=4 Allways nice ;)</p>
-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</p>
-14:04 < Ragnarok> without hardware :P</p>
-14:04 < susi23> . o O ( I thought somebody using i2p knows why he should not use /dev/urandom )</p>
-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</p>
-14:05 < hobbs> susi23: when it's just for mischief, I think it's alright ;)</p>
-14:05 < ant> <Nolar> who here does the python BT port?</p>
-14:05 < jrandom> Nolar: that'd be duck</p>
-14:06  * duck whistles</p>
-14:06 < ant> <Nolar> duck:  why did you guys change the request block size to 128k ?</p>
-14:06 < susi23> . o O ( next one suggests: while true; do echo $RANDOM >> largefile; done )</p>
-14:06 < ant> <Nolar> that's why az cant seed to you</p>
-14:06 < tracker> cervantes: Ok</p>
-14:06 < ant> <Nolar> we block requests > 64k</p>
-14:06 < laberhorst> hell, i need more mp3</p>
-14:06 < frosk> susi23: for grepping for linux on an idle evening, /dev/urandom is just fine :)</p>
-14:07 < jrandom> ah, did you always?  iirc i2p-bt has used 128k for a while</p>
-14:08 < ant> <Nolar> yup, been there since the beginning :)</p>
-14:08 < ant> <Nolar> any reason 128 is used?</p>
-14:08 < ant> * duck looks through cvs log</p>
-14:08 < jrandom> keeps the pipeline filled, i2p has some lag ;)</p>
-14:08 < jrandom> with 32KB, thats essentially a fixed window size of 1</p>
-14:09 < jrandom> so each message blocks for an ACK, while 128KB allows 4 messages to fly in the rtt</p>
-14:09 <@duck> right, maximum allowed slice size according to the BT specs</p>
-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</p>
-14:09 < cervantes> i2pbt is a little snappier than it used to be...perhaps you can afford to reduce it...</p>
-14:10 <@duck> schni, schna, schnappi</p>
-14:10 < ant> <Nolar> so, instread of making a single 128k request, send out two 64k ones for example</p>
-14:10 < hobbs> duck: haha... that thing has gotten around the world.</p>
-14:10 <@duck> why do you block 128k?</p>
-14:11 < cervantes> *shudder* europop</p>
-14:11 < laberhorst> duck: pls. be quiet OR i shoot you down!</p>
-14:11 < tracker> Sometimes I regret that I learned german some years ago...</p>
-14:11 < laberhorst> no europop, really not POP</p>
-14:11  * cervantes orders the UK to repel borders before a song like that enters the charts</p>
-14:11 < laberhorst> tracker: don't care, its ok</p>
-14:12 < ant> <duck> its now (2^17)-13</p>
-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</p>
-14:12 < ant> <duck> 13 bytes being the bittorrent command length</p>
-14:12 < ant> <duck> would have no problem to (2^16)-13</p>
-14:12 < laberhorst> some music is really ridiculous, but real industrial music, boh, no</p>
-14:13 < ant> <duck> or go back to the default?</p>
-14:13 < jrandom> reducing it to 64KB seems the simplest (is that a cli param atm?)</p>
-14:13 < ant> <duck> --download_slice_size</p>
-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</p>
-14:14 < ant> <Nolar> rather than just pipelining multiplpe smaller requests?</p>
-14:14 < ant> <duck> I have no reason.</p>
-14:14 < tracker> laberhorst: Sometimes I catch some of the german channels via satellite. Especially viva and that "Theater Kanal" are really gruesome...</p>
-14:15 < ant> <Nolar> one problem with large blocks is that once i choke you, i still have to finish sending that 128k chunk</p>
-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 ;)</p>
-14:15 < ant> <Nolar> which can take a while</p>
-14:15 < laberhorst> tracker: viva is only interesting while "hard rock" time, all other times "please ignore", and theater, i don't know</p>
-14:15 < jrandom> with i2p, 128KB isn't really that large, since there's an inherent lag on the order of seconds</p>
-14:15 < ant> <Nolar> which can mess with the chunk/unchoke </p>
-14:16 <@duck> jrandom: does it still make sense to subtract the bittorrent 13 byte overhead so it fits in a sam message?</p>
-14:16 < jrandom> duck: nah, since the streaming lib already reduces it further into 16KB messages, so just have it be 64KB</p>
-14:17 <@duck> ok, 2**16 it is</p>
-14:17 < jrandom> (and then the tunnels break those 16KB messages into 996 byte fragments..)</p>
-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</p>
-14:18 < cervantes> wow that's almost as long as the lag on irc...</p>
-14:18 < jrandom> which is 1-10 RTTs (while on the normal net, 10-500)</p>
-14:18 <+detonate> i was all set to use 512K blocks</p>
-14:18 < ant> <Nolar> you might also experiment with pipelinng 16kb blocks</p>
-14:18 < jrandom> heh</p>
-14:18 <+detonate> so 64 is preferred?</p>
-14:19 < ant> <Nolar> all bt clients afiak use 16KB blocks</p>
-14:19 < ant> <duck> fixed in CVS;</p>
-14:19 < jrandom> wikked, thanks duck!  (and Nolar!)</p>
-14:19 < ant> <duck> expect it to appear in the 0.1.8 release together with some sam i2cp tuning</p>
-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 ;)</p>
-14:19 < jrandom> ok, heh, I just remembered we're still in a meeting</p>
-14:19 < jrandom> anyone else have anything for the meeting?</p>
-14:20 < ant> <Nolar> so if we want a 128k chunk, we just make 8 simult requests</p>
-14:20 < susi23> . o O ( and discard the 448 left bytes? )</p>
-14:20 < jrandom> right right</p>
-14:20 < laberhorst> tracker: oh, that is small side channel... arte or 3sat is really more interesting</p>
-14:20 < laberhorst> and arte is german/french :-)</p>
-14:20 < ant> <Nolar> if the uploader can fill such a request, all 128k should be pushed into the i2p pipe stream</p>
-14:20 < jrandom> cool</p>
-14:21 < cervantes> . o O ( wonders why he can hear everything susi is thinking )</p>
-14:21 < ant> <Nolar> so, it might be worth experimenting with 16KB vs 32KB vs 64KB blocks sizes</p>
-14:21 < jrandom> aye</p>
-14:21 < jrandom> as long as its pipelined, i2p doesnt care</p>
-14:21 < ant> <Nolar> great</p>
-14:22 < jrandom> the speed at 16KB without pipelines is pretty bad though, or at least it used to be</p>
-14:22 < tracker> laberhorst: Ok, I'll try if I can catch arte in the next days...</p>
-14:22 < ant> <duck> I suggest leaving this tweaking for 0.2</p>
-14:22 < ant> <duck> since it will include the bittorrent 3.9.1 improvements</p>
-14:22 < jrandom> yeah, DTSTTCPW</p>
-14:22 < susi23> . o O ( oh thats easy... people are so predictable... )</p>
-14:23 < ant> <duck> which might completely restructure the network code</p>
-14:23 < cervantes> http://www.gavelstore.com</p>
-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</p>
-14:24 < ant> <Nolar> ya, i can see how single 16kb requests would be slow</p>
-14:24  * jrandom downloads a gavel</p>
-14:24  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/130.rst b/i2p2www/meetings/130.rst
new file mode 100644
index 00000000..0596da60
--- /dev/null
+++ b/i2p2www/meetings/130.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 22, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/131.log b/i2p2www/meetings/131.log
index 2131d894..12515675 100644
--- a/i2p2www/meetings/131.log
+++ b/i2p2www/meetings/131.log
@@ -1,372 +1,366 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 131{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 1, 2005</h3>
-<div class="irclog">
-13:05 <@jrandom> 0) hi</p>
-13:05 <@jrandom> 1) 0.5.0.1</p>
-13:05 <@jrandom> 2) roadmap</p>
-13:05 <@jrandom> 3) addressbook editor and config</p>
-13:05 <@jrandom> 4) i2p-bt</p>
-13:05 <@jrandom> 5) ???</p>
-13:05 <@jrandom> 0) hi</p>
-13:05  * jrandom waves</p>
-13:05 <@duck> hi</p>
-13:05 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000616.html</p>
-13:05 < null> hi</p>
-13:05 <@jrandom> (yeah, i'm late this week, off with my head)</p>
-13:06 <@jrandom> while y'all speedreaders dig through that, perhaps we can jump into 1) 0.5.0.1</p>
-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</p>
-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)</p>
-13:07 <+ugha2p> Hi.</p>
-13:08 <+ugha2p> Does CVS HEAD fix that 100% CPU issue?</p>
-13:08 <@jrandom> yes, -7 should get the last remnants of it</p>
-13:08 <@duck> Does CVS HEAD fix that OOM issue?</p>
-13:08 <+detonate> hi</p>
-13:08 <@jrandom> no, the OOM is still being tracked down</p>
-13:09 <@jrandom> actually... is there a Connelly in the house?</p>
-13:09 < ant> <jrandom> nope</p>
-13:09 <@jrandom> bugger</p>
-13:09 <+ugha2p> jrandom must be going crazy, he is having a dialogue with himself.</p>
-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</p>
-13:10 <+detonate> just in time for the meeting</p>
-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?</p>
-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?</p>
-13:12 <+ugha2p> I downgraded back to 0.5.0.1 as a result.</p>
-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</p>
-13:13 <+detonate> was wondering if you knew why</p>
-13:14 <+detonate> the immediate one, obviously</p>
-13:14 <@jrandom> it could happen with 0.5.0.1, you just hadn't run into it.  </p>
-13:14 <@jrandom> (its not a common occurrence, and it only hits some people in odd situations)</p>
-13:14 <@jrandom> detonate: very long, as in, more than the usual 11-12 minutes?</p>
-13:14 <+ugha2p> Well, it hit me twice during a 8-hour period.</p>
-13:15 <+detonate> once all the participating tunnels are gone</p>
-13:15 <+ugha2p> jrandom: Is it supposed to use up all the CPU and lose all the leases until restarted when that bug occurs?</p>
-13:16 <@jrandom> ugha2p: thats a typical result from the bug, yes</p>
-13:16 <+detonate> hmm</p>
-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)</p>
-13:17 <+ugha2p> Must have been an extreme coincidence that it only happened to me while on 0.5.0.1-5.</p>
-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</p>
-13:18 < cervantes> it was a wonderous godsend</p>
-13:18 <+ugha2p> jrandom: I'll try out -7.</p>
-13:18 <@jrandom> cool</p>
-13:19 <+ugha2p> Although I'm already feeling guilty for giving a bumpy ride to the wiki users so far. :)</p>
-13:20 <+ugha2p> One more thing, have you documented the bulk/interactive tunnel types anywhere?</p>
-13:20 <+ugha2p> (Except for the source ;)</p>
-13:20 <@jrandom> in the changelog.  the only difference is a max window size of 1 message</p>
-13:20 <+ugha2p> Oh, okay.</p>
-13:21 <@jrandom> ok, anything else on 0.5.0.1, or shall we move on over to 2) roadmap?</p>
-13:21 <@duck> move on!</p>
-13:21 <@jrandom> consider us moved</p>
-13:22 <@jrandom> roadmap updated.  'n stuff.  see the page for details</p>
-13:22 < cervantes> eeh, duck ankle bites</p>
-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</p>
-13:23 <@jrandom> anyone have any questions/comments/concerns/frisbees?</p>
-13:23 <+detonate> have you heard from mule lately?</p>
-13:23 <+detonate> speaking of udp</p>
-13:24 <@jrandom> nope, he was fairly ill last i heard from 'im</p>
-13:24 <+detonate> :/</p>
-13:24 < jnymo> udp would kick ass</p>
-13:25 <@jrandom> s/would/will/</p>
-13:25 <@jrandom> hopefully he's off having fun instead though :)</p>
-13:25 <+ugha2p> jrandom: What kind of changes would the bandwidth and performance tuning include?</p>
-13:26 < jnymo> so, udp basically means connectionless.. which means.. bigger network, right</p>
-13:26 <+detonate> udp introduces all sorts of difficulties along with that</p>
-13:26 <@jrandom> ugha2p: batching the tunnel message fragments to fit better into the fixed 1024byte tunnel messages, adding per-pool bw throttles, etc</p>
-13:27 <+detonate> but yeah</p>
-13:27 <@jrandom> detonate: it won't be so bad, the token bucket scheme we have now can handle async requests without a problem</p>
-13:27 <@jrandom> (we just obviously wouldn't use the BandwidthLimitedOutputStream, but would ask the FIFOBandwidthLimiter to allocate K bytes)</p>
-13:27 <+ugha2p> Would the first one really make much difference? Per-pool throttling doesn't sound urgent.</p>
-13:28 <+detonate> that's good then</p>
-13:28 <@jrandom> ugha2p: likely, yes.  you can see the exact #s involved by going to /oldstats.jsp#tunnel.smallFragments</p>
-13:29 < bla> detonate: How's progress on the reassembly?</p>
-13:29 <+detonate> really stalled</p>
-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</p>
-13:30 <+ugha2p> jrandom: Ok.</p>
-13:30 <+ugha2p> Right.</p>
-13:31 <+detonate> i stopped working on it completely and started working on the addressbook-editor</p>
-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 </p>
-13:31 < jnymo> will upd mean people behind nats can get through now?</p>
-13:31 <@jrandom> some jnymo </p>
-13:31 < jnymo> and use i2p?</p>
-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</p>
-13:32 < jnymo> that'll be a boon</p>
-13:33 <+detonate> of course if anyone has suggestions on what to do, i'd appreciate them</p>
-13:33 <+ugha2p> jrandom: How would UDP help people behind NATs?</p>
-13:34 < bla> detonate: TCP (on the regular net) does reassembly. Can those concepts be carried over to the I2P UDP reassembly?</p>
-13:34 <+detonate> i haven't looked into how tcp does it</p>
-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</p>
-13:35 <@jrandom> bla: we'll certainly be using some level of UDP reassembly along tcp-SACK lines</p>
-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</p>
-13:35 <+detonate> saving the hassle</p>
-13:35 <@jrandom> no, there's substantial reason for why we do want both some reassembly/retransmission and not tcp</p>
-13:36 <+detonate> well, the threads thing</p>
-13:36 <@jrandom> the transport layer will not need to be fully reliable or ordered, just semireliable and unordered</p>
-13:37 <+ugha2p> Can we also expect a drop in memory usage because of fewer threads?</p>
-13:37 <@jrandom> yes</p>
-13:37 <+ugha2p> A significant drop</p>
-13:38 <+ugha2p> ?</p>
-13:38 <@jrandom> substantially.  (as well as a drop in memory usage, based off whatever the current OOM is coming from ;)</p>
-13:38 <+ugha2p> Right.</p>
-13:39 <@jrandom> ok, anything else on 2) roadmap?</p>
-13:39 < bla> jrandom: Yeah.</p>
-13:40 < bla> jrandom: Will detonate be doing the UDP stuff now? Or else, who will?</p>
-13:40 <@jrandom> its a team effort for all who can contribute :)</p>
-13:40 <+detonate> heh, i plan on working on udp stuff more, it's less boring than watching tv</p>
-13:41 <@jrandom> heh w3wt</p>
-13:41 < bla> jrandom: I understand. But for a moment it looked like detonate dropped the project ;)</p>
-13:42 <@jrandom> its on the roadmap, it will be done</p>
-13:42 <+detonate> sorry for the confusion</p>
-13:43 <@jrandom> ok anyone else have anything on 2) roadmap, or shall we mosey on over to 3) addressbook stuff?</p>
-13:44 <@jrandom> ok, detonate wanna give us an overview/status report on the editor?</p>
-13:45 < bla> detonate: (np)</p>
-13:45 <+detonate> ok</p>
-13:45 <+detonate> the current state of the editor is here:</p>
-13:45 <+detonate> http://detonate.i2p/addressbook-editor/current-state.html</p>
-13:45 <+detonate> it still doesn't do any actual editing</p>
-13:45 <+detonate> and currently i'm working on the table at the bottom</p>
-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</p>
-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</p>
-13:47 <+detonate> that's pretty much all</p>
-13:47 <@jrandom> w3wt</p>
-13:48 < bla> detonate: Looks good</p>
-13:49 <@jrandom> yeah, mos' def', I'm looking forward to a way to manage the entries /other/ than just hcaking the hosts file</p>
-13:49 <+detonate> thanks</p>
-13:49 <+detonate> that's the first time i've used jsp for anything</p>
-13:50 <@jrandom> cool</p>
-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</p>
-13:51 <@jrandom> smeghead: you 'round?  you seen this yet?</p>
-13:51 < jnymo> detonate: will there be collision detection and what not?</p>
-13:51 <@smeghead> actually i only hashed out some skeleton code on the addressbook console, nothing useful</p>
-13:51 <+detonate> yeah, i got tired of that, thank duck for suggesting the idea :)</p>
-13:51 <@smeghead> i got sidetracked on the TrustedUpdate thingy</p>
-13:52 <@jrandom> ah cool :)</p>
-13:53  * jrandom likes sidetracking to add new features </p>
-13:53 < bla> smeghead: You mean 1-click updates of I2P from _within_ I2P?</p>
-13:53 <@smeghead> so luck, not laziness (at least this time :)</p>
-13:53 < cervantes2p> bla: 2 click at least ;-)</p>
-13:54 <@jrandom> bah, we can get it down to 1 (reject if bad sig/invalid/etc ;)</p>
-13:54 <+detonate> yeah, there will be collision detection, that's currently what i'm working on</p>
-13:54 <@jrandom> detonate: doesnt the addressbook itself take care of that?</p>
-13:54 <@jrandom> detonate: i thought what you're doing just edited the files?  </p>
-13:55 <@jrandom> (the files will be uniq'ed by the addressbook)</p>
-13:55 <+detonate> i mean, showing you the collisions from the logs and handling that</p>
-13:55 <@jrandom> ah</p>
-13:55 <@jrandom> ok cool</p>
-13:55 <+detonate> i assume that's what jnymo is talking about</p>
-13:55 < Ragnarok> hm, is there anything I can do to make your life easier? :)</p>
-13:55 <+detonate> so you can say "replace entry" with the colliding one of your choice</p>
-13:55 <@jrandom> nice!</p>
-13:58 <@jrandom> Ragnarok: iirc detonate was able to parse out the logfile pretty easily.  do you forsee that format changing?</p>
-13:58 < jnymo> detonate: pretty much, yea</p>
-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?</p>
-13:59 <+detonate> yeah, don't change the format, that'll break everything</p>
-13:59 < Ragnarok> the format is highly unlikely to change</p>
-14:00 < Ragnarok> though more things may get logged in the future</p>
-14:00 <@jrandom> jnymo: the eepproxy doesn't have any hooks into detonate's editor atm, but we could add something down the road</p>
-14:00 <+detonate> although if you modified the Conflict lines, that would make them easier to parse</p>
-14:00 < cervantes2p> possibly something my firefox plugin could do</p>
-14:00 <+detonate> right now there are lots of human readable words that get in the way</p>
-14:00 < Ragnarok> modify how?</p>
-14:00 <@jrandom> (for instance, perhaps i2paddresshelper might redirect to an editor page)</p>
-14:00 < cervantes2p> "click here to add this to your addressbook"</p>
-14:00 < Ragnarok> ah...  I want to be nice to the humans, though</p>
-14:00 <+detonate> <date>=<host>=<source>=<new destination> would be superior</p>
-14:01 <@jrandom> cervantes2p: that going to work like google's page rewriter?  :)</p>
-14:01 <+detonate> well, that's what the addressbook-editor is for :)</p>
-14:01 <+detonate> it's really not an issue, i've got it covered</p>
-14:01 < cervantes2p> jrandom: nah...just have it in the link context menu</p>
-14:01 <@jrandom> ooOOoo</p>
-14:01 <+detonate> as long as nothing changes radically, things should keep working smoothly</p>
-14:02 < cervantes2p> of course I could add a rewriter...but that's just breaks people's page layouts ;-)</p>
-14:02 <+detonate> oh, one thing you could do</p>
-14:02 <+detonate> because it conflicts with what i do</p>
-14:02 <+detonate> make sure all the entries for the hostnames are all-lowercase</p>
-14:02 <+detonate> since Legion.i2p is in there</p>
-14:02 < cervantes2p> I do want to add a "non i2p link highlighter"</p>
-14:02 <+detonate> and i run them all through toLowercase()</p>
-14:02 <@jrandom> ah that'd be neat cervantes2p </p>
-14:03 <@jrandom> (be sure to only toLowercase the names, base64 is case sensitive ;)</p>
-14:03 <+detonate> yeah, only the names</p>
-14:04 < jnymo> context menu would be ideal</p>
-14:04 <@jrandom> (dont forget the flying ponies!)</p>
-14:04 < Ragnarok> I've made address comparisons non-case sensitive in my local branch... I should commit that...</p>
-14:04 <+detonate> /make all the hostnames lowercase</p>
-14:04 <+detonate>                 pair[0] = pair[0].toLowerCase();</p>
-14:05 <+detonate> there, in black and white</p>
-14:05 <+detonate> it just does the hostnames</p>
-14:05 <@jrandom> aye Ragnarok, give us the goods :)</p>
-14:05 < jnymo> why do i always feel i'm the one riding the flying ponies :(</p>
-14:06 <@jrandom> thats 'cause you're hoggin' 'em jnymo ;)</p>
-14:06 < cervantes2p> jnymo: don't discuss your domestic "arrangements" in a meeting</p>
-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)</p>
-14:07 < jnymo> heh</p>
-14:07 <+detonate> well, as soon as you can get it to work in jetty, you can put it in beta i think</p>
-14:07  * jnymo pulls out his p32-space-modulator</p>
-14:07 <@jrandom> it works in jetty</p>
-14:07 <+detonate> i have no idea how to get netbeans to precompile them and put them in the war</p>
-14:08 <+detonate> as long as people don't change the names of the files in config.txt, it should work hopefully without bugs</p>
-14:08 <@jrandom> ok, we can work you through ant to take care of things</p>
-14:08 <+detonate> ok</p>
-14:08 <+detonate> cool</p>
-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 ;-)</p>
-14:08 <@jrandom> heh</p>
-14:09 <@smeghead> detonate: i know a thing or two about ant, yell if ya get stuck</p>
-14:09 <+detonate> feel free to add it to your release</p>
-14:09 <+detonate> if you know how to do that</p>
-14:09 < MichElle> s/you don't need//</p>
-14:09 < Ragnarok> addressbook has a very simple build script, if you want to take a look at that</p>
-14:10 <+detonate> i need the section that precompiles jsps</p>
-14:10 <+detonate> that's missing from mine</p>
-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</p>
-14:10 <@jrandom> detonate: check out the precompilejsp targets in routerconsole, that'll get you started</p>
-14:10 <+detonate> and i need to figure out where to put -source 1.3 etc in</p>
-14:10 <@jrandom> (and the <war> task)</p>
-14:11 <+detonate> yeah, we can sort things out later this evening</p>
-14:11 <@jrandom> aye</p>
-14:11 < cervantes> yup that's how I managed it...and I don't know ANY java or jsp ;-)</p>
-14:11 <@jrandom> ok, if there's nothing more on 3) addressbook stuff, moving on to 4) bt stuff</p>
-14:12 <@jrandom> duck/smeghead: wanna give us an update?</p>
-14:12 <@duck> k</p>
-14:12 <@duck> last week we spoke with Nolar from Azureus about fixing some compatibility problems</p>
-14:12 <@duck> with the release of 0.1.8 as result</p>
-14:12 <@duck> this week has been mostly about communication</p>
-14:12 <@duck> with fellow developers, with forum admins and with users</p>
-14:13 <+detonate> does anyone know if the aznet plugin can host torrents again?</p>
-14:13 <@duck> the FAQ has been updated based on input from the forum, thanks for those who contributed</p>
-14:13 <@duck> also there has been some miscommunication and confusion</p>
-14:13 <@jrandom> detonate: word on the street is yes</p>
-14:13 <@duck> like legions spork</p>
-14:13 <+detonate> excellent</p>
-14:13 <@duck> I believe that changing the name of it will prevent further problems there</p>
-14:13 <@duck> .</p>
-14:14 <@jrandom> r0xor duck</p>
-14:14  * MichElle applauds duck</p>
-14:14 < MichElle> duck: you work very hard</p>
-14:14 < jnymo> yea, why not i2p-bt_extractor or some shit?</p>
-14:15 <@jrandom> any word on the later 0.2 stuff, or is that to be addressed after 0.5.0.2/etc?</p>
-14:15 <@smeghead> don't applaud yet, you don't know what we're naming it >;-}</p>
-14:15 <@jrandom> heh</p>
-14:15  * jnymo claps</p>
-14:15 <@duck> tell us!</p>
-14:15 <@jrandom> i2p-flying-pony-torrent</p>
-14:16 <+detonate> heh, are we hiding it now by changing the name?</p>
-14:16 < MichElle> again with the ponies</p>
-14:16 <@smeghead> it's top-secret for now, we don't want to get sued</p>
-14:16 < jnymo> what a debocle</p>
-14:17  * bla makes sign for MPAA: "Sue me, if you can..."</p>
-14:17 <@smeghead> duck and i have agreed 0.2 will be the first version with the new name</p>
-14:17 <+detonate> i2p-communism</p>
-14:17 <@duck> released spring 2006</p>
-14:17 <@jrandom> heh</p>
-14:17 <@duck> .</p>
-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</p>
-14:18 <@duck> been doing 8 hours of C++ pointer fixing</p>
-14:19 <@duck> so not much here either :)</p>
-14:19 <@jrandom> 'k but something we can perhaps look forward to along side 0.6 (or 0.5.1 if we're lucky?)</p>
-14:19 <@jrandom> yikes, fun fun fun</p>
-14:19 <@duck> before 2.0 atleast</p>
-14:19 <@smeghead> i'd estimate a month or so, just a wild guess, what do you think duck</p>
-14:19 <@duck> yeah</p>
-14:19 <@jrandom> cool</p>
-14:19 <@duck> ballpark</p>
-14:20 <@smeghead> the thing is we'd like to wait until the release of the official BT 4.0</p>
-14:20 <@jrandom> its ok, we know how schedules go ;)</p>
-14:20 <@smeghead> so we can sync 0.2 up-to-date with that</p>
-14:20 < MichElle> duck has many things on his plate, indeed</p>
-14:20 <@smeghead> 4.0 appears imminent</p>
-14:20 <@jrandom> ah, really smeghead?  cool</p>
-14:20 <@duck> smeghead: that is just the official excuse :)</p>
-14:20 < MichElle> but he is a hard worker</p>
-14:21 <@duck> I am for 5) ???</p>
-14:21 <@jrandom> almost there... </p>
-14:21 <@jrandom> legion: any updates on your bt client?  progress, etc?</p>
-14:21 <@smeghead> source code?</p>
-14:22 <@smeghead> (in a zip, not an .exe)</p>
-14:22 < cervantes> so the next wave of releases then</p>
-14:22 <@jrandom> hmm, legion seems to be idle, ok perhaps we can get an update later</p>
-14:22 < cervantes2p> damn huge lag</p>
-14:23 <@jrandom> so, movin' on over to 5) ???</p>
-14:23 < cervantes> *ahem* w00t</p>
-14:23 <@jrandom> cervantes2p: nah, you're just slow ;)</p>
-14:23 <@jrandom> ok, anyone else have anything to bring up?</p>
-14:23 < cervantes2p> I said those things like 5 minutes ago</p>
-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? :)</p>
-14:23  * cervantes2p feeds his router's hamster</p>
-14:24 <@jrandom> ah, yeah, prolly ugha2p </p>
-14:24  * jrandom has some sysadmin work i've been avoiding for a while (like, oh, moving things to the new srever...)</p>
-14:24 < MichElle> I have a concern</p>
-14:24 < MichElle> regarding transparency</p>
-14:24 <@jrandom> sup MichElle?</p>
-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</p>
-14:25 <+detonate> oh, i've noticed 190 routers, how close are we to the thread limit right now?</p>
-14:25  * jnymo wonders about other help people can do</p>
-14:25 < jnymo> (still looking into the php thing, duck ;)</p>
-14:25 <@jrandom> heh MichElle</p>
-14:25 < MichElle> his 'convenient' ability to work 24/7 on i2p is quite suspicious, indeed</p>
-14:25 < MichElle> anyway</p>
-14:25 < MichElle> that's all I wanted to say</p>
-14:25 < MichElle> keep your eyes on jrandom</p>
-14:26 < MichElle> his gentle and warm facade may be just that.</p>
-14:26 <+ugha2p> detonate: There are no theoretical thread limits, it will just consume all available resources until it crashes. :)</p>
-14:26 < jnymo> facade</p>
-14:26 <@jrandom> detonate: some OSes/ulimits may throttle @ 256, but win98 is already past the 100 TCP connections limit anyway</p>
-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 )</p>
-14:27 < jnymo> MichElle, if the source code is sound, then who cares?</p>
-14:27 <+detonate> oh, is the firefox plugin released?</p>
-14:27 < MichElle> jnymo: it ruins the mood a little</p>
-14:27 < cervantes2p> and I want to implement a downloader/install service that ties into smeghead's new updater verifier before I release</p>
-14:27 < ddd> hi channel</p>
-14:28 <+detonate> ok</p>
-14:28 <@jrandom> w0ah! kickass cervantes2p </p>
-14:28 <@jrandom> it looks really nice</p>
-14:28 <+detonate> hi ddd</p>
-14:28 < cervantes2p> but getting close now...probably another couple of weeks...</p>
-14:28 < MichElle> sort of like how running windows would still not be cool, even if microsoft open-sourced it</p>
-14:28 <+detonate> that plugin looks cool</p>
-14:28 < MichElle> back to the meeting, though ...</p>
-14:28 <@smeghead> TrustedUpdate may be done this week hopefully, before i move</p>
-14:28 <@jrandom> cool</p>
-14:29 < ddd> ?</p>
-14:29 < ddd> is i2p the only anonymous chat?</p>
-14:29 <@jrandom> hi ddd .  weekly dev meeting going on</p>
-14:30 < cervantes2p> 'lo ddd, we're just finishing a meeting...stick around we'll be done in a couple of minutes</p>
-14:30 < ddd> are there other projects like i2p?</p>
-14:30 <@smeghead> ddd: type /list then take your pick</p>
-14:30 < ddd> ok</p>
-14:30 < ddd> no i mean on other networks</p>
-14:30 <@jrandom> ok, anyone else have anything to bring up for 5) ???</p>
-14:30 <@smeghead> ddd: ask in #i2p-chat</p>
-14:30 < ddd> ok i let you guys finish</p>
-14:30 <+detonate> has anyone successfully run i2p in openbsd yet?</p>
-14:31 <@jrandom> ddd: http://www.i2p.net/how_networkcomparisons</p>
-14:31 < ddd> ok</p>
-14:31 <+detonate> i was thinking of starting that fiasco up again</p>
-14:31 <@jrandom> detonate: dunno</p>
-14:31 < jnymo> oh yea.. who was doing the bsd i2p distro, and which bsd was it?</p>
-14:31 <@jrandom> heh cool detonate, let us know how it goes</p>
-14:31 <@jrandom> jnymo: lioux packaged 'er up for fbsd</p>
-14:32 <@smeghead> i2p would never ship with openbsd :)</p>
-14:32 <+detonate> sure</p>
-14:32 < jnymo> woord..  wasn't someone going to do a i2p oriented distro?</p>
-14:32 <+detonate> yeah, there's a port in freebsd now</p>
-14:32 <+detonate> it's scary</p>
-14:32 <+detonate> heh, someone wanted to have a knoppix cd that ran i2p</p>
-14:32 <@jrandom> jnymo: after i2p is rock solid, it'd be worthwhile to explore packaging on distros/microdistros, yeah</p>
-14:32 <+detonate> who knows why</p>
-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</p>
-14:33 <@jrandom> detonate: netcafe</p>
-14:33 <+detonate> ah</p>
-14:34 <@jrandom> ok, anything else for the meeting?</p>
-14:34 < MichElle> what the fuck is an i2p 'oriented' distro</p>
-14:34 < MichElle> tor, i2p, and freenet ?</p>
-14:34 < MichElle> there is no purpose</p>
-14:34 < MichElle> the bandwidth requirements cancel the programmes out</p>
-14:34 < MichElle> is jrandom theo de raadt ?</p>
-14:34 < cervantes> a slightly camp distribution</p>
-14:34 < jnymo> a completely anonymized distro</p>
-14:35 < cervantes2p> jrandom: I guess not :)</p>
-14:35 < MichElle> jrandom: nothing</p>
-14:35  * jrandom winds up</p>
-14:35  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/131.rst b/i2p2www/meetings/131.rst
new file mode 100644
index 00000000..15817f45
--- /dev/null
+++ b/i2p2www/meetings/131.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 1, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/132.log b/i2p2www/meetings/132.log
index 60d3cd0d..ef6bbe62 100644
--- a/i2p2www/meetings/132.log
+++ b/i2p2www/meetings/132.log
@@ -1,365 +1,359 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 132{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 8, 2005</h3>
-<div class="irclog">
-13:06 <@jrandom> 0) hi</p>
-13:06 <@jrandom> 1) 0.5.0.2</p>
-13:06 <@jrandom> 2) mail.i2p updates</p>
-13:06 <@jrandom> 3) i2p-bt updates</p>
-13:06 < legion> so it's related to the irc servers?</p>
-13:06 <@jrandom> 4) ???</p>
-13:06 <@jrandom> 0) hi</p>
-13:06 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000633.html</p>
-13:07 < fedo> hi</p>
-13:07 <+postman> hi</p>
-13:07 < frosk> goodday</p>
-13:07 <@jrandom> legion: no, related to i2p bugs, being worked on</p>
-13:07 < bla> hi</p>
-13:07 < legion> ok</p>
-13:07 <@jrandom> speaking bugs being worked on, lets jump on in to 1) 0.5.0.2 :)</p>
-13:07 < cervantes> 'lo</p>
-13:07 < cervantes> -- Disconnected</p>
-13:08 <@jrandom> heh</p>
-13:08 < ant> <mihi> hi all</p>
-13:08 <@jrandom> 0.5.0.2 is out, and while your irc connection may lag at times, it'll recover ;)</p>
-13:08 <@jrandom> woah heya mihi</p>
-13:09 < cervantes> hey mihi</p>
-13:09 <@jrandom> the status notes give a general overview of where things are and the most immediate priorities</p>
-13:10 <@jrandom> the scary thing I'm trying to track down can be seen on http://localhost:7657/oldstats.jsp#router.invalidMessageTime</p>
-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 </p>
-13:10 <@jrandom> those numbers should be very very small, but they're not, unfortunately</p>
-13:10 <@jrandom> wikked bla </p>
-13:11 <@jrandom> yeah, the 0.5.0.2 is definitely an improvement, and everyone should upgrade ASAP </p>
-13:11 < bla> 375,932.22 in the last 10 minutes here....</p>
-13:11 <@jrandom> well, the particular value isn't really the problem, its their frequency</p>
-13:11 <@jrandom> (events per period)</p>
-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</p>
-13:12 <@jrandom> it may be the case that its something else though, but I'd like to rule it out</p>
-13:12 < bla> jrandom: I get about 200 per hour here</p>
-13:13 <@jrandom> bla: i've currently got 93 this hour, but peak count much higher (thousands)</p>
-13:13 <@jrandom> anyway, this particular stat is published in the netdb</p>
-13:13 < bla> jrandom: How about excluding 0.5-0 from the net in software when releasing 0.5.0.3?</p>
-13:14 <@jrandom> so we can all look around and see what values other people have ;)</p>
-13:14 <@duck> 309,854.24 peak 5,473,314.59</p>
-13:15 <@duck> pasting the wrong one,  huh</p>
-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</p>
-13:16 <@jrandom> duck: hard to have a nonintegral # of events ;)</p>
-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</p>
-13:16 <@jrandom> bla: aye, though it'd be great if people updated before then ;)</p>
-13:17 <@jrandom> (so for those reading at home: http://www.i2p.net/download is your friend ;)</p>
-13:17 < maestro^> jr: those numbers for router.invalidMessageTime deviations in ms?</p>
-13:17 <@jrandom> maestro^: yes</p>
-13:18 <@jrandom> (aka some really insanely skewed values)</p>
-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]</p>
-13:18 <@jrandom> yeah, y'all have been great about updating</p>
-13:18 < legion> So there is still a few people running 0.5 and many people running 0.5.0.1</p>
-13:18 < maestro^> so any idea where they might be lagging?</p>
-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?</p>
-13:19 <@jrandom> maestro^: many, many ideas for why 0.5 and 0.5.0.1 users are lagging.</p>
-13:19 <@jrandom> bla: similar</p>
-13:19 < maestro^> or is it clock drift on nodes?</p>
-13:20 <@jrandom> maestro^: clock skew, some serialization bugs, the 100% cpu bug</p>
-13:20 <@jrandom> ok, thats generally my focus atm, trying to get the message reliability back up</p>
-13:21 <@jrandom> anyone have any questions/comments/concerns on 0.5.0.2?</p>
-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...</p>
-13:21 <@jrandom> heh</p>
-13:21 <@jrandom> yeah, that wont talk to too many routers ;)</p>
-13:21  * postman got a backup copy of his last 0.4 installation :)</p>
-13:21 < ant> <mihi> question for me 'd be upgrade or delete.</p>
-13:22 <@jrandom> delete</p>
-13:22 <@jrandom> (backing up any destination keys)</p>
-13:22 <@jrandom> there is no upgrade procedure from pre-0.5 anymore</p>
-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?</p>
-13:22 <@jrandom> legion: that would segment the network</p>
-13:22 <@jrandom> people should juts upgrade.</p>
-13:23 <@jrandom> (and we should work around those that dont)</p>
-13:24 < legion> yeah until the people running outdated nodes updated ;)</p>
-13:24 <@jrandom> segmenting the network hurts us all, not just them</p>
-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?</p>
-13:25 <@jrandom> yeah, that'd certainly be pretty cool</p>
-13:25 <@jrandom> hopefully that can get tied in with the updater as well</p>
-13:26 < legion> yeah, I know, segmentation is bad...</p>
-13:26 <@jrandom> smeghead is working on some of the key components of that, though not sure if that includes the notification / download</p>
-13:26 <@jrandom> (so if anyone wants to help work on that, get in touch!)</p>
-13:27 <@jrandom> ok, movin' on to 2) mail.i2p updates</p>
-13:27 <@jrandom> postman: ping</p>
-13:27 <+postman> yes</p>
-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)</p>
-13:28  * postman takes over the mike</p>
-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.</p>
-13:28 <@jrandom> right bla</p>
-13:28 < ant> <Gatak> Oh, btw. Would I2P work behind nat even if you cannot open a port?</p>
-13:28 <@jrandom> Gatak: not yet.  some people will be able to at 0.6, others at 2.0</p>
-13:29 <@jrandom> legion: patches welcome</p>
-13:29 < ant> <Gatak> 2.0 heck, that is far on the future =)</p>
-13:29 <@jrandom> (http://www.i2p.net/roadmap#2.0 ;)</p>
-13:29 <+postman> erm, shall i start now?</p>
-13:29 < aum> morning all</p>
-13:30 <@jrandom> mic is all yours postman (sorry ;)</p>
-13:30 <@jrandom> 'lo aum, made it for the meeting</p>
-13:30 <@jrandom> (d'oh!  /me shuts up again)</p>
-13:30 < cervantes> Gatek: http://www.i2p.net/roadmap</p>
-13:30 <+postman> first, i wanted to say, that we reached 300 accounts registered at postman.i2p already</p>
-13:30 <@jrandom> w00t</p>
-13:30 <+postman> the number of mails from/to internet is growing steadily and once more proves that we need to move further</p>
-13:31 < cervantes> *squeeeel*</p>
-13:31 <+postman> after talking to jr some weeks ago we agreed upon the the release of v2mail together with I2P 1.0</p>
-13:31 <+postman> recent status is: the java based smtp proxy designed to run on every node is finished</p>
-13:31 <@jrandom> nice!</p>
-13:32 <+postman> the java based POP3 proxy is at 80% with just the maildir engine missing</p>
-13:32 <+postman> there will be a webmanager that needs some heavy tweaking still (15% done)</p>
-13:32 <+postman> the inter node communication is at 40% - we tested some datarecord exchanging with HTTP/XML</p>
-13:33 <+postman> seems to work quite well and fast even</p>
-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</p>
-13:33 <@jrandom> wikked</p>
-13:33 <+postman> i think we're quite n track</p>
-13:34 <+postman> one thing is noteable</p>
-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)?</p>
-13:34 < cervantes> cool</p>
-13:34 <+postman> bla: later</p>
-13:34 <+postman> in v2mail there will be a locally run webapp</p>
-13:34 <+postman> with this you can manager your local proxies AND apply for an "relayaccount"</p>
-13:35 <+postman> this relayaccount will then be used to associate your addess/domain to the relays</p>
-13:35 <+postman> the relays will sync the information automatically</p>
-13:35 <@jrandom> cool</p>
-13:35 <+postman> even features like the addressbook / public keys and stuff will work with the LOCAL interface</p>
-13:36 <+postman> so the idea is to have one centralized manager where you can do all your mailstuff</p>
-13:36 <+postman> relevant data is transferred to ONE of the relays and then being synced between the relays</p>
-13:36 <+postman> and this webbased manager will run on your very node</p>
-13:37 <+postman> when your node is online, the relays will deliver mails queued for your destination/domain/address</p>
-13:37 <+postman> it will be delivered to your local smtp proxy</p>
-13:37 <+postman> you can even trigger the whole thing with ETRN :)</p>
-13:37 < aum> hi again</p>
-13:37 < aum> i'd like to raise a discussion point in this meeting, if it's ok</p>
-13:37 <+postman> so much for the future folks :)</p>
-13:37 <+postman> .</p>
-13:38 <@jrandom> sound bitchin postman </p>
-13:38  * postman hands back the mike</p>
-13:38 <@jrandom> aum: great, should be some time at 4) </p>
-13:38 <+postman> yeah, iam ecstatic :)</p>
-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?</p>
-13:39 <+postman> yeah, the smtp proxy got a MDA</p>
-13:39 <+postman> and will deliver the mail into local maildirs</p>
-13:39 <+postman> even several accounts/users can be created locally</p>
-13:39 < cervantes> postman: will the relays keep track of your quotas etc and propogate such info between each other?</p>
-13:39 <+postman> and mapped to accounts of your domain</p>
-13:39 <+postman> cervantes: yes, they will</p>
-13:39 < septu_ssh> sorry, can I ask postman about payment/anti-spam mechanisms in the new model?</p>
-13:40 <+postman> septu_ssh: have you read any of the documents on the webpage?</p>
-13:40 <+postman> cervantes: it's not perfect real time</p>
-13:40 <+postman> cervantes: but i am fine with a few minutes update of quota information exchange</p>
-13:40 < septu_ssh> postman: in the queue for reading :/</p>
-13:40 < septu_ssh> but if it's doc'd, then it's fine</p>
-13:40 < cervantes> postman: yeah I figured</p>
-13:41 <+postman> septu_ssh: www.postman.i2p/inout.html</p>
-13:41 <+postman> septu_ssh: www.postman.i2p/mailv2.html</p>
-13:41 <+postman> cervantes: this is no drama really - the quota is a sane limit</p>
-13:41 < cervantes> postman: even someone being able to send  nrelays * quota recipients is no bad thing</p>
-13:41  * septu_ssh is bungle</p>
-13:41 <+postman> cervantes: yep</p>
-13:42 <+postman> the goal is just to stop anybody from really abusing the service</p>
-13:42 <+postman> in the tests i had 3 relays have been really fast </p>
-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?</p>
-13:42 <+postman> cervantes: within 10 secs they have been synced :)</p>
-13:43 <@jrandom> (or perhaps thats just for later)</p>
-13:43 <+postman> jrandom: the i2p mail relays will be operated by several ppl and are the preferred dests for routing mail</p>
-13:43 < cervantes> postman: you could introduce an exponential delay to the send queue</p>
-13:43 < cervantes> if it becomes an issue</p>
-13:43 <+postman> jrandom: so sending to other destinations could be handy under certain circumstances</p>
-13:44 <@jrandom> aye, though dangerous under others</p>
-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</p>
-13:44 <+postman> jrandom: but if a node's owner discloses his IMIO destination he could be spammed w/o control :)</p>
-13:44 <@jrandom> exactly</p>
-13:44 <@jrandom> otoh, same goes if the i2p mail relays are hostile</p>
-13:45 <+postman> jrandom: indeed, it's a WOT like construction</p>
-13:45 <@jrandom> </tinFoil></p>
-13:45 <+postman> jrandom: i cannot stop a relay operator from distributing a quota of 0 for your address</p>
-13:45 <@jrandom> 'k great.  yeah, no need to worry about it for now</p>
-13:45 <+postman> :)</p>
-13:46 <+postman> ok</p>
-13:46 <+postman> .</p>
-13:46 <@jrandom> ok cool, thanks for the update.  some really exciting stuff</p>
-13:46 <@jrandom> ok, swinging on to 3) i2p-bt updates</p>
-13:46 <@jrandom> duck: ping</p>
-13:46 <@duck> hi</p>
-13:47 <@duck> Yesterday BitTorren 4.0.0 was released</p>
-13:47 < ant> <dm> sounds german</p>
-13:47 <@duck> which we more or less waited for before starting on 0.2</p>
-13:47 <@duck> wrote a tasklist / todo: http://pastebin.ca/raw/7037</p>
-13:47 <@duck> (sorry my www is currently down)</p>
-13:48 <@jrandom> cool</p>
-13:48 < legion> what sort of timetable are we talking about for 0.2?</p>
-13:48 <@duck> the goal was 4 weeks</p>
-13:49 < legion> cool</p>
-13:49 <@duck> as you can see RawServer (the part that communicates with i2p) is the biggest task</p>
-13:50 <@duck> .</p>
-13:50 <@duck> a quick poll:</p>
-13:50 < legion> yeah, I'm well aware of that :)</p>
-13:50 <@duck> who is planning to create an i2p-bt fork?</p>
-13:50 <@jrandom> cool, is there anything people can do to help?</p>
-13:50 <@jrandom> heh</p>
-13:51 < ant> <dm> i</p>
-13:51  * jrandom grabs a spoon</p>
-13:51 < ant> <dm> m wiling to hepl</p>
-13:51 < legion> i</p>
-13:51 < ant> <dm> m gay</p>
-13:51 < legion> I'm working on a fork</p>
-13:52 <@duck> good, then I know who not to take serious.</p>
-13:52 <@duck> really, I think it is silly; pooling resources might get you much further</p>
-13:53 <@jrandom> or perhaps if there are better ways to go, you can convince duck to work that way?</p>
-13:53 < named> I'm going to write a fork in qbasic, please take me seriously.</p>
-13:53 <@duck> I'll try to have the process more open, so others can see what is planned etc</p>
-13:53 < ant> <dm> your openness is not swaying us. FORK! FORK! FORK! FORK!</p>
-13:53 <@duck> if you have any other suggestions</p>
-13:54 < ant> * dm raises legion onto his shoulders.</p>
-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 ;)</p>
-13:54 < ant> <dm> FORK! FORK! FORK! FORK!</p>
-13:54 <@jrandom> legion: what are you doing that duck wouldn't want to support?</p>
-13:55 <@duck> legion: congrats, if you google for 'i2p bittorrent', then an announcement of "Windows I2P Bittorrent Version 1.0" is #1</p>
-13:55 <@jrandom> jesus</p>
-13:56 < bla> jrandom: Yes?</p>
-13:56 <+postman> jrandom: yeah, they will rip this network's ass open soon :)</p>
-13:56 < bla> ;)</p>
-13:56 < named> 1.0? Damn, I'm using 0.1.8!</p>
-13:56 < Ragnarok> oy</p>
-13:57 < legion> omfg, really?! I cannot believe it... that's insane.</p>
-13:57 <@duck> anyway, I dont think that there is much new to say on this</p>
-13:57 < legion> my 1.0 release is based on 0.1.8 if you're running 0.1.8 you're fine.</p>
-13:58 <@jrandom> (and the 1.0 release is a .exe that no one has reviewed, ymmv)</p>
-13:58 < legion> I poorly named and numbered it sorry, again about that.</p>
-13:58 < ant> <dm> 1.0 >> 0.1.8</p>
-13:58 < ant> <dm> any day of the week</p>
-13:59 <@duck> slightly related:</p>
-13:59 <@jrandom> ok, anything else on 3) i2p-bt, or shall we move on to 4) ???</p>
-13:59 <+postman> legion: when there will be sourcecode downloadable?</p>
-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)</p>
-13:59  * jrandom sighs</p>
-13:59 <@duck> last month bram cohen held a talk about bittorrent on some university</p>
-14:00 <@duck> quite interesting: http://netnews.nctu.edu.tw/~gslin/tmp/050216-ee380-100.wmv.torrent</p>
-14:00 <@duck> (learned lessons about big p2p programs, plus some bittorrent details explained)</p>
-14:00 <@duck> .</p>
-14:01 <@jrandom> word</p>
-14:01 <@duck> postman: legion has released some sourcecode</p>
-14:01 < ant> <dm> is he the inventor of BT?</p>
-14:01 <@duck> but according to smeghead it isnt the same as the .exe</p>
-14:01 <@jrandom> dm: yes</p>
-14:01 < legion> There is a developer source you can download from http://legion.i2p/archives/Itorrent_1_x_Developer_Source.zip.bz2</p>
-14:02 <+postman> k, will have a look</p>
-14:02 < ant> <dm> is the exe a direct compile of that source?</p>
-14:03 < legion> though really the 1.0 source is really just 0.1.8 with a patch from smeghead, compiled and nicely packaged.</p>
-14:04  * cervantes walks over to 4)??? and waits for everyone to catch up</p>
-14:04 < ant> <dm> the question remains unanswered</p>
-14:04 < ant> <dm> Legion, did you or did you not, order a code red???</p>
-14:04 <@jrandom> *cough*</p>
-14:04 < legion> Perhaps we should get back on topic, my bt client discussion moved to #itorrent</p>
-14:05 <@jrandom> ok, 4) ???</p>
-14:05 <@jrandom> anything else people want to bring up?</p>
-14:05 <@jrandom> aum: you had something?</p>
-14:06 < ant> <dm> stasher is back?</p>
-14:06 < legion> I'm just seeing some funky behavior with 0.5.0.2 periods of heavy traffic...</p>
-14:06 < aum> yes</p>
-14:06 < aum> i'd like to raise the question of automated tunnel creation/management</p>
-14:07 < ant> <dm> go on</p>
-14:07 <+detonate> there's a null pointer exception in the systray thing in windows, i just noticed</p>
-14:07 < aum> it's 1337 that the web console now allows for humans to manually create/delete/manage tunnels</p>
-14:07 <@jrandom> detonate: could you toss 'er on the bugzilla?</p>
-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</p>
-14:08 <@jrandom> aum: no one disagrees.  we need it, and we will have it.  just not yet.</p>
-14:08 < ant> <dm> can't you do that through SAM?</p>
-14:08 < aum> i noticed on my recent return to i2p that the pysam library is no longer working</p>
-14:08 < septu_ssh> I have a quick question as well after aum</p>
-14:08 < aum> which was a disappointment</p>
-14:08 <@jrandom> the SAM protocol works, pysam doesnt</p>
-14:08 < Ragnarok> did it ever work?</p>
-14:09 < aum> correct</p>
-14:09 < aum> pysam used to work brilliantly</p>
-14:09 < legion> During such periods there are 1000+ tunnels my node is participating in and several seconds of lag and delay.</p>
-14:09 <@jrandom> legion: aye, the # of tunnels is because of older builds</p>
-14:09 < cervantes> ah mymodesty</p>
-14:09 < cervantes> eerm pymodesty</p>
-14:09 < aum> i'm presently writing a module 'i2ptunnel.py', which defines classes allowing easy tunnel management</p>
-14:10 < legion> so if older builds were not being connected to, the networking would be much smoother?</p>
-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</p>
-14:10 <@jrandom> legion: those tunnels aren't the problem</p>
-14:11 < aum> well, the class interfaces can remain even though the underlying mechanism changes</p>
-14:11 <@jrandom> 'k</p>
-14:11 < legion> aren't they?</p>
-14:12 < legion> When there a few tunnels, there is very little lag and delay...</p>
-14:12 < cervantes> legion: sorry aum is just raising some questions, if you hang fire a minute</p>
-14:12 < legion> it just seems odd to me.</p>
-14:13 < legion> ok</p>
-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?</p>
-14:13 <@jrandom> just so that there is always something that is using i2ptunnel.py, to stress it</p>
-14:13 < aum> we seem to be deadlocking</p>
-14:13 <+detonate> jrandom:sure</p>
-14:14 < ant> <dm> let's move on then</p>
-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</p>
-14:14 < septu_ssh> \o. - point to raise </p>
-14:14 < cervantes> realistically I can't imagine the tunnel interface will be revamped in the next couple of months though...</p>
-14:14 <@jrandom> but surely you see that we can add one trivially</p>
-14:14 < cervantes> so a stopgap solution is viable</p>
-14:15 < named_> Couldn't the web config have some kind of api that aum's program manipulates?</p>
-14:15 <@jrandom> named_: yes</p>
-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</p>
-14:16 <@jrandom> otherwise it'll just rot</p>
-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</p>
-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</p>
-14:17 <@jrandom> aye, the proxies do need a bunch of work, which i've been hiding from as much as possible :)</p>
-14:17 < aum> SAM is good for some situations, bad for others</p>
-14:17 < cervantes> but that's somewhat down the line...</p>
-14:17 < fedo> (</p>
-14:18 <@jrandom> aum: but as a stopgap, couldn't you just use one of the three available methods?</p>
-14:18 < cervantes> ie if the webinterface itself uses the api then there's no maintenance overhead</p>
-14:18 <@jrandom> right.  the web interface uses the TunnelControllerGroup</p>
-14:19 < aum> SAM usage gets difficult when one wants to use existing libs that are extensively dependent on standard TCP sockets</p>
-14:19 < aum> jrandom: the I2PTunnel CLI doesn't work for opening server tunnels, so i'm presently writing code for using TunnelControllerGroup</p>
-14:19 <@jrandom> aum: exising libs need to be carefully audited.  for instance, the gzip utility itself exposes sensitive data</p>
-14:19 < aum> coding as we speak</p>
-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</p>
-14:21 <@jrandom> ok, anyone else have anything to bring up?</p>
-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?</p>
-14:22 < mancom> a question concerning the roadmap: is 0.6 still scheduled for april?</p>
-14:22 <@jrandom> septu_ssh: non-routing data goes in the netDb over my dead body ;)</p>
-14:23 < septu_ssh> jrandom: not the same db</p>
-14:23 < septu_ssh> a different distributed db</p>
-14:23 < aum> jrandom: did you see my bug report? the CLI 'server' command /does not work/</p>
-14:23 < maestro^> septu_ssh: there isnt any i2p registrar</p>
-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?</p>
-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</p>
-14:26 <@jrandom> aum: i used it daily up through a few weeks ago, did you see my reply?</p>
-14:26 <@jrandom> maestro^: thats the plan</p>
-14:26 <@jrandom> er, mancom:</p>
-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?</p>
-14:26 < septu_ssh> the only reason why I suggest a 'registrar' is because collisions can take place otherwise</p>
-14:26 <@jrandom> septu_ssh: embrace collisions :)</p>
-14:26 <@jrandom> globally unique, human readable, distributed, and secure naming doesnt exist</p>
-14:27 < septu_ssh> it can also happen in host.txt if it is manually edited, but the problem remains the same</p>
-14:27 <@jrandom> drop the first parameter, and you're golden</p>
-14:27 < aum> jrandom: i did see your reply - and I /do/ have streaming.jar in my cp</p>
-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?</p>
-14:27 <@jrandom> ok cool, and it still comes back with that stacktrace aum?</p>
-14:28 < aum> yes</p>
-14:28 <@jrandom> septu_ssh: postman only acts as a central element for postman's outproxies and inproxies</p>
-14:28  * Ragnarok really need to get around to writing that addressbook doc...</p>
-14:28 < aum> this is when i manually run the cli, do a genkeys, then do a 'server' using the privkeyfile generated by genkeys</p>
-14:28 <@jrandom> septu_ssh: no one will trust anyone to manage a namespace.  censorship == exert presure on that registrar.</p>
-14:28 < maestro^> everyone is really their own registrar</p>
-14:29 < maestro^> you trust your friends and they trust you</p>
-14:29 < aum> oh shit, i picked up an old classpath</p>
-14:29  * aum tests again</p>
-14:30 < ant> <dm> ok, I'll be the registrar.</p>
-14:31 < ant> <dm> I'll be as unbiased as I can... cool?</p>
-14:31 < septu_ssh> hmmm, ok, back to the proverbial drawing board then...</p>
-14:31 <@jrandom> septu_ssh: a good place to review is http://zooko.com/distnames.html :)</p>
-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</p>
-14:33 < septu_ssh> hmmm, ok</p>
-14:33 <@jrandom> ok, anyone else have anything else to bring up for the meeting?</p>
-14:33 < cervantes> septu_ssh: http://forum.i2p.net/viewtopic.php?t=134</p>
-14:33 < aum> jrandom - ok, cli 'server' now works, but i never got a 'job number' for the tunnel</p>
-14:34 <@jrandom> hmm right, it runs forever</p>
-14:34 < aum> oh, i gotta do 'list' to get the job num</p>
-14:36 <@jrandom> ok cool, if there's nothing else...</p>
-14:36  * jrandom winds up</p>
-14:36  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/132.rst b/i2p2www/meetings/132.rst
new file mode 100644
index 00000000..ad2f8b32
--- /dev/null
+++ b/i2p2www/meetings/132.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 8, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/133.log b/i2p2www/meetings/133.log
index 43a70829..ced46f5b 100644
--- a/i2p2www/meetings/133.log
+++ b/i2p2www/meetings/133.log
@@ -1,323 +1,317 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 133{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 15, 2005</h3>
-<div class="irclog">
-13:07 < jrandom> 0) hi</p>
-13:07 < jrandom> 1) Net status</p>
-13:07 < jrandom> 2) Feedspace</p>
-13:07 < jrandom> 3) ???</p>
-13:07 < jrandom> 0) hi</p>
-13:07  * jrandom waves</p>
-13:07 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000649.html</p>
-13:08 < Teal> hi</p>
-13:08 < jrandom> (yeah, i was late this time, but close!)</p>
-13:08 < frosk> hi</p>
-13:08 < jrandom> might as well jump on in to 1) net status</p>
-13:08 < jrandom> the net, its, like, up, 'n stuff</p>
-13:09 < jrandom> overall throughput is still down where it was before, with a substantial number of dropped messages & fragments</p>
-13:09 < bla> hi</p>
-13:09 < ant> <dm> bad</p>
-13:09 < Teal> any clues as to why ?</p>
-13:10 < jrandom> Teal: sure, read the status notes?  :)</p>
-13:10 <+detonate> hi</p>
-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</p>
-13:11 < jrandom> in any case, we should be able to work around them, so having them here is actually helpful, i suppose</p>
-13:11 < jrandom> (though it'd be nice if they upgraded... ;)</p>
-13:11 < cervantes> (hi)</p>
-13:11 < frosk> those are probably sheeple who installed i2p because they read about it somewhere and wanted to try "anonymous p2p"</p>
-13:12 < ant> <BS314159> yeah, if network quality degradation can happen due to bugs, it's possible due to malice</p>
-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</p>
-13:12 < Pseudonym> do we know what specific probblems the old nodes are causing and why?</p>
-13:12 < jrandom> bs314159: never attribute to malice what can be attributed to jrandom writing bad code ;)</p>
-13:13 < jrandom> Pseudonym: yeah, see the changelog</p>
-13:13 < newkid> I run two nodes, milliseconds apart, and they don't regard eacxh other "fast" more of the time</p>
-13:13 < jrandom> right newkid </p>
-13:13 < jrandom> the speed calculator as deployed is, well, pretty shitty</p>
-13:13 < jrandom> it doesnt gather enough data to have any sort of confidence in the values</p>
-13:13 < bla> Hmm.. That's bad at best ;)</p>
-13:13 < jrandom> its about as meaningless as the "instantaneous rates" you can see on /oldconsole.jsp</p>
-13:14 < jrandom> i'm trying out some new calculators, and there is an improvement, but there are problems in the algorithm</p>
-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</p>
-13:15 < bla> jrandom: Does every node get "fastness" data for the other nodes directly ("P2P"), or via tunnels?</p>
-13:15 < jrandom> (aka the first K peers placed in the fast group will stay in the fast group)</p>
-13:15 < jrandom> bla: tunnels, we cannot trust direct measurement, as that'd allow trivial anonymity attacks</p>
-13:15 < godmode0> "alfYl6RvHzw="  =   "21538-900"</p>
-13:15 < godmode0> "alV9ye/y/Us="  =  "23565-200"</p>
-13:15 < godmode0> its is sha1 ?</p>
-13:15 < jrandom> (e.g. be really really slow to everyone except Alice)</p>
-13:15 <+detonate> they'll stay there for the lifetime of the router?</p>
-13:15 < jrandom> godmode0: we're in a meeting right now</p>
-13:16 < godmode0> ops sorry</p>
-13:16 < jrandom> detonate: until one of them failed or rejected a tunnel (aka their capacity rank drops them from the high capacity group)</p>
-13:16 <+detonate> ok</p>
-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. </p>
-13:17 < jrandom> i've been toying with some ideas to get more data, but haven't updated it yet</p>
-13:17 < bla> In terms of load, that is.</p>
-13:18 < jrandom> well, one of the critical points certainly is when the network load exceeds the network capacity</p>
-13:18 < jrandom> i believe our capacity calculators can handle that though</p>
-13:18 < cervantes> jrandom: is -3 actually employing this fast peer selection method?</p>
-13:18 <+polecat> Hopefully since data transfer between peers has fairness controls, there won't be any way to increase load too much...</p>
-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))</p>
-13:19 < jrandom> cervantes: yeah, but as i said, it doesn't allow promoting peers between fast and high capacity</p>
-13:19 < jrandom> polecat: fairness controls?</p>
-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) ;-)</p>
-13:20 < cervantes> s/live web/outerweb</p>
-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'</p>
-13:20 <@smeghead> it would seem i2pProxy.pac is dangerous even for its creator :)</p>
-13:20 < jrandom> heh nice cervantes :)</p>
-13:20 < jrandom> lol</p>
-13:20 < cervantes> so it certainly seems to have improved things on my home node which was really suffering before</p>
-13:21 < ant> <BS314159> jrandom: can you randomize it?</p>
-13:21 < cervantes> smeghead: hehe hell I don't use that! you think I'm mad!</p>
-13:21 < ant> <BS314159> i.e. create a spontaneous transition rate?</p>
-13:21 < jrandom> BS314159: we use the tiers, and randomize within the tiers</p>
-13:22 < jrandom> BS314159: spontaneous rates are essentially what we have now, which fluctuate widely</p>
-13:22 < jrandom> (we == 0.5.0.2-0)</p>
-13:22 < ant> <BS314159> I think I don't understand the problem. nm.</p>
-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</p>
-13:23 < bla> jrandom: In any case, finding out a couple of good nodes looks an awful lot like an ant-colony optimization thing</p>
-13:24 < bla> jrandom: Because once you've got fast peers, you're likely to use _those_ to find out who else is fast.</p>
-13:24 < jrandom> would you propose further active probing along those lines?</p>
-13:24 < jrandom> ah, actualy, thats not true</p>
-13:25 < jrandom> thats the difference between client tunnels and exploratory tunnels</p>
-13:25 < bla> jrandom: And thus, it seems you'd essentially be doing a greedy optimization scheme (much like ant-colony)</p>
-13:25 < jrandom> client tunnels are built with fast peers, exploratory tunnels are built with any non-failing peer</p>
-13:25 < jrandom> (chosen randomly)</p>
-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</p>
-13:26 < jrandom> otoh, there may be something in that vein to help optimize the peer selection</p>
-13:26 < jrandom> oh, right, certainly you'd get better performance by using the fast peers, but then you wouldn't be exploring :)</p>
-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</p>
-13:27 < bla> jrandom: I see, so effectively, you use random expl. tunnels to prevent falling into local optima?</p>
-13:27 < jrandom> so the actual throughput of the exploratory tunnels doesnt matter (as long as the data gets through, eventually)</p>
-13:27 < jrandom> aye</p>
-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?</p>
-13:29 < jrandom> definitely bla, and at the moment, we don't yet harvest that data within the speed selection</p>
-13:29 < bla> jrandom: i.e. as an aux. way to get more data on peers</p>
-13:30 < jrandom> some of it we can, though some of it will be harder to grab (since the streaming lib is external)</p>
-13:30 < jrandom> we should definitely grab what we can though to get more confidence</p>
-13:30 < ant> <BS314159> won't that depend on the slowest link in any tunnel?</p>
-13:31 < ant> <BS314159> making it very difficult to use for hops>0?</p>
-13:31 < jrandom> BS314159: yeah, but it'll average out, as peers are selected randomly within the fast tier</p>
-13:31 < jrandom> same goes for any remote measurement</p>
-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</p>
-13:34 < jrandom> anyone have anything else to bring up for 1) Net status?</p>
-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...</p>
-13:35 < jrandom> bla: its certainly important, but remember, we don't need optimal peer selection.  merely sufficient</p>
-13:35 < ant> <aum> morning folks</p>
-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</p>
-13:36 < jrandom> 'mornin aum, in time for the meeting :)</p>
-13:36 < bla> jrandom: I see. Thnx for the explaination!</p>
-13:36 < jrandom> of course, you're right in that it'd be kickass if we /could/ find the optimal peer selection ;)</p>
-13:37 < jrandom> and there is definitely lots of room for some students to work out some ideas and write up some papers</p>
-13:37 < frosk> this would be a cool thesis project :)</p>
-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? :)</p>
-13:38 < jrandom> detonate: manual peer selection is a PITA, since fast peers get congested occationally, asking you to back off, etc.  </p>
-13:38 <+detonate> ah</p>
-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</p>
-13:39 <+detonate> alright</p>
-13:40 < Teal> Victory at any cost!</p>
-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 ;)</p>
-13:40 < jrandom> ok, thats 'bout it for 1), now lets swing on to 2) Feedspace</p>
-13:41  * jrandom hands the mic to frosk </p>
-13:41 < frosk> oh, ok, hi</p>
-13:42 < Myo9> Hi Frosk.</p>
-13:42  * jrandom gets out the high intensity spotlight</p>
-13:42 < frosk> so, everyone should check out http://feedspace.i2p (keys at orion or jrandom's blog)</p>
-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</p>
-13:42 < frosk> also, http://feedspace.i2p/wiki/CallForComments has a fresh rev of the feedspace document :)</p>
-13:43 < frosk> hi Myo9</p>
-13:43 < frosk> oh yeah, feedspace is our new (and final) name for what used to be known as i2pcontent or fusenet :)</p>
-13:43 < jrandom> r0x0r</p>
-13:43 < frosk> as the status notes notes, we are still very interested in feedback on the general design of everything</p>
-13:44 < frosk> nobody should be shy about challenging it :)</p>
-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</p>
-13:45 < frosk> we're on a pretty tight schedule and none of us are full-time developers on the project unfortunately</p>
-13:45 < frosk> so that's pretty much it, i think. questions? :)</p>
-13:45 < ant> * aum can't reach orion.i2p or jrandom's blog, so can't reach feedspace.i2p</p>
-13:46 < frosk> hm yes, the web site also has a roadmap, but the dates there _will_ change :)</p>
-13:46 < legion> feedspace.i2p=KuW5sR2iGCfnnuwdslHbFsNyNCsoZnoIwAmHeypOV-s8OQxokBpdNazksBrhoQum9nv81vprl6k15Mhcd~KWE4OajjmdU7v2fjqps7QK3KmLv4UTrX-ihSIUdhb5B9FLh2XEFEQ4-8guFTVxBRqQQE~c058AL6~uZpuFpLtEOg0HEZ6BydndOhx-FCDm8ip12pPwZ3a5O86l1UoATZBXxoctGafTjnUlx64jyQs6y0WB811l36wVrc~~dqEcanxab0yfg8dJ~1M4EUNrXcHT-PwYYrr3GgpimuF4oUtYjkeDKlq5WjfMAa8bE73HFgquxq99fuW5aI1JbLPxnTLHi00-2On0dSDwJxSP08HOhKFKMNzykI9Asg8CywzNO6kWpbX9yaML36ohCJF0iaLvvDyhS4a2B65crSJRJPVkbxIvsyyUyYMGi31EK593ijOLjOvug</p>
-13:46 < legion> there you go aum</p>
-13:46  * jrandom just added feedspace to http://dev.i2p.net/i2p/hosts.txt</p>
-13:46 < jrandom> (and cvs)</p>
-13:46  * frosk goes temporarily blind</p>
-13:46 < jrandom> legion: never paste as a single line, its too large to fit</p>
-13:47 < ant> <aum> thx</p>
-13:47 < frosk> jrandom can probably commit the key into his hosts.txt maybe? :)</p>
-13:47 < jrandom> aye, 'tis on there now, forgot to :)</p>
-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</p>
-13:49 < jrandom> heh wikked</p>
-13:49 < frosk> s/out/ready for real-world testing/</p>
-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 ;)</p>
-13:49 < ant> <BS314159> since I can't reach feedspace.i2p, I'll ask a basic question</p>
-13:50 < ant> <aum> that key is not correct, only 441 chars</p>
-13:50 < jrandom> right aum, irc trims it, snag http://dev.i2p.net/i2p/hosts.txt</p>
-13:51 <+detonate> frosk: i have a suggestion for the meantime</p>
-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 :)</p>
-13:51 < legion> ah sorry, about that. Anyways I've already commited it to my hosts.txt also.</p>
-13:51 < ant> <aum> thx jrandom</p>
-13:51 < ant> <BS314159> which of the following systems do you see feedspace supplanting: usenet, gnutella, google, livejournal, www</p>
-13:52 < jrandom> , the church</p>
-13:52 < jrandom> er..</p>
-13:52 < cervantes> jrandom: ah you caught me mid commit of hosts</p>
-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</p>
-13:53 < ant> * aum turns off throttling within routerConsole, and sees if that helps</p>
-13:54 < frosk> BS314159: we will support blogs, forums, and shared address books (for the first version, other applications are possible)</p>
-13:54 < frosk> it doesn't replace web pages per se</p>
-13:54 < frosk> but it certainly could be used for "file sharing"</p>
-13:54 <+detonate> content syndication then?</p>
-13:54 < jrandom> it'd probably supplant static web content though, allowing persistent web publication for people who cannot run eepsites</p>
-13:54 < frosk> that's what it's about</p>
-13:55 < jrandom> (two word summary: usenet+SSK)</p>
-13:55 < frosk> yeah</p>
-13:55 < ant> <BS314159> ok</p>
-13:55 < Ragnarok> not that persistent</p>
-13:56 < jrandom> Ragnarok: depends on syndicator policy, true</p>
-13:56 <+detonate> is anything happening with stasher?</p>
-13:56 < frosk> it can be as persistant as the most eager syndicator :)</p>
-13:56 < jrandom> (see: dejanews ;)</p>
-13:56 < ant> <aum> detonate: stasher is on hold, writing a whole new thing called quartermaster</p>
-13:57 <+detonate> i see</p>
-13:58 < jrandom> frosk: what can we do to help?</p>
-13:59 < jrandom> should people register & hack on the wiki, email, post on the forum?</p>
-13:59 < jrandom> oh, perhaps we can get cervantes to add a new forum category?</p>
-13:59 < frosk> i think actually a forum would be very nice at this point</p>
-14:00 < frosk> for more private discussion, you can email us both at ku@mail.i2p and frosk@mail.i2p</p>
-14:01 < cervantes> hrrrm ... are you going to put game reviews in it?</p>
-14:01 < jrandom> heh</p>
-14:01 < jrandom> w3rd</p>
-14:01 < cervantes> because if not...then you're welcome to have a new forum section</p>
-14:01 < frosk> i was thinking top20 music reviews, cervantes</p>
-14:02 < jrandom> (btw, mirror of the call for comments @ http://dev.i2p.net/~jrandom/feedspace.txt)</p>
-14:02 < cervantes> :)</p>
-14:04 < cervantes> frosk: feedspace or feed space or Feedspace or Feed Space or FeedSpace?</p>
-14:04 < frosk> cervantes: Feedspace</p>
-14:05 < frosk> looking forward to much discussion over at the forum then :) i don't have anything else for this point, anyone else?</p>
-14:05 < jrandom> ok cool, thanks for the update frosk </p>
-14:06 <@smeghead> or FEeDspace?</p>
-14:06 < ant> <cervantes> frosk: when you have a moment, just pm me a one liner description for the forum section</p>
-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. ;)</p>
-14:06 < jrandom> cool legion </p>
-14:06 < jrandom> that actually brings us into 3) ??? nicely</p>
-14:06 < jrandom> anyone have anything else to bring up? </p>
-14:06 < jrandom> aum: any updates on Q?</p>
-14:07 < frosk> i, uhm, no</p>
-14:07 < ant> <aum> Q devlt is moving along nicely, nothing to announce atm</p>
-14:07 < jrandom> w3rd</p>
-14:07 < ant> * aum is 90% complete with net.i2p.i2ptunnel.I2PTunnelXMLServer</p>
-14:07 < ant> <BS314159> I have a simple question about netDb</p>
-14:07 < ant> <aum> everything's working now except 'i2p.tunnel.close'</p>
-14:07 < legion> my forums will allow for members to have decent sized avatars, discuss shared content, just about whatever.</p>
-14:08 < jrandom> wikked</p>
-14:08 < ant> <BS314159> it says on the page that entries are stores on the peers closest to SHA256(router identity + YYYYMMdd)</p>
-14:08 < jrandom> right BSpi</p>
-14:08 <@smeghead> legion: will it be as much a security hazard as your bt client?</p>
-14:08 < ant> <BS314159> does this mean there's a burst of traffic every 00:00 GMT?</p>
-14:08 < ant> * aum is actually gaining some fluency in java, having attained a 'cognitive critical mass'</p>
-14:09 < jrandom> BS: data points expire more frequently than they migrate</p>
-14:09 < jrandom> a LeaseSet is only good for 10 minutes, for example</p>
-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?</p>
-14:09 < legion> lol, forums a security hazard?</p>
-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</p>
-14:10 < jrandom> bla: yeah, java -cp lib/i2p.jar:lib/router.jar -Djava.library.path=. net.i2p.router.peermanager.ProfileOrganizer peerProfiles/*</p>
-14:10 < jrandom> (i think)</p>
-14:10 < legion> oh and the next release of my bt client shouldn't cause such issues...</p>
-14:10 < jrandom> you may need to add some log levels to logger.config, lemmie check</p>
-14:10 <@smeghead> legion: Cervantes made a ton of modifications to phpBB to lock it down for i2p use</p>
-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</p>
-14:11 < jrandom> nah, it dumps to stdout</p>
-14:11 < frosk> jrandom: how do you feel about the i2p roadmap currently, if one may ask? do you think it's realistic?</p>
-14:11 < legion> Hmm I wonder if I can get a copy of cervantes mods?</p>
-14:11 < jrandom> frosk: i update it when i become uncomfortable with it</p>
-14:12 < frosk> ok</p>
-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</p>
-14:12 < legion> Otherwise I'll just have to continue to hack on the phpbb source myself...</p>
-14:12 < jrandom> BS: peers would only look in the wrong place for up to 30s, due to clock synchronization</p>
-14:12 <@smeghead> legion: have fun</p>
-14:12 < legion> well why would anyone get and use kazaa?</p>
-14:13 < bla> jrandom: I'm asking, because...</p>
-14:13 < legion> Or morpheus?</p>
-14:13 < jrandom> (because they dont know better?)</p>
-14:13 < legion> Both of those contain adware/etc...</p>
-14:13 <+detonate> they are ignorant?</p>
-14:14 < legion> yeah and there are millions of ignorant users out there. ;)</p>
-14:14 < ant> <BS314159> legion: you sound like you want to bundle spyware with I2P.  Truly, a stroke of genius.</p>
-14:14 < bla> jrandom: ...I browsed SpeedCalculator.java and CapacityCalculator.java, and I'd like to experiment with the estimators</p>
-14:14 < cervantes> legion: stay uptodate with official patches, and put htaccess on the admin areas</p>
-14:14 < jrandom> wikked bla</p>
-14:14 < legion> What? Heck no... I hate malware...</p>
-14:14 < cervantes> most of my mods involve spam prevention</p>
-14:14 < ant> <aum> can i raise a more critical issue?</p>
-14:14 < legion> That's it? cervantes?</p>
-14:15 < jrandom> sup aum?</p>
-14:15 <@smeghead> legion: what about your users that also hate malware? why do you do nothing to alleviate any concerns they might have?</p>
-14:15 < ant> <dm> BS314159: are you a windows hotfix?</p>
-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</p>
-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:...</p>
-14:15 < jrandom> aum: see the weekly status notes</p>
-14:16 < cervantes> legion: rename all registration, login , posting and profile editing pages to something non-standard </p>
-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.</p>
-14:16 < cervantes> will help keep worms at bay</p>
-14:16 < jrandom> bla: aye, i read that timing paper, and yesterday's tor attack paper with much interest</p>
-14:17 < Myo9> Cervantes, releasing ant of your mods?</p>
-14:17 < Myo9> s/ant/any/</p>
-14:17 < jrandom> there is worry along those lines in the capacity calculator with the different tiers of rejection</p>
-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)</p>
-14:18 < legion> thanks for the advice cervantes :)</p>
-14:18 < bla> jrandom: Now, I happen to know some ppl that know a lot about Bayesian Belief Networks... ;))</p>
-14:18 <@smeghead> again, legion ignores the question</p>
-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.</p>
-14:18 < jrandom> hmm, what do you mean by distance bla?</p>
-14:18 < ant> <dm> what is legion up to?</p>
-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)</p>
-14:19 < jrandom> wikked</p>
-14:19 < jrandom> suggestions as to how we can best select 'quality' peers are very much welcome</p>
-14:19 < cervantes> Myo9: I certainly could do.</p>
-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.</p>
-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</p>
-14:20 < ant> <aum> frosk: what lang you writing feedspace in? (forgive me if i asked you before)</p>
-14:20 < cervantes> it's not a clean "patch" or anything though</p>
-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</p>
-14:20 < frosk> aum: java (and i forgive you ;)</p>
-14:20 < cervantes> I've just been fixing stuff andproblems as it arises</p>
-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</p>
-14:20 < cervantes> as they</p>
-14:20 < jrandom> bla: its very hard to tell whether lag or congestion occurs @ X or Y (or earlier hops)</p>
-14:20 < cervantes> http://forum.i2p/index.php?c=4</p>
-14:21 < cervantes> new section: Feedspace</p>
-14:21 < jrandom> w00t</p>
-14:21 < frosk> yay</p>
-14:22 < legion> anyways enough discussion about my release, any further discussion about it should be done in the #itorrent channel</p>
-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</p>
-14:22 <@smeghead> legion: we can discuss in meeting point # 3) any business that affects i2p</p>
-14:23 <@smeghead> legion: and i think your software is of serious concern and warrants a warning to users</p>
-14:23 < legion> yeah, ok</p>
-14:23 < jrandom> bla: certainly, we just need to rope in the RTT from the OutboundClientMessageOneShotJob</p>
-14:23 < jrandom> (and then figure out how best to calculate & decay the data)</p>
-14:24 < legion> So smeghead if you were to make such a release, what would you do differently?</p>
-14:24 <@smeghead> legion: the way you continually dodge questions and try to defer discussion on the subject is very disconcerting</p>
-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</p>
-14:25 < bla> jrandom: What does the RTT signify there?</p>
-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</p>
-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</p>
-14:28 < bla> jrandom: (yes)</p>
-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</p>
-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</p>
-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</p>
-14:30 <+detonate> indeed</p>
-14:30 <@smeghead> *suspicion</p>
-14:31 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-14:31 < ant> <drakoh> hi people ! wanted to know, is there anything special with the network ?</p>
-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</p>
-14:32 < jrandom> drakoh: see the weekly status notes</p>
-14:32 < bla> quit</p>
-14:32 < ant> <drakoh> no I mean something strange ...</p>
-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</p>
-14:32 < ant> <drakoh> like I lost all my peers</p>
-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.</p>
-14:33 < jrandom> drakoh: ok, hold on, we can debug that once the meeting is over</p>
-14:33 < ant> <drakoh> woops sorry</p>
-14:33 < jrandom> ok, speaking of the meeting being over...</p>
-14:34  * jrandom winds up</p>
-14:34  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/133.rst b/i2p2www/meetings/133.rst
new file mode 100644
index 00000000..e3a40e52
--- /dev/null
+++ b/i2p2www/meetings/133.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 15, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/134.log b/i2p2www/meetings/134.log
index 62dfb1b5..37cbc49e 100644
--- a/i2p2www/meetings/134.log
+++ b/i2p2www/meetings/134.log
@@ -1,177 +1,171 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 134{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 22, 2005</h3>
-<div class="irclog">
-13:01 <@jrandom> 0) hi</p>
-13:01 <@jrandom> 1) 0.5.0.3</p>
-13:01 <@jrandom> 2) batching</p>
-13:01 <@jrandom> 3) updating</p>
-13:01 <@jrandom> 4) ???</p>
-13:01 <@jrandom> 0) hi</p>
-13:01  * jrandom waves</p>
-13:01 <@jrandom> the just-now-posted weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-March/000654.html</p>
-13:02 <+detonate> hi</p>
-13:02 <+cervantes> 'lo</p>
-13:02 <@jrandom> jumpin' right in to 1) 0.5.0.3</p>
-13:02 <@jrandom> the release came out a few days ago, and reports have been positive</p>
-13:02 <+cervantes> jrandom: let us know when the blue dancing dwarves climb onto your monitor and we'll stop the meeting early</p>
-13:03 <@jrandom> heh cervantes </p>
-13:03 <@jrandom> (thank Bob for editable meeting logs ;)</p>
-13:04 <@jrandom> i dont really have much to add wrt 0.5.0.3 than whats in that message</p>
-13:04 <@jrandom> anyone have any comments/questions/concerns on it?</p>
-13:04 < bla> jrandom: Any new measurements on the fast-peers-selection code?</p>
-13:05 <@jrandom> ah, i knew there was something else in 0.5.0.3 that i had neglected ;)</p>
-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)</p>
-13:07 < bla> jrandom: Sometimes, eepsites still require a number of retries to find a good tunnel to use</p>
-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)</p>
-13:08 <+ant> <Connelly> oops there's a meeting</p>
-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</p>
-13:09 <@jrandom> what i've seen on the net though is some not-infrequent-enough transport layer delay spikes</p>
-13:10 <@jrandom> e.g. taking 5-20+ seconds just to flush a 1-2KB message through a socket</p>
-13:10 <@jrandom> tie that up with a 5 hop path (2 hop tunnels) and you can run into trouble</p>
-13:11 <@jrandom> thats actually part of whats driving the batching code - reducing the # of messages to be sent</p>
-13:13 <@jrandom> ok, anyone else have any questions/comments/concerns on 0.5.0.3?</p>
-13:13 < bla> jrandom: Looks good. I will ask more about it in the next "section"</p>
-13:14 <@jrandom> w3rd, ok, perhaps we can move on there then - 2) batching</p>
-13:15 <@jrandom> the email and my blog (jrandom.dev.i2p</spam>) should describe the basics of whats planned</p>
-13:15 <@jrandom> and, well, really its some pretty basic stuff</p>
-13:15 <@jrandom> the current preprocessor we have was the simplest possible one to implement (class name: TrivialPreprocessor) ;)</p>
-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)</p>
-13:17 <@jrandom> that's about all i have to add on that though - any questions/comments/concerns?  </p>
-13:18 < bla> Does this require all participating nodes to run the new preprocessor, or can a mix of Trivial/NewOne coexist?</p>
-13:18 <+Ragnarok> this will add .5 s to latency, right?</p>
-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</p>
-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</p>
-13:20 <+Ragnarok> cool</p>
-13:20 <+Ragnarok> how much overhead does it save?</p>
-13:21 <@jrandom> substantial ;)</p>
-13:21 <+Ragnarok> substantial is good, if vague :P</p>
-13:21 <@jrandom> look on your http://localhost:7657/oldstats.jsp#tunnel.smallFragments</p>
-13:21 <@jrandom> compare that to #tunnel.fullFragments</p>
-13:22 < bla> jrandom: Does this concern endpoint->IB-gateway communication only? </p>
-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</p>
-13:23 <@jrandom> bla: hmm, it concerns all tunnel gateways, whether inbound or outbound</p>
-13:24 < mihi> full fragments: lifetime average value: 1,00 over 1.621,00 events</p>
-13:24 < bla> jrandom: ok</p>
-13:24 < mihi> can there be a frational number of fragments?</p>
-13:24 <@jrandom> full: 1.00 over 807,077.00 events small: 746.80 over 692,682.00 events</p>
-13:25 <@jrandom> heh mihi</p>
-13:25 <@jrandom> (that small: 746 means that on those 692k messages, 746 out of 996 bytes were wasted pad bytes!)</p>
-13:26 <@jrandom> well, not quite wasted - they served their purpose</p>
-13:26 <+detonate> needless overhead anyway</p>
-13:27 <@jrandom> yep, much of which we should be able to shed with the batching preprocessor</p>
-13:28 <@jrandom> unfortunately, that won't be bundled in the next release</p>
-13:28 <@jrandom> but it will be bundled in the 0.5.0.6 rev (or perhaps 0.5.1)</p>
-13:28 <@jrandom> erm, 0.5.0.5, or 0.5.1</p>
-13:28  * jrandom gets confused with #s</p>
-13:29 < bla> jrandom: How come not?</p>
-13:29 <+cervantes> hash and pills...damn</p>
-13:30 <@jrandom> !thwap cervantes </p>
-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</p>
-13:31 <@jrandom> if we deployed the batching preprocessor directly, we'd have a substantial number of lost messages</p>
-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 ;)</p>
-13:31 < bla> jrandom: Ah, so that</p>
-13:32 < bla> jrandom: Ah, so that is why we have to do that after 0.5.0.4 is mainstream.. I see. Thnx.</p>
-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)</p>
-13:33 <@jrandom> ok, anything else on 2), or shall we move on to 3) updating?</p>
-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 :)</p>
-13:36 <+detonate> cool</p>
-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</p>
-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</p>
-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)</p>
-13:39 <+Ragnarok> so... what's the cool stuff for 5.0.4, then?</p>
-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</p>
-13:42 <+Ragnarok> neat</p>
-13:43 <@jrandom> ok, anyone else have any questions/comments/concerns on 3) updating?</p>
-13:45 <@jrandom> if not, moving on to 4) ???</p>
-13:45 <@jrandom> anything else anyone wants to bring up?  i'm sure i've missed soem things</p>
-13:45 <+detonate> i2p's known to work with the sun jvm in OpenBSD 3.7 :)</p>
-13:45 <@jrandom> nice!</p>
-13:47 < bla> What is the status on the UDP transport?</p>
-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 ;)</p>
-13:48 <@jrandom> *cough*</p>
-13:49 <@jrandom> i dont expect there to be much trouble, but there's certainly work to be done</p>
-13:49 <@jrandom> how the queueing policy operates, as well as the bw throttling for admission to the queue will be interesting</p>
-13:50 < bla> Who was doing that prelim work?</p>
-13:50 <@jrandom> bla: detonate and mule</p>
-13:50 <+detonate> yeah.. i've been slacking off the last month or so though</p>
-13:50 < bla> detonate: I assume you jest, with your BT remark?</p>
-13:51 <+detonate> i'm half-serious</p>
-13:51 <+detonate> you could at least cut the thread count for the transport in half if you did that</p>
-13:51  * jrandom flings a bucket of mud at detonate </p>
-13:51 < jdot> woohoo.  my router is now running on my dedicated server rather than my POS cable connection.</p>
-13:51 <@jrandom> nice1 jdot </p>
-13:52 <@jrandom> we'll be able to get by with 3-5 threads in the transport layer for all comm with all peers</p>
-13:52 < bla> detonate: But half is not going to cut it, when the net becomes large (> couple hundred nodes)</p>
-13:52 < jdot> with 1000GB of b/w at its disposal</p>
-13:53 < jdot> unforunately j.i2p and the chat.i2p will be down for a few more hours while i migrate things</p>
-13:53 < duck> detonate: addressbook on halt too?</p>
-13:53 <+detonate> yeah, it's on halt too</p>
-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</p>
-13:54 <@jrandom> w3rd</p>
-13:54 <+detonate> then i2p won't fragment the drive massively</p>
-13:54 < jdot> jrandom: as far as BW limits go, are they averages?</p>
-13:54 <+frosk> modern filesystems don't fragment, silly</p>
-13:55 <+detonate> ntfs does</p>
-13:55 <@jrandom> jdot: the bandwidth limits are strict token buckets</p>
-13:55 <@jrandom> jdot: if you set the burst duration out, thats how long of a period it averages out through</p>
-13:56 <@jrandom> (well, 2x burst == period)</p>
-13:56 <@jrandom> ((ish))</p>
-13:56 < jdot> hmmm...  well i have 1000GB and want i2p to be able to take up to 800GB/mo....</p>
-13:56 <+ant> <mihi> detonate: ntfs stores really small files in mft which means nealy no fragmentation</p>
-13:57 < jdot> and i dont care what it bursts to</p>
-13:57 <+detonate> well, when you run the defragmenter, it spends 10 minutes moving all 6000 profiles around.. so they must fragment</p>
-13:58 <@jrandom> jdot: hmm, well, 800GB is probably more than it'll want to push anyway, so you can probably go without limits ;)  </p>
-13:58 <@jrandom> otoh, if you could describe a policy that you'd like implemented, we might be able to handle it</p>
-13:58 < jdot> jrandom: i'll do that for now and see how it works</p>
-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 </p>
-13:58 <+detonate> everything gets written at once</p>
-13:59 <+detonate> and read at once</p>
-13:59 < bla> detonate: Ok. I see.</p>
-13:59 < jdot> jrandom: well, lets wait until we figure out if it'll even be a problem.</p>
-13:59 < bla> detonate: Good work in that case!</p>
-13:59 <+detonate> i'd be interested in knowing how much usage there really is if you leave it uncapped</p>
-14:00 <+detonate> on a good connection</p>
-14:00 < jdot> i'm interested too!</p>
-14:00 <@jrandom> my colo routers run uncapped, though cpu constrained</p>
-14:00 <+Ragnarok> can you use a bitbucket to average over a month?</p>
-14:00 < jdot> jrandom: cpu contrianed?  what kind of cpu?</p>
-14:01 <@jrandom> 4d transfer 3.04GB/2.73GB</p>
-14:01 <+detonate> hmm, was expecting less</p>
-14:01 <@jrandom> jdot: cpu constrained because i run 3 routers on it, plus a few other jvms, sometimes profiling</p>
-14:01 <+detonate> must be those bt people</p>
-14:01 <+detonate> once the batching stuff is online, it would be interesting to see how that changes</p>
-14:02 <@jrandom> detonate: some of that transfer is also me pushing 50MB files between itself ;)</p>
-14:02 <+detonate> heh</p>
-14:02 < jdot> ahh.  ok.  well, we'll see how this system does.  its an AMD XP 2400 w/ 512MB and a 10Mbit connection</p>
-14:02 <@jrandom> Ragnarok: token buckets dont really work that way</p>
-14:02 <@jrandom> jdot: word, yeah, this is a p4 1.6 iirc</p>
-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</p>
-14:04 <@jrandom> whenever you want to transfer data, you need to get a sufficient amount of tokens</p>
-14:04 <@jrandom> (1 token = 1 byte)</p>
-14:04 <+Ragnarok> I know how they work... what happens if you just make the bucket really big?</p>
-14:05 <+detonate> then you never stop sending data</p>
-14:05 <+detonate> if it's infinite in size</p>
-14:05 <+detonate> err, and it's filled with tokens</p>
-14:05 <@jrandom> if its really big, it may go out and burst to unlimited rates after low usage</p>
-14:06 <@jrandom> though perhaps thats desired in some cases</p>
-14:07 <@jrandom> the thing is, you can't just set the token bucket to 800GB, as that wouldnt constrain the total amount transferred</p>
-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</p>
-14:08 <+detonate> :)</p>
-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</p>
-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?</p>
-14:11 <+Ragnarok> s/larger/large/</p>
-14:12 <+detonate> well, you could set it so that it never sends more than 800GB/44000 in a 60 second burst period</p>
-14:12 <+detonate> 44000 being roughly the number of minutes in a month</p>
-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)</p>
-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)</p>
-14:16 <+Ragnarok> I thought the bucket only got paid into when there was bandwidth not being used</p>
-14:16 <@jrandom> tokens are added to the bucket at a constant rate (e.g. 64k tokens per second)</p>
-14:17 <@jrandom> anything that wants bandwidth always asks the bucket</p>
-14:18 <+Ragnarok> ah.. ok</p>
-14:19 <@jrandom> ok cool, anyone else have anything they want to bring up for the meeting?</p>
-14:21 <@jrandom> ok if not</p>
-14:21  * jrandom winds up</p>
-14:21  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/134.rst b/i2p2www/meetings/134.rst
new file mode 100644
index 00000000..b1a1245c
--- /dev/null
+++ b/i2p2www/meetings/134.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 22, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/135.log b/i2p2www/meetings/135.log
index cc0cd36d..d269af7a 100644
--- a/i2p2www/meetings/135.log
+++ b/i2p2www/meetings/135.log
@@ -1,125 +1,119 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 135{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 29, 2005</h3>
-<div class="irclog">
-13:13 < jrandom> 0) hi</p>
-13:13 < jrandom> 1) 0.5.0.5</p>
-13:13 < jrandom> 2) UDP (SSU)</p>
-13:13 < jrandom> 3) Q</p>
-13:13 < jrandom> 4) ???</p>
-13:13 < jrandom> 0) hi</p>
-13:13  * jrandom waves</p>
-13:13  * smeghead particles</p>
-13:13 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-March/000661.html</p>
-13:14 < jrandom> (an hour early *mumblemumble*)</p>
-13:14 < jrandom> anyway, jumping in to 1) 0.5.0.5</p>
-13:15 < jrandom> as mentioned in the status notes, there'll be a new release later this evening</p>
-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</p>
-13:15 < jrandom> all 0.5.0.4 users should upgrade as soon as 0.5.0.5 is out, as well</p>
-13:16 <@smeghead> will the update work through the new trusted update facility in the router console?</p>
-13:17 < jrandom> yes and no</p>
-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 </p>
-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</p>
-13:18 < zzz> yes if you want to wait 12 hours? there's no 'update now' button, is there?</p>
-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</p>
-13:19 <@smeghead> what's the name of this file?</p>
-13:19 <@smeghead> oh ic</p>
-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</p>
-13:20 < jrandom> there'll be a new i2pupdate.zip made available, as well as i2pupdate.sud</p>
-13:20 < jrandom> (though for later revs, the .zip may not be provided)</p>
-13:20 <@smeghead> should news.xml be in the base install dir?</p>
-13:20 < jrandom> smeghead: docs/news.xml</p>
-13:21 <+Myo9> Would it not good to get updates anonymous by default?</p>
-13:21 <+Myo9> s/not/"not be"/</p>
-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</p>
-13:22 <+frosk> anyone can tell you're running a router anyway</p>
-13:22 <+ant> <mae^> lalalala</p>
-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</p>
-13:23 <+Myo9> Ok.</p>
-13:23 <+ant> * mae^ covers his ears</p>
-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 :)</p>
-13:23 <+ant> <mae^> dont talle me your goddamn network passwword</p>
-13:24 <+ant> <mae^> damnit</p>
-13:25 < jrandom> ok, anyone else have anything for 1) 0.5.0.5?</p>
-13:25 <+ant> <mae^> lets all take take a minute to thank jr ight now</p>
-13:25 <+ant> <mae^> silently and to yourself...</p>
-13:25 <@smeghead> mae^: how about after the meeting</p>
-13:25 < jrandom> heh, and to the donations page ;)</p>
-13:25 <+ant> <mae^> or to him and private is ifine too</p>
-13:26 <+ant> <mae^> or donate!</p>
-13:26 < jrandom> ok, moving on to 2) UDP (SSU)</p>
-13:26 < jrandom> we've got some thoughts on the new UDP protocol up on the web, and some critical feedback would be great</p>
-13:27 <+ant> * cervantes notes the royal "we"</p>
-13:27 <@smeghead> what is SSU</p>
-13:27 < jrandom> well, i may be the one who types it in, but we've all been discussing the issues ;)</p>
-13:28 < jrandom> SSU == Secure Semireliable UDP</p>
-13:28 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html?rev=HEAD</p>
-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)</p>
-13:28 <@smeghead> Eol: --> #i2p-chat</p>
-13:29 < jrandom> Eol: perhaps some people in #i2p-chat can help, we're in the weekly dev meeting right now</p>
-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)</p>
-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</p>
-13:31 <+ant> * Eol apologizes</p>
-13:31 <@smeghead> the remaining should rebel against their tyrannical system admins</p>
-13:31 < jrandom> np eol</p>
-13:32 <@smeghead> (or splurge for a real net connection)</p>
-13:32 < jrandom> or get a non-symmetric NAT</p>
-13:32 <+frosk> (or wait for restricted routes)</p>
-13:32 < jrandom> yeah, or wait for 2.0 :)</p>
-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</p>
-13:32 < jrandom> smeghead: not everyone has a choice in the matter</p>
-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</p>
-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</p>
-13:33 <@smeghead> right</p>
-13:34 < jrandom> aye, we'll support what we can, and what we can't, well, we can't, yet</p>
-13:34 <@smeghead> the more people bend over for their ISPs, the more ISPs will restrict their users, and the harder our task becomes</p>
-13:37 < jrandom> ok, anyone else have anything for 2) UDP?  if not, moving on to 3) Q</p>
-13:37 < jrandom> hmm, looks like aum isn't up yet :)</p>
-13:37 < jrandom> but basically, lots of cool stuff up @ http://aum.i2p/q/</p>
-13:38 <@smeghead> i think i speak for aum when i say, "zzzzzzzzzzzzzZZZz"</p>
-13:39 < jrandom> ok, i dont know if i have anything to add beyond whats in the email, beyond "neat stuff, talk to aum" :)</p>
-13:40 < jrandom> ok, moving on at a rapid rate to 4) ???</p>
-13:40 < jrandom> anyone else have anything they want to bring up?</p>
-13:41 < cervantes> whoa a sub half hour?</p>
-13:41 < jrandom> first i get the meeting notes out an hour early, and now this!</p>
-13:41 <@smeghead> time for a filibuster</p>
-13:41 < jrandom> *cough*</p>
-13:41 <+postman> :)</p>
-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 :)</p>
-13:41 <+postman> ok, just wanted to announce v2mail.i2p</p>
-13:42  * cervantes wheels out a ming dynasty china gong</p>
-13:42 < jrandom> ooh word postman </p>
-13:42 <+postman> as official portal to the v2mail deleopment</p>
-13:42 <+postman> the html layout eats babys</p>
-13:42 <+postman> but still i hope you find the docs/whitepapers there interesting</p>
-13:43 <+postman> the documentation will be updated over the next week</p>
-13:43 <@smeghead> could you say a little about what v2mail is?</p>
-13:43 <@smeghead> v2 like version 2, or like the rocket?</p>
-13:43 <+postman> smeghead: the new decentralized mailservice for i2p 1.0</p>
-13:43 <+postman> smeghead: v2 refers to the version</p>
-13:44  * postman does not plan any mailbombs or rockets :)</p>
-13:44 <@smeghead> does it have specific dependencies on 1.0, or is that just a target?</p>
-13:45 <+postman> there's still a few months work ahead - updates will be announced there</p>
-13:45 <+frosk> nice effort, postman</p>
-13:45 <+postman> smeghead: no, there're no dependencies on 1.0 - you'll still continue using susimail or your own mua</p>
-13:46 <+postman> frosk: thanks </p>
-13:46 <+postman> jrandom: k, /me hands back the microphone</p>
-13:47 <+ant> <cervantes> *distant clapping*</p>
-13:47 < jrandom> w3rd, it definitely looks cool</p>
-13:47 <+postman> cervantes: hey, what about your firefox plugin?</p>
-13:47 < jrandom> ok, anyone else have anything to add to the meeting?</p>
-13:48 <+ant> <cervantes> postman: eerm still plugin away at it</p>
-13:49 <+postman> cervantes: me want play with it :)</p>
-13:50 <+ant> <cervantes> just getting through a tedious part of managing user preferences...then all should be ready for a test release</p>
-13:50 < jrandom> wikked</p>
-13:50 <+postman> c00l :)</p>
-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)</p>
-13:52 < jrandom> oh, nice!</p>
-13:52 <+ant> <cervantes> but that won't be in firefox for a couple of releases</p>
-13:53 < jrandom> great, please keep us updated</p>
-13:53 <+ant> <cervantes> will do</p>
-13:54 < jrandom> ok, if there's nothing else...</p>
-13:54  * jrandom winds up</p>
-13:54  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/135.rst b/i2p2www/meetings/135.rst
new file mode 100644
index 00000000..2ba08d41
--- /dev/null
+++ b/i2p2www/meetings/135.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 29, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/136.log b/i2p2www/meetings/136.log
index 8c0a7466..4c3539dd 100644
--- a/i2p2www/meetings/136.log
+++ b/i2p2www/meetings/136.log
@@ -1,103 +1,97 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 136{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 5, 2005</h3>
-<div class="irclog">
-14:34 <@jrandom> 0) hi</p>
-14:34 <@jrandom> 1) 0.5.0.5</p>
-14:34 <@jrandom> 2) Bayesian peer profiling</p>
-14:34 <@jrandom> 3) Q</p>
-14:34 <@jrandom> 4) ???</p>
-14:35 <@jrandom> 0) hi</p>
-14:35  * jrandom waves</p>
-14:35  * smeghead outsources his todo list to a parallel universe</p>
-14:35 <@jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-April/000675.html</p>
-14:36 <@jrandom> might as well jump on in to 1) 0.5.0.5</p>
-14:36 <+ant> * Connelly waves</p>
-14:37 <+protokol> high everyone</p>
-14:37 <@jrandom> as mentioned in the status notes (and the current history.txt), we've tracked down some very long lasting netDb bugs</p>
-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</p>
-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 :)</p>
-14:39 <+protokol> yey</p>
-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?</p>
-14:40 <+protokol> nope</p>
-14:41 <@jrandom> ok, moving on to 2) Bayesian peer profiling</p>
-14:41 <@jrandom> ah, damn, bla dropped off the channel a few mins back</p>
-14:42 <@jrandom> well, anyway, I just wanted to point people out at bla's work exploring some more robust profiling techniques</p>
-14:42 <+protokol> postponing 2?</p>
-14:43 <@jrandom> check out the forum post and the link to theland.i2p for more info, and bounce bla your thoughts :)</p>
-14:44 <@jrandom> ok, movin' on to 3) Q</p>
-14:44 <@jrandom> aum: you up?</p>
-14:44 <@jrandom> hmm, doesnt look like it</p>
-14:45 <@jrandom> ok, lots of progress on the Q front, more details for getting involved in alpha testing up @ http://aum.i2p/q/ </p>
-14:45 <@jrandom> i'm sure we'll hear more on the list when there's an update available</p>
-14:46 <+ant> <Connelly> Q works for me for retrieving content</p>
-14:46 <@jrandom> yeah, its been working great for me as well, a few bumps here and there, but quite promising</p>
-14:47 <+ant> <Connelly> my Q server stored 2 small items, then got stuck at 100% cpu usage until i killed it</p>
-14:47 < zzz> for those who haven't seen it check out my q front end http://flock.i2p/cgi-bin/q</p>
-14:47 <@jrandom> zzz: that is quite kickass</p>
-14:48  * jrandom forgot the url to that when writing up the status notes (d'oh)</p>
-14:50 <@jrandom> ok, anything else on 3) Q?  or shall we move on to 4) ???</p>
-14:50  * jrandom considers us moved</p>
-14:51 <@jrandom> anyone have anything else they'd like to bring up for the meeting?</p>
-14:51 <+ant> <Connelly> i've coding an http/html filter for i2p</p>
-14:51 <+protokol> yes</p>
-14:51 <+protokol> ian clarke is a troll on slashdot</p>
-14:51 <+ant> <Connelly> been coding</p>
-14:51 <+ant> <Connelly> should be more safe than freenet's html filterer</p>
-14:51 <+ant> <Connelly> if i run out of time i'll just incorporate freenet's filterer</p>
-14:51 <@jrandom> cool Connelly, how is it coming along?</p>
-14:52 <@jrandom> protokol: and you're a troll in #i2p ;)</p>
-14:52 <+ant> <Connelly> so in the end we should have an html filterer for i2p</p>
-14:52 <+ant> <Connelly> got html filtering done, now working on css, still haven't looked at header filtering</p>
-14:53 <+ant> <Connelly> it's very paranoid :)</p>
-14:53 <@jrandom> bitchin</p>
-14:53 <+protokol> whitelist?</p>
-14:53 <@duck> does it let anything trough at all?</p>
-14:53 <+ant> <Connelly> yeah</p>
-14:53 <+protokol> if so, what is currently disallowed</p>
-14:53 <+protokol> (of any importance)</p>
-14:55 <+ant> <Connelly> disallowed of significance: frames and iframes, scripting, optgroup</p>
-14:55 <+ant> <Connelly> meta</p>
-14:55 <+ant> <Connelly> embedded objects</p>
-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?</p>
-14:56 <+ant> <Connelly> i'll probably have an alpha in 1-2 weeks</p>
-14:57 <+ant> <Connelly> so we can test out how it works</p>
-14:57 < jrandom2p> kickass</p>
-14:58 <+ant> <Connelly> it allows forms, cookies, content caching but those can be turned off in 'paranoid' mode</p>
-14:58 <+protokol> why frames and iframes? can you just not block connections to non-i2p sites from them?</p>
-14:59 <+ant> <Connelly> it has a cgiproxy like url navigator bar at the top</p>
-14:59 <+ant> <BS314159> I suspect the hard thing would be blocking frames between different eepsites</p>
-14:59 <+ant> <Connelly> i don't want that hijacked</p>
-14:59 <+protokol> i mean can you just block connections</p>
-14:59 <+ant> <Connelly> could make it like freenet's proxy where you just enter a url at the beginning</p>
-14:59 <+protokol> yeah, frames can rock</p>
-14:59 <+ant> <Connelly> and can't enter urls once you start browsing</p>
-14:59 < jrandom2p> frames kill kittens</p>
-15:00 <+ant> <BS314159> this has to be the oldest framewar ever.  excuse me, flamewar</p>
-15:00 < jrandom2p> heh</p>
-15:00 <+protokol> i said "can" rock</p>
-15:00 <+ant> <BS314159> what we need is our own browser</p>
-15:00 <@jrandom> and flying ponies</p>
-15:01 <@jrandom> *cough*</p>
-15:01 <+ant> <Connelly> i'd prefer an F-16 to a pony</p>
-15:01 < Teal`c__> can i have a girl ?</p>
-15:01 <+ant> <Connelly> i'll make an option for enabling frames</p>
-15:01 <+protokol> Teal`c__: no</p>
-15:02 <+ant> <BS314159> Is there a functioning I2P inproxy? bolas.mine.nu appears to be dead.</p>
-15:02 <+protokol> from other eepsites, right?</p>
-15:02 <@jrandom> BS314159: http://i2p.mine.nu/</p>
-15:02 <+protokol> i2p.mine.nu</p>
-15:02 < frosk> i2p.mine.nu</p>
-15:02 <+ant> <BS314159> thanks</p>
-15:02 <+ant> <BS314159> frames are safe if they're inside one eepsite.  frames are safe if all content is static</p>
-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</p>
-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</p>
-15:04 <+ant> <BS314159> wise</p>
-15:06 <@jrandom> ok, anyone else have anything for the meeting?</p>
-15:06 < Teal`c__> sorry didn't know a meeting was on</p>
-15:07 <@jrandom> heh no worry, you'll be immortalized in the meeting logs ;)</p>
-15:07 <@jrandom> speaking of which</p>
-15:07  * jrandom winds up</p>
-15:07  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/136.rst b/i2p2www/meetings/136.rst
new file mode 100644
index 00000000..91773f80
--- /dev/null
+++ b/i2p2www/meetings/136.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 5, 2005
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/137.log b/i2p2www/meetings/137.log
index 4953812b..6bbfa33f 100644
--- a/i2p2www/meetings/137.log
+++ b/i2p2www/meetings/137.log
@@ -1,286 +1,280 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 137{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 12, 2005</h3>
-<div class="irclog">
-14:05 < jrandom> 0) hi</p>
-14:05 < jrandom> 1) Net status</p>
-14:05 < jrandom> 2) SSU status</p>
-14:05 < jrandom> 3) Bayesian peer profiling</p>
-14:05 < jrandom> 4) Q status</p>
-14:05 < jrandom> 5) ???</p>
-14:05 < hummingbird> 7) Profit</p>
-14:06 < jrandom> damn, i messed up y'all's agenda :)</p>
-14:06 < jrandom> hi</p>
-14:06 < jrandom> weekly status notes posted /before/ the meeting up @ http://dev.i2p.net/pipermail/i2p/2005-April/000683.html</p>
-14:06 < gott> jrandom: try it again</p>
-14:06 <+cervantes> never mind, this meeting gott off onto a bad footing anyway</p>
-14:06 < jrandom> *cough*</p>
-14:06 < jrandom> jumping in to 1) Net status</p>
-14:07 < jrandom> the big problem we were seeing with the netDb has been fixed and confirmed dead in the wild</p>
-14:07 < jrandom> there are still some other issues, but it seems on the whole to be fairly reasonable</p>
-14:08 < frosk> any idea what's causing the weird dnfs sometimes?</p>
-14:08 < gott> confirm; I can get my illegal porn at record speeds for i2p now.</p>
-14:08 <+cervantes> seems like that might be a hard one to pin down</p>
-14:08 < jrandom> sneaking suspicion that its some confusion related to the throttle on the tunnel building</p>
-14:09 < jrandom> pulling out those throttles will probably address it, but could be painful for users with slow CPUs</p>
-14:09 < jrandom> otoh, perhaps we could make them optional, or someone could write some smarter throttling code</p>
-14:10 < frosk> i see</p>
-14:10 <+cervantes> the throttle seems much more pro-active than previous versions on my system</p>
-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"</p>
-14:10 <+cervantes> can we not make the threshold tweakable?</p>
-14:11 < jrandom> aye, that we can</p>
-14:11 < gott> jrandom: optional</p>
-14:11 < gott> so users with thin i2p servents can still be productive</p>
-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</p>
-14:12 < jrandom> (or if no one jumps at it, i can toss in some tweaks when the next build comes out)</p>
-14:13 <+cervantes> ........@    <-- tumbleweed</p>
-14:13 < jrandom> :)</p>
-14:13 < jrandom> anyone have anything else for 1) net status, or shall we move on to 2) SSU?</p>
-14:14  * gott mutters something about too much talk and too little action when it comes to the i2p community</p>
-14:14 <+cervantes> perhaps in the future we can introduce performance profiles into the console</p>
-14:14 < gott> jrandom does too much on the development side.</p>
-14:14 <+cervantes> so people can choose a preset batch of config options for high/med/low spec systems</p>
-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</p>
-14:15 <+cervantes> since there are many that seem to be using low spec machines and modem connections atm</p>
-14:15 < gott> cervantes: yeah, excellent idea.</p>
-14:15 <+cervantes> I should publish my fire2pe todo list...it has lots of shit like that in it ;-)</p>
-14:16 < gott> based on processor and network speed primarily ?</p>
-14:16 < jrandom> a site with a pseudonymous todo list would be nice</p>
-14:16 < gott> that is a good idea.</p>
-14:16 <+cervantes> well the bandwidth limiter should ideally take care of net speed</p>
-14:16 < gott> in typical google-fashion, have a bunch of 'thin i2p servents' in your LAN.</p>
-14:17 <+cervantes> jrandom: ugha.i2p?</p>
-14:17 < jrandom> perhaps</p>
-14:19 < jrandom> ok, anything else for 1) net status?</p>
-14:19  * jrandom moves us on to 2) SSU</p>
-14:19 < jrandom> Lots of progress on the UDP front (SSU == Secure Semireliable UDP)</p>
-14:19 < gott> someone should alias 'i2pwiki.i2p' to that</p>
-14:20 <+cervantes> I guess that's up to ugha ;-)</p>
-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</p>
-14:21 <+ant> <godmode0> udp is safe ?</p>
-14:21 <+ant> <godmode0> how :)</p>
-14:21 < jrandom> http://dev.i2p/cgi-bin/cvsweb.cgi/i2p/router/doc/udp.html <-- how</p>
-14:22 <+ant> <godmode0> hehe</p>
-14:22 <+ant> <godmode0> i2p not found  right ip my computer</p>
-14:22 < jrandom> sorry, if you don't have i2p installed, change "dev.i2p" to "dev.i2p.net"</p>
-14:22 <+ant> <godmode0> have installled</p>
-14:23 <+ant> <godmode0> but not work</p>
-14:23 < jrandom> ok, perhaps we can debug that after the meeting </p>
-14:23 <+ant> <godmode0> oops in meeting again sorry</p>
-14:23 < jrandom> hehe np</p>
-14:25 < jrandom> anyway, as i said, the general plan of how things are going is in the email</p>
-14:25 < jrandom> anyone have any questions/comments/concerns wrt SSU?</p>
-14:26 <+Ragnarok> will throughput/latency be much different than the tcp transport?</p>
-14:27 < jrandom> my hope is that the cause of the lag spikes will be addressed, but i'm not making any particular predictions.</p>
-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</p>
-14:29 <+Ragnarok> cool</p>
-14:29 < gott> will there be documentation on the implementation provided on i2p.net ?</p>
-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</p>
-14:30 < gott> awesome \m/</p>
-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</p>
-14:31 < jrandom> anyway, if there's nothing else on 2) SSU, lets shimmy on over to 3) Bayesian peer profiling</p>
-14:32 < jrandom> we got a brief update from bla earlier this evening, as shown in the status notes</p>
-14:32 <+bla> I'm still here though... ;)</p>
-14:33 < jrandom> bla may atcually still be around to give us any further thoughts or answer questions -</p>
-14:33 < jrandom> ah, there you are</p>
-14:33 < defnax> jrandom : what do you think about anounce i2p bittorrent Tracker, for security i think is not good or?, </p>
-14:34 <+bla> The IRC discussion quoted by jrandom shows the general idea. Summarized: </p>
-14:34 < jrandom> defnax: perhaps we can discuss that further in 5) </p>
-14:34 < defnax> ok i can wait </p>
-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</p>
-14:35 <+bla> For now, I use information obtained from explicit tunnel tests only, as for those tests, all participating peers are known.</p>
-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</p>
-14:36 <+bla> In order to compare things to a "ground truth", I've obtained "actual" peer speeds as listed in the status notes</p>
-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</p>
-14:37 <+bla> Well. Any questions or comments?</p>
-14:38 < jrandom> comment: looks promising.  </p>
-14:38 <+ant> <BS314159> it seems like the total tunnel speed provides a hard lower bound on the speed of every participating peer</p>
-14:38 <+detonate> comment: seem to be a few outliers</p>
-14:38 <+ant> <BS314159> is that incorporated?</p>
-14:39 < jrandom> BS314159: total tunnel speed?  oh, do you mean the testing node's net connection?</p>
-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</p>
-14:40 <+ant> <BS314159> I mean the total bandwidth of a given tunnel</p>
-14:40 <+bla> BS: The results show _latency_ measurements, for now</p>
-14:40 <+ant> <BS314159> right.</p>
-14:41 <+ant> <BS314159> nevermind, then</p>
-14:41 < jrandom> ah, right, certainly.  throughput measurements will require further modifications to test with different size messages</p>
-14:41 < jrandom> otoh, the implicit tunnel tests are driven by larger messages (typically 4KB, since thats the streaming lib fragmentation size)</p>
-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</p>
-14:42 <+detonate> ok</p>
-14:43 <+bla> jrandom: Indeed. Once I get that working (in not a Java buff...), I'll also test using the larger messages</p>
-14:43 <+bla> detonate: Now, I'd like to make the separation between fast and really-fast peers in a better way.</p>
-14:43 < jrandom> cool, i'll see if i can bounce you a modified TestJob for that</p>
-14:44 <+bla> I'll report when I have new results.</p>
-14:44 < jrandom> kickass</p>
-14:45 < jrandom> ok cool, anyone else have anything for 3) Bayesian peer profiling?</p>
-14:46 < jrandom> if not, moving on to 4) Q status</p>
-14:46 < jrandom> As mentioned in the email, rumor has it Aum is making progress on a new web interface</p>
-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</p>
-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) ???</p>
-14:49 < jrandom> [consider us moved]</p>
-14:49 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
-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</p>
-14:50 < gott> Yes.</p>
-14:50 < jrandom> (or 1.0 ;)</p>
-14:50 < gott> I have some information to bring up on userland documentation efforts.</p>
-14:51 <+mancom> just for the record: on mancom.i2p there is a c# implementation of Q's client api (in its first incarnation)</p>
-14:51 < jrandom> oh cool, sup gott</p>
-14:51 < jrandom> ah nice1 mancom</p>
-14:51 < gott> I have previously written userland documentation for 0.4 i2p.</p>
-14:52 < jrandom> which i unforutnately obsoleted by changing a whole bunch of stuff :(</p>
-14:52 < gott> But it is entirely out-of-date with current i2p.</p>
-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.</p>
-14:53 < jrandom> wikked.  docs to bundle with i2p (localized to the user's language, etc) would be great</p>
-14:53 <+cervantes> cool</p>
-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 ;-)</p>
-14:53 < gott> Okay.</p>
-14:53 < gott> But is it overkill ?</p>
-14:53 <+ant> <BS314159> what respectable program comes without man pages?</p>
-14:53 <+cervantes> and is it worth waiting til 1.0?</p>
-14:54 < gott> That is another question.</p>
-14:54 < jrandom> since development is fairly fluid, it might be worth focusing on context-specific help, rather than an overall user guide</p>
-14:54 < gott> BS314159: these are not manpages, as it will be platform-independent. Probably HTML.</p>
-14:54 <+cervantes> how much more structural changes are we due before then</p>
-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.</p>
-14:55 < gott> Okay, so I shall write an english and french localisation of a manual for i2p.</p>
-14:55 <+jdot> actually, we could use the inproxy to access the documentation even w/o i2p being installed.</p>
-14:55 < gott> Two major questions :</p>
-14:55 < jrandom> those could be kept up to date by virtue of being *in* the interface itself</p>
-14:55 <+cervantes> yeah context help would rock</p>
-14:55 < gott> (1) Bundled or accessible via manual.i2p ?</p>
-14:55 < gott> (2) For which version ?</p>
-14:55 < gott> yes</p>
-14:55 < jrandom> gott: i'm not sure it'd be wise to build a user guide yet</p>
-14:55 < gott> that's a great idea</p>
-14:56 < gott> do you mean to use the auto-update function to update the usermanual ?</p>
-14:56 < gott> jrandom: okay</p>
-14:56 < gott> but then how do you suggest context-specific help ?</p>
-14:56 < jrandom> oh, we can certainly deploy updates to the docs with the update process</p>
-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</p>
-14:57 < gott> I am thinking of a user-manual.</p>
-14:57 < gott> or a HOWTO.</p>
-14:57 < gott> I have no idea what you mean by context-specific help.</p>
-14:57 < gott> it's pretty straightforward.</p>
-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</p>
-14:58 < jrandom> a user-manual or howto would be great, but not until 1.0</p>
-14:59 < jrandom> there's already some work on that front in the forum @ http://forum.i2p.net/viewtopic.php?t=385</p>
-14:59 < gott> jrandom: yes.</p>
-14:59 < gott> well.</p>
-14:59 < gott> the information on config.jsp is pretty straightfoward already </p>
-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</p>
-15:00 < gott> heh</p>
-15:00 < jrandom> gott: its straightforward to you because you've been using i2p for almost two years</p>
-15:00 < gott> nevermind, 'configtunnels.jsp' could use some work.</p>
-15:00 < gott> okay.</p>
-15:00 <+cervantes> straightforward to the initiated perhaps, a n00b would be lost</p>
-15:01 < gott> this is, then, a more up-to-date selection of tasks :</p>
-15:01 <+cervantes> not sure the best way to present the help from an interface perspective</p>
-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</p>
-15:02 < gott> I'm not sure how java figures out the default locale under windows.</p>
-15:02 < gott> But this is a good start to localisation and documentation writing.</p>
-15:03 < gott> (2) For version 1.0, a HOWTO _accessed_ via i2p</p>
-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 ?</p>
-15:03 < jrandom> dood, its html.  its tiny.  even if its huge, html compresses *really* well</p>
-15:03 < jrandom> having a local manual would be very much preferred</p>
-15:03 < jrandom> especially since we can push updates</p>
-15:03  * gott shrugs</p>
-15:04 < gott> I suppose.</p>
-15:04 < gott> I just find it silly.</p>
-15:04 < gott> when you can just download it via the web.</p>
-15:04 < gott> but on the other hand, if the user can't figure out how to use i2p</p>
-15:04 < gott> he can't.</p>
-15:04 <+ant> <Synonymous2> Is aum around, i was looking at the specs for QuarterMaster</p>
-15:04 <+ant> <Synonymous2> * In order to help client-side searching, all data items are accompanied</p>
-15:04 <+ant> <Synonymous2>    by a simple metadata schema - so far, just consisting of:</p>
-15:04 <+ant> <Synonymous2>     - key - text name of key</p>
-15:04 <+jdot> put it on www.i2p.net so it is accessible via the intarweb and i2p.</p>
-15:04 <+jdot> and always up to date</p>
-15:05 < gott> yeah.</p>
-15:05 < gott> well, just use the update mechanism.</p>
-15:05 < gott> okay.</p>
-15:05 < gott> so, finalising :</p>
-15:05 < jrandom> sure, we can put it on the website too.  we can spam it all over the net if it helps ;)</p>
-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</p>
-15:05 < gott> 1 : Localised interface and context-specific help.</p>
-15:05 < gott> 2 : Localised HOWTO for version 1.0</p>
-15:05 <+ant> <Synonymous2> oopse is this the meeting :)</p>
-15:05 < gott> Any additions ?</p>
-15:06 < gott> the HOWTO will cover a lot of extra i2p-network features.</p>
-15:06 < gott> where to get the latest porn ( j/k )</p>
-15:06 <+ant> <BS314159> manpage! :-)</p>
-15:06 < gott> manpages aren't platform-independent</p>
-15:06 < jrandom> cool, including things like Q, i2ptunnel, feedspace, i2p-bt, etc would be great for a howto</p>
-15:06 <+cervantes> the installer could be localised too I guess...</p>
-15:06 < gott> the i2p network has a hilariously large amount of french users</p>
-15:07 <+Ragnarok> you should clearly write the addressbook documentation I've never gotten around to :)</p>
-15:07 < gott> I'm sure they would appreciate a localised interface so they don't have to look at the disgusting english language</p>
-15:07 <+cervantes> hey it's mostly french already</p>
-15:07 < gott> true.</p>
-15:07 < gott> good ideas.</p>
-15:08 < gott> well, that is all I had to say.</p>
-15:08 < jrandom> ok cool, thanks gott, nice initiative</p>
-15:08 < gott> for now, I shall start on the context-specific stuff</p>
-15:08 < jrandom> Synonymous2: I'm not sure what Aum is doing on that front</p>
-15:08 < jrandom> bitchin'</p>
-15:08 < gott> and then, when a localisation option is added, the localised languages </p>
-15:08 <+bla> gott: Je _deteste_ Anglais! ;)</p>
-15:09 < gott> moi aussi</p>
-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</p>
-15:09 <+cervantes> ewll you have william the conquerer to blame for that</p>
-15:09 < jrandom> heh</p>
-15:09 < gott> a wiki is good, but also non-official.</p>
-15:09 < gott> the manual has the element of certification.</p>
-15:09 < gott> it is more reassuring.</p>
-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</p>
-15:10 <+cervantes> we'd still be speaking anglo-saxon otherwise</p>
-15:10 < jrandom> everything i do which i 'have rights to' is released implicitly into the public domain</p>
-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 :></p>
-15:11 <+ant> <Synonymous2> :)))</p>
-15:11 < gott> jrandom: all the localisation I write will be public domain</p>
-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</p>
-15:11 < gott> I don't give a damn about any licenses.</p>
-15:12 < gott> also, last question :</p>
-15:12 <+ant> <Synonymous2> i was going to copy a few things like the chart and some graphics hehe</p>
-15:12 < gott> where are the .jsp for the router located ?</p>
-15:12 < jrandom> gott: http://dev.i2p/cgi-bin/cvsweb.cgi/apps/routerconsole/jsp/</p>
-15:13 < gott> ah</p>
-15:13 < gott> so, locally, they are in a .jar ?</p>
-15:13 < jrandom> gott: routerconsole.war</p>
-15:13 < jrandom> but you can't really edit them there, as they're precompiled into java</p>
-15:13  * gott nods</p>
-15:13 < gott> Sure.</p>
-15:14 < gott> Though, that's an inconvenience.</p>
-15:14 < gott> when localisation comes out, that might be changed ?</p>
-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</p>
-15:14 <+cervantes> Synonymous: http://www.i2p.net/licenses</p>
-15:15 < gott> so you can have language packs</p>
-15:15  * gott nods</p>
-15:15 < gott> for now, it is just hardcoded</p>
-15:15 < jrandom> localization in java works by loading up per-language properties files with resources</p>
-15:15 < gott> but later on, it should be less restricted, I suggest</p>
-15:15 < jrandom> right right</p>
-15:16 < gott> awesome.</p>
-15:16 < gott> well, I'll use anonymous CVS then ;-)</p>
-15:16 < jrandom> bitchin'</p>
-15:16 <+ant> <BS314159> bla: is your raw data available anywhere?</p>
-15:16 < jrandom> bla has recently disconnected, but we'll see about getting some data available</p>
-15:17 < gott> btw, do we have anyone running i2p on openbsd ?</p>
-15:17 <+ant> <BS314159> it's be fun to let people try their own estimators</p>
-15:17 <+ant> <BS314159> sister:...23?</p>
-15:17 < jrandom> gott: yeah, i think detonate is</p>
-15:18 <+ant> <BS314159> ack</p>
-15:18 <+ant> <BS314159> cross-post</p>
-15:18 <+ant> <BS314159> curses!</p>
-15:18 < gott> is it even possible ? what are the java limitations regarding openbsd and i2p ?</p>
-15:18 < gott> okay.</p>
-15:18 < jrandom> BS314159: yeah, there's some good info about modifying your estimators up in the forum</p>
-15:18 <+cervantes> long meeting</p>
-15:18 < gott> if I ever have time, I might get it running and setup a port.</p>
-15:18 < gott> but that is long off and someone will probably do it before me ;-)</p>
-15:18 < jrandom> cervantes: check the logs, we've broken 2h before ;)</p>
-15:19 < jrandom> ok, anyone else have anything for the meeting?</p>
-15:20 < jrandom> if not</p>
-15:20  * jrandom winds up</p>
-15:20  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/137.rst b/i2p2www/meetings/137.rst
new file mode 100644
index 00000000..d614b533
--- /dev/null
+++ b/i2p2www/meetings/137.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 12, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/138.log b/i2p2www/meetings/138.log
index ae1afef8..ad0bac53 100644
--- a/i2p2www/meetings/138.log
+++ b/i2p2www/meetings/138.log
@@ -1,106 +1,100 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 138{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 19, 2005</h3>
-<div class="irclog">
-14:05 <@jrandom> 0) hi</p>
-14:05 <@jrandom> 1) Net status</p>
-14:05 <@jrandom> 2) SSU status</p>
-14:05 <@jrandom> 3) Roadmap update</p>
-14:05 <@jrandom> 4) Q status</p>
-14:05 <@jrandom> 5) ???</p>
-14:05 <@jrandom> 0) hi</p>
-14:05  * jrandom waves</p>
-14:05 <@jrandom> weekly status notes (posted a sec ago) up @ http://dev.i2p.net/pipermail/i2p/2005-April/000708.html</p>
-14:06  * maestro^ beatboxes</p>
-14:06 <+cervantes> evening</p>
-14:06 <+protokol> susi23: you there?</p>
-14:06 <@jrandom> while y'all read those exciting notes, lets jump on in to 1) net status</p>
-14:06 <+protokol> oops, meeting</p>
-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</p>
-14:08 <@jrandom> anyone have any comments or concerns w/ the net status &&/|| the upcoming 0.5.0.7?</p>
-14:10 <@jrandom> if not, moving on to 2) SSU status</p>
-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?)</p>
-14:10 <@jrandom> ah, yeah, thats the tunnel throttling issue</p>
-14:10 <+protokol> will it support ftp?</p>
-14:10 <@jrandom> its a bit... overzealous</p>
-14:10 <+protokol> jk jk</p>
-14:10 <@jrandom> !thwap protokol </p>
-14:10 <+maestro^> heh, ok</p>
-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</p>
-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 ;)</p>
-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</p>
-14:14 <@jrandom> (and in the jobQueue).  i've pulled those out now, locally, and testing continues.</p>
-14:15 <@jrandom> we may have some alphas for the SSU transport this week, more likely this weekend though</p>
-14:15 <@jrandom> not much more i have to say on that - anyone have any questions?</p>
-14:16 <+Ragnarok> how much impact did the choke points have?</p>
-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</p>
-14:17 <@jrandom> but i don't expect that to occur on the live net</p>
-14:17 <+Ragnarok> yikes</p>
-14:18 <+Ragnarok> heh, ok</p>
-14:18 <@jrandom> (at least, not until we move to 0.6 ;)</p>
-14:20 <@jrandom> ok, following that lead, lets move to 3) Roadmap update</p>
-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</p>
-14:21 <+cervantes> 3) Roadmap Skew</p>
-14:21 <@jrandom> heh</p>
-14:22 <@jrandom> yeah, when you run a fast CPU, it skews the clock more frequently.  similary... ;)</p>
-14:22 <@jrandom> ^ry^rly</p>
-14:23 <+cervantes> ooh is that a hint of an ego? I never would have thought! :)</p>
-14:23 <@jrandom> but yeah, unfortunately, a 0.6 rev in april just isnt going to happen</p>
-14:23 <@jrandom> hehe</p>
-14:23 <@jrandom> cervantes: dont worry, its tempered by the fact that its taken 2 years to get this far ;)</p>
-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</p>
-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)</p>
-14:25 <+cervantes> heh, if anyone here is a little deserving of self-appreciation then I guess it would be you ;-)</p>
-14:26 <+polecat> Where you going, jrandom ?</p>
-14:27 <+cervantes> $somewhere</p>
-14:27 <@jrandom> dunno</p>
-14:27 <@jrandom> (thankfully, $somewhere is a runtime expression ;)</p>
-14:27 <+cervantes> jrandom: do you envisage a months downtime?</p>
-14:27 <+maestro^> jr: walk around the neighborhood and setup a wireless relay network from someone else's link ;]</p>
-14:27 <@jrandom> depends on the internet situation where i end up cervantes.</p>
-14:28 <@jrandom> i'm quite likely to hop online occationally of course, though</p>
-14:28 <+protokol> polecat: lol</p>
-14:28 <+cervantes> I would have though you would have got the relocation class method pretty slick by now</p>
-14:28 < Teal`c> lets move to .6 now and work the bugs out as we go along</p>
-14:28 <+cervantes> *thought</p>
-14:28 <+cervantes> cool, Teal'c you can do Q&A</p>
-14:29 <@jrandom> Teal`c: "work the bugs out" == fix the code == (have a coder who knows the code to fix it)</p>
-14:29 < Teal`c> ya, I'd like that.</p>
-14:29 < Teal`c> I know some perl</p>
-14:29  * cervantes sets bugzilla > tealc@mail.i2p</p>
-14:29 <@jrandom> word Teal`c, we can always use some help testing</p>
-14:30 <@jrandom> especially in automation of tests</p>
-14:31 <@jrandom> ok, anything else on 3) or shall we move to 4) Q status</p>
-14:31 <+polecat> I see.  Good luck getting stable Internet back.</p>
-14:31 <+ant> <jrandom> hrm, aum seems to be sleeping still</p>
-14:31 <@jrandom> thanks. i'm sure i'll find a way ;)</p>
-14:32 <@jrandom> ok, I don't really have much more to add beyond whats in the status notes</p>
-14:32 <@jrandom> aum's code is in cvs now though, so the hardcore can grab it and start hacking</p>
-14:32 <+maestro^> shweet</p>
-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</p>
-14:34 <@jrandom> (but dont ask me what the implications of licensing is when it comes to xmlrpc ;)</p>
-14:34 <@jrandom> ok, anyone have anything on 4) to bring up?</p>
-14:36 <@jrandom> ok, if not, moving on to 5) ???</p>
-14:36 <@jrandom> anyone have anything else to bring up for the meeting?</p>
-14:36 <+polecat> I would like to say a few words for this occasion.</p>
-14:37 <+polecat> Hinkle finkle dinkle doo.</p>
-14:37 <@jrandom> mmmhmm.</p>
-14:37 <@jrandom> ok, anyone have anything to bring up in a human language?  :)</p>
-14:38 < defnax> what moving on 5?</p>
-14:39 <+maestro^> long live spacerace! long live i2p!</p>
-14:39 <@jrandom> hmm defnax?</p>
-14:41 < defnax> on 5 o'clock in the morning?</p>
-14:41 < defnax> in 5 hours?</p>
-14:41 <+cervantes> wrt xmlrpc, copyright is retained on the specification, but no restrictions placed upon implementation</p>
-14:42 <@jrandom> defnax: agenda item 5: "???", where we discuss other issues</p>
-14:43 <+maestro^> jr: have you committed those optimization changes?</p>
-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)</p>
-14:43 <@jrandom> maestro^: nope</p>
-14:43  * jrandom tests before committing</p>
-14:43 <+maestro^> excellent! whats your eta on that?</p>
-14:44 <@jrandom> later tonight, maybe, else tomorrow for the release</p>
-14:45 <@jrandom> ok, if there's nothing else</p>
-14:45  * jrandom winds up</p>
-14:45  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/138.rst b/i2p2www/meetings/138.rst
new file mode 100644
index 00000000..5f3a8b17
--- /dev/null
+++ b/i2p2www/meetings/138.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 19, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/139.log b/i2p2www/meetings/139.log
index edcb3ce1..a5228acb 100644
--- a/i2p2www/meetings/139.log
+++ b/i2p2www/meetings/139.log
@@ -1,64 +1,58 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 139{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 26, 2005</h3>
-<div class="irclog">
-14:10 <@jrandom> 0) hi</p>
-14:10 <@jrandom> 1) Net status</p>
-14:10 <@jrandom> 2) SSU status</p>
-14:10 <@jrandom> 3) Unit test bounty</p>
-14:10 <@jrandom> 4) ???</p>
-14:10 <@jrandom> 0) hi</p>
-14:10  * jrandom waves</p>
-14:10 <@jrandom> (late) weekly status notes are up @ http://dev.i2p.net/pipermail/i2p/2005-April/000723.html</p>
-14:10 < bla> hi</p>
-14:11 <@jrandom> while y'all read that tome, lets jump on into 1) Net status</p>
-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</p>
-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</p>
-14:13 < laberhorst> net status: fairly well beside the not reachable prob :-)</p>
-14:13 <@jrandom> heh</p>
-14:13 <@jrandom> yeah, i'm stil not sure whats going on with your site. we can debug further after the meeting</p>
-14:14 <@jrandom> other than that, anyone else have any questions/comments/concerns wrt the net status / 0.5.0.7?</p>
-14:16 <@jrandom> ok, if not, moving on to 2) SSU status</p>
-14:16 <@jrandom> [insert hand waving here]</p>
-14:17 < Lorie> Good morning.</p>
-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</p>
-14:18 <@smeghead> i commend you for not foisting crapware on us :)</p>
-14:18 <@jrandom> i'm hoping this week we'll have some further live net tests though (fingers crossed)</p>
-14:19 <@jrandom> well, i've foisted enough bugs on y'all so far</p>
-14:19 < Lorie> you're dragging your heels, are you ?</p>
-14:19  * Lorie eyes smeghead</p>
-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?</p>
-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 :)</p>
-14:20 <@jrandom> the live net will actually handle that as well, ignoring any UDP addresses (for people who don't yet support it)</p>
-14:20 <@smeghead> and that's given us lots of protein, but we don't want to over-indulge</p>
-14:21 < bla> jrandom: Nice! That's good for the transition</p>
-14:23 <@jrandom> aye, thats the hope.  still, there's lots of work to do[/obligatory]</p>
-14:23 <@jrandom> while our transport is SSU - "SEMIreliable Secure UDP" - we still need to try to be kind of reliable</p>
-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</p>
-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</p>
-14:26 < Lorie> yes</p>
-14:26 < Lorie> do be reliable; time is a luxury one has</p>
-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?</p>
-14:28 < jrandom2p> consider us moved</p>
-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.</p>
-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 ;)</p>
-14:30 < jrandom2p> but anyway, y'all can read all that stuff.  does anyone have any questions on it?</p>
-14:31 < jrandom2p> ok, if not, moving on to 4) ???</p>
-14:32 <@smeghead> anyone tried that emma code coverage suite?</p>
-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?</p>
-14:33 < jrandom2p> not i</p>
-14:33 <@duck> *hick*</p>
-14:34 <@smeghead> either duck is inebriated, or he has spotted a redneck</p>
-14:34 <@duck> !former</p>
-14:35 < jrandom2p> (to evaluate as a shell command or c/java... ;)</p>
-14:36 < jrandom2p> anyone else have anything to bring up for the meeting?</p>
-14:36  * jrandom2p likes short meetings, leaves more time for coding</p>
-14:36 <@smeghead> and drinking apparently :)</p>
-14:36 <@duck> & drinking</p>
-14:37 <@smeghead> bah lag</p>
-14:37 < jrandom2p> heh</p>
-14:38 < jrandom2p> ok, time to get back to dri^Wworking</p>
-14:38  * jrandom2p winds up</p>
-14:38  * jrandom2p *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/139.rst b/i2p2www/meetings/139.rst
new file mode 100644
index 00000000..cc307cb8
--- /dev/null
+++ b/i2p2www/meetings/139.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 26, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/140.log b/i2p2www/meetings/140.log
index dd03992e..3ab4212a 100644
--- a/i2p2www/meetings/140.log
+++ b/i2p2www/meetings/140.log
@@ -1,199 +1,193 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 140{% endblock %}
-{% block content %}<h3>I2P dev meeting, May 3, 2005</h3>
-<div class="irclog">
-14:08 < jrandom> 0) hi</p>
-14:08 < jrandom> 1) Net status</p>
-14:08 < jrandom> 2) SSU status</p>
-14:08 < jrandom> 3) i2phex</p>
-14:08 < jrandom> 4) awol</p>
-14:08 < jrandom> 5) ???</p>
-14:08 < jrandom> 0) hi</p>
-14:08  * jrandom waves</p>
-14:08 < jrandom> weekly status notes posted nearly an hour early @ http://dev.i2p.net/pipermail/i2p/2005-May/000738.html</p>
-14:09  * Masterboy waves back:P</p>
-14:10 < jrandom> ok, jumping into 1) Net status</p>
-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</p>
-14:11 < jrandom> hopefully it'll hold up well enough though, we'll see</p>
-14:11 < Masterboy> no big probs for me and i can't remember the little ones.</p>
-14:11 < jrandom> heh cool</p>
-14:11 < jrandom> anyone else have any questions/comments/concerns wrt the current net status?  </p>
-14:11 < sirup> is azureus using out proxies?</p>
-14:12 < jrandom> heh i hope not</p>
-14:12 < jrandom> its probably just people trying it out after seeing the option listed</p>
-14:12 <@smeghead> most will bugger off in a week or so</p>
-14:13 < Masterboy> :D</p>
-14:13 <+DrWoo> smeghead: that's not good</p>
-14:13 < sirup> so they wrap two different networks under one hood</p>
-14:13 <+cervantes> it's not mentioned in the az release notes</p>
-14:13 <+cervantes> although it is listed in the plugins section</p>
-14:14 < ant> <cat-a-puss> There is a link that mentions it on the left of their main page</p>
-14:14 < jrandom> it'll be great once 0.6 is out and we can handle the increased user load</p>
-14:14 <+DrWoo> jrandom: what is the current status of getting out a build to cope with more users?</p>
-14:14 < jrandom> yeah, azureus is currently our largest referrer to the website, well more than even the /. references</p>
-14:15 < jrandom> DrWoo: no chance.  </p>
-14:15 < sirup> don't let that stress you and put out 0.6 too early</p>
-14:15  * eAi sets unreasonable bandwidth limit to stop people haxoring my download speed</p>
-14:15 < ant> <cat-a-puss> how big of a network will .6 support?</p>
-14:15 < jrandom> DrWoo: 0.6 is the solution, and that'll be ready when its ready :)</p>
-14:15 <+cervantes> there are 445 google hits for "i2p" and "azureus"</p>
-14:15 < jrandom> heh eAi </p>
-14:16 <+cervantes> I must say I was impressed with the throughput of the test SSU net</p>
-14:16 < Masterboy> w00t cervantes:)</p>
-14:16 <+DrWoo> jrandom: you know I love ya but your shedule is slipping like a $5 hooker's panties ;)</p>
-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.</p>
-14:16 <+cervantes> managed to max out my DSL connection with a straight http file transfer</p>
-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</p>
-14:17 < sirup> cervantes: 0 hops both ends ;)</p>
-14:18 < jrandom> sirup: sure, but the point is the SSU transport was able to handle it</p>
-14:18 <+DrWoo> jrandom: yikes that sux, good luck :)</p>
-14:18 < Teal`c__> there is an alternative.  I'm calling toad, he'll finish it up while you're in tahiti</p>
-14:18 <@smeghead> movin' on up, to the east side, to a deluxe apartment in the skyyyyy</p>
-14:18 < shendaras> You have a place in mind, jrandom, or is it up in the air where you end up?</p>
-14:19 <+cervantes> *mute*</p>
-14:19 < jrandom> heh</p>
-14:19 < jrandom> i think i know what country i'll end up in.  beyond that, not really</p>
-14:19 < jrandom> ok, anyway, back onto the agenda</p>
-14:19 < jrandom> anything else on 1) Net status, or shall we move on to 2) SSU status?</p>
-14:20 < Masterboy> move</p>
-14:20 < jrandom> consider us moved</p>
-14:21 < jrandom> ok, as described in the status notes and as cervantes said a minute ago, things are looking promising</p>
-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</p>
-14:23 < Masterboy> how can one join a test net?:P</p>
-14:23 < jrandom> thats the thing - the ssu testing is done on the live net</p>
-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.  </p>
-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.</p>
-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</p>
-14:25 < Masterboy> thanks:)</p>
-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</p>
-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?</p>
-14:27 < Teal`c__> jrandom: can we use ssu while your gone ?</p>
-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</p>
-14:29 < shendaras> What's your new SACK technique? =)</p>
-14:29 < jrandom> i've still got almost a week of hacking time left, so there's going to be more improvement</p>
-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)?</p>
-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</p>
-14:31 < jrandom> bla: correct, they never establish a TCP connection if SSU is available</p>
-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</p>
-14:31 <+bla> jrandom: That's good, but it means I'll have to update my theland.i2p scripts :(... ;)</p>
-14:32 < jrandom> heh well, yeah too bad ;)</p>
-14:32 < jrandom> (the new peers.jsp may be what you're after though)</p>
-14:33 <+bla> jrandom: I'll have a look. But I don't plan on using SSU until it is ready, though</p>
-14:33 <+cervantes> perhaps we should all stay on TCP so bla doesn't have to do any coding</p>
-14:34 < jrandom> heh </p>
-14:34 < jrandom> cool bla, yeah, no rush</p>
-14:34 <+cervantes> ;)</p>
-14:34 <+bla> cervantes: ;) </p>
-14:35 <+cervantes> will there be any situations where an SSU connection is not appropriate and a TCP one would be preferred?</p>
-14:36  * Masterboy pokes jr</p>
-14:36 < jrandom> the current default setup prefers an established TCP connection to an unestablished SSU connection</p>
-14:36 < jrandom> (you can override that with a config flag, i think its documented in the history.txt)</p>
-14:37 <@smeghead> there are some people who've claimed their ISPs block UDP altogether</p>
-14:37 < jrandom> but in general, no i can't think of why you'd want to go TCP when SSU is available</p>
-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</p>
-14:37 < jrandom> smeghead: there are some people who've claimed elvis was a martian</p>
-14:38 <+cervantes> so it's good just as a fallback</p>
-14:38 < jrandom> cervantes: none i can think of, as long as ssu is available by both peers</p>
-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.</p>
-14:40 < jrandom> if we allow TCP only nodes, that means everyone must be reachable through TCP and UDP</p>
-14:41 < Teal`c__> :~(</p>
-14:41 < jrandom> for this summer, we'll probably support both, but i'm inclined to lean towards udp only</p>
-14:41 < entroy> Hi, can any one tell me where I can go to ask a q about setting up 12p and Azureus?</p>
-14:41 < jrandom> (until 2.0)</p>
-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</p>
-14:42 <+cervantes> here they come, repel borders :)</p>
-14:42 < jrandom> cervantes: anyone who can make it onto irc is one of us :)</p>
-14:42 <@smeghead> better call the Minutemen</p>
-14:43 < Teal`c__> liverpool or chelsea ?!</p>
-14:43 < entroy> ok, thx</p>
-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.</p>
-14:43 <+cervantes> jrandom: are you sure about that...someone mentioned an mschat client earlier</p>
-14:43 <+cervantes> ;-)</p>
-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</p>
-14:45 < Teal`c__> <steve> # Appears as TIKI</p>
-14:45 < jrandom> streaming lib messages between the endpoint and gateway is only 4KB - up to 8 bits, or 2 bytes wiwth the bitfields</p>
-14:45 < jrandom> that is, assuming the absolute smallest MTU</p>
-14:46 < jrandom> with 1492 (or 1472, depending on who is counting), you can handle most anything in a single bitfield byte</p>
-14:46 < ant> <cat-a-puss> jrandom: ah, so the bitfields are only for fragments, not for each packet then?</p>
-14:47 < jrandom> right, if a message is partially received, you send back the bitfield for the received fragments of that message</p>
-14:47 < ant> <cat-a-puss> ok</p>
-14:47 < jrandom> message ids are unfortunately completely random and unordered, so we can't use tcp style sequence numbers</p>
-14:48 < jrandom> (and, well, we dont want that overhead either)</p>
-14:49 < jrandom> ok, if there's nothing else on 2) SSU, lets move on to 3) i2phex</p>
-14:49 < jrandom> sirup: you 'round?</p>
-14:49 < ant> <cat-a-puss> quickly:why random?</p>
-14:50  * sirup is lurking</p>
-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 #)</p>
-14:50 < ant> <cat-a-puss> ok</p>
-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</p>
-14:52 < sirup> well. first tests were successfull</p>
-14:52 < jrandom> [w3wt]</p>
-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</p>
-14:53 < sirup> so it's not run and gun right now :)</p>
-14:53 < sirup> but i also expected that, cause i didn't change anything concerning timeouts and such</p>
-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</p>
-14:55 < sirup> several instances on the same machine only get you so far...</p>
-14:55 < sirup> oh. and any experience/input is welcome. best done wiht mail to sirup@mail.i2p</p>
-14:56 < sirup> a forum would be great too (i can't have any at my destination, 'cause i'm not 24/7)</p>
-14:56 < sirup> that's it :)</p>
-14:56 < jrandom> wikked</p>
-14:56 < jrandom> cervantes: any way we could get an i2phex section added in there?</p>
-14:57 <+cervantes> sure could</p>
-14:57  * sirup wonders who's downloading that crappy commons licensed music from me :)</p>
-14:58 <@smeghead> hey, you can build more crap on top of that crap at least :)</p>
-14:58 <+cervantes> sirup: I take it "sirup" is your moniker on the forum</p>
-14:58 < sirup> that would be neat</p>
-14:58 < sirup> yes</p>
-14:59 < ant> <BS314159> status notes?</p>
-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 :)</p>
-15:00 <@smeghead> mailing list?</p>
-15:00 < RevDuck> or www.i2phex.tk</p>
-15:01 < sirup> mailing list would also be nice, of course</p>
-15:01 < sirup> lol. i2phex.tk is fake. get your dialers there :)</p>
-15:01 <+cervantes> I2Phex forum added</p>
-15:01 < jrandom> !stab duck</p>
-15:02 <+cervantes> sirup is moderator</p>
-15:02 < Masterboy> :D</p>
-15:02 <+cervantes> sirup: let me know if you want to change the description text</p>
-15:02 < jrandom> sirup: if you'd like an i2phex and i2phex-cvs list, lemmie know, they're easy enough to add</p>
-15:02 < jrandom> (though at the moment, it may be simpler to just use the i2p list)</p>
-15:02 < sirup> cervantes, thanks a bunch </p>
-15:03 < sirup> yeah. forum will do atm</p>
-15:04 < jrandom> ok cool.  anyone have anything else on 3) i2phex?</p>
-15:05 < jrandom> if not, moving on briefly to 4) awol</p>
-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</p>
-15:05 <+bla> jrandom: You're finally being canceled by Operations?</p>
-15:06 < jrandom> nah, the CIA is just reassigning me^Ula la la</p>
-15:06 <@smeghead> no the black budget was increased this quarter</p>
-15:07 <+cervantes> *the elephant has flown the nest* repeat *the elephant has flown the nest* over</p>
-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 </p>
-15:07  * smeghead supresses elephantitis joke</p>
-15:08 < jrandom> so your homework assignment while i'm gone is to pick something neat that you want to build, and build it ;)</p>
-15:08  * cervantes staunches smeghead's bleeding temples</p>
-15:08 < jrandom> (be it a webpage or a flying pony)</p>
-15:09 < jrandom> ok, moving on to 5) ???</p>
-15:09 < jrandom> anyone else have anything they want to bring up for the meeting?</p>
-15:09 < shendaras> We'll miss you...</p>
-15:09 <@smeghead> yeah who's chairing the meetings while you're gone?</p>
-15:09 <+mancom> has aum shown up during the last week?</p>
-15:09 <@smeghead> mancom: negative</p>
-15:10 < Masterboy> brother duck?:P</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 :)</p>
-15:11 < jrandom> mancom: he was by #i2p-chat the other day briefly</p>
-15:12 < RevDuck> maybe only hold meetings when there is actually something to report though</p>
-15:12 <+cervantes> it's ok I'm writing a jrandom simulation script</p>
-15:12 <+cervantes> * w3wt</p>
-15:12 < jrandom> nothing wrong with 5 minute meeting ;)</p>
-15:13 <+cervantes> * jrandom flings a mud at his flying pony</p>
-15:13  * smeghead writes a cervantes simulation script that writes a jrandom simulation script</p>
-15:13  * jrandom writes a smeghead simu[CRASH]</p>
-15:13 <+cervantes> oop gotta work on that grammar</p>
-15:14 <@smeghead> haha</p>
-15:14 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-15:14  * cervantes writes an aum simula.........</p>
-15:14 <@smeghead> java.util.RecursiveIdiocyException</p>
-15:15 < jrandom> speaking of which.. ;)</p>
-15:15  * jrandom winds up</p>
-15:15  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/140.rst b/i2p2www/meetings/140.rst
new file mode 100644
index 00000000..f2b12b32
--- /dev/null
+++ b/i2p2www/meetings/140.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 3, 2005
+============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/141.log b/i2p2www/meetings/141.log
index 136227cb..fa86a384 100644
--- a/i2p2www/meetings/141.log
+++ b/i2p2www/meetings/141.log
@@ -1,135 +1,129 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 141{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 2, 2005</h3>
-<div class="irclog">
-13:53 < jrandom2p> ok, as i'm here, is there anyone interested in having a brief meeting wrt the notes (or something else)?</p>
-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?</p>
-13:54 <@smeghead> sure</p>
-13:54 <+protokol> is icepick here?</p>
-13:55 <+protokol> i am wondering if i2p-mnet is testable yet and/or an ETA on it</p>
-13:55 < jrandom2p> idle for 9 hours atm..</p>
-13:56 < jrandom2p> from the channel logs, it didnt sound workable, but he did get the basic SAM integration going</p>
-13:56 < jrandom2p> i'm sure we'll hear more when there's more to hear</p>
-13:56 <+protokol> cooool</p>
-13:57 < jrandom2p> smeghead: has -1 fixed your port migration issue?</p>
-13:57 <@smeghead> i haven't noticed any funny business</p>
-13:58 <@smeghead> in 3 days or so</p>
-13:58 <@cervantes> glad to say I haven't had a loss of service for a day or two</p>
-13:58 <@smeghead> i think i can call it fixed</p>
-13:58 < jrandom2p> wr0d</p>
-13:58 < jrandom2p> (^2)</p>
-13:59 <@cervantes> and thetower is only reconnecting every 4 minutes now...so the network health in general must be improving</p>
-13:59 < jrandom2p> heh</p>
-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.</p>
-14:00 < jrandom2p> hmm</p>
-14:00 < jrandom2p> was it irc only, or were you losing many peers?</p>
-14:00 <@cervantes> gremlins</p>
-14:01 <+thetower> Is it possible that changing the router.config file without restarting i2p would have caused the crashes?</p>
-14:01 < jrandom2p> hmm, no, i change router.config often</p>
-14:01 < jrandom2p> or, is there a particular change you're concerned with?</p>
-14:02 <@cervantes> I remember copying over my jbigi lib once while the router was still running.... THAT caused problems ;-)</p>
-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.</p>
-14:02 < jrandom2p> heh yeah cervantes, that'll always kill the router</p>
-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...</p>
-14:04 <+thetower> Well, it had fairly reasonable lower limits so I guess that wasn't it.</p>
-14:04 < jrandom2p> ok cool, just checkin~ :)</p>
-14:05 < jrandom2p> i suppose we'll have 0.6.0.1 tomorrow then, as -1 seems to be a pretty good improvement</p>
-14:05 < jrandom2p> it'll be backwards compat, etc, yadda yadda.</p>
-14:06 < jrandom2p> anything else y'all know that needs to get pushed out there?</p>
-14:06 < jrandom2p> whats the status with i2phex?</p>
-14:06 <@smeghead> maybe push the cvs hosts.txt to dev.i2p.net... the current one is months old</p>
-14:06 < jrandom2p> i did the other night iirc</p>
-14:07 <@smeghead> sirup hasn't been around in a couple of weeks</p>
-14:07 < jrandom2p> ooh, hmmm..</p>
-14:07 <@smeghead> it's summer though</p>
-14:07 <@smeghead> maybe on holiday or something</p>
-14:08 <@cervantes> or he's been bum-raped by the riaa</p>
-14:08 < jrandom2p> ah yeah, its up there (it was just cached on squid.i2p)</p>
-14:08 <@smeghead> riaaped?</p>
-14:09 < jrandom2p> ($Id: meeting141.html,v 1.2 2005-08-04 16:21:39 duck Exp $)</p>
-14:09 < jrandom2p> *cough*</p>
-14:09 <+bar> there are some things that need to be added to bugzilla, like i2p 0.6 and java 1.5</p>
-14:09 <@smeghead> ok</p>
-14:09 < jrandom2p> ah right, yeah i still havent gotten my laptop online yet (grr)</p>
-14:10 < jrandom2p> ((the weekly status notes needed to be burnt to cd... a 1KB cd...))</p>
-14:10 < jrandom2p> woah heya mihi</p>
-14:10 <@duck> hi mihi!</p>
-14:10 < mihi> hi all :)</p>
-14:10 <@cervantes> could be dm :)</p>
-14:10 < jrandom2p> heh</p>
-14:10 <@smeghead> indeed</p>
-14:10 <@cervantes> 'lo mihi</p>
-14:10 < mihi> seemed to require a bit of tweaking in the config file till my router believed that *only* 8887/udp is open...</p>
-14:11  * jrandom2p mentioned i2ptunnel in the status notes and mihi appears ;)</p>
-14:11 < jrandom2p> ah, hmm, the i2np.udp.fixedPort=true thing?</p>
-14:11 < mihi> hmm? was it there?</p>
-14:11  * mihi read status notes only quickly</p>
-14:11 < mihi> hmm... is that better solution?</p>
-14:12  * mihi just reset the port to 8887 and restarted hard until it did not change the port...</p>
-14:12 < jrandom2p> whats the tweak you did to your router.config to make it believe only 8886?</p>
-14:12 < jrandom2p> er, 8887</p>
-14:12 < jrandom2p> hah</p>
-14:12 <@cervantes> can we perhaps rename I2PTunnel as you suggested to something like I2PProxy...?</p>
-14:12 < jrandom2p> ok, yeah, use i2np.udp.fixedPort=true</p>
-14:12 < jrandom2p> (deployed in 0.6-1 and to be released asap as 0.6.0.1)</p>
-14:12 <@cervantes> it can get very confusing talking about "the tunnel config page"</p>
-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?</p>
-14:13 < mihi> hmmkay...</p>
-14:14 < mihi> seems that i2p changed the port once again</p>
-14:14 < mihi> expect me to be away soon :)</p>
-14:14 < jrandom2p> thetower: yes, it should automatically detect, but there are some funky tap dances that we~re going through at the moment </p>
-14:14 <@cervantes> mihi: d'you have the latest cvs?</p>
-14:14 < jrandom2p> thats what the whole PeerTest thing is about (making it so that we always automatically configure it properly)</p>
-14:14 < mihi> nope.</p>
-14:14 <@cervantes> mihi: that would be why then :)</p>
-14:15 < mihi> only the version from i2pupdate.zip</p>
-14:15 <@cervantes> mihi: 0.6 has RandomPort (tm) functionality</p>
-14:15 < jrandom2p> heh</p>
-14:16 <@cervantes> :)</p>
-14:16 <+ant> * mihi 'd like FixedPorto functionality :)</p>
-14:16 <+ant> <mihi> and disconnected...</p>
-14:16 <@cervantes> then you'd need  0.6-1 FixedPort Pro</p>
-14:16 < jrandom2p> heh</p>
-14:16 < jrandom2p> ok, anyone else have something to bring up for the meeting?</p>
-14:16 <@cervantes> or wait for 0.6.0.1</p>
-14:17 < jrandom2p> how has the latency/throughput been, barring the intermittent reachability?</p>
-14:17 <+ant> <mihi> hmm. here is a cvs checkout from 2004-10-06. should try to update it :)</p>
-14:17 < jrandom2p> !thwap mihi</p>
-14:18 <@cervantes> I got i2pinstall.jar at 110k/sec from dev.i2p yesterday on a single stream</p>
-14:18 < jrandom2p> nice</p>
-14:19 <@cervantes> and 320k/sec using multiple</p>
-14:19 < jrandom2p> w0ah</p>
-14:19 < jrandom2p> 0hop, i assume</p>
-14:19 < jrandom2p> (dev.i2p is 0hop)</p>
-14:19 <@cervantes> yup</p>
-14:19 < jrandom2p> ((in case you couldn't tell ;)</p>
-14:19 <@cervantes> ;-)</p>
-14:19 <+thetower> download to:    GTA San Andreas</p>
-14:19 <+thetower> download rate:  28.51 kB/s</p>
-14:20 <@cervantes> that was from multiple sources though...</p>
-14:20 < jrandom2p> ah cool thetower </p>
-14:20 <@cervantes> managed to push squid.i2p up to about 280</p>
-14:21 < lucky> jrandom2p :)</p>
-14:21 < lucky> would you push the new hosts.txt to the site</p>
-14:21 <@cervantes> lucky: tis done</p>
-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</p>
-14:22 < jrandom2p> (so it delays AVG(tunnelTestTime/2) but doesnt waste bw or lose messages)</p>
-14:22 <@cervantes> to hide the fact that it's a 0 hop tunnel?</p>
-14:22 < lucky> i wonder if I2P will ever have speeds decent enough tha ti could let people log into my virtu-vax</p>
-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</p>
-14:23 < jrandom2p> (otoh, 1 to 2 to 3 to 4hops don't have such a dramatic cut)</p>
-14:23 <@cervantes> so will i2p effectively have a bandwidth cap</p>
-14:23 < jrandom2p> ((as once you force true tunnel operation, each intermediate hop isn't much))</p>
-14:24 < jrandom2p> nah cervantes, large windows + delays </p>
-14:24  * cervantes cancels his plans for HDTV streaming anonymous pr0n</p>
-14:24 < jrandom2p> you can just have more messages in the air to get the same rate</p>
-14:25 <@cervantes> ah right</p>
-14:25 < jrandom2p> (but it'll take a few more rtts to get to the larger window, of course)</p>
-14:25 < jrandom2p> ok, anyone have anything else to bring up?</p>
-14:26 < mihi> bring up a *baf*er :)</p>
-14:26 <@cervantes> it's gone rusty with missuse</p>
-14:27 < jrandom2p> heh i suppose its time ;)</p>
-14:27  * jrandom2p winds up</p>
-14:27  * jrandom2p *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/141.rst b/i2p2www/meetings/141.rst
new file mode 100644
index 00000000..75e11e52
--- /dev/null
+++ b/i2p2www/meetings/141.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 2, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/142.log b/i2p2www/meetings/142.log
index 60f92ed9..73fb614a 100644
--- a/i2p2www/meetings/142.log
+++ b/i2p2www/meetings/142.log
@@ -1,94 +1,88 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 142{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 9, 2005</h3>
-<div class="irclog">
-13:11 < jrandom2p> 0) hi</p>
-13:11 < jrandom2p> 1) 0.6.0.2</p>
-13:11 < jrandom2p> 2) roadmap update</p>
-13:11 < jrandom2p> 3) ???</p>
-13:11 < jrandom2p> 0) hi</p>
-13:11  * jrandom2p waves</p>
-13:11 <+detonate> hi</p>
-13:11 < jrandom2p> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000839.html</p>
-13:12 < jrandom2p> ok, jumping in briefly to [1-2] before the freeforall..</p>
-13:12 < jrandom2p> 1) 0.6.0.2</p>
-13:12 < jrandom2p> its out.  and stuff</p>
-13:12 < jrandom2p> anyone have any questions/comments/concerns w/ 0.6.0.2?</p>
-13:13 < jrandom2p> if not, moving on to 2) roadmap update</p>
-13:13 < jrandom2p> the, er, roadmap has been updated.  and stuff ;)</p>
-13:14 < duck> you aussie</p>
-13:14 <+bla> jrandom: There still are intermittent problems contacting a destination, even when it's normally up</p>
-13:14  * postman can second this</p>
-13:14  * detonate can third that</p>
-13:14 <+bla> jrandom: E.g., forum.i2p works fine, then after a few minutes it doesn't, and requires a few reloads</p>
-13:15  * bla firsted it ;)</p>
-13:15 < jrandom2p> hmm, aye, i've heard reports of that.  with 0.6.0.2 as well, right?</p>
-13:16 <+postman> indeed sir</p>
-13:16 <+bla> Yes, 0.6.0.2</p>
-13:16 <+bla> Could be netDb trouble, or poor selection of peers to put in tunnels (or something else)</p>
-13:16 < jrandom2p> 'k</p>
-13:17 < jrandom2p> the tunnel peer selection has been pretty bad lately, as has netDb store flooding</p>
-13:17 < jrandom2p> (see your /oldstats.jsp for tunnel request failure counts)</p>
-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</p>
-13:19 < jrandom2p> nice</p>
-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</p>
-13:19 <+bla> Though I really should get going at the classification algorithms again... ;)</p>
-13:20 < jrandom2p> i've been doing profile/stat analysis, but no solid results yet</p>
-13:21 < jrandom> that would be cool bla :)</p>
-13:25 < jrandom2p> ok, anything else on 2) roadmpa update?  :)</p>
-13:26 < jrandom2p> if not, moving on to 3) ???</p>
-13:26 <+detonate> do you think it would be useful to shitlist peers with high failure/duprecv rates compared to the mode?</p>
-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</p>
-13:27 < jrandom> as long as messages are getting through, messages are getting through</p>
-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)</p>
-13:29 <+detonate> hmm</p>
-13:29 <+detonate> ok</p>
-13:29 < jrandom> but perhaps we need to drop sessions for peers who are in such congested cons</p>
-13:29 <+detonate> good point</p>
-13:34 < jrandom> ok, anyone else have something to bring up for 3) ???</p>
-13:34 < luckypunk> o,oh, maybe you should wait ti leveryone is back</p>
-13:34 < luckypunk> before asking critical questions :P</p>
-13:35 < jrandom2p> bah, they've got the mailing list ;)</p>
-13:35 < luckypunk> well</p>
-13:35 < luckypunk> i guess this is the right place to whine</p>
-13:36 < luckypunk> I2P still uses a bit of CPU</p>
-13:36 < luckypunk> but not as much as before</p>
-13:36 < luckypunk> true, i haven't run it since the 5.0 days</p>
-13:36 < luckypunk> but yeah</p>
-13:36 < luckypunk> er</p>
-13:36 < luckypunk> 0.5.0</p>
-13:36 < jrandom2p> cool, which of your boxes works with it?</p>
-13:36 < luckypunk> er</p>
-13:36 < luckypunk> ffs</p>
-13:36 < luckypunk> i haven't used it since 0.6.0.0</p>
-13:36 < luckypunk> it works fine with the pentium 2</p>
-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</p>
-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</p>
-13:39 < jrandom2p> are you on 0.6.0.2 now luckypunk?</p>
-13:39 <@smeghead> detonate: that's trusted route stuff... later on in the roadmap :)</p>
-13:39 < luckypunk> no</p>
-13:39 < luckypunk> i haven't run it since 0.6.0.0</p>
-13:39 <@smeghead> *restricted route</p>
-13:40 < luckypunk> but it's CPU use seemed much less.</p>
-13:40 <+detonate> heh, it should be there as soon as there's introducers :)</p>
-13:40 < jrandom2p> ah yeah detonate, the introducer selection could certainly be configurable, but it'll probably be a hidden advanced config option ;)</p>
-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</p>
-13:41 < luckypunk> ok</p>
-13:41 <@smeghead> what if an introducer doesn't want you selecting them all the time?</p>
-13:41 < luckypunk> i have the feeling I2P would on a dedicated mid range pentium now.</p>
-13:41 < jrandom> smeghead: then they say "fuck off, i'm not going to serve as an introducer for you"</p>
-13:42 < jrandom> and peers will have multiple introducers, so it'll be balanced</p>
-13:42 < jrandom> (and its only 2 packets to wire up a new peer, not all packets communicated)</p>
-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</p>
-13:45 < ant> <jme___> q. where can i find a description of this voting system ?</p>
-13:45 < jrandom> majority doesnt make any sense</p>
-13:45  * jrandom doesnt trust voting any further than i can throw it</p>
-13:45 < jrandom> (especially in light of sybil)</p>
-13:45 < jrandom> an introducer is working if a new peer can contact you through it</p>
-13:47 <+detonate> what's the status of vanguard, that's sort of related</p>
-13:47 <+detonate> while smeghead is around</p>
-13:51 < jrandom> ok, if there isn't anything else...</p>
-13:51  * jrandom winds up </p>
-13:51  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/142.rst b/i2p2www/meetings/142.rst
new file mode 100644
index 00000000..b290c358
--- /dev/null
+++ b/i2p2www/meetings/142.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 9, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/143.log b/i2p2www/meetings/143.log
index b62d56f8..6d26ce71 100644
--- a/i2p2www/meetings/143.log
+++ b/i2p2www/meetings/143.log
@@ -1,56 +1,50 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 143{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 16, 2005</h3>
-<div class="irclog">
-13:09 <@jrandom> 0) hi</p>
-13:09 <@jrandom> 1) PeerTest status</p>
-13:09 <@jrandom> 2) Irc2P</p>
-13:09 <@jrandom> 3) Feedspace</p>
-13:09 <@jrandom> 4) meta</p>
-13:09 <@jrandom> 5) ???</p>
-13:09 <@jrandom> 0) hi</p>
-13:09  * jrandom waves</p>
-13:09 <@jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000842.html</p>
-13:10 <@jrandom> (which i'm sure you've all read studiously)</p>
-13:10 <@postman> hi</p>
-13:10 <+cervantes> hmm changate perl scripts...will give them a go...</p>
-13:10 <+cervantes> hi</p>
-13:10 <@jrandom> 1) peer test status</p>
-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?</p>
-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</p>
-13:11 <@jrandom> (we do that now with tcp)</p>
-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</p>
-13:13 <@jrandom> ok, moving on to 2) irc2p</p>
-13:13 <@jrandom> y'all are here, so you know whats up :)</p>
-13:13 <@jrandom> nice work postman & smeghead</p>
-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</p>
-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)</p>
-13:17 <@postman> :)</p>
-13:17  * Complication is reading frosk's blog</p>
-13:18 <@jrandom> ok, perhaps frosk'll fill us in with a post there when there's more info to share</p>
-13:19 <@jrandom> movin' on briefly to 4) meta</p>
-13:19 <@jrandom> what are y'all's thoughts on 8p GMT meetings?  too early, too late, just right?</p>
-13:21  * jrandom holds back the crowds</p>
-13:21 <+Complication> I'd like to say something useful, but cannot seem to find my world clock...</p>
-13:21 <@jrandom> google://what+time+is+it</p>
-13:22 <+Complication> :)</p>
-13:22 <@jrandom> ok, movin' on to 5) ???</p>
-13:22 <@jrandom> anyone have anything else they want to bring up?</p>
-13:23 <+susi23> well</p>
-13:23 <+susi23> not officially ;)</p>
-13:24 <+Complication> It's been an unusually stable time.</p>
-13:24 <+Complication> Aside from occasional "message invalid" (or was it "packet invalid"), I can't find errors to report. :o</p>
-13:24 <@postman> my errors are already reported :)</p>
-13:24 <@jrandom> coo', though thats unfortunately a symptom of undetected errors Complication, since there's still some stuff not going as it Should</p>
-13:25 <@jrandom> but, progress, ever onwards</p>
-13:25 <@jrandom> perhaps we're seeing a lot of restricted routes out there due to the udp situation</p>
-13:25 <+susi23> we started a new idlerpg on #idle and you are all invited to join :)</p>
-13:25 <@jrandom> (and perhaps there's a bunch of other things...)</p>
-13:25 <@jrandom> w00t susi23 </p>
-13:26 <+susi23> :P</p>
-13:30 <@jrandom> ok, anyone else have something to bring up for the meeting?</p>
-13:32 <@jrandom> ok, if there's nothin' else</p>
-13:32  * jrandom winds up</p>
-13:32  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/143.rst b/i2p2www/meetings/143.rst
new file mode 100644
index 00000000..fa707358
--- /dev/null
+++ b/i2p2www/meetings/143.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 16, 2005
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/144.log b/i2p2www/meetings/144.log
index ee66a9ea..bd1e82a8 100644
--- a/i2p2www/meetings/144.log
+++ b/i2p2www/meetings/144.log
@@ -1,149 +1,143 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 144{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 23, 2005</h2>
-<div class="irclog">
-12:01 < jrandom> 0) hi</p>
-12:01 < jrandom> 1) 0.6.0.3 status</p>
-12:01 < jrandom> 2) IRC status</p>
-12:01 < jrandom> 3) susibt</p>
-12:01 < jrandom> 4) Syndie</p>
-12:01 < jrandom> 5) ???</p>
-12:01 < jrandom> 0) hi</p>
-12:01  * jrandom waves</p>
-12:01 < lucky> hi</p>
-12:02 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-August/000857.html</p>
-12:02 < lucky> hihihihi</p>
-12:02 < jrandom> hi lucky </p>
-12:02 < jrandom> ok, jumping into 1) 0.6.0.3 status</p>
-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?</p>
-12:04 < gott> What's the deal with 'Unknown' ?</p>
-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</p>
-12:04 < jrandom> gott: there are two paragraphs in the email related to that - do you have any specific questions beyond those?</p>
-12:05 < jrandom> or is there some point i could clarify?</p>
-12:05 < gott> No, I just haven't read the bloody email.</p>
-12:05 < jrandom> heh</p>
-12:05 < jrandom> well, scroll up five lines and read the bloody email ;)</p>
-12:06 < jrandom> ok, anyone else have any questions on 0.6.0.3?</p>
-12:07 < jrandom> if not, moving on to 2) IRC status</p>
-12:07 < modulus> sorry guys, but need to leave. later all.</p>
-12:08 < jrandom> beyond whats in the mail, postman/cervantes/arcturus: y'all have anything you want to bring up?</p>
-12:08 < jrandom> l8r modulus</p>
-12:08 <+arcturus> on 1)?</p>
-12:08 <+arcturus> oh sorry</p>
-12:08 < gott> Hmm.</p>
-12:08 <+arcturus> 2) it is now</p>
-12:09 < gott> How much upstream bandwidth does IRC over i2p usually take at the moment ?</p>
-12:09 <+arcturus> netsplits are history</p>
-12:09 <+arcturus> gott: i coudln't say that without compromising my router's anonymity</p>
-12:09 < gott> No, no, no.</p>
-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</p>
-12:10 < gott> Does it require a commercial line ?</p>
-12:10 < jrandom> nice1 arcturus</p>
-12:10 < gott> jrandom: I mean to say, to host.</p>
-12:10 < jrandom> gott: to operate a server or a client?</p>
-12:10 < jrandom> ah</p>
-12:10 <+arcturus> gott: i couldn't say that without compromising my router's anonymity</p>
-12:10 < gott> server.</p>
-12:10  * jrandom knows not.  probably less when you have just one ircd</p>
-12:10 < gott> So are you running a modified unrealircd ?</p>
-12:11 < jrandom> say, add a factor of 1.3 to the client usage for a single server</p>
-12:11 <+arcturus> i'd like to also add that inter-server lag is steady and very very low</p>
-12:11 < gott> I assume you are, since there doesn't seem to be a VERSION command</p>
-12:11 <+arcturus> i disabled version</p>
-12:12 < gott> Are your modifications open-source ?</p>
-12:12 <+arcturus> maybe we're running unreal, maybe we aren't :)</p>
-12:12 < gott> You should put them up so others can start their own private networks.</p>
-12:12 <+arcturus> i can't tell you without compromising security</p>
-12:12 < gott> security through obscurity, sweet.</p>
-12:12 < jrandom> word arcturus.  i'm seeing something like 0-2s lag on average (at the moment, less than irssi's lag detector)</p>
-12:12 <+arcturus> no, it's only one layer of security</p>
-12:13 <+arcturus> and it only serves as a deterrent, no substitute for technical security measures</p>
-12:15 < jrandom> arcturus: how goes with vanguard?</p>
-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 :)</p>
-12:16 < jrandom> heh coo'</p>
-12:16 <+arcturus> vanguard will be most effective against bots, the hashcash measure is a separate deal</p>
-12:16 <+arcturus> i'm concerned about hashcash now though</p>
-12:17 <+arcturus> with the latest attacks against sha-1</p>
-12:17 <+arcturus> it won't be long before there are tools available to the masses</p>
-12:17 <+arcturus> unfortunately the standard hashcash implementation is based entirely on sha-1</p>
-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</p>
-12:18 <@cervantes> ah made it</p>
-12:18 < susi23_> any ideas about this? JAVA_HOME points definitely to the right dir, javac is in PATH and callable</p>
-12:18 <+arcturus> susi23_: we're in a meeting atm :)</p>
-12:18 < jrandom> susi23_: OOM?</p>
-12:18 < susi23_> meeting? though its 8pm?</p>
-12:18 < jrandom> (precompile your jsps rather than letting jetty/tomcat do it, its faster ;)</p>
-12:19 < jrandom> yeah we moved it susi23_ :)</p>
-12:19 < susi23_> didn't know, sorry</p>
-12:19 < jrandom> hehe np, glad you made it for the meeting, your agenda item is up next ;)</p>
-12:20  * susi23_ sits down and listens</p>
-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</p>
-12:21 < jrandom> arcturus: hashcash with md5 would probably be fine</p>
-12:21 < jrandom> its just a PoW</p>
-12:21 <+arcturus> if anyone knows of any hashcash implementations based on sha256 or higher please met me know</p>
-12:21 <+arcturus> well PoW is pointless if there's little P in it :)</p>
-12:21 < jrandom> the size of the hash only matters when your hashcash reaches the size of the hash</p>
-12:23 < jrandom> (but, yeah, running against a truncated sha256 or 512 or whirlpool or whatever would be neat)</p>
-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</p>
-12:24 < jrandom> (DTSTTCPW)</p>
-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</p>
-12:25 < jrandom> (its only for a PoW to get a nym on irc, not to get access to fort knox ;)</p>
-12:26 <@cervantes> there's some talk on the hashcash mailing list about implementing sha256</p>
-12:26 <+arcturus> it's not for a nym, it's for entry to the server</p>
-12:26 <+arcturus> cervantes: cool i'll check that</p>
-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</p>
-12:28 < jrandom> certainly those are renewed over time though, right?</p>
-12:28 < jrandom> e.g. a new PoW cert every 6 months (or 6h, or whatever)</p>
-12:28 <+arcturus> if a user doen't have to do any work to get their ID, that nullifies our ability to ban them</p>
-12:29 <+arcturus> i don't know of any reason to expire them automatically, only expire them manually if they violate terms of service</p>
-12:29 <+arcturus> no need to make people do unnecessary work for new IDs</p>
-12:29 < jrandom> eh, its just a passive PoW, they can run one cycle every 6 hours to regenerate a new one</p>
-12:29 < jrandom> but perhaps DTSTTCPW</p>
-12:30 <+arcturus> any hashcash genereated must be used within 24 hours or it is invalid</p>
-12:32 <@cervantes> just to reiterate the new server irc.freshcoffee.i2p needs to be added into your i2ptunnel console</p>
-12:32 < jrandom> coo'.  ok, anything else for 2) irc2p?</p>
-12:33 <@cervantes> (http://forum.i2p/viewtopic.php?t=911</p>
-12:33 <@cervantes> )</p>
-12:33 <@cervantes> <-- done</p>
-12:34 <+arcturus> i don't have anything else to bore you all with :)</p>
-12:34 < jrandom> hehe</p>
-12:34 < jrandom> ok, 3) susibt</p>
-12:34 < ardvark> um, when I add the new server to my tunnel, do I have to restart i2p?</p>
-12:34 < jrandom> susi23_: p1ng</p>
-12:35 <@cervantes> ardvark: just the tunnel</p>
-12:35 <@cervantes> (ircproxy tunnel)</p>
-12:35 < ardvark> oh ok, I just added and saved, so that is not enuff then</p>
-12:36 < jrandom> right, unfortunately you need to stop and start that proxy</p>
-12:36 < susi23_> well</p>
-12:36 < ardvark> but i'll miss the meeting then ;)</p>
-12:37 < susi23_> susibt is a webapp (like susimail) to drop into your routers VM</p>
-12:37 < susi23_> it acts as a web frontend for i2p-bt</p>
-12:38 < susi23_> so you can manage your seeds, up- and download files etc.</p>
-12:38 < jrandom> w00t</p>
-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 :)</p>
-12:39 <+arcturus> that will be addressed in ducktorrent *cough*</p>
-12:39 < jrandom> heh</p>
-12:39  * jrandom holds breath</p>
-12:40 < susi23_> it even supports restart of seeds after router restart</p>
-12:40 <@cervantes> nice</p>
-12:40 < jrandom> wikked</p>
-12:40 < susi23_> future plans are automatic build of torrents and ui improvement</p>
-12:41 < susi23_> if you want to try it out, I recommend a separate jetty instance</p>
-12:41 < susi23_> so you don't have to fiddle with your router :)</p>
-12:41 < susi23_> download and installation instructions on http://susi.i2p</p>
-12:42 < susi23_> thats all *ping back to jr*</p>
-12:42 < jrandom> w3wt, gracias susi</p>
-12:42 < jrandom> ok, anyone have any questions & comments on that, or shall we jump on over to 4) syndie?</p>
-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</p>
-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</p>
-12:45 < jrandom> i dont have too much to add at the moment on that frnt. unless anyone has any questions?</p>
-12:46 < gott> Why is it called syndie ?</p>
-12:46 < gott> is it a reference to 'syndicate' ?</p>
-12:47 < jrandom> yeah, its a generic syndication frontend (+ security, authentication, and anonymity awareness)</p>
-12:48 < jrandom> ok, if there's nothing else on 4), lets jump on over to 5) ???</p>
-12:48 < jrandom> anyone have anythin i2p related to bring up for the meeting?</p>
-12:51 < jrandom> ok, if there's nothing else</p>
-12:51  * jrandom winds up</p>
-12:52  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/144.rst b/i2p2www/meetings/144.rst
new file mode 100644
index 00000000..fd827fee
--- /dev/null
+++ b/i2p2www/meetings/144.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 23, 2005
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/145.log b/i2p2www/meetings/145.log
index cf33de28..8d51fadd 100644
--- a/i2p2www/meetings/145.log
+++ b/i2p2www/meetings/145.log
@@ -1,134 +1,128 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 145{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 30, 2005</h2>
-<div class="irclog">
-13:03 <+bla> Is there a meeting today?</p>
-13:04 < jrandom> 0) hi</p>
-13:04 < jrandom> 1) Net status</p>
-13:04 < jrandom> 2) floodfill netDb</p>
-13:04 < jrandom> 3) Syndie</p>
-13:04 < jrandom> 4) ???</p>
-13:04 < jrandom> 0) hi</p>
-13:04 <+bla> ;)</p>
-13:04  * jrandom waves</p>
-13:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-August/000871.html</p>
-13:04 < jrandom> (yeah, i'm a few minutes late ;)</p>
-13:05 < jrandom> anyway, jumping into 1) net status</p>
-13:06 < jrandom> restricted routes suck, and we finally have some data as to how common they are (boo hiss)</p>
-13:06 < jrandom> but stil, the net seems fairly healthy, if you ignore all the worried reports of "omg it says status: Unknown!" ;)</p>
-13:07 < gloin> hmm.. where should be the document root for the i2p  included webserver?</p>
-13:07 < jrandom> $i2pInstallDir/eepsite/docroot/</p>
-13:07 < gloin> i2p/eepsite/docroot ?</p>
-13:07 < jrandom> anyone have any questions/comments/concerns regarding the net status outside of whats posted in the status notes?</p>
-13:08 < gloin> found it. it seems that the webserver won't deliver index.html automatically.</p>
-13:08 <+bla> jrandom: I have been doing some tests to check which nodes are selected in tunnels.</p>
-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.</p>
-13:09 <+bla> I am in Europe (no secret), and most of my tunnel participants are in Europe</p>
-13:09 < jrandom> gloin: it should serve up the index.html (thats what renders "Welcome to your Eepsite")</p>
-13:10 < jrandom> ooh nice1 bla!</p>
-13:10 < redzara> as some people have reported some low perf with UDP, maybe we could had a little perfmeter like iperf in I2P ?</p>
-13:11 < redzara> s/had/add</p>
-13:11 < jrandom> bla: so thats not just on the profiles.jsp page, but also on tunnels.jsp?  v.cool... screenshots, screenshots!  :)</p>
-13:11 < gloin> jrandom: now it works. strange.</p>
-13:11 <+bla> jrandom: I'll post some screenshots, but I first have to black out my own router-ID in the screenshots ;)</p>
-13:11 < jrandom> redzara: hmm, a command line utility to let people check their link quality, or a monitor for SSU performance?</p>
-13:11 < jrandom> heh bla</p>
-13:12 < jrandom> odd gloin </p>
-13:13 < gloin> jrandom: btw, since I updated my pppoe i2p seems to be more stable.</p>
-13:13 < jrandom> nice, what was the problem with your net connection?  firmware update?</p>
-13:14 < gloin> jrandom: I lost all peers. But the internet connection was ok, but every peer failed. </p>
-13:16 < jrandom> right, but what did you update about your pppoe settings?</p>
-13:17 < gloin> jrandom: I mean the linux ppppoe deamon.</p>
-13:18 < jrandom> ah ok</p>
-13:18 < jrandom> ok, anyone else have anything for 1) net status, or shall we move on to 2) floodfill netdb?</p>
-13:18 <+bla> http://theland.i2p/parttunnels.jpg</p>
-13:19 <+bla> http://theland.i2p/servertunnels.jpg</p>
-13:21 <+bar> (umm.. inaccessible?)</p>
-13:21 < jrandom> yeah, i'm having trouble reaching it too</p>
-13:21 < fox> <godmode0> i use pppoe never be at problem i2p</p>
-13:22  * jrandom will try later though</p>
-13:22 <+bla> jrandom: Well.. There's new network problem just there ;)</p>
-13:22 < jrandom> hehe</p>
-13:22 < jrandom> bla: are you on -4 or an earlier build?</p>
-13:23 <+bla> jrandom: I'm on -4</p>
-13:23 < jrandom> hmm, ok cool</p>
-13:23 < jrandom> ok, anyway, we can dig through that later</p>
-13:24 < jrandom> (if you could send me the netDb stats from /oldstats.jsp, that'd be great :)</p>
-13:25 < jrandom> ok, moving on to 2) floodfill netdb</p>
-13:26 < jrandom> there's lots of info posted to my blog on this topic</p>
-13:26 < jrandom> we've begun deploying a first pass, though there's still some work to be done</p>
-13:26 < jrandom> does anyone have any questions/comments/concerns on the plan?</p>
-13:27 <+bla> jrandom: Will the floodfill scale as log(N) (N=number of peers in the net), or linearly?</p>
-13:27 < jrandom> linearly with M (M= number of peers participating in the floodfill netdb)</p>
-13:28 < jrandom> well, M may be small enough that N is the dominant term</p>
-13:29 < jrandom> (in which case it'll be linearly with N)</p>
-13:29 < jrandom> which is not great, but until we have > 10K eepsites, it doesnt matter</p>
-13:30 < jrandom> once we do, then we can go into more advanced algorithms for sharing the load between the floodfill participants</p>
-13:31 < jrandom> (note thats 10k eepsites, not users, since we don't really need to publish client leaseSets in the netdb)</p>
-13:32 <+bla> jrandom: Is there a reason why we still do publish the client destinations in the netDb?</p>
-13:32 <+bla> jrandom: Or, for that matter, why we still show off who our fast peers are in the netDb?</p>
-13:33 <+bla> jrandom: Removing both would slash the netDb data by a big factor</p>
-13:33 < jrandom> bla: to the former, no.  to the later, for me to debug (though i havent looked at that particular field recently)</p>
-13:33 < jrandom> aye, worth trying, perhaps in -5</p>
-13:36 < jrandom> ok coo', well, we'll see and hopefully get -5 out in the next few days</p>
-13:37 < jrandom> (maybe tomorrow)</p>
-13:37 < jrandom> ok, if there's nothing else on 2) floodfill netdb, lets move on to 3) syndie</p>
-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?</p>
-13:40  * jrandom really digs the remote syndication functionality, though its far from what we're hoping for with feedspace integration</p>
-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)</p>
-13:42 < jrandom> ok, if there's nothing else on 3) syndie, lets open 'er up to 4) ???</p>
-13:42 < jrandom> anyone have anything else i2p related to bring up?</p>
-13:42 < redzara> sure, where is the doc ;)</p>
-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</p>
-13:43 <+nickless_head> I think the i2pProxy.pac script should be in the jetty web folder by default.</p>
-13:43 < jrandom> nickless_head: i dont recommend i2pproxy.pac, as its a huge security risk</p>
-13:44 < redzara> 2 - could be have the latest build of jetty included in I2P ?</p>
-13:44 < jrandom> we've got 5.2.1 in i2p right now</p>
-13:44 < jrandom> er, 5.1.2</p>
-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</p>
-13:45 < jrandom> i use switchproxy</p>
-13:45 < jrandom> (and i dont switch to non-anonymous browsing)</p>
-13:45 < jrandom> ((squid.i2p is fast enough for me))</p>
-13:45 <+nickless_head> Think of the slashdotters! :p</p>
-13:46 < jrandom> as i've said before, i have reservations about the viability of eepsites.  the security risks are tremendous</p>
-13:46 < jrandom> but, for those who don't care about those risks, perhaps an i2pproxy.pac makes sense.</p>
-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</p>
-13:48 < jrandom> agreed (though we do push i2pproxy.pac, we just dont tell people about it until we scare 'em enough ;)</p>
-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 .. </p>
-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</p>
-13:50 < redzara> Jetty-5.1.5rc1 - 23 August 2005</p>
-13:52 < jrandom> ah cool, whats the problem exactly redzara?</p>
-13:52 < jrandom> nickless_head: if you find a way, let us know</p>
-13:52 < redzara> or maybe i could even only build my own I2P with the latest version of jetty</p>
-13:52 < jrandom> redzara: that you certainly can do - just drop in the jetty jar files into your i2p lib directory</p>
-13:53 < redzara> jrandom : everythime i try to start mvnforum in I2P, jetty failed to find apache common logging</p>
-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.</p>
-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</p>
-13:54 < jrandom> nickless_head: yet another reason why i dont recommend anyone use it ;)</p>
-13:55 < redzara> yes i know, i'm not so n00b :)) i've to dig into again with this new version of jetty</p>
-13:56 < jrandom> cool, keep us updated</p>
-13:56 < redzara> np</p>
-13:57 < fox> * mihi guesses most i2p users will reveal their "real ip" to a java applet  anyway :)</p>
-13:57 < fox> <mihi> try http://www.stilllistener.com/checkpoint1/Java/ (and scroll down)</p>
-13:58  * jrandom sees lots of blank fields ;)</p>
-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.</p>
-13:59 < jrandom> bla: unless the user is on some site like e.g. http://i_have_illegal_stuff.i2p/</p>
-14:00 < jrandom> (exposing the clients IP "just once" is fatal enough ;)</p>
-14:00 <+bla> jrandom: Yes. </p>
-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</p>
-14:01 < jrandom> or use syndie :)</p>
-14:02 < ZULU> sorry for interruption,is duck.ip down ?</p>
-14:02 <+bla> jrandom: Is it time yet for general questions?</p>
-14:02 < jrandom> aye, we're on 4) ???</p>
-14:02 < jrandom> ZULU: yeah, duck is offline for the time being</p>
-14:03 <+bla> jrandom: I've edited the java-files that help profiles.jsp and tunnels.jsp generate the country-flags</p>
-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)?</p>
-14:06 < jrandom> we need a "get.jsp?name" that dumps the contents of ./docs/'name' to the browser</p>
-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)</p>
-14:06 <+bla> jrandom: Ah, ok, so it wasn't my fault ;)</p>
-14:06 < jrandom> heh nope, blame me :)</p>
-14:09 < jrandom> ok, if there's nothing else for the meeting</p>
-14:09  * jrandom winds up</p>
-14:10  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/145.rst b/i2p2www/meetings/145.rst
new file mode 100644
index 00000000..eaa6ee95
--- /dev/null
+++ b/i2p2www/meetings/145.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 30, 2005
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/146.log b/i2p2www/meetings/146.log
index 6a6f865a..8ddb6bda 100644
--- a/i2p2www/meetings/146.log
+++ b/i2p2www/meetings/146.log
@@ -1,218 +1,212 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 146{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 06, 2005</h3>
-<div class="irclog">
-13:04 < jrandom> 0) hi</p>
-13:04 < jrandom> 1) Net status</p>
-13:04 < jrandom> 2) Syndie status</p>
-13:04 < jrandom> 3) susidns</p>
-13:04 < jrandom> 4) ???</p>
-13:04 < jrandom> 0) hi</p>
-13:04  * jrandom waves</p>
-13:04 <+bar> salaam aleikum</p>
-13:04 < jrandom> status notes up @ http://dev.i2p.net/pipermail/i2p/2005-September/000888.html</p>
-13:04 <+Ragnarok> hi</p>
-13:04  * cervantes tips his hat</p>
-13:04 <+fox> * adamta waves back across the Irc2p/Freenode bridge</p>
-13:05 < jrandom> :)  ok, movin' in to 1) net status</p>
-13:05 <@cervantes> *** Disconnected</p>
-13:05 < jrandom> things seem to be going reasonably well from what i can see</p>
-13:05 < jrandom> heh</p>
-13:06  * cervantes concurs...only one netsplit in a few days</p>
-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)</p>
-13:06 <@cervantes> and my irc connection uptime is as long as my routers'</p>
-13:06 <+Ragnarok> same as usual for me.  Slow, but usable, with intermittent unreliability</p>
-13:07 < jrandom> nice, i have been seeing that too cervantes </p>
-13:07 < jrandom> Ragnarok: unreliability with eepsites, irc, i2pbt, i2phex, mail, all of the above?  with 0.6.0.5 or earlier?</p>
-13:08 <+Ragnarok> mostly in the form of irc disconnects every few hours. </p>
-13:08 <+Ragnarok> don't use a whole lot else, so I don't have much more information</p>
-13:08 < jrandom> hmm, do you have the bw limiter set?</p>
-13:08 <+Ragnarok> yeah</p>
-13:08 < jrandom> (as a reminder, -1 now means 16KBps)</p>
-13:09 <+Ragnarok> it's set to more than the default</p>
-13:09 < jrandom> ok cool, is it hitting that limit at all, and/or is that limit appropriate for your real net capacity?</p>
-13:09 <+Ragnarok> the limit is well below my real capacity, since setting it high seems to kill my wireless router</p>
-13:10 < jrandom> heh ok</p>
-13:10 <+Ragnarok> but my router doesn't seem to hit the limit anyway</p>
-13:11 <+Ragnarok> I can try to stress test it a bit, and keep better track</p>
-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</p>
-13:11 < jrandom> cool, that'd be great.  i can only locally test so many situations, so any reports are appreciated</p>
-13:11 <+Ragnarok> which number am I looking for.  oldstats is pretty dense...</p>
-13:12 <+Ragnarok> s/./?/</p>
-13:12 < jrandom> heh, sorry - oldstats.jsp#bw.sendBps the 60s peak (the second number on the line)</p>
-13:14 <+Ragnarok> what are the units?  The number seems highly improbable</p>
-13:14 < jrandom> KBps, sorry</p>
-13:14 < jrandom> (its improperly named)</p>
-13:15 < Pseudonym> bits or bytes?</p>
-13:15 < jrandom> bytes</p>
-13:15 <+Ragnarok> unfortuneately, it must be wrong then</p>
-13:15 <+Ragnarok> the peak number is a small fraction of the limit, and of the current usage of the router</p>
-13:15 < jrandom> hmm, its pretty specific, counting sizeof(messages received)</p>
-13:16 < jrandom> (though the bw limiter itself works at a lower level, counting sizeof(packets received or sent)</p>
-13:16 <+Ragnarok> how bad is it if I cut & paste the line? :)</p>
-13:16 < jrandom> might be safer to msg it to me </p>
-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.</p>
-13:17 <+Ragnarok> sorry</p>
-13:17 <+Ragnarok> I'll /msg you more info</p>
-13:17 <@cervantes> Ragnarok: we'd instantly be able to determin your name, address and credit details from the netDB</p>
-13:17 < jrandom> heh</p>
-13:18 < jrandom> cervantes: thats why the netDb bw publishes only the *current* rate, not the peak ;)</p>
-13:18 < jrandom> (but yeah, giving out one's bw usage can be dangerous to an adversary)</p>
-13:19 < jrandom> ok, anyone else have anything to bring up wrt net status?</p>
-13:21 < jrandom> if not, moving on to 2) syndie status</p>
-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?</p>
-13:22 <@cervantes> Officiali2pApps++</p>
-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.</p>
-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.</p>
-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</p>
-13:23 < jrandom> cool adamta - be sure to work with the latest codebase, as I went through and css'ed everything last night</p>
-13:24 < jrandom> (at a rought level, that is)</p>
-13:24 <+fox> <adamta> jrandom: Oops... I'd been working on an earlier version.</p>
-13:24 <+fox> <adamta> I'll `cvs update` and see what's changed, then.</p>
-13:24  * Ragnarok , asking for user docs.  Oh the hypocrisy</p>
-13:24 < jrandom> good call Ragnarok.  the use case is essentially '$myI2P.getUseCases()'</p>
-13:25 < jrandom> safe syndication and publication of content, rather than using eepsites</p>
-13:25 < jrandom> (as eepsites don't allow safe syndication, require more skill for publication, and require high availability of the operating node)</p>
-13:25 <+Ragnarok> how is it syndicated, though?</p>
-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</p>
-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)</p>
-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</p>
-13:27 <+Ragnarok> oh, nice.  I don't think I've seen that</p>
-13:27 <@cervantes> *classes=classed</p>
-13:27 <@cervantes> adamta: I'd be interested in seeing what you come up with</p>
-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 :)</p>
-13:28 <@cervantes> just get rid of those damn tables :)</p>
-13:28 < jrandom> heh</p>
-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.</p>
-13:30 <@cervantes> cool</p>
-13:30 < jrandom> kickass adamta!</p>
-13:31  * jrandom will not touch that side of things for a bit (i've got plenty to work on in the router :)</p>
-13:31 <@cervantes> on a semi related note the new routerconsole themes have been somewhat delayed by arcturus' *ahem* disappearence</p>
-13:31 < jrandom> heh d'oh</p>
-13:31 <@cervantes> I'm trying to pick up where he left off with some of the workflow tweaks</p>
-13:32 <@cervantes> but I don't have the JSP skills to do anything radical like fix the broken tunnel config screens</p>
-13:33 < jrandom> ah cool, any progress is good, and if you need help with anything in particular, i'm 'round</p>
-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))</p>
-13:33 <@cervantes> having said that the new alternative theme is looking ok</p>
-13:33 < jrandom> nice</p>
-13:34 <+fox> <adamta> The new color scheme is definitely nicer, if that's what you're referring to (?).</p>
-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</p>
-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?</p>
-13:36 <@cervantes> jrandom: I'm not sure what he gave you</p>
-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</p>
-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")</p>
-13:37 < jrandom> cool, i'll bounce 'em your way cervantes </p>
-13:37 <@cervantes> ta</p>
-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</p>
-13:38 < jrandom> we could publish a 'DefaultStyle: minimal' in the blog's metadata to allow the later</p>
-13:39 <@cervantes> yeah that was what I was imagining</p>
-13:39 <+susi23> (readers preferences should always override others)</p>
-13:39 <+susi23> (but thats an opinion :)</p>
-13:39 < jrandom> right, when the reader has explicit preferences</p>
-13:39 <@cervantes>  /ignore susi23</p>
-13:39 <@cervantes> sheet it didn't work</p>
-13:41 <@cervantes> if we make filter by blog more distinct form of navigation</p>
-13:42 <@cervantes> such as a side list</p>
-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</p>
-13:42 <@cervantes> then it will make style changes more pallatable</p>
-13:42 < jrandom> hmm yeah ,interblog navigation is going to be interesting</p>
-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?</p>
-13:43 < jrandom> http://syndiemedia.i2p/viewattachment.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=1124769600000&attachment=0</p>
-13:44 <@cervantes> <bluesky>well that could be a template preference perhaps?</bluesky></p>
-13:44 < jrandom> hmm, i dont know if stylesheets can turn a list into a drop down, can it?</p>
-13:44 <@cervantes> navigation type: dropdown|sidelist|hierarchy  </p>
-13:44 <@cervantes> no</p>
-13:45 < jrandom> ok, yeah, that can be done in jsp & user preference though, no problem</p>
-13:45 < jrandom> (hierarchy?)</p>
-13:45 <+susi23> (sure, you can give the select a rows parameter)</p>
-13:45 <@cervantes> but if you abstract the markup into templates then you can have multiple user preference layouts</p>
-13:45 < jrandom> ah, true, as a multivalued list</p>
-13:45 < jrandom> (rather than an html list of links)</p>
-13:46 <@cervantes> (I was blueskying though)</p>
-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)</p>
-13:46 < jrandom> ((especially with the new docs/syndie_standard.css))</p>
-13:46 <@cervantes> you might want to save that until version 2 and concentrate on more important aspects</p>
-13:47 <+susi23> (you could put all three variants in the html source and the users decides which divs we want to hide)</p>
-13:47 <@cervantes> right, if adamta sorts out the markup then you can probably do quite dramatic variations</p>
-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</p>
-13:47 < jrandom> good call susi23 </p>
-13:47 <+susi23> (k, not very elegant way ;)</p>
-13:47 <@cervantes> as in http://www.csszengarden.copm</p>
-13:48 <@cervantes> * http://www.csszengarden.com</p>
-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 :)</p>
-13:49 < jrandom> ok, anyone have any further questions/comments/concerns wrt syndie?</p>
-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])</p>
-13:50 <@cervantes> nice work</p>
-13:50 < jrandom> gracias cervantes </p>
-13:50 <@cervantes> you going to ever do anything on i2p core again? :)</p>
-13:50 < jrandom> heh</p>
-13:51  * jrandom has a pair of killer changes to the router coming up, giving us lots of capabilities</p>
-13:51 < jrandom> (but more on those when they're tested and ready for deployment)</p>
-13:51 <@cervantes> i2pponies.ar</p>
-13:51 <@cervantes> i2ponies.war</p>
-13:52 <@cervantes> hmm vnc refresh is slow tonight</p>
-13:52 <+susi23> (pony wars? poor ponies...)</p>
-13:52 < jrandom> heh</p>
-13:52 < jrandom> ok, moving on to 3) susidns</p>
-13:52 < jrandom> susi23: wanna give us a rundown?</p>
-13:52 <+susi23> well</p>
-13:53 <+susi23> there is not much to say... susidns is a very simple webapp giving you access to addressbook configuration and subscriptions files</p>
-13:53 <+susi23> and to your "addressbooks" namely hosts.txt, userhosts.txt and (if existing) your published addressbook</p>
-13:54 <+susi23> I added an introduction page and some explanations how addressbook works</p>
-13:54 <+susi23> (ok, how I think addressbok works ;)</p>
-13:54 < jrandom> w00t :)</p>
-13:54 <+bar> userhosts.txt?</p>
-13:54 <+susi23> as there've been user questions about this in the last weeks</p>
-13:54 <+Ragnarok> I'll send feedback, once I try it out :)</p>
-13:54 <@cervantes> cool, how ready is it?</p>
-13:54 <+susi23> sure</p>
-13:54 <+susi23> usable</p>
-13:55 < ardvark> i use addressbook, but have no userhosts.txt, or is userhosts.txt my personal/private eepsites?</p>
-13:55 < jrandom> ardvark: userhosts is for user specified custom overrides (it doesnt exist by default)</p>
-13:55 <+susi23> userhosts.txt is a 2nd hosts.txt file which is read by the NamingService</p>
-13:55 < ardvark> ok</p>
-13:55 <+Ragnarok> userhosts.txt is the one you can edit without fear of dataloss via race conditions :)</p>
-13:55 <+susi23> and yes people used this for private keys</p>
-13:56 <+susi23> (which is a bit dangerous now when you activate addressbook publication)</p>
-13:57 <+susi23> well, no magic here... thats all</p>
-13:57 <+Ragnarok> adding a privatehosts.txt or something, which is read by the NamingService but not addressbook would be trivial</p>
-13:57 <+susi23> true</p>
-13:57 <@cervantes> I would like to see that ;-)</p>
-13:58  * cervantes clutches his private keys ;-)</p>
-13:58 < jrandom> ooh, susidns intro page is nice :)</p>
-13:58 < jrandom> (cervantes/susi/ragnarok/et al: see the syndie pet name web interface too [you need to log in to see it])</p>
-13:58 <+susi23> as addressbooks publication is turned off by default there is no danger for normal people</p>
-13:58 < jrandom> right right</p>
-13:59 <+Ragnarok> I've asked this before, but is there anything I can do to make life easier for people writing addressbook frontends?</p>
-13:59  * cervantes has forgotten his login</p>
-13:59 < jrandom> cervantes: you can register again ;)</p>
-13:59 <+Ragnarok> so have I, probably</p>
-14:00 <@cervantes> wouldn't sushidns be a better name?</p>
-14:00  * cervantes ducks</p>
-14:00 <+susi23> ragnarok: how about a function to interupt the sleeping thread for immediate (user triggered) subscription update?</p>
-14:01 < jrandom> ooh, or a manual "fetch now" capabiliy</p>
-14:01  * susi23 slaps cervantes with a large trout.</p>
-14:01 <+susi23> yes, calling it dns is ridiculous here...but thats a historic name :)</p>
-14:01 <@cervantes> raw trout!</p>
-14:01  * cervantes grabs the soya sauce</p>
-14:01 <+susi23> (pervert!)</p>
-14:02 <+susi23> k, back to topic please ;)</p>
-14:02 <+Ragnarok> ok, I'll look into that</p>
-14:02 <+susi23> (don't drink at meetings!)</p>
-14:02  * jrandom hides my drink</p>
-14:03  * susi23 pings jrandom</p>
-14:03 < jrandom> ok cool, thanks susi, looks v.nice</p>
-14:03 < jrandom> ok, moving on to 4) ???</p>
-14:03 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-14:04 <@cervantes> if anyone has been experiencing any issues with irc2p please let the admins know</p>
-14:06 <@cervantes> #irc2p is the support channel</p>
-14:06 <@cervantes> or post to the forum</p>
-14:06 <@cervantes> jrandom: do you want a syndie forum btw? (or is that redundant)</p>
-14:07 <@cervantes> susi23: you're welcome to have one too, for you plethora of i2p apps ;-)</p>
-14:07 < jrandom> atm, i think we're ok without one, thanks though</p>
-14:07 < jrandom> the susiworld forum</p>
-14:09 < jrandom> ok, if there's nothing else</p>
-14:09  * jrandom winds up</p>
-14:09  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/146.rst b/i2p2www/meetings/146.rst
new file mode 100644
index 00000000..cea587af
--- /dev/null
+++ b/i2p2www/meetings/146.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 6, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/147.log b/i2p2www/meetings/147.log
index 927fd091..60a3f8ea 100644
--- a/i2p2www/meetings/147.log
+++ b/i2p2www/meetings/147.log
@@ -1,47 +1,41 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 147{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 13, 2005</h3>
-<div class="irclog">
-13:01 < jrandom> 0) hi</p>
-13:01 < jrandom> 1) Net status</p>
-13:01 < jrandom> 2) SSU introductions / NAT hole punching</p>
-13:01 < jrandom> 3) Bounties</p>
-13:01 < jrandom> 4) Client app directions</p>
-13:01 < jrandom> 5) ???</p>
-13:01 < jrandom> 0) hi</p>
-13:01  * jrandom waves</p>
-13:01 < jrandom> weekly status notes posted up (before the meeting!) at http://dev.i2p.net/pipermail/i2p/2005-September/000892.html</p>
-13:01 < jrandom> (drop the .net if you prefer, of course)</p>
-13:03 < jrandom> jumping on in to 1) Net status</p>
-13:03 < jrandom> there are a few users bouncing a bit on irc, but it seems pretty good for most</p>
-13:04 < jrandom> does anyone have any reports regarding other protocols to bring up, or questions/concerns regarding the net status?</p>
-13:05 <@cervantes> I've found this version to be the most stable since 0.4.x</p>
-13:05 <@cervantes> so top work! ;-)</p>
-13:05 < jrandom> w00t</p>
-13:05 < jrandom> ok, if there's nothing else on 1) net status, lets move on to 2) SSU introductions</p>
-13:06 < jrandom> I don't really have much to add beyond whats in the email - anyone have any questions/comments/concerns?</p>
-13:07 < jrandom> if not, i suppose we'll be hearing more when 0.6.0.6 comes out ;)</p>
-13:07 < jrandom> ok, moving on to 3) bounties</p>
-13:07  * cervantes battens down the hatches</p>
-13:08  * cervantes wonders if people have got the hang of the new meeting time yet</p>
-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</p>
-13:08 < jrandom> bah, bloody americans and their slow time zones</p>
-13:09 <+Myo9> I though you were one, having your own bunker and all. ;)</p>
-13:09  * susi23 listens to the dialog ;)</p>
-13:10 < jrandom> ok, if there's nothing else on 3), we can race on through to 4) client apps directions</p>
-13:11 < jrandom> lots of typing in the mail, so rather than repeat it here, anyone have any thoughts on it?  </p>
-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</p>
-13:12 <@cervantes> there's a new Application Support section in the forum, which is a good place to post about such matters</p>
-13:12 < jrandom> ah good call</p>
-13:13 < jrandom> also the discussion section for non-support comments, e.g. prioritization stuff</p>
-13:13 < jrandom> ok, working us towards the first under-15-minute meeting in a long time...</p>
-13:14 < kbi> i guess the meetings go fast when everyone is happy</p>
-13:15 < jrandom> could be, and hopefully we'll get some posts on the list and the forum</p>
-13:15 < jrandom> ok, moving on to 5) ???</p>
-13:15 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-13:15 <@cervantes> (except their lunch)</p>
-13:17 <@cervantes> there goes 15 mins</p>
-13:17  * jrandom winds up</p>
-13:17  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/147.rst b/i2p2www/meetings/147.rst
new file mode 100644
index 00000000..50d0e7c3
--- /dev/null
+++ b/i2p2www/meetings/147.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 13, 2005
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/148.log b/i2p2www/meetings/148.log
index 06c33ae0..57296ccf 100644
--- a/i2p2www/meetings/148.log
+++ b/i2p2www/meetings/148.log
@@ -1,103 +1,97 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 148{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 20 @ 20:00 GMT</h3>
-<div class="irclog">
-16:18 < jrandom> 0) hi</p>
-16:18 < jrandom> 1) 0.6.0.6</p>
-16:18 < jrandom> 2) I2Phex 0.1.1.27</p>
-16:18 < jrandom> 3) migration</p>
-16:18 < jrandom> 4) ???</p>
-16:18 < jrandom> 0) hi</p>
-16:18  * jrandom waves</p>
-16:18 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-September/000929.html</p>
-16:18 <+postman> hello</p>
-16:18 < forest> hi</p>
-16:18 < jrandom> lets jump on in to 1) 0.6.0.6</p>
-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?</p>
-16:19 <+postman> jrandom: observation:</p>
-16:19 <+postman> jrandom: much higher bandwidth consumption</p>
-16:20 <+postman> jrandom: all within the limits and running fine - but my routers really getting warm now</p>
-16:20  * nickless_head makes similar observation</p>
-16:20 < jrandom> aye, me too, i think its likely due to an increase in bt and i2phex traffic</p>
-16:20 <+postman> what increase, with just 80 active torrents on the tracker? :)</p>
-16:20 < jrandom> heh</p>
-16:21 <+postman> but its good to see, that the network does not crumble</p>
-16:21 <+postman> irc is pretty stable altho the router does 50k/s atm</p>
-16:21 < jrandom> mos' def'.  i'm not even logged into freenode anymore, as irc here is stable enough</p>
-16:22  * postman hands the mike back</p>
-16:22 < jrandom> cool, thanks.  i think there's definitely still room to go for bandwidth efficiency, but it seems reasonable atm</p>
-16:22 < jrandom> (hopefully the thing i'm working on will help, but more on that when its ready)</p>
-16:22 < fox> <mihi> you should definitely distinguish between OK (Nat) and Err (Nat)...</p>
-16:23 < fox> <mihi> or is your hole punching almighty?</p>
-16:23 < jrandom> heh</p>
-16:23 < jrandom> well, ERR-SymmetricNAT is and will continue to be an ERR</p>
-16:23 < fox> <mihi> or is it impossible to check whether it was successful?</p>
-16:24 < fox> <mihi> ok</p>
-16:24 < jrandom> but ERR-Reject is due to restricted cone, while full cone nats work fine</p>
-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)</p>
-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</p>
-16:25 < fox> <mihi> as long as there are no nasty iptables rules (like drop UDP to 8887 from IP addresses divisable by 7 :) )</p>
-16:25 < jrandom> heh</p>
-16:26 < jrandom> and unfortunately, some people do have b0rked configurations like that (*cough*peerguardian*cough*)</p>
-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</p>
-16:27 <+Ragnarok> .edu?  That's pretty random</p>
-16:27 < jrandom> yeah, made no sense to me, in so many ways</p>
-16:27 < jrandom> but, c'est la vie</p>
-16:27  * nickless_head sings: We don't need no education...</p>
-16:28 < jrandom> heh</p>
-16:28 < jrandom> ok, anyone else have anything on 1) 0.6.0.6?</p>
-16:29 < jrandom> if not, moving on to 2) i2phex 0.1.1.27</p>
-16:29 < jrandom> not much to say here beyond whats in the mail either...</p>
-16:30 <+postman> jrandom: there was no positive response in the mentioned forums either :(</p>
-16:31 <+postman> jrandom: i will forward your statusnotes and links - maybe the readers get the point</p>
-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</p>
-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</p>
-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)</p>
-16:34 < jrandom> ok, anyone else have anyhing on 2) i2phex, or shall we move on to 3) migration</p>
-16:34  * postman has a look</p>
-16:34 < jrandom> there's not much really to add for 3), its more of an fyi</p>
-16:34 < jrandom> so, perhaps we can jump quickly to 4) ???</p>
-16:34 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-16:35 <+Complication> Migration?</p>
-16:36 < jrandom> if you didn't notice, great :)</p>
-16:36 < jrandom> we moved from one colo to another</p>
-16:36 < jrandom> (cvs.i2p.net, dev.i2p.net, www.i2p.net, mail.i2p.net)</p>
-16:36 <+Complication> Oh, that migration. :)</p>
-16:36  * Complication is simply a bit slow today</p>
-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.</p>
-16:39 <+Complication> Not even once.</p>
-16:39 < jrandom> nice</p>
-16:40 < jrandom> ok, if there's nothing else people want to bring up for the meeting...</p>
-16:40  * jrandom winds up</p>
-16:40 <+postman> jrandom: one thing</p>
-16:40  * jrandom stops winding</p>
-16:40 <+postman> jrandom: you just incremented the i2phex version - what if sirup plans another release?</p>
-16:40 < jrandom> postman: sirup uses the cvs</p>
-16:41 <+postman> jrandom: how about giving it a an additional tag</p>
-16:41 <+postman> ok, that's fine then</p>
-16:41 <+postman> :)</p>
-16:41  * postman is back in his cave</p>
-16:41 < jrandom> (developing code outside a source control system == crazy)</p>
-16:41  * Kefoo remembers how crazy it was developing inside a source control system, too</p>
-16:41 <+postman> jrandom: (it did not need to be YOUR's)</p>
-16:42 < jrandom> heh true enough Kefoo ;)</p>
-16:42 < jrandom> heh well, yeah... his just happens to be though ;)</p>
-16:43  * bar just set a new personal record of 156 concurrent udp connections (old record was 152)</p>
-16:43 < jrandom> cool, yeah, i saw 173 earlier today</p>
-16:44 <+bar> oh :) yeah the indtroducing is doing its thing fo' sure</p>
-16:44 < Kefoo> Not to backtrack, but is i2phex supossed to try connecting on startup? I've heard both yes and no.</p>
-16:44 <+bar> -d</p>
-16:44 < jrandom> wikked bar</p>
-16:44 < jrandom> Kefoo: afaik, no.</p>
-16:44 < jrandom> but, i'm no phex dev</p>
-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</p>
-16:45 < jrandom> thats what i've done Kefoo</p>
-16:45 <+postman> wind ye up now, jrandom :)</p>
-16:45 < Kefoo> Ok, so I'm not making it harder than it should be</p>
-16:45 < Kefoo> I do that sometimes</p>
-16:46 < jrandom> Kefoo: if there's something easier, i'd like to hear about it :)</p>
-16:46 < jrandom> ok ok postman, you can go get your beer ;)</p>
-16:46  * jrandom winds up</p>
-16:46  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/148.rst b/i2p2www/meetings/148.rst
new file mode 100644
index 00000000..6ef41045
--- /dev/null
+++ b/i2p2www/meetings/148.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 20, 2005 @ 20:00 UTC
+===============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/149.log b/i2p2www/meetings/149.log
index 9da682a6..6cebeb2d 100644
--- a/i2p2www/meetings/149.log
+++ b/i2p2www/meetings/149.log
@@ -1,258 +1,252 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 149{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 27, 2005</h3>
-<div class="irclog">
-16:14 < jrandom> 0) hi</p>
-16:14 < jrandom> 1) Net status</p>
-16:14 < jrandom> 2) 0.6.1</p>
-16:14 < jrandom> 3) ???</p>
-16:14 < jrandom> 0) hi</p>
-16:14  * jrandom waves</p>
-16:14 <+Ragnarok> ok, I'll hold my further questions</p>
-16:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-September/000933.html</p>
-16:14 <+Ragnarok> hi :)</p>
-16:15 < wiht> Hello.</p>
-16:15 < jrandom> we can definitely dig into it further in 3?? if you'd prefer</p>
-16:15 <+Ragnarok> cool</p>
-16:15 < jrandom> ok, jumping into 1) Net status</p>
-16:15 < jrandom> in general, things seem pretty solid</p>
-16:16 < A123> Is the http outproxy run by just one router?</p>
-16:16 < wiht> I see 307 known nodes on my router console.</p>
-16:16 < A123> (I'm still a little hazy on how I2P works)</p>
-16:16 < jrandom> there are two outproxies configured by default, and a few others available not configured by default</p>
-16:16 < wiht> Has anyone's bandwidth been maxed out by the recent growth of the network?</p>
-16:17 < jrandom> well, my bandwidth usage has grown, a steady 30-40KBps on my routers</p>
-16:17 < jrandom> (to a steady 30-40, that is)</p>
-16:18 < jrandom> (i'm also running a few high traffic services, like squid.i2p ;)</p>
-16:19 < A123> Ever look at the logs?</p>
-16:19 < jrandom> of squid?  no, i have it set to not do any request logging</p>
-16:20 <+Ragnarok> remember, he could be lying :)</p>
-16:20 <+Ragnarok> thus, it's a stupid question to ask</p>
-16:20 < jrandom> (though that could be a lie, and may work for the FBI/etc, so don't abuse it ;)</p>
-16:20 < A123> I was just curious as to whether there was anything interesting in there :)</p>
-16:21 <+mihi> A123: run your own outproxy :)</p>
-16:21 < gloin> A123: setup a tor node.</p>
-16:21 < A123> Is it easy to set up?</p>
-16:21 < jrandom> not really</p>
-16:21 < A123> gloin, tor is explicitly not designed for file sharing, so I have little interest in it.</p>
-16:22 < jrandom> (an outproxy, that is.  tor is easy to set up)</p>
-16:22 < A123> Or at least, they've explicitly stated that they don't want people to use it for file sharing.</p>
-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?</p>
-16:23 <+mihi> A123: it is definitely harder than registering your nick with nickserv *hint* *hint*</p>
-16:23 < A123> Oh yeah, I sure don't want A123 to be taken :)</p>
-16:23 < wiht> If the network is doing well now, could it stand the addition of more users?</p>
-16:23 < jrandom> we'll need to do some outreach before 1.0 so that we can have some testing in larger environments</p>
-16:24 <+Ragnarok> maybe a preview release, or some such thing</p>
-16:24 < wiht> A beta release? Sounds like a good idea.</p>
-16:25 < jrandom> aye, that'll happen along side the website revamp, maybe before 0.6.2</p>
-16:25 < jrandom> (or maybe @ 0.6.2)</p>
-16:25 < jrandom> (website revamp being part of that critical path so we dont spend hours upon hours answering the same questions)</p>
-16:25 <+Ragnarok> well, with a little more end-user polish than just another beta</p>
-16:26 < A123> Is it possible for I2P-aware clients to configure tunnels themselves easily?</p>
-16:26 < jrandom> yes</p>
-16:26 < A123> I guess they could always do HTTP requests to the console...</p>
-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</p>
-16:26 < jrandom> its one of the properties they send when they connect to i2p</p>
-16:26 < jrandom> agreed Ragnarok</p>
-16:27 < A123> Hrm. The Azureus I2P plugin could have a bit of additional friendliness, then.</p>
-16:27 < A123> Or any friendliness at all.</p>
-16:27 < jrandom> agreed A123 ;)</p>
-16:27 < jrandom> (though they've done a great job showing the proof of work)</p>
-16:28 < jrandom> there have been a lot of great suggestions on the mailing list as of late regarding usability</p>
-16:28 < jrandom> many/most of which should be done prior to asking new users to try i2p out</p>
-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..."</p>
-16:28 < A123> Where would I see "Status: ERR-Reject"?</p>
-16:29 <+Ragnarok> it's nice that we're at the point where we can worry about usability :)</p>
-16:29 < jrandom> A123: on the left hand side of your router console, it says Status: OK (or Status: unknown, or something else)</p>
-16:29 <+Complication> In the Status field of the router console.</p>
-16:29 < jrandom> true 'nuff Ragnarok </p>
-16:29 <+Complication> Hopefully you've got an OK or OK (NAT) there.</p>
-16:30 < A123> Complication, ah, thanks. Is that the thing that gets updated if you click on "Check network reachability..."?</p>
-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.</p>
-16:30 <+Complication> A123: yes, it should test again when you click</p>
-16:30 <+Complication> Doesn't happen instantly, though.</p>
-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</p>
-16:30 < A123> So I have to refresh the page?</p>
-16:30 < A123> Well, no, that would do another http post...</p>
-16:31 <+Complication> A123: it may take a minute to find a testing-suitable peer</p>
-16:31 <+Complication> 'cause you cannot test with those whom you're already speaking to</p>
-16:31 <+Complication> It could give false results.</p>
-16:32 <+Complication> So, it should show up when you view the router console sometime later.</p>
-16:32 <+Complication> Basically, in ideal circumstances, you shouldn not need to fire a peer test manually.</p>
-16:33 <+Complication> =shouldn't need</p>
-16:33 < jrandom> right, i2p now does a peer test automatically when certain events occur</p>
-16:33 < jrandom> (such as when someone tells you that your IP is something other than what you think it is)</p>
-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...</p>
-16:34 < A123> The page wasn't automatically refreshing (I think), I can't do a reload in the browser...</p>
-16:34 < jrandom> reload should be safe</p>
-16:34 < A123> Surely that fires another test?</p>
-16:34 < jrandom> but yeah, the router console was designed more for technical reasons rather than usability</p>
-16:34 < jrandom> A123: it has a nonce to prevent that</p>
-16:34 <+Complication> That facet might benefit from a better explanation text in future</p>
-16:35 < wiht> Have we skipped 2) and gone to 3) already?</p>
-16:35 < jrandom> Complication: we'll probably drop it, since its unnecessary</p>
-16:35 < jrandom> no, still on 1</p>
-16:35 < jrandom> actually, anyone have anything else for 1) network status?</p>
-16:35 < A123> Ah, indeed, after a few times it complains about the nonce.</p>
-16:35 < jrandom> if not, moving on to 2) 0.6.1</p>
-16:35 < A123> "nonce" to non-geeks is just going to seem like a nonsense word.</p>
-16:36 < A123> :)</p>
-16:36  * Complication looks at graphs</p>
-16:36 <+Complication> No complaints about net status from here.</p>
-16:36 < jrandom> w3wt</p>
-16:37 < A123> Is there any reason that reseeding isn't automatic?</p>
-16:37 < jrandom> ok, i don't really have too much to mention regarding 0.6.1 beyond whats in the mail</p>
-16:37 < gloin> hmm.. shouldn't be the incoming and outoging traffic more or less symmetric?</p>
-16:37 < A123> Mine seems more or less symmetric.</p>
-16:37 < jrandom> A123: yes, though we may be able to do it safer</p>
-16:37 <+Complication> gloin: not if one's leeching or seeding ;)</p>
-16:37 <+Ragnarok> not if you're downloading stuff</p>
-16:38 < A123> Total: 3.74/4.09KBps (that's in/out)</p>
-16:39 < gloin> Complication: Is this a security problem? Shouldn't the 'foreign' traffic be reduced?</p>
-16:39 <+Complication> gloin: depends on what the criteria are</p>
-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.</p>
-16:40 < jrandom> gloin: as we move to 1.0, we will stop publishing those stats</p>
-16:40 < A123> My ISP will still know them...</p>
-16:40 < jrandom> but yes, defending against local traffic analysis does require you to participate in other people's tunnels</p>
-16:41 <+Complication> (for a strict definition of "their BW", meaning "bandwidth use starting/ending at their node")</p>
-16:41 < jrandom> (or do sufficient chaff activity.  tarzan for instance has "mimics" for wasting bandwidth^W^Wdefending anonymity)</p>
-16:41 < A123> Hrm.</p>
-16:41 < A123> I'm on ADSL, with far more download ability than upload.</p>
-16:42 <+Complication> Many are.</p>
-16:42 < A123> When my download exceeds my upload, doesn't that imply that I'm downloading stuff?</p>
-16:43 < wiht> No, you could also be forwarding others' traffic.</p>
-16:43 <+Complication> I guess it would imply you are downloading something.</p>
-16:43 < A123> Does I2P cache data?</p>
-16:43  * wiht would like to be corrected if that's wrong.</p>
-16:43 <+Complication> Unless you are seeding as much as you're leeching.</p>
-16:43 < jrandom> i2p itself does not cache</p>
-16:43 <+Complication> A123: no caching occurs to my knowledge</p>
-16:43 < jrandom> though syndie, on the other hand, does.  </p>
-16:44 < A123> If there's no caching, then my download exceeding my upload must mean that I'm downloading something myself, right?</p>
-16:44 < jrandom> if you have large amounts of inbound trafffic but no current outbound traffic, you could just be running a syndie node</p>
-16:44 < jrandom> yes A123, given a small enough time frame</p>
-16:45 < A123> Since I could only usefully be downloading at the speed of my upload, after network buffers fill.</p>
-16:45 < jrandom> for a certain threat model, yes</p>
-16:45 < A123> Hrm.</p>
-16:45 < jrandom> (local passive attacker with sufficient resources, or a targetted local attacker, etc)</p>
-16:46 <+Complication> You could download faster, but it would increase your risk. (For which reason I have allocated up/down similar limits.)</p>
-16:46 < A123> Ah, good point, I can just limit my download speed.</p>
-16:46 <@LevDavidovitch> btw, you should limit both your dl and ul speed</p>
-16:47 <+Complication> But if someone targeted everyone who downloads more than uploads... they'd be targeting everyone and their granny.</p>
-16:47 < wiht> We are still having disconnection issues with IRC, it seems.</p>
-16:47 < jrandom> wiht: only a few people are</p>
-16:47 < wiht> OK.</p>
-16:47 <@LevDavidovitch> also reconnection is v FAST these days</p>
-16:48 < jrandom> (and nothing as bad as it was)</p>
-16:48 < wiht> I agree, reconnections are better.</p>
-16:48 < jrandom> aye, its nice to have our irc servers hosted on routers with reasonable bw limits :)</p>
-16:49 < jrandom> ((not that before was unreasonable, it was great, we just outgrew it))</p>
-16:49 < A123> Is there any technical reason why DCC isn't supported? It can be implemented similar to the nat module, right?</p>
-16:49 < jrandom> ok, anyone have anything for 2) 0.6.1?</p>
-16:49 < jrandom> yes A123, there are technical reasons why dcc isnt supported</p>
-16:50 <@LevDavidovitch> it'd have to be done client side, i think.</p>
-16:50 < jrandom> someone could implement an irc proxy with dcc support, but no one has</p>
-16:50 < A123> What are they? Or is that a long discussion?</p>
-16:50 < jrandom> dcc support requires knowing and interpretting the irc protocol, and rewriting the irc messages sent as necessary</p>
-16:50 <@LevDavidovitch> normal dcc uses arbitrary ports and all</p>
-16:50 < jrandom> (in particular, ctcp messages for establishing dcc connections)</p>
-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).</p>
-16:51 < jrandom> i dont know what a nat module is?</p>
-16:51 <@LevDavidovitch> the nat uses some UDP weirdnesses.</p>
-16:52 <@LevDavidovitch> the nat traversal thing i think he means</p>
-16:52 < jrandom> ah, ok, yeah, its technically possible, but no one has volunteered to work on it (and i'm swamped)</p>
-16:52 < A123> No... At least for Linux, there's a masq module for iptables which will rewrite IRC packets with DCC CTCP requests.</p>
-16:53 <@LevDavidovitch> ah, i see</p>
-16:53 <@LevDavidovitch> maybe some of that code would be usable</p>
-16:53 <@LevDavidovitch> depends how intimate it is with the ipfilter thing</p>
-16:54 < jrandom> probably simpler to just extend I2PTunnelClient to interpret irc perhaps</p>
-16:54 < A123> http://www.koders.com/c/fidA6A89E1080590138EB211E694473DDDD098B6B75.aspx <- Might be interesting, courtesy of Google.</p>
-16:54 < jrandom> (in the same way I2PTunnelHTTPClient extends it to interpret HTTP)</p>
-16:55 <@LevDavidovitch> not in most countries. </p>
-16:55 <@LevDavidovitch> oops</p>
-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</p>
-16:57 < jrandom> ok, anything else on 2) 0.6.1, or shall we move on to 3) ???</p>
-16:57 < A123> jrandom, it wouldn't really need to be OS level, would it? It would be coming through the IRC tunnel anyway...</p>
-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</p>
-16:58 < jrandom> in any case, its a lot of work, and unless someone volunteers to do it, it'll never get done ;)</p>
-16:59 < jrandom> (it *woudl* be cool though)</p>
-16:59 < A123> Right.</p>
-16:59 < A123> I meant "like the iptables filter", not "using the iptables filter" :)</p>
-16:59 < A123> -the+a</p>
-16:59 < A123> +n</p>
-17:00 < A123> Hrm hrm.</p>
-17:00 <@LevDavidovitch> go forth I think</p>
-17:01 < jrandom> ok, on to 3) ??? </p>
-17:01 < jrandom> (though one could probably say we've been on 3) all along ;)</p>
-17:01 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-17:01 <+fox> <brutus> on 3) bugzilla would be nice to have in shape before 1.0</p>
-17:01 < wiht> Speaking of the usability suggestions from the mailing list, have you incorporated any of them into I2P?</p>
-17:02 < jrandom> brutus: we used to have bugzilla, but no one used it</p>
-17:03 < wiht> I should say, are you still concentrating on the core I2P functionality and planning to focus on usability a little later?</p>
-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.</p>
-17:03 < A123> (Assuming your client knows your IP)</p>
-17:03 < jrandom> wiht: the last week i've been doing a lot of improvements to the streaming lib which should substantially improve usability</p>
-17:04 < jrandom> A123: the irc servers filter ctcp messages</p>
-17:04 < jrandom> (they've been modified)</p>
-17:04 < A123> Servers...</p>
-17:04 < jrandom> but yes, that does send your ip to the server (which it may discard, or may file into some NSA database)</p>
-17:04 < jrandom> so, dont send dcc requests</p>
-17:04 < A123> I don't really want the server admins knowing who I am, either :)</p>
-17:05 < A123> (In theory. I don't care now or with you guys)</p>
-17:05 < A123> It might be worth warning users about that.</p>
-17:05 < jrandom> there's a page on the wiki about a whole slew of issues iirc</p>
-17:05 < jrandom> (swing by ugha.i2p)</p>
-17:06 <+fox> <mihi> btw: are the irc2p servers connected via i2p or directly?</p>
-17:06 <+Complication> I'd assume i2p</p>
-17:06 <+Complication> Unless someone's gone mad meanwhile, and not notified me. :P</p>
-17:06 < wiht> jrandom, that's good, but what about the UI suggestions by Isamoor?</p>
-17:07 < jrandom> mihi: i believe they're done over i2p</p>
-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</p>
-17:09 < jrandom> there's a lot more to be done, and a lot more will be done, but i have only two hands</p>
-17:09 < wiht> Thank you, I will look there.</p>
-17:10 < jrandom> actually, i have something to bring up for the meeting...</p>
-17:10 < A123> What's the server/channel that fox is changating? Or do I misunderstand fox's purpose?</p>
-17:11 < jrandom> as mentioned on hq.postman.i2p, we've had over a full year of anonymous mail service through postman's servers!  </p>
-17:11  * jrandom cheers</p>
-17:11  * wiht does not want to seem ungrateful.</p>
-17:12 < A123> jrandom, have the spammers caught on yet?</p>
-17:12 < jrandom> A123: fox is a bridge to irc.freenode.net</p>
-17:12 < A123> (OK, it's a slow way to go about spamming...)</p>
-17:12 < jrandom> A123: doubt it, postman has antispam measures</p>
-17:12 < jrandom> inbound spam is a bit of a problem though ;)</p>
-17:13 < jrandom> (but my account there has been well filtered)</p>
-17:13 < mule> is it really that long. time passes ...</p>
-17:13 < A123> jrandom, ah, thanks.</p>
-17:13  * Complication looks if someone has finally dropped him a bear via e-mail</p>
-17:14 <+fox> <brutus> yeah, postman & cervantes deserve a medal, they're pulling some great weights around here</p>
-17:15 <+fox> <brutus> excellent services indeed</p>
-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 :)</p>
-17:16 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
-17:16 < wiht> Speaking of content...</p>
-17:16 < wiht> It seems that we know what sites are up or not, but no easily accessible directory of sites.</p>
-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.</p>
-17:17 < wiht> I was thinking of creating one where site admins can post what their site is about.</p>
-17:17 < jrandom> orion.i2p is pretty easily accessible...?</p>
-17:17 < jrandom> A123: hmm, perhaps</p>
-17:18 < wiht> It has a short description of sites' purposes?</p>
-17:18 <+postman> A123: spam is only a problem for incoming mail ( mail FROM the internet )</p>
-17:18 < jrandom> wiht: yeah, it does, though i dont know where they come from</p>
-17:18 <+Complication> wiht: no, orion doesn't seem to have that feature</p>
-17:18 < wiht> I will look again.</p>
-17:18 < jrandom> iirc jnymo used to maintain them</p>
-17:18 <+postman> A123: i2p mail  users can rarely spam themselves as well as they cannot spam internet targets</p>
-17:19 <+Complication> Sorry, meant to say it doesn't seem user-accessible.</p>
-17:19 < wiht> I was thinking of a directory that categorizes sites, something similar to dmoz.org.</p>
-17:19 < A123> wiht, as a brand new user, that sounds great.</p>
-17:19 <+fox> <Sugadude> wiht: Do we have enough sites to need to classify them?</p>
-17:19 < A123> wiht, but check Freenet for an excellent example of how not to do it.</p>
-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)</p>
-17:20 < jrandom> (syndie already has a set of category tags for each bookmark, laying it out visually dmoz style wouldnt be hard)</p>
-17:20 < jrandom> and it'd be local <--- fast</p>
-17:20 < A123> Or just get Google interested in i2p...</p>
-17:20 < jrandom> heh</p>
-17:24 < jrandom> ok, if there's nothing more for the meeting...</p>
-17:25  * jrandom winds up</p>
-17:25  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/149.rst b/i2p2www/meetings/149.rst
new file mode 100644
index 00000000..335c1089
--- /dev/null
+++ b/i2p2www/meetings/149.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 27, 2005
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/15.log b/i2p2www/meetings/15.log
index e568271e..93074d5d 100644
--- a/i2p2www/meetings/15.log
+++ b/i2p2www/meetings/15.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 15{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 15</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Oct 15 23:31:29 2002
 23:31 < logger> test
 23:32 < mason> sorry, that test did not work
@@ -285,7 +278,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 < 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
@@ -302,7 +295,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 < 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
@@ -427,7 +420,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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: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'
@@ -493,7 +486,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> <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
@@ -514,7 +507,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> <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
@@ -522,5 +515,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 02:02 < philocs> later
 02:11 < logger> logging ended
 --- Log closed Wed Oct 16 02:11:14 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/15.rst b/i2p2www/meetings/15.rst
new file mode 100644
index 00000000..b08f2a86
--- /dev/null
+++ b/i2p2www/meetings/15.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 16, 2002
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/150.log b/i2p2www/meetings/150.log
index 95797f0a..5bb9fc11 100644
--- a/i2p2www/meetings/150.log
+++ b/i2p2www/meetings/150.log
@@ -1,148 +1,142 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 150{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 4, 2005</h3>
-<div class="irclog">
-16:16 < jrandom> 0) hi</p>
-16:16 < jrandom> 1) 0.6.1.1</p>
-16:16 < jrandom> 2) i2phex</p>
-16:16 <@protokol> speaking of, whats the news on legion and i2phex</p>
-16:16 < jrandom> 3) syndie</p>
-16:16 < jrandom> 4) ???</p>
-16:16 < jrandom> 0) hi</p>
-16:16  * jrandom waves</p>
-16:16 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2005-October/000939.html</p>
-16:17 <+postman> hi</p>
-16:17 < jrandom> might as well jump into 1) 0.6.1.1</p>
-16:18 <+postman> ya</p>
-16:18 < jrandom> the network has been growing in number and in usage, but things have been doing pretty well</p>
-16:18 <+postman> .. apart from the irc servers</p>
-16:18 < jrandom> aye, thats an interesting one</p>
-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)</p>
-16:19 <+Ragnarok> what happened?</p>
-16:20 < jrandom> hopefully we'll get the irc servers upgraded sooner rather than later, as there has been some good stuff lately</p>
-16:20 < cervantes> Ragnarok: server<->server link is shakey under 1.1</p>
-16:20 <+Ragnarok> weird</p>
-16:20 < jrandom> 0.6.1.1, that is ;)</p>
-16:20 <+Complication> protokol: see forum, he finally opted for a sensible approach</p>
-16:20 <+postman> cervantes: don't mention the time travel, idiot</p>
-16:20 < cervantes> 0.6.1.x</p>
-16:20 <+postman> :)</p>
-16:21 < cervantes> oop</p>
-16:21 <+postman> jrandom: i hope i'll be able to build a test ircd this week</p>
-16:21 <+postman> jrandom: we could link to an instance run by you or cervantes </p>
-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</p>
-16:23 < jrandom> it'd be cool if we could do that before 0.6.1.2, but if not, no big deal</p>
-16:24 < jrandom> ok, anyone else have anything for 1) 0.6.1.1?</p>
-16:24 <+postman> jrandom: apart from that: runs like hell</p>
-16:24 < jrandom> would that be a good hell or a bad hell?  :)</p>
-16:24 <+postman> a hell of a hell :)</p>
-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.</p>
-16:26 < jrandom> ah cool, thanks Complication </p>
-16:26 <+Complication> (e.g. they probably won't hurt anyone in real life)</p>
-16:26 < jrandom> heh never underestimate people's ability to break things :)</p>
-16:27 < cervantes> or the ingenuity of fools in testing fool proof systems</p>
-16:27 <+postman> yea, make something fool proof and you'll be rewarded with a new kind of fool</p>
-16:28 < jrandom> hallelujah</p>
-16:29 < jrandom> ok, anything else for 1), or shall we move on to 2) i2phex</p>
-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.  </p>
-16:30 <+postman> move</p>
-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</p>
-16:31 <+Ragnarok> what did he actually do?</p>
-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</p>
-16:33 <+Ragnarok> hm, ok</p>
-16:33 <+postman> jrandom: so there're a bunch of improvements - those will be kept tho?</p>
-16:34 < jrandom> certainly, all good stuff will be integrated into i2phex</p>
-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 ;)</p>
-16:35 <+postman> k</p>
-16:36 < jrandom> ok, anyone else have anything for 2) i2phex?  or shall we move on to 3) syndie?</p>
-16:37  * postman prepares his syndie500 franchising goods</p>
-16:37 < jrandom> heh</p>
-16:37 < jrandom> ok, Ragnarok, wanna give us the rundown on the latest?</p>
-16:37 <+Ragnarok> hm, ok</p>
-16:38 <+Ragnarok> Syndie will now get new posts from an archive automatically.  </p>
-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</p>
-16:39 <+Ragnarok> more details about that are in history.txt</p>
-16:39 <+Ragnarok> it needs a ui, but otherwise it's essentially done</p>
-16:39 <+Ragnarok> 'course, no one seems to be posting anything recently, so maybe it's not that useful :)</p>
-16:40 < jrandom> [insert field of dreams quote here]</p>
-16:40 < jrandom> thanks Ragnarok, this has been an oft requested feature</p>
-16:41 <+Ragnarok> cool</p>
-16:41 <+Ragnarok> happy to do it, wasn't really that much work</p>
-16:42 <+Ragnarok> mostly just scratching my own itch :)</p>
-16:42 < cervantes> oh wasn't it? or forget it then :P</p>
-16:42 < cervantes> or=oh</p>
-16:42 <+postman> (hush, the genius must not admit that it needs to work hard too)</p>
-16:42 <+Ragnarok> hehe</p>
-16:43 <+Ragnarok> anyway, if anyone's got bug reports/feature requests/boos/cheers/etc. let me know</p>
-16:43 < jrandom> (cheers!)</p>
-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...</p>
-16:44 <+Ragnarok> but, it would essentially allow syndie to replace addressbook</p>
-16:44 < jrandom> that would be Very Cool</p>
-16:44 <+nickless_head> yeah :)</p>
-16:45 <+Ragnarok> I just have to figure out how to get a list of petnames out of the archive</p>
-16:45 <+Ragnarok> everything else is trivial</p>
-16:45 <+nickless_head> ragnarok: are your  changes already in cvs? (too lazy to read the whole discussion) :)</p>
-16:45 <+Ragnarok> yeah</p>
-16:45 <+nickless_head> :happy:</p>
-16:45  * nickless_head considers cvs update</p>
-16:45 <+Ragnarok> have been since yesterday</p>
-16:45 <+nickless_head> nah, probably better to wait for the next release</p>
-16:45 < jrandom> perhaps get the petnames whenever they're rendered, exposed via the HTMLRenderer (in the addressReceived)</p>
-16:46 <+Ragnarok> ok, I'll look into that</p>
-16:46 < jrandom> cool, thanks Ragnarok </p>
-16:47 <+Ragnarok> well, that's it from me, unless there's questions</p>
-16:49 < jrandom> wr0d.  ok, jumping on to 4) ??? </p>
-16:49 < jrandom> anyone have anything else to bring up for the meeting?</p>
-16:49 < cervantes> aye</p>
-16:49  * nickless_head looks at cervantes interestedly</p>
-16:50 <+fox> <mancom> is there anything new on Q or feedspace?</p>
-16:50 <+postman> nickless_head: hey, he's mine - don't dare to stare at him like that :)</p>
-16:50 <+nickless_head> I'm not staring at him .. I'm looking at him interestedly.</p>
-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</p>
-16:51 <+nickless_head> congratulations complication!</p>
-16:51 <+postman> kudos :)</p>
-16:51 < cervantes> so he gets an avatar (whether he likes it or not) :P</p>
-16:51 <+Complication> Heh, I hope my blunders have been less outstanding. :O :D</p>
-16:52 <@protokol> oh yeah</p>
-16:52 < jrandom> w00t!  thanks Complication </p>
-16:52 < cervantes> (which is active now)</p>
-16:52 <@protokol> hows that Yellow Submarine i2phex test going</p>
-16:52 <@protokol> any notable speeds or lack thereof?</p>
-16:52 <+Complication> It's going.</p>
-16:52 < jrandom> mancom: nothing new regarding Q or feedspace</p>
-16:53 <+Complication> No hyperfast speeds, but a guaranteed good-enough speed, I'd say.</p>
-16:53 < jrandom> protokol: last i heard was 10-20KBps, but thats just stuff on the forum</p>
-16:53 <@protokol> im downloading it right now</p>
-16:53  * nickless_head understands what postman implied</p>
-16:53  * nickless_head blushes</p>
-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.)</p>
-16:54 <+postman> nickless_head: LOL (sorry)</p>
-16:54  * Complication looks at the avatar and grins :D</p>
-16:54 <+nickless_head> postman: *GG* (no problem)</p>
-16:54 < cat-a-puss> Has anything been done in an effort to get "Amazon honor system" as an alternate method of collecting donations?</p>
-16:54 <+Complication> Spot on. :P</p>
-16:55 <@protokol> cat-a-puss: what do you mean?</p>
-16:55 < jrandom> not yet cat-a-puss, haven't seen wilde around</p>
-16:55 < jrandom> woah, hey phedy</p>
-16:55 < phedy> Hi jrandom.</p>
-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</p>
-16:56 < jrandom> Complication: thanks re: the comparisons.  there are a few cleanups left, but its coming along</p>
-16:56 <@protokol> weak</p>
-16:56 <+Complication> (not that I know Tor or Freenet in decent degree, although I've used both)</p>
-16:57  * cat-a-puss is thinking of creating a bounty for helping finish the distributed search engine. </p>
-16:57 < jrandom> (before putting the doc out on the normal website i'll run it by those folks for comment)</p>
-16:58 < cervantes> Complication: it's an art installation on a roundabout in London that causes havoc with the traffic ;-)</p>
-16:59 < jrandom> cat-a-puss: i've got to work out some other financial stuff soon anyway, so shall let you know asap</p>
-16:59 < jrandom> ok, anyone else have anything to bring up for the meeting?</p>
-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.</p>
-16:59 < cat-a-puss> ok</p>
-16:59 < jrandom> kickass, that'd be great</p>
-17:00 <+Complication> cervantes: thanks for telling, I wasn't aware where such an, umm... effect occurred :D</p>
-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</p>
-17:03  * nickless_head goes to sleep</p>
-17:03 < jrandom> i suppose i should grab the baffer...</p>
-17:03 < jrandom> if there's nothing else</p>
-17:03  * jrandom winds up </p>
-17:03  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/150.rst b/i2p2www/meetings/150.rst
new file mode 100644
index 00000000..4e8e991c
--- /dev/null
+++ b/i2p2www/meetings/150.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 4, 2005
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/151.log b/i2p2www/meetings/151.log
index c0195d8d..b87b3f87 100644
--- a/i2p2www/meetings/151.log
+++ b/i2p2www/meetings/151.log
@@ -1,240 +1,234 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 151{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 11, 2005</h3>
-<div class="irclog">
-16:29 < jrandom> 0) hi</p>
-16:29 < jrandom> 1) 0.6.1.2</p>
-16:29 < jrandom> 2) I2PTunnelIRCClient</p>
-16:29 < jrandom> 3) Syndie</p>
-16:29 < jrandom> 4) I2Phex</p>
-16:29 < jrandom> 5) Stego and darknets (re: flamewar)</p>
-16:29 < jrandom> 5) ???</p>
-16:29 < jrandom> 0) hi</p>
-16:29 <@cervantes> (6)</p>
-16:29 <+postman> you mean 6)?</p>
-16:29 < jrandom> yeah, i can't count ;)</p>
-16:30  * postman high-fives cervantes </p>
-16:30 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/000990.html</p>
-16:30 < wiht> Questions should be item 6.</p>
-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 ;)</p>
-16:31 < jrandom> 1) 0.6.1.2</p>
-16:31 <@cervantes> 6) Discuss jrandom's roommate's poor judgement in timing</p>
-16:31 < jrandom> *cough* ;)</p>
-16:31 < jrandom> ok, as mentioned in the email, the 0.6.1.2 release seems to be doing pretty well</p>
-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!)</p>
-16:32 <+postman> :)</p>
-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?</p>
-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?</p>
-16:34 < jrandom> its kind of nice seeing 9 versions playing well together, though of course newer ones work best</p>
-16:35 < jrandom> ok, anyone else have something to bring up regarding 1) 0.6.1.2?</p>
-16:35 <+postman> one of my routers shows 1080 known</p>
-16:35 < jrandom> zounds</p>
-16:35 <+postman> i think this is a bit off track?</p>
-16:35 < jrandom> is that on 0.6.1.2?</p>
-16:35 <+postman> yeah, think so</p>
-16:36 < jrandom> hmm, yeah, thats a... bit high.  i'm seeing about half that many right now</p>
-16:36 <+Complication> Sustainably 400-ish here</p>
-16:37 <+bar> same here</p>
-16:37 < wiht> I see 260 known routers.</p>
-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-*?)</p>
-16:38 <+postman> jrandom: yeah thanks</p>
-16:38 < jrandom> gracias</p>
-16:38 < jrandom> yeah, not everyone will see every netDb reference, so thats normal for there to be fluctuation</p>
-16:40 < jrandom> ok, if there's nothing else on 1) 0.6.1.2, lets swing on over to 2) I2PTunnelIRCClient</p>
-16:40 <@cervantes> nice one dust</p>
-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</p>
-16:41 <+postman> cool</p>
-16:41 < jrandom> yeah, this is very cool, people have been asking for something like it for ages</p>
-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</p>
-16:41 < jrandom> *cough*</p>
-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</p>
-16:43 < dust> i've tested some clients but there are many..</p>
-16:43 < jrandom> yeah, i've been watching it for a lil bit, but the filtering seems sound</p>
-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</p>
-16:44 <+Complication> dust: thanks for the "info" :)</p>
-16:44 <+bar> awsome dust, thanks a lot</p>
-16:44 < wiht> Does this mean we don't need to set up an extra IRC tunnel?</p>
-16:44 < jrandom> wiht: no, you'll need an irc tunnel, but it can replace the one you use already</p>
-16:45 <+Complication> wiht: just worry less about our IRC client giving away our ass</p>
-16:45 < jrandom> postman/cervantes: any thoughts on increasing or removing the server ping/pong timeouts?  </p>
-16:45 < wiht> That explains it, thanks.</p>
-16:46 <+postman> mmh, i would not remove them, my client completely freaked when i played around with it</p>
-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</p>
-16:46 <@cervantes> postman: the proxy could respond to pings</p>
-16:46 < jrandom> (but the ping/pong wouldn't need to go over the network)</p>
-16:47 < jrandom> i don't know the impact, but it may be worth looking into.</p>
-16:47 <@cervantes> but I'm not sure how the servers would react, you might end up with a bunch of zombie clients</p>
-16:47 <+postman> jrandom: well</p>
-16:47 < jrandom> well, the streaming lib's keepalive should handle that</p>
-16:47  * Complication has occasionally experienced zombification</p>
-16:47 < jrandom> Complication: recently?</p>
-16:47 <+postman> jrandom: if the proxy pings for the client, the proxy must ping/pong to the client as well</p>
-16:48 <+Complication> A week ago, I think.</p>
-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</p>
-16:48 <+Complication> But my "copy" was dropped eventually.</p>
-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</p>
-16:48 < jrandom> Complication: ah, the irc servers weren't up to date back then, shouldn't happen anymore</p>
-16:49 <+Complication> Without me using "ghost". Recent uses of the ghost command have been due to operating with many nodes.</p>
-16:49 <+postman> jrandom: and the lag measurement?</p>
-16:49 < jrandom> cervantes: right.  and/or if necessary, the proxy could inject an extra PING message to the server if it /needs/ one. </p>
-16:49 <+postman> i find it quite useful to know if i am lagged or not</p>
-16:49 < jrandom> postman: i do too, but you can always /msg yourself</p>
-16:50 < dust> you could perhaps reduce the number of pings</p>
-16:50 < jrandom> it would save a substantial amount of bandwidth, since tunnel messages are 1024byte blocks, sent over 2*k+1 hops</p>
-16:50 < jrandom> that too</p>
-16:50 < jrandom> i don't know, just an idea.  what we have now is kick ass regardless </p>
-16:51 <+postman> ok, i would try to patch a testserver</p>
-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</p>
-16:51 <+postman> maybe it works</p>
-16:51 < jrandom> seems reasonable cervantes.  i don't think it'd need any patching on the server, i hope?</p>
-16:52 <+postman> jrandom: to deactivate maybe - but lowering the interval is conf parameter</p>
-16:53  * postman chews on the ircd documentation ( again )</p>
-16:53 < jrandom> cool, no rush.  just something we can look into sometime</p>
-16:53 <@cervantes> class servers</p>
-16:53 <@cervantes> {</p>
-16:53 <@cervantes>     pingfreq   120;</p>
-16:54 <@cervantes> class clients { pingfreq 90 }</p>
-16:54 <@cervantes> that's my current config</p>
-16:54 <+postman> cervantes: yes, i know  - the question is if it can be deactivated at all</p>
-16:54 <@cervantes> I wouldn't deactivate them...just look into reducing them</p>
-16:55 <+postman> ok, let's start with that</p>
-16:55 <+postman> cervantes: how about 180 secs?</p>
-16:56 <@cervantes> in at the deep end with 240</p>
-16:56 <@cervantes> but perhaps we should ge tthe ircproxy side of things ready first</p>
-16:57 <@cervantes> *discuss after meeting*</p>
-16:57 <+postman> agreed</p>
-16:57 < jrandom> w3rd.  ok, anything else on 2) I2PTunnelIRCClient, or shall we move on to 3) Syndie?</p>
-16:57 <@cervantes> anything to reduce my current 40kb/sec average router traffic ;-)</p>
-16:58 < jrandom> heh, for some reason i doubt thats all irc ;)</p>
-16:58 < jrandom> ok, movin' on</p>
-16:59  * cervantes hides is pony video downloads he's been leeching from jrandom all week</p>
-16:59 <@cervantes> is=the</p>
-16:59 <+postman> LOL</p>
-16:59 < jrandom> as mentioned in the mail, there's some pretty cool stuff going on with syndie</p>
-16:59 < jrandom> the cli is trivial, but dust's new Sucker looks really promising</p>
-16:59 < jrandom> dust: wanna give us a rundown?</p>
-17:00 < dust> oh,</p>
-17:01 < dust> well, it uses rome for parsing the feeds and then converts it to sml, like described in jrandoms blog</p>
-17:02 < dust> it's not what you'd call robust yet, but it's only two days old :)</p>
-17:02 < dust> i've got some dilbert in my syndie..</p>
-17:02 < dust> :)</p>
-17:02 < dust> .</p>
-17:02 < jrandom> nice</p>
-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?</p>
-17:04  * dust don't know, you decide</p>
-17:04 < dust> the less separate tools the better</p>
-17:04 < jrandom> yeah, probably easier to bundle it all together, that way everyone knows they can use it</p>
-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)</p>
-17:07 < jrandom> ok, anyone have any questions/comments/concerns on 3) Syndie?</p>
-17:07 < wiht> If you keep integrating software into I2P, it may become a bloated software package.</p>
-17:07 < wiht> Of course, I can turn off Syndie if I am not using it.</p>
-17:08 < jrandom> the i2p sdk 13KLOC</p>
-17:08 < jrandom> and the i2p router is only 22KLOC</p>
-17:08 < jrandom> but yeah, there is an impact on download times of the install</p>
-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</p>
-17:09 < wiht> Yes, I was referring to the download.</p>
-17:09 < jrandom> (but its much more useful when there's a web interface to control it, and i2ptunnel, and the streaming lib, etc ;)</p>
-17:11 < jrandom> smeghead was working on a distribution system (like emerge, for java), and there's the jpackage folks too</p>
-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</p>
-17:12 < jrandom> ok, if there's nothing else on that, lets jump on over to 4) I2Phex</p>
-17:13 < jrandom> I don't really have much to add beyond whats in the status notes</p>
-17:13 < jrandom> redzara: you around?</p>
-17:13 <+redzara> yes i'm</p>
-17:13 <+redzara> I'm already working on the next version, while waiting for the meeting with Gregor.</p>
-17:13 < jrandom> ah great</p>
-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... </p>
-17:14 <+redzara> I have much documentation and code to read</p>
-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</p>
-17:16 < jrandom> getting the I2Phex part into a plugin for the mainline Phex would be really kickass</p>
-17:17 < jrandom> ok, anyone else have anything for 4) I2Phex?</p>
-17:18 <+redzara> I would need certainly assistance for the petname part</p>
-17:19 <+redzara> and maybe too for fine tunning tunnels's parameters</p>
-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)</p>
-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</p>
-17:20 < jrandom> (we'd obviously want to have good defaults anyway)</p>
-17:21 <+redzara> maybe something like ircclient, an filter to be sure</p>
-17:22 <@cervantes> better to get the app in shape imho</p>
-17:22 < jrandom> that might work, though dealing with arbitrary byte sequences may be tough</p>
-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.</p>
-17:23 <+redzara> humm, it's just an idea ;)</p>
-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 :)</p>
-17:25 < jrandom> ok, if there's isn't anything else, perhaps we can swing through 5) stego and darknets briefly</p>
-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)</p>
-17:27 < jrandom> that said, is there anything people want to bring up about the issues raised?</p>
-17:27 < wiht> Freenet version 0.5 and 0.7 were mentioned in the discussion. Is there a version 0.6 for Freenet?</p>
-17:27 < jrandom> 0.6 is their current "unstable" branch of the network</p>
-17:27 < jrandom> afaik</p>
-17:27 <+postman> ohh and i thought it has been stolen by alien forces</p>
-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</p>
-17:28 <+postman> :)</p>
-17:28 < wiht> Toad was talking about being able to harvest the IP addresses of I2P or FreeNet nodes, right?</p>
-17:28 < jrandom> among other things</p>
-17:29 < wiht> Just wanted to clarify that, thanks.</p>
-17:29 < jrandom> np.  ok, anyone else have anything on 5), or shall we move on over to the good ol' fashioned 6) ???</p>
-17:30 <+postman> ok, i got one for 6)</p>
-17:30 < jrandom> consider us moved.</p>
-17:30 < jrandom> whats up postman?</p>
-17:30 <+postman> we all have seen that protocol specific filter capable proxies are good and needed</p>
-17:31 <+postman> would it be feasable to invest thinking in a generic proxy</p>
-17:31 <+postman> that can be fed with a protocol description</p>
-17:31 <+redzara> I would like to have an application like cron using beanshell to run code java code dynamically</p>
-17:31 <+postman> along with stuff to watch for/filter/disguise</p>
-17:31 <+postman> like a filter/sanitize xml description </p>
-17:32 <+postman> so that we dont need new source but just a new filter file/profile</p>
-17:32 <+postman> (just a question if its worth to think about it)</p>
-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</p>
-17:32 <@cervantes> it's catching the stuff that deviates from the protocol that's tricky</p>
-17:33 <+postman> it was just an idea to trigger a process of brainstorming</p>
-17:33 <+postman> imho something like a generic proxy with modeled filter/parser is very usable</p>
-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.</p>
-17:33 < jrandom> wiht: i loaded it once, its the same as eepsites.com</p>
-17:34 < jrandom> (or is it .net?  or .org?  i forget)</p>
-17:34  * wiht visits eepsites.com</p>
-17:34 < jrandom> postman: if someone could come up with something that'd work, that'd kick ass</p>
-17:34 <+postman> jrandom: ok, i'll do some thinking together with susi</p>
-17:34 < jrandom> w3wt</p>
-17:34 <+postman> jrandom: maybe we'll drop it next week </p>
-17:35 < wiht> It is eepsites.com, and it is a search engine for eepsites.</p>
-17:35 <+postman> but i had a dream that it worked</p>
-17:35 <+postman> :]</p>
-17:35 < jrandom> :)</p>
-17:36  * Complication suspects that descibing all the subtleties which occur in protocols... requires code, and nothing less than code</p>
-17:36 <+Complication> (for most protocols, at least)</p>
-17:36 <@cervantes> nah just some eeevul regex</p>
-17:36 <+postman> Complication: maybe this suspicion is the reason that keeps us from further investigation</p>
-17:37 <+postman> Complication: i am not yet sure, but suspicion alone will not put me to rest on that matter</p>
-17:37 < jrandom> well, an important point here is something dust demonstrated for us -</p>
-17:37  * Complication fears a regex capable of such things</p>
-17:37 < jrandom> code isn't necessarily that scary.</p>
-17:37 <+postman> see? :)</p>
-17:37 <+postman> a good filter modelling language will do the same</p>
-17:38 <+postman> :)</p>
-17:38 <@cervantes> tcl? :)</p>
-17:38 <+Complication> It would have to be good.</p>
-17:38  * jrandom sees that you've got your own flying ponies too postman ;)</p>
-17:38  * dust also felt bad about duplicating code here and there</p>
-17:38 <+postman> jrandom: no cows :)</p>
-17:38 < jrandom> working code >>> theoretical improvements in code </p>
-17:39 <+postman> mmh</p>
-17:40 <+postman> one thing i learned from i2p</p>
-17:40 < wiht> >>> means "much, much better?"</p>
-17:40 <+postman> do not give up on first looks</p>
-17:40 < jrandom> true enough postman </p>
-17:40 < jrandom> yes wiht </p>
-17:41 < jrandom> it would be really cool</p>
-17:41 < jrandom> ok, anyone else have something to bring up for the meeting?</p>
-17:41 <+bar> well, how's the IMAP working, postman? (i read about it in the forums but haven't tried it yet myself)</p>
-17:41 <+postman> bar: try it yourself - i have no user reports yet</p>
-17:41  * cervantes rolls in the pony shaped gong</p>
-17:42 <+bar> ok, will do :)</p>
-17:42 <+postman> bar: and for me it works FINE :)</p>
-17:42 < jrandom> nice</p>
-17:42 <+bar> cool</p>
-17:42 <+postman> cervantes: you're fixated</p>
-17:42 <@cervantes> me?!</p>
-17:42 <@cervantes> :)</p>
-17:43 < jrandom> ok, before we reach the 90 minute mark</p>
-17:43  * jrandom winds up</p>
-17:43  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/151.rst b/i2p2www/meetings/151.rst
new file mode 100644
index 00000000..fabe0924
--- /dev/null
+++ b/i2p2www/meetings/151.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 11, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/152.log b/i2p2www/meetings/152.log
index 4de2f908..40ef226b 100644
--- a/i2p2www/meetings/152.log
+++ b/i2p2www/meetings/152.log
@@ -1,276 +1,270 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 152{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 18, 2005</h3>
-<div class="irclog">
-16:10 < jrandom> 0) hi</p>
-16:10 < jrandom> 1) 0.6.1.3</p>
-16:10 < jrandom> 2) Freenet, I2P, and darknets (oh my)</p>
-16:10 < jrandom> 3) Tunnel bootstrap attacks</p>
-16:10 < jrandom> 4) I2Phex</p>
-16:10 < jrandom> 5) Syndie/Sucker</p>
-16:10 < jrandom> 6) ???</p>
-16:10 < jrandom> 0) hi</p>
-16:10  * jrandom waves</p>
-16:10 < jrandom> weekly status notes are up at http://dev.i2p.net/pipermail/i2p/2005-October/001017.html</p>
-16:10 < dust> yay, works now. thanks Gregor</p>
-16:10 < cervantes> hullo</p>
-16:11 <+fox> <blx> heloa</p>
-16:11 < jrandom> ok, jumping into 1) 0.6.1.3</p>
-16:11 < jrandom> y'all have updated at a pretty good clip, thanks!  </p>
-16:12 < jrandom> things seem to be in reasonable condition, but I don't have much to add beyond whats in the status notes</p>
-16:12 < jrandom> anyone have any questions/comments/concerns re: 0.6.1.3?</p>
-16:13 < jrandom> ok if not, lets jump on in to 2) Freenet, I2P, and darknets (oh my)</p>
-16:13 < cervantes> 609 known peers!</p>
-16:14 < cervantes> (w00t)</p>
-16:14 < jrandom> aye, network has been growin'</p>
-16:14 <+fox> <blx> oh my!</p>
-16:14  * cervantes is holding a sweepstake for how long until the big 1000</p>
-16:14 < jrandom> heh</p>
-16:14 < tethra> heheh</p>
-16:15 < tethra> are we betting with digital cash? ;)</p>
-16:15 < cervantes> but it show how solid i2p core has got lately that the user uptake has been accelerating</p>
-16:16 < cervantes> nah...jrandom has already unknowningly donated all his beer money for this year</p>
-16:16 < jrandom> hehe</p>
-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?</p>
-16:18 < cervantes> as you said, if nothing else it has stimulated some interesting semi-related security discussions ie 3)</p>
-16:18 < jrandom> if not, we can jump forward at a quick pace to 3) Tunnel bootstrap attacks</p>
-16:18 < jrandom> aye, that it has</p>
-16:19 < jrandom> the issue Michael brought up quantifies a general view i've had, but its nice to make it explicit</p>
-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</p>
-16:21 < jrandom> does it make sense to people, or do people have any questions or concerns about it?</p>
-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</p>
-16:23 < cervantes> I'll put myself in the ignorance is bliss category</p>
-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</p>
-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)</p>
-16:24 < jrandom> but after a few seconds, the number grows large enough to turn (c/n)^t into a really really small number</p>
-16:25 < tethra> (c/n)^t is...</p>
-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)</p>
-16:25 < jrandom> c == # of colluding peers (bad guys), n == # of peers in the network, t == # of tunnels you've built.</p>
-16:25 < cervantes> right...</p>
-16:25 < tethra> ah</p>
-16:26 < jrandom> so as t grows, the probability of successful attack gets really small</p>
-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?</p>
-16:26 < jrandom> (or, in any case, smaller than the probability of taking over all hops in a tunnel)</p>
-16:26 < tethra> ahh, i see</p>
-16:27 < jrandom> cervantes: immediately, before the 3rd tunnel is built</p>
-16:27 < jrandom> (assuming you use 3 hop tunnels)</p>
-16:27 < cervantes> that's fairly improbable</p>
-16:28 < cervantes> just from a use case perspective</p>
-16:28 < jrandom> 'zactly.</p>
-16:28 < jrandom> and since we build more than 3 tunnels on startup before letting any clients run, its not just a probability issue</p>
-16:28 < jrandom> but its good to quanitify the attack anyway</p>
-16:29 < cervantes> is it worth letting the router churn for a bit longer to guard against any likelyhood?</p>
-16:30 < cervantes> or churn harder...</p>
-16:30 < jrandom> perhaps.  if we ignore connection establishment time as well as nonrandom peer selection, it has no likelihood</p>
-16:31 < tethra> that's cause for a "woot!" i take it?</p>
-16:32 < jrandom> aye, though from an engineering perspective, we shouldn't ignore those characteristics ;)  </p>
-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</p>
-16:34 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2Phex</p>
-16:34 < jrandom> sirup isn't here, and i haven't seen striker on irc - redzara, you around?</p>
-16:36 <+redzara> yes</p>
-16:36 <+redzara> First pass is nearly completed : port Sirup's mod to lastest phex cvs.</p>
-16:36 < jrandom> nice1!</p>
-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 :)</p>
-16:37 <+redzara> maybe terminated for this W.E.</p>
-16:37 < jrandom> wow that'd be great</p>
-16:37 <+redzara> Pass three : refactoring comm layer with GregorK</p>
-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</p>
-16:38 < jrandom> this is i2p, we're used to instability :)</p>
-16:38 <+fox> <GregorK> :)</p>
-16:38 <+redzara> For the last pass, as I've currently no contact with GregorK, this sould be pretty hard :(</p>
-16:38 < jrandom> GregorK: what would you recommend for inegration?</p>
-16:39 <+fox> <GregorK> well you now have contact with me ;)</p>
-16:39 < jrandom> ah 'k redzara, the first two are big enough in any case :)</p>
-16:39 <+redzara> GregorK : hi man</p>
-16:40 <+redzara> GregorK : I've read carefully all codes</p>
-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</p>
-16:40 <+fox> <GregorK> all?? wow...</p>
-16:40 <+redzara> Gregork : yes, all !!</p>
-16:41 < cervantes> he even knows the size of your underwear</p>
-16:41 < Rawn> :D</p>
-16:41 <+fox> <GregorK> great... next time I'm shopping I just need to ask you... </p>
-16:43 <+fox> <GregorK> what would be nice if we could maybe have someone from the i2phex team on the phex team too..</p>
-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?</p>
-16:43 <+redzara> Sorry, but I don't understand / speak /read / write english good enough to  laugh with what you have writed</p>
-16:43 <+fox> <GregorK> this would also help solve bugs that are on both sides</p>
-16:44 < jrandom> GregorK: hopefully we'll find a way that the I2P side is just a thin plugin in Phex though, right?</p>
-16:44 < jrandom> or do you think the two should stay separate?</p>
-16:44 <+redzara> jrandom : I think we could have an Phex 2.6.4 over I2P, for me I2Phex is down</p>
-16:45 < jrandom> down?</p>
-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.</p>
-16:45 < jrandom> cool, yeah, its a lot of work, I'm sure</p>
-16:46 < jrandom> especially when you look at things like java.net.URL (which leaks DNS requests on instantiation, etc)</p>
-16:46 <+redzara> jrandom : down, endded</p>
-16:46 <+Ragnarok> grr</p>
-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</p>
-16:47 <+fox> <GregorK> right... I think Phex uses the apache URI class in some places to work around this.. but only when necessary</p>
-16:48 < jrandom> ah right, I remember playing around with that library, looks good</p>
-16:49 < jrandom> we'll definitely be helping audit things a bit for anonymity/security before pushing it for end users over i2p</p>
-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)</p>
-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</p>
-16:50 <+fox> <GregorK> oh i'm sure there are many problems in phex. :)</p>
-16:50 < jrandom> ah, yeah sockets will be easy, but we may need to disable other things.  what is udp used for - quick queries?</p>
-16:51 <+fox> <GregorK> currently only bootstrapping</p>
-16:51 <+fox> <GregorK> UDP Host Cache.. a replacement for GWebCache</p>
-16:52 < jrandom> ahhh, ok.  </p>
-16:52 <+redzara> So we don't need it if we have a descent GwebCache ?</p>
-16:53 <+fox> <GregorK> yes... but the standard GWebCache have there security problems too...</p>
-16:53 <+redzara> GregorK : not inside I2P I think</p>
-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!"</p>
-16:54 < jrandom> but you're right, its soemthing that needs to be verified </p>
-16:54 <+fox> <GregorK> also firewall to firewall transfers would be a UDP topic we like to implement once we find a volunteer :)</p>
-16:54 < jrandom> ah, well, I2P doesn't need firewall to firewall transfers - I2P exposes an entirely open end to end address space :)</p>
-16:55 < jrandom> but... ooh, thats something that might be useful</p>
-16:55 < jrandom> if Phex users had "0 hop tunnels", they'd get free NAT traversal/firewall to firewall transfers with pretty decent speed</p>
-16:55 <+fox> <GregorK> another one would be LAN broadcasts of queries and such... for easier sharing of contents in private networks</p>
-16:56 < jrandom> (0 hop tunnels offers a level of plausible deniability without requiring any intermediary peers to carry the trafffic)</p>
-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?</p>
-16:58 < cervantes> *disabled by default</p>
-16:58 <+fox> <GregorK> well its not available yet.. but in this case user usually know each other anyway to build that private network..</p>
-16:58 < jrandom> oh right cervantes </p>
-16:58 < jrandom> right right GregorK</p>
-16:59 <+fox> <GregorK> are there any changes regarding the user interface??</p>
-17:00 <+bar> well, we won't need flags :)</p>
-17:00 < jrandom> at the least, the ability to have a few configuration options related to I2P would be useful.</p>
-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 </p>
-17:01 <+redzara> And what about bitzyNot for the moment, but flags and countries are unused</p>
-17:01 < jrandom> bitzy?</p>
-17:01 <+redzara> sorry, wrong coupy/paste :(</p>
-17:02 <+fox> <GregorK> can you provide a list of configuration options and optional features you need?</p>
-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</p>
-17:03 < jrandom> we'll get you the details though</p>
-17:02 <cervantes> [x] Super transfer speed mode</p>
-17:02 <+fox> < GregorK> well bitzi is used to identify files.. is that an anonymity problem?</p>
-17:03 < vulpine> <redzara> GregorK : I'm preparing it, but basicly, thre is no changes</p>
-17:03 <+fox> < GregorK> :) ask your provider cervantes...</p>
-17:03 <redzara> GregorK : maybe, I'm working on it</p>
-17:04 <cervantes> GregorK: heh UK resident....no chance ;-)</p>
-17:04 <+fox> < GregorK> if you transfer files between 2 Phex instances on the same PC.. transfers are lightning fast ;)</p>
-17:05 <cervantes> cool...I have lots of cool movies I can share with myself :)</p>
-17:05 <cervantes> * strike that from the meeting notes *</p>
-17:06 <bar> jrandom touched the subject before, but, here's that crazy idea again:</p>
-17:06 <+bar> how 'bout integrating i2p into Phex, so that ordinary users have 0-hop tunnels?</p>
-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</p>
-17:07 <+bar> (for plausible deniability and udp firewall hole punching)</p>
-17:08 <+fox> <GregorK> not sure if I really understand what that means ;)</p>
-17:08 <+bar> probably me neither ;)</p>
-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</p>
-17:09 <+bar> jrandom, i'm sure you're catching my drift here, could you elaborate?</p>
-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</p>
-17:09 <+redzara> GregorK : so you have to strip all code related to host+port + IsLocalIP + Is PrivateIP + ...</p>
-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</p>
-17:10 < jrandom> (though eventually, they all will ;)</p>
-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.</p>
-17:10 < jrandom> agreed</p>
-17:10 <+bar> (damn, didn't think of that)</p>
-17:11 <+bar> yeah, def.</p>
-17:11 < jrandom> this is flying pony stuff.  lets get the practical things first</p>
-17:11 <+fox> <GregorK> and after we see how good that worked we can decide how we go further.. </p>
-17:11 < jrandom> exactly</p>
-17:12 <+fox> <GregorK> redzara: I like to have two implementations of HostAddress one for i2p and on like the current.</p>
-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</p>
-17:14 <+fox> <GregorK> sure.. no problem..</p>
-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?</p>
-17:15 < jrandom> (for the phase 2 part.  your phase 3 will take more work integrating with the mainline)</p>
-17:15 <+redzara> jrandom : next sems to be ok for me</p>
-17:16 < jrandom> ok great</p>
-17:16 <+redzara> s/next/next week/</p>
-17:16 < jrandom> ok, this is pretty exciting stuff, it'll be wonderful to get it going smoothly </p>
-17:17 < jrandom> does anyone have anything else to bring up for 4) I2Phex, or shall we move on briefly to 5) Syndie/Sucker?</p>
-17:17 < cervantes> I2P will surely benefit from such killer apps</p>
-17:18 <+fox> <GregorK> btw there is a Phex CVS mailing list for all CVS changes in Phex... if that is of any help</p>
-17:18 < jnymo> *ehem*.. hell yes</p>
-17:18 < jrandom> ok great, thanks GregorK</p>
-17:18 < jrandom> definitely cervantes </p>
-17:19 < jrandom> ok, on 5), I don't really have anything to add beyond whats there</p>
-17:19 < jrandom> dust: are you around?</p>
-17:19 <+redzara> GregorK : Thanks but handlingone version is far enough for me :)</p>
-17:19 < jrandom> hehe redzara </p>
-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.</p>
-17:20 < dust> unless anyone have a better idea</p>
-17:20 < jrandom> kickass</p>
-17:20 < jrandom> that sounds perfect.</p>
-17:21 < jrandom> though, hmm, maybe it'd need an additional field (the "what blog to post it in" and "what tag prefix")...</p>
-17:21 < jrandom> maybe a separate form/table would make sense, though maybe not</p>
-17:22 < dust> oh, I thought addresses.jsp was for one blog only (since you have to login to get there?)</p>
-17:22 < jrandom> ah, true, good point</p>
-17:23 < jrandom> the updater part is kind of fuzzy, but you're right</p>
-17:23 < dust> (we'll figure it out when we get there)</p>
-17:23 < jrandom> aye</p>
-17:24  * jnymo thinks www.i2p.net could start up a 'merchandise cafe' type thing</p>
-17:24 < jnymo> with eyetoopie shirts that say "I am Jrandom" on them ;)</p>
-17:24  * mrflibble  is still catching up on the "flamewar",  which seems to be spiraling into  a proper flamewar :)</p>
-17:24 < jrandom> heh jnymo </p>
-17:25 < jrandom> yeah, there's a lot of content in that thread</p>
-17:25 < jrandom> ok, maybe this gets us to 6) ???</p>
-17:25 < jrandom> anyone have anything else to bring up for the meeting?</p>
-17:25 <+bar> aye, just a quick note on the symmetric nat issue (been doin a lil snoopin'):</p>
-17:25 <+nickless_head> jrandom: I know the truth!</p>
-17:25 <+fox> <blx> kaffe?</p>
-17:25 < mrflibble> oops,  sorry jr</p>
-17:26 < jnymo> but seriously.. every open source project of any size has their own merchandise section</p>
-17:26 <+nickless_head> jrandom: I have definite proof you hacked the last.fm homepage!</p>
-17:26 <+nickless_head> (the what you get when you sign up section listed 'a pony')</p>
-17:26 < jrandom> jnymo: i think you're right, we will want to explore that avenue, might be a good method of fundraising too</p>
-17:27 < jnymo> jrandom: exactly</p>
-17:27  * mrflibble would buy the tshirt</p>
-17:27 <+bar> right, regarding symmetric nats,</p>
-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.</p>
-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:// :(</p>
-17:28 < jnymo> You probably wouldn't want to wear it in public until i2p has a few thousand users though ;)</p>
-17:28 <+bar> (i believe this is how e.g. Hamachi and Skype do udp hole punching from behind symmetric nats)</p>
-17:28 <+nickless_head> jnymo: cups would rule :)</p>
-17:28 <+bar> based on what i have read on the 'net so far, symmetric nat prediction algos pretty much suck.</p>
-17:28 < jrandom> hmm bar</p>
-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</p>
-17:28 < jrandom> yeah, thats what i read too</p>
-17:29 <+bar> i will try gathering some more good, relevant reading material on this.</p>
-17:29 <+redzara> Small question : what was the common average percentage of bytes retransmitted in 0.6.1.3 ?</p>
-17:29 < jrandom> thanks bar</p>
-17:29 <+fox> <jme___> bar, the prediction they got are consistent ? </p>
-17:29 <+fox> <jme___> bar, let me rephrase :)</p>
-17:29 <+fox> <blx> jrandom, i'm sad to hear</p>
-17:30 < jrandom> redzara: I unfortunately forgot to put that into the netDb.  I do see 2.6 and 3.8 right now though</p>
-17:30 < jrandom> blx: me too :(</p>
-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 ?</p>
-17:30 < jrandom> blx: i know they're doing some merging with classpath now though, so hopefully once thats sorted</p>
-17:30 <+fox> <blx> probably means i wont be joining the party</p>
-17:30 < jrandom> blx: are you kaffe-specific, or OSS/DFSG-specific?</p>
-17:31 <+fox> <blx> free software</p>
-17:31 <+fox> <blx> dfsg you could say</p>
-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?</p>
-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</p>
-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</p>
-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)</p>
-17:32 < jrandom> i know there are some cheap ones in germany too</p>
-17:33 <+fox> <jme___> bar, 97% would be terrific</p>
-17:33 < jrandom> redzara: what are you seeing for retransmission rate?</p>
-17:33 <+bar> jme___: yeah, so i guess most symmetric nats are predictable</p>
-17:33 <+fox> <blx> jrandom, i sure hope so. i'm really interested in this shit :)</p>
-17:33 <+fox> <jme___> bar, what would you do ? relay, udp hole punching, cnx reversal.. is there others thech ?</p>
-17:33 < jnymo> is 99 expensive, on average?</p>
-17:34 <+redzara> jrandom between 3;8 and 4.2</p>
-17:34 < jrandom> jme___: we're udp, no need for connection reversal :)</p>
-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 ;)</p>
-17:35 < jrandom> jnymo: for 1250GB, not really.  i've seen 60-120USD/mo for 50-100GB/mo</p>
-17:35 < jrandom> bar: perhaps UPnP would be a better way to go?</p>
-17:35 <+fox> <jme___> jrandom, even with udp it is usefull :)</p>
-17:35 <+redzara> jrandom : but only some node done major impact, maybe some olders</p>
-17:35 <+fox> <jme___> vulpine: ok</p>
-17:35 < jrandom> though that only helps the people who could control their NAT</p>
-17:36 <+fox> <jme___> upnp must be supported but it isnt exclusive to other means</p>
-17:36 < jrandom> well, we're doing everything we do now without any UPnP</p>
-17:36 <+fox> <jme___> because upnp isnt supported by all nat, far from it</p>
-17:36 < jrandom> right, e.g. an ISP's nat</p>
-17:36 <+bar> jrandom: if there are no security issues with upnp, i guess it can't hurt. though, hamachi doesn't use upnp</p>
-17:36 <+fox> <jme___> here by 'must' = to provide the max connectivity</p>
-17:37 <+fox> <jme___> ok going back to my c++ :)</p>
-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</p>
-17:38 < jrandom> l8s jme___</p>
-17:38 < jrandom> yeah, it'd be ideal if we didn't need it</p>
-17:39 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
-17:41 < jrandom> if not...</p>
-17:41  * jrandom winds up</p>
-17:41  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/152.rst b/i2p2www/meetings/152.rst
new file mode 100644
index 00000000..3dae84c0
--- /dev/null
+++ b/i2p2www/meetings/152.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 18, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/153.log b/i2p2www/meetings/153.log
index c83fd4ac..81f82f37 100644
--- a/i2p2www/meetings/153.log
+++ b/i2p2www/meetings/153.log
@@ -1,446 +1,440 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 153{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 25, 2005</h3>
-<div class="irclog">
-16:24 < jrandom> 0) hi</p>
-16:24 < jrandom> 1) Net status</p>
-16:24 < jrandom> 2) Fortuna integration</p>
-16:24 < jrandom> 3) GCJ status</p>
-16:24 < jrandom> 4) i2psnark returns</p>
-16:24 < jrandom> 5) More on bootstrapping</p>
-16:24 < jrandom> 6) Virus investigations</p>
-16:24 < jrandom> 7) ???</p>
-16:24 < jrandom> 0) hi</p>
-16:24  * jrandom waves</p>
-16:24 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-October/001079.html</p>
-16:25  * susi23 waves back</p>
-16:26 < jrandom> lets jump on in to 1) net status</p>
-16:26 < jrandom> as I mentioned, things look pretty reasonable so far.  </p>
-16:26 <+fox> <Romster> ah meeting sweet</p>
-16:27 < jrandom> there is some good stuff coming down the line too, so we'll have a new release later this week</p>
-16:27 < jrandom> anyone have anything they want to bring up regarding 1) net status?</p>
-16:27 <@cervantes> omg 7 issues</p>
-16:27 <+legion> yup looking good :-)</p>
-16:27 < jrandom> busy week cervantes :)</p>
-16:28 <@cervantes> can only be good</p>
-16:28 <+Complication> Works relatively well, dev.i2p even - I can even pull CVS checkouts without EOF messages.</p>
-16:28 < jrandom> nice :)</p>
-16:28 <+Complication> Might have been release-related overloads, those last ones.</p>
-16:28 <+Complication> But I can't tell.</p>
-16:28 < jrandom> dev.i2p is on the latest build code too (-7), so it'll be hopefully performing substantially better than before</p>
-16:29 < jrandom> s/dev.i2p/cvs.i2p (etc)/</p>
-16:29 <+legion> forums.i2p also seems to be much better than before :)</p>
-16:29 <@cervantes> *ahem*</p>
-16:29 <+fox> <Romster> is i2p safe to let others join etc?</p>
-16:29 <+Ragnarok> ok, now I've got to try this miraculous "cvs checkout that works the first time"</p>
-16:30 <+fox> <Romster> since there is no known limits now</p>
-16:30 <@cervantes> that's because everyone's hammering i2p-list instead of posting to the forum </p>
-16:30 <+legion> hmm you sure cervantes?</p>
-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</p>
-16:30 < jrandom> heh cervantes ;)</p>
-16:30 < jrandom> hush Ragnarok, you'll jinx it!</p>
-16:31 <+Ragnarok> wow... it's true.  I'm speechless</p>
-16:31 <+fox> <Romster> k jrandom</p>
-16:31 < jrandom> (man my eyes are watering from the curry my roomates are cooking downstairs)</p>
-16:31 < jrandom> nice1 Ragnarok </p>
-16:32 <+fox> <Romster> lol now that's a strong curry</p>
-16:32 < jrandom> ok, if there's nothing else on 1), we can jump quickly through 2) Fortuna integration</p>
-16:32 < jrandom> (true that Romster)</p>
-16:32 <+fox> <shardy> yay for fortuna integration!</p>
-16:32 <+fox> <Romster> moving onto 2) :P</p>
-16:32 <+fox> <Romster> what is fortuna?</p>
-16:32 < jrandom> heh thought you'd like that shardy :)</p>
-16:32 <+fox> <Romster> i've been a bit behind the last month</p>
-16:32 <+Complication> PRNG algo, if I remember.</p>
-16:33 <+Complication> Supposedly a good one, or so they write. :P</p>
-16:34  * Complication knows nothing about its inner workings, though</p>
-16:34 < jrandom> shardy: I'd love if you could give it a look sometime</p>
-16:34 <+fox> <shardy> of course</p>
-16:34 <+fox> <shardy> you're using the gnu implementation?</p>
-16:34 < jrandom> Romster/Complication: there are some links in the email</p>
-16:34 < jrandom> yeah shardy - http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/gnu/crypto/prng/Fortuna.java</p>
-16:35 < jrandom> (integrated with http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/core/java/src/net/i2p/util/FortunaRandomSource.java )</p>
-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)</p>
-16:36 < jrandom> ok, anyway, this looks cool, as we've been hacking through getting that support in there for probably a year now</p>
-16:37 < jrandom> (fortuna integration was one of the main projects driving smeghead to build 'pants' ;)</p>
-16:37 < jrandom> if anyone has any questions/comments/concerns about it, please bounce 'em to the list</p>
-16:37 < jrandom> (or email, or forum, of course)</p>
-16:38 <+fox> <Romster> yeah where is smeghead hes not been around for awhile now</p>
-16:38 < jrandom> smeghead is [redacted] doing [redacted]</p>
-16:39 < jrandom> ok, moving on to 3) GCJ status</p>
-16:39 < jrandom> i2p works on GCJ!  [w00t!]</p>
-16:39 <+susi23> nice job</p>
-16:39 <+legion> sweet</p>
-16:39 < jrandom> at least, it does on GCJ 4.0.2 on linux 2.6.12.  I haven't tried any other platforms</p>
-16:40 < jrandom> yeah, the GCJ and GNU Classpath folks have worked wonders</p>
-16:40 < jrandom> it was really easy to get it building, the old static reference classes I remember weren't necessary</p>
-16:41 <+Complication> Which sounds quite positive, given Sun Java's less-than complete openness (with regard to distribution, if I remember correct).</p>
-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</p>
-16:41 <+susi23> (next we try to run it on J2ME ;)</p>
-16:42 <+fox> <Romster> GCJ to take over Suns JVM></p>
-16:42 < cat-a-puss> how is preformance with GCJ?</p>
-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</p>
-16:42 < jrandom> cat-a-puss: comparable</p>
-16:42 < jrandom> most of the heavy work in i2p is already done by assembler code ;)</p>
-16:43 <+fox> <Romster> how would i2p go with C#/mono again with that jave to C# adition (forgot it's name)</p>
-16:43 <+fox> <Romster> i remember jrandom and i both tryed it out ages ago</p>
-16:43 < jrandom> no idea.  but if it works with gcj, it might work with ikvm - the mono jvm thing</p>
-16:44 <+Ragnarok> IKVM</p>
-16:44 <+Ragnarok> nm</p>
-16:44 <+fox> <Romster> ah tahts the one ikvm</p>
-16:44 <+fox> <Romster> much difereances with GCJ and IKVM and Sun's?</p>
-16:45 < jrandom> i've never used ikvm</p>
-16:45 <+fox> <Romster> i'm sure you have once with mono or was that eclipse?</p>
-16:45 <+fox> * Romster shrugs</p>
-16:45 < jrandom> and i2p as shipped doesn't currently support the router console, though it does support the router operation, i2ptunnel, and sam</p>
-16:46 <+Ragnarok> what's blocking the router console?</p>
-16:47 <+susi23> xerces, when I remember correctly</p>
-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</p>
-16:47 < jrandom> there are some additional requirements of the latest xerces, it seems</p>
-16:48 < jrandom> (for jar files we don't currently ship).  however, I'm sure we can track it down</p>
-16:49 <+fox> <Romster> jrandom is good at tracking down problems :)</p>
-16:49 < jrandom> even better at making problems</p>
-16:49 <+fox> * Romster featches a coffee</p>
-16:49 < jrandom> ok, anything else on 3) GCJ status?</p>
-16:49 < jrandom> or shall we move on to 4) i2psnark</p>
-16:50 < jrandom> consider us moved</p>
-16:50 < jrandom> ok, i2psnark is back (yay)</p>
-16:51 < jrandom> not much I have to add to whats in the mail... you have anything Ragnarok?</p>
-16:51 <+Ragnarok> nope</p>
-16:51 <+susi23> regarding web frontend</p>
-16:51 <+Ragnarok> more testing would be nice though, so everyone should try it :)</p>
-16:52 <+susi23> supporting it with susibt shouldn't be a problem</p>
-16:52 < jrandom> ooh give us the scoop susi23 :)  </p>
-16:52 < jrandom> nice</p>
-16:52 <+fox> <jme___> naive question, why spending time supporting old bt client while other (azureus) support full blown client ?</p>
-16:52 < jrandom> jme___: azureus *is* kickass</p>
-16:52 <+susi23> major release of susibt is scheduled for november :)</p>
-16:53 < jrandom> heh cool susi23 </p>
-16:53 <+Complication> To me, Azureus seemed terribly complex.</p>
-16:53 <+Ragnarok> azureus blows monkey chunks</p>
-16:53 <+susi23> for me, I always need a headless solution</p>
-16:53 <+Ragnarok> not to put too fine a point on it</p>
-16:53 <+fox> <jme___> ok :)</p>
-16:53 < jrandom> jme___: azureus is a bit heavyweight though, but is a great general purpose bt solution</p>
-16:53 <+Complication> (I personally could see the day I'd misconfigure something in it, and dent my anonymity.)</p>
-16:54 <+fox> <jme___> it make sense, just wanted to know</p>
-16:54 <+fox> <Romster> to me azerious never workd well i've moved to bitlord which does work</p>
-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</p>
-16:54 <+legion> Yeah azureus is just too big and complicated for i2p</p>
-16:54 <+Complication> If the goal is bundling a bt client along with i2p, a lightweight client sounds best.</p>
-16:54 <+fox> <Romster> KISS principal</p>
-16:54 <+Ragnarok> I like the official client best, but i2psnark has the major advantage of being simple enough for me to hack on</p>
-16:55 <+legion> thing is i2p doesn't need a heavyweight bittorrent client</p>
-16:55 < jrandom> yeah, its really clean code (with oddball gnu formatting ;)</p>
-16:55 <+Ragnarok> damn gnu</p>
-16:55 <+Ragnarok> worst brace style ever</p>
-16:55 < jrandom> heh</p>
-16:55 <+fox> <Romster> heh code reformatter :)</p>
-16:55 <+Ragnarok> jrandom won't let me :)</p>
-16:55 <+Ragnarok> well, for good reason</p>
-16:55 <+fox> <jme___> independance and simplicity are criteria i definitly agree with</p>
-16:56 <+fox> <Romster> will there be options to enable the bt-torrent program on each i2p node?</p>
-16:56 < jrandom> aye, it'd be nice if we can backport multitorrent, piece selection, and web capacity to mjw's mainline snark</p>
-16:56 <+Ragnarok> the simpler it is, the more likely it will be maintained</p>
-16:56 < jrandom> exaaactly Ragnarok </p>
-16:57 <+legion> yeah backporting those would be killer</p>
-16:57 <+fox> <Romster> as a OT point here take a look at emules KAD network i think it's rather neat.</p>
-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</p>
-16:58 <+Ragnarok> we need to be able to ship a .torrent maker as well, though.  And a tracker would be nice.</p>
-16:58 < jrandom> yeah, actually, snark has both of those, I just disabled them because i didn't want to maintain 'em :)</p>
-16:58 <+legion> hmm good point ragnarok</p>
-16:58 < jrandom> but getting them back in wouldn't be much trouble</p>
-16:59 <+Ragnarok> well, the torrent maker at least shouldn't be that bad</p>
-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</p>
-17:00 < jrandom> (and review http://dev.i2p/~jrandom/snark_diff.txt for changes)</p>
-17:00 <+fox> <Romster> since snarik is back it'll get worked on right :)</p>
-17:00 <+legion> actually when it comes to a tracker, it'd be better to come up with a distributed solution</p>
-17:00 <+fox> <Romster> snark*</p>
-17:00 < jrandom> porting code is easier than building a new distributed tracker legion ;)</p>
-17:00 <+fox> <Romster> legion, your your talking</p>
-17:00 <+legion> true, that</p>
-17:01 < jrandom> but I wouldn't be opposed to integrating a nice clean maintained anonymity-friendly distributed tracker solution :)</p>
-17:01 <+fox> <Romster> could be tacked onto the eepsites?</p>
-17:01  * jrandom spots a flying pony go past the window</p>
-17:01 <+Ragnarok> the official bt client has a kademlia based distributed tracker, but obviously that's only good as a design reference</p>
-17:01 <+legion> a place to start ;)</p>
-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</p>
-17:03 <+Ragnarok> they're based on the same algorithm, but they're not in any way compatable</p>
-17:03 <+Ragnarok> compatible, even</p>
-17:04 <+Ragnarok> doing something like emule's KAD for i2phex would be sort of interesting...</p>
-17:04 <+Ragnarok> anyway, flying ponies</p>
-17:04 < jrandom> :)</p>
-17:04 < jrandom> (agreed on both counts)</p>
-17:04 < jrandom> ok, anything else on 4) i2psnark?</p>
-17:05 <+Ragnarok> as long as we have something to make .torrent files, the existing trackers are fine</p>
-17:05 < jrandom> thats a good point - there's some commented out code in Snark's main I believe</p>
-17:05 <+legion> no I think the existing trackers are not fine :(</p>
-17:05 < jrandom> whats wrong with them legion?</p>
-17:05 < cat-a-puss> don't just hand uesrs a torrent file ether</p>
-17:05 <+legion> often have trouble accessing them</p>
-17:06 < jrandom> hmm cat-a-puss?  oh, you mean, we need to get a web interface to transparently swarm?</p>
-17:06 <+legion> sites get flooded with traffic</p>
-17:06 < jrandom> ah, thats i2p's issue, hopefully 0.6.1.4 will improve that</p>
-17:06 < jrandom> postman was telling me how he was getting tons of hits @ tracker.postman.i2p</p>
-17:06 < jrandom> i forget the #s offhand</p>
-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</p>
-17:07 < jrandom> orion.i2p/bt/ isn't really used though</p>
-17:07 < jrandom> (and tracker-fr seems lively)</p>
-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 :)</p>
-17:07 < cat-a-puss> also prevents confusing an i2p torrent with a non-anonymous one</p>
-17:07 <+fox> <jme___> http tracker for bt doesnt scale due to poorely designed protocol</p>
-17:07 <+fox> <Romster> router watchdog router hung hard restart wtf</p>
-17:07 <+legion> right, which is my point some trackers are flooded while others are idle</p>
-17:07 < jrandom> cat-a-puss: ah, yeah I'd love to integrate hooks from syndie into susibt :)</p>
-17:07 <+fox> <jme___> it can be easily fixed but break the compatibility with official bt protocol</p>
-17:08 <+fox> <jme___> it is the road followed by the dht tracker stuff</p>
-17:08 < jrandom> (and the other way around, so people can easily syndicate .torrent files, etc)</p>
-17:08 <+Complication> Romster: I get those, but the machine I get them on is borderline (300 MHz)</p>
-17:08 <+fox> <Romster> the distributed tracker is the solution to hammered trackers</p>
-17:08 < jrandom> legion: that can easily be remedied by people using different trackers :)</p>
-17:08 <+fox> <Romster> azerius DHT</p>
-17:08 < jrandom> code is expensive, using different URLs is cheap</p>
-17:08 <+legion> yeah, but they don't seem to be doing that do they?</p>
-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.</p>
-17:09 <+Complication> In due time... surely someone can go distributed too.</p>
-17:09 <+legion> Instead of of posting torrents to tracker sites, they could post a bith and whatever details to their eepsite.</p>
-17:10 < jrandom> bith == hash?</p>
-17:10 <+legion> yeah, stands for bittorrent hash, not my term</p>
-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.)</p>
-17:11 <+legion> yeah, that would be great</p>
-17:11 < jrandom> aye Complication </p>
-17:11 <+fox> <Romster> yeah torrent updates</p>
-17:11 <+fox> <Romster> ok next item ont he list :)</p>
-17:12 < jrandom> ok, 5) more on bootstrapping</p>
-17:12 <+legion> yeah lets move on</p>
-17:12 < jrandom> lots of interesting stuff on the list as of late, and no way am i going to summarize it all here :)</p>
-17:12 <+fox> <Romster> bootstraping the i2p router database?</p>
-17:12 < jrandom> anyone have any questions/comments/concerns they want to discuss about the thread?</p>
-17:12 < jrandom> Romster: see the list and/or email</p>
-17:12 <+fox> * Romster needs to read that list</p>
-17:13 < jrandom> aye, there's good stuff on there :)</p>
-17:13 <+fox> <Romster> i've been rather busy laterly</p>
-17:13 <+Complication> 26 messages to read through, can't comment yet</p>
-17:13 < jrandom> still no end result, but we're looking towards a new way of building tunnels for 0.6.2</p>
-17:14 <+fox> <Romster> a new way, is there a flay in the current method?</p>
-17:14 <+fox> <Romster> flaw*</p>
-17:14 < jrandom> Michael's analysis shows the attack is not really a problem now, as there are easier attacks on the alternatives</p>
-17:14 < jrandom> read the list ;)</p>
-17:14 <+fox> <Romster> arg later</p>
-17:14 <+fox> <Romster> this is now :)</p>
-17:15 <+fox> <Romster> i'm noramlly asleep at this time.</p>
-17:15 <+fox> <Romster> so i rearly get to be at a meeting</p>
-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</p>
-17:16 <+fox> <Romster> so its todo with attack methods and tunnel creation i assume, without reading the list yet</p>
-17:16 < cat-a-puss> (that's for Jrandom)</p>
-17:16 < jrandom> cat-a-puss: i'm not sure if we've really hashed out an end result yet</p>
-17:16 <+fox> <Romster> be an idea cat-a-puss</p>
-17:17 <+Complication> Romster: yes, it was more-or-less about giving the endpoint of an exploratory tunnel less influence as a possible attacker</p>
-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</p>
-17:17 < jrandom> well, not influence - i2p is a free route mixnet - but less information</p>
-17:18 <+Complication> Yes, that would likely be a more correct term</p>
-17:18 < jrandom> (the above linked url is full of arm waving, no solid crypto figured out yet)</p>
-17:18 <+fox> <Romster> lesss = better for more robustness agenst attacks, i get what your geting at</p>
-17:18 < jrandom> ((but i think its all doable with existing techniques)</p>
-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</p>
-17:20 < jrandom> (plain telescopic building would be off the chart before hitting x=200)</p>
-17:20 < jrandom> ((so what we have now is literally orders of magnitude better))</p>
-17:20 < jrandom> but we can improve upon that further</p>
-17:21 < jrandom> though there's also the garlic routing alternative too</p>
-17:21 < jrandom> anyway, yeah, more things to be hashed out, keep an eye on the list :)</p>
-17:21 <+fox> <Romster> ok i'll have a good read of that list later</p>
-17:22 <+fox> <Romster> and see if i can think of anything too add</p>
-17:22 < jrandom> cool</p>
-17:22 < cat-a-puss> would the "new" telescopic method be fast enough to do on demand construction?</p>
-17:22 < jrandom> I'm not sure we want that</p>
-17:22 < jrandom> its the O(1) vs O(N) issue</p>
-17:23 < jrandom> the new technique would allow tunnel creation without using the exploratory tunnels, leavng the exploratory tunnels for netDb operation </p>
-17:23 < jrandom> (and for exploratory tunnel creation :)</p>
-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</p>
-17:24 <+legion> sounds good :)</p>
-17:24 <+legion> I'd think some screwing like that would be good</p>
-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.</p>
-17:25 <+fox> <Romster> exploratory tunnels to collect netDB router refereances?</p>
-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</p>
-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</p>
-17:26 < jrandom> or what do you mean by speed things up?</p>
-17:26 <+fox> <Romster> and if it got to the point of being detected it could then drop off and go silent forawhile?</p>
-17:26 < jrandom> using the new technique would reduce the failed tunnel creations, certainly</p>
-17:26 <+fox> <Romster> or mistearly change it's key and continue or something heh</p>
-17:26 < jrandom> romster: it'd probably be worth digging through the mails to review the attack ;)</p>
-17:27 <+fox> <Romster> yeah after sleep</p>
-17:27 <+Complication> Romster: afaik, it's a passive attack mostly, so the target can't detect it occurring</p>
-17:27 <+fox> <Romster> and fixing a friends pc i got sitting here</p>
-17:27 <+fox> <Romster> ah ic complication.</p>
-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. </p>
-17:28 <+Complication> (but I might be wrong, and those last 26 messages might have active components)</p>
-17:28 <+fox> <Romster> would a long term passive attack evently find the target?</p>
-17:28 <+fox> <Romster> i'll comment after i've read the list</p>
-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)</p>
-17:28 <+Complication> Romster: well, persisting the attack beyond tunnel lifetime would require resources and patience</p>
-17:28 <+fox> <Romster> and understand it better</p>
-17:29 <+Complication> But time plays a part in every probability of success. You try long, you get more chances.</p>
-17:29 <+fox> <Romster> ah that's the idea tunnel life tiem be too short to actually have a worthwhile attack work.</p>
-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</p>
-17:29 <+fox> <Romster> time*</p>
-17:30 < jrandom> right Complication - each sample occurs only 'm' times every (c/n) tunnels</p>
-17:30 <+fox> <Romster> there is no interaction between each tunnel to gather stastics?</p>
-17:30 <+fox> <Romster> as one is about to die and another is being built</p>
-17:31 < jrandom> romster: the new tunnels do not talk to each other, no, but thats not the attack Michael has been describing</p>
-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</p>
-17:31 <+fox> <Romster> must read the list, ok i'll leave it at that for now, anyone else got anything to say?</p>
-17:32 < jrandom> ok, if there's nothing else, lets move on to 6) virus investigations</p>
-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</p>
-17:33 < jrandom> I don't have anything to add beyond whats been discussed on the forum</p>
-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</p>
-17:33 <+fox> <Romster> virus, what virus, if it's linux it'll be nonexistant, but windows hmmm</p>
-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.</p>
-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 ;)</p>
-17:35 <+Complication> I sure couldn't find anything obvious in there, but nor could I explain away all the difference.</p>
-17:35 <@cervantes> rtfml and rtff</p>
-17:35 <+fox> <Romster> yeah i haven't been upto speed for quite awhile, sorry about taht jrandom</p>
-17:35 <@cervantes> ;-)</p>
-17:35 < jrandom> aye, the fact that both a known safe bat file and the old one triggered the same detection code is substantial</p>
-17:35 <+Complication> Yes, that sort of eases doubts.</p>
-17:36 <+Complication> I guess the QBFC might have undocumented differences within the same version number (different builds?)</p>
-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</p>
-17:37 <+Complication> I think it's better that way.</p>
-17:37 <+Complication> Disassembly is really notably outside my usual playground.</p>
-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?</p>
-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</p>
-17:38 < jrandom> aye, its much appreciated</p>
-17:38 <+legion> I've nothing to add, I feel that I've said way too much about it already</p>
-17:39 < jrandom> 'k understood.  ok, anyone else have anything to bring up on this, or shall we move on to 7) ???</p>
-17:39 < jrandom> [consider us moved]</p>
-17:40 <+fox> * Romster seconds that :)</p>
-17:40 <+legion> ok for 7)??? how about we take a moment to discuss i2phex</p>
-17:40 < jrandom> cool, good idea</p>
-17:40 <+fox> <Romster> since i'm using it right now even :)</p>
-17:40 <@cervantes> no no group hug first</p>
-17:40 < jrandom> redzara mentioned he was going to be at the meeting, but progress on the merge is going slow</p>
-17:41 <+legion> susi23 inquired about a headless version</p>
-17:41 < jrandom> ah cool, i saw your post on that</p>
-17:41 <+fox> <Romster> might i add the favourites list needs to be wider to cope with the longer i2p keys</p>
-17:42 <+susi23> (that's no must, I was just curious about it)</p>
-17:42 < jrandom> well, no one can remember base64 keys, so I'm not sure if you're missing much Romster ;)</p>
-17:42 < jrandom> (and the first few bytes should be enough to uniquely identify them)</p>
-17:42 <+fox> <Romster> starting i2phex with a server is the major problem i see so far</p>
-17:42 <+legion> Actually I'd like to see only like the first 12 characters of keys to displayed in the client</p>
-17:42 <+fox> <Romster> heh guess</p>
-17:42  * Complication is regrettably majorly busy, and can't do no xml-rpc</p>
-17:43 < jrandom> seems reasonable legion </p>
-17:43 <+fox> <Romster> what about display as many characters to make the key unique</p>
-17:43 < jnymo_> I'm having good results with i2phex</p>
-17:44 < jrandom> cool jnymo_, i've been hearing good things too</p>
-17:44 <+fox> <Romster> so if 2 keys start with abc it'll be abcx</p>
-17:44 < jnymo_> 12 identical characters isn't likely, romster</p>
-17:44 <+fox> <Romster> true</p>
-17:44 <+Complication> Besides, simpler = quicker</p>
-17:44 <+fox> <Romster> but wouldnt need 12 if the keys are that far randomised</p>
-17:45 <+Complication> (not that there is much speed to gain from displaying things)</p>
-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</p>
-17:45 <+susi23> (netdb works great with 4 chars only for router ids)</p>
-17:45 <+fox> <Romster> or the database and using the keyname=base64 and only displaying the keyname</p>
-17:45 < jrandom> hmm, i thought there was already a peer info display legion?</p>
-17:46 < jrandom> legion: some things like that would be good to add to the mainline phex, most likely?</p>
-17:46 <+legion> hmm could be right...</p>
-17:46 < jrandom> (that way Gregor can maintain it ;)</p>
-17:46 <+Complication> Well, there's a "Browse host" function, but that may not be the exact same thing. (If it works.)</p>
-17:46 < jrandom> Complication: it does</p>
-17:46 < jrandom> (work, that is)</p>
-17:47 <+Complication> Seems to basically drop the host destkey into the search box</p>
-17:47 <+Complication> ...and runs a search.</p>
-17:48 < jnymo_> this may be an i2phex mainline issue, but I didn't see an ETA on i2phex downloads</p>
-17:48 <+Complication> Hmm... or actually, doesn't run a search.</p>
-17:48 <+Complication> Mine seems to wait until I manually start it.</p>
-17:48 <+fox> <Romster> whats the nearby i2phex running tickbox for?</p>
-17:49 <+legion> I see where there is plenty of room for improvement. ;)</p>
-17:49 < jrandom> yep :)</p>
-17:50 < jrandom> lots to be done, and the forum is a good place to post up ideas/suggestions/questions(/patches :)</p>
-17:50 <+fox> <Romster> despite it's ovous name</p>
-17:50 < jrandom> ok, anyone have anything else for the meeting?</p>
-17:50 <+fox> <Romster> hmm good point</p>
-17:50 <+fox> <Romster> can't think of anything else</p>
-17:51 <+fox> <Romster> but anyone working on a distributed data store?</p>
-17:51  * cervantes checks his watch</p>
-17:51 <+fox> <Romster> like activtely</p>
-17:51 < jrandom> Romster: beyond syndie, no</p>
-17:51 < jrandom> (not to my knowledge, at least)</p>
-17:52 <+legion> well I was wondering about integrating a http download manager into i2p, would make downloading larger content from eepsites easier.</p>
-17:52 <+fox> <Romster> q and iphex and one or 2 others but i've not seen anything mentained for awhile now</p>
-17:52 <@cervantes> what's the status of feedspace...I haven't heard aught of it in a while</p>
-17:52 < jrandom> legion: that would be cool - there's a post about that on the forum too i think</p>
-17:53 <+fox> <Romster> ah feedspace another one</p>
-17:53 < jnymo_> if this was mentioned in the meeting already, nm.. but, is there news on i2p freenet colab?</p>
-17:53 < jrandom> cervantes: last i heard frosk was kind of busy, but if frosk is around, maybe he can tell us more :)</p>
-17:53 <+legion> Personally I'd like to see a i2p entropy colab.</p>
-17:54 <+fox> <Romster> i have ideas for a datastore, but it be a expansion to existing methods that are in use currently</p>
-17:54 <+legion> Given that q, feedspace and such don't seem to be going anywhere fast right now</p>
-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)</p>
-17:54 <+fox> <Romster> i want to start a project but not go over what others have done already</p>
-17:54 <+legion> wonder if it'd be possible to port entropy to run over i2p...</p>
-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</p>
-17:55  * jrandom doesnt know entropy's transport code at all</p>
-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 :)</p>
-17:55 < jrandom> (but perhaps that'd be a good way to get someone to hack on the GCJ SDK :)</p>
-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 :)</p>
-17:56 < jnymo_> ah.. congrats on the gcj port</p>
-17:56 <+fox> <Romster> entropy's is in c or C++ iirc</p>
-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</p>
-17:57 <+fox> <Romster> jrandom true, but who :)</p>
-17:57 < jrandom> not I</p>
-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.</p>
-17:57 < jrandom> (the only way to get something you care about done is for *you* to do it :)</p>
-17:57 < jrandom> cool</p>
-17:57  * dust would like to see some kind of 'squid' syndication for offloading eepsites</p>
-17:58 < jrandom> dust: yeah totally, if we can get sucker into that position, that'd be ideal</p>
-17:58 < jrandom> e.g. I'd love to get the latest info from orion in syndie, local</p>
-17:58 <+fox> <Romster> build a proxy for squid to use :)</p>
-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.</p>
-17:59 < dust> ah, syndie</p>
-17:59 < jrandom> (thats actually what syndie is for - syndication to cut down on load)</p>
-17:59 < dust> _the_ answer</p>
-17:59 < jrandom> there's a python eepsite checker?</p>
-17:59 <+fox> <Romster> first i've heard about it</p>
-17:59 <+legion> yeah, it's what I use ;)</p>
-18:00 < jrandom> cool legion </p>
-18:00 <+legion> really? It's been around for awhile</p>
-18:00 <+fox> <Romster> nice i'd like to check that out :)</p>
-18:00 <@cervantes> think someone ported baffled's script... can't remember who/when</p>
-18:00 <+fox> <Romster> i'm learning python</p>
-18:00 < jrandom> ah ok cervantes </p>
-18:00 <+fox> <Romster> the hard way by examples and the manual :)</p>
-18:00 < jrandom> yeah, i'm lazy, i just use polecat.i2p/i2psurvey/ and orion.i2p/ :)</p>
-18:01 < jrandom> (no need for me to spider)</p>
-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</p>
-18:01 <+fox> <Romster> i have 2.4 installed here</p>
-18:01 <+Ragnarok> I may have a look at it.  Got link?</p>
-18:01 <+fox> <Romster> actually think it's 2.4.1</p>
-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.</p>
-18:02  * jnymo_ would love to see an orion.i2p/I2PDirectory hybrid.. info, catagories, stats.. butter</p>
-18:02 <+legion> I'll archive it after the meeting and post a link to the forums</p>
-18:03 <+Ragnarok> ok</p>
-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</p>
-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</p>
-18:03 < jrandom> (not that there's anything wrong with making it easy for those few people, that is :)</p>
-18:04 <+fox> <Romster> cold be disected and used todo other things too?</p>
-18:04 <+legion> Well thing is I can see where there could be some uses for everyone that runs i2p.</p>
-18:04 <+fox> <Romster> could*</p>
-18:04 < jrandom> hmm, I'm not so sure, could you explain how?</p>
-18:04 < jrandom> I mean, I don't want everyone to essentially DDoS every eepsite</p>
-18:05 <+legion> One of which would be a dynamic bookmarks page, that is auto generated every 12-24 hours or so.</p>
-18:05 < jrandom> ah, that is trivial in syndie (actually one of the main features - 'new blogs')</p>
-18:05 < jrandom> ((but of course, syndie doesn't have a great ui for that yet))</p>
-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</p>
-18:06 < jrandom> right Romster (though that torrent/dht-like database to sync, or "syndi"cate, could be syndie ;)</p>
-18:06 <+fox> <Romster> could even be a hidden way to learn more i2p nodes and services</p>
-18:07 <+fox> <Romster> yeah or syndie</p>
-18:07 < jrandom> ok, anyone else have anything for the meeting?  the curry is getting cold ;)</p>
-18:08 <+fox> <Romster> if syndie is going tobe that great one could store static pages to cashe and the same with images</p>
-18:08 <+fox> <reliver> bon appetit, jrandom :-)</p>
-18:08 < jrandom> exactly romster, you can do that now </p>
-18:09 < jrandom> ok, if there's nothing else...</p>
-18:09  * jrandom winds up</p>
-18:09  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/153.rst b/i2p2www/meetings/153.rst
new file mode 100644
index 00000000..b2b775a5
--- /dev/null
+++ b/i2p2www/meetings/153.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 25, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/154.log b/i2p2www/meetings/154.log
index 7bb1bd52..ebeef12c 100644
--- a/i2p2www/meetings/154.log
+++ b/i2p2www/meetings/154.log
@@ -1,182 +1,176 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 154{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 1, 2005</h3>
-<div class="irclog">
-15:04 < jrandom> 0) hi</p>
-15:04 < jrandom> 1) 0.6.1.4 and net status</p>
-15:04 < jrandom> 2) boostraps, predecessors, global passive adversaries, and CBR</p>
-15:05 < jrandom> 3) i2phex 0.1.1.34</p>
-15:05 < jrandom> 4) voi2p app</p>
-15:05 < jrandom> 5) syndie and sucker</p>
-15:05 < jrandom> 6) ???</p>
-15:05 < jrandom> 0) hi</p>
-15:05  * jrandom waves</p>
-15:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001186.html</p>
-15:05 < jrandom> (lets see if this cat will let me use both hands to type...)</p>
-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 ;)</p>
-15:07 < jrandom> anyway, jumping into 1) 0.6.1.4 and net status</p>
-15:08 < jrandom> I don't have much to add beyond whats in the status notes</p>
-15:08  * cervantes is waiting till the correct time to say hi</p>
-15:08 < jrandom> heh</p>
-15:09 < jrandom> you've got 19 seconds, acording to timeanddate.com :)</p>
-15:09 <@cervantes> hi</p>
-15:09 < jrandom> ;)  ok, anyway, anyone have any comments/concerns on 0.6.1.4?  from what i can see, its gone prety well</p>
-15:10 <+Complication> Counted 747.6 routers today :P</p>
-15:10 < jrandom> yeah, we've had a higher churn than usual lately</p>
-15:10 < jrandom> still getting a bunch of referrers in from that digg / gotroot article</p>
-15:10 <+Complication> And one trick to "knowing" more peers is simply restarting less often :)</p>
-15:10 < jrandom> heh true enough</p>
-15:10 <@cervantes> *cough*sourceforge*cough*</p>
-15:11 <+polecat> I've had some trouble with number of participating tunnels dropping abruptly now and again.  Might be that darn NAT thing.</p>
-15:11  * jrandom cringes.  have you had many referrers from sf cervantes?</p>
-15:11 <+Complication> cervantes: you mean *that* SourceForge page? :eek:</p>
-15:11  * cervantes doesn't log referrers</p>
-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 </p>
-15:11 < jrandom> ah ok cervantes </p>
-15:12 <+polecat> Really?  I thought lots of participating tunnels was good.</p>
-15:12 <+Complication> polecat: mine used to drop them rapidly when it exceeded practically usable bandwidth</p>
-15:12 <@cervantes> I make a point of only logging the minimum required to debug forum issues ;-)</p>
-15:12 <@cervantes> since folk seem touchy on the subject</p>
-15:12 <@cervantes> I've noticed...</p>
-15:13 < jrandom> polecat: sure, but the # should drop if your machine gets loaded or otherwise acts funky</p>
-15:13 < jrandom> reasonable enough cervantes </p>
-15:13  * jrandom logs everyone's mother's maiden name, to remind people not to trust anyone ;)</p>
-15:14 < jrandom> (or do I?  you'll never know ;)</p>
-15:15 < jrandom> polecat: is your nat just randomly restarting, or losing its ip address, or something else?</p>
-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</p>
-15:16 < jrandom> its how i found the got-root and digg articles :)</p>
-15:16 < dust> i've noticed better network throughput lately, or it it just me imagining things again?</p>
-15:17 < jrandom> it should be better, especially for short lived connections (e.g. http responses)</p>
-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</p>
-15:18 < dust> e.g. i2phex pretty much takes any limit i give it if i give it enough parallel transfers</p>
-15:18 < jrandom> nice</p>
-15:20 < dust> per-tunnel seems limited <~10k/s</p>
-15:20 < dust> or per-transfer</p>
-15:20 <+polecat> Okay, my machine does get loaded now and again.</p>
-15:21 <@cervantes> have any of the folk on bandwidth restricted connections noticed improvement?</p>
-15:22 < jrandom> hmm right, 10KBps per stream seems ballpark to what i'm seeing as well</p>
-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 :)</p>
-15:23 < jrandom> ok, if there's nothing else on 1), lets move on to 2) boostraps, predecessors, global passive adversaries, and CBR</p>
-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!)</p>
-15:24 < defnax> did anywere looked eepsites.i2p?</p>
-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?</p>
-15:24 <@cervantes> I think you've successfully generated full tunnel CBR by maintaining a constant level of i2plist mails</p>
-15:24 < jrandom> heh cervantes </p>
-15:24 < jrandom> defnax: yeah, it looks neat, a nice database growing there</p>
-15:25 < jrandom> same with tino.i2p</p>
-15:25 < defnax> but i dont like it</p>
-15:25 <+polecat> Hey, I'm on a bandwidth restricted connection!  i2p gets 10K/s up and 32K/s down.  :)</p>
-15:26 < defnax> www.eepsites.com then can all normal users on internet search for i2p sites</p>
-15:26 < defnax> and mpaa or riaa can browse what sites avaible and </p>
-15:26 < jrandom> so?</p>
-15:26 < jrandom> mpaa/riaa/etc can just run i2p if they want to see whats on i2p</p>
-15:26 < jrandom> w3wt polecat </p>
-15:27 < jrandom> (jesus, some sick search queries @ eepsites.com...)</p>
-15:27 < defnax> thats not good for anonnymity</p>
-15:27 < defnax> then all users now where can find torrents on I2P eepsites</p>
-15:27 < jrandom> defnax: same with tino.i2p</p>
-15:27 <@cervantes> I like the faux google ads on eepsites.i2p.... but anyway, digression</p>
-15:27 < jrandom> defnax: thats not good for /secrecy/.  thats different from anonymity.</p>
-15:27 < jrandom> people hosting public eepsites should expect that anyone can view their eepsites</p>
-15:28 < jrandom> if they want to restrict who can access it, they should do so</p>
-15:28 < jrandom> yeah definitely cervantes :)</p>
-15:28 <+polecat> Anyone who wants a private eepsite, just don't give it a name in hosts.txt.  Problem solved!</p>
-15:28 < defnax> but normal internet users must dont know which eepsites is avaible!</p>
-15:28 < jrandom> polecat: thats not entirely sufficient</p>
-15:29 <+polecat> Really?</p>
-15:29 < jrandom> i'm sorry, perhaps I misunderstand defnax.  why shouldn't people know what eepsites are available?</p>
-15:29 < defnax> i know it then not listend in a search enigine when dont make eespite public</p>
-15:29 <+polecat> I thought it was a brute force sweep through the base64 keyspace to find eepsites...</p>
-15:29 < jrandom> polecat: right, someone can harvest the netDb</p>
-15:29 < defnax> i think this person dont need I2P</p>
-15:29 < jrandom> well, harvesting for leaseSets is substantially more work than harvesting for routers...</p>
-15:30 < jrandom> defnax: I'm sorry, I don't understand</p>
-15:30 < jrandom> eepsites.com is a public interface to a search engine across public eepsites.  nothing private is being revealed</p>
-15:30 <@cervantes> lol @ last 5 searches</p>
-15:30 <+Complication> Yep, the "last searches" box suggests someone (ironically someone who is probably non-anonymous) is a tiny bit sick.</p>
-15:30 <+Complication> Ah, whatever.</p>
-15:30 < defnax> i mean he dont need I2P ! he tells on public IP on which eespites are torrents or other things avaible!</p>
-15:31 < defnax> on I2P is ok , but not on normal internet</p>
-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.</p>
-15:31 < jrandom> but, on the other hand, same goes for forum.i2p.  </p>
-15:31 < jrandom> (and to some extent, www.i2p, though that doesn't give you /my/ info ;)</p>
-15:32 < jrandom> some sites are public.  thats fine.  thats neat.  </p>
-15:32 <+fox> <jme___> defnax, what attacks is possible thanks to this site, which isnt without this site ?</p>
-15:32 <@cervantes> Complication: snigger</p>
-15:32 < jrandom> they're offering a potentially useful service to people who may want to try out i2p before installing</p>
-15:33 < defnax> ok any news from I2Psnark? </p>
-15:33 <+Complication> cervantes: yeah, nothing like good old irony :)</p>
-15:33 < defnax> i will become before 0.6.2 a webinterface/gui?</p>
-15:33 <@cervantes> defnax: there's been an i2p inproxy for several months</p>
-15:33 < jrandom> defnax: nope, but I suppose we should jump forward in the agenda before we hit 6) ???</p>
-15:33 < jrandom> ok, is there anything else on 2) boostraps, predecessors, global passive adversaries, and CBR?</p>
-15:34 < jrandom> or shall we move on to 3) I2Phex 0.1.1.34</p>
-15:34 < jrandom> [consider us moved]</p>
-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</p>
-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</p>
-15:36 < jrandom> redzara: any word on the merge?</p>
-15:37 <+Complication> The post .34 cvs improvements seem to make the GUI *much* more responsive.</p>
-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 :)</p>
-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</p>
-15:43 < jrandom> ah cool!</p>
-15:43 < jrandom> no rush, just wondering</p>
-15:44 <+redzara> and maybe I've to get lastest I??phex code to see if GregorK's mod apply to lastest phex code ?!?</p>
-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).</p>
-15:45 < jrandom> same for the latest synchronization issue (remove unnecessary locks on network operations)</p>
-15:46 <+fox> <jme___> I??phex <- interesting how typo can reveal location too :)</p>
-15:46 < jrandom> not as much as "in France" does ;)</p>
-15:46 <+redzara> this is already done in my code</p>
-15:46 <@cervantes> hehe</p>
-15:46 < jrandom> (but thats another bug thats not yet fixed... the irc charset stuff)</p>
-15:46 < jrandom> ok cool redzara </p>
-15:47 <+redzara> jme___ : I don't search to hide my location, you konw :-)</p>
-15:47 <+redzara> so nothing more to say about i2phex for me</p>
-15:47 <+fox> <jme___> redzara, ok :) </p>
-15:48 < jrandom> ok great, thanks for the update</p>
-15:48 < jrandom> anyone else have anything on i2phex, or shall we move on to 4) voi2p app?</p>
-15:49 <+redzara> consider we are moving :)</p>
-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</p>
-15:49 < jrandom> (unless someone else has something to discuss for 4)?)</p>
-15:50 < jrandom> if not, consider us moved to 5) syndie and sucker</p>
-15:50 < jrandom> dust: wanna give us the word?</p>
-15:51 <@cervantes> so is syndie good at sucking now?</p>
-15:51 < jrandom> yes *cough*</p>
-15:51 < dust> heh</p>
-15:52 < dust> well, the note says pretty much it</p>
-15:52 < dust> there are still stuff to do</p>
-15:53 < dust> word on the testing and reporting of bugs</p>
-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?</p>
-15:55 <+fox> <brutus> oi, how about the auto ping-pongin' ircProxy, any progrssthat?</p>
-15:55 < jrandom> no progress i know of</p>
-15:55 <+fox> <brutus> (ups, sry)</p>
-15:55 <+polecat> voi2p, make a mp3 of your voice and i2p bittorrent it.</p>
-15:56 < dust> no, dunno the eta on next rome</p>
-15:56 < dust> i couldn't get to the cvs</p>
-15:57 < dust> (i don't remember why)</p>
-15:57 < jrandom> ah 'k, well, we don't need it yet, it'd just be neat.  a later date then</p>
-15:58 < jrandom> ok, anyone have anyhing else on 5)? or shall we move on to 6) ???</p>
-15:59 < jrandom> [consider us moved]</p>
-15:59 <@cervantes> brutus: I don't beleive anything has been done concerning that</p>
-16:00 < dust> should it be done?</p>
-16:01 <+fox> <brutus> oki, yeah, i guess it's pretty low priority as well</p>
-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.</p>
-16:01 < jrandom> polecat: by getting someone with a dialup connection to help test ;)</p>
-16:01 <@cervantes> free rifle with every installation?</p>
-16:02 < jrandom> polecat: we're definitely working on that, but we have so, so much more to do first.</p>
-16:02 < jrandom> dust: the irc thing?  might be worthwhile, but sucker improvements are probably more important</p>
-16:02 < jrandom> (imho)</p>
-16:03 <@cervantes> (somewhat biases opinion ;-)</p>
-16:03 <@cervantes> *biased</p>
-16:03 < jrandom> true that, but i think my bias is Right :)</p>
-16:04  * cervantes notes the capital lettering ;-)</p>
-16:05  * Complication looks at the phone socket, and wonders if anything good can come of such <things> :D</p>
-16:05 <+Complication> Then again, if DSL travels over it, it cannot be inherently evil. :D</p>
-16:05 <+polecat> No... not Things!</p>
-16:05 <@cervantes> Complication: you can also use it to call people....</p>
-16:06 < jrandom> ok, anyone have anything else for 6) ???</p>
-16:07  * cervantes wasn't sure we had anything for ??? in the first place</p>
-16:07 < jrandom> in that case... </p>
-16:07  * jrandom winds up</p>
-16:08  * jrandom *bafs* the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/154.rst b/i2p2www/meetings/154.rst
new file mode 100644
index 00000000..72164e5f
--- /dev/null
+++ b/i2p2www/meetings/154.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 1, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/155.log b/i2p2www/meetings/155.log
index 15954237..16227451 100644
--- a/i2p2www/meetings/155.log
+++ b/i2p2www/meetings/155.log
@@ -1,66 +1,60 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 155{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 8, 2005</h3>
-<div class="irclog">
-15:21 < jrandom> 0) hi</p>
-15:21 < jrandom> 1) Net status / short term roadmap</p>
-15:21 < jrandom> 2) I2Phex</p>
-15:21 < jrandom> 3) I2P-Rufus</p>
-15:21 < jrandom> 4) I2PSnarkGUI</p>
-15:21 < jrandom> 5) Syndie</p>
-15:22 < jrandom> 6) ???</p>
-15:22 < jrandom> 0) hi</p>
-15:22  * jrandom waves</p>
-15:22 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2005-November/001206.html</p>
-15:22  * bar mumbles greetings from behind his/her false(?) beard</p>
-15:23 < jrandom> ok, jumping into 1) Net status / short term roadmap</p>
-15:23 < jrandom> Not much to say beyond whats in the mail - hopefully a new release later this week, or this weekend</p>
-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</p>
-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</p>
-15:26 < jrandom> right now, however, that isn't our choke point, so there's still work to be done.</p>
-15:26 < jrandom> I don't have much more to add on that front - anyone have any questions/comments/concerns?</p>
-15:28 < jrandom> ok, if not, moving on to 2) I2Phex</p>
-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 </p>
-15:31 < jrandom> ok, if not, jumping on over to 3) I2P-Rufus</p>
-15:31 < jrandom> this bullet point was really just me repeating a rumor, but we'll see how things go</p>
-15:32 < jrandom> Rawn / defnax: do you have anything to add?</p>
-15:35 < tealc_> whats i2p-rufus ?</p>
-15:35 < jrandom> a port of the rufus bittorrent client for I2P (http://rufus.sourceforge.net/)</p>
-15:36 < jrandom> ok, if there's nothing else, we can jump to another quick rumor reportage - 4) I2PSnarkGUI</p>
-15:37 < jrandom> I don't have much to add to this beyond saying "hey, cool" :)</p>
-15:38 <+bar> yeah, looks nice</p>
-15:38 <@frosk> snark is Y.A. BT client?</p>
-15:38 < jrandom> yeah, but snark is a bittorrent client bundled with I2P :)</p>
-15:38 <@frosk> oh yeah, right :)</p>
-15:38 < jrandom> (currently a command line tool, but multitorrent and web interface is on the way, though not imminent)</p>
-15:39 <+fox> <ZipTie> who was doing the work for the rarest-first fetching strategy for snark? did that ever get done?</p>
-15:39 < jrandom> yeah, Ragnarok implemented that</p>
-15:39 < jrandom> its in the current I2PSnark</p>
-15:39 <+fox> <ZipTie> cool</p>
-15:40 < jrandom> aye, quite</p>
-15:41 <+fox> <ZipTie> is i2p-bt going to be decomissioned then in favor of either rufus or snark?</p>
-15:41 < jrandom> thats for users to decide</p>
-15:42 <+fox> <ZipTie> or maintainability :)</p>
-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</p>
-15:43 < jrandom> but really, what you mention is the key - who does the maintenance and development is the driving force</p>
-15:43  * jrandom does not maintain python apps</p>
-15:44 < jrandom> ok, if there's nothing else on 4, lets move on to 5) Syndie</p>
-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</p>
-15:46 < tealc_> ahh, i thought i2phex was java.. the stuff on the forums offers .exe installers and .exe's in zips</p>
-15:47 < jrandom> i2phex is java</p>
-15:47 < jrandom> and the .exe works with any platform that java works on</p>
-15:47 < jrandom> java -jar i2phex.exe</p>
-15:47 < jrandom> (yes, really)</p>
-15:49 < jrandom> (cough)</p>
-15:49 < jrandom> dust: anything to add re: syndie stuff?</p>
-15:50 < dust> nope</p>
-15:50 < jrandom> ok cool.  unless anyone else has anything on it, lets jump to ol' faithful: 6) ???</p>
-15:50 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-15:53 <+fox> <reliver> is the paella ready ? ;-)</p>
-15:53  * jrandom grabs a spork</p>
-15:54 < jrandom> (on that note...)</p>
-15:54 <+fox> <reliver> and the cat still smells like cats ;?)</p>
-15:54  * jrandom windos up</p>
-15:54  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/155.rst b/i2p2www/meetings/155.rst
new file mode 100644
index 00000000..7ebbfa62
--- /dev/null
+++ b/i2p2www/meetings/155.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 8, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/156.log b/i2p2www/meetings/156.log
index de250272..4bb8fa3d 100644
--- a/i2p2www/meetings/156.log
+++ b/i2p2www/meetings/156.log
@@ -1,351 +1,345 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 156{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 15, 2005</h3>
-<div class="irclog">
-15:15 < jrandom> 0) hi</p>
-15:15 < jrandom> 1) Net status / 0.6.1.5</p>
-15:15 < jrandom> 2) Syndie updates</p>
-15:15 < jrandom> 3) I2Phex</p>
-15:15 < jrandom> 4) I2P-Rufus</p>
-15:15 < jrandom> 5) Issue tracker</p>
-15:15 < jrandom> 6) Dynamic Keys</p>
-15:15 < jrandom> 7) ???</p>
-15:15 < jrandom> 0) hi</p>
-15:15  * jrandom waves</p>
-15:16 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-November/001210.html</p>
-15:17 <+bar> yalla! *fires some rounds into the air*</p>
-15:17  * jrandom ducks and covers, diving into 1) Net status / 0.6.1.5</p>
-15:18 < jrandom> as mentioned in the mail, there's been a lot of progress, and there should be a new release later tonight</p>
-15:18  * jrandom would have released it earlier, but I slept late and didn't want everyone upgrading /during/ the meeting :)</p>
-15:20 < jrandom> anyone have any questions/comments/concerns re: 1) net status / 0.6.1.5?</p>
-15:20 <+fox> <ailouros> is "please keep up the good work" an acceptable comment?</p>
-15:20 < jrandom> :) thanks</p>
-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</p>
-15:22 < tethra> i second ailouros's comment, and furthermore, propose a toast:</p>
-15:22 < jrandom> we've also had some more positive reports from users on dialup connections</p>
-15:22 < tethra> to jrandom, and i2p! woot!</p>
-15:22 < tethra> <3</p>
-15:23 < jrandom> w3wt.  ok, if there's nothing else, lets jump on over to 2) Syndie updates</p>
-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</p>
-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 :)</p>
-15:25 <+fox> <ailouros> oh come on, first you don't release it, then you say "try it first"... this is just teasing! :D</p>
-15:25 < jrandom> :)</p>
-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 ;)</p>
-15:27 < jrandom> there's going to be an announcement for I2Phex 0.1.1.36 later tonight</p>
-15:28 < jrandom> the only change is the fix for the annoying "Please insert a disk" popup</p>
-15:28 < tethra> that means i can take the disk out the drive without it screaming at me, then? ;)</p>
-15:28 < jrandom> heh yes</p>
-15:28 < tethra> :D</p>
-15:30 < jrandom> ok, if there's nothing more on 3) I2Phex, lets jump on over to 4) I2P-Rufus</p>
-15:30 < tethra> what are the plans for i2phex, while we're on the subject?</p>
-15:30 < jrandom> ah</p>
-15:30 < jrandom> there's a set of feature requests posted to the forum</p>
-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</p>
-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</p>
-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</p>
-15:33 < tethra> cool.</p>
-15:33 <+fox> <reliver> _007pig perhaps ?</p>
-15:33 <+fox> <ailouros> sorry if I ask, but wasn't gnutella network the one that flooded itself to death some time ago?</p>
-15:33 < tethra> the new guys do tend to be a bit confused about it at first</p>
-15:33 <+fox> <reliver> you did not take him up on his offer for help, yesterday, jrandom</p>
-15:33 < jrandom> _007pig was looking into translation work, but anyone would be great.  Phex itself has gwebcache support, but sirup disabled it</p>
-15:34 < jrandom> ailouros: gnutella is still around, but yeah, its not ideal.</p>
-15:34 < tethra> is anyone looking into perhaps changing the protocol i2phex uses to something else?</p>
-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</p>
-15:35 < jrandom> tethra: no one that I know of</p>
-15:35 <+fox> <ailouros> well, I think I'd rather see Localhost (azureus modification) on i2p then</p>
-15:36 < tethra> surely bittorrent is more awkward than gnutella?</p>
-15:36 < tethra> in terms of seeding and such</p>
-15:36 < jrandom> ailouros: whatever people implement and maintain is good :)</p>
-15:36 <+fox> <ailouros> I don't know, I didn't use gnutella since... 6 years I think</p>
-15:37 < anti> surely it is more efficient and better test of true scalability?</p>
-15:37 <+fox> <ailouros> jrandom yeah that's a good metric :D</p>
-15:37 < jrandom> i2phex works pretty well, I've transferred lots of data through it, and found some neat content</p>
-15:37 <@cervantes> (pony pr0n)</p>
-15:37 <+fox> <ailouros> lol</p>
-15:37 < tethra> hahah</p>
-15:37 < jrandom> there may be better ways to do things, but something that works is better than something that doesn't exist</p>
-15:37 < tethra> cervantes++</p>
-15:37 < tethra> ;)</p>
-15:38 < tethra> truer words have never been spoken.</p>
-15:39 < anti> good point</p>
-15:39 <@cervantes> uhoh... jr has taken offense and gone early to dinner</p>
-15:39 <@cervantes> (sorry)</p>
-15:39 < anti> no, he's probably searching for that (mythical) pony pr0n. ;)</p>
-15:40 < jrandom> *cough* ;)</p>
-15:40 < tethra> lol </p>
-15:40 < tethra> heheh ;)</p>
-15:40 < jrandom> ok, if there's nothing else on 3), lets move on to 4) I2P-Rufus</p>
-15:40 <+fox> <reliver> i want flying pony pr0n :-)</p>
-15:40 < jrandom> Rawn / defnax: anything to add to what was posted on the forum?</p>
-15:41 <@cervantes> looks like some good progress is being made</p>
-15:41 < jrandom> aye</p>
-15:45 < jrandom> ok, if there's nothing on that, lets jump on to 5) issue tracker</p>
-15:45 < jrandom> the forum is a bit heavyweight for managing bugs and feature requests, and bugzilla is a bit of a beast... </p>
-15:46 <@frosk> isn't there a bugzilla already somewhere?</p>
-15:46 < jrandom> i've posted up some general requirements, and cervantes has come up with one workable solution</p>
-15:46 < jrandom> nah, the bugzilla was on the old host (@johnscompanies) before we migrated to sago</p>
-15:46 <+fox> <ailouros> hot about NNTP? better than forums, usually threaded...</p>
-15:46 <+fox> <reliver> strange that bugzilla is so lacking, considering the huge open source community using it ...</p>
-15:46 <+fox> <ailouros> how*</p>
-15:46 <@frosk> ah ok</p>
-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&</p>
-15:48 < jrandom> but nntp does have the benefits of having decades of battle testing</p>
-15:48 <+fox> <ailouros> NNTP reader filter by keyword (the [] tags)? :D</p>
-15:49 <@modulus> perhaps not so much testing of late?</p>
-15:49 <+fox> <reliver> including spamming and flaming ...</p>
-15:49 < jrandom> we'd want something web accessible though, since most people don't use nntp readers</p>
-15:49 <+fox> <ailouros> I say Thunderbird is good in that sense, and you can share the enigmail between i2mail and i2nntp</p>
-15:49 <@modulus> maybe a web accessible nntp reader?</p>
-15:49 <+fox> <reliver> gateways are common</p>
-15:49 < jrandom> hmm modulus?</p>
-15:50 <@modulus> well, usenet is not so much used anymore i think</p>
-15:50 < jrandom> right, so we'd have to have an nntp server and a gateway with filtering support</p>
-15:50 <@frosk> i like cervantes' idea though</p>
-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)</p>
-15:50 <@modulus> hmm, gateway with filtering support? what are you guys talking about, maybe it helps knowing. :-)</p>
-15:51 <@modulus> imo forums suck, i hate fucking forums, they're unusable ;-(</p>
-15:51 <+fox> <ailouros> LOL I guess he wants the access from the InterNEt</p>
-15:51 <+fox> * ailouros agrees with modulus</p>
-15:51 <@frosk> modulus: so very true</p>
-15:51 < jrandom> heh modulus ;)  we're discussing http://syndiemedia.i2p.net:8000/threads.jsp?visible=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003&</p>
-15:51 <+fox> <ailouros> aieee the megabyte long URI</p>
-15:52 <@modulus> what I love about syndie URLs is how memorable and simple they are to type</p>
-15:52 < jrandom> I do still like http://syndiemedia.i2p.net:8000/threads.jsp?post=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800004&</p>
-15:52 < jrandom> heh</p>
-15:52 < jrandom> well, go to http://syndiemedia.i2p.net/threads.jsp then and click on the "Issue tracking software" link :)</p>
-15:53 <@frosk> bug reporting right from your router console</p>
-15:53 <@modulus> hmm, bug tracking.</p>
-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 :)</p>
-15:54 <+fox> <reliver> sounds great :-)</p>
-15:54 <+fox> <ailouros> it is</p>
-15:54 < jrandom> aye that is a really good feature frosk... we could even have specialized html forms to post to /syndie/post.jsp</p>
-15:54 <+fox> <ailouros> and by the way, wasn't there talk about basing syndie on NNTP? :D :D :D</p>
-15:54 <@modulus> hmm, how about the Debian bug tools? they're nice i think, the mailbug</p>
-15:54 < anti-> can't argue with what already works!</p>
-15:55 <@cervantes> I think you should do it purely from a techdemo perspective</p>
-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</p>
-15:56 <@cervantes> no better way to demonstrate syndie than with some real world use cases</p>
-15:56 < jrandom> true enough</p>
-15:56 < jrandom> ok, perhaps we can plan on getting that out in the 0.6.1.6 release</p>
-15:56 <+fox> <reliver> what i don't like about forum is they are low entry cost</p>
-15:57 <+fox> <reliver> so lots of distractions filling them.</p>
-15:57 <@modulus> i don't know, this syndie thing ... i much do not like yet, but maybe i'll get used to it.</p>
-15:57 <+fox> <reliver> and you can only work with them online</p>
-15:57 < jrandom> modulus: have you read the post linked to from http://syndiemedia.i2p.net/about.html ?</p>
-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.</p>
-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</p>
-15:57 < jrandom> agreed modulus</p>
-15:58 <+fox> <ailouros> oh yeah and you have to be online indeed</p>
-15:58 < jrandom> heh ailouros, thats something we need to deal with in Syndie anyway :)</p>
-15:58 <@modulus> hmm, probably not, jr, let me check</p>
-15:58 <+fox> <ailouros> well, with syndie you can blacklist the users and you're pretty much set</p>
-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 :)</p>
-15:58 < jrandom> exactly ailouros, with one click in the new release too</p>
-15:59 <+fox> <ailouros> with forums either you hope for an admin to come and kill'em, or you keep them</p>
-15:59 < anti-> it's more uucp than nntp :)</p>
-15:59 <@modulus> hmm, which post in particular linked from there?</p>
-15:59 < jrandom> lol *exactly* anti</p>
-15:59 < jrandom> modulus: the first link "in syndie itself"</p>
-15:59  * cervantes likes the killing option</p>
-16:00 <@modulus> bah, uucp == nntp for all practical purposes :-)</p>
-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</p>
-16:00 <+fox> <ailouros> this all reminds me of plan9</p>
-16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems used as firewalls against users ...</p>
-16:01 < jrandom> used as firewalls against users?</p>
-16:01 <+fox> <reliver> i2p may be special, but usually bug reporting systems are used as firewalls against users ...</p>
-16:01 <+fox> <reliver> yes.</p>
-16:01 < jrandom> I want it to be really, really easy for people to report bugs</p>
-16:01 <+fox> <reliver> mozilla, thunderbird, ubuntu are just examples</p>
-16:02 <+fox> <reliver> ok, great :-)</p>
-16:02 < jrandom> mozilla/etc have that integrated "feedback agent" for submitting bug reports automatically</p>
-16:02 <+fox> <reliver> they don't read those bug reports</p>
-16:02 < jrandom> heh</p>
-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</p>
-16:02 <@modulus> but that's just me</p>
-16:02 < jrandom> modulus: perhaps the rss export would best serve your needs then?</p>
-16:02 <+fox> <ailouros> I agree with modulus (anyone guessed? :D )</p>
-16:02 <@cervantes> having to use pastebin to show console errors is a bit of a put-off for some folks</p>
-16:03 < jrandom> or we can get susimail integration, as cervantes suggested, to send out reports</p>
-16:03 < jrandom> (or to post to syndie)</p>
-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.</p>
-16:05 <@cervantes> modulus: I'll be curious to find out what you think of the new i2ptunnel interface come the next i2p release</p>
-16:05 <@cervantes> whether it's better or worse for you in terms of usability</p>
-16:05 <@cervantes> (but I guess you just normally edit the config files?)</p>
-16:07 < jrandom> ooh yeah shit, I forgot so much stuff in the status notes...</p>
-16:08 <+fox> <ailouros> then let's hurry ahead and skip to the next point in line... that was point number C, right?</p>
-16:08  * jrandom thinks it really kicks ass, but we'll get some more feedback as people try it out</p>
-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? :-)</p>
-16:08 < jrandom> yeah, jumping to 6), anyone have any thoughts on the Dynamic Keys proposal?</p>
-16:09 <@modulus> cervantes: usually use the interface actually, though now i know the config files are editable ... :-)</p>
-16:09 <+fox> <ailouros> yeah, I'm pretty certain it will cause the skyrocket in the number of supposed known routers</p>
-16:09 <@cervantes> *damn* :)</p>
-16:10 <@modulus> this dynamic key is the idea that routers get a new key upon new IP, right?</p>
-16:10 <@cervantes> modulus: well, just if it's even worth bothering with WAI bullshit</p>
-16:10 < jrandom> heh thats true ailouros</p>
-16:10 <@cervantes> anyway...I digress</p>
-16:10 < jrandom> right modulus </p>
-16:11 <@modulus> well, perhaps it isn't bad that the known peers are actually guesswork, more so than now.</p>
-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).</p>
-16:11 <+Complication> But when IP changes (rare enough?) it might not hurt.</p>
-16:11 < jrandom> right Complication.  it isn't something we'd want by default.  most people will *not* want it</p>
-16:12 < anti-> i'm not sure of the positive impact of the proposals.</p>
-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</p>
-16:12 <+fox> <ailouros> wouldn't it also give away which nodes are fixed ip and which aren't?</p>
-16:13  * cervantes has had the same key for nearly 2 years :)</p>
-16:13 <+polecat> Well at least I can get here.</p>
-16:13 < jrandom> ailouros: it would not be used by most people.  only a very, very small minority would want to use it</p>
-16:13 <+fox> <ailouros> so basically more churn for a bit of protection against weak adversaries?</p>
-16:13 < jrandom> right ailouros</p>
-16:13 <+fox> <ailouros> oh ok</p>
-16:14 <+fox> <ailouros> is there a way to measure the performance hit of that feature once in the wild?</p>
-16:14 <@modulus> it would, i think, help against a node-dest intersection attack?</p>
-16:14 <+polecat> I still wonder why I keep switching between OK and OK(NAT), puzzling...</p>
-16:14 < jrandom> modulus: only for a weak adversary</p>
-16:14 <+fox> <ailouros> polecat don't worry, I keep switching between 15h uptime and 0h uptime :|</p>
-16:14 < jrandom> ailouros: not sure, though stats.i2p suggests that we can handle the churn</p>
-16:15 < jrandom> polecat: hmm, means there's likely some filtering going on</p>
-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.</p>
-16:15 <@modulus> so, i think anything which helps on that line is probably a good idea</p>
-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.</p>
-16:16 <+fox> <ailouros> I agree with the "good idea" as long as the churn doesn't cause a severe performance hit</p>
-16:16 < anti-> when the network is bigger, there will be plenty of churn anyway...</p>
-16:17 < anti-> *points out the obvious DoS attack involving constantly changing keys every few minutes</p>
-16:17 < anti-> what impact would that have?</p>
-16:17 <+fox> <ailouros> dos against who? :D</p>
-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</p>
-16:18 < jrandom> so it won't DoS peer selection</p>
-16:18 < anti-> with a relatively strong opponent... would create an awful lot of apparently dead nodes/netdb churn?</p>
-16:18 <+Complication> anti: nobody would consider that node reliable any more</p>
-16:18 <+polecat> anti-: We have a shitlist for a reason.</p>
-16:19 < anti-> *satisfied</p>
-16:19 < jrandom> well, the netDb entries are dropped if the peer is unreachable</p>
-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?</p>
-16:20 <+polecat> incremental trust really does help with handling late onset betrayers, I was thinking.</p>
-16:20 <+fox> <ailouros> what's a "late onset betrayer"?</p>
-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...</p>
-16:20 < anti-> join for ages, then turn judas.</p>
-16:21 < jrandom> right, peers get dropped out of the 'fast' tier quickly if they act poorly</p>
-16:21 <+Complication> I'd think it would be someone behaving like "wait until 300 participating tunnels, crash"</p>
-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.</p>
-16:21 < anti-> oh no, the tunnels broken *rebuild*</p>
-16:21 < jrandom> the peers promoted to the 'fast' tier during that time they're dropped should then suffice</p>
-16:21 <+fox> * ailouros has fun with these incorrect bible refernces :D</p>
-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)</p>
-16:22 < jrandom> 600KBps?!</p>
-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.</p>
-16:22 < jmg> yes</p>
-16:22 <+fox> <ailouros> O_O what are you connected to?</p>
-16:22 <+Complication> Such bandwidth is news to me :)</p>
-16:22 < jrandom> damn, thats fast enough to start running into our bloom filters</p>
-16:22 < anti-> ailouros: rude question to anony researchers ;)</p>
-16:23 <+polecat> It's gotta be 600KBpm or ph.</p>
-16:23 <+fox> <ailouros> sorry anti- :D but he was the first to speak</p>
-16:23 <+polecat> puh!</p>
-16:23 < jrandom> I'd love to get some stats from the oldstats.jsp page off you.  but glad to hear its handling things :)</p>
-16:23 < anti-> one day i will try from i2...</p>
-16:23 < jrandom> hehe</p>
-16:24 <+fox> <ailouros> sounds cool, I2P on I2</p>
-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</p>
-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.</p>
-16:24 < jrandom> nice jmg </p>
-16:24 < anti-> polecat: do we do udp holepunching yet? i lost track</p>
-16:25 < jrandom> anti-: yes, we do, for all but symmetric NATs</p>
-16:25 < jrandom> polecat: if your friend has their model #, there are a few sites online listing what type of NAT it is</p>
-16:26 < anti-> regarding late onset betrayal... might be an issue with a powerful adversary?</p>
-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</p>
-16:26 < anti-> 24000 nodes, so you get one crashing every 10 seconds or so?</p>
-16:26 <+polecat> symmetric NAT, as opposed to full cone?</p>
-16:26 < jrandom> nice jmg </p>
-16:26 < jrandom> hmm anti-?</p>
-16:26 < jrandom> polecat: or restricted cone</p>
-16:27 <+polecat> Wow, it can even do restricted cone that's impressive..</p>
-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?</p>
-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</p>
-16:28 <+Complication> Late betrayal kind of requires contributing a lot (as to get other machines relying on your machine).</p>
-16:28 <+fox> <ailouros> incredibly massive scale = you are all the netries on almost everyone else's router?</p>
-16:28 < anti-> that is exactly what anti-p2ps do now, but we do have anti-anti-p2ps now...</p>
-16:29 <+fox> <ailouros> no wait anti-p2p send trash instead of good data</p>
-16:29 <+fox> <ailouros> that's not the same</p>
-16:29 < anti-> that's just a faster way of getting shitlisted, so you would never be listed well.</p>
-16:29 < anti-> that wouldn't work against i2p at all, i think.</p>
-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?</p>
-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.</p>
-16:29 < anti-> but we would probably bleed them dry of bandwidth first!</p>
-16:29 < jrandom> anti-: if they're reliable for days on end, they can only attack once for less than 10 minutes</p>
-16:30 < jrandom> exactly anti- :)</p>
-16:30 <+polecat> Or in the context of online banking.</p>
-16:30 < jmg> does anyone have easy instructions on setting up the Native BigInteger library for amd64? if not ill just figure it out</p>
-16:30 < jrandom> heh polecat </p>
-16:30 < jrandom> jmg: its built into jbigi.jar, but it should build on amd64 now</p>
-16:30 < jrandom> though, I suppose this means we're now on 6.1) ??? </p>
-16:31 < jrandom> anyone have anything else to bring up?  :)</p>
-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!</p>
-16:31 < jrandom> that is the hope anti-</p>
-16:31 <+fox> <ailouros> well, worst case scenario is that people must reseed</p>
-16:31 < jmg> oh thanks</p>
-16:31 <+polecat> 64 bit processor, 4mbit upload bandwidth, sounds like somebody's a lucky bastard.</p>
-16:32 < anti-> or running a normal machine at a uni...</p>
-16:32 <+fox> * ailouros looks at his uni's hardware list and frowns</p>
-16:32 < anti-> a uni that doesn't buy dell ;)</p>
-16:33 <+fox> <ailouros> I think we have a couple of dells... from 5 years ago IIRC</p>
-16:33 <+fox> <Sonium> i think this is bad:</p>
-16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError</p>
-16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError</p>
-16:33 <+fox> <Sonium> jvm 1    | java.lang.OutOfMemoryError</p>
-16:33 <@cervantes> polecat: 4 megabyte ;-)</p>
-16:33 < jrandom> Sonium: yeah, once it gets one OOM, it'll die fast</p>
-16:34 <+fox> <Sonium> and this too:</p>
-16:34 <+fox> <Sonium> jvm 1    | 21:21:44.484 CRIT  [ Establisher] sport.udp.EstablishmentManager: Err</p>
-16:34 <+fox> <Sonium> or in the establisher</p>
-16:34 < jrandom> (subsequent OOMs are safe to ignore)</p>
-16:34 < jrandom> once it gets a single OOM, you can ignore all subsequent errors</p>
-16:34 <+fox> <ailouros> yeah but you shouldn't have the first OOM :D</p>
-16:34 < jmg> polecat: the latency out here on the russian space station in phenominal though..</p>
-16:34 < jrandom> true ailouros</p>
-16:35 <+fox> <ailouros> oh, by the way... my router gets watchdogged quite often</p>
-16:35 < jrandom> hrm, high cpu usage?</p>
-16:35 <+fox> <ailouros> I guess it's just my unlucky installation?</p>
-16:35 <+fox> <ailouros> not that I know of, the machine is rather unloaded</p>
-16:36 <+fox> <ailouros> but I guess this is what I should expect from a buggy JVM on a somewhat bugged linux emulation layer</p>
-16:36 < jrandom> what jvm are you using, and what os?</p>
-16:36 <+fox> <Sonium> me?</p>
-16:36 <+fox> <ailouros> Sun's Java(tm) 2 Standard Edition, JRE 5.0 Update 5 on NetBSD/i386 2.0.2</p>
-16:37 < jrandom> ahhh yeah, I have done no testing on nbsd.  fbsd is fine, but I don't have any experience w/ nbsd</p>
-16:38 < jrandom> might be worth trying out gcj, perhaps we can dig into that after the meeting</p>
-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</p>
-16:38 <+fox> <Sonium> something really sucks here</p>
-16:38 <+fox> <Sonium> jvm 1    | #  Internal Error (53414645504F494E540E4350500175), pid=3500, tid=345</p>
-16:38 <+fox> <Sonium> 6</p>
-16:39 <+fox> <ailouros> sorry the netDb files are created 540</p>
-16:39 <+fox> <Sonium> I think I will reinstall this later</p>
-16:39 < jrandom> Sonium: what OS are you on?  the jvm seems to be acting up</p>
-16:39 <+fox> <Sonium> winxp</p>
-16:39 < jrandom> yeah, if you're on 1.5.0_5, might be worth trying 1.4.2_09</p>
-16:39 < anti-> i don't think that's i2p's problem...</p>
-16:40 < jrandom> (1.4.2 has been more stable for me, requiring less resources)</p>
-16:40 < jrandom> and i2p doesn't use any 1.5-isms, nor do we need the 1.5 GUI improvements</p>
-16:40 <+fox> <Sonium> the curious thing is, that is never occured before</p>
-16:40 <+polecat> Can't use azureus if you don't have 1.5 though, meh.</p>
-16:40 <+fox> <ailouros> and of course I *DO* use azureus :|</p>
-16:41 <+fox> <ailouros> but it isn't a real problem... not much, I think...</p>
-16:41 <+fox> <ailouros> unless those messages about bob being fourth are relevant</p>
-16:41 < jrandom> nah, those are safe to ignore</p>
-16:41 < anti-> (am i the only one irked by utorrent and bitcomet not being open?)</p>
-16:42 <+polecat> :o  Damn you bob!</p>
-16:42 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:42 < anti-> muffins?</p>
-16:42  * cervantes can recommend ibm java 1.4.2 if you're after better resource handling</p>
-16:42 <+polecat> anti-: Try mlnet.  caml -> weirdest language in the world, but it works well.</p>
-16:42 <+fox> <ailouros> caml is cool</p>
-16:42 <+fox> <ailouros> (if you can read it :D )</p>
-16:42 <@frosk> hey, don't diss caml</p>
-16:43 < anti-> prolog deserves a mention there, as does brainf**k et al</p>
-16:43 <+polecat> caml has horrible docs.  It took me half an hour to figure out that ! usually (sometimes) is a dereference operator.</p>
-16:43 <@frosk> i'm paid to write ocaml :)</p>
-16:43 <+polecat> jrandom: Didn't know I crashed a meeting, sorry.</p>
-16:44 < jrandom> np, we're making up for our short meetings ;)</p>
-16:44  * jrandom winds up</p>
-16:44  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/156.rst b/i2p2www/meetings/156.rst
new file mode 100644
index 00000000..78f933a8
--- /dev/null
+++ b/i2p2www/meetings/156.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 15, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/157.log b/i2p2www/meetings/157.log
index 9fed0c62..d38c1a2c 100644
--- a/i2p2www/meetings/157.log
+++ b/i2p2www/meetings/157.log
@@ -1,144 +1,138 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 157{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 22, 2005</h3>
-<div class="irclog">
-16:18 < jrandom> 0) hi</p>
-16:18 < jrandom> 1) Net status</p>
-16:18 < jrandom> 2) Fox hunt</p>
-16:18 < jrandom> 3) ???</p>
-16:18 < jrandom> 0) hi</p>
-16:18  * jrandom waves belatedly from a house with its power restored</p>
-16:18 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001227.html</p>
-16:19 < jrandom> 1) Net status</p>
-16:20 < jrandom> not much to add beyond whats in the mail.. anyone have anything they want to bring up re: net status?</p>
-16:21 < jrandom> if not, movin' on to 2) Fox hunt</p>
-16:21 < zzz> great idea</p>
-16:22 < jrandom> here, too, I don't have much to add beyond whats in the mail and Raccoon23's proposals..</p>
-16:22 <+fox> <ailouros> I have something against the name "Fox hunt". I'd rather call it "Man hunt". Foxes did nothing wrong.</p>
-16:22 < Raccoon23> hah</p>
-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 </p>
-16:23 < nickless_head> call it "<politically correct animal> hunt</p>
-16:23 < Raccoon23> "Fox hunt" is the typical name for a ham radio contest where you try to find a rogue transmitter</p>
-16:24 <+fox> <ailouros> I don't care for radio trasmitters called Fox, we're talking i2p here, no anonymous foxes allowed</p>
-16:24 <+fox> <ailouros> :D</p>
-16:24  * cervantes wonders if ailouros is aware of the name of changate</p>
-16:24 < nickless_head> maybe "Dissident hunt"</p>
-16:25 <@cervantes> <fox> <ailouros> :D</p>
-16:25 <+fox> <ailouros> (err what's changate?)</p>
-16:25 < jrandom> heh</p>
-16:25 <@cervantes> ailouros: it's the bots that relay chat between different networks</p>
-16:26 <+fox> <ailouros> you mean vulpine here?</p>
-16:26 <@cervantes> chat over on i2p gets relayed to you as vulpine</p>
-16:26 <@cervantes> and you chat is relayed to us via fox</p>
-16:26 <@cervantes> ;-)</p>
-16:26 <@cervantes> *your</p>
-16:26 <+fox> <ailouros> so the hunt is for the poor slave-working bot? :D</p>
-16:27 < Raccoon23> so yeah, I think there should be a bounty/info page set up. I think we should shoot for raising $1k</p>
-16:27 <+fox> <ailouros> yeah sorry I don't usually go i2pchat  :)</p>
-16:27 <+fox> <ailouros> now, that's a bounty!</p>
-16:28 < jrandom> Raccoon23: I agree, but it may be a bit premature to do so now.  </p>
-16:28 < jrandom> (we can always allocate funds out of the general fund to the bounty to kick start it when necessary)</p>
-16:28 <+fox> <ailouros> start the hunt right now but without a bounty?</p>
-16:28 <+fox> <ailouros> I mean, the sooner it starts, the more eyes get open</p>
-16:28 < jrandom> for the fox hunt to make sense (aka help I2P), we need to do so carefully.</p>
-16:28 < jrandom> no ailouros, I disagree.</p>
-16:29 < jrandom> running the contest before I2P is ready would be very bad.</p>
-16:29 < Raccoon23> yah</p>
-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</p>
-16:30 <+fox> <ailouros> ....point taken</p>
-16:30 < Raccoon23> and it would be bad press if vulns were "found" that were scheduled to be fixed in coming versions</p>
-16:30 < jrandom> aye</p>
-16:33 < jrandom> ok, anything else on 2), or shall we move on over to 3) ???</p>
-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?</p>
-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</p>
-16:35 < jrandom> other conclusions may be "hey, get rolling on 0.6.2" :)</p>
-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</p>
-16:36 < jrandom> ailouros: you should be able to save the settings on /i2ptunnel/ </p>
-16:36 < jrandom> or are you changing them on /configtunnels.jsp ?</p>
-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</p>
-16:37 <+fox> <ailouros> configtunnels it is</p>
-16:37 < jrandom> aye, agreed Raccoon23 </p>
-16:37 < jrandom> ailouros: use /i2ptunnel/ and save your settings</p>
-16:37 <+fox> <ailouros> didn't notice the new interface :D</p>
-16:38 <@cervantes> ailouros: just added in 0.6.1.5</p>
-16:38 < jrandom> yeah cervantes did some great work there ailouros</p>
-16:38 <+fox> <ailouros> well, kudos for that</p>
-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</p>
-16:39 <@cervantes> *grumble* microsoft *grumble*</p>
-16:40 <+fox> <ailouros> on a different topic, would anyone be interested if I set up a nethack server on i2p? :D</p>
-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)</p>
-16:42 <+fox> <ailouros> guess so</p>
-16:42 <+fox> <ailouros> okay, idea scrapped</p>
-16:43  * frosk just had his first ascension a few months back, woot</p>
-16:44 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:45 <+fox> <ailouros> yes, some indicator for syndie wen the thread has a new message</p>
-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</p>
-16:47 < nickless_head> jrandom: is there a _really simple_ way to get to the messages in the syndie database, over http?</p>
-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).  </p>
-16:47 < nickless_head> jrandom: preferredly in something nice and importable like xml</p>
-16:48 < jrandom> nickless_head: wget -R http://localhost:7657/syndie/archive/</p>
-16:48 < nickless_head> if there is, I could write a syndie to nntp exporter</p>
-16:48 < jrandom> oh, if you want to export to nntp, use rss to nntp</p>
-16:48 < nickless_head> jrandom: ok I'll try that :)</p>
-16:48 < nickless_head> jrandom: that already exists? ... damn. ;)</p>
-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 :)</p>
-16:49 < jrandom> or perhaps a new filter on the thread tree - only show messages posted since [today |v]</p>
-16:49 < jrandom> (or yesterday, or 2 days ago)</p>
-16:50 < jrandom> nickless_head: http://www.methodize.org/nntprss/</p>
-16:50 < nickless_head> jrandom: thanks</p>
-16:54 < jrandom> np</p>
-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?</p>
-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)</p>
-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..</p>
-16:56 < jrandom> not everyone has p4s ;)</p>
-16:56 < jrandom> i hear reports of 8-15% usage on slow machines, but that spikes bad under congestion</p>
-16:56 < jrandom> (to 100+%)</p>
-16:56 <+Complication> About CPU consumption: curiously enough, Java on Mandriva 10.1 consumes a lot less than Java on Mandriva 2006.</p>
-16:56 < Raccoon23> yah, but those who don't probably don't have T1</p>
-16:56 < Raccoon23> either :)</p>
-16:57 <+Complication> Both tweaked, 2006 has jbigi compiled locally.</p>
-16:57 < jrandom> weird Complication </p>
-16:57 < jrandom> same revs of i2p?</p>
-16:57 <+Complication> On 2006 (Celeron 2.4) java can hit 20%.</p>
-16:58 <+Complication> On 10.1 it wouldn't go higher than 5%.</p>
-16:58 <+Complication> (Usually)</p>
-16:58 <+Complication> (usually==not on startup)</p>
-16:58 <+Complication> Same revisions.</p>
-16:58 <+Complication> Almost the same Java too (_04 versus _05)</p>
-16:59 <+Complication> Reminds me to tweak daemons a bit more. Perhaps some of them is obstructing java.</p>
-16:59 <+Complication> In some wacky way I cannot figure out.</p>
-17:00 <+Complication> But yes, the Cel 300 is feeling notably better. Could have been the adaptive MTU</p>
-17:01 < jrandom> ah cool, yeah, we've got some neat stuff on the way :)</p>
-17:03 <+Complication> I wonder if there'd be a way to get past the libc-related jbigi problems on certain Linux distros?</p>
-17:03 < jrandom> yeah, definitely, just need to rebuild all the jbigis </p>
-17:03 < jrandom> (its not libc, its libg++)</p>
-17:05  * Raccoon23 decides he doesn't give up his dreams of garlic routing, but will wait for performance to stabilize.. perhaps 2.0</p>
-17:05 <+Complication> Oh, you think a proper rebuild will help it?</p>
-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 ;)</p>
-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</p>
-17:06 < jrandom> (eventually)</p>
-17:07 < Raccoon23> like a caps=S for speedy CPU? ;) </p>
-17:08 < jrandom> and caps=I for insane ;)</p>
-17:08 < jrandom> ok, anyone else have something for the meeting?</p>
-17:08 < Raccoon23> haha</p>
-17:09 < Raccoon23> what do you think about the stopgap of sharing keys across multiple tunnels? too little payoff for the work?</p>
-17:09 < jrandom> why would that be better than just having multiple tunnels and sending the message through one of the multiple tunnels?</p>
-17:10 < jrandom> (and, erm, wouldn't it be worse, from a security perspective, and anonymity perspective)</p>
-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</p>
-17:11 < Raccoon23> which should make timing attacks harder</p>
-17:11 < jrandom> ah, yikes, yeah.  that adds Really Bad linkability</p>
-17:11 < jrandom> its why we moved to per-client tunnel pools in 0.4</p>
-17:11 < Raccoon23> explain?</p>
-17:11 < jrandom> i2ptunnel does let people share pools, if they want, by sharing the same destination</p>
-17:12 < jrandom> if messages for 2 clients go down a tunnel, you know both of those clients are controlled by the same person</p>
-17:12 < jrandom> s/clients/destinations/</p>
-17:13 < Raccoon23> well if keys were shared, the early hops could be blended, but the leasesets seperate..</p>
-17:13 < Raccoon23> the early hops being the dangerous ones for timing attacks anyways</p>
-17:13 < jrandom> it'd still allow a vector for linking the two unlinkable destinations</p>
-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.</p>
-17:18 < Raccoon23> back to dreaming of caps=SI I guess :)</p>
-17:19 < jrandom> ah well.  ok, anyone have anything else?</p>
-17:20  * jrandom winds up</p>
-17:20  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/157.rst b/i2p2www/meetings/157.rst
new file mode 100644
index 00000000..9a7c46c6
--- /dev/null
+++ b/i2p2www/meetings/157.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 22, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/158.log b/i2p2www/meetings/158.log
index 73a1f49c..d3d35fc8 100644
--- a/i2p2www/meetings/158.log
+++ b/i2p2www/meetings/158.log
@@ -1,228 +1,222 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 158{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 29, 2005</h3>
-<div class="irclog">
-15:25 < jrandom> 0) hi</p>
-15:25 < jrandom> 1) Net status and 0.6.1.6</p>
-15:25 < jrandom> 2) Syndie</p>
-15:25 < jrandom> 3) I2P Rufus 0.0.4</p>
-15:25 < jrandom> 4) ???</p>
-15:25 < jrandom> 0) hi</p>
-15:25  * jrandom waves</p>
-15:25 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2005-November/001234.html</p>
-15:26  * bar hands jrandom a baf</p>
-15:26 < c3rvantes> not yet!</p>
-15:26  * jrandom winds up</p>
-15:26 < jrandom> er...</p>
-15:26 < jrandom> lets hit the first few agenda items first :)  1) Net status and 0.6.1.6</p>
-15:27 < jrandom> lots of things have been updated in the last few releases, but the network still seems reasonably stable.  </p>
-15:28 < jrandom> we've had some serious spikes in router participation on a few routers, though thats pretty harmless</p>
-15:28 <+legion> cool, I agree net status is getting better. Also yeah why not drop tcp for 0.6.1.7</p>
-15:28 < jrandom> (er, spikes in tunnel participation, that is)</p>
-15:29 <@cervantes> you're not kidding</p>
-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</p>
-15:29 <+legion> well I've noticed with 0.6.1.5 the router would sometimes restart on its own.</p>
-15:29 <+Complication> Mine's been swinging withint reasonable limits, 100 to 250 participating tunnels</p>
-15:29 < jrandom> I can't think of any great reason to keep it, and I can think of a few to drop it</p>
-15:30 < jrandom> cool Complication</p>
-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 ;)</p>
-15:30 <+Complication> My old Celeron is still auto-restarting every 10 hours or so</p>
-15:30 <+Complication> Otherwise it's better connected than ever before</p>
-15:30 < Pseudonym> what are the reasons to drop it?</p>
-15:31 <+Complication> TCP is expensive</p>
-15:31 <@cervantes> my router is shagged out</p>
-15:31 <+Complication> In terms of threads per connections</p>
-15:31 <@cervantes> Complication: multiply that by 10 and you get my router's current range ;-)</p>
-15:31 <+legion> Mines been swinging within 200-400 participating tunnels, so it seems better than ever.</p>
-15:32 <+Complication> cervantes: ouchie ouchie</p>
-15:32 <+Complication> I've seen a freak accident which caused 2000 participating tunnels, but that was in Summer</p>
-15:32 < jrandom> Pseudonym: performance (cpu/memory, better scheduling due to our semireliable requirements), maintainability, more effective shitlisting</p>
-15:32 <+Complication> A single spike which never repeated again</p>
-15:32 <+legion> yeah, with some past versions there were such spikes</p>
-15:32 < jrandom> Complication: we've had > 2000 tunnel spikes with this last rev</p>
-15:33 < jrandom> but hopefully 0.6.1.7 will take care of that</p>
-15:33 <+legion> Well those are some good reasons to drop tcp :)</p>
-15:33 < jrandom> but, again, the spikes in tunnel participation is fine, as most of them aren't used</p>
-15:34 <@cervantes> Pseudonym: there only seems to be one or two routers still using tcp on the network</p>
-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</p>
-15:34 < jrandom> (and can reenable it if necessary)</p>
-15:35 < Pseudonym> if there are only two routers using it, I can't imagine it would have much effect either way</p>
-15:35 < Pseudonym> (except for there being two less routers on the network)</p>
-15:35 <@cervantes> 2 disgruntled customers</p>
-15:35 < jrandom> well, the transport does show up in some odd situations, which is one of the reasons i want to disable it :)</p>
-15:35 <+Complication> I hope they won't take it very personally</p>
-15:36 <+Complication> It's really nasty of certain ISP's to filter UDP.</p>
-15:36 <+Complication> Nasty, and completely senseless.</p>
-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)</p>
-15:36  * Pseudonym loves his ISP.  no restrictions</p>
-15:37 <+Complication> So without TCP, one would see how UDP handles it alone?</p>
-15:37 <+Complication> "with no auxiliary wheels" :P</p>
-15:37 <+legion> huh so how do we get around such nasty filtering without tcp?</p>
-15:38 < jrandom> exactly Complication :)</p>
-15:38 < jrandom> legion: we don't</p>
-15:38 < jrandom> (restricted routes)</p>
-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?</p>
-15:39 <+legion> :( doesn't sound good</p>
-15:39 <+Complication> Sized similarly to the smallest packet size I2P uses?</p>
-15:39 < jrandom> eh legion, its not a problem</p>
-15:39 < jrandom> Complication: streaming protocols</p>
-15:39 <+Complication> One cannot block UDP directly, ever, without crippling DNS.</p>
-15:39 <+Complication> One can limit the packet size.</p>
-15:40 <+legion> ok, it did sound like it could be</p>
-15:40 <+Complication> VoIP?</p>
-15:40 < jrandom> it'd be a problem if it were widespread - if the internet community in general banned udp</p>
-15:40 <+Complication> Hmm, does VoIP use big or small packets?</p>
-15:40 < jrandom> but if its just a few isps, we can treat them like restricted routes</p>
-15:40 <+Complication> Or did you mean more like... video spreaming?</p>
-15:40 <+legion> I'd think it'd use a mix of both</p>
-15:41 < jrandom> both Complication, RTSP runs over UDP, and real runs over RTSP iirc</p>
-15:41 <+Complication> s/p/s</p>
-15:42 <+legion> So on to the next item?</p>
-15:42 <+Complication> cat /etc/services | grep -c udp</p>
-15:42 <+Complication> 227</p>
-15:43 < jrandom> I'm still not sure if we'll drop tcp in 0.6.1.7, but probably.  </p>
-15:43 < jrandom> aye, anyone have anything else on 1)?  if not, lets jump on to 2) Syndie</p>
-15:43 <+Complication> Meaning, there are at least 227 apps (some possibly obsolete or LAN apps) which use UDP</p>
-15:44 < jrandom> bah, this is the intarweb.  all you need is proxied HTTP access</p>
-15:44 < jrandom> I don't have much to add to 2) beyond whats in the mail (and whats on Syndie)</p>
-15:44 <+legion> I'm convinced, yeah drop it. :)</p>
-15:44 < jrandom> anyone have anything re: syndie they want to bring up?</p>
-15:45 <+legion> I've nothing to say about 2) either.</p>
-15:45  * Complication is reading "how Syndie works"</p>
-15:46 <+Complication> One little UI effect, keeps surprising me. :D</p>
-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</p>
-15:47 <+Complication> But you can proabably safely ignore that. I'm just very picky, and a creature of habit. :P</p>
-15:47 <@cervantes> the threading model is something that's being discussed at length</p>
-15:47 <@cervantes> ;-)</p>
-15:47 <+Complication> I'll get used to it. :)</p>
-15:48 <+Complication> cervantes: in Syndie? I gotta find that thread. :)</p>
-15:48 <@cervantes> I don't like that either - but it could well change</p>
-15:48 < jrandom> yeah, thats kind of kooky I suppose</p>
-15:48 <+legion> yeah</p>
-15:48 <@cervantes> "subject: syndie threading"</p>
-15:49 <+Complication> Besides, if the expanded message were the bottom-most, it *would* have to move anyway.</p>
-15:49 <+Complication> 'Cause otherwise it'd be stuck there.</p>
-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</p>
-15:50  * cervantes is testing some different threading UI style implementations atm</p>
-15:51 < jrandom> wikked</p>
-15:51 < jrandom> yeah, ideally we'll be able to switch them around in css, or if not, on the server side</p>
-15:52 <@cervantes> or rather "threading navigation styles"</p>
-15:53 <@cervantes> hmm my tests use pure html nested unnordered lists by default</p>
-15:53 <@cervantes> you can layer on as much css and javascript as your need or want</p>
-15:53 < jrandom> any eta on when we can see some mockups?</p>
-15:53 <@cervantes> (however it's only a proof of concept, not an actual ui implementation)</p>
-15:54 <@cervantes> I do most of my coding during I2P meetings ;-)</p>
-15:54 < jrandom> heh</p>
-15:54 <@cervantes> perhaps the first mockup will be ready this evening</p>
-15:54  * jrandom schedules daily meetings</p>
-15:54 < jrandom> wikked</p>
-15:54 <@cervantes> curses :)</p>
-15:55 < jrandom> ok, anyone have anything else for 2) syndie?</p>
-15:55 < jrandom> if not, lets move on to 3) I2P Rufus 0.0.4</p>
-15:56 < jrandom> I don't have much to add beyond whats in the mail - Rawn/defnax, y'all around?</p>
-15:56 <+legion> so how good is 0.0.4? What problems remain if any?</p>
-15:57  * jrandom hasn't a clue</p>
-15:58 <+legion> Maybe one of its users can answer. Does it seem good and stable?</p>
-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</p>
-15:58 <+legion> darn, guess we'll have to.</p>
-15:59 <+legion> on to 4)?</p>
-15:59 < jrandom> aye, so it seems.  ok, 4) ??? </p>
-15:59 <+Complication> I haven't tried I2P Rufus, unfortunately.</p>
-16:00 < jrandom> anyone have anything else they want to bring up?</p>
-16:00 < jrandom> (c'mon, we've got to drag this out so cervantes can do some more work!)</p>
-16:00 <+legion> yeah, what sort of interesting stuff is coming down the pipe?</p>
-16:00 <+bar> is there anywhere i could read more about "restricted routes"?</p>
-16:00 <+bar> (i *have* searched)</p>
-16:01 <+legion> Maybe we could even discuss i2phex?</p>
-16:01 < jrandom> http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD</p>
-16:01  * cervantes poises his mouse over the close button</p>
-16:01 < jrandom> er, #future.restricted</p>
-16:02 < jrandom> plus the how_* pages & todo</p>
-16:02 < jrandom> (on the web)</p>
-16:02 <+Complication> Heh, I2P seems to have skipped a build :D</p>
-16:02 <+Complication> :D</p>
-16:02 <+bar> thanks</p>
-16:02 <+Complication> -    public final static long BUILD = 1;</p>
-16:02 <+Complication> +    public final static long BUILD = 3;</p>
-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</p>
-16:03 <+legion> huh, odd</p>
-16:03 < jrandom> anything to bring up re: i2phex legion?</p>
-16:03 < jrandom> Complication: yeah, intended.  I forgot to increase it for BUILD = 2</p>
-16:03 <+Complication> (not that it matters for anything, just wondering if I've seen this rare occasion before :)</p>
-16:04 <+legion> sweet, sounds great, thanks!</p>
-16:04 < jrandom> oh, that reminds me... it'd be cool if someone wanted to dig into looking at revamping our webpage</p>
-16:05  * jrandom doesnt want to think about it, but its got to be done sooner or later</p>
-16:05 <+legion> yeah, there is</p>
-16:05 <+legion> would it be worthwhile to update i2phex at this point to the latest phex cvs code?</p>
-16:06 <+Complication> Not sure, I haven't heard from Redzara recently</p>
-16:06 < jrandom> last I recall, redzara was waiting on gregorz's updates to phex</p>
-16:06 < jrandom> (so we could have a fairly clean update/extension)</p>
-16:08 <+legion> huh, then why have i2phex?</p>
-16:08 <+Complication> Just in case?</p>
-16:08 < jrandom> hmm?</p>
-16:08 < jrandom> i2phex is an extension to phex</p>
-16:08 <+legion> Seems like they wanted there to just be phex with a i2p extension</p>
-16:09 < jrandom> extension, as in, modification to a very small number of bits</p>
-16:09 < jrandom> er, s/bits/components/.  so we can easily update the code whenever the phex devs fix things</p>
-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.</p>
-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</p>
-16:10 < jrandom> aye legion, that'd be great, but last I heard, Gregor hadn't finished the modifications to Phex yet</p>
-16:11 < jrandom> (which is what redzara was waiting on)</p>
-16:11 <+legion> ah I see</p>
-16:11 < jrandom> so, the alternative is to either help Gregor out or continue modifying the existing I2Phex codebase</p>
-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</p>
-16:12 < jrandom> well, not really. </p>
-16:12 < jrandom> updating I2Phex to the current Phex code would be great, yes</p>
-16:13 < jrandom> but as soon as the Phex developers update their Phex code, we're out of sync again</p>
-16:13 <+legion> ok, I'll probably get to it sometime tonight or within a couple days.</p>
-16:13 < jrandom> wikked</p>
-16:13 <+legion> That is fine.</p>
-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.</p>
-16:15 <+legion> Also I'm really looking to drop out any phex code and features which i2phex doesn't need.</p>
-16:15 < jrandom> cool</p>
-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.</p>
-16:17 < jrandom> word.  yeah, phex used to have working gwebcache support, but sirup disabled it, as it wasn't necessary at first</p>
-16:17 <+legion> I do plan on adding jeti to i2phex eventually.</p>
-16:17 < jrandom> neat</p>
-16:18  * jrandom has never used jeti, and I hope it stays an optional component, but supporting more things is cool</p>
-16:18 <+legion> Yeah it can be optionally, users will be able to download a jeti2phex ;)</p>
-16:19 < jrandom> word</p>
-16:19 <+legion> There still is much we can do with i2phex, though it is working great as it is.</p>
-16:20 <+legion> So far keeping a client connected, up and running for 24/7 is possible and easy.</p>
-16:21 < jrandom> yeah, I've had some good success with it... "backing up my licensed recordings"</p>
-16:21 <+legion> heh :)</p>
-16:22 < jrandom> ok, anyone else have anything for the meeting?</p>
-16:23  * cervantes wheels in the chinese gong</p>
-16:23 <+legion> Seems like I'm forgetting something... hmm</p>
-16:24 <+legion> Oh yeah, any ideas on how we can reduce the amount of memory i2p and i2phex consumes?</p>
-16:25 <+Complication> Well, the TCP transport takes a bit</p>
-16:25 < jrandom> one could run both in the same jvm</p>
-16:25 <+Complication> If that is going, it will free a bit</p>
-16:26 <@cervantes> take some ramsticks out of your machine</p>
-16:26 < cat-a-puss> anyone with any experence with javolution know if it would help? http://javolution.org/</p>
-16:26 < jrandom> (clients.config in the i2p install dir defines the main class and arguments to launch clients)</p>
-16:26 <+legion> So if we ran both in the same jvm and when tcp goes, could we bring it down to under 50mb?</p>
-16:27 < jrandom> no idea legion.  depends on what you mean by 50MB as well.  RSS/VSS/etc</p>
-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</p>
-16:27 <@cervantes> legion: limiting bandwith and capping participants might also help</p>
-16:27 < jrandom> aye, what cervantes said</p>
-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</p>
-16:28 <+Complication> Right, it makes those different allocations, which I've never really managed to make sense of</p>
-16:28 < jrandom> aye, we do some of that cat-a-puss (see net.i2p.util.ByteCache)</p>
-16:29 <+Complication> (but as said, Java is a very new thing to me)</p>
-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</p>
-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</p>
-16:31 < jrandom> well, it really wouldn't save any memory, but would help cut down on GC churn</p>
-16:31 <+legion> Well I personally don't care much about memory allocation, however many people do.</p>
-16:31 < jrandom> ooh, and its BSD licensed too</p>
-16:31 < cat-a-puss> right</p>
-16:31 < jrandom> legion: memory allocation means performance</p>
-16:32 <+legion> er, oh, memory consumption then</p>
-16:33 <+legion> Many people are so very happy with utorrent because of it's very small memory footprint.</p>
-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)</p>
-16:34 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:35 <+legion> nah I'm good...</p>
-16:37  * jrandom winds up</p>
-16:37  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/158.rst b/i2p2www/meetings/158.rst
new file mode 100644
index 00000000..4c7f15f8
--- /dev/null
+++ b/i2p2www/meetings/158.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 29, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/159.log b/i2p2www/meetings/159.log
index 93309585..054c98d5 100644
--- a/i2p2www/meetings/159.log
+++ b/i2p2www/meetings/159.log
@@ -1,266 +1,260 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 159{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 6, 2005</h3>
-<div class="irclog">
-15:26 < jrandom> 0) hi</p>
-15:26 < jrandom> 1) 0.6.1.7 and net status</p>
-15:26 < jrandom> 2) Experimental tunnel failures</p>
-15:26 < jrandom> 3) SSU and NATs</p>
-15:26 < jrandom> 4) Syndie</p>
-15:26 < jrandom> 5) ???</p>
-15:26 < jrandom> 0) hi</p>
-15:26  * jrandom waves</p>
-15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001237.html</p>
-15:26  * ailouros read the notes</p>
-15:27  * jrandom is late, so I'll give y'all a moment to read up :)</p>
-15:29 < jrandom> ok, might as well jump on in to 1) 0.6.1.7 and net status</p>
-15:29 <@cervantes> *cough*</p>
-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?</p>
-15:30 < Pseudonym> seems like doing performance optimization before changing the the tunnel creation algo might be backwards</p>
-15:30 < gott> I am getting a lot of "No HTTP method found in the request.</p>
-15:30 < gott> Software caused connection abort: socket write error</p>
-15:30 < gott> "</p>
-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.</p>
-15:30 < gott> from the I2PTunnel Webmanager</p>
-15:31 < jrandom> gott: those suggest bad http requests, or things that the eepproxy ouldn't understand</p>
-15:31 < jrandom> modulus: cool, we've been doing lots to try and improve things</p>
-15:31 < jrandom> Pseudonym: well, so far tunnel creation hasn't been our choke point - our choke point was much higher level stuff</p>
-15:32 < jrandom> otoh, the improvements of the last few revs have exposed some issues down there</p>
-15:32 < Pseudonym> oh, so the optimization has been related to other parts of the code?</p>
-15:32 < Pseudonym> cool</p>
-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 ;]</p>
-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</p>
-15:34 < ailouros> I wonder why sometimes I see more tunnels than those configured for a destination (eg. eeProxy, inbound 7 tunnels 4 outbound)</p>
-15:34 < jrandom> so, over the next few days when you see the router 7xgV transferring lots of data, well, dont mind it ;)</p>
-15:35 < jrandom> ailouros: when tunnel creation takes a while, it builds extras, just in case.  </p>
-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</p>
-15:35 < ailouros> I see.. but then why they all expire at the same time?</p>
-15:35 <@cervantes> jrandom: out of curiosity, when did you begin those tests?</p>
-15:35 < jrandom> cervantes: a few days ago</p>
-15:36 <@cervantes> ah cool, it's _not_ that then ;-)</p>
-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</p>
-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</p>
-15:38 < ailouros> as in, tunnel creations are skewed</p>
-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</p>
-15:40 <+Complication> I wonder why an otherwise sane instance of i2phex... would decide to rehash files every other time I start it?</p>
-15:40 < jrandom> not a clue</p>
-15:40 <+Complication> Damaged configuration sounds the likely cause so far, but I've not deleted my config yet.</p>
-15:40 < jrandom> perhaps skewed timestamps?</p>
-15:42 <+Complication> Nah, they seem correct too</p>
-15:42  * jrandom knows not.  never looked at that part of phex's cod</p>
-15:42 < jrandom> er, code</p>
-15:42 <+Complication> I'll see if deleting old config files does it any good</p>
-15:42 < jrandom> cool</p>
-15:43 < jrandom> ok, anything else on 1) Net status / 0.6.1.7?</p>
-15:43 < jrandom> if not, moving on to 2) Experimental tunnel failures</p>
-15:44 < jrandom> we've touched on this a bit already, and there's more in the notes and on zzz.i2p</p>
-15:44 < jrandom> zzz: do you have anything you want to add/bring up?</p>
-15:46 < jrandom> if not, lets move on to 3) SSU and NATs</p>
-15:46 < jrandom> bar: anything you want to add?</p>
-15:46 <+bar> nope, i have nothing else to add but what's in the mail</p>
-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</p>
-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)</p>
-15:48 <+bar> all in due time, no hurry</p>
-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</p>
-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 </p>
-15:50 < jrandom> (everyone meaning myself included ;)</p>
-15:52 <+bar> agree</p>
-15:52 < ailouros> lol if I did too then there were something wrong with the docs, as I followed them bit by bit :D</p>
-15:53 <+bar> meanwhile, i will spend some time studying the peer testing</p>
-15:53 < jrandom> cool, thanks bar!</p>
-15:54 <+bar> (perhaps i could generate some useless spam regarding that as well :)</p>
-15:54 < jrandom> :)</p>
-15:55 < jrandom> ok, if there's nothing else on 3), lets move on to 4) Syndie</p>
-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</p>
-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 </p>
-15:57 < ailouros> I find that 6.1.7's layout is harder to use than 6.1.6's</p>
-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?</p>
-15:58 < ailouros> official 0.6.1.7, single user</p>
-15:58 < jrandom> are you one of the proponents of the blog-like interface, as opposed to the threaded nav?</p>
-15:58 < ailouros> I am not, though I don't really know which is the blog-like</p>
-15:58 < ailouros> personally I'd rather have a threaded nav</p>
-15:59 < ailouros> (and some color-coding of new messages as well in thread view)</p>
-15:59 <+Complication> Relatively late CVS, single user</p>
-15:59 <+Complication> I've found a minor oddity (which I think, could be non-intended)</p>
-15:59 < jrandom> ah, there has been a lot of progress on that front in CVS ailouros </p>
-15:59 < ailouros> great :)</p>
-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</p>
-16:00 <@cervantes> are those changes pushed to syndiemedia.i2p.net?</p>
-16:00 <+bla> Would it be a good idea to show some default examples for the location in http://localhost:7657/syndie/syndicate.jsp ?</p>
-16:00 < jrandom> syndiemedia.i2p.net is CVS head, yeah</p>
-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")...</p>
-16:00 < jrandom> aye, perhaps bla.  new installs will have the three defaults in there, but examples would be good</p>
-16:01 <@cervantes> (the actual thread's tree needs to fully open too though)</p>
-16:01 <+Complication> ...it appears to leave the current posts displayed, as if they were matching or something...</p>
-16:01 <+Complication> Despite me definitely clicking the "Go" button.</p>
-16:01 <@cervantes> Complication: yeah I found that confusing too</p>
-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</p>
-16:02 < jrandom> cervantes: ah, yeah expanding it to the leaf would be good, and should be trivial to do</p>
-16:02 <+Complication> Just noticed, and since it stuck out, thought I'd tell</p>
-16:02 <@cervantes> (or make it more obvious that there aren't any matches)</p>
-16:03 < jrandom> well, the thread nav says *no matches* :)</p>
-16:03 < ailouros> perhaps he's looking for a lighter</p>
-16:03 < jrandom> !thwap</p>
-16:03 <@cervantes> (or make it even more obvious that there aren't any matches)</p>
-16:03 < jrandom> <blink>No matches</blink></p>
-16:03 <+Complication> Oops :)</p>
-16:04 < tethra> seems your !thwap got spaetz__ instead, jr!</p>
-16:04 <+Complication> Right, sometimes the thread navigator *does* feel a long distance away :)</p>
-16:04 < jrandom> yeah, we're experimenting with some css to float that down the side, as an option</p>
-16:05 <@cervantes> with skinning support you could have the thread top buttom left right etc</p>
-16:05 <@cervantes> ah as jr said</p>
-16:05 <+Complication> The "Threads" link takes one there fairly quick, though</p>
-16:05 <+Complication> ...if it's within the viewport currently.</p>
-16:06 <+Complication> And those who are used to keyboard-navigating can naturally press "End"</p>
-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</p>
-16:07 < jrandom> I expect we'll have a main blog overview page in the next few days in cvs</p>
-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 :)</p>
-16:08 < jrandom> anyone have anything else to bring up on that, or shall we move on to 5) ???</p>
-16:09 < zzz> hi just walked in. on 2), I'm looking for testers for my patch.  </p>
-16:10 < zzz> My results are improvements in job lag and reliability, and reduction in router hangs. So hoping others will try.</p>
-16:10 < ailouros> that sounds good enough. what do I have to do?</p>
-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</p>
-16:11 < ailouros> (average uptime is about 10h here :(</p>
-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</p>
-16:12 < zzz> jrandom I'll work on splitting it up</p>
-16:12 < ailouros> I'll go for the update, thanks</p>
-16:13 < zzz> ailouros will put it on zzz.i2p within an hour - thanks</p>
-16:13 < jrandom> zzz: I wouldn't worry about it unless you've got spare time... I can read through the diff :)</p>
-16:13 < ailouros> thank you</p>
-16:14 < zzz> jrandom OK. There's some miscellaneous stuff that can easily be ripped out by either you or me.</p>
-16:16 < ailouros> I guess we're at 5) ??? now?</p>
-16:16 < zzz> jrandom other topic  was Router OOMs with i2phex and possible SAM  issues</p>
-16:16 < jrandom> aye ailouros </p>
-16:16 < jrandom> ah yeah zzz, it'd be great to track down whats up with SAM</p>
-16:17 < ailouros> j346, did you have the chance to check out my app?</p>
-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.</p>
-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</p>
-16:20 < ailouros> feel free to ask</p>
-16:20 < ailouros> (and good luck on the journey through the source, it's a good definition for the word "mess")</p>
-16:20 < jrandom> hehe</p>
-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</p>
-16:22 <+Complication> Mine happened after some late-night stress-testing.</p>
-16:22 <+Complication> (during which, let it be noted, I saw 5-minute averages of 50 KB/s)</p>
-16:22 < bar_> could you please remind me what your app is/does, ailouros? my memory is good but short...</p>
-16:22 <+Complication> Incoming, that is.</p>
-16:22 <+Complication> Outgoing was limited to 35 KB/s</p>
-16:22 <@cervantes> Complication: I've never heard it called late-night stress testing before...</p>
-16:22 < jrandom> nice Complication </p>
-16:23 <+Complication> cervantes: well, one *could* call it semi-daily megaleeching then :P</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)</p>
-16:23 < bar_> ah, right, thanks ailouros</p>
-16:24 < tethra> cervantes: heheheh ;)</p>
-16:24 < ailouros> you're welcome (if anyone wants to get the source, it's in c/c++)</p>
-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.</p>
-16:25 < ailouros> polecat, I agree. My best guess is that it comes useful when you get different versions of the same files</p>
-16:25 < ailouros> like, a movie which has a corrupted block</p>
-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")</p>
-16:26 < ailouros> or an archive of other zip files</p>
-16:26 < jrandom> or e.g. modified ID3 tags, etc</p>
-16:26 < ailouros> exactly</p>
-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.</p>
-16:26 < jrandom> archives of files probably won't work though, since they'd have to break on file boundaries</p>
-16:27 < ailouros> j636, that's why I want to implement LBFS's idea of splitting on data marks and not fixed block sizes</p>
-16:27 <@cervantes> the DC community used that method, by sharing file distributions in rarsets</p>
-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.</p>
-16:29 <@cervantes> and then searches are basedon tiger hashes of those rar parts</p>
-16:29 <+Complication> Nice thought... sounds difficult though :)</p>
-16:29 <+polecat> But just a hash-for-hash equivalent... you'd never find two blocks alike!</p>
-16:29 < ailouros> cervantes, what's a "rarset"? :D (except a "RAR file", that is)</p>
-16:29 <+polecat> Unless both sides already had the file, one of them corrupted.</p>
-16:29 < ailouros> polecat, uh?</p>
-16:29 <@cervantes> ailouros: a split rar archive, with parity files if necessary</p>
-16:30 < ailouros> cervantes: I don't understand the advantage of doing that</p>
-16:31 <@cervantes> it's main benefit was to add pseudo-multi-source downloading to DC</p>
-16:32 < ailouros> well, that's part of the block sharing mechanism between files, isn't it?</p>
-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</p>
-16:35 <@cervantes> your client only matches/downloads valid parts, if you have parity files you can also recover damaged parts </p>
-16:35 < ailouros> with my system there are no damaged parts (files are assembled only when the composing blocks are downloaded and re-checked)</p>
-16:36 <@cervantes> stuff bittorrent does by default, except that you can't search specifically for individual parts</p>
-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.</p>
-16:37 <+polecat> Or another jerk takes random data and names it by the file you want to download.</p>
-16:37 < ailouros> lol that's correct</p>
-16:37 <@cervantes> exactly and rarset releases are immune to that...</p>
-16:37 < ailouros> but keep in mind that files from other networks (emule, kazaa, whatever) often come corrupted</p>
-16:38 <+polecat> rarset releases aren't immune...</p>
-16:38 <+polecat> You still have to figure out which rarset is the right one.</p>
-16:38 < ailouros> cervantes, how are rarsets immune to an idiot publishing random junk?</p>
-16:38 <@cervantes> (provided you have a reliable source)</p>
-16:39 <@cervantes> because a release group publishes hashes/distribution information</p>
-16:39 < ailouros> hahaha that's easy :D</p>
-16:39 <@cervantes> and stuff is marked as nuked if it's poor quality, folk remove it from shares</p>
-16:40 < ailouros> cervantes, that much my toy already does</p>
-16:40 <@cervantes> cool</p>
-16:40 < ailouros> you get the file descriptor from a trusted source, you multiget the file pronto</p>
-16:41 <@cervantes> sounds good ;-)</p>
-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</p>
-16:42 < ailouros> though I might add a search function sometime in the future if deemed necessary</p>
-16:44 < ailouros> I believe my toy, proprely developed into an app, can offer the caching and resiliancy the freenet people try to offer</p>
-16:44 < ailouros> as in static content distribution and caching</p>
-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</p>
-16:45 < ailouros> don't like the content? delete it and we're all set</p>
-16:45 < jrandom> hmm, so do you see it as a backing store that could be used for syndie?  </p>
-16:46 < ailouros> it CAN be used as a backing store</p>
-16:46 < ailouros> as it is now, you might even use it in place of jetty, in i2p default installations</p>
-16:46 < jrandom> e.g. attachments / links to [clunk hash="$foo"]my file[/clunk]</p>
-16:46 < ailouros> (well with a couple of minor changes :D )</p>
-16:46 < jrandom> heh</p>
-16:47 < jrandom> ok, yeah, I definitely don't understand how clunk works... wanna post about it in syndie, or put up an eepsite?  :)</p>
-16:47 < ailouros> file hashes are downloaded on file request, and these hashes are automagically downloaded into the full file</p>
-16:48 < jrandom> right, but "down"loaded is a question of from where to where, etc.  an overal network architecture description would be helpful</p>
-16:48 < ailouros> I'll write a decent doc first, then publish it somewhere</p>
-16:48 < jrandom> r0x0r, thanks</p>
-16:48 < ailouros> downloaded from wherever you got the hash from</p>
-16:48 < ailouros> plus everyone else sharing these blocks</p>
-16:49 < ailouros> think go!zilla and download accellerator :)</p>
-16:49 < jrandom> I think you misunderstand how much I am confused</p>
-16:49 < ailouros> but transparent and within i2p</p>
-16:49 < ailouros> lol guess so :D</p>
-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</p>
-16:50 < jrandom> do I use a web browser to query a clunk client?  or server?  or peer?</p>
-16:51 < jrandom> (thats how lost I am)</p>
-16:51 < ailouros> redo from 0 :)</p>
-16:51 < ailouros> you use your web browser</p>
-16:51 < ailouros> you connect to your client</p>
-16:51 < ailouros> you browse others' dir with your browser</p>
-16:51 < ailouros> you select which files to download with your browser</p>
-16:51 < ailouros> your client does the dirty work</p>
-16:52 < ailouros> you get the downloaded file back</p>
-16:52 < ailouros> is this better? :)</p>
-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</p>
-16:52 < ailouros> exactly</p>
-16:52 < jrandom> (or pulled from some server/superpeer/etc)</p>
-16:53 < jrandom> coo'</p>
-16:53 < ailouros> all the dirty work (finding duplicates, multidownloads and so on) is done by your (local) client transparently</p>
-16:54 < ailouros> what you see is, basically, a directory tree and some fiels you can download</p>
-16:54 < jrandom> cool</p>
-16:55 < ailouros> to publish your data you give away your public (p2p) address</p>
-16:55 < ailouros> and to share files you copy them (or symlink them) to the pub/ directory (or some subdir). It's that easy</p>
-16:57  * jrandom will dig through the source further, and look forward to more info :)</p>
-16:57 < jrandom> ok, anyone else have anything for the meeting?</p>
-16:57 < bar_> umm.. what's the difference between publishing and sharing, if i may ask? does publishing push the data to some datastore?</p>
-16:58 < ailouros> bar_: sharing is giving the blocks to download. publishing is letting the world know what you share</p>
-16:58 < ailouros> publishing is a subset of sharing</p>
-16:58 < bar_> aha, gotcha, thanks</p>
-16:58 < ailouros> for example, if you have half of a file, you share it but don't publish it</p>
-16:59 < jrandom> how would people know they ould get those blocks from you then?</p>
-16:59 < ailouros> and you have full control over which files you publish (unlike emule where every downloaded file is published)</p>
-16:59 < ailouros> because each client periodically sends information to the network about which blocks he has to offer</p>
-17:00 < jrandom> coo'</p>
-17:00 < ailouros> sends to the network as in server (as is now) or DHT (future)</p>
-17:00 < jrandom> so its mnet-esque, with a block tracker</p>
-17:00 < ailouros> err mnet-esque?</p>
-17:01 < jrandom> similar to how mnet (mnetproject.org) works</p>
-17:01  * ailouros is reading mnetproject.org</p>
-17:02 < ailouros> well, you have just your personal spaces, no shared spaces</p>
-17:02 < ailouros> and you don't PUSH blocks around</p>
-17:02 < jrandom> yeah, its not exactly the same as mnet, but it similar structurally</p>
-17:03 < jrandom> its like mnet where everyone is too broke to have anyone host their data ;)</p>
-17:03 < ailouros> yep</p>
-17:03 < ailouros> :D</p>
-17:03 < jrandom> ok, anyone else have anything else to bring up?</p>
-17:04 < jrandom> if not...</p>
-17:04  * jrandom winds up</p>
-17:04  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/159.rst b/i2p2www/meetings/159.rst
new file mode 100644
index 00000000..96e9e5cc
--- /dev/null
+++ b/i2p2www/meetings/159.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 6, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/160.log b/i2p2www/meetings/160.log
index afd55b92..f4b2618a 100644
--- a/i2p2www/meetings/160.log
+++ b/i2p2www/meetings/160.log
@@ -1,55 +1,49 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 160{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 13, 2005</h3>
-<div class="irclog">
-15:15 < jrandom> 0) hi</p>
-15:15 < jrandom> 1) Net status and load testing</p>
-15:15 < jrandom> 2) I2PSnark</p>
-15:15 < jrandom> 3) Syndie</p>
-15:15 < jrandom> 4) ???</p>
-15:15 < jrandom> 0) hi</p>
-15:15  * jrandom waves</p>
-15:15 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2005-December/001239.html</p>
-15:15 < jrandom> (*before* the meeting this week - who woulda thunk it?)</p>
-15:16 < jrandom> not that it matters, since y'all wait until the meeting starts to read it anyway ;)</p>
-15:16 < jrandom> so, movin' on in to 1) Net status and load testing</p>
-15:16 <@cervantes> hey!</p>
-15:17 < jrandom> thanks for doing your part cervantes ;)</p>
-15:17 <@cervantes> read what?</p>
-15:17 -!- DreamTheaterFan [anonymous@irc2p] has quit [Connection reset by peer]</p>
-15:17 < jrandom> I don't have much to add beyond whats in the mail, anyone have any questions or comments on 1)?</p>
-15:19 < spaetz> is load testing performed on *the* i2p net or do you have a private net for this?</p>
-15:19 < jrandom> I'm doing it on the live net</p>
-15:19 < spaetz> just curious</p>
-15:19 < spaetz> k</p>
-15:20 < jrandom> its being done carefully though, backing off hard from peers under load, and it of course honors tunnel rejections</p>
-15:20 <@cervantes> recent irc2p instability was unrelated to the tests</p>
-15:21 <@cervantes> (in case you were wondering)</p>
-15:21 < jrandom> hows the new setup handling things cervantes?  </p>
-15:21 <@cervantes> been rock solid so far</p>
-15:22 < jrandom> cool</p>
-15:22 <@cervantes> just took some tedium to track down the source of the gremlins</p>
-15:24 < jrandom> ok, anyone else have any questions/omments, or shall we jump on over to 2) I2PSnark?</p>
-15:25 < jrandom> consider us jumped</p>
-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</p>
-15:26 < jrandom> i2psnark now works with all of the torrents i've tested, but if anyone runs into trouble, let me know</p>
-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</p>
-15:28 < jrandom> not much more to add on that front... unless anyone has any questions, lets move on over to 3) Syndie</p>
-15:29 -!- Xunk [Xunk@irc2p] has quit [Connection reset by peer]</p>
-15:30 < jrandom> ok, I don't have much to add beyond the email on that front either</p>
-15:31 -!- Xunk [Xunk@irc2p] has joined #i2p</p>
-15:31 < jrandom> if there aren't any questions re: Syndie, lets continue on and open the floor with 4) ???</p>
-15:31 -!- DreamTheaterFan [anonymous@irc2p] has joined #i2p</p>
-15:32  * jrandom remembers that clunk wasn't in the agenda, among other things.  anyone have anything they want to bring up?</p>
-15:32 <@cervantes> man speeding though</p>
-15:32 <@cervantes> *through</p>
-15:33 -!- bar [bar@irc2p] has quit [Connection reset by peer]</p>
-15:33 < jrandom> aye, no need to talk just to see words on the meeting logs :)</p>
-15:33 -!- bar [bar@irc2p] has joined #i2p</p>
-15:33 -!- mode/#i2p [+v bar] by chanserv</p>
-15:33 -!- mule [mule@irc2p] has joined #i2p</p>
-15:35 < jrandom> ok, if there's nothing else...</p>
-15:35  * jrandom winds up</p>
-15:35  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/160.rst b/i2p2www/meetings/160.rst
new file mode 100644
index 00000000..e77de58c
--- /dev/null
+++ b/i2p2www/meetings/160.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 13, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/161.log b/i2p2www/meetings/161.log
index 1d57559c..76379d8e 100644
--- a/i2p2www/meetings/161.log
+++ b/i2p2www/meetings/161.log
@@ -1,122 +1,116 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 161{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 20, 2005</h3>
-<div class="irclog">
-15:20 < jrandom> 0) hi</p>
-15:20 < jrandom> 1) Net status</p>
-15:20 < jrandom> 2) I2PSnark updates</p>
-15:20 < jrandom> 3) Syndie blog UI</p>
-15:20 < jrandom> 4) ???</p>
-15:20 < jrandom> 0) hi</p>
-15:20  * jrandom waves</p>
-15:20 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2005-December/001240.html</p>
-15:22 < jrandom> ok, jumping on in to 1) Net status</p>
-15:22 < jrandom> I don't have much to add beyond whats in the status notes.</p>
-15:22 <+Complication> If it weren't for the occasional OOM's, I'd dare call it good</p>
-15:22 < jrandom> the load testing is looking quite promising, suggesting that we have a lot of room to improve performance</p>
-15:23 <+Complication> And I guess the OOM</p>
-15:23 < jrandom> heh, i2psnark related OOMs?  or from before that?</p>
-15:23 <+Complication> 's contribute to flakyness, when either i2p-bt, i2psnark, or i2p-rufus  instances do... things.</p>
-15:24 < zzz> my theory is that increased torrent traffic is somewhat hurting IRC reliability</p>
-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)</p>
-15:24 < jrandom> hmm, I'm not sure, as the irc status was similar to before the latest snark updates</p>
-15:25 <+Complication> Bandwidth has been solid, part. tunnels solid too... just crashing now and then</p>
-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</p>
-15:26 <+Complication> For known reasons, which hopefully go away when their time comes :)</p>
-15:26 < jrandom> aye, I think so too zzz, so we'll probably have a release in the next day or so</p>
-15:26 <+legion> Well irc might just be too sensitive, maybe just using something like jabber would be better?</p>
-15:26 < zzz> especially for people on slower machines and/or connections</p>
-15:27 < jrandom> jabber would not change things</p>
-15:27 <+Complication> Especially with tunnel redundancy at 2</p>
-15:28 <+bar> i'd say irc is an excellent crap-o-meter for determining the network weather</p>
-15:28 <+legion> Yeah, the wind just blows a little and irc craps out</p>
-15:28 <+bar> exactly :)</p>
-15:28 <+Complication> I notice that after the shitlisting fix, "Recent" tends to always exceed "Known"</p>
-15:29 <+Complication> Would this be because "Known" doesn't include shitlisted peers, while "Recent" does?</p>
-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)</p>
-15:30 < jrandom> hmm, that makes sense Complication </p>
-15:30 <+Complication> (I'm not sure if it does, just guessing)</p>
-15:30 < jrandom> (as shitlisted peers are dropped from the netDb, but their profiles are not removed)</p>
-15:32 <+Complication> Then the indicators seem OK (just wanted to ask in case they wouldn't)</p>
-15:33 < jrandom> ok, anything else on 1) Net status?</p>
-15:33 < jrandom> if not, lets move on over to 2) I2PSnark updates</p>
-15:33 < tealc_>  what sort of updates are available?</p>
-15:34 < jrandom> see http://dev.i2p.net/pipermail/i2p/2005-December/001240.html for a brief listing ;)</p>
-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</p>
-15:35 < tealc_> i'm running of the latest cvs builds and i2psnark is causing a lot of memory heap errors or whatever</p>
-15:35 <+Complication> ...and it also handles Azureus-created torrents with odd meta-tags.</p>
-15:35 <+Complication> Which it previously got stuck on.</p>
-15:35 < jrandom> ah, yeah, there are still some things I'm debugging in there tealc_ </p>
-15:35 < jrandom> (as mentioned in the weekly status notes ;)</p>
-15:35 < jrandom> ah right Complication </p>
-15:36 < jrandom> oh, also, the Azureus folks have fixed a bug in their tracker that would keep I2PSnark from using it</p>
-15:36 < jrandom> (so people running azureus trackers prior to B16 should upgrade at their earliest convenience)</p>
-15:37 <+bar> i'd like to have the possibility to easily disable the i2psnark autostart (for low bw scenarios, etc.)</p>
-15:38 < jrandom> that should be easy enough to add in</p>
-15:38 <+bar> sounds great</p>
-15:39 < jrandom> ok, anything else on 2) I2PSnark updates?  </p>
-15:40 < jrandom> if not, lets move on to 3) Syndie blog UI</p>
-15:40 < zzz> two thumbs up on the new i2psnark - good job</p>
-15:41 < jrandom> gracias, mjw did the hard work, making snark so easy to extend</p>
-15:41 < jrandom> ok, as mentioned in the status notes, syndie now has a new blog UI</p>
-15:42 < jrandom> I think it'll offer a balance between whitelists and blacklists, dealing with the different spam issues available to people</p>
-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</p>
-15:43 <+legion> Is spam really going to become much of a problem anytime soon?</p>
-15:44 <+Complication> legion: as someone was kindly willing to demonstrate, it could be</p>
-15:44 < jrandom> nah, blacklists take care of authors who flood, and whitelists take care of spammers who create lots of authors</p>
-15:44 < dust> (anonymity brings out the worst in a some people)</p>
-15:44 < jrandom> (so spamming is not a problem)</p>
-15:45 <+Complication> (Although I think the fellow was regenerating keys to avoid perma-blacklisting, which *is* somewhat of a slow-down.)</p>
-15:45 <+Complication> Although not a big slow-down, and thus I whole-heartedly agree that whitelists are good too. :)</p>
-15:46 <+bar> perhaps some hashcash solution could be feasible down the road, if necessary</p>
-15:46 < jrandom> if necessary, but I don't see why it would be</p>
-15:46 <+bar> agree, right now, i don't either</p>
-15:46 <+Complication> bar: like "don't show unless they've bothered to crunch some numbers"?</p>
-15:47 <+bar> yes, something along that line</p>
-15:47 <+Complication> Sounds possible, even if probably needless.</p>
-15:47 <+bar> probably so.</p>
-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</p>
-15:47 <+Complication> Or more like, hopefully needless.</p>
-15:48 <+Complication> Might be good to consider if Syndie can accommodate such functionality, should need ever arise.</p>
-15:49 < jrandom> aye, it can, with headers in the blog post or in the blog's own metainfo</p>
-15:49 < jrandom> er, metadata (damn you bt!)</p>
-15:51 < jrandom> ok, if there's nothing else on 3) Syndie, lets jump on to 4) ???</p>
-15:51 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-15:51 <+legion> yes a couple things</p>
-15:52 <+legion> first clunk</p>
-15:52 < jrandom> cool, yeah clunk sounds interesting</p>
-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.</p>
-15:53 <+legion> So far just the client is broken, the rest including the server compiles and seems to work</p>
-15:53 < jrandom> neat</p>
-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</p>
-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.</p>
-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.</p>
-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.)</p>
-15:57 < tethra> </$0.02></p>
-15:58 <+polecat> That would be a primitive example of my trust network idea, with a heuristic of 100% trust transfer, yes.</p>
-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?</p>
-15:59 < jrandom> aye, there is a lot of room for integration of trust metrics into syndie</p>
-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.</p>
-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.</p>
-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</p>
-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</p>
-16:06 <+legion> So I would recommend only using known clients which don't leak, such as jeti.</p>
-16:07 < zzz> could you add a verified-doesn't-leak column to your client chart?</p>
-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)</p>
-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.</p>
-16:09 < jrandom> that the developer said it may be certain, but what the developer understands about anonymity is another question ;)</p>
-16:09 <+legion> Yeah zzz I could add another such column</p>
-16:09 < jrandom> I don't doubt the possibility that jeti behaves properly, but we need to know what that means</p>
-16:10 < zzz> seems like non-leakage can only be verified by protocol tracing</p>
-16:10 < zzz> not by looking at source or asking developer</p>
-16:12 < jrandom> ok, does anyone have anything else for the meeting?</p>
-16:12 <+bar> just a reminder not to forget amd64 jbigi</p>
-16:13 <+bar> (but i bet it's on your todo list)</p>
-16:13 < jrandom> aye :)</p>
-16:13 < jrandom> (win amd64, that is, linux amd64 is already working)</p>
-16:13 < jrandom> but, if there's nothing else...</p>
-16:14  * jrandom winds up</p>
-16:14 <+bar> yes, win amd64.</p>
-16:14  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/161.rst b/i2p2www/meetings/161.rst
new file mode 100644
index 00000000..3519ccf2
--- /dev/null
+++ b/i2p2www/meetings/161.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 20, 2005
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/162.log b/i2p2www/meetings/162.log
index f1658f1b..0b008445 100644
--- a/i2p2www/meetings/162.log
+++ b/i2p2www/meetings/162.log
@@ -1,93 +1,87 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 162{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 4, 2006</h3>
-<div class="irclog">
-15:22 < jrandom> 0) hi</p>
-15:22 < jrandom> 1) Net status and 0.6.1.8</p>
-15:22 < jrandom> 2) Load testing results and peer profiling</p>
-15:22 <@cervantes> jrandom: arguably the slowest most horrific punishment since they banned stoning</p>
-15:22 < jrandom> 3) 2005 review / 2006 preview / ???</p>
-15:22 < jrandom> 0) hi</p>
-15:22 < gott>   falafel</p>
-15:22 < gott>        n : small croquette of mashed chick peas or fava beans seasoned</p>
-15:22 < gott>            with sesame seeds</p>
-15:22 <@cervantes> hullo</p>
-15:22  * jrandom waves after recovering from the falafel pelting</p>
-15:22 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001246.html</p>
-15:23 < jrandom> as I'm 10m late, I'm sure y'all have already read those notes and have comments ready</p>
-15:23 < jrandom> *cough*</p>
-15:23 < jrandom> ok, lets jump on in to 1) net status and 0.6.1.8</p>
-15:24 <@cervantes> ie. it works well, except protocol is slowing it down</p>
-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</p>
-15:25 < jrandom> heh yeah, I'm not sure if infoshop has posted anything since the last rss import</p>
-15:25 < JosephLeBlanc> Hmm, well I have just a couple of comments.</p>
-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.</p>
-15:26 <+Complication> Lets me extensively browse eepsites, and only rarely kicks me from IRC.</p>
-15:26 < jrandom> word Complication </p>
-15:26 < jrandom> whats up JosephLeBlanc </p>
-15:26 <@cervantes>  /kick complication</p>
-15:26 <@cervantes> doh</p>
-15:26 < JosephLeBlanc> I am running the latest CVS and, afaics, most things are in order.</p>
-15:27 < JosephLeBlanc> However, I was wondering if that jbigi athlon problem was fixed which I talked to you about some time ago.</p>
-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</p>
-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).</p>
-15:29 < JosephLeBlanc> Well, the logs are returning: 'NOTICE: Resource name [jbigi] was not found' </p>
-15:30 < jrandom> JosephLeBlanc: there is a line after that regarding jbigi - what does it say?</p>
-15:31 < JosephLeBlanc> It reads, "INFO: Optimized native BigInteger library 'libjbigi-linux-athlon.so' loaded from resource</p>
-15:31 < jrandom> ok great</p>
-15:32 < JosephLeBlanc> Just wanted to give you a heads up about that NOTICE line.</p>
-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)</p>
-15:32 < jrandom> it then tries to pull the OS/architecture specific resource "libjbigi-linux-athlon.so" and succeeds</p>
-15:33 < JosephLeBlanc> Ah, okay. Then, it seems that whatever bug I was experiencing earlier has been fixed in -7</p>
-15:33 < jrandom> w3wt</p>
-15:33 < JosephLeBlanc> Thanks a billion, bud.</p>
-15:34 < jrandom> np</p>
-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</p>
-15:35 < jrandom> ok, anyone else have something for 1) net status / 0.6.1.8?</p>
-15:37 < jrandom> if not, lets move on to 2) Load testing results and peer profiling</p>
-15:39 < jrandom> ok, lots of stuff in the email, does anyone have any questions on it?</p>
-15:40 <+bar> how big was the resonable improvement?</p>
-15:41 <+Complication> Late remark about 0.6.1.8 (just tested with my laptop) - jbigi was loaded correctly there too.</p>
-15:42 <+Complication> Previously, this machine (Mandriva 2005) was failing to load the correct one.</p>
-15:42 <+Complication> Due to the jcpuid problem.</p>
-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.</p>
-15:43 < jrandom> (and the load test is a bit contrived)</p>
-15:43 <+bar> alrighty np :)</p>
-15:44 < jrandom> cool complication.  Yeah, I finally bundled up scintilla's C jcpuid port :)</p>
-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.</p>
-15:47 < jrandom> if there's nothing else on that, jumping on to 3) 2005 review / 2006 preview / ???</p>
-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</p>
-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.  </p>
-15:50  * tethra came in towards the wrong end of 2005, but it was still pretty damn cool. *thumbs up*</p>
-15:51 <+Complication> Hoping for the best.</p>
-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</p>
-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?</p>
-15:52 <+Complication> e.g. which parts are liable to change heavily, or such matters</p>
-15:53 <+Complication> Also, in which format would it be best to have various docs?</p>
-15:54 < jrandom> the tech intro doc @ dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/doc/techintro.html?rev=HEAD is fairly stable</p>
-15:54 <+Complication> Included with the router... on the website... both?</p>
-15:54 < jrandom> (there will be updates on 0.6.2 though)</p>
-15:54 < jrandom> well, I'm hugely in favor of inline documentation</p>
-15:54 < jrandom> but that should probably wait until the new router console is in place</p>
-15:55 < jrandom> website intro docs would be good as well, but that should probably wait until the new website is in place</p>
-15:55 <+Complication> Aha... so it would be best to not touch that yet...</p>
-15:56 <+Complication> ...instead preferring docs like the above.</p>
-15:58 < jrandom> probably.  ok, is there anything else people want to bring up for the meeting?</p>
-15:59 < jrandom> if not...</p>
-15:59 < tethra> did we discuss the eepget UI idea yet?</p>
-15:59 < gott> If the meeting is still on, please fix the trouble with accents in IRCclient</p>
-15:59 < tethra> ie, before i got here</p>
-15:59 < jrandom> nope, wanna implement it tethra?  :)</p>
-15:59 < jrandom> gott: patches welcome</p>
-16:00 < gott> If not, please fix the trouble with accents in IRCclient.</p>
-16:00 < gott> jrandom: By the time, I fix it, it will be fixed by somebody else ;-)</p>
-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.</p>
-16:01 < gott> I reserve the right to be defeatist in deed and action.</p>
-16:01 < tethra> haha</p>
-16:01 <+Complication> :)</p>
-16:02 < jrandom> tethra: the oreily servlets books are pretty good</p>
-16:02 < jrandom> ok, if there's nothing else...</p>
-16:02  * jrandom winds up</p>
-16:02  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/162.rst b/i2p2www/meetings/162.rst
new file mode 100644
index 00000000..4778e387
--- /dev/null
+++ b/i2p2www/meetings/162.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 4, 2006
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/163.log b/i2p2www/meetings/163.log
index 733b9c4f..c3c1ed4d 100644
--- a/i2p2www/meetings/163.log
+++ b/i2p2www/meetings/163.log
@@ -1,176 +1,170 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 163{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 10, 2006</h3>
-<div class="irclog">
-15:26 < jrandom> 0) hi</p>
-15:26 < jrandom> 1) Net status</p>
-15:26 < jrandom> 2) Throughput profiling</p>
-15:26 < jrandom> 3) Syndie blogs</p>
-15:26 < jrandom> 4) HTTP persistent connections</p>
-15:26 < jrandom> 5) I2Phex gwebcache</p>
-15:26 < jrandom> 6) ???</p>
-15:26  * jrandom waves</p>
-15:26 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001247.html</p>
-15:27 < jrandom> (yeah, I know... we need a 7) One more thing...)</p>
-15:28 < jrandom> jumping on in to 1) Net status </p>
-15:28 < jrandom> In general, seems the same ol' same ol', beyond whats in the mail.  </p>
-15:28 < jrandom> Anyone have anything they want to bring up about 1)?</p>
-15:30 < jrandom> ok, if not, moving on over to 2) Throughput profiling</p>
-15:31 < tethra> it sounds cool, but may i ask what the objective is?</p>
-15:31 < jrandom> find fast peers</p>
-15:31 < tethra> (forgive my lack of wit and tact)</p>
-15:31 < tethra> ah, cool.</p>
-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</p>
-15:32 < jrandom> (I know they're fast because I've cheated and measured them with non-anonymous techniques)</p>
-15:33 < tethra> shocking! ;)</p>
-15:33 < jrandom> ((yes, someone could have been crazy and mounted attacks to confuse my measurements, but, well, I doubt it ;)</p>
-15:33 < tethra> haha</p>
-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?</p>
-15:35 < tethra> s/'good'/fast/</p>
-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</p>
-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</p>
-15:36 < jrandom> e.g. rather than having $slow-->$fast-->$fast, it'll have $fast-->$fast-->$fast</p>
-15:36 < tethra> ah, i see</p>
-15:36 < jrandom> aye cervantes, I've been paying attention to the capacity profile as well, and its been doing the trick</p>
-15:36 <@cervantes> grand</p>
-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</p>
-15:37 <@cervantes> be interesting to see how it effects througput</p>
-15:37 < jrandom> (which is why 'fast' is just shorthand for 'fast and high capacity')</p>
-15:37 <@cervantes> +h</p>
-15:37 < jrandom> aye cervantes</p>
-15:39 < jrandom> ok, if there's nothing else on 2, lets jump on over to 3) Syndie blogs</p>
-15:40 < jrandom> I don't have much more to add beyond whats in the mail there</p>
-15:41 <@cervantes> it's looking swell</p>
-15:41 < tethra> i very much like where the blogs are going, personally. it seems to all be gravy, one might say.</p>
-15:41 < tethra> :D</p>
-15:41 <+Complication> Bit late, sorry.</p>
-15:42 < jrandom> cool, its similar to how it was originally, but I think the blog view has some promise</p>
-15:42 < jrandom> wb Complication, no worry, we've got logs :)</p>
-15:43 <+Complication> Reading scrollback right now :)</p>
-15:43 < jrandom> I do think there's a place for both views, I suppose it just depends on the user</p>
-15:43 < jrandom> (and the content, and the author)</p>
-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</p>
-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</p>
-15:47 <@cervantes> other than having 2 opening <style> tags the code looks pretty clean ;-)</p>
-15:47 < jrandom> heh oops</p>
-15:48 <@cervantes> I think the emphasis will be on getting the styling clean and readable and perhaps designing some template alternatives</p>
-15:48 < jrandom> hmm</p>
-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</p>
-15:50 < jrandom> otoh, the blog view, like the thread view, is all just a template over the syndie archive</p>
-15:50 <@cervantes> well you certainly don't want to allow deployable templates</p>
-15:50 < jrandom> so the question is, a template for whom?</p>
-15:50 < jrandom> (what level of experience would those using the template require)</p>
-15:51 <@cervantes> I was thinking just a popup config option someone can choose for their blog</p>
-15:51 < jrandom> hmm?</p>
-15:51 <@cervantes> I want "Pony Look"</p>
-15:51 < jrandom> ah, ok</p>
-15:51 <@cervantes> so we ship syndie with a variety of skins</p>
-15:52 < jrandom> yeah, preset colors/font/etc</p>
-15:52 < jrandom> (and icons, etc)</p>
-15:52 < jrandom> thats one thing that hasn't really been implemented through the blog view yet</p>
-15:54 < jrandom> good idea on the simple theme chooser though, rather than some complex set of options</p>
-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</p>
-15:55 <@cervantes> it's up to the individual if they want to trust the blog author's custom skin</p>
-15:55 < jrandom> ... trust?</p>
-15:55 < jrandom> nothing in syndie will let you do unsafe html or css</p>
-15:55 < tethra> what of unsafe javascript/etc</p>
-15:55 < jrandom> the skins would be text files/config files/images, rather than jsp</p>
-15:55 < tethra> ?</p>
-15:56 < tethra> (page forwards to non-anonymous addresses with js, for instance?)</p>
-15:56 <@cervantes> it depends if a theme might also contain structural html changes </p>
-15:56 <@cervantes> right ok</p>
-15:56 <@cervantes> well that would keep it nice an clean and simple</p>
-15:57 < jrandom> tethra: I'm... incredibly hesitant about javascript.  seen that new blog post today from default?</p>
-15:57 < jrandom> "I'm just curious: does it use AJAX? The page doesn't seem to update as a whole..."</p>
-15:57 < tethra> nein, i did not.</p>
-15:57 < tethra> i'd find a way to just shag any js that is used, personally.</p>
-15:58 < jrandom> since syndie is *local*, its insanely fast, and we don't need do worry about the same latency issues</p>
-15:58 < tethra> as i don't trust it as far as i can throw it.</p>
-15:58 < tethra> hmm :/</p>
-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"</p>
-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</p>
-16:00 < jrandom> heh</p>
-16:00 < jrandom> (and you've got all those accessibility issues of javascript)</p>
-16:00 <+Complication> cervantes: mind you, alert() in an infinite loop can be bad :P</p>
-16:00  * jrandom is quite proud of syndie's lynx-friendliness</p>
-16:00 < tethra> lynx <3</p>
-16:02 < jrandom> ok, if there's nothing else on 3), lets jump on over to 4) HTTP persistent connections</p>
-16:02 < jrandom> I don't have anything to add beyond whats in the mail... zzz, you here?</p>
-16:02 <@cervantes> there are other ways of implementing a *spit* AJAX ui, like a mozilla extension</p>
-16:03 < jrandom> fire2pe++ :)</p>
-16:03 < jrandom> zzz doesn't seem to be around, so we'll probably have to wait for later for more info on 4)</p>
-16:03 <@cervantes> fire2pe is just a helper - syndilla is what you mean ;-)</p>
-16:03 < jrandom> lol</p>
-16:04 < jrandom> (and, the usb keychain version, syndog ;)</p>
-16:04 < jrandom> ok, moving on to 5) I2Phex gwebcache</p>
-16:05 < jrandom> Complication: p1ng</p>
-16:05 <+Complication> Well, since it would make integrating with the net easier...</p>
-16:06 <+Complication> ...I've recently worked on reviving the gwebcache code already in I2Phex</p>
-16:06 <+Complication> It's already doing some very limited things (like crash neatly) at this stage :)</p>
-16:06 <+Complication> Also pesters awup's webcache server with moderate success</p>
-16:07 < jrandom> lol nice</p>
-16:07 <+Complication> I have hope though, that eventually I'll get it reworked</p>
-16:07 <+Complication> (lots of it is currently meant to deal with IP addresses)</p>
-16:09 < jrandom> cool, good luck, and lemmie know if there's anything I can do to help</p>
-16:09 <+Complication> Will do :)</p>
-16:10 < jrandom> ok, anything else on 5) I2Phex gwebcache, or shall we mosey on over to 6) ???</p>
-16:11 < jrandom> consider us moseyed</p>
-16:11 < jrandom> anyone have anything else for the meeting?</p>
-16:11 <@cervantes> another cup of tea would be nice</p>
-16:12 < tethra> heheh</p>
-16:12 < Pseudonym> how's the roadmap?</p>
-16:12 < jrandom> no changes</p>
-16:12 < Pseudonym> what's left for 0.6.2?</p>
-16:13 < jrandom> all of the 0.6.2-related stuff</p>
-16:13  * jrandom ducks</p>
-16:14 < Pseudonym> :-P</p>
-16:14 <@cervantes> some bling bling</p>
-16:14 < Pseudonym> do we have a tentative date/timeline?</p>
-16:14 < jrandom> specifically, the new tunnel creation crypto and algorithms, the new peer selection strategies</p>
-16:14 < tethra> heheh</p>
-16:14 < jrandom> no dates and timelines (at least, not announced in meetings ;)</p>
-16:15 < Pseudonym> is there more to peer selection strategies than the throughput stuff you've been working on?</p>
-16:16 < jrandom> yes, these peer profiling changes are performance issues, not the anonymity related peer selection and ordering strategies</p>
-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?</p>
-16:17 < jrandom> yeah Complication </p>
-16:17 <+Complication> s/related/relates</p>
-16:19 <+Complication> You're going to try making that fancy lil' datastructure work?</p>
-16:19 < jrandom> aye</p>
-16:20 < jrandom> (hence, 0.6.2 is not on the 2 week horizon ;)</p>
-16:20 <+Complication> Neat. Sounds interesting, I should probably read up about it</p>
-16:21 <+Complication> I hope it goes smoothly</p>
-16:21 < jrandom> it was only arm-waved around on the list, no spec digitized yet</p>
-16:21 < tethra> which neat datastructure is this, sorry?</p>
-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)</p>
-16:21 < jrandom> it'll be backwards incompatible, so smooth won't be its catchphrase, but hopefully won't hurt too much :)</p>
-16:21 < jrandom> ah bugger</p>
-16:22 < jrandom> tethra: a datastructure that doesn't exist yet for creating tunnels</p>
-16:22 < tethra> cool</p>
-16:22 < jrandom> (see the predecessor threads from november or so)</p>
-16:23 < tethra> what advantages/disadvantages will it have over the current one? (if there is a current one :o)</p>
-16:23 < jrandom> (see the predecessor threads from november or so) ;)</p>
-16:23 < tethra> ah, ok</p>
-16:23 <+Complication> IIRC, to make tunnel creation less transparent to observers</p>
-16:23 < tethra> ""</p>
-16:23 < tethra> ;)</p>
-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.</p>
-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.</p>
-16:24 < Pseudonym> other than fast peer selection, what's not working?</p>
-16:25 < jrandom> fast peer selection is a part of "good performance"</p>
-16:25 < jrandom> we /do/ have good performance, for an anonymous network, but not good enough to compete with non-anonymous networks</p>
-16:25 < jrandom> to compete, we've got to get better performance *and* provide functionality they can't get elsewhere</p>
-16:26 < jrandom> (anonymity does not sell)</p>
-16:26 < Pseudonym> is there more to it than fast peer selection?</p>
-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.</p>
-16:27 < jrandom> (there have also been countless improvements at different points to improve performance)</p>
-16:27 < jrandom> (see http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/history.txt?rev=HEAD )</p>
-16:28 < Pseudonym> so... release of new peer selection this week? ;-)</p>
-16:28 < teal`c_> i2p feels good</p>
-16:29 < jrandom> Pseudonym: aye, new peer profile algorithm is in cvs and will be deployed this week with 0.6.1.9</p>
-16:30 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:30 < Pseudonym> cool</p>
-16:31 < jrandom> if not...</p>
-16:31  * jrandom winds up</p>
-16:32  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/163.rst b/i2p2www/meetings/163.rst
new file mode 100644
index 00000000..39d7b402
--- /dev/null
+++ b/i2p2www/meetings/163.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 10, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/164.log b/i2p2www/meetings/164.log
index 48f992a8..5be0b576 100644
--- a/i2p2www/meetings/164.log
+++ b/i2p2www/meetings/164.log
@@ -1,267 +1,261 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 164{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 17, 2006</h3>
-<div class="irclog">
-15:40 < jrandom> 0) hi</p>
-15:40 < jrandom> 1) Net status and 0.6.1.9</p>
-15:40 < jrandom> 2) Tunnel creation crypto</p>
-15:40 < jrandom> 3) Syndie blogs</p>
-15:40 < jrandom> 4) ???</p>
-15:40 < jrandom> 0) hi</p>
-15:40  * jrandom waves</p>
-15:40 < jrandom> weekly status notes posted @ http://dev.i2p.net/pipermail/i2p/2006-January/001251.html</p>
-15:41 <@cervantes> pfff, good job i2p is more reliable than NASA</p>
-15:41 < jrandom> heh </p>
-15:41 < tethra> haha</p>
-15:41 < jrandom> (though I am 20 minutes late... ;)</p>
-15:41 < jrandom> anyway, lets jump on in to 1) Net status and 0.6.1.9</p>
-15:42 < wmpq> NSA or NASA, not that diffrent are they?</p>
-15:42 <@cervantes> I said I2P not jrandom ;-)</p>
-15:42 < jrandom> good point cervantes ;)</p>
-15:42 < tethra> don't be silly, jrandom IS i2p! ;D</p>
-15:42 <@cervantes> oh I thought it was a way of thinking</p>
-15:42 < wmpq> [redact]</p>
-15:43 < jrandom> heh well, anyway, 0.6.1.9 is out and about, with 70% of the net upgraded (thanks y'all)</p>
-15:43 < Pseudonym> mmmm, tasty new release</p>
-15:44 <+zzz> client tunnel build success remains < 30%</p>
-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</p>
-15:44 <+zzz> down from ~40%</p>
-15:44 <+Complication> Bandwidth seems normal, a bit higher than on the last CVS before release. Peer counts look a big higher.</p>
-15:45 < jrandom> hmm, yeah, I'm not really worried about that zzz, since its all getting completely reworked for 0.6.2</p>
-15:45 <+zzz> avg BW up from ~12K to ~20K</p>
-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</p>
-15:46 <+Complication> Retransmission percentage (noted 7% on the night of release) has come down to 6 point something</p>
-15:46 < jrandom> aye, with routers pushing 1-300KBps, there's going to be a skew</p>
-15:46 < jrandom> hmm, thats a pretty crazy rate Complication, i've only seen 2-3%</p>
-15:46 < jrandom> (but I don't doubt what you see)</p>
-15:47 <+Complication> I'm maxing out my outbound, pretty much</p>
-15:47 <+Complication> (and I mean maxing out the line capacity)</p>
-15:47 < jrandom> ah, that'd do the trick</p>
-15:47 <+zzz> still getting NULLs before gets which results in 405 bad method, rate may be declining, hard to say for sure</p>
-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</p>
-15:48 < jrandom> (but if someone wants to dig in further before that, that would rule, of course)</p>
-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?</p>
-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 :)</p>
-15:50 <+zzz> First seen Dec. 29</p>
-15:50 < jrandom> yeah zzz, it certainly was.  likely related to how we now honor timeouts.</p>
-15:51 <+Complication> jrandom: I'm actually trying that currently :)</p>
-15:51 <+Complication> Adjusted a few seconds before you asked, but won't know very soon, I guess</p>
-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)</p>
-15:51 < jrandom> cool Complication, yeah, give it 3-6 hours </p>
-15:51 < jrandom> (to clear out the old values / connections)</p>
-15:52 <+zzz> ~ 1% - 3% of GETs are corrupted atm</p>
-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?</p>
-15:55 <+zzz> certainly don't revert</p>
-15:56 <+zzz> your call</p>
-15:56 <+Complication> It's a fairly sly bug, I can only say</p>
-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).  </p>
-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</p>
-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.</p>
-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</p>
-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 ;)</p>
-16:01 <+Complication> That's what the rate is like, here too</p>
-16:02 <+Complication> (on my eepsite)</p>
-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)</p>
-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!)</p>
-16:06 <+Complication> jrandom: out of curiosity, could one exclude i2ptunnel with a test app?</p>
-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?</p>
-16:07 < jrandom> one could wire up a thin (in-VM) I2PSocket implementation to do that, certainly </p>
-16:07 <+Complication> Since, IIRC, that sample used the streaming lib directly...</p>
-16:08 <+Complication> (or pretty directly)</p>
-16:08 < jrandom> aye, of course if something using the streaming lib can duplicate it, it would exonerate i2ptunnel</p>
-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...</p>
-16:10 < jrandom> wikked, thanks Complication</p>
-16:10 < jrandom> ok, anything else on 1) Net status and 0.6.1.9?  </p>
-16:11 < jrandom> if not, lets mosey on over to 2) Tunnel creation crypto</p>
-16:11 <+Complication> Nah, it may lead to nothing useful, or I may stumble on halfway... but it's a possibility which intrigues me</p>
-16:11 < jrandom> aye, definitely worth exploring Complication</p>
-16:12 < jrandom> (and explorations do not have to have positive results to be worthwhile :)</p>
-16:12  * cervantes spots a "moo" exception in the source changes leading up to new year....perhaps that's the issue? :)</p>
-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</p>
-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</p>
-16:14 <+Complication> Is "moo" a reserved word for Java? ;P</p>
-16:14 <+zzz> on 2) I'll help review references in status mail</p>
-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...</p>
-16:14 < jrandom> thanks zzz</p>
-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?"</p>
-16:15 < jrandom> Complication: yes</p>
-16:15 <+Complication> Or is my rephrase plain wrong?</p>
-16:16 <+fox> <jme___> and way to complicated, if i may</p>
-16:16 < jrandom> its correct I believe, but yeah, too many clauses :)</p>
-16:16 <+Complication> I didn't think of a better way to visualize it. 'Twas hard enough that way. :P</p>
-16:16 < jrandom> (or jme___ are you saying the algorithm is too complicated?)</p>
-16:17 <+fox> <jme___> nope i tried rapidely to read the doc and give up as too many things require prior knowledge</p>
-16:17 <+fox> <jme___> on the other hand i didnt try much :) other things to do</p>
-16:17 < jrandom> Complication: http://dev.i2p.net/cgi-bin/cvsweb.cgi/i2p/router/java/src/net/i2p/router/tunnel/BuildMessageProcessor.java?rev=HEAD</p>
-16:18 <+fox> <jme___> is this peer review a formality, or you are really worried/unsure of it ?</p>
-16:19 <+Complication> Well, it's always good to know what an underlying mechanism is doing...</p>
-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</p>
-16:19 <+fox> <jme___> if the second i could spend the time, but my knowledge is old and not on top of my head</p>
-16:20 <+fox> <jme___> if not i trust :)</p>
-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 </p>
-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 </p>
-16:22 <@cervantes> jrandom: on those, would there be much of a performance hit on injecting a random delay between hops?</p>
-16:22 <@cervantes> as that seems the most sensible option to prevent timing attacks</p>
-16:23 < jrandom> its tunnel creation, so a delay wouldn't hurt, though could cause premature lease set expiration under catastrophic failures</p>
-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</p>
-16:25 <+fox> <jme___> ok rereading it</p>
-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)</p>
-16:27 < jrandom> ok, anything else on 2, or shall we move on to 3) Syndie blogs?</p>
-16:29 < jrandom> (consider us moved)</p>
-16:29 < jrandom> ok, new neat bloggy stuff in syndie, dig in ;)</p>
-16:29 <@cervantes> v.cool</p>
-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</p>
-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 :)</p>
-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)</p>
-16:31 <@cervantes> comments/posts</p>
-16:32 < jrandom> ah, good idea</p>
-16:33 < jrandom> (net.i2p.syndie.sml.BlogPostInfoRenderer method renderLinks(...) :)</p>
-16:34 <@cervantes> *scribble*</p>
-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</p>
-16:36 < jrandom> are there particular customizations you want to be able to do?  if so, lemmie know</p>
-16:37 < DoubtfulSalmon> jrandom: updating existing content via script?</p>
-16:37 <@cervantes> archive by date</p>
-16:37 < jrandom> DoubtfulSalmon: via script?</p>
-16:37 < jrandom> cervantes: ah, like a little calendar widget, rather than the "5 older entries" links?</p>
-16:38 <@cervantes> yup</p>
-16:38 < DoubtfulSalmon> jrandom: say I want this file/text to replace that file/text. How do I do that?</p>
-16:38 < jrandom> ok cool, yeah, that should be really easy (if someone whips up the html :)</p>
-16:38 <@cervantes> or more simply "view last month's posts"</p>
-16:39 <@cervantes> jrandom: you just need a 7x6 table with some numbers in it ;-)</p>
-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)</p>
-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</p>
-16:40 < jrandom> (that way, the old content is still there, but people are directed to the new content)</p>
-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.</p>
-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</p>
-16:41 < jrandom> hmm, ok I see what you're saying</p>
-16:42 < jrandom> so, you want the ability to have redirectable links, rather than the existing links to exact versions of content</p>
-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</p>
-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</p>
-16:44 < jrandom> (though thats probably not as seamless)</p>
-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.</p>
-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</p>
-16:45 <+Complication> cervantes: oddity of the day :D Last post in: http://forum.i2p/viewtopic.php?t=1199&start=15</p>
-16:46 <+Complication> Felt like it might be another of our robotic overlords :P</p>
-16:46 < jrandom> but its a good idea to support both concepts, and I don't think it'd be much trouble</p>
-16:46 <@cervantes> thnx</p>
-16:46 < jrandom> though it'd need a small extension to sml (e.g. [blog bloghash="ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=" bookmark="radar.png"])</p>
-16:47  * cervantes will upgrade forum defenses if we start to get a lot of them</p>
-16:47 <@cervantes> (already know how to stop that one)</p>
-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</p>
-16:47 < jrandom> (which would look at ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c='s current meta post for bookmarks, pulling the exact uri from the one named "radar.png")</p>
-16:48 < DoubtfulSalmon> jrandom: could that be done now with something like: "View most recent one post in tag <weird string>"</p>
-16:48 < jrandom> ah, good point - yes, it could</p>
-16:49 < jrandom> that could even be restricted to "View most recent post by $author with tag $tag"</p>
-16:49 < jrandom> (so other people couldn't spoof it)</p>
-16:49 < DoubtfulSalmon> so maybe just put some sort of UI so the user does not have to see weird tags and what not</p>
-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</p>
-16:50 < DoubtfulSalmon> I assume all of that information can come in URL form.</p>
-16:51 < jrandom> but this is definitely complicated to write the source SML, which is why a GUI to create SML would be useful</p>
-16:51 < jrandom> they're attributes on the SML tags, not URLs</p>
-16:52 <@cervantes> and SML gui will be tricky without javascript</p>
-16:52 < DoubtfulSalmon> but you can bookmark a search result right?</p>
-16:52 < jrandom> what is a search result?</p>
-16:52 < jrandom> and what do you mean by bookmark?</p>
-16:52 <@cervantes> (or a browser extension ;-)</p>
-16:52 < jrandom> oh, browser side bookmarks,  yes</p>
-16:52 <+Complication> A filter result?</p>
-16:53 < jrandom> but those bookmarks are not generally shareable</p>
-16:53 < DoubtfulSalmon> er: a "get most resent 1 post by X with tag Y" </p>
-16:53 < jrandom> (actually, most are, but its not universal, since they're URLs not URIs))</p>
-16:53 < DoubtfulSalmon> yeah, it would be good if other bolgs could link to those too</p>
-16:54 < jrandom> DoubtfulSalmon: they can, with sml</p>
-16:54 < jrandom> [blog tag="Y" bloghash="X"]</p>
-16:54 < DoubtfulSalmon> oh goodie</p>
-16:55 < jrandom> cervantes: javascript, or xul, or java, or some other OS-specific client app</p>
-16:57 <@cervantes> ah cool, so you don't mind a scripting or plugin dependancy</p>
-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 ;)</p>
-16:57 <@cervantes> (as long as it degrades gracefully)</p>
-16:57 < jrandom> cervantes: syndie should be function with lynx, but there's lots of room for rich clients</p>
-16:58 < jrandom> (s/function/functional/)</p>
-16:58 <@cervantes> right..so lynx uses would get an SML reference chart, but nothing more</p>
-16:58 < jrandom> aye, as we have now</p>
-16:58 < jrandom> though perhaps a simplified sml, dunno.</p>
-17:01 <+Complication> jrandom: do you think it might be even remotely plausible... that the null bug might be related to gzip encoding?</p>
-17:01 <+Complication> I was thinking of how to disable gzipping for my eepsite tunnel...</p>
-17:01 <+Complication> Or would that be entirely implausible?</p>
-17:01 <@cervantes> there was some http compressor stuff added just before new year in i2ptunnel</p>
-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</p>
-17:03 <+zzz> it's on the request side where there isn't any compression</p>
-17:03 <+zzz> server won't compess if client set to false</p>
-17:03 <+Complication> zzz: oh, right, I forgot that</p>
-17:04 < jrandom> (but without too much trouble you could add it to I2PTunnelHTTPServer [line 310, etc)</p>
-17:04  * Complication is a fool, and apologizes for that</p>
-17:04 <@cervantes> (or you could use a normal tunnel)</p>
-17:04 <+Complication> Aha, thanks...</p>
-17:05 < jrandom> hmm, though by the time the i2ptunnelhttpserver receives the GET, the null is already there</p>
-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</p>
-17:05 <+Complication> I somehow entirely forgot that gzipping starts when the client and server have *agreed* to do it</p>
-17:05 < jrandom> so it may be on the client side, but definitely not the server side</p>
-17:05 < jrandom> yeah zzz, its pretty insanely fast now :)</p>
-17:05 <+zzz> its on the _request_ side not the _response_ side - could be on either client or server side</p>
-17:06 < jrandom> true</p>
-17:09 < jrandom> ok, anyone else have anything on 3) Syndie blogs?</p>
-17:09 < jrandom> if not, lets jump on to 4) ???</p>
-17:09 < jrandom> anyone have anything else to bring up for the meeting?</p>
-17:10 < cat-a-puss> Complication: Java's gzip stream + I2P tunnels. Does NOT work and it's sun's bug</p>
-17:10 < jrandom> hmm cat-a-puss?  really?</p>
-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</p>
-17:10 < jrandom> nice1 zzz!</p>
-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.</p>
-17:12 < jrandom> hmm I'm out of context, what exactly does not work?  what is sun's bug?  </p>
-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></p>
-17:14 < jrandom> hmm, interesting</p>
-17:15 < jrandom> what tracker?</p>
-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)</p>
-17:16 < dust> for example the  OSDevWithCVS_3E.pdf.torrent</p>
-17:17 < dust> d8:announce540:http://YRgrgTLGnbTq2aZOZDJQ...</p>
-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)</p>
-17:19 < jrandom> ok cool dust, so postman's tracker.  hmm, are you on 0.6.1.9 dust?</p>
-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.</p>
-17:20 < dust> yes</p>
-17:20 < jrandom> cat-a-puss: we've changed things dramatically for compression over i2p in the last year ;)</p>
-17:21 < jrandom> (and I don't personally use 1.5)</p>
-17:21 < jrandom> but we do our own zip encoding explicitly, rather than use their packaged stream (but for anonymity / efficiency reasons, not compatability)</p>
-17:22 <@cervantes> zzz: where exactly in the request does the null happen? right after GET?</p>
-17:22 <+Complication> Before, if I remember</p>
-17:23 <+fox> <lordalbert> hi</p>
-17:23 <+Complication> Sidenote: Celeron 300 shows twice lower retran. percentage than Sempron</p>
-17:23 < jrandom> 'lo lordalbert</p>
-17:23 < jrandom> cool Complication, 2-3% is reasonable (though I'd prefer lower, of course)</p>
-17:23 <@cervantes> would be interesting to fire off a load of HEAD requests or something...</p>
-17:24 < jrandom> yeah, a set of local tests would be great, though iirc Complication tried that a while back with no errors</p>
-17:24 <+fox> <lordalbert> can anyone make a anonymous tracker? I try it but i dont' understand how use the tunnel</p>
-17:24 <+Complication> cervantes: I once tried provoking it, with a recursive wget between my 2 nodes</p>
-17:24 <+Complication> Grew tired before it happened</p>
-17:25 <@cervantes> heh</p>
-17:26 <+fox> <lordalbert> 'lo b0unc3 ;)</p>
-17:26 <+fox> <b0unc3> lordalbert, :D</p>
-17:26 <+Complication> lordalbert: which part would you need advise about?</p>
-17:27 <+Complication> About setting up trackers, I unfortunately don't know.</p>
-17:27 <+Complication> About I2PTunnel, I could try explaining...</p>
-17:27 <+fox> <lordalbert> I have installed BTtracker, and it work perfectly</p>
-17:28 <+Complication> It should also be noted that, for the tracker to *remain* anonymous, it should likely run a pretty careful config</p>
-17:28 <+fox> <lordalbert> now, i'd like anonimise it</p>
-17:28 <+fox> <lordalbert> so</p>
-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</p>
-17:28 <+fox> <lordalbert> i have just made a i2ptunnel</p>
-17:29 < jrandom> (e.g. the bytemonsoon modification that you can find on any of the i2p trackers, or in the cvs)</p>
-17:29 <+fox> <lordalbert> now, i'd like to know how use this tunnel. I have made a tunnel yet</p>
-17:29 < jrandom> ok, anyone have anything else for the meeting?</p>
-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</p>
-17:30 <+fox> <lordalbert> jrandom, what tracker i must use?</p>
-17:31 <+Complication> postman uses a modified version of ByteMonsoon, I think</p>
-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</p>
-17:32 <+fox> <lordalbert> isn't bytemonsoon obsolete?</p>
-17:32 < jrandom> if it works, its not obsolete.  it works</p>
-17:33 <+fox> <lordalbert> ok XD</p>
-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</p>
-17:33 <+Complication> May well be oldish... but definitely works with destkeys instead of IP's...</p>
-17:33 <+Complication> Can't tell about security and leakproofness</p>
-17:34 < jrandom> (it was modified by duck et al for anonymity and security)</p>
-17:34 <+Complication> But it's been up for a while, and seems to manage...</p>
-17:35 < jrandom> ok, if there's nothing else for the meeting...</p>
-17:36  * jrandom winds up</p>
-17:36  * jrandom *baf*S the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/164.rst b/i2p2www/meetings/164.rst
new file mode 100644
index 00000000..5f2bd40a
--- /dev/null
+++ b/i2p2www/meetings/164.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 17, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/165.log b/i2p2www/meetings/165.log
index bcd549cd..475579df 100644
--- a/i2p2www/meetings/165.log
+++ b/i2p2www/meetings/165.log
@@ -1,114 +1,108 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 165{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 24, 2006</h3>
-<div class="irclog">
-15:25 < jrandom> 0) hi</p>
-15:25 < jrandom> 1) Net status</p>
-15:25 < jrandom> 2) New build process</p>
-15:26 < jrandom> 3) ???</p>
-15:26 < jrandom> 0) hi</p>
-15:26  * jrandom waves</p>
-15:26 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-January/001254.html</p>
-15:26 -!- Teal`c [tealc@irc2p] has joined #i2p</p>
-15:26 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
-15:26 < bar> hi</p>
-15:26 < jrandom> lets jump on in to 1) Net status</p>
-15:26 -!- gloin [gloin@irc2p] has joined #i2p</p>
-15:27 < jrandom> I don't have much more to add beyond whats in the mail... anyone have any questions/comments/concerns?</p>
-15:27 <+Complication> Moving to CVS build -6 has been... challenging</p>
-15:28 < jrandom> aye, understandable</p>
-15:28 <+Complication> Net is probably doing fine. It's just my node whcih isn't.</p>
-15:28 <+Complication> =which</p>
-15:28 < bar> it's a rough road, but it's the right road. i'm 100% supportive of this move</p>
-15:29 < jrandom> tunnel building on 2+ hop tunnels is a pain, with nasty failure rates as has been reported</p>
-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.</p>
-15:30 < jrandom> I do wonder whether we'll be able to get it reliable enough prior to that though.  But we'll try</p>
-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</p>
-15:31 < jrandom> so, 1 hop tunnels are fairly reliable on the latest builds, but those who need 2+ hop tunnels should expect... bumps</p>
-15:31 < jrandom> thanks Complication</p>
-15:32 <+Complication> Most of my apps are 2+0..1</p>
-15:32 <+Complication> And the router itself too, if I remember correct</p>
-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</p>
-15:34 < jrandom> (s/short/1hop/)</p>
-15:34 <+Complication> Right, I could probably adjust it to 2+0</p>
-15:34 <+Complication> And have less spectacular effects</p>
-15:35 < jrandom> aye, though that'll still, in effect, turn to 2+/-1, but it'll try its best to stay at 2hops</p>
-15:36 <+Complication> With build -6 too?</p>
-15:36 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
-15:36 < jrandom> no, the current release will fail hard rather than go to fallback tunnels</p>
-15:37 <+Complication> Or is there probability involved, which never quite goes zero?</p>
-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)</p>
-15:37 <+Complication> Saw it once :)</p>
-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)</p>
-15:39 < jrandom> ok, anyone have anything else for 1) Net status?</p>
-15:39 < jrandom> or, I suppose we're already discussing 2) New build process ;)</p>
-15:40 < jrandom> does anyone have anything else to discuss on 2) New build process?</p>
-15:40 <+Complication> Not much here, anymore :D</p>
-15:41 < jrandom> hehe ok, if not, lets shimmy on over to 3) ???</p>
-15:41 < jrandom> anyone have anything else they want to discuss?</p>
-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?</p>
-15:42 < bar> i mean, is there more than one backwards incompatible release planned, until 0.6.2?</p>
-15:42 < jrandom> bar: the hope is to do them all at once</p>
-15:42 < jrandom> (though there may be further ones down the line)</p>
-15:43 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]</p>
-15:43 -!- Complication2 [Complicati@irc2p] has joined #i2p</p>
-15:43 < bar> hmac bug, new crypto and restricted routes at once?</p>
-15:43 < bar> that's a tall order :)</p>
-15:43 < jrandom> restricted routes?</p>
-15:43 < jrandom> the hmac bug "fix" is changing one value ;)</p>
-15:44 < bar> ah :)</p>
-15:44 -!- Complication2 is now known as Complication</p>
-15:44 < bar> umm.. perhaps restricted routes was 2.0..</p>
-15:44 < jrandom> yeah, but restricted routes will be doable without losing backwards compatability</p>
-15:45 < jrandom> (in fact, it can be done with 0.6.2, if done carefully, to a degree)</p>
-15:45 < bar> ok, great</p>
-15:45 < jrandom> I'm also thinking of when to drop tcp... maybe in the next release</p>
-15:46 < jrandom> or maybe after, so we don't have /too much/ at once</p>
-15:49 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:51 < jrandom> if not</p>
-15:51  * jrandom winds</p>
-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 ?</p>
-15:51 < jrandom> [saved]</p>
-15:51 < jrandom> sure, I think thats cool</p>
-15:51 < jrandom> anyone who publishes information should expect that their information is public </p>
-15:52 -!- gloin [gloin@irc2p] has joined #i2p</p>
-15:52 < jrandom> I think tino has a way for people to topopt out as well</p>
-15:52 < tethra> that was short</p>
-15:53 < stealth> They are also indexed by google...</p>
-15:53 < jrandom> isnt that a good thing stealth?</p>
-15:53 < Complication> Did it not involve some convention similar to "robots.txt"</p>
-15:54 < jrandom> aye Complication </p>
-15:54 < Complication> (might be best to ask tin0)</p>
-15:54 <@postman> damn, i am too late</p>
-15:54 <@postman> (again)</p>
-15:54 < jrandom> nah, hasn't ended yet postman :)</p>
-15:54 < Complication> He wrote about it in the forum, at some point</p>
-15:54 < Complication> Might be findable there</p>
-15:54 <@postman> ahh cool ( hello then) :)</p>
-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"?)</p>
-15:55 < jrandom> but, whatever, tino is being nicer than I would be regarding inproxies ;)</p>
-15:56 -!- Rawn [Rawn@irc2p] has quit [Connection reset by peer]</p>
-15:56 -!- gloin [gloin@irc2p] has quit [Connection reset by peer]</p>
-15:57 -!- Karellen [Karellen@irc2p] has quit [Connection reset by peer]</p>
-15:57 < Complication> Yes indeed, the assumption shouldn't follow that other providers of in-proxies will be equally nice</p>
-15:58 -!- Karellen [Karellen@irc2p] has joined #i2p</p>
-15:58 -!- Rawn [Rawn@irc2p] has joined #i2p</p>
-15:58 -!- mode/#i2p [+v Rawn] by chanserv</p>
-15:59 < Complication> Information intended to be secret... is best simply not published</p>
-15:59 < tethra> indeed :/</p>
-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...</p>
-16:00 -!- Complication [Complicati@irc2p] has quit [Connection reset by peer]</p>
-16:00 < jrandom> our anonymity isn't dependent upon the size, and i2p has been googled plenty</p>
-16:01 < jrandom> (or, the base level of anonymity isn't dependent upon the size)</p>
-16:01 < jrandom> but, of course, no one who needs hard anonymity should use i2p now.</p>
-16:01 -!- digger3 [digger3@irc2p] has quit [Connection reset by peer]</p>
-16:01 -!- digger3 [digger3@irc2p] has joined #i2p</p>
-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</p>
-16:03 -!- gloin [gloin@irc2p] has joined #i2p</p>
-16:03 < bar> (well.. dead, that depends on tino's inproxy being up or not, of course)</p>
-16:05 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:06 < jrandom> if not</p>
-16:06  * jrandom winds up</p>
-16:07  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/165.rst b/i2p2www/meetings/165.rst
new file mode 100644
index 00000000..119cc39c
--- /dev/null
+++ b/i2p2www/meetings/165.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 24, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/166.log b/i2p2www/meetings/166.log
index 1d52749d..9f65de40 100644
--- a/i2p2www/meetings/166.log
+++ b/i2p2www/meetings/166.log
@@ -1,142 +1,136 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 166{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 31, 2006</h3>
-<div class="irclog">
-15:19 < jrandom>  0) hi</p>
-15:19 < jrandom> 1) Net status</p>
-15:19 < jrandom> 2) 0.6.1.10 status</p>
-15:19 < jrandom> 3) ???</p>
-15:19  * jrandom waves</p>
-15:19 < jrandom> status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-January/001257.html</p>
-15:20 < jrandom> ok, jumping on in to 1) Net status</p>
-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'</p>
-15:21 < jrandom> though users on newer builds (those since 0.6.1.9-5 or newer) may have trouble</p>
-15:21 < jrandom> ("trouble" is perhaps an understatement...)</p>
-15:21 <+Complication> CVS -8 was a bit flaky, so running -2 instad (works nice enough)</p>
-15:22 < gloin> :-)</p>
-15:22 <+Complication> =instead</p>
-15:22 < Pseudonym> things seem unstable lately (I'm on 0.6.1.9-0)</p>
-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</p>
-15:23 < jrandom> hmm Pseudonym, accessing eepsites, irc, or other services, or hosting them?</p>
-15:23 <+Complication> Unstable with -0? How does the problem exibit itself?</p>
-15:23 < Pseudonym> I notice IRC primarily (playing idlerpg)</p>
-15:24 < jrandom> ("playing" ;)</p>
-15:24 < Pseudonym> also, somtimes the router goes wonky and has to be restarted (no active peers)</p>
-15:24 < Pseudonym> heh</p>
-15:24 < jrandom> hmm, internet connectivity issues?</p>
-15:24 <@frosk> -0 is stable here, of course except for the twice-daily "router hung!" restarts</p>
-15:24 < jrandom> hrm frosk, real "router hung", or "router hung" due to leaseSet expiration?</p>
-15:25 < Pseudonym> internet connectivity is fine.  when I restart the i2p router it comes right back</p>
-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</p>
-15:25 <@frosk> jrandom: lease expiration, i'm pretty sure</p>
-15:25 < jrandom> hmm 'k</p>
-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</p>
-15:27 <@frosk> cool</p>
-15:27 <@frosk> i'll be glad to help test it</p>
-15:28 < Pseudonym> I don't need you to troubleshoot the problem right now.  I just wanted to add a datapoint about stability</p>
-15:28 < jrandom> wikked, once its stable locally I'll certainly need to recruit some help :)</p>
-15:28 < jrandom> cool, thanks Pseudonym </p>
-15:28 < jrandom> ok, anyone else have something for 1) Net status?</p>
-15:30 < jrandom> if not, lets jump on in to 2) 0.6.1.10 status</p>
-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</p>
-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</p>
-15:32 < jrandom> more specifically, one idea I'm toying with is migrating to 1024bit ElGamal for the tunnel creation code, rather than 2048bit</p>
-15:32 < jrandom> but that may not be necessary.  it depends on how hard it hits us on the live net</p>
-15:34 < jrandom> if it does, it would just mean a network upgrade, but all destinations/etc would stay the same.</p>
-15:34 < jrandom> but, anyway, thats something to explore after 0.6.1.10 comes out</p>
-15:34 <+Complication> A loosely related question: is the key length in any way related to the tunnel-creation datastructure length?</p>
-15:34 < jrandom> yes</p>
-15:35 < jrandom> directly related: key length * 2 * max # hops == data structure size</p>
-15:36 < jrandom> (so, 256*2*8 = 4KB, which also happens to be the size of full streaming lib messages)</p>
-15:37 < jrandom> ((ElGamal has a 2x expansion factor))</p>
-15:38 <+Complication> Aha, thanks. :)</p>
-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</p>
-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</p>
-15:40 < jrandom> but, of course, more info on that as it comes</p>
-15:41 < jrandom> ok, anyone have any questions/comments/concerns on the 0.6.1.10 stuff?</p>
-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?</p>
-15:41 < bar> rollout*</p>
-15:41 < jrandom> aye, definnitely</p>
-15:42 < jrandom> I'll probably have two or three routers on that box during the migration</p>
-15:42 < jrandom> and there will be loud warnings at least 5 days in advance of the release</p>
-15:42 < bar> smooth</p>
-15:42 <+Complication> This way it would be smoother indeed.</p>
-15:43 <+Complication> Forum seems a good channel. News box on the Router Console too...</p>
-15:43  * jrandom remembers the days when every release was backwards incompatible... we got a lot of practice then ;)</p>
-15:43 < jrandom> aye, forum, news box, list, website</p>
-15:43 <+Complication> So those who attend their machines would know.</p>
-15:43 < tethra> heheh</p>
-15:44 < jrandom> and those on 0.6.0.1 still, well, they're fscked anyway ;)</p>
-15:44 <@frosk> off with their heads</p>
-15:44 <+Sugadude> Totally un-related: Can we have more backwards incompatible changes more often to force these old routers out?</p>
-15:44 <+Complication> I think they just forgot I2P running :)</p>
-15:44 < jrandom> heh Sugadude</p>
-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</p>
-15:47 < jrandom> ok, if there's nothing else on that, lets jump on over to our catch-all: 3) ???</p>
-15:47 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-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? </p>
-15:48 < tethra> or am i showing immense ignorance of something</p>
-15:49 <+Complication> Regarding webcache code... it seems I'm pretty much ready.</p>
-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</p>
-15:49 < jrandom> oh, nice1 Complication, lemmie know when to push the release :)</p>
-15:50 <+Complication> Got the watchdog aborting downloads reasonably, doing some testing and clean-up (it currently logs way more than decent)..</p>
-15:50 <+Complication> I have one webcache server up, awup has another... for some realistic testing, we may want to turn limiting on...</p>
-15:51 <+Complication> ...if I manage to encounter legion, I'll ask if he might be interested in running one too.</p>
-15:52 < jrandom> cool, even a single webcache would be a great start</p>
-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.</p>
-15:53 <+Complication> (not in a file but the header of GWebCacheContainer.java)</p>
-15:53  * gloin don't know what this webcache stuff is.</p>
-15:53 < jrandom> gloin: it lets you connect to i2phex without having to download an i2phex.hosts file the first time</p>
-15:54 <+Complication> gloin: for easier integration of I2PHex</p>
-15:55  * cervantes arrives late</p>
-15:55 <+Complication> And for later reconnecters (e.g. people who've run out of live peer refs) it can offer fresh refs</p>
-15:55 < gloin> ok.</p>
-15:57 <+Complication> Oh, offline again</p>
-15:58 < stealth> what about an automatic startup of i2phex after i2p has started ?</p>
-15:58 <+Complication> Seems like overkill</p>
-15:58 <+Complication> At current phase, at least</p>
-15:58 < jrandom> stealth: you can have the i2p router launch any java application you want by adding entries into your client.config file</p>
-15:59 <+Complication> Besides, I think I2Phex can be started before I2P runs</p>
-15:59 <@frosk> at any phase</p>
-15:59 <+Complication> Theoretically, it should keep trying to connect until I2P gets up</p>
-15:59 <+Complication> (haven't tested, though)</p>
-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)</p>
-16:00 <+Complication> Besides, one could script it fairly easily too...</p>
-16:00 <+Complication> e.g. "cd /home/i2p; sh i2prouter start; cd /home/i2phex; sleep 100; sh run.sh;"</p>
-16:00 <+Complication> (or however it was)</p>
-16:01 <+Complication> Sorry, /home/user/i2p more likely :)</p>
-16:01 < cervantes> don't forget to start /usr/games/tetris before the sleep 100</p>
-16:02 < jrandom> damn straight</p>
-16:02 < jrandom> ok, anyone have anything else for the meeting?</p>
-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...</p>
-16:04 < jrandom> aye, though I've yet to hear of a gnutella client that is thin enough (that could be integrated)</p>
-16:05 < cervantes> isn't the work being done on the current Phex to abstract the UI? perhaps the client eventually become skinny</p>
-16:05 <+Complication> I haven't read that part of Phex CVS</p>
-16:06 < jrandom> if phex could be run as a .war, that would indeed rule</p>
-16:06 < cervantes> isn't the=isn't there</p>
-16:06 < cervantes> I'm probably mistaken</p>
-16:06 <+Complication> Sirup certainly was working on an XML-RPC interface, but I'm not sure if Gregor & co are too</p>
-16:07 <+Complication> So I'm not sure if sirup ported it in, or started writing it from scratch</p>
-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</p>
-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.</p>
-16:10 < fox_> <tethra> might not be what is being looked for, though.</p>
-16:12 < jrandom> porting a new one is a chunk of work, especially a C/C++ one, unfortunately</p>
-16:12 <+Complication> I'm personally unlikely to tinker with XML-RPC. Attempting to catch various bugs... is in my near-term plans, though.</p>
-16:13  * Complication wants the rehash effect gone for good, since it's such a waste of time</p>
-16:13 < jrandom> ooh, perhaps thats triggered by timezone shift?</p>
-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</p>
-16:14 <+Complication> Sounds unlikely... but at this stage, I can't exclude much</p>
-16:15 < jrandom> (and if the rehash depended upon ordering and file timestamps, perhaps the shift of a few hours would change that)</p>
-16:15 < jrandom> yeah, you've dug into a lot of it, just mentioning a possibility</p>
-16:15  * jrandom doesn't know anything about it beyond your bug reports :)</p>
-16:16 <+Complication> It occurs occasionally, and *seems* related to something happening when the "sharedlibrary" config file is being loaded/rewritten</p>
-16:16 <+Complication> Hmm, interesting possibility...</p>
-16:16 <+Complication> I've not dug enough to exclude that</p>
-16:18 < jrandom> ok, anyone else have something for the meeting?</p>
-16:19 < jrandom> if not...</p>
-16:19  * jrandom winds up</p>
-16:19  * bar wishes jrandom good luck with .10 and hands him a shiny baf</p>
-16:19 < jrandom> gracias :)</p>
-16:19  * jrandom *baf*s the meeting closed </p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/166.rst b/i2p2www/meetings/166.rst
new file mode 100644
index 00000000..ab9dc392
--- /dev/null
+++ b/i2p2www/meetings/166.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 31, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/167.log b/i2p2www/meetings/167.log
index b3ee153b..dfa60695 100644
--- a/i2p2www/meetings/167.log
+++ b/i2p2www/meetings/167.log
@@ -1,151 +1,145 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 167{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 7, 2005</h3>
-<div class="irclog">
-15:36 < jrandom> 0) hi</p>
-15:36 < jrandom> 1) Net status</p>
-15:36 < jrandom> 2) _PRE net progress</p>
-15:36 < jrandom> 3) I2Phex 0.1.1.37</p>
-15:36 < jrandom> 4) ???</p>
-15:36 < jrandom> 0) hi</p>
-15:37  * jrandom waves</p>
-15:37 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-February/001258.html</p>
-15:37 < bar> hello</p>
-15:38 < jrandom> while y'all dig through that oh-so-exciting material, lets jump on in to 1) Net status</p>
-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</p>
-15:39 < jrandom> anyone have anything they want to bring up regarding the current net status?</p>
-15:39 < KBlup> I have seen terrible spikes of failing clients when running i2p for long... dunno if thats fits to 1)</p>
-15:39 < jrandom> KBlup: does that correlate to high cpu load or bandwidth consumption?</p>
-15:40 < KBlup> resuluts in msg-delay > 10000ms :-/</p>
-15:40 < jrandom> ah, very likely one of the causes of the _PRE net being developed :)</p>
-15:40 < KBlup> I think it then tries to establish new tunnels and fails constantly, which results in 300+ jobs some times...</p>
-15:41 < KBlup> my maschine is quite strong but overloaded with that...</p>
-15:41 < jrandom> aye, thats all been reworked along the way for 0.6.1.10, hang tight until thats ready</p>
-15:43 < jrandom> ok, anything else on 1), or shall we mosey on over to 2) _PRE net progress</p>
-15:43 <+Complication> 0.6.1.10 seems to contain substantial changed indeed</p>
-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</p>
-15:46 <+Complication> You mentioned having to cough up a lot of CPU time in advance</p>
-15:47 <+Complication> Would this cost now be associated with building any sort of a tunnel?</p>
-15:48 <+Complication> (meaning, before the construction, during a short while, you'd have to perform a batch of heavy crypto)</p>
-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)</p>
-15:49 <+Complication> Whad I wanted to ask... is the interval just tighter than before, or the amount bigger too?</p>
-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</p>
-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</p>
-15:52 <+Complication> ...and it couldn't be pre-calculated, unless one knew the final set that's going to succeed?</p>
-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)</p>
-15:53 <+Complication> (set of peers)</p>
-15:53 < jrandom> hmm, it could certainly be precalculated, assuming you know who the peers in the tunnel that are going to be asked</p>
-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</p>
-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?</p>
-15:54 < jrandom> hmm, not entirely sure I follow</p>
-15:55 <+Complication> Or is knowing them already useless, since the struct must be redone from scratch?</p>
-15:56 <+Complication> (meaning: the ElGamals redone from scratch, at least)</p>
-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</p>
-15:56 < jrandom> so, yes, if the next hop changes, the ElGamal must be redone</p>
-15:56 < jrandom> (if you precompute)</p>
-15:56 <+Complication> Right, I wasn't sure enough about that instantly</p>
-15:57 <+Complication> Now I realize it, though</p>
-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</p>
-15:58 <+Complication> How does it seem doing in reality?</p>
-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 )</p>
-15:59 <+Complication> I noticed the detail about ElGamal encrypts taking a leap towards quickness...</p>
-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</p>
-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)</p>
-16:02 < jrandom> (on the same box)</p>
-16:02 <+Complication> Would this 542 include retries on failure too, or just the pure building?</p>
-16:02 <+Complication> If it's pure building, I need to find my lower jaw... it's on the floor somewhere. :P</p>
-16:02 < KBlup> about that change of the exponent : at what scale does that affect anonymity?</p>
-16:02 < jrandom> no, thats the pure elGamal stat, since the live net doesn't build the new _PRE net structure</p>
-16:04 < jrandom> KBlup: anonymity?  none.  security?  according to what I've read, 228 bits is more than enough to match 2048bit ElGamal</p>
-16:04  * Complication doesn't know much about ElGamal's x and y</p>
-16:04 <+Complication> Not enough to comment meaninfully</p>
-16:06 <+Complication> If serious researchers consider the shorter x hard enough, and those crypto wonks didn't run away screaming...</p>
-16:06 <@cervantes> well not only that, but the implications of dropping to 1024/160</p>
-16:07 < KBlup> i guess i have to read the paper later ;)</p>
-16:07 <+Complication> cervantes: yes, it's better than that, for sure</p>
-16:08 <+Complication> Besides, what is the foremost attack this cipher must repel, and how long is the attack viable?</p>
-16:09 <+Complication> Could it be something which benefits you only if you break it quick, or also benefits if you break it eventually?</p>
-16:11 <+Complication> If I understand right, the immediate secret it guards is the next tunnel participant, right?</p>
-16:11 <+Complication> (or more precisely, the next-to-next one)</p>
-16:11 <@modulus> meeting ongoing?</p>
-16:11 <+Complication> (which only the next one may know)</p>
-16:11 <@cervantes> modulus: ayre</p>
-16:11 <@cervantes> -r</p>
-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)</p>
-16:11 < jrandom> so, we're talking on the order of minutes here, not decades</p>
-16:12 < jrandom> (so 1024bit is probably even overkill)</p>
-16:12 <@cervantes> is there a way to measure the risk in a meaningful way?</p>
-16:13 <+Complication> Besides, for a tunnel with more hops, the adversary would have to break several, right?</p>
-16:13 <+Complication> (though the builder would have to build several too)</p>
-16:13 <@cervantes> if we need no more than 1024 bits, then is it really necessary to use more? </p>
-16:14 <@cervantes> we can always use a stronger algo in 3 years time when we've got vastly more powerful quantum computers</p>
-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?</p>
-16:14 < jrandom> Complication: right, they'd have to break several (and the DH keys protecting the transport layer)</p>
-16:14 <@modulus> afaik 1024bit is break()able with a lot of power</p>
-16:15 < jrandom> a lot of power and a decade</p>
-16:15 < jrandom> (or three)</p>
-16:15 <@cervantes> jrandom: is it difficult to try the weaker cipher?</p>
-16:15 <@modulus> i was under the impression that 1024bit composits were factorizable these days in a few months.</p>
-16:15 <@cervantes> could we roll out to the pre net </p>
-16:15 <@cervantes> and see whether it actually offers much benefit</p>
-16:16 <@cervantes> modulus: yes but they'd need to break several</p>
-16:16 <@modulus> if this is based on discrete log domain and all that stuff then i don't know anything</p>
-16:16 <@modulus> cervantes: aha</p>
-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</p>
-16:17 < jrandom> modulus: ElGamal is based on discrete log</p>
-16:17 <@cervantes> jrandom: worthy of testing?</p>
-16:17 <@modulus> right right, i was imagining RSA</p>
-16:17 <@cervantes> or better to focus on other things and return to it if necessary</p>
-16:18 < jrandom> definitely worth testing, though for the moment I'm hacking away at some transport layer evaluations</p>
-16:18 <+Complication> I guess it depends on how their calculation can be handled in real life.</p>
-16:18 < jrandom> (and the 44ms encryption time is good enough for the moment, though a 4ms encryption time would be even better :)</p>
-16:19 <+Complication> If it holds together with current computers, it will improve with newer machines.</p>
-16:19 <@modulus> especially if there comes crypto hw, as it is starting to come in some</p>
-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</p>
-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</p>
-16:22 <@cervantes> they have crypto machines built on ring sprinkled donut technology</p>
-16:23  * Complication is willing to upgrade the Celeron 300 to Athlon 600, if it holds the tide of ring-sprinkled donuts :D</p>
-16:23 < tethra> heheh</p>
-16:24 < jrandom> mmMMmm donuts</p>
-16:25 < jrandom> ok, anyone have anything else on 2) _PRE net progress?</p>
-16:25 < jrandom> if not, lets jump on over to 3) I2Phex 0.1.1.37</p>
-16:26 < jrandom> Complication: wanna give us the skinny?</p>
-16:26 <+Complication> Well, it seems to work. :)</p>
-16:26 <+Complication> There is hope of getting more webcaches for extra redundancy soon.</p>
-16:27 < jrandom> word</p>
-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</p>
-16:27 <+Complication> (if legion manages to solve the mysteries which haunted his initial try)</p>
-16:27 <+Complication> There's also a mystery bug in there, but it doesn't byte hard, and I'm trying to find it.</p>
-16:28 <+Complication> One up is enough</p>
-16:28 <+Complication> More just increases the chances that one is up</p>
-16:28 < jrandom> cool</p>
-16:28 <+Complication> Because at current stage, it will never drop webcaches as bad. Too few of them altogether.</p>
-16:29 <+Complication> (that routine will activate if there exist more than 10)</p>
-16:29 <+Complication> (if I remember correctly)</p>
-16:29 <+Complication> As for the bug: after a long time operating, the webcache subsystem sometimes stalls</p>
-16:30 <+Complication> Likely because a httpclient's GET request can't be aborted successfully</p>
-16:31 <@modulus> so it needs to die from time to time?</p>
-16:31 <+Complication> It's safe, and never seems to bite freshly joined machines</p>
-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?</p>
-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</p>
-16:31 <+Complication> So currently the impact seems close to 0</p>
-16:31 <@modulus> cool</p>
-16:32 <+Complication> It's curious, just</p>
-16:32 <@modulus> no rule about when it will fail or anything?</p>
-16:32 <+Complication> modulus: generally not before 20 hours</p>
-16:33 <+Complication> And since I have no way of forcing it to occur, debugging is a bit slow</p>
-16:33 <@modulus> :_)</p>
-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 :)</p>
-16:34 < jrandom> :)</p>
-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</p>
-16:35 <+Complication> Could be</p>
-16:38 < jrandom> ok great, nice work Complication</p>
-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) ???</p>
-16:41 < jrandom> (consider us jumped)</p>
-16:41 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:42 < tmp> Or forever hold your breath?</p>
-16:43 < jrandom> and ever and ever</p>
-16:43  * jrandom winds up</p>
-16:43  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/167.rst b/i2p2www/meetings/167.rst
new file mode 100644
index 00000000..60578d4c
--- /dev/null
+++ b/i2p2www/meetings/167.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 7, 2005
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/168.log b/i2p2www/meetings/168.log
index 7efe3230..7c1234f9 100644
--- a/i2p2www/meetings/168.log
+++ b/i2p2www/meetings/168.log
@@ -1,74 +1,68 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 168{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 14, 2006</h3>
-<div class="irclog">
-15:39 < jrandom> 0) hi</p>
-15:39 < jrandom> 1) Net status</p>
-15:39 < jrandom> 2) 0.6.1.10</p>
-15:39 < jrandom> 3) Syndie activity</p>
-15:39 < jrandom> 4) ???</p>
-15:39 < jrandom> 0) hi</p>
-15:39  * jrandom waves</p>
-15:39 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001260.html</p>
-15:39 < jrandom> (I'm a lil late with that, so I'll give y'all a minute to skim through those brief notes)</p>
-15:40 <+Complication> hello</p>
-15:40 <@cervantes> 'lo</p>
-15:41 < jrandom> well, its brief enough, so lets just jump on in to 1) Net status</p>
-15:41 < jrandom> I don't have anything to add to this one, anyone have something on it to discuss?</p>
-15:41 <@cervantes> <jrandom> (damn flakey net connection)</p>
-15:41 <+Complication> A bit congested occasionally, but graphs suggest it's nothing new</p>
-15:42 < jrandom> heh cervantes, well, thats due to one of my roommates using limewire, not i2p ;)</p>
-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</p>
-15:43 <+Complication> It must be hard letting them do that, but I guess... such is life :O</p>
-15:43 <+Complication> do that=use limewire</p>
-15:44 <+Complication> This morning, tracker.postman.i2p was refusing connections, though</p>
-15:44 < jrandom> Complication: disk was full, fixed now</p>
-15:44 < jrandom> (new machines have their new quirks)</p>
-15:46 < jrandom> ok, anyone have anything else on 1) Net status?</p>
-15:46 < jrandom> otherwise, lets shimmy on over to 2) 0.6.1.10</p>
-15:47 < jrandom> As mentioned, we're going to have a new backwards incompatible release in a few days</p>
-15:48 < jrandom> while it alone won't revolutionize our performance, it will improve a few key metrics to get us on our way</p>
-15:48 < jrandom> there are also a whole bunch of bug fixes in there too</p>
-15:49 <@cervantes> will zzz's server tunnel improvements make the fold?</p>
-15:49 < jrandom> oh, and there's that whole improved anonymity thing... ya know, sine qua non</p>
-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</p>
-15:50 < jrandom> (yet)</p>
-15:51 <@frosk> what DH key size/etc did you land on?</p>
-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</p>
-15:51 < jrandom> ah, for the moment we'll be sticking with 2048bit crypto with small exponents</p>
-15:52 <@frosk> so some lower cpu consumption can be expected?</p>
-15:52 < jrandom> aye</p>
-15:53 <@frosk> excellente</p>
-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).  </p>
-15:54 < jrandom> we may explore that in the future though, but this next release should substantially cut down cpu overhead</p>
-15:54 < jrandom> I've also disabled the TCP transport, because I'm a mean and vicious person</p>
-15:55 <@frosk> do you expect any more incompatible upgrades before 1.0?</p>
-15:55 < jrandom> hope not</p>
-15:55  * cervantes must be a danish cartoonist</p>
-15:55 <@frosk> i don't think we'll miss tcp :)</p>
-15:55 <@cervantes> I mean jrandom must be</p>
-15:55 <@cervantes> ;-)</p>
-15:55  * jrandom watches the embassy burn</p>
-15:56 < jrandom> ok, anyone have anything else on 2) 0.6.1.10?</p>
-15:56 < void> why wouldn't it support lighttpd earlier?</p>
-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)</p>
-15:57 <@cervantes> void: malformed headers</p>
-15:57 < jrandom> void: bug where we weren't standards compliant</p>
-15:57 < void> ah, are these inconsistent newline bugs also fixed?</p>
-15:58 < void> and what about the null character one? are you waiting for zzz's persistent connection patch?</p>
-15:58 < jrandom> the newline bug is the malformed header, and is fixed</p>
-15:58 < jrandom> no news on the null character one</p>
-15:59 < void> ok</p>
-16:00 < jrandom> ok, if there's nothing else on 2, lets swing on by 3) Syndie activity briefly</p>
-16:00 < jrandom> well, I don't really have much to add...</p>
-16:01 < jrandom> (I /did/ say briefly)</p>
-16:01 < jrandom> so lets jump on to 4) ???</p>
-16:01 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-16:01 <+fox> <duck> too busy reading Syndie to comment</p>
-16:01 < jrandom> ;)</p>
-16:02  * Complication is too busy issuing meaningless signatures to comment :D</p>
-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</p>
-16:05  * jrandom winds up</p>
-16:05  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/168.rst b/i2p2www/meetings/168.rst
new file mode 100644
index 00000000..7453c0cd
--- /dev/null
+++ b/i2p2www/meetings/168.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 14, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/170.log b/i2p2www/meetings/170.log
index a0abe54e..987d34a9 100644
--- a/i2p2www/meetings/170.log
+++ b/i2p2www/meetings/170.log
@@ -1,122 +1,116 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 170{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 28, 2006</h3>
-<div class="irclog">
-15:11 < jrandom> 0) hi</p>
-15:11 < jrandom> 1) Net status and 0.6.1.12</p>
-15:11 < jrandom> 2) Road to 0.6.2</p>
-15:12 < jrandom> 3) Miniprojects</p>
-15:12 < jrandom> 4) ???</p>
-15:12 < jrandom> 0) hi</p>
-15:12  * Complication quickly reads notes</p>
-15:12  * jrandom waves</p>
-15:12 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-February/001266.html</p>
-15:12 < jrandom> (and here I was posting the notes more than 15 minutes before the meeting!  ;)</p>
-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</p>
-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</p>
-15:16 < jrandom> the bumps we saw at 0.6.1.10 are gone, and irc stability seems quite good again</p>
-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?</p>
-15:17 <+Complication> Net status over here: no more going back under 20 KB/s :)</p>
-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</p>
-15:20 < jrandom> ok, lets jump on to 2)</p>
-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</p>
-15:20 < nymisis> net status is fine :)</p>
-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</p>
-15:23 < jrandom> anyone have any questions/comments/concerns regarding 2) road to 0.6.2?</p>
-15:23 < postman> jrandom: any testnets this time?</p>
-15:24 < postman> (need any routers, particpants to test stuff)</p>
-15:24 < postman> ?</p>
-15:24 <+Complication> The essence of the matter seemed quite straightforward - to limit opportunity for an adversary to harvest diverse statistical data</p>
-15:25 <+Complication> Sounds like a fairly desirable feature</p>
-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</p>
-15:25 < jrandom> aye, exactly Complication </p>
-15:26 < postman> ok</p>
-15:26 < postman> jrandom: are you bold enough to disclose an ETA for 0.6.2 ? :)</p>
-15:27 < blubb> 1 april</p>
-15:27 < jrandom> well, seeing as today is the end of feb, i'd guess march or april</p>
-15:27 < postman> hehe</p>
-15:27 < jrandom> blubb: we've already got an mi6 backdoor scheduled for then ;)</p>
-15:29 <@cervantes> more like an mi6 catflap</p>
-15:29 <@cervantes> (budget cuts)</p>
-15:29 < postman> in an elephant house</p>
-15:30 < nymisis> That's SIS, not MI6, if you're going to be accurate. :)</p>
-15:30 < jrandom> well, lets just call them Them ;)</p>
-15:31 < jrandom> ok, anything else for 2)?</p>
-15:31 < jrandom> if not, lets shimmy on over to 3) miniprojects</p>
-15:31 <@cervantes> sorry "the firm"</p>
-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</p>
-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.</p>
-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</p>
-15:35 < DeltaQ> hmm if i upp the bw on the console is the chanes immediate or reboot needed?</p>
-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</p>
-15:35 < jrandom> w3wt, great Complication </p>
-15:36 < jrandom> DeltaQ: immediately </p>
-15:36 <@cervantes> isn't 1) syndie scheduler a tie in with 4) Download Manager / eepget scheduler</p>
-15:36 <+Complication> DeltaQ: takes effect almost instantly (within the periods that bandwidth gets averaged over)</p>
-15:37 <@cervantes> seems to me that a more generally functional up and download manager would service both needs</p>
-15:37 < jrandom> cervantes: hmm, not necessarily.  1) is pretty focused, and also includes pushes, while 4) is prety generic</p>
-15:37 <+Complication> cervantes: sounds like it could</p>
-15:37 < jrandom> but yeah, the engine behind both is EepGet</p>
-15:37 < jrandom> (eepget does syndie's http transfers, programatically)</p>
-15:38 < DeltaQ> avg doesnt seem yto go above 13kb/s</p>
-15:38 < DeltaQ> i set 64kb/s with 192 burst down</p>
-15:38 < DeltaQ> 32/64 up</p>
-15:38 <@cervantes> so a generic pushing and pulling eepget with a scheduling and management api...</p>
-15:39 <@cervantes> still, in probably ceases to become a mini-project at that point</p>
-15:39 <+Complication> DeltaQ: the average also depends on how much load your client tunnels (and other peers' participating tunnels) generate</p>
-15:39 <+Complication> sorry, s/average/actual bandwidth</p>
-15:39 < jrandom> cervantes: yeah, there's substantial logic involved in the syndie stuff though.</p>
-15:40 < DeltaQ> heh it finally went up</p>
-15:40 < DeltaQ> 1s: 30.82/29.33KBps</p>
-15:40 < DeltaQ> guess i needed up upp the ul bw</p>
-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</p>
-15:40 <+Complication> DeltaQ: for pass-though traffic (participating tunnels), what comes in must also get out</p>
-15:41 <+Complication> DeltaQ: so very different ul/dl rates would choke participating traffic to the lower of the two</p>
-15:42 <+Complication> DeltaQ: also, participating traffic depends on how other nodes "perceive" your node's routing capacity</p>
-15:42 < DeltaQ> oki</p>
-15:43 <+Complication> If they think it can route well, they'll ask more often</p>
-15:43 < jrandom> ok, if there's nothing else on 3) miniprojects, lets jump on over to 4) ???</p>
-15:43 < jrandom> anyone have anything else to bring up for the meeting?</p>
-15:43 < DeltaQ> well i am behind a router but i did map port 8887 to this pc</p>
-15:43 <+Complication> If it's new, or has only recently increased in capacity, they're a bit shy</p>
-15:44 < DeltaQ> oh sorry i didnt mean to intervere a meeting ^^</p>
-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)...</p>
-15:44 <@cervantes> (thanks for the mention in the status notes) ;-)_</p>
-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?</p>
-15:47 <+Complication> I've not managed to dig myself up-to-date on this, so I'm a bit clueless about it</p>
-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</p>
-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</p>
-15:49 <+Complication> Do you think there would ultimately be any benefit to receive from a more "streamlined" NTP client?</p>
-15:49 <+Complication> One which would / could easier keep skews smaller?</p>
-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</p>
-15:51 < jrandom> perhaps we could reduce the minimum-skew limit from 10s to perhaps 2 or 3s, or maybe less</p>
-15:51 < jrandom> alternately, we could allow it to look at the ssu clock skews as well to avoid unecessary skews</p>
-15:52 <+Complication> Or alternatively, could it be possible to limit further any opportunity to guess at another peer's possible clock value?</p>
-15:53  * Complication doesn't know which way would be more practical, just suggesting random possibilities :D</p>
-15:53 < jrandom> no, we know the clock skew of directly connected peers</p>
-15:55 < Magii> is there anyway to tell if the update was done successfully?</p>
-15:55 <+Complication> Aha, so session protocol really depends on that info..</p>
-15:55 < tethra> look at your version number</p>
-15:55 <+Complication> Magii: it should file a CRIT like "update verified, restarting to install" in logs</p>
-15:55 < tethra> :/</p>
-15:55 <+Complication> Then, it should count down minutes to a graceful restart</p>
-15:56 <+Complication> And finally restart</p>
-15:57 <+Complication> Oh, sidenote: does the internal NTP client know of a concept like "clock drift rate"?</p>
-15:58 < jrandom> yeah, the version number on the top left corner of http://localhost:7657/index.jsp should be a giveaway :)</p>
-15:58 < jrandom> Complication: no, it doesn't guarantee sequential clock ticks</p>
-15:59 < jrandom> s/sequential/ordered/</p>
-15:59 <+Complication> Nor develop knowledge like "our system clock is 0.00345 times faster than needed"?</p>
-16:00 < jrandom> ah, no, though adding that to net.i2p.util.Clock wouldn't be that hard (wanna miniproject?  :)</p>
-16:00 <+Complication> I was thinking of something along those lines</p>
-16:01 <+Complication> I guess I'm now thinking a bit more about it :)</p>
-16:01 <+Complication> Other miniprojects first, though :)</p>
-16:02 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:03 < nymisis> Muffins?</p>
-16:04 < jrandom> no, pancakes</p>
-16:04 < jrandom> (mmMMmm pancakes)</p>
-16:04 < jrandom> speaking of which</p>
-16:04  * jrandom winds up</p>
-16:04 < nymisis> Oh, darn, good point.</p>
-16:04  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/170.rst b/i2p2www/meetings/170.rst
new file mode 100644
index 00000000..60d7ada9
--- /dev/null
+++ b/i2p2www/meetings/170.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 28, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/171.log b/i2p2www/meetings/171.log
index 3a1fc17e..745bea50 100644
--- a/i2p2www/meetings/171.log
+++ b/i2p2www/meetings/171.log
@@ -1,78 +1,72 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 171{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 7, 2006</h3>
-<div class="irclog">
-15:08 < jrandom> 0) hi</p>
-15:08 < jrandom> 1) Net status</p>
-15:08 < jrandom> 2) ???</p>
-15:08 < jrandom> 0) hi</p>
-15:08  * jrandom waves</p>
-15:08 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001267.html</p>
-15:09  * jrandom gives y'all hours to read through that huge tome of notes</p>
-15:10  * Complication pretends not having noticed yet ;)</p>
-15:11 <+Complication> Hi :)</p>
-15:11 <+susi23> hi :)</p>
-15:12 < jrandom> well, might as well dig on in to 1) net status</p>
-15:12 < jrandom> The mail gives my general view of whats going on.  how does that line up with what y'all are seeing?</p>
-15:13 <+Complication> Throttling fixes seem to have increased reliability, but really suppressed bandwidth</p>
-15:13 <+Complication> Just a second, digging for the graph</p>
-15:14 <+Complication> http://complication.i2p/files/bw-week.png</p>
-15:14 <+Complication> High stretches are on non-latest, low stretches on latest</p>
-15:15 <+Complication> Same limiter settings, possibly more lax on stricter (latest) versions</p>
-15:16 <+Complication> But it's not much of a problem, since it does transfer</p>
-15:16 < jrandom> cool, reduced bandwidth usage is appropriate as you approach your actual bandwidth limit</p>
-15:17 <+Complication> Most of time, it seems to bounce back before the "sustained bandwidth" limit</p>
-15:17 <+Complication> Never touches the burst limit</p>
-15:18 <+Complication> (which, in itself, is sensible - it's the bouncing back before the sustained limit which concerns me)</p>
-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</p>
-15:19 < jrandom> is 200kbps your limiter rate, w/ 300kbps burst?</p>
-15:20 < jrandom> (just wondering how much time it used to spend in the burst)</p>
-15:20 < jrandom> reduced bandwidth usage though is one of the aims of the recent changes</p>
-15:21 <+Complication> ~225 sustained, ~325 burst</p>
-15:21 <+Complication> Hey, I could have...</p>
-15:22 <+Complication> Have I *interpreted* it wrong?</p>
-15:23 <+Complication> Forget it, I'm a fool... did the math wrong, it's not nearly as bad :O</p>
-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</p>
-15:23 <+Complication> It's a bit on the conservative side, but not nearly as bad as I thought</p>
-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</p>
-15:25 <+Complication> But inbound total average, I have to say, is only slightly above 1/3 sustained limit, and 1/4 burst limit</p>
-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)</p>
-15:26 < jrandom> cool</p>
-15:26 <+Complication> But the graph I misinterpreted, due to Kb/KB issues :O</p>
-15:27  * Complication wipes the graph from history</p>
-15:28 < jrandom> good eye though, definitely lemmie know when things sound funky</p>
-15:28 < jrandom> ok, anything else on 1) Net status?</p>
-15:28 < jrandom> if not, lets shimmy on over to 2) ???</p>
-15:28 < jrandom> anyone have anything else to discuss?</p>
-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</p>
-15:31 <+Complication> They had it slower than pure Java, not sure if a measurement glitch or not :O</p>
-15:32 <+Complication> I couldn't repeat it</p>
-15:32 < jrandom> yeah, i wasn't sure exactly what .so they were using for the platform</p>
-15:32 <+Complication> Over here, it was about twice faster than pure Java</p>
-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</p>
-15:33 < jrandom> ah wikked dust </p>
-15:33 <+dust> no css tho</p>
-15:33 <+Complication> But people on 32-bit spoke of it being *way* faster then pure Java (like 10x or similar)</p>
-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?</p>
-15:36 <+Complication> bar: could be, since I tested it too on a 64-bit OS :O</p>
-15:36 < jrandom> iirc the amd64 was built to work on pure64 debian</p>
-15:37 <+Complication> Either way, some people suggested that importing a fresher gmp might help</p>
-15:37 < bar> just a stab in the dark, i'm no wiz at these things</p>
-15:37 < jrandom> eh, we use 4.1.4</p>
-15:37 <+Complication> Especially after they've done their soon-to-come version jump</p>
-15:38 <+Complication> Since I'm no gmp specialist, I couldn't tell much about it</p>
-15:38 < jrandom> (and the upcoming optimizations in gmp aren't likely to have substantial improvement)</p>
-15:38 <+Complication> Aside from "perhaps indeed"</p>
-15:38 < jrandom> improvements come from per-arch builds</p>
-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</p>
-15:40 <+Complication> (oh, and a 64-bit VM)</p>
-15:41 <+Complication> (marginally being twice)</p>
-15:41 < jrandom> hmm 'k</p>
-15:42 <+Complication> I'll try testing on more platform combinations, and tell if I find anything which seems worth relaying</p>
-15:43 < jrandom> cool, thanks</p>
-15:43 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:46 < jrandom> if not...</p>
-15:46  * jrandom winds up</p>
-15:47  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/171.rst b/i2p2www/meetings/171.rst
new file mode 100644
index 00000000..3e030f15
--- /dev/null
+++ b/i2p2www/meetings/171.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 7, 2006
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/172.log b/i2p2www/meetings/172.log
index 4938692a..3ea5462a 100644
--- a/i2p2www/meetings/172.log
+++ b/i2p2www/meetings/172.log
@@ -1,65 +1,59 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 172{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 14, 2006</h3>
-<div class="irclog">
-15:09 <@jrandom> 0) hi</p>
-15:09 <@jrandom> 1) Net status</p>
-15:09 <@jrandom> 2) ???</p>
-15:09 <@jrandom> 0) hi</p>
-15:09  * jrandom waves</p>
-15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001270.html</p>
-15:10 <@jrandom> while y'all read that massive missive, lets jump into 1) Net status</p>
-15:10 <@jrandom> the net seems to still work (woot)</p>
-15:12 < bar> got me a new udp connection high score yesterday, 244</p>
-15:12 <@jrandom> I don't have much more to add on that front - anyone have any comments/questions/concerns?</p>
-15:12 <@jrandom> ah nice</p>
-15:12 <@jrandom> yeah, I'm hitting peak values too, currently 338 SSU connections</p>
-15:14  * jrandom has also done some substantial i2psnark transfers, though not always at great rates</p>
-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</p>
-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</p>
-15:18 <@jrandom> ok, if there's nothing else on 1) Net status, lets move on over to the floor - 2) ???</p>
-15:18 <@jrandom> anyone have anything they want to bring up?</p>
-15:18 <+Complication> I have only record uptimes to report, and to add that build -6 is very conservative on accepting participating tunnels</p>
-15:19 <+Complication> (but I mentioned that already earlier)</p>
-15:19 <@jrandom> nice - its doing well with the lower peer counts still, too, right?</p>
-15:19 <+Complication> Peer counts have recently risen a bit, actually</p>
-15:20 <@jrandom> ah 'k</p>
-15:20 <+Complication> They are now more like 50...100</p>
-15:20 <+Complication> (generally more towards 50 than 100)</p>
-15:20 <@jrandom> oh, so still fairly low compared to before</p>
-15:20 <+Complication> The around-30 values seem to have been as low as it gets</p>
-15:21 <+Complication> But generally, it's doing fine</p>
-15:21 <@jrandom> great</p>
-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!</p>
-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</p>
-15:28 < bar> me blushes, but thanks :)</p>
-15:28 <@cervantes> w00t</p>
-15:29 <+Complication> nice :)</p>
-15:31 < ripple> jrandom: pastebin.i2p...mission accomplished....</p>
-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</p>
-15:32 <@jrandom> ok, anyone have anything else for the meeting?</p>
-15:34 < tmp> Yes, let's pray for the recovery of Betty.</p>
-15:34  * tethra prays</p>
-15:34 <@jrandom> your prayers have been answered - she's back :)</p>
-15:34 < tmp> Faith based I2P.</p>
-15:35 < tmp> Ok. ;)</p>
-15:35 < tethra> awesome</p>
-15:35 < tethra> XD</p>
-15:35 < fc> tmp: is that a transport protocol or what?</p>
-15:35 < tethra> anonymous prayer?</p>
-15:35 <@jrandom> betty == my laptop</p>
-15:35 < tethra> not even god knows who you are!</p>
-15:36 <@frosk> how about the new machine that bar so awesomely donated?</p>
-15:36 <+susi23> jr: you did not name it susi??? shame on you ;)</p>
-15:37 <@jrandom> the new machine is currently being assembled, an x86_64 (x2) box for windows, gentoo, and perhaps fbsd</p>
-15:37 <@frosk> cool</p>
-15:37 <@jrandom> (once its ready, expect some photos on my blog ;)</p>
-15:38 < fc> bsd! bsd! bsd! ;)</p>
-15:38 <@jrandom> susi23: the new one will need a new name... ;)</p>
-15:38 <@cervantes> susan!</p>
-15:39 <@jrandom> ;)</p>
-15:39 <@jrandom> ok, if there's nothing else for the meeting...</p>
-15:39  * jrandom winds up</p>
-15:39  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/172.rst b/i2p2www/meetings/172.rst
new file mode 100644
index 00000000..ee4cd58d
--- /dev/null
+++ b/i2p2www/meetings/172.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 14, 2006
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/173.log b/i2p2www/meetings/173.log
index eeefbb5e..c53a07b7 100644
--- a/i2p2www/meetings/173.log
+++ b/i2p2www/meetings/173.log
@@ -1,122 +1,116 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 173{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 21, 2006</h3>
-<div class="irclog">
-15:09 <@jrandom> 0) hi</p>
-15:09 <@jrandom> 1) Net status</p>
-15:09 <@jrandom> 2) jrobin</p>
-15:09 <@jrandom> 3) biff and toopie</p>
-15:09 <@jrandom> 4) new key</p>
-15:09 <@jrandom> 5) ???</p>
-15:09 <@jrandom> 0) hi</p>
-15:09  * jrandom waves</p>
-15:09 <@jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-March/001271.html</p>
-15:11 <@jrandom> lets jump briefly on in to 1) Net status</p>
-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</p>
-15:13 <@jrandom> anyone have any questions/comments/concerns regarding the status of the network?</p>
-15:13 <+Complication> About the periodism I noticed yesterday on a freshly started node: it desynchronized itself in a few hours</p>
-15:14 <@jrandom> ah cool</p>
-15:14 <+Complication> Meaning, the highs and lows became a lot more random</p>
-15:14 <@jrandom> I think it still may be worthwhile to jumpstart that at the beginning though</p>
-15:14 <@jrandom> (for those playing at home, we're talking about the implications of the 10m rebuild period)</p>
-15:15 <+Complication> Probably helps prevent tunnel failures</p>
-15:15 <+Complication> I'm still observing a healthy amount of those, but haven't counted</p>
-15:15 <+tethra> (thanks for the translation :)</p>
-15:15 <+Complication> Aside from that, working decently here</p>
-15:16 <+Complication> I think I get "as there are no inbound/outbound tunnels available" about once per 2 hours</p>
-15:17 <@jrandom> hmm, on an i2phex / i2psnark / eepproxy / ircproxy / eepsite destination?</p>
-15:17 <@jrandom> (its possible for clients to overload their own tunnels, which is why I ask which)</p>
-15:18 <+Complication> Checking if there's a trend</p>
-15:19 <+Complication> Bit of shared clients and Pycache, more of I2Phex</p>
-15:20 <@jrandom> hmm ok cool, thanks</p>
-15:20 <+Complication> Significantly more of I2Phex</p>
-15:20 <+Complication> Might have to limit its bandwidth</p>
-15:21 <+Complication> (was at default 16K)</p>
-15:23 <@jrandom> ok cool, anyone have anything else for 1) Net status?</p>
-15:25 <@jrandom> if not, lets shimmy on over to 2) JRobin</p>
-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</p>
-15:27 <+Complication> Quite agreed :)</p>
-15:29 <+Complication> Convenient graphs, with high enough resolution, help find oddities and help ask about them :)</p>
-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</p>
-15:30 <@jrandom> (rrdtool <-->jrobin info @ http://www.jrobin.org/api/jrobinandrrdtoolcompared.html)</p>
-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)</p>
-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</p>
-15:34 <@jrandom> ok, if there's nothing else on 2) JRobin, lets swing on over to 3) biff and toopie</p>
-15:34 <@jrandom> postman: wanna give us the rundown?</p>
-15:34 < postman> aah yes</p>
-15:35 < postman> years ago the mailservice had an irc bot called biff could notify you about new mails</p>
-15:35 <+Complication> Postman's AI foundry ;P</p>
-15:35 < postman> with the migration to a new platform biff became unusauble and i had no time to revamp it</p>
-15:35 < postman> now it's back online again</p>
-15:35 <@jrandom> (yay!)</p>
-15:36 < postman> if you wish to monitor your mailbox over irc just /msg biff .help for a list of commands</p>
-15:36 < postman> usage is straightforward</p>
-15:36 < postman> question/errors/rants/flames -> postman@mail.i2p</p>
-15:36 < postman> 2.</p>
-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</p>
-15:38 < postman> first draft is named toopie and will soon reside on #i2p (i2p-chat maybe too)</p>
-15:38 < postman> it will hold a list of topics, and Q&A sorted by topics and indexed by keywords</p>
-15:38 < postman> toopie can speak to the channel as well as privmsg with a user</p>
-15:38 <+Complication> Sounds neat, though I've never seen one before :)</p>
-15:39 < postman> we hope to fill its brain asap</p>
-15:39 < postman> Complication: you can play with it in #irc2p (in private if you wish :))</p>
-15:39 <@jrandom> and one of the good parts about it is that we can fill it up with messages on irc :)</p>
-15:39 < postman> yes</p>
-15:40 < postman> admins can add some lines straight from irc and make it a new q&a</p>
-15:40  * tethra suggests an entry purely for the sake of TheJudge/closedshop to the effect of "No, predecessor attacks don't work."</p>
-15:40 <+tethra> ;)</p>
-15:40 < postman> hee</p>
-15:41 < postman> there is still room for the way of structuring the informationm</p>
-15:41 <@jrandom> (but they do.  though they're not a particular program you "run" to attack someone)</p>
-15:41 < postman> more to come soon</p>
-15:41  * postman hand back the mike</p>
-15:41 <@jrandom> word, thanks postman</p>
-15:42 < ashter> postman; will toopie speak in other langages too ?</p>
-15:42 < postman> ashter: not (yet)</p>
-15:42 <+fox> <mihi> igpay atinlay? *g*</p>
-15:42 < ashter> ok</p>
-15:42 < postman> ashter: the infrastructure is there ( /me planned this )</p>
-15:42 <@jrandom> word</p>
-15:42 < postman> ashter: it will be a version 2 feature </p>
-15:42 < ashter> great, really nice thank you</p>
-15:44 < postman> (thejudge makes alone 50% of alle irc disconnects today)</p>
-15:45 < postman> jrandom: ok next topic</p>
-15:46 <@jrandom> ok cool, anyone have anything else on 3) biff and toopie?</p>
-15:46 <@jrandom> if not, lets swing on by to 4) new key</p>
-15:47 <@jrandom> well, there's not really anything to add to what I posted.  new key, yadda yadda</p>
-15:47 <@jrandom> ok, lets jump on over to 5) ???</p>
-15:47 <+tethra> erm</p>
-15:47 <@jrandom> anyone have anything else to bring up?</p>
-15:48 <+tethra> how does biff know you are you? :/</p>
-15:48 <+fox> <mihi> tethra: you have to register</p>
-15:48 <+fox> <mihi> just read what is referenced in the weekly notes :)</p>
-15:48 < postman> tethra: 1.) you know your mailboxes credentials, 2. you register with an identified nick@biff</p>
-15:48 <+fox> <mihi> yes :)</p>
-15:48 <+fox> <mihi> what is the point to have expiring keys when you could have expiring subkeys instead?</p>
-15:48 <+tethra> postman: ah, ok. thanks.</p>
-15:49 <@jrandom> mihi: to compartmentalize compromise.</p>
-15:50 <+fox> <mihi> you can delete expired secret subkeys from your keyring if you wish</p>
-15:51 <+fox> <mihi> but I guess it is much nicer to have ppl lsign your key every year :)</p>
-15:51 <+fox> <mihi> nicer in some sadistic point of view :-></p>
-15:51 < postman> jrandom: now, riddle mihi this :)</p>
-15:52 <@jrandom> (assuming only the subkey could be compromised)</p>
-15:54 <@jrandom> in any case, anyone have anything else to bring up for the meeting?</p>
-15:54 <+fox> <mihi> assume someone compromised your key yesterday. now he can have played a mitm and replaced the new key.</p>
-15:54 <+fox> <mihi> i.e. compromise one key -> compromise all future keys, isn't it</p>
-15:55 <+Complication> Unless the owner uses a revocation certificate</p>
-15:55 <+Complication> invalidate compromised key -> invalidate future ones</p>
-15:55 <@jrandom> mihi: and I could revoke the compromised key and tell you not to trust new keys</p>
-15:55 <@jrandom> you now have the choice whether to trust the key change or not</p>
-15:56 <+fox> <mihi> whom to believe then? :)</p>
-15:56 <@jrandom> good question.  if you hear a signed revocation in the next day or two, you should discard the new key</p>
-15:57 <+fox> <mihi> and if it was a subkey, you'd revoked the amin key and the subkey is automatically discarded :)</p>
-15:57 <+fox> <mihi> s/amin/main/</p>
-15:58 <+fox> <mihi> agree to disagree?</p>
-15:58 <@jrandom> aye, that we can agree to ;)</p>
-15:58 <@jrandom> ok, if there's nothing else for the meeting...</p>
-15:58 <+fox> * mihi hands jrandom the *baf*er (after years, just like in good old times...)</p>
-16:00 <@jrandom> hehe</p>
-16:00  * jrandom winds up</p>
-16:00  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/173.rst b/i2p2www/meetings/173.rst
new file mode 100644
index 00000000..ab284a23
--- /dev/null
+++ b/i2p2www/meetings/173.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 21, 2006
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/174.log b/i2p2www/meetings/174.log
index 0dce7b5c..1288a74c 100644
--- a/i2p2www/meetings/174.log
+++ b/i2p2www/meetings/174.log
@@ -1,78 +1,72 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 174{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 28, 2006</h3>
-<div class="irclog">
-15:08 < jrandom> 0) hi</p>
-15:08 < jrandom> 1) Net status and 0.6.1.13</p>
-15:08 < jrandom> 2) Use case survey</p>
-15:09 < jrandom> 3) ???</p>
-15:09 < jrandom> 0) hi</p>
-15:09  * jrandom waves</p>
-15:09 < Complication> Finally loaded, reading :)</p>
-15:10 < jrandom> weekly status notes posted up at dev.i2p.net/pipermail/i2p/2006-March/001274.html</p>
-15:10 <@cervantes> *** connection reset</p>
-15:10 < jrandom> heh</p>
-15:11 < jrandom> ok, while y'all dig into that, lets jump on in to 1) Net status</p>
-15:12 < jrandom> about 2/3rds of the net has upgraded to 0.6.1.13 (thanks!), and results have been mixed</p>
-15:12 < jrandom> anyone out there on low bandwidth links have any experiences they want to share?  better / worse / no difference?</p>
-15:13 < jrandom> or, any results from folks on dsl-class links?</p>
-15:13  * jrandom has heard (and felt) some results on faster links (largely negative, unfortunately)</p>
-15:14 <+Complication> Well, I wanted to say that net status is a bit flaky. :) But the net said it first. :D</p>
-15:15 <+Complication> On the scale of recent disconnects, this was a very rapid recovery, though.</p>
-15:16 <+Complication> Haven't had any more massive message jams, but it still loses a lease now and then</p>
-15:17 <+Complication> Also, I think the last router run ended when a lease couldn't be renewed, so it concluded "Router hung!"</p>
-15:18 < jrandom> ah col</p>
-15:18 <+Complication> Had been ticking for 15 hours or so</p>
-15:18 < jrandom> perhaps we should adjust the watchdog to stop restarting the router under those situations</p>
-15:19 <+Complication> Retransmission is also the same as before (uncomfortably high, but apparently possible to live with - which in itself is good news)</p>
-15:19 < jrandom> the restart used to be necessary, but recurrant tunnel failure should be recoverable</p>
-15:19 < jrandom> hmm, <10%, <20%, >20%?</p>
-15:20 <+Complication> > 20%</p>
-15:20 <+Complication> I don't know many protocols which work tolerably when every third message goes missing</p>
-15:21 <+Complication> This one works :) But it used to be around 7%</p>
-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</p>
-15:21 < jrandom> (as shown on peers.jsp)</p>
-15:22 <+Complication> True, and I haven't taken a look at that side of the distribution yet</p>
-15:23 <+Complication> Might need to check, if for nothing else, then to verify how it's distributed</p>
-15:24 < jrandom> cool, thanks Complication </p>
-15:24 < jrandom> ok, anyone have anything else on 1) Net status?</p>
-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% </p>
-15:26 <+Complication> bar: it's around 80% of line speed</p>
-15:26 < bar> ok</p>
-15:26 <+Complication> On the same level as it was, when retransmission was around 7%</p>
-15:26 <+Complication> Had it higher meanwhile, but brought back down</p>
-15:28 < bar> i'll try to use 80% for a day or so to see if anything happens</p>
-15:28 <+Complication> And sustained transfer limit is around 65%</p>
-15:28 <+Complication> Actual transfer, if the total indicator is correct, averages near 60% of line speed</p>
-15:29 <+Complication> (peaks are higher)</p>
-15:30 < ashter_> for my part lot of 'no lease' thing for local destination (as i said today)</p>
-15:30 < ashter_> and a node a bit more congested</p>
-15:30 <+fox> <nextgens> hi</p>
-15:30 < jrandom> heya nextgens</p>
-15:30 < jrandom> ashter_: hmm, are you on dialup, dsl/cable, or faster?  or, better said (more anonymously), are you congested?</p>
-15:31 <+fox> <nextgens> cool, jrandom is around :) you might help me :)</p>
-15:31 < jrandom> (as in, network congestion, not the numbers i2p displays)</p>
-15:31 < ashter_> dsl/cable</p>
-15:32 < jrandom> ok thanks</p>
-15:33 < jrandom> ok, if there's nothing else on 1) Net status, lets jump on over to 2) Use case survey</p>
-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</p>
-15:37 <@cervantes> *cough*</p>
-15:38 <+tethra> oh dear :/</p>
-15:39 < jrandom> (|grep -v -- -\!- ;)</p>
-15:39 < jrandom> ok, as I said though, bounce word through whatever fashion you care to use at your convenience.  gracias</p>
-15:39 < jrandom> movin' on to 3) ???</p>
-15:39 < jrandom> anyone have anything they want to bring up for the meeting?</p>
-15:40 <@cervantes> http://forum.i2p.net/viewtopic.php?p=7442  <-- sticky thread for use case discussion</p>
-15:40 < jrandom> ah cool, thanks cerv</p>
-15:42 < ashter> (erf that happened once again, and when this occurs participating tunnels grows insanly :( )</p>
-15:43 < jrandom> hmm, to the thousands, or hundreds?</p>
-15:43 < jrandom> (there are a few fixes for bursts of new tunnels pending, should be out later this week)</p>
-15:43 < ashter> thousands</p>
-15:44 < ashter> (ok thank you)</p>
-15:44 < jrandom> ok cool.  you may want to conider lowering your bandwidth limit or share percentage in the meantime</p>
-15:44 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:45 < jrandom> if not...</p>
-15:45  * jrandom winds up</p>
-15:46  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/174.rst b/i2p2www/meetings/174.rst
new file mode 100644
index 00000000..dccdf845
--- /dev/null
+++ b/i2p2www/meetings/174.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 28, 2006
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/175.log b/i2p2www/meetings/175.log
index a6030831..ea4a582e 100644
--- a/i2p2www/meetings/175.log
+++ b/i2p2www/meetings/175.log
@@ -1,132 +1,126 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 175{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 4, 2006</h3>
-<div class="irclog">
-16:21 < jrandom> 0) hi</p>
-16:21 < jrandom> 1) Net status and 0.6.1.14</p>
-16:21 < jrandom> 2) Syndie plotting</p>
-16:21 < jrandom> 3) Local jbigi optimizations</p>
-16:21 < jrandom> 4) ???</p>
-16:21 < jrandom> 0) hi</p>
-16:21  * jrandom waves</p>
-16:21 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001275.html</p>
-16:21  * Complication reads</p>
-16:22 < jrandom> while y'all read that (briefly put together) post, lets jump on in to 1) Net status</p>
-16:23 <@cervantes> (forum back)</p>
-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</p>
-16:24 < Complication> Over here, with the "fourth" CVS build, I noticed a change in my graphs</p>
-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</p>
-16:24 < Complication> In general, things moved towards more stability and less jumpyness</p>
-16:24 < jrandom> oh bugger, I forgot to increment it to -4 didn't I?</p>
-16:24 < jrandom> (ok, -5 will be out later this evening)</p>
-16:24 < jrandom> cool Complication </p>
-16:25 < Complication> But my perceptions could be influenced by jbigi too, as I didn't take steps to exclude that</p>
-16:25 < Complication> Now, after a while, retransmission has edged down to 15% too</p>
-16:28 < jrandom> hmm, i'm also seeing my average ssu rto approach the 3s ceiling as well</p>
-16:28 < jrandom> (though very low retransmission still, under 5%)</p>
-16:29  * Complication takes a second look at it</p>
-16:29 < Complication> Let's say the raw average is a little over 1500</p>
-16:29 < Complication> (over here)</p>
-16:30 <+fox> <BrianR___> jrandom: Is there a de-facto "MTU" for i2p packets?</p>
-16:30 < jrandom> ah ok, perhapsas that inches up, the retransmission rate will go down</p>
-16:30 < Complication> I noticed mine start out with smaller MTUs, now it's upped some to 1350</p>
-16:30 < jrandom> BrianR___: yes, either 1350 or 608 (as shown on http://localhost:7657/peers.js)</p>
-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)</p>
-16:31 <+fox> <BrianR___> jrandom: Now is that for the inside payload or the visible IP packets?</p>
-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?</p>
-16:31 < jrandom> that is for the UDP payload</p>
-16:32 < jrandom> streams are two layers up</p>
-16:32 < jrandom> (there's fragmentation for tunnels, and then fragmentation at the stream/i2cp level)</p>
-16:32 <+fox> <BrianR___> Yes... Is there an ideal size to minimize fragmentation?</p>
-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.</p>
-16:33 < jrandom> (aka ignore the man behind the curtain)</p>
-16:33 <+fox> <BrianR___> Aah.. Maybe I should think about pipelining or something then..</p>
-16:34 <+fox> <BrianR___> I'm planning an app with lots of request/response traffic...</p>
-16:34 < jrandom> i'd recommend batching then to cut down on the chattyness</p>
-16:34 < Complication> Perhaps keeping traffic focused would help to some extent</p>
-16:37 < jrandom> ok, anyhing else on 1) Net status, or shall e shimmy on over to 2) Syndie plotting</p>
-16:38  * jrandom shimmies</p>
-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</p>
-16:40 < jrandom> (more info will be of course forthcoming as things get fleshed out further)</p>
-16:42 < jrandom> thats all i've got to say on that for the moment, so, moving on over to 3) jbigi optimizations</p>
-16:42 <@frosk> and i had assumed "plotting" referred to some jrobin stuff in syndie :)</p>
-16:43 < jrandom> hehe</p>
-16:43 < jrandom> it'd be interesting to plot posts/day, posts/author, new authors/day, etc ;)</p>
-16:44 < Complication> Oh, on bit about Syndie (sorry, only now remembered)</p>
-16:44 < Complication> =one bit</p>
-16:44 <@frosk> which do you want, 0 or 1? :)</p>
-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?</p>
-16:45 < Complication> On addresses.jsp</p>
-16:45 < jrandom> oh, yeah without much trouble</p>
-16:46 < jrandom> thats a good idea for therevamp too, but perhaps we can get that into the 0.6.1.14 build</p>
-16:47 < Complication> Nah, it's not byting me, I just remembered something I noticed back then</p>
-16:47 < Complication> Anyway, jbigi gets faster on Linux/AMD64 when you compile locally and use GMP 4.2</p>
-16:48 < jrandom> cool</p>
-16:48 < jrandom> did you compare that w/ -O3 -m64 on GMP 4.1.2?</p>
-16:48 < Complication> And I'm a damn fool for going after way wrong compile flags :O</p>
-16:48 <@cervantes> the relevant link was http://forum.i2p/viewtopic.php?t=1523&start=30 btw</p>
-16:48 < jrandom> ah thanks cervantes </p>
-16:48 < Complication> jrandom: I haven't compared yet, but will</p>
-16:49 < Complication> During next scheduled reboot</p>
-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</p>
-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*</p>
-16:50 < jrandom> aye, might be compiler rev dependent as well</p>
-16:50 < jrandom> (especially with all these 3.3/3.4/4.0/4.1 issues)</p>
-16:51 <@cervantes> just to re-iterate what I mentioned in that thread... we probably won't see windows64 optimised jbigi anytime soon</p>
-16:51 <+fox> <BrianR___> Does the i2p stream lib do payload compression?</p>
-16:52 < Complication> BrianR: yes</p>
-16:52 <@cervantes> unless someone has M$ VC 2005 w/64-bit SDK and fancies some heavy toil to get it to compile gmp</p>
-16:52 < Complication> At least to my knowledge</p>
-16:53 <@cervantes> (there was a project to port gmp into a vc project somewhere though)</p>
-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 ;)</p>
-16:53 < jrandom> (when my new box gets here though i may be able to tweak that, as its an amd64)</p>
-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..</p>
-16:54 <@cervantes> coolio - unfortunately Mingw64 or cygwin64 doesn't seem to be on the near horizon...</p>
-16:54 < jrandom> BrianR___: premature optimization being the root of all evil, and all that jazz...</p>
-16:55 < Complication> at least partly human readable protocols are generally easier to debug, but I guess it depends what one's doing</p>
-16:56 < Complication> ('cause some things like encryption don't like being human-readable, no matter what :) )</p>
-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</p>
-16:58 < jrandom> aye</p>
-16:58 < jrandom> ok, anything else on 3) jbigi stuff?</p>
-16:58 < jrandom> if not, lets move to 4) ??? </p>
-16:59 < jrandom> anyone have anything else for the meeting?</p>
-17:01 <+tethra> i recall hearing something about anonymous collaboration tools recently</p>
-17:01 <+tethra> care to elaborate on what kind, and whether they'll be syndie-esque or not?</p>
-17:02 <@cervantes> irc and syndie is an anonymous collaboration tool :)</p>
-17:02 < jrandom> hmm, not sure of what you refer to - or maybe you mean the actual planned syndie revamps?  :)</p>
-17:02 <+tethra> true.</p>
-17:02  * tethra isn't sure either, which is why he asked</p>
-17:02 <+tethra> there was talk of it on the forums - reasons for anonymity and stuff</p>
-17:03 <+tethra> i'll find the thread so i can get the quote</p>
-17:03 < jrandom> ah right</p>
-17:03 <+tethra> http://forum.i2p.net/viewtopic.php?t=1618</p>
-17:03 < jrandom> the use case thread</p>
-17:03 <+tethra>  - anonymously hosted & publicly reachable forums/boards/wikis </p>
-17:03 <+tethra> yeah</p>
-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?</p>
-17:04 < jrandom> there have been some good ideas in there, and some good feedback</p>
-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</p>
-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"</p>
-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</p>
-17:07 <+tethra> right</p>
-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?</p>
-17:08 < jrandom> likely so, though there is no cabal - anyone can learn</p>
-17:08 <+tethra> (key things, basically. not that i'm naming any, but hey.)</p>
-17:08 <+tethra> true</p>
-17:09 <+tethra> but learning at the cost of your own and other people's anonymity isn't the greatest way of doing it</p>
-17:10 < jrandom> everyone has to start somewhere, of course</p>
-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?)</p>
-17:10 <+tethra> yeah</p>
-17:14 < jrandom> ok, anyone else have anything for the meeting?</p>
-17:15 < jrandom> if not</p>
-17:15  * jrandom winds up</p>
-17:15 <@cervantes> *ahem*</p>
-17:15  * jrandom pauses</p>
-17:16 < jrandom> whats shakin' cerv? </p>
-17:16 < Complication> Neat, I found a baf ;P</p>
-17:17 < jrandom> baf-blocked ;)</p>
-17:17 <@cervantes> hups srry, continue baffing</p>
-17:17  * jrandom resumes winding</p>
-17:18  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/175.rst b/i2p2www/meetings/175.rst
new file mode 100644
index 00000000..ae638002
--- /dev/null
+++ b/i2p2www/meetings/175.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 4, 2006
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/176.log b/i2p2www/meetings/176.log
index 27b01e62..9e0f3142 100644
--- a/i2p2www/meetings/176.log
+++ b/i2p2www/meetings/176.log
@@ -1,180 +1,174 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 176{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 18, 2005</h3>
-<div class="irclog">
-16:09 < jrandom> 0) hi</p>
-16:09 < jrandom> 1) Net status and 0.6.1.16</p>
-16:09 < jrandom> 2) Tunnel creation and congestion</p>
-16:10 < jrandom> 3) Feedspace</p>
-16:10 < jrandom> 4) ???</p>
-16:10 < jrandom> 0) hi</p>
-16:10  * jrandom waves</p>
-16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-April/001281.html</p>
-16:10  * frosk too</p>
-16:10 < jrandom> (almost two hours *before* the meeting, too :)</p>
-16:11 < jrandom> ok, since i'm sure y'all've already poured over the notes, lets jump into 1) Net status</p>
-16:12 <+Complication> Hi :)</p>
-16:12  * Complication quickly grabs the notes</p>
-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</p>
-16:13 < jrandom> (the root cause was injected last october, but is fixed now)</p>
-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</p>
-16:14 < jrandom> aye, thats understandable too, especially under slower links</p>
-16:14 < jrandom> (unfortunately, "slower" isn't all that slow, either)</p>
-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</p>
-16:17 <+Complication> Something I've been thinking of,  with regard to what you called "congestion collapse"</p>
-16:18 <+Complication> One way to limit its impact might be to actually *require* a router to accept a certain quota of participation requests</p>
-16:19 <+Complication> (something specified by the user either directly or indirectly?)</p>
-16:19 < jrandom> specified by which user?</p>
-16:19 <+Complication> (e.g. some part of share percentage or an additional parameter)</p>
-16:19 < jrandom> the local user, or by us as remote users?</p>
-16:19 <+Complication> Specified by everyone for themselves</p>
-16:19 <@frosk> should we move over to 2) then? :)</p>
-16:20 < jrandom> aye, might as well consider us on 2) :)</p>
-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"</p>
-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.</p>
-16:21 <+Complication> (this would, of course, mean that some local destination could be offline a while longer)</p>
-16:21 < jrandom> and if they aren't asked, they /cant/ push other people's data</p>
-16:22 <+Complication> Ah, perhaps I should have phrased it significantly clearer</p>
-16:24 <+Complication> I imagined it could, under a certain quota of participating traffic, throttle its own tunnel creation messages instead of participating tunnels</p>
-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."</p>
-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)</p>
-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</p>
-16:28 < spinky> Currently, you get no cover traffic at all when transferring lots of data.</p>
-16:29 < spinky> Having a floor for participation bw sounds good.</p>
-16:30 < jrandom> well, we do have a floor (both as the share percentage and an internal 4KBps reserved after all bw is assigned)</p>
-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 :)</p>
-16:32 <@frosk> is there anything significant about 4KBps?</p>
-16:33 < jrandom> a few things - 4KB ~= sizeof(tunnel create message), and heuristically, i've never heard of a router running uccessfully on less</p>
-16:33 < spinky> Maybe it's the bugs that keep the share percentage from working then?</p>
-16:34 < jrandom> what makes you say the share percentage doesn't work?</p>
-16:34 <@frosk> i see</p>
-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</p>
-16:35 <+Complication> (not because of meaningful reasons, just because what I imagined was, in a certain sense, its equal opposite)</p>
-16:35 < spinky> It's set to 80% and participation goes to 0 when locally generating data. Perhaps I'm misunderstanding things.</p>
-16:36 < jrandom> ah, yes, thats not what the share percentage does</p>
-16:36 <+Complication> spinky: it's a maximum limit of what may be shared, subject to bandwidth actually available for sharing</p>
-16:37 <+Complication> If local traffic takes up 70%, you've only got 10% left for sharing</p>
-16:37 <+Complication> If local traffic is heavy, you'll have 0% left, and the top limit of 80% will never be touched</p>
-16:37 < spinky> Ok. I see it says 'up to'...</p>
-16:38 <+Complication> And also, there's the 4 KB/s reserve</p>
-16:38 < jrandom> ah, its share percentage of what you have available</p>
-16:38 < spinky> Maybe another setting for the floor participation bw, under which the router will accept more tunnels?</p>
-16:38 < jrandom> if you are using 95% of your bw, it will share up to 80% of the remaining 5%</p>
-16:39 <+Complication> Oh, then I've partly misunderstood it too</p>
-16:40 < fox> <zorglu1> how i2p measure the amount of bw used by other local applications ?</p>
-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)</p>
-16:40 <+Complication> I thought it was applied against the sustained limit</p>
-16:40 < jrandom> zorglu1: it measures i2p's bw usage, and knows i2p's bw limits</p>
-16:41 < jrandom> oh, hmm, looking back at the code, int availBps = (int)(((maxKBps*1024)*share) - used);</p>
-16:41 < jrandom> so you're right Complication </p>
-16:42 < jrandom> spinky: cover traffic is only so useful on a low latency mixnet</p>
-16:42 < jrandom> it does add some incentive for higher bw routers, but those w/out bw to spare have little recourse</p>
-16:49 < jrandom> anyway, the tunnel congestion issue has been around for a while, but only recently exacerbated by the insane tunnel rejection rates</p>
-16:49 < jrandom> hopefully the next rev will clear it up for us</p>
-16:49 < jrandom> ok, anyone have anything else on 2) tunnel creation and congestion?</p>
-16:50 <@frosk> sounds like it would take some changes to the tunnel-building scheme</p>
-16:50 <+Complication> I hope it will help improve things :)</p>
-16:51 <+Complication> Oh, by the way...</p>
-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</p>
-16:52 <+Complication> ...did you perchance find anything which could explain the big disparity between raw bandwidth indicators and tunnel payload indicators?</p>
-16:52 <+Complication> (e.g. total banwidth 1 GB, tunnel payload summed up 300 MB)</p>
-16:52 < jrandom> but its true, those only affect the magnitude</p>
-16:52 <+Complication> (since I haven't been around IRC lately, I'm not sure if you've been looking at that one recently)</p>
-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...)</p>
-16:54  * Complication isn't certain if it's the indicators, or a real effect</p>
-16:55 <+Complication> Oh... outbound build requests... indeed</p>
-16:55 < jrandom> the upcoming -1 build adds a slew of stats for monitoring per-message-type packet monitoring</p>
-16:55 <+Complication> That could be precisely it</p>
-16:55 < jrandom> (also included in those outbound build requests are build participationg requests - forwarding a reply)</p>
-16:56 < jrandom> ((so its not just local stuff))</p>
-17:00 <+Complication> > Thanks, that explains it a whole lot :)</p>
-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</p>
-17:00 <+Complication> It would indeed have to occur, and would indeed cost a lot of bytes</p>
-17:00 <+Complication> Especially with low success rates</p>
-17:01 < jrandom> aye, though i shouldn't cost as much as it does, since we should have higher success rates than we do :)</p>
-17:01 < jrandom> ok, anything else on 2)?</p>
-17:02 < jrandom> if not, lets swing on over to 3) Feedspace</p>
-17:02 < jrandom> frosk: wanna give us an update?</p>
-17:03 < jrandom> (or tell us to fsck off and read the eepsite?  ;)</p>
-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)</p>
-17:04 < jrandom> (w00t)</p>
-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)</p>
-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</p>
-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</p>
-17:07 < jrandom> (crude + functional)++</p>
-17:07 <@frosk> so there is of course a job opening for a client hacker ;)</p>
-17:08 <@frosk> there are still some necessary stuff that feedspace needs before any public testing, but it shouldn't be long now :)</p>
-17:08 < jrandom> nice1</p>
-17:08 < jrandom> anything we can do to help?</p>
-17:08 <@frosk> also i've been working a bit on documentation, which has been lacking</p>
-17:09 < spinky> Do you see feedspace being usable for large files?</p>
-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</p>
-17:10 <@frosk> large files support is not a priority for now, but perhaps later</p>
-17:10 <@frosk> focus for "1.0" is smaller messages such as blog and discussion entries, and events of any sort</p>
-17:11 < jrandom> though feeding .torrent files into an rss/feedspace-enabled bt client wouldn't be a problem</p>
-17:11 <@frosk> large files may or may not work :)</p>
-17:11 <@frosk> that would be a superneat thing</p>
-17:12 < jrandom> feed2snark ;)</p>
-17:12 <@frosk> i hope we'll see all sorts of such "adapter" apps :)</p>
-17:12 <+Complication> Well, I'm sure people will find ways to move large files using bit... umm, side channels :)</p>
-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 :)</p>
-17:15 < jrandom> yikes</p>
-17:16 < jrandom> well, there are rumors of gcj adopting ecj for 1.5-isms</p>
-17:16 < spinky> Complication: Ponies with saddle bags full of hdds?</p>
-17:16 <@frosk> yep</p>
-17:17 <+Complication> spinky: drones, in my preferred case :P</p>
-17:17  * jrandom is still barely moving up to 1.4-isms</p>
-17:17 <+Complication> But I guess ponies work too :P</p>
-17:17 < jrandom> though 1.6 sure is nice ;)</p>
-17:17 <@frosk> to stay gcj-compatible?</p>
-17:18 <@frosk> well 1.6 doesn't have a lot of "isms" for most things anyway i think :)</p>
-17:18 <+Complication> (or flying hedgehogs airdropping memory cards)</p>
-17:18 < jrandom> gcj/classpath/etc, but also for performance (i've found 1.5 a bit heftier than 1.4)</p>
-17:19 < jrandom> true, 1.6's improvements are largely vm/bytecode specific</p>
-17:19 <@frosk> hm ok</p>
-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</p>
-17:21 <@frosk> well there's no going back :) hopefully it won't be too bumpy</p>
-17:24 < jrandom> aye, i'm ure it'll work out fine :)</p>
-17:25 < jrandom> ok cool, anyone have anything else on 3) feedspace?</p>
-17:25  * frosk hugs his generics and java.util.concurrent ;)</p>
-17:25 < jrandom> heheh</p>
-17:27 < jrandom> ok, if there's nothing else on 3, lets move on over to 4) ???</p>
-17:27 < jrandom> anyone have anything else for the meeting?</p>
-17:27 <+Complication> A little question which I should have asked under 2)</p>
-17:28 <+Complication> Do you know, how do idle participating tunnels typically form?</p>
-17:28 <+Complication> Are they mostly a sign of failed tunnel builds, where only the creator really knows it failed?</p>
-17:28 <+Complication> Or do they have additional reasons?</p>
-17:28 <+Complication> (besides, of course, the obvious - namely an app sitting idle)</p>
-17:29 < jrandom> an idle app wouldn't have idle tunnels (they'd be tested)</p>
-17:29 < jrandom> idle tunnels are failed for some reason or another</p>
-17:29 < jrandom> (either failed to be creted fully, or failed during operation)</p>
-17:30 <+Complication> Right, so all tunnels are tested anyway, and tunnel testing should cause traffic... indeed</p>
-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?</p>
-17:31 <+Complication> Are there any precious resources to be saved there?</p>
-17:32 < jrandom> none - a tunnel that isn't pushing data isn't using up resources</p>
-17:32 < jrandom> (ok, its using up some ram, perhaps 32 bytes)</p>
-17:32 <+Complication> Or perhaps, could it help a router to keep a better picture of its load and similar parameters...</p>
-17:33 < jrandom> predictions on bw usage bsed on the tunnel history is certainly an open question</p>
-17:33 <+Complication> Or would it just be pointless work, and it's best to wait until it expires naturally?</p>
-17:33 <+Complication> (like it does now)</p>
-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</p>
-17:34 <+Complication> Aha, so no gain...</p>
-17:34 <+Complication> Thanks, that was basically all I wanted to ask about it :)</p>
-17:34 < jrandom> np, understandable concern</p>
-17:34 < jrandom> ok, anyone have anything else for the meeting?</p>
-17:35 <+Complication> Yeah, if one did predictions, the percentage of idling tunnels might tilt estimates</p>
-17:35 <+Complication> (if it varied significantly)</p>
-17:36 < jrandom> aye, we'd want to keep idle % as part of the estimate</p>
-17:36 < jrandom> (we used to - see the RouterThrottleImpl.allowTunnel method)</p>
-17:37 <+Complication> Oh, didn't know that :)</p>
-17:37 < jrandom> and note the new comment:</p>
-17:38 < jrandom>  // ok, ignore any predictions of 'bytesAllocated', since that makes poorly</p>
-17:38 < jrandom>  // grounded conclusions about future use (or even the bursty use).  Instead,</p>
-17:38 < jrandom>  // simply say "do we have the bw to handle a new request"?</p>
-17:39  * Complication is still browsing towards the file, but thanks :)</p>
-17:39 < jrandom> w3rd</p>
-17:40 < jrandom> ok, if there's nothing else for the meeting...</p>
-17:40  * jrandom winds up</p>
-17:41  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/176.rst b/i2p2www/meetings/176.rst
new file mode 100644
index 00000000..d221fd98
--- /dev/null
+++ b/i2p2www/meetings/176.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 18, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/177.log b/i2p2www/meetings/177.log
index 6d0cf70e..213ec9ed 100644
--- a/i2p2www/meetings/177.log
+++ b/i2p2www/meetings/177.log
@@ -1,154 +1,148 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 177{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 25, 2005</h3>
-<div class="irclog">
-16:12 < jrandom> 0) hi</p>
-16:12 < jrandom> 1) Net status and 0.6.1.17</p>
-16:12 < jrandom> 2) I2Phex</p>
-16:13 < jrandom>  3) ???</p>
-16:13 < jrandom> 0) hi</p>
-16:13  * jrandom waves</p>
-16:13 <@cervantes> 'lo</p>
-16:13 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-April/001283.html</p>
-16:14 < jrandom> while y'all skim that, lets jump into 1) Net status </p>
-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</p>
-16:15 <@cervantes> (yay!)</p>
-16:15 < jrandom> still not where we need to be, but it pretty much sorts out the main issues we were seeing</p>
-16:15 < jrandom> aye, 'tis nice to have halfway decent tunnel build rates again, at 2+ hop tunnels :)</p>
-16:16  * jrandom has 50%+ success rates on another router w/ 1hop tunnels</p>
-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</p>
-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</p>
-16:17  * cervantes sparks up azureus</p>
-16:18 <+Complication> This morning, I recorded client tunnel (length 2 +/- 1) success rates near 35%</p>
-16:18 <+Complication> Currently it's lower, since I tried making some modifications, and the latest of them wasn't so great :D</p>
-16:18 <@cervantes> jrandom: well done tracking that down - we were beginning to look like freenet for a bit :)</p>
-16:19 < jrandom> *cough* ;)</p>
-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</p>
-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</p>
-16:21 <@cervantes> *cough* did I say freenet, I meant tor</p>
-16:21 <+fox> <inkeystring> :-)</p>
-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</p>
-16:22 < jrandom> (rather than sending more tunnel build attempts)</p>
-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?</p>
-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 :/</p>
-16:23 < jrandom> the receiver can NACK, and we've got hooks for ECN, but they haven't been necessary</p>
-16:23 <+fox> <inkeystring> yeah the debate has resurfaced on freenet-dev :-) still no silver bullet</p>
-16:24 <+fox> <inkeystring> cool, thanks for the information</p>
-16:24 <+Complication> They're using UDP too these days, aren't they?</p>
-16:24 < jrandom> currently, the highly congested peers have trouble not with per-peer throttling, but with the breadth of the peer comm</p>
-16:24 <+Complication> (as the transport protocol)</p>
-16:24 <+fox> <inkeystring> breadth = number of peers?</p>
-16:24 < jrandom> yes</p>
-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</p>
-16:25 < jrandom> so they can get by with just 20-30 peers</p>
-16:25 < jrandom> (directly connected peers, that is)</p>
-16:26 <+fox> <inkeystring> i guess that's good news for nat hole punching, keepalives etc?</p>
-16:26 < jrandom> otoh, w/ 2-300 active SSU connections, a 6KBps link is going to have trouble</p>
-16:26 < jrandom> aye</p>
-16:26 <+fox> <inkeystring> Complication: yes</p>
-16:27 <+fox> <inkeystring> (in the 0.7 alpha)</p>
-16:27 <+Complication> Aha, then they're likely facing some similar stuff</p>
-16:27 <+Complication> I hope someone finds the magic bullet :D</p>
-16:27 < jrandom> in a different way though.  the transport layer is a relatively easy issue</p>
-16:27 <+fox> <inkeystring> i think they might have reused some of the SSU code... or at least they talked about it</p>
-16:27 < jrandom> (aka well studied for 30+ years)</p>
-16:28 < jrandom> but i2p (and freenet) load balancing works at a higher level than point to point links, and has different requirements</p>
-16:28 <+fox> <inkeystring> yeah it's the interaction with routing that's tricky</p>
-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)</p>
-16:30 <+fox> <inkeystring> so there's no efficiency loss if you avoid an overloaded peer...</p>
-16:30 <+fox> <inkeystring> whereas in freenet, routing around an overloaded peer could increase the path length</p>
-16:30 <+fox> <inkeystring> anyway sorry this is OT</p>
-16:31 < jrandom> np, though explaining why the changes in 0.6.1.17 affect our congestion collapse was relevent :)</p>
-16:31 < jrandom> ok, anyone else have anything for 1) Net status?</p>
-16:32 <+Complication> Well, as actually mentioned before, while running pure .17, I observed a noticable periodism in bandwidth and active peers</p>
-16:32 <+Complication> And a few other people seem to experience it too, though I've got no clue about how common it is</p>
-16:33 <+Complication> I've been wondering about its primary causes, mostly from the perspective of tunnel throttling, but no solution yet</p>
-16:33 <+Complication> I managed to get my own graphs to look flatter, but only at the cost of some overall deterioration</p>
-16:33 <+Complication> Tried modifications like:</p>
-16:34 <+Complication> > _log.error("Allowed was " + allowed + ", but we were overloaded, so ended up allowing " + Math.min(allowed,1));</p>
-16:34 <+Complication> (this was to avoid it totally refraining from build attempts for its own tunnels)</p>
-16:35 < jrandom> ah right</p>
-16:35 <+Complication> (oh, and naturally the loglevel is wacky, since I changed those for testing)</p>
-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)</p>
-16:36  * perv just shot his system :(</p>
-16:36 <+Complication> But I tried some things like that, and tried reducing the growth factor for tunnel counts</p>
-16:36 < perv> is there an undelete for reiser4?</p>
-16:36 < jrandom> basically, if we just act as if tunnels expire (randomly) earlier than they actually do, it should help</p>
-16:36 <+Complication> Currently reading the big "countHowManyToBuild" function in TunnelPool.java :D</p>
-16:36 <+Complication> But I've not read it through yet</p>
-16:37 < jrandom> (though it'd obviously increase the tunnel build frequency, which prior to 0.6.1.17, wouldn't have been reasonable)</p>
-16:37 <+Complication> perv: there is something</p>
-16:37 < jrandom> hmm, putting a randomization in there would be tough Complication, as we call that function quite frequently</p>
-16:38  * perv considers salvaging and switching to gentoo</p>
-16:38 < jrandom> what i'd recommend would be to look at randomizing the expiration time of successfully built tunnels</p>
-16:38 <+Complication> perv: you're better off with reiser than ext3, certainly</p>
-16:38 <+Complication> perv: but I don't know it by heart</p>
-16:38 <+Complication> jrandom: true, sometimes it could overbuild this way</p>
-16:38 < jrandom> (so that the existing countHowManyToBuild thinks it needs them before it actually does)</p>
-16:38 <+Complication> (and sometimes it inevitably overbuilds, when tunnels break and it gets hasty)</p>
-16:40 <+Complication> Hmm, a possibility I've not considered...</p>
-16:41 <+Complication> Either way, playing with it too, but no useful observations yet</p>
-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 ;)</p>
-16:43 < spinky> Is there a stat where you can see the amount of overhead the i2p network adds to the application data?</p>
-16:43 < jrandom> "overhead" is such a loaded term... ;)</p>
-16:43 < jrandom> we call it the cost of anonymity ;)</p>
-16:43 < spinky> hehe</p>
-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)</p>
-16:45 < jrandom> ((last i measured))</p>
-16:45 < jrandom> but thats really lab conditions</p>
-16:45 < jrandom> live net is much more complicated</p>
-16:47 < spinky> Right, I meant just the amount of extra data used for setting up tunnels, keys, padding etc </p>
-16:47 < spinky> ...compared to the application data transferred</p>
-16:47 < jrandom> depends on the message framing, congestion, tunnel build success rates, etc</p>
-16:48 < jrandom> a 2 hop tunnel can be built by the network bearing 20KB</p>
-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</p>
-16:48 <+Complication> But I never got around to doing a clean measurement between my two nodes</p>
-16:48 <+Complication> Some day, I'll get back to that, though</p>
-16:49 < jrandom> Complication: its pretty tough with chatty apps, much simpler to measure wget :)</p>
-16:49 <+Complication> How very true</p>
-16:50 <+Complication> In what I managed to try, no resemblance of precision was involved</p>
-16:54 < jrandom> ok, if there's nothing else on 1), lets slide on over to 2) I2Phex</p>
-16:55 < jrandom> Complication: whatcha upta?  :)</p>
-16:55 <+Complication> Well, yesterday's commit was a fix to certain problems which some people experienced with my silly first-run detector</p>
-16:56 <+Complication> The first-run detector is now less silly, and bar reported that it seemed to start behaving normally</p>
-16:56 <+Complication> However, since I2Phex seems runnable already in current network conditions,</p>
-16:56 <+Complication> I'll try finding the rehash bug too.</p>
-16:57 <+Complication> If I only can</p>
-16:57 < jrandom> cool, i know that one has been haunting you for months now </p>
-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</p>
-16:58 < jrandom> but nice to hear the startup fix is in there</p>
-16:58 < jrandom> ah word</p>
-16:58 <+Complication> =is that</p>
-16:58 <+Complication> I can't confirm currently if mainline Phex has it or not, though - never seen it personally there</p>
-16:59 < jrandom> (intermittent bugs)--</p>
-16:59 <+Complication> It's difficult to cause in controlled fashion, and thus difficult to find</p>
-17:00 <+Complication> And on my side, that's about all currently</p>
-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</p>
-17:01 < jrandom> aye, likely</p>
-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</p>
-17:02 < jrandom> and new destination contacts require elG instead of aes</p>
-17:02 <+Complication> But I've not read or written any actual code towards that goal yet</p>
-17:04 < jrandom> k np.  perhaps the mythical i2phex/phex merge'll bundle a solution :)</p>
-17:04 <+Complication> And on my part, that's about all the news from the I2Phex front...</p>
-17:04 < jrandom> cool, thanks for the update and the effort looking into things!</p>
-17:05 < jrandom> ok, lets jump on over to 3) ???</p>
-17:05 < jrandom> anyone have anything else to bring up for the meeting?</p>
-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 :)</p>
-17:05 <+Complication> :D</p>
-17:06 < jrandom> thanks for your patience along the way - supporting low bw users is critical</p>
-17:06 <@cervantes> lsmith: that's really good to</p>
-17:06 <@cervantes> * Connection Reset</p>
-17:06 < jrandom> heh</p>
-17:07 < lsmith> :)</p>
-17:09 < jrandom> oh, one other thing of note is that zzz is back, and with 'im comes stats.i2p :)</p>
-17:09 < jrandom> [wewt]</p>
-17:11 <+Complication> A quite useful source of comparison data :)</p>
-17:11 < jrandom> mos' def'</p>
-17:11 < jrandom> ok, anyone have anything else for the meeting?</p>
-17:13 < jrandom> if not...</p>
-17:13 < jdot> i have a post-baf question or two</p>
-17:13 < jrandom> heh ok, then lets get the baffer rollin' :)</p>
-17:13  * jrandom winds up...</p>
-17:13  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/177.rst b/i2p2www/meetings/177.rst
new file mode 100644
index 00000000..ab96b52d
--- /dev/null
+++ b/i2p2www/meetings/177.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 25, 2005
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/178.log b/i2p2www/meetings/178.log
index d385f2cc..1c87757f 100644
--- a/i2p2www/meetings/178.log
+++ b/i2p2www/meetings/178.log
@@ -1,41 +1,35 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 178{% endblock %}
-{% block content %}<h3>I2P dev meeting, May 2, 2006</h3>
-<div class="irclog">
-16:09 < jrandom> 0) hi</p>
-16:09 < jrandom> 1) Net status</p>
-16:09 < jrandom> 2) Syndie status</p>
-16:09 < jrandom> 3) ???</p>
-16:09 < jrandom> 0) hi</p>
-16:09  * jrandom waves</p>
-16:10 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001285.html</p>
-16:11 < jrandom> ok, while y'all read through that exciting mail, lets jump on in to 1) Net status</p>
-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</p>
-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</p>
-16:15 < jrandom> (namely, randomize the tunnel expirations /correctly/, unlike the broken randomization before)</p>
-16:16 < jrandom> that, plus the improved ssu and tunnel test scheduling should help, but to what dgree, i'm not entirely sure yet</p>
-16:17 < jrandom> ok, thats about all i have on that at the moment.  anyone have any questions/comments/concerns on 1) Net status?</p>
-16:18 < green> humm, max bw limits are never reached and this is really far from previous</p>
-16:18 < green> like in 1é-7</p>
-16:18 < green> s/1é-7/.12-7</p>
-16:18 < jrandom> how is your bw share percentage set?  thats now a very powerful control</p>
-16:19 < green> 80%</p>
-16:19 < green> but only about 40% of total bw is used</p>
-16:20 < green> this is just a "do nothing router" :P</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.*)</p>
-16:21 < jrandom> the periodicity seen in tunnel requests often causes people to detect overload when it isn't really there</p>
-16:21 < jrandom> (because routers have excess capacity at other times, just not when they're being spiked)</p>
-16:22 < green> tunnel.reject.30 is very flat like 1,00 over 14 025,00 events</p>
-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</p>
-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)</p>
-16:27 < jrandom> ok, if there's nothing else on 1) Net status, lets slide on over to 2) Syndie status</p>
-16:27 < jrandom> I don't have much more to add to whats in the email regarding syndie, just wanted to give an update</p>
-16:28 < jrandom> ok, as such, unless there's something someone wants to bring up wrt syndie, lets jump on to ol' faithful, 3) ???</p>
-16:28 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-16:31  * tethra would like to say "thanks" (again) for .17, as it has been muchos improvement</p>
-16:33 < jrandom> glad to help, and there's more stuff on the way</p>
-16:33 < jrandom> ok, but if there's nothing else for toay's meeting...</p>
-16:33  * jrandom winds up</p>
-16:33  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/178.rst b/i2p2www/meetings/178.rst
new file mode 100644
index 00000000..d289a262
--- /dev/null
+++ b/i2p2www/meetings/178.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 2, 2006
+============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/179.log b/i2p2www/meetings/179.log
index 9f41502a..0806fb2f 100644
--- a/i2p2www/meetings/179.log
+++ b/i2p2www/meetings/179.log
@@ -1,67 +1,61 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 179{% endblock %}
-{% block content %}<h3>I2P dev meeting, May 9, 2006</h3>
-<div class="irclog">
-16:31 < jrandom> 0) hi</p>
-16:31 < jrandom> 1) Net status and 0.6.1.18</p>
-16:31 < jrandom> 2) baz</p>
-16:31 < jrandom> 3) ???</p>
-16:31 < jrandom> 0) hi</p>
-16:31  * jrandom waves</p>
-16:32 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-May/001288.html</p>
-16:32 < jrandom> while y'all read through that, lets jump on in to 1) Net status and 0.6.1.18</p>
-16:33 < jrandom> the past week has been pretty bumpy on irc & the net in general</p>
-16:33 <+Complication> Watching the graphs, but haven't noticed a perceivable change yet</p>
-16:33 <+Complication> Only the beginning too, of course</p>
-16:34 < jrandom> aye, its only been a few hours, with under 20% of the net upgraded</p>
-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</p>
-16:35 <+Complication> Indeed, it helps to see (as much as seeing is possible) what changes what, and in which direction</p>
-16:36 <+Complication> If one deploys everything at once, figuring out what worked may be very tough</p>
-16:38 < tmp> *sigh* </p>
-16:38  * tmp dreams of IRC stability.</p>
-16:39 < jrandom> aye, on all fronts ;)</p>
-16:39 <+fox> <roderick_spod1> Roderick dreams of big tits.</p>
-16:39 < jrandom> (this is why we can filter the meeting logs... ;)</p>
-16:40 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.18?</p>
-16:41 < jrandom> if not, lets hop on over to 2) </p>
-16:42 < jrandom> not much more to add here, just giving a status update on some w32/w64 support</p>
-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</p>
-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.</p>
-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)</p>
-16:47 < jrandom> ok, if there's nothing else, lets move on over to 3) ???</p>
-16:47 < jrandom> anyone have anything else to bring up for the meeting?</p>
-16:48 < cervantes> just to say "nice one bar" for his cool donation </p>
-16:48 <+Complication> Well, there was a question in the forum about uptimes presented in NetDB...</p>
-16:48  * Complication seconds that</p>
-16:49 <+Complication> 'bout the uptimes, if you recall, I fuzzified them slightly in March...</p>
-16:49 < cervantes> must have missed that amongst the odci.gov rants</p>
-16:50 < tmp> What on earth are you doing on that side roderick_spod?</p>
-16:50 < jrandom> aye Complication </p>
-16:50 <+Complication> Well, since the question was raised, I wondered if they could be fuzzified further, or would it hurt ability to debug?</p>
-16:52 < jrandom> i'm not sure of the point - with careful analysis, all of the stat data can reveal a bunch of information</p>
-16:52 < arse> do you guys think the network periodicity is gonna subside</p>
-16:52 < jrandom> when its time, we will just turn off the stat publhshing whatsoever</p>
-16:52 <+Complication> We haven't recently had any router-restarting ones, but that's only recently...</p>
-16:52 < jrandom> arse: yes</p>
-16:52 <+Complication> (and partly because the watchdog lacks teeth)</p>
-16:54 <+Complication> True, it's pretty inevitable that during this phase, some info must be out there</p>
-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</p>
-16:55 < jrandom> erm, wait, no, thats not true</p>
-16:56 < jrandom> never mind me.  yeah, it just adds a small variation</p>
-16:56 <+Complication> Heh, I'm trying to post a reply, but get "no post mode specified" currently</p>
-16:57 <+Complication> Yeah, there's delay involved, and besides, how often was this info published? Not very frequently, IIRC?</p>
-16:57 <+Complication> Basically, if I offered to somewhat decrease the precision there, would you mind?</p>
-16:58 < jrandom> a new signed entry is published eery 5-15 minutes, but that is only published to the netDb, not all peers</p>
-16:58 < jrandom> peers only get the updated one when they either search for it or they reconnect</p>
-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</p>
-17:01 <+Complication> I'll try to keep it reasonable, then :)</p>
-17:01 < jrandom> heh cool, thanks Complication </p>
-17:04 < jrandom> *cough* (and consistent ;) ok, anyone have anything else for the meeting?</p>
-17:04 <+Complication> sidenote: neat, the "post mode" bug yielded to persistence, and I could post a reply too :)</p>
-17:05 < jrandom> w3rd Complication </p>
-<i>offtopic messages snipped</i></p>
-17:08 < jrandom> ok, if there's nothing else...</p>
-17:08  * jrandom winds up</p>
-17:09  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/179.rst b/i2p2www/meetings/179.rst
new file mode 100644
index 00000000..7ac912cf
--- /dev/null
+++ b/i2p2www/meetings/179.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 9, 2006
+============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/18.log b/i2p2www/meetings/18.log
index ca960a73..1a8dbf3e 100644
--- a/i2p2www/meetings/18.log
+++ b/i2p2www/meetings/18.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 18{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 18</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Nov 05 23:14:03 2002
 23:14 < logger> test
 23:55 < nop> hineo
@@ -27,8 +20,8 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> 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
@@ -164,9 +157,9 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> < #elif defined(__FreeBSD__) || defined(__MACH__)
 00:32 < Neo> ---
-00:32 < Neo> > #elif defined(__FreeBSD__) || defined(__MACH__) || defined(__OpenBSD__)
+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
@@ -175,5 +168,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 00:37 < nop> any more questions?
 00:42 < nop> thanks for attending
 00:42 < nop> .
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/18.rst b/i2p2www/meetings/18.rst
new file mode 100644
index 00000000..007a6c7e
--- /dev/null
+++ b/i2p2www/meetings/18.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 5, 2002 @ 23:00 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/180.log b/i2p2www/meetings/180.log
index 5aeb118c..916303e3 100644
--- a/i2p2www/meetings/180.log
+++ b/i2p2www/meetings/180.log
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 180{% endblock %}
-{% block content %}<h3>I2P dev meeting, May 16, 2006</h3>
-<div class="irclog">
 < cervantes>  moo: http://dev.i2p.net/pipermail/i2p/2006-May/001289.html
 < cervantes>  0) hi
 < cervantes>  1) jrandom's not here
@@ -37,11 +33,11 @@
 < 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
+< 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?
+< 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 :)
@@ -51,16 +47,16 @@
 < 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)
+< 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?
+< 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
+< 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?"
@@ -77,7 +73,5 @@
 < cervantes>  in that case...
 * cervantes winds up
 * cervantes *baffs* the meeting closed
-< fox>  < duck>  thx for taking care of the meeting
+< 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 :)
-</div>
-{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/180.rst b/i2p2www/meetings/180.rst
new file mode 100644
index 00000000..d16439cf
--- /dev/null
+++ b/i2p2www/meetings/180.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 16, 2006
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/181.log b/i2p2www/meetings/181.log
index e00e7e9d..14d99618 100644
--- a/i2p2www/meetings/181.log
+++ b/i2p2www/meetings/181.log
@@ -1,58 +1,52 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 181{% endblock %}
-{% block content %}<h3>I2P dev meeting, May 30, 2006</h3>
-<div class="irclog">
-16:00 < jrandom> 0) hi</p>
-16:00 < jrandom> 1) Net status</p>
-16:00 < jrandom> 2) Peer filtering</p>
-16:00 < jrandom> 3) Syndie status</p>
-16:00 < jrandom> 4) ???</p>
-16:00 < jrandom> 0) hi</p>
-16:00  * jrandom waves</p>
-16:01 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-May/001291.html</p>
-16:01 < jrandom> (up an hour early, even [or a few weeks late, if you want to pick on me ;])</p>
-16:02 < jrandom> ok, lets jump on in to 1) Net status</p>
-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</p>
-16:03 < jrandom> i don't have much more to add on that though, unless anyone has any questions/concerns on 1)?</p>
-16:03 <@frosk> i get days of irc connection with .19, so no complaints here</p>
-16:04 < jrandom> nice</p>
-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</p>
-16:06 < jrandom> ok, anyone have anything else on 1) Net status, or shall we move on over to 2)Peer filtering?</p>
-16:07 < jrandom> [insert moving sounds here]</p>
-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</p>
-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)</p>
-16:11 < bar> reset them once or repeatedly?</p>
-16:11 < bar> s/reset/killing</p>
-16:11 < jrandom> at least once, but also on all subsequent drastic config changes</p>
-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)</p>
-16:13 < bar> gotcha</p>
-16:14 < jrandom> ok, i dont think i have anything else on that topic atm, unless anyone has any questions/comments/concerns?</p>
-16:15 < jrandom> (hopefully there'll be a build out in the next day or two, release after it stabilizes)</p>
-16:17 < jrandom> ok, hitting 3) briefly..</p>
-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</p>
-16:19 < jrandom> (but still don't talk to me about mingw/gcj ;)</p>
-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?</p>
-16:21 <@cervantes> how's mingw/gcj support coming along?</p>
-16:21 <@cervantes> *duck*</p>
-16:22 <@cervantes> do we get some screenies before the june release? :)</p>
-16:23 < jrandom> i'm sure i'll try to rope some eager volunteers into pre-release testing ;)</p>
-16:23 < tethrar> count me in ;)</p>
-16:23 < jrandom> w3wt</p>
-16:24 < jrandom> ok, lets swing over to the bullet point i know y'all have been waiting for: 4) ???</p>
-16:24 < jrandom> wazaaaap?</p>
-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</p>
-16:25 < jrandom> is 30% still too cpu intensive?  what makes it not "real"?</p>
-16:25 < jrandom> but no, i do not have the math or c7 asm skill to make a better libGMP for C7.</p>
-16:25 < green> sure too cpu intensive with 100% cpu load :P</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</p>
-16:26 < jrandom> and for that, yes, there is lots we've got on the way.</p>
-16:26 < jrandom> (e.g. reducing the connection reestablishments, improving tunnel build success rates, etc)</p>
-16:27 < jrandom> ((and not getting as many tunnel requests if the router is not capable of handling them))</p>
-16:29 < green> humm, this is with a dedicated box with 100Mb/s so It should be capable</p>
-16:30 < jrandom> no, bandwidth is not the only resource constrained here, cpu obviously is ;)</p>
-16:33 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:36 < jrandom> *cough*</p>
-16:37  * jrandom winds up</p>
-16:37  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/181.rst b/i2p2www/meetings/181.rst
new file mode 100644
index 00000000..3e675e5c
--- /dev/null
+++ b/i2p2www/meetings/181.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 30, 2006
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/182.log b/i2p2www/meetings/182.log
index f91c1006..2accbbab 100644
--- a/i2p2www/meetings/182.log
+++ b/i2p2www/meetings/182.log
@@ -1,63 +1,57 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 182{% endblock %}
-{% block content %}<h3>I2P dev meeting, June 13, 2006</h3>
-<div class="irclog">
-16:05 < jrandom> 0) hi</p>
-16:05 < jrandom> 1) Net status</p>
-16:05 < jrandom> 2) 0.6.1.21</p>
-16:05 < jrandom> 3) ???</p>
-16:05 < jrandom> 0) hi</p>
-16:05  * jrandom waves</p>
-16:05 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-June/001293.html</p>
-16:06 < jrandom> while y'all dig through that, lets jump on over to 1) Net status</p>
-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</p>
-16:07 < modulus> .20 works pretty well for me, where .19 didn't work at all, but i guess that's just anecdote.</p>
-16:08 < jrandom> you say anecdote, i say data point :)</p>
-16:08 < jrandom> there'll be a new release tomorrow though which should improve things a bit</p>
-16:09 < jrandom> oh, i suppose thats 2)... anyone have anything else on 1) net status they'd like to discuss first?</p>
-16:10 < jrandom> if not, lets jump to 2) 0.6.1.21</p>
-16:11 < jrandom> 0.6.1.20-7 is cvs head, and will become 0.6.1.21 sometime tomorrow</p>
-16:12 < jrandom> it should improve the ability for fast peers to handle more tunnels, which in turn should improve everyone's success rates</p>
-16:13  * jrandom currently gets ~30-60% success rates (excluding expirations) - hopefully the expirations will be cut further</p>
-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</p>
-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)</p>
-16:15 < jrandom> ok, lets shimmy on over to 3) ???</p>
-16:15 < jrandom> anyone have anything else they want to bring up?</p>
-16:15 < user-land> are there recommendations for routers that can take the load from i2p ?</p>
-16:15 < NickyB> yes</p>
-16:15 < NickyB> about the ircproxy</p>
-16:15 < user-land> and what holds up i2p 1.0 ? :-)</p>
-16:16 < jrandom> user-land: to the first question, no (other than "patience")</p>
-16:16 < jrandom> to the second question, see the first question</p>
-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....</p>
-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)</p>
-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</p>
-16:19 < NickyB> err, for my console, i did a change in client.config</p>
-16:19 < NickyB> clientApp.0.args=7657 192.168.0.1 ./webapps/</p>
-16:19 < NickyB> 192.168.0.1  is the adresse gived to all my proxy </p>
-16:19 < NickyB> Reachable by:</p>
-16:20 < NickyB> LAN Hosts</p>
-16:20 < NickyB> 192.168.0.1</p>
-16:20 < NickyB> and my 4444 is not reachable on the net, but my 6668 yes</p>
-16:20 < jrandom> NickyB: you need to stop and start that particular i2ptunnel proxy for the changes to take effect</p>
-16:21 < jrandom> though, perhaps we can continue debugging after the meeting (as this is all logged ;)</p>
-16:21 < NickyB> will try, thank you</p>
-16:21 < jrandom> np, thanks for your patience</p>
-16:21 < jrandom> ok, anyone have anything else for the meeting?</p>
-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 ...</p>
-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)</p>
-16:23 < user-land> my hardware router crashed under i2p load. that is why i asked for hardware recommendations.</p>
-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</p>
-16:24 < user-land> thanks.</p>
-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</p>
-16:26 < fedo> ok Jr</p>
-16:26 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:28 < user-land> thanks for your efforts :-)</p>
-16:28  * ashter2 seconds user-land</p>
-16:28 < user-land> and http://www.savetheinternet.com/</p>
-16:29 < jrandom> (bah, never trust politics to defend us.  use technology)</p>
-16:29 < jrandom> ok, if there's nothin' else...</p>
-16:30  * jrandom winds up</p>
-16:30  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/182.rst b/i2p2www/meetings/182.rst
new file mode 100644
index 00000000..9572a235
--- /dev/null
+++ b/i2p2www/meetings/182.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, June 13, 2006
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/183.log b/i2p2www/meetings/183.log
index 165e9570..8efac097 100644
--- a/i2p2www/meetings/183.log
+++ b/i2p2www/meetings/183.log
@@ -1,191 +1,185 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 183{% endblock %}
-{% block content %}<h3>I2P dev meeting, August 1, 2006</h3>
-<div class="irclog">
-16:02 < jrandom> ok, might as well get this rolling</p>
-16:03 < jrandom> hi, pre-meeting notes posted up at http://dev.i2p.net/pipermail/i2p/2006-August/001304.html</p>
-16:03 < jrandom> rather than have me essentially reread that message to y'all here, lets just skip to our standard ??? section -</p>
-16:04 < jrandom> anyone have anything they want to bring up and discuss?</p>
-16:04 <@cervantes> eerm</p>
-16:04  * cervantes scurries to read the post</p>
-16:05 <+Complication> With regard to network status, all fine over here...</p>
-16:05 <+Complication> But one question (actually relaying from forum) about the NTCP transport,</p>
-16:06 <+Complication> namely, does it sound likely that activating it could cause someone CPU load issues (they were on XP)?</p>
-16:06 <@cervantes> I have to say I've actually been seeing lower CPU usage since switching over :)</p>
-16:07 < jrandom> well, you can't *deactivate* it (unless you've been reading the source code and know the magic incantation ;)</p>
-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</p>
-16:07 < jrandom> so, i assume they mean not accepting inbound ntcp connections</p>
-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.</p>
-16:07 < jrandom> (while still using outbound ntcp connections)</p>
-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)</p>
-16:08 <+Complication> ( http://forum.i2p/viewtopic.php?t=1815 )</p>
-16:08 < jrandom> when you establish an ntcp connection, you do a heavyweight crypto calculation (or three)</p>
-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</p>
-16:09 < jrandom> polecat: that wasn't ntcp's fault, it was the fault of a bad ntp server in the ntp pool</p>
-16:09 <+polecat> Yes.  So I can't handle that myself, apparantly.</p>
-16:09 < jrandom> (thanks to cervantes for tracking down that ntp server and getting the pool folks to !thwap 'em :)</p>
-16:10 < jrandom> ((and Complication for making it so we avoid those crazy bastards in the future :))</p>
-16:10 <@cervantes> heh I think their server watchdogs only work on weekdays ;-)</p>
-16:10 <+Complication> Well, the current avoidance is pretty limited</p>
-16:10 <@cervantes> http://www.pool.ntp.org/scores/216.52.237.153</p>
-16:11 <+Complication> I hope to get something more paranoid coded eventually</p>
-16:11 <+polecat> Oh, so enabling NTCP won't clock the CPU anymore?</p>
-16:11 < jrandom> (it never did polecat, 'twas a coincidence ;)</p>
-16:12 <+Complication> "clock" in which particular sense?</p>
-16:12 < jrandom> (see cervantes' link)</p>
-16:12  * polecat clocks Complication upside the head.</p>
-16:12 <@cervantes> whatcha smoking polecat</p>
-16:12 <+Complication> :P</p>
-16:12 <+polecat> Er, I mean, stole all clock cycles.  :)</p>
-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</p>
-16:13 <+Complication> That could steal plenty of CPU cycles, I think</p>
-16:13 <+Complication> Indeed, perhaps the person in the forum actually saw the same, and mis-correlated it? Have to ask...</p>
-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</p>
-16:14 < jrandom> there is nothing wrong with not enabling inbound ntcp.  </p>
-16:15 <@cervantes> Complication: the server was corrected mid-monday, so it might be worth seeing if they've had issues since then</p>
-16:15 < jrandom> ok, anyone else have something they want to discuss?</p>
-16:16 <+Complication> cervantes: indeed, could be worth a try</p>
-16:16 <@cervantes> I've had reports of some folk still losing leases periodically... is that a known problem?</p>
-16:16 <+void> how much does the ntcp implementation differ from ssu?</p>
-16:17 <+polecat> How do we tell if we lose leases?</p>
-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)</p>
-16:18 <+Complication> polecat: tunnels.jsp will show no tunnels for a particular tunnel pool (e.g. "shared clients")</p>
-16:18 < jrandom> cervantes: aye, our tunnel build success rates still aren't where they need to be</p>
-16:18 <+void> polecat: the router console says so</p>
-16:18 <+Complication> And like void says, the left sidebar of the console will tell so</p>
-16:19 <+polecat> I get those "No leases" messages a lot... that's what you mean, right?</p>
-16:19 <@cervantes> yup</p>
-16:20 <+polecat> That's usually what kills my IRC connection.  Thought it was normal!</p>
-16:21  * jrandom cringes</p>
-16:24 <+tethra> lol ;)</p>
-16:25 < jrandom> ok, anyone have anything else for the meeting?</p>
-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 ?</p>
-16:27 <+tethra> any news on feedspace, or should i just go to their eepsite?</p>
-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)</p>
-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)</p>
-16:29  * jrandom hasn't heard any news on feedspace</p>
-16:29 <@cervantes> cool</p>
-16:29 < jrandom> frosk: any word?  :)</p>
-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?</p>
-16:30 <@cervantes> <jrandom> DELETE FROM messages WHERE postedOn < NOW()-14*24*60*60;</p>
-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)</p>
-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</p>
-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)</p>
-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.</p>
-16:34 <+tethra> heheh</p>
-16:35 < jrandom> physical deletion is trivial, its the question of what posts to accept in the first place ;)</p>
-16:36 < jrandom> (i have no interest in making syndie into a movie distriution platform, etc)</p>
-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.</p>
-16:36 < jrandom> aye</p>
-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!</p>
-16:37 < jrandom> (manually allowing new ids, manually kickbanning ids that flood, etc)</p>
-16:37 < jrandom> there's even inherent support for that in the crypto polecat :)</p>
-16:37 <+polecat> Possibly a moderator signing approved messages for the BBS, and people collecting those approval lists from the moderator's blog.</p>
-16:38 <+polecat> Ooh excellent.</p>
-16:38 <@frosk> jrandom: been working on gui stuff lately, but it's been hard to combine with starting a new job :(</p>
-16:39  * cervantes contacts Human Resources to get frosk fired</p>
-16:40 < jrandom> ah cool, hopefully once syndie is out there pushing kludged http syndication we'll tempt you on it again ;)</p>
-16:40 <@frosk> at least my boss follows i2p development now :)</p>
-16:40  * jrandom waves to frosk's boss</p>
-16:40 <@frosk> oh yes, i'm still determined (damn it!) :)</p>
-16:40 < jrandom> (gives frosk more time off, we need 'im!)</p>
-16:41 <@cervantes> hopefully he won't read about how you've been posting classified company information onto your syndie blog</p>
-16:41 < bar> gui is good, we like gui. you're forgiven.</p>
-16:41 <+Complication> Hehe :)</p>
-16:41 <@frosk> it's weird to walk into his office and catch him reading syndie :)</p>
-16:41 < jrandom> hah awesome</p>
-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.</p>
-16:43 <@frosk> hehe yeah</p>
-16:43 <+tethra> haha</p>
-16:44 <@frosk> the gui (in swt) is/will be a testbed for all things feedspace, to kickstart it</p>
-16:44 < jrandom> r0x0r</p>
-16:45 <+void> jrandom: perhaps you should cross-post everything that goes onto the mailing lists to syndie as well?</p>
-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)</p>
-16:46 <+polecat> That'd be nice.  I can't seem to get the mailing list anymore.</p>
-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</p>
-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 </p>
-16:46 <@frosk> that makes sense</p>
-16:46 < jrandom> (iirc there's a post in my blog a while back explaining how to use the syndie cli to insert posts)</p>
-16:47 <+polecat> Currently one can make RSS feeds to feed into syndie, though it's kind of cludgy still.</p>
-16:47 < jrandom> cervantes: jdbc in event handlers, inline with jni and msvc callouts, of course ;)</p>
-16:47  * jrandom ducks</p>
-16:48 <+polecat> Microsoft Visual Classes?</p>
-16:49 <@cervantes> jrandom: so anything that can talk SQL can administer syndie then</p>
-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)</p>
-16:51 <+polecat> And since the database has two interfaces, JDBC, and SQL, a client communicating in either protocol can screw with syndie.</p>
-16:51 < jrandom> cervantes: well, yes and no - there's a good portion of the database thats encrypted, so not all fields are readable</p>
-16:51 <+void> will the current web interface still be there?</p>
-16:51 < jrandom> (jdbc == sql)</p>
-16:51 < jrandom> void: no</p>
-16:51 <+polecat> I thought you said that JDBC wasn't a stupid human readable protocol?</p>
-16:51 <+Complication> jdbc == java database interface, perhaps a bit similar to odbc</p>
-16:51 < jrandom> ((jdbc ~= sql))</p>
-16:51 <+Complication> Something you talk SQL over</p>
-16:52 <+void> jrandom: what will happen to syndie.i2p/syndiemedia.i2p.net?</p>
-16:52 <+polecat> Oh.  Well I never liked SQL anyway, for the record.</p>
-16:52 <@cervantes> jrandom: so it's best to create a top for syndieTools (tm) than to try and leech the data yourself</p>
-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</p>
-16:53 <+polecat> Why not submit bytecode as database queries, instead of archaic COBOL statements?</p>
-16:53 < jrandom> aye cervantes</p>
-16:53 < jrandom> !lart polecat</p>
-16:54 <+void> hehehe</p>
-16:54 <+polecat> Ah, my secret weakness.</p>
-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</p>
-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)))</p>
-16:54 < jrandom> lol</p>
-16:54 <+tethra> haha</p>
-16:55 <+Complication> feature proposal: instead of bytecode, why not submit live $agency agents as database queries? ;P</p>
-16:56 <+Complication> Would be far easier to validate for safety :P</p>
-16:56 <@cervantes> jrandom: gotcha</p>
-16:56 <+tethra> do they act like carrier pigeons under the right climate, Complication? </p>
-16:56 <+Complication> tethra: only if you manage to push them through the TCP stack intact :P</p>
-16:56 <+polecat> Yes, database queries over CPP!</p>
-16:57 <+Complication> I imagine that getting wrinkled in TCP might corrupt them</p>
-16:58 <+Complication> (sorry, should really keep jokes to #i2p-chat, but sometimes can't help)</p>
-16:58  * cervantes senses a baff is soon approaching</p>
-16:58 <+Complication> database queries as shellcode?</p>
-16:59 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:59 <+polecat> http://www.blug.linux.no/rfc1149/ <- we could tunnel i2p over this, really.</p>
-16:59  * Complication would rather stick with SQL</p>
-17:00 <+void> jrandom: do other langauges than java have libraries for hsqldb databases?</p>
-17:01 <+Complication> Oo would seem likely to, since they seem to use it</p>
-17:01 <+void> looks like a "no" to me</p>
-17:01 <+void> oh, hmm</p>
-17:01 <@cervantes> openoffice uses it so I would guess so</p>
-17:01 <+Complication> But I'm not sure what OpenOffice is written in</p>
-17:01 < jrandom> not that i know of.  but someone could run syndie against another jdbc database (mysql, oracle, etc)</p>
-17:01 < jrandom> oo uses java</p>
-17:02 <+void> what exactly does openoffice use this database for?</p>
-17:02 <+Complication> But seems to only partially use it</p>
-17:02 < jrandom> void: for pdf generation and for their access-like database app</p>
-17:02 < jrandom> (among other things)</p>
-17:02 <+Complication> Given that it recommends an external JRE</p>
-17:02 <+void> okay</p>
-17:03 <+void> it's a pain in the ass to write portable sql though</p>
-17:03 <+Complication> if one doesn't do triggers or stored procedures, shouldn't be a big pain, though</p>
-17:04 < jrandom> eh, its not that bad, and easy to externalize</p>
-17:04 <+void> especially when aiming oracle ;)</p>
-17:05 < jrandom> actually, hsqldb supports pl/sql ;)</p>
-17:06 < bar> are there any other plans for this database, such as for stats, peer profiles, netdb..?</p>
-17:06 < jrandom> no, this is syndie only</p>
-17:06 < bar> ok</p>
-17:07 < jrandom> (though when we ship the hsqldb code, we can use it in i2p 'for free')</p>
-17:07 <@cervantes> since syndie is not an I2P application, just an application that can run over I2P correct?</p>
-17:07 < jrandom> aye cervantes, there is no dependency upon i2p</p>
-17:07 <+Complication> Good to keep Syndie portable, since it might have other transports besides I2P</p>
-17:07 < bar> right</p>
-17:08 <+Complication> However, I take it wouldn't be difficult to run many hsqldb instances on the same machine</p>
-17:08 <+Complication> So if other apps would need it, it seems they could just use it</p>
-17:08 < jrandom> trivial, and 0-cost if you just use the in-jvm dataase</p>
-17:08 <+Complication> (use their own instance, preferably)</p>
-17:10 <+void> there's no jdbc driver for sqlite?</p>
-17:11 < jrandom> dunno, never used it</p>
-17:11 <+void> ah, looks like there is *something*</p>
-17:13 < jrandom> ok, anything else for the meeting?</p>
-17:13 < jrandom> if not...</p>
-17:13  * jrandom dinws up</p>
-17:13  * jrandom steps back</p>
-17:13  * jrandom winds up</p>
-17:13  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/183.rst b/i2p2www/meetings/183.rst
new file mode 100644
index 00000000..79d8b24c
--- /dev/null
+++ b/i2p2www/meetings/183.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 1, 2006
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/184.log b/i2p2www/meetings/184.log
index 8cec865b..454eb601 100644
--- a/i2p2www/meetings/184.log
+++ b/i2p2www/meetings/184.log
@@ -1,268 +1,262 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 184{% endblock %}
-{% block content %}<h3>I2P dev meeting, September 12, 2006</h3>
-<div class="irclog">
-16:06 < jrandom> 0) hi</p>
-16:06 < jrandom> 1) 0.6.1.25 and net status</p>
-16:06 < jrandom> 2) I2PSnark</p>
-16:06 < jrandom> 3) Syndie (what/why/when)</p>
-16:06 < jrandom> 4) Syndie crypto questions</p>
-16:06 < jrandom> 5) ???</p>
-16:06 < jrandom> 0) hi</p>
-16:06  * jrandom waves</p>
-16:06 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-September/001307.html</p>
-16:07 < jrandom> since those notes came up hours and hours ago, y'all should have already read them and have notes ready, right? ;)</p>
-16:07 < jrandom> jumping forward to 1) 0.6.1.25 and net status</p>
-16:08 < vulpine> <Complication> Regarding 0.6.1.25 seems to have worked fine over here, only one previously unseen error</p>
-16:08 < jrandom> cool, whats the prob?</p>
-16:08 < vulpine> * Complication searches logs</p>
-16:09 < jrandom> the net size seems larger than before, though still same orer of magnitude</p>
-16:09 < vulpine> <Complication> "Unknown error reading the net.i2p.data.i2np.GarlicMessage: wtf, fromLong got a negative? -840"</p>
-16:10 < vulpine> <Complication> Started with "ERROR [NTCP read 1 ] .router.tunnel.FragmentHandler: Error receiving fragmented message (corrupt?)"</p>
-16:10 < jrandom> ah ok cool, that one has been around for a long time, safe to ignore</p>
-16:11 < vulpine> <Complication> Single occurrence</p>
-16:11 < vulpine> <frosk> i've gotten several of that last one</p>
-16:11 < vulpine> * jrandom pokes fox</p>
-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"</p>
-16:12 < vulpine> <Complication> (seems non-significant too, maybe simple congestion)</p>
-16:12 < jrandom> aye, likely </p>
-16:13 < jrandom> irc is, obviously, a bit rough at the moment still</p>
-16:13 < jrandom> (but, for once, its not i2p's fault :)</p>
-16:14 < jrandom> ok, anyone have anything else for 1) Net status and 0.6.1.25?</p>
-16:15 < kostya213> just want to add that .25 fixed all my problems i've been having the past few months</p>
-16:15 < jrandom> wikked!</p>
-16:16 < vulpine> <green> please, change status calcul when only using NTCP</p>
-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)</p>
-16:17 < jrandom> but the status should be updated to take into consideration that udp is not the only transport</p>
-16:17 < jrandom> i'll get that fixed in the next rev, thanks</p>
-16:17 < vulpine> <green> jrandom : sure you don't tell, but i'm able to read code ;)</p>
-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 ;)</p>
-16:19 < vulpine> <green> sure, i could also juste display "OK" in console :)</p>
-16:19 < jrandom> true 'nuff</p>
-16:21 < jrandom> ok, lets jump on over to 2) I2PSnark </p>
-16:21 < jrandom> zzz doesn't seem to be over there atm</p>
-16:22 < jrandom> there are some changes zzz is working on to improve the scheduling in i2psnark</p>
-16:23 < jrandom> (its a bit.. simplistic atm iirc, though i'm not entirely certain of the mods zzz is hacking on)</p>
-16:23 < jrandom> ((but i look forward to the progress!))</p>
-16:25 < jrandom> ok, if there's nothing else on 2) I2PSnark, lets move forward to 3.*) Syndie stuff</p>
-16:26 < jrandom> lets jump in to 3.1) what is syndie first, since there's so much to cover</p>
-16:27 < jrandom> i got a few questions before the meeting regarding the encryption for posts</p>
-16:27 < jrandom> basically, posts are *symmetrically* encrypted - anyone with the symmetric key can read the post, as they're authorized</p>
-16:28 < jrandom> channel replies are asymmetrically encrypted to the public key associated with the channel/forum</p>
-16:28 < jrandom> some posts can use passphrase based encryption to generate the symmetric key for reading</p>
-16:29 < jrandom> and some posts can include the symmetric key in the post's readable headers (so that anyone can read it)</p>
-16:29 < modulus> what's the point of that last one?</p>
-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</p>
-16:29 < jrandom> modulus: so that everything is always encrypted, even publicly readable stuff</p>
-16:29 < jrandom> (so that trivial wiretapping is useless)</p>
-16:30 < modulus> right, i see.</p>
-16:31 < jrandom> ok, i think that covers the encryption questions that were asked before the meeting</p>
-16:31 < jrandom> does anyone have any questions on 3.1) what is syndie?</p>
-16:31 < jrandom> (I mean, more will be clarified as it is pushed out there, of course)</p>
-16:32 < vulpine> <void> hmm</p>
-16:33 < jrandom> que tal void?</p>
-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?</p>
-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</p>
-16:34 < jrandom> (aka you don't have to do frost-style "threading")</p>
-16:35 < vulpine> <void> ok, right</p>
-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</p>
-16:38 < vulpine> <Complication> One solution, of course, seemed for the author to specify a recommendation of whose replies clients should display</p>
-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"</p>
-16:38 < vulpine> <Complication> ..and for clients, unless they desire to research history, to follow this recommendation (or more specifically its latest version)</p>
-16:38 < jrandom> (and when they are no longer authorized, remove that key from the list of "keys allowed to post")</p>
-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</p>
-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</p>
-16:39 < vulpine> <Complication> "keys allowed to post" would be metadata attached to the author's latest post, or some other message, right?</p>
-16:39 < jrandom> good point kostya213, though we may be stuck with .dat then ;)</p>
-16:40 < jrandom> Complication: ah sorry, no, its like the current/old syndie- separate signed metadata posts for the forum/channel itself</p>
-16:40 < vulpine> * Complication believes that someone has even claimed .dat for something :)</p>
-16:40 < jrandom> yes, the application called "octet-stream" ;)</p>
-16:40 < vulpine> <void> it doesn't look like .syn is used for anything noteworthy</p>
-16:41 < vulpine> <Complication> Aha, special metadata posts... right, that could do it</p>
-16:41 < jrandom> oh neat, we get to syn!</p>
-16:41 < jrandom> (good eye void, thanks kostya213)</p>
-16:41 < vulpine> <void> hmm, "</p>
-16:41 < vulpine> <void> hmm, "Word Synonym File", Company: Microsoft</p>
-16:42 < jrandom> well, i'm sure we'll work 'er out</p>
-16:42 < kostya213> yes it's used by word</p>
-16:42 < vulpine> <void> but we might as well ignore that :)</p>
-16:42 < kostya213> don't lose hope, i think it's possible to find something that won't cause problems with widely used mimetypes</p>
-16:43 < jrandom> ok, anything else on 3.1) What is syndie?</p>
-16:43 < vulpine> <void> err, then again, why would we stick with three-letter extensions? it's a relic from the DOS ages</p>
-16:43 < kostya213> one thing that must be asked, why limit to a three-letter extension? nobody uses DOS anymore</p>
-16:44 < jrandom> heh</p>
-16:44 < kostya213> jinx on void</p>
-16:44 < kostya213> .syndie seems good to me</p>
-16:44 < vulpine> <void> .synd wouldn't conflict with any</p>
-16:44 < kostya213> good as well</p>
-16:45 < vulpine> <void> damn lag :(</p>
-16:48 < jrandom> ok, lets jump on over to 3.2) Why does Syndie matter?</p>
-16:48 < vulpine> <void> jrandom: wait</p>
-16:48 < cervantes> (because you say it does)</p>
-16:48  * jrandom waits</p>
-16:48 < jrandom> !thwap cervantes ;)</p>
-16:48 < vulpine> <void> the status notes post mentions that an avatar can be attached to a post, otherwise a default will be used</p>
-16:49 < vulpine> <void> but what if a person wants to have several predefined avatars instead of a single "default" one?</p>
-16:49 < jrandom> aye, the author can include a default avatar in their own channel's metadata</p>
-16:49 < vulpine> <void> attaching the other one every time isn't going to be efficient</p>
-16:49 < jrandom> good question void - lets jump to that script code in the notes</p>
-16:50 < jrandom>     listauthkeys --authorizedOnly true</p>
-16:50 < jrandom>     authenticate 0</p>
-16:50 < vulpine> <void> (?)</p>
-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</p>
-16:51 < jrandom> so, that identity has its own channel, and that channel has its own metadata, which may include an avatar</p>
-16:51 < vulpine> <void> hmm, a separate identity means a separate keypair?</p>
-16:51 < jrandom> yes</p>
-16:51 < vulpine> <void> what if a person wants to have several avatars on a single identity?</p>
-16:52 < jrandom> they have a default avatar on their channel metadata, and they can override it on a per-message basis</p>
-16:52 < kostya213> dubious value</p>
-16:52 < vulpine> <void> several "default" avatars he can choose from</p>
-16:52 < vulpine> <void> or am i splitting hair here? :)</p>
-16:53 < jrandom> ah, i understand what you're saying.  nah, not supported at first</p>
-16:53 < jrandom> maybe later</p>
-16:53 < vulpine> <void> true kostya213, never mind then</p>
-16:53 < vulpine> <void> :)</p>
-16:53 < jrandom> (but the avatars will be very limited in size, so shouldn't be much trouble to include)</p>
-16:53 < vulpine> * Complication thinks the adding of per-message ones could be coded to be easy enough</p>
-16:53 < vulpine> <void> so, 3.1) What is syndie?</p>
-16:53 < vulpine> <Complication> (eventually)</p>
-16:54 < vulpine> * cervantes glues the irc servers together</p>
-16:54 < vulpine> <void> Complication: jrandom just said he is going to do that already :)</p>
-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)</p>
-16:54 < vulpine> <Complication> latency, latency...</p>
-16:54 < jrandom> ok, anything else for 3.1?</p>
-16:54 < jrandom> if not, lets jump to 3.2</p>
-16:55 < vulpine> <void> i think that's all</p>
-16:55 < jrandom> wr0d.</p>
-16:56 < jrandom> other than cervantes' snark, anyone have any questions/comments/concernts re "why"?</p>
-16:56 < jrandom> (er, "concerns")</p>
-16:58 < vulpine> <Complication> cervantes: did you clean the surface with alcohol before applying glue on the ircd? ;)</p>
-16:58 < kostya213> imo syndie doesn't need justification, its value should be self-evident to anyone who's already interested in anonymizing networks</p>
-16:58 < kostya213> and aware of the dangers of centralization of information</p>
-16:59 < vulpine> <Complication> (repost, please ignore if reached server)</p>
-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</p>
-16:59 < vulpine> <Complication> (even if probability might vary)</p>
-16:59 < vulpine> <void> indeed</p>
-16:59 < jrandom> aye, plus anyone facing actual hostile adversaries (not even necessarily state level)</p>
-17:00 < jrandom> ok, cool, just wanted to run things by y'all</p>
-17:00 < jrandom> anything else on 3.2, or shall we move over to 3.3) when can we use syndie?</p>
-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</p>
-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)</p>
-17:01 < kostya213> it might be a harder sell to those who don't see immediate value in privacy/anonymity</p>
-17:01 < jrandom> kostya213: aye, though we may be able to pull some tricks, like being able to safely browse offline</p>
-17:02 < vulpine> <Complication> They might appreciate security regardless</p>
-17:02 < jrandom> (e.g. an offline rss reader that also pulls in the full set of pages referenced, not just the rss summary)</p>
-17:02 < vulpine> <void> so yeah, i can't see why it needs justification :)</p>
-17:02 < vulpine> <void> kostya213: they needn't be anonymous to use syndie</p>
-17:02 < cervantes> when can we use syndie or when will syndie be useable?</p>
-17:02 < jrandom> word void :)</p>
-17:03 < cervantes> for the text interface I imagine there needs to be a fairly hefty amount of usage documentation</p>
-17:03 < jrandom> cervantes: right now, syndie is functional (you can create posts, manage channels, read posts, reply to posts, etc)</p>
-17:03 < kostya213> jrandom: how does syndie handle redundancy? how resilient is it against content disappearing?</p>
-17:03 < cervantes> (before it's useable)</p>
-17:03 < jrandom> cervantes: there's inline menus with each command doc'ed (at least minimaly)</p>
-17:04 < cervantes> cool, any plans on some use case examples?</p>
-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)</p>
-17:04 < cervantes> I think the trick will be learning how they all script together</p>
-17:04 < vulpine> <void> kostya213: that's out of the scope of syndie, it's dependant on the transport mechanism</p>
-17:04 < vulpine> <void> unfortunately</p>
-17:04 < jrandom> good idea cervantes</p>
-17:05 < jrandom> the first syndie release will include an http replication system like the old/existing syndie</p>
-17:05 < jrandom> cervantes: perhaps some of the beta users can put together  their favorite scripts for us to distribute :)</p>
-17:05 < modulus> mmm, is this a console app?</p>
-17:05 < jrandom> modulus: yes, the first text based app</p>
-17:06 < modulus> excellent!</p>
-17:06 < cervantes> jrandom: provided the beta users can work out how to use it ;-)</p>
-17:06 < jrandom> hehe</p>
-17:06  * jrandom considered curses/etc, as well as cli-only, but an interactive scriptable text interface is probably the simplest and most useful</p>
-17:07 < jrandom> (sans gui, that is)</p>
-17:07 < cervantes> modulus: see, jrandom listened to your relentless feedback :)</p>
-17:07 < vulpine> <Complication> If people want, they can probably build more interactive textual interfaces on top of it</p>
-17:07 < jrandom> aye, certainly</p>
-17:08 < jrandom> (the code is built to support easy integration with an irc client, like pircbot)</p>
-17:08 < modulus> cervantes: hehe</p>
-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</p>
-17:09 < modulus> although that'd be lots more work.</p>
-17:09  * kostya213 waits for the emacs plugin</p>
-17:09 < modulus> hahaha</p>
-17:09 < jrandom> heh</p>
-17:09 < modulus> actually an emacs mode isn't such a bad idea, maybe would attract more crazies to it.</p>
-17:10 < cervantes> press ctrl-alt-shift-break-uparrow-num7-b to choose your identity</p>
-17:10  * jrandom will leave that to elipsers to hack through ;)</p>
-17:10 < kostya213> no offense, but i'm not sure this project needs to attract more crazies</p>
-17:10 < vulpine> <Complication> would those sort of crazies code, too?</p>
-17:11 < jrandom> hopefuly complication</p>
-17:11 < jrandom> ok, hopefully 3.3) explains a it of whats coming down the line</p>
-17:11 < jrandom> as for *when*, well, we'll see, but i'm hoping "soon" ;)</p>
-17:12 < jrandom> ok, anyone have anything else for 3.3)?</p>
-17:12 < vulpine> * Complication would welcome a few hordes of those crazies then :D</p>
-17:12 < cervantes> well there's coding and then there's writing obfuscated perl interpreted tcl</p>
-17:12 < kostya213> a plugin for FUSE might be useful too</p>
-17:13 < jrandom> aye</p>
-17:13 < jrandom> ok, lets jump on over to 4) crypto for syndie</p>
-17:13 < jrandom> anyone have any comments on those issues?</p>
-17:14 < vulpine> <Complication> I wish I had, but I'm not competent to estimate the strength of those ciphers/hashes/key lengths</p>
-17:15 < vulpine> <void> how long are elgamal/rsa signatures? 4kbit for a 2kbit key?</p>
-17:15 < vulpine> * Complication leaves that talk entirely for others</p>
-17:15 < jrandom> dunno offhand</p>
-17:15 < vulpine> <void> vs dsa?</p>
-17:16 < jrandom> (though ecc looks nice'n'tiny)</p>
-17:16 < modulus> ElGamal signatures are hard and long. as gnupg's team found out.</p>
-17:16 < jrandom> aye, though some of those tricks were related to key reuse</p>
-17:16 < vulpine> <void> ah, ok</p>
-17:16 < vulpine> <void> yeah, it does</p>
-17:16 < tethra> modulus: if they're hard and long, there's a fetish site for it</p>
-17:17 < jrandom> ok, that point was really just a heads up and call for comments whenever y'all have thoughts</p>
-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</p>
-17:17 < tethra> (sorry)</p>
-17:17 < jrandom> cervantes: it includes a DSA: prefix, so an Elg: prefix would work</p>
-17:17 < modulus> are you using 1024-limited dsa or not?</p>
-17:18 < modulus> also what has? sha1 or higher order revs?</p>
-17:18 < cervantes> so really you are just concerned with getting syndie off to a good start</p>
-17:18 < jrandom> dsa is only 1024bit (there are dsa2 proposals for longer, but they aren't standardized yet)</p>
-17:18 < jrandom> and yes, dsa requires sha1</p>
-17:18 < modulus> hmm, my understanding is that they were quite strong pre-standards.</p>
-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</p>
-17:18 < modulus> but i don't follow the process closely enough so you are probably right</p>
-17:19 < jrandom> kostya213: but choice is bad for crypto, so we should have fixed values when we can</p>
-17:19 < jrandom> (bad because of anonymity)</p>
-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?</p>
-17:19 < modulus> patents.</p>
-17:20 < jrandom> patents and fud, yet some concerns in implementation</p>
-17:20 < vulpine> <void> ah, right modulus</p>
-17:20 < modulus> btw, is there are a good reason to go dsa vs rsa-sha512 for instance?</p>
-17:20 < tethra> patents and fud and the state (oh my)</p>
-17:20 < modulus> not trying to be annoying, just considering that gpg for instance has gone this way, among others.</p>
-17:20 < jrandom> haven't reviewed that option in years modulus</p>
-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 ;-)</p>
-17:23 < cervantes> I wouldn't propose "choice" - but new versions of syndie would package increasingly secure (mandatory) ciphers</p>
-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</p>
-17:23 < jrandom> aye, though that implies the fallback to weaker/older versions to interoperate</p>
-17:23 < jrandom> but, ok, we'll work through it</p>
-17:24 < jrandom> ok, lets jump on over to 5) ???</p>
-17:24 < jrandom> anyone have anything else to bring up for the meeting?</p>
-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</p>
-17:25 < jrandom> to a degree</p>
-17:26 < cervantes> no=not</p>
-17:26 < jrandom> (aye, its an incentive, but people are lazy/not interested in "upgrading software", etc)</p>
-17:27 < jrandom> s/people/some people/</p>
-17:27 < cervantes> I guess that's their issue though</p>
-17:27 < jrandom> true that</p>
-17:27 < kostya213> the i2p implementation at least can have painless upgrading</p>
-17:28 < jrandom> certainly</p>
-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"</p>
-17:29 < jrandom> w3wt</p>
-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</p>
-17:29  * cervantes pinches salt</p>
-17:29 < kostya213> what's the near-term plans for router development? is the roadmap accurate?</p>
-17:29 < jrandom> wikked complication</p>
-17:29 < vulpine> <Complication> It's goal is to second-guess NTP servers basing on peer clock skews</p>
-17:29 < jrandom> kostya213: stabilization until syndie is out</p>
-17:30 < jrandom> (from my perspective)</p>
-17:30 < vulpine> <Complication> (and avoid taking potentially connectivity-damaging action)</p>
-17:31 < cervantes> grand</p>
-17:32 < jrandom> ok, anything else for the meeting?</p>
-17:34  * jrandom winds up</p>
-17:34  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/184.rst b/i2p2www/meetings/184.rst
new file mode 100644
index 00000000..cbaa1513
--- /dev/null
+++ b/i2p2www/meetings/184.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, September 12, 2006
+===================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/185.log b/i2p2www/meetings/185.log
index 5e1708ea..eb79fabe 100644
--- a/i2p2www/meetings/185.log
+++ b/i2p2www/meetings/185.log
@@ -1,85 +1,79 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 185{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 17, 2006</h3>
-<div class="irclog">
-16:01 < jrandom> 0) hi</p>
-16:01 < jrandom> 1) Net status</p>
-16:01 < jrandom> 2) Syndie dev status</p>
-16:01 < jrandom> 3) ???</p>
-16:01 < jrandom> 0) hi</p>
-16:01  * jrandom waves</p>
-16:01 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001314.html</p>
-16:02 <+fox> * dm waves</p>
-16:02 < jrandom> w3wt, ok, while y'all read that oh-so-fun missive, lets jump on to 1) net status</p>
-16:03 < jrandom> the net seems to be maintaining the steady state right now, though with a slight growth trend</p>
-16:04 < jrandom> there are some discussions on the big cpu-related issue on the forum, though no big win yet, afaics</p>
-16:04 < jrandom> anyone have anything to bring up re: 1) net status?</p>
-16:05 < jrandom> (the last full week w/ 0.6.1.26 seems to have gone well [yay])</p>
-16:06 <+fox> <dm> well, I better say something</p>
-16:06 <+fox> <dm> is there a consistent metric that is being used to monitor net status</p>
-16:06 <+fox> <dm> or is it just ad-hoc experiences?</p>
-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.</p>
-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)</p>
-16:08 <+fox> <dm> cool, I'll check that site out.</p>
-16:08 < jrandom> there are several people running stat monitoring apps - orion.i2p, tino.i2p, eepsites.i2p, as well as stats.i2p</p>
-16:09 <+fox> <dm> thank you!</p>
-16:09 < jrandom> np :)</p>
-16:09 < jrandom> ok, if there's nothing else on 1), lets jump on over to 2) syndie dev status</p>
-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 :)</p>
-16:11 <+fox> <dm> down at the moment?</p>
-16:11 <+fox> <dm> scratch that</p>
-16:11 <+fox> * dm shuts up</p>
-16:11 < jrandom> :)</p>
-16:12 < marlowe> jrandom, the diagram on the front page is very helpful</p>
-16:12 < marlowe> i know understand the concept behind syndie</p>
-16:12 <+fox> <dm> it's pretty as well</p>
-16:13 <+fox> <dm> but how do you access syndie without download/installing it? I remember you could do this before?</p>
-16:13 < jrandom> great, glad its clear marlowe - it can be a confusing concept in just text :)</p>
-16:13 < jrandom> dm: the old syndie (syndiemedia.i2p.net/) was web based, but this new one is, well, brand new, completely redesigned</p>
-16:14 <+fox> <dm> it's not web-based?</p>
-16:14 < jrandom> (and thanks to cervantes for turning my ugly ms-paint-style image into the slick pic you see there :)</p>
-16:14 < jrandom> no, its not web based - current release is actually text only, but work continues on a gui</p>
-16:14 < jrandom> http://syndie.i2p.net/roadmap.html</p>
-16:14 <+fox> <dm> text-only! wow. ok. downloading.</p>
-16:14 < jrandom> w3wt</p>
-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</p>
-16:15 <+fox> <dm> wow.. this is hardcore stuff. (Next Command:) hehhehe</p>
-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" :)</p>
-16:16 < jrandom> its a fairly simple system, though with very specific design features</p>
-16:16 < jrandom> (and incredibly robust - it can run on anything :)</p>
-16:17 <+fox> <dm> there's something cool about really complex apps running with a text frontend</p>
-16:17 <+fox> <dm> anyway...</p>
-16:17 <+fox> * dm shuts up again</p>
-16:19  * jrandom hopes to bring us up to 1.0 sometime this month, so beta testing would be great</p>
-16:20 < jrandom> (kick the tires, tell me whats broken, etc)</p>
-16:20 < jrandom> 1.0 won't include the gui, of course, thats 2.0</p>
-16:20 <+fox> <dm> of course</p>
-16:21 < jrandom> ok, anyone have any comments/questions/suggestions/toenails on 2) Syndie dev status?</p>
-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 :)</p>
-16:23 <+fox> <dm> there's a good place to get free or semi-free very high quality logos</p>
-16:24 < jrandom> flickr?  :)</p>
-16:24 <+fox> <dm> http://www.worth1000.com/ <--- photoshop geeks around try to outdo each other for a little fame and/or money</p>
-16:24 < jrandom> ah cool</p>
-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</p>
-16:25 <+fox> * dm shuts up again</p>
-16:26 < jrandom> wikked, thanks dm</p>
-16:27 < jrandom> ok, if there's nothing on 2, lets jump to 3) ???</p>
-16:28 < jrandom> anyone have anything else for the meeting?</p>
-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?</p>
-16:28 < jrandom> ah, thats a good idea, since 1.* is going to be text anyway</p>
-16:30 < bar> think about it, i'm sure we can dig up some funding</p>
-16:30 <+fox> <dm> how's funding going anyway? </p>
-16:31 <+fox> <dm> are you still doing this full-time jr?</p>
-16:31 < jrandom> aye, still getting by, thanks to some insanely generous contributors (thanks!)</p>
-16:31 < jrandom> http://www.i2p.net/halloffame</p>
-16:32 <+fox> <dm> ah yes.. the shoestring budget. I remember now</p>
-16:32 < jrandom> hehe</p>
-16:34 < jrandom> ok, anyone have anything else to bring up?</p>
-16:34 <+fox> <dm> just dropped you a c-bill. Make sure it's only used for alcohol or other frivolous uses.</p>
-16:34 <+fox> <dm> oh and keep my real name secret!</p>
-16:34 < jrandom> w00t!  thanks dm</p>
-16:36 < jrandom> ok, if there's nothing else...</p>
-16:36  * jrandom winds up</p>
-16:36  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/185.rst b/i2p2www/meetings/185.rst
new file mode 100644
index 00000000..4a934093
--- /dev/null
+++ b/i2p2www/meetings/185.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 17, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/186.log b/i2p2www/meetings/186.log
index 367ec69f..25059457 100644
--- a/i2p2www/meetings/186.log
+++ b/i2p2www/meetings/186.log
@@ -1,103 +1,97 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 186{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 24, 2006</h3>
-<div class="irclog">
-16:03 < jrandom> 0) hi</p>
-16:03 < jrandom> 1) Net status</p>
-16:03 < jrandom> 2) Syndie dev status</p>
-16:03 < jrandom> 3) ???</p>
-16:03 < jrandom> 0) hi</p>
-16:03  * jrandom waves</p>
-16:03  * Complication stumbles to somewhere within reach of keyboard (week's beginning was hell, but it's over now)</p>
-16:04 < jrandom> (hooray to hellish beginnings!)</p>
-16:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-October/001315.html</p>
-16:04 <+Complication> Hello</p>
-16:05 < jrandom> while y'all read the (short) notes, lets jump to 1) Net status</p>
-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</p>
-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</p>
-16:06 < jrandom> (though still in the 20-30 range)</p>
-16:06 < jrandom> ((which is much better than 5-10, but much worse than 60-80))</p>
-16:07 < jrandom> ok, anyone have anything to bring up for 1) net status?</p>
-16:08 <+Complication> Similar here, but no extra-persistent connections</p>
-16:08 <+tethra> other than applause, nothing from me!</p>
-16:08 <+Complication> I just wanted to drop a little line related to NTP issues</p>
-16:09 <+Complication> Basically, on Sunday, Oct 29, some times zones will jump off dailight saving time</p>
-16:09 < jrandom> (its going to suck)</p>
-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</p>
-16:10 <+Complication> So, just in case the recent NTP server sanity check (added with version .26) should inconvenience someone that night...</p>
-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)</p>
-16:11 <+Complication> (so folks who read status notes would know)</p>
-16:12 <+Complication> Disabling it can be done by entering the line "router.clockOffsetSanityCheck=false" into http://localhost:7657/configadvanced.jsp</p>
-16:12 <+Complication> But as mentioned, I do hope nobody needs that</p>
-16:13 <+Complication> It will be interesting to watch and see how the network behaves that night, though, as different time zones start switching</p>
-16:13 <+Complication> I'll certainly observe, in hope that if any anomaly is seen, perhaps it can be fixed by Spring :D</p>
-16:14 < jrandom> the minute-of will probably be pretty jumpy, but should heal shortly</p>
-16:14 <+Complication> ...and that's all I had. :)</p>
-16:14 < jrandom> but, hopefully it'll work out, and if not, as you say, there's spring :)</p>
-16:14 < bar> and should things indeed b0rk, there were two possible suggestions for future improvement that surfaced in the chat the other day:</p>
-16:15 < bar> "prevent skewed routers from forming subnets by handing over control to NTP if peers < some number"</p>
-16:15 < bar> ...and "do not delete floodfill peer router infos from netdb if there are too few of them"</p>
-16:15 < jrandom> aye</p>
-16:16 <+Complication> Indeed, adjusting the required number of data points (available peer clock skews) which are required to deem peer skew measurements reliable</p>
-16:16 <+Complication> (oops, some redundancy in my last sentence)</p>
-16:17 <+Complication> ...and yes, the floodfill check. I take that no similar check exists currently?</p>
-16:18 < jrandom> right</p>
-16:18 <+Complication> Seems like some people, sometimes, either with luck or magic, may be managing to lose track of floodfill peers</p>
-16:19 < jrandom> that should certainly be remedied</p>
-16:19 < jrandom> (it hit some folks the other day, when one of 'em was null routed)</p>
-16:20 < jrandom> (if #floodfill == 0, perhaps randomly treat a few as floodfill)</p>
-16:20 <+Complication> If that's doable, possible also</p>
-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</p>
-16:22 < jrandom> aye</p>
-16:25 < jrandom> ok, anyone have anything else for 1) net status?  or shall we move on over to 2) syndie dev status?</p>
-16:25 < badger> re irc stability: seeing much much much fewer reconnects at the server end.</p>
-16:25 < badger> you could almost call it a service :)</p>
-16:26 < jrandom> :)</p>
-16:28 < jrandom> ok, jumping on to 2) syndie dev status</p>
-16:28 < jrandom> lots of progress here, as mentioned in the status notes</p>
-16:28 < jrandom> there's also been a bunch of discussion on it here over the last few days</p>
-16:28 < jrandom> anyone have anything they want to bring up on that front?</p>
-16:30 <@cervantes> install something other than mspaint</p>
-16:30 < jrandom> heh</p>
-16:30 < jrandom> well, there's value in using *ugly* things to sketch - limits expectations</p>
-16:31 <+fox> <HotTuna> the links in the forumpost seem to be down ... some are anyway..</p>
-16:31 <@cervantes> I think that's mentioned in the posts</p>
-16:31 <+fox> <HotTuna> oh. . sorry</p>
-16:31 < jrandom> hottuna: they're mirrored @ dev.i2p.net/~jrandom/mockup/</p>
-16:31 <@cervantes> some should be mirrored further down</p>
-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?</p>
-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)</p>
-16:33 <@cervantes> most definitely easier to do that safely</p>
-16:33 <+Complication> (just being curious as to what's going in on the GUI side, having been somewhat unaware of it)</p>
-16:33 < jrandom> Complication: i've got nearly everything done for general formatting purposes already</p>
-16:33 <@cervantes> especially given the limited subset of html that syndie will support</p>
-16:34 <+Complication> Aha</p>
-16:34 < jrandom> (fonts, alignment, sizes, colors, images, links, lists (including nested), headers, paragraphs, html entities)</p>
-16:35 < jrandom> now, going in and doing divs for placement or tables requires substantially more work, but i'm not tackling that now</p>
-16:35 <+Complication> Sounds nice enough</p>
-16:36 <@cervantes> and of course the <blink> tag</p>
-16:36  * jrandom pelts cervantes with †</p>
-16:37 <@cervantes> ouch, skewered by an entity</p>
-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</p>
-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</p>
-16:39 <+Complication> Indeed, there are doubtless benefits to handling text/plain</p>
-16:40 <+Complication> (which hopefully only supports natural-language attacks ;P )</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?</p>
-16:42 <@cervantes> well I guess using bbcode or wiki syntax would reduce the risk of markup injection in a full html engine</p>
-16:42 <@cervantes> *rendering engine</p>
-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)</p>
-16:44  * Complication thought about some a few days back, but only lightly</p>
-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)</p>
-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?</p>
-16:45 <+Complication> Aha, the uri... might be indeed</p>
-16:45 <+Complication> Oh, indeed</p>
-16:45 <+Complication> That's some things I didn't think about</p>
-16:48 < jrandom> cervantes: true enough</p>
-16:48 < jrandom> ok, anyone have anything else for 2) syndie dev status?</p>
-16:51 < jrandom> ok, if not, lets jump to 3) ???</p>
-16:51 < jrandom> anyone have anything else they want to bring up?</p>
-16:54 < jrandom> ok, if not...</p>
-16:54  * jrandom winds up</p>
-16:54  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/186.rst b/i2p2www/meetings/186.rst
new file mode 100644
index 00000000..8a8e9c7f
--- /dev/null
+++ b/i2p2www/meetings/186.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 24, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/187.log b/i2p2www/meetings/187.log
index ca688108..73baa63c 100644
--- a/i2p2www/meetings/187.log
+++ b/i2p2www/meetings/187.log
@@ -1,76 +1,70 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 187{% endblock %}
-{% block content %}<h3>I2P dev meeting, October 31, 2006</h3>
-<div class="irclog">
-15:33 < jrandom> 0) hi</p>
-15:33 < jrandom> 1) Net status</p>
-15:33 < jrandom> 2) Syndie dev status</p>
-15:33 < jrandom> 3) ???</p>
-15:33 < jrandom> 0) hi</p>
-15:33  * jrandom waves</p>
-15:33 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-October/001316.html</p>
-15:33  * tethra waves back!</p>
-15:34 < jrandom> lets jump on in to 1) net status</p>
-15:34 < jrandom> no news on this front afaik... things seem stable</p>
-15:34 < jrandom> anyone have anything they want to bring up on it?</p>
-15:35 <+tethra> nothing here</p>
-15:36 < jrandom> ok lets jump on to 2) Syndie dev status then</p>
-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</p>
-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</p>
-15:39 <+tethra> makes sense. might wysiwyg be a progression later on, then?</p>
-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)</p>
-15:39 < jrandom> aye, thats a great way for later enhancement</p>
-15:40 <+tethra> less of a jump between geek and non geek that way :)</p>
-15:40 <+tethra> (have you looked at Nvu?)</p>
-15:41 < jrandom> aye, huge, but promising</p>
-15:41 <+tethra> which others had you looked at?</p>
-15:42 <+tethra> out of interest</p>
-15:42 < jrandom> everything i could google into.  no list at hand</p>
-15:42 <+tethra> ah, right</p>
-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?</p>
-15:45 <+tethra> or maybe left/right (being able to choose would be lovely</p>
-15:45 <+tethra> )</p>
-15:45 < jrandom> aye, thats a good idea (not entirely realtime, but semi-realtime)</p>
-15:46 <+tethra> yeah, refresh button etc</p>
-15:46 < jrandom> perhaps on 5s idle or a button press</p>
-15:46 < jrandom> right</p>
-15:48 < koff> You could maybe even have two cursors, so you almost feel like you're navigating both at the same time?</p>
-15:48 <+tethra> that'd be a bit confusing :/</p>
-15:48 < koff> maybe :)</p>
-15:50 < jrandom> ok, anyone have anything else on 2) syndie dev status?</p>
-15:51 < jrandom> if not, lets move on to 3) ???</p>
-15:51 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-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 ...</p>
-15:55 <+fedo> i'll love to help to test syndie but i'm still unable to understand how to use syndie ! :)</p>
-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?</p>
-15:55 < jrandom> is it a question of "what can you do with syndie", or "how can you do $x"?</p>
-15:55 <+fedo> hm not really Jr :-/</p>
-15:56 <+fedo> really, i try to do it ...</p>
-15:56 <+fedo> how i can use syndie ...</p>
-15:57 <+fedo> the text mode console is not a problem</p>
-15:57 < jrandom> how you can use syndie /to do what/?  or is that the question itself - why would you install and use syndie?</p>
-15:57 <+fedo> but what to do when i've installed Syndie is one :-s</p>
-15:57 < jrandom> ah</p>
-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</p>
-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</p>
-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</p>
-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 ...</p>
-16:02 <+tethra> (or even, an example repository (syndie.i2p.net ?) to sync to)</p>
-16:02 <+tethra> oh, didn't read above :/</p>
-16:02 <+tethra> nvm</p>
-16:03 < jrandom> fedo: good idea, i'll write one up</p>
-16:03  * fedo waves</p>
-16:05 < jrandom> ok cool, anyone have anything else for the meeting?</p>
-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 :-/ )</p>
-16:05 <+fedo> ((help me :))</p>
-16:06 < jrandom> http://syndie.i2p.net/manual.html#syndicate_freenetpost</p>
-16:06 < jrandom> and http://syndie.i2p.net/manual.html#syndicate_getindex</p>
-16:07 <+fedo> many 'neurones' to burn but i'll  try :)</p>
-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</p>
-16:08 < jrandom> ah right, thats a good one burl</p>
-16:08 <+fedo> thanks burl : i'll have a look to that note ;)</p>
-16:12 < jrandom> word, ok, if there's nothing else for the meeting...</p>
-16:12  * jrandom winds up</p>
-16:12  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/187.rst b/i2p2www/meetings/187.rst
new file mode 100644
index 00000000..209ade1d
--- /dev/null
+++ b/i2p2www/meetings/187.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 31, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/188.log b/i2p2www/meetings/188.log
index 70b2b42b..e9af7e15 100644
--- a/i2p2www/meetings/188.log
+++ b/i2p2www/meetings/188.log
@@ -1,93 +1,87 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 188{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 7, 2006</h3>
-<div class="irclog">
-15:09 < jrandom> 0) hi</p>
-15:09 < jrandom> 1) Net status</p>
-15:09 < jrandom> 2) Syndie dev status</p>
-15:09 < jrandom> 3) I2Phex mods</p>
-15:09 < jrandom> 4) ???</p>
-15:09 < jrandom> 0) hi</p>
-15:09  * jrandom waves</p>
-15:10 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2006-November/001317.html</p>
-15:10  * spaetz waves back</p>
-15:10 < mrflibble> cool,  i was the only one  in #i2p-dev a minute ago :)</p>
-15:10 < jrandom> hehe</p>
-15:10 < jrandom> yeah, the i2p-dev chan migration didn't last too long ;)</p>
-15:10 < jrandom> ok, lets jump into 1) Net status</p>
-15:11 < spaetz> ad 1) net seems stable</p>
-15:11 < spaetz> however, as you noted, reseeding is needed every 7 days or so</p>
-15:11 < jrandom> aye, 'tis unfortunate, and fixable</p>
-15:12 < jrandom> though the kludge fix is kind of ugly, and the long term fix is pretty involved</p>
-15:12 < spaetz> yep, that would be nice. My firewall is too tight for reseeding</p>
-15:12 < jrandom> damn, doesn't allow outbound http to dev.i2p.net?</p>
-15:12 < spaetz> I need to poke additional holes in it :-)</p>
-15:13 < spaetz> jrandom: outbound yes, but all the reply data gets stopped by default :-)</p>
-15:13 < spaetz> but that OT. go on.</p>
-15:14 < jrandom> lol ok, interesting</p>
-15:14 < jrandom> its something that needs to get addressed, though its not on my do-immediately pile</p>
-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?</p>
-15:15 < spaetz> I get disconnected on IRC every 1-2 hours</p>
-15:15 < spaetz> but I would call that stable :-)</p>
-15:16 < spaetz> ok, on to 2)</p>
-15:16 < jrandom> heh cool, 2) it is</p>
-15:17 < jrandom> lots of progress on this front</p>
-15:17 < spaetz> Is the new Syndie going to be integrated into i2p when it goes gold?</p>
-15:18 < jrandom> hmm, if you mean bundled with, i'm not sure.  if you mean capable of seamlessly using, yes, definitely</p>
-15:19 < spaetz> I actually meant bundled. I2p seems to come "with batteries included"</p>
-15:19 < jrandom> the reason i'm not sure is that syndie will weigh a good deal (swt native libs, translations, spellcheck dictionaries, etc)</p>
-15:19 < jrandom> we will have an option to bundle them, certainly</p>
-15:20 < jrandom> and maybe that'll be the most common download</p>
-15:20 < spaetz> ok, I'm  for an optional install then. alright. </p>
-15:21 < jrandom> bundling the text UI is certainly doable without a doubt, thats quite lightweight</p>
-15:22 < spaetz> that might be good enough to tease people</p>
-15:22 < spaetz> SOme might want to run the gui on a different machine than their i2p peer anyway</p>
-15:22 < spaetz> (I will)</p>
-15:23 < jrandom> word</p>
-15:23 < jrandom> ok, some teaser images for the gui dev status:</p>
-15:23 < jrandom> html rendering: http://dev.i2p.net/~jrandom/mockup/render_snap.png</p>
-15:23 < jrandom> forum tree: http://dev.i2p.net/~jrandom/mockup/syndie_refchooser.png</p>
-15:23 < jrandom> message tree / filter: http://dev.i2p.net/~jrandom/mockup/syndie_msgchooser.png</p>
-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 ;)</p>
-15:25 < jrandom> there'll be lots of little add-ons, but i'm focusing on first getting gui message generation in place</p>
-15:25 < jrandom> (which requires being able to browse forums and messages anyway, to pick links)</p>
-15:26 < spaetz> cool</p>
-15:26 < spaetz> although the beauty of syndie was its seamless integration through the web interface</p>
-15:26 < spaetz> but I bet that would be possible to implement</p>
-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</p>
-15:28 < spaetz> mmh, I see the hell you'd get into. I remember the corresponding freenet discussions a few years back</p>
-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</p>
-15:29 < jrandom> aye, exactly</p>
-15:29 < jrandom> (and what, 5-8 years on, they still just found another security hole in their filter the other week)</p>
-15:30 < jrandom> ((my point is not that their filter isn't great, its that doing the filter is insanely dangerous))</p>
-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?</p>
-15:30 < spaetz> It seemed a bit specific already</p>
-15:31 < jrandom> ah - check out Complication2's post: http://forum.i2p.net/viewtopic.php?t=1935</p>
-15:31 < spaetz> ok, thanks.</p>
-15:31 < jrandom> that's getting wrapped up into a page for the syndie site, but isn't up yet</p>
-15:32 < spaetz> ok, that's great. all I needed</p>
-15:34 < jrandom> cool.  ok, thats about it for gui stuff atm</p>
-15:34 < jrandom> there's a little teaser for the p2p folks in the status notes regarding a swarming syndication system</p>
-15:35 < jrandom> thats an area quite ripe for playing around in, for those who'd like to do some network hacking</p>
-15:36 < jrandom> but, thats just a side note</p>
-15:36 < jrandom> ok, if there's nothing else on 2) syndie dev status, lets jump over to 3) i2phex mods</p>
-15:36 < jrandom> Complication2: wanna give us the rundown?</p>
-15:38 < jrandom> or, if you're not here, those of y'all interested can check the status notes for my synopsis</p>
-15:39 < spaetz> mmh, gone fishin'</p>
-15:39 < jrandom> ok, lets jump on over to 4) ???</p>
-15:39 < jrandom> anyone have anything else to bring up for the meeting?</p>
-15:39  * mrflibble sticks his hand up</p>
-15:40 < spaetz> nahh, looking forward to see (the new) Syndie getting more useful</p>
-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?</p>
-15:40 < spaetz> will the first codename be "will the real Syndie please stand up?" :-)</p>
-15:41 < jrandom> mrflibble: http://www.electoral-vote.com:2006/</p>
-15:41 < jrandom> hehe spaetz </p>
-15:41 < mrflibble> oh!</p>
-15:41  * bar impregnates a ballot</p>
-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)</p>
-15:44 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:45 < jrandom> if not...</p>
-15:46  * jrandom winds up</p>
-15:46  * jrandom *baf*S the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/188.rst b/i2p2www/meetings/188.rst
new file mode 100644
index 00000000..c7979ee9
--- /dev/null
+++ b/i2p2www/meetings/188.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 7, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/189.log b/i2p2www/meetings/189.log
index 263a2b26..90eaaf0d 100644
--- a/i2p2www/meetings/189.log
+++ b/i2p2www/meetings/189.log
@@ -1,96 +1,90 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 189{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 14, 2006</h3>
-<div class="irclog">
-15:07 < jrandom> 0) hi</p>
-15:07 < jrandom> 1) Net status</p>
-15:07 < jrandom> 2) Syndie dev status</p>
-15:07 < jrandom> 3) I2Phex mods</p>
-15:07 < jrandom> 4) ???</p>
-15:07 < jrandom> 0) hi</p>
-15:07  * jrandom waves</p>
-15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001318.html</p>
-15:07 < jrandom> (i'm late, so i'll let y'all catch up on those)</p>
-15:09 < jrandom> ok, lets jump on in to 1) net status</p>
-15:10 < jrandom> [eom] :)</p>
-15:10  * jrandom has had a good irc connection now (4+ days), so things are in pretty good shape.</p>
-15:11 < jrandom> we've also got those new peer capacity graphs on stats.i2p, detailing some interesting ratios </p>
-15:13 < jrandom> ok, anyone have anything else for 1) net status?</p>
-15:14 < striker> just that it looks nice.</p>
-15:14 < jrandom> w00t :)</p>
-15:15 < jrandom> ok, lets hop on over to 2) syndie dev status then</p>
-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</p>
-15:15 < jrandom> green: unfortunately, its pretty arbitrary.</p>
-15:16 < jrandom> (or, more precicely, the cause is dependent upon many factors without a good control over them)</p>
-15:17 < green> any chance to really know why ?</p>
-15:17 < green> I've plenty of tunnels even where IRC goes down</p>
-15:18 < green> s/when</p>
-15:18 < jrandom> yes, there's lots we can do, but i'm focusing my time on getting syndie out first</p>
-15:18 < green> I know, so I've just to way more ;)</p>
-15:19 < green> s/wait</p>
-15:20 < green> gr f..ing keyboard</p>
-15:20 < green> ok, no more on 1 let's got to 2</p>
-15:20 < jrandom> w3rd</p>
-15:21 < jrandom> ok, not much more to add beyond whats in the notes (well, that can reasonably be brought up)</p>
-15:21 < jrandom> the webcaching discussion thread is http://forum.i2p.net/viewtopic.php?t=1958</p>
-15:22 < green> is there any plan on phpbb to syndie converter ?</p>
-15:22 < jrandom> and the latest mockup image referred to is http://dev.i2p.net/~jrandom/mockup/forum.png</p>
-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</p>
-15:24 < jrandom> short answer: doable, and maybe it'll get done, but its not on the immediate roadmap</p>
-15:24 < jrandom> at least, not bidirectional phpbb<-->syndie operation</p>
-15:24 < jrandom> phpbb-->syndie is easy (just suck in the posts, or use server side generation)</p>
-15:25 < jrandom> syndie-->phpbb is easy too</p>
-15:25 < jrandom> i'm not sure if the phpbb model of operation is what people will end up using syndie for though</p>
-15:25 < jrandom> but we'll see</p>
-15:28 < green> even just an phpbb -> syndie would be enough</p>
-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)</p>
-15:31 < badger> phpbb's admin is fairly flat.... not a challenge to get a hook of</p>
-15:32 < badger> and there are various rss plugins available for it</p>
-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] </p>
-15:34 < jrandom> (and if you need images/etc, just reference them as img src="attachment1" etc)</p>
-15:34 < jrandom> (and then we can shove 'em into a syndie post with no problem)</p>
-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</p>
-15:37 < badger> http://forum.i2p/rss_news.php</p>
-15:38 < badger> translating that to syndie markup would probably be straightforward</p>
-15:39 < jrandom> aye (though remember, syndie markup /is html/.  the uris are just... long and hard to read :)</p>
-15:41 < jrandom> ok, anyone have anything else on 2) syndie dev?</p>
-15:42 < jrandom> if not, lets jump to 3) i2phex mods</p>
-15:43 < jrandom> strike1 / Complication: wanna give us an update?</p>
-15:43 < strike1> I did a quick sanity check in regards to solving the connect to self problem</p>
-15:43 < strike1> http://forum.i2p.net/viewtopic.php?t=1965</p>
-15:44 < strike1> It seems to be working okay, but is merely preventing the local dest from being added to i2phex.hosts</p>
-15:44 < strike1> I am also looking into the hashing problems, and the downloading issues</p>
-15:45 < jrandom> kickass!</p>
-15:45 < strike1> The new mods in cvs seem to make for a slightly better i2phex so far too, I must say.</p>
-15:48 < strike1> Hopefully between Complication, I, and anyone else who wants to help we can solve them all soon. :)</p>
-15:49 < jrandom> wikked, thanks strike1 (& complication et al!)</p>
-15:50 < jrandom> ok, anyone have anything else for 3) i2phex mods?</p>
-15:51 < jrandom> if not, lets jump to 4) ???</p>
-15:51 < jrandom> anyone have anything else they'd like to bring up for the meeting?</p>
-15:54 < green> any chance to have a dijjer port on I2P ?</p>
-15:55 < green> wow, don't worry, just a simple question ;)</p>
-15:55 < jrandom> probably not (dijjer port being a large number of public squid outproxies that cache)</p>
-15:56 < jrandom> but the ability to have content hosted when you're not online will be there with syndie</p>
-15:56 < jrandom> (and syndie can run over i2p)</p>
-15:56 < green> sure but how syndie can handle large content ?</p>
-15:57 < jrandom> technically, yes, but practically, no</p>
-15:58 < green> so using cache is not a so bad idea ?</p>
-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</p>
-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</p>
-15:59 < jrandom> (no pun intended)</p>
-15:59 < green> humm .torrent files so we have to rely on a cetral server / tracker</p>
-15:59 < green> s/central</p>
-16:00 < jrandom> (for instance, see http://freehaven.net/anonbib/#redblue )</p>
-16:01 < jrandom> green: torrents can be distributed, and you can put the same data on lots of swarms</p>
-16:01 < jrandom> but functionally, we know that torrents work for transfering truckloads of data</p>
-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</p>
-16:05 < jrandom> hmm, the trackers we have are good, there just isn't that much content :)</p>
-16:06 < strike1> I agree though looking at postman's tracker I was impressed with what I found there as opposed to last year.</p>
-16:07 < jrandom> aye, quite</p>
-16:07 < strike1> Lots of nice stuff :)</p>
-16:09 < jrandom> ok, anything else for the meeting?</p>
-16:10 < green> (baf) :)</p>
-16:10  * jrandom winds up</p>
-16:10  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/189.rst b/i2p2www/meetings/189.rst
new file mode 100644
index 00000000..07c431b8
--- /dev/null
+++ b/i2p2www/meetings/189.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 14, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/190.log b/i2p2www/meetings/190.log
index 068ed543..f53b108f 100644
--- a/i2p2www/meetings/190.log
+++ b/i2p2www/meetings/190.log
@@ -1,120 +1,114 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 190{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 21, 2006</h3>
-<div class="irclog">
-15:02 < jrandom> 0) hi</p>
-15:02 < jrandom> 1) Net status</p>
-15:02 < jrandom> 2) Syndie dev status</p>
-15:02 < jrandom> 3) ???</p>
-15:02 < jrandom> 0) hi</p>
-15:02  * jrandom waves</p>
-15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001319.html</p>
-15:03 < jrandom> since that one is pretty short, lets jump on in to 1) net status</p>
-15:04 < jrandom> things are looking pretty good atm, network seems pretty steady</p>
-15:04 <+zzz> I invented a "peer capacity index"</p>
-15:04 <+zzz> on the dashboard...</p>
-15:04 <+zzz> so far not sure it is helpful though</p>
-15:04 < jrandom> ah yeah, sorry, metioned that one last week - looks quite useful, thanks!</p>
-15:05 < jrandom> interesting to see the disparity out there so clarly</p>
-15:05 <+zzz> the idea is the ratio of high-cap routers to low-cap routers, which is obviously important to tunnel build %</p>
-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</p>
-15:07 < jrandom> ah, ok, that would explain it.  are you still harvesting?</p>
-15:07 < jrandom> (or wget'ing from dev.i2p.net?)</p>
-15:08 <+zzz> yes</p>
-15:08 < jrandom> cool</p>
-15:08 <+zzz> netDb.harvestDirectly=false</p>
-15:08 <+zzz>   netDb.shouldHarvest=true, right?</p>
-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?</p>
-15:09 < jrandom> right</p>
-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</p>
-15:10 < jrandom> ah ok</p>
-15:10 <+zzz> you can see spikes/dips in all the data that last 1.5 hours :)</p>
-15:11 < spaetz> net seems pretty stable. Yep</p>
-15:12 <+zzz> thats all I have for that topic</p>
-15:12 < spaetz> I'd like to know if jrandom completely focuses on syndie nowadays or if he still looks at i2p dev.</p>
-15:12 < spaetz> or if this is just a bit on hte backburner temporarily</p>
-15:13  * jrandom completely focuses on syndie nowadays, but will work on i2p both when there are problems and once syndie is established</p>
-15:13  * spaetz thanks for the information</p>
-15:14  * spaetz is fine with this</p>
-15:15 < jrandom> w3wt.  yeah, steadystate means syndie dev can continue, but if there are problems, of course i reprioritize</p>
-15:15 < jrandom> ok, anyone have anything else on 1) net status?</p>
-15:15 < Walter> I have a random question.</p>
-15:15 < jrandom> hit me Walter </p>
-15:17 < Walter> Assume you have 100Mb/s BW, what kind of server would you need to saturate it as an I2P node?</p>
-15:17 < jrandom> doesnt matter</p>
-15:17 < jrandom> i2p does not and will not saturate 100Mbps</p>
-15:18 < Walter> Assume one wanted to make use of available BW.</p>
-15:18 < jrandom> you would not.</p>
-15:19 < spaetz> I've got 150kbs up and down and it uses like 25% of a vserver (Dell shared with a dozen others)</p>
-15:19 < jrandom> that exceeds the capacity of the entire network</p>
-15:19 < spaetz> 25%CPU that is</p>
-15:19  * spaetz admits that's not really a precise answer and shuts up</p>
-15:20 < jrandom> the routers themselves have a mem v. throughput tradeoff, making it less likely that a router can even push > 3-350KBps</p>
-15:20 < jrandom> (of course, that tradeoff can be tweake to allow higher rates, but thats not an issue)</p>
-15:21 < jrandom> using bandwidth is *BAD* unless that bandwidth is being used only when necessary</p>
-15:22 <+zzz> the network is averaging about 1.5 MBps (=12 Mbps) total traffic over the last 3 months</p>
-15:23 < Walter> I see.</p>
-15:24 <+fox> <LeerokKitchen> Field trip!</p>
-15:26 < jrandom> ok, if there's nothing else for 1) net status, lets jump on over to 2) syndie dev status</p>
-15:26 < jrandom> progress here continues, and i've been doing testing both on windows and linux</p>
-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</p>
-15:29 < jrandom> not much more news to discuss on that front though</p>
-15:30 < jrandom> anyone have any questions/comments/concerns on 2) syndie dev status?</p>
-15:33 < jrandom> ok, lets jump on to 3) ???</p>
-15:33 < jrandom> y'all have anything else for the meeting?</p>
-15:34 <+fox> <blx> when will gpl java be usable with i2p=</p>
-15:34 <+fox> <blx> ?</p>
-15:35 < Complication3> I guess it depends on when gpl java will be usable on various distros</p>
-15:35 < Complication3> Or available for download from Sun</p>
-15:36 < Complication3> But it feels like a moot point, since it's the same Java which is usable already now</p>
-15:36 < Complication3> GPL would only let it be packaged more conveniently, and improved upon</p>
-15:37 < jrandom> (and i2p already works with gcj/kaffe, though not all of the client apps)</p>
-15:37  * Complication3 quickly reads backlog</p>
-15:37 < jrandom> ((and syndie works with gcj/kaffe completely))</p>
-15:38 <+fox> <blx> Compilation, thats what they want you to think ;)</p>
-15:38 <+fox> <blx> but ok, i got my question answered.</p>
-15:38 <+fox> <blx> Complication even. misread</p>
-15:39 < Complication3> blx: well, the sources are available already now, it's just that few read and compile them</p>
-15:39 < jrandom> (and you can even modify and use those modifications, you just can't distribute your mods)</p>
-15:40 < koff> when will i2p have the logging functionality suggested by the proposed laws i heard about?</p>
-15:41 < jrandom> never</p>
-15:41 <+zzz> hahahaha</p>
-15:41  * Complication3 suspects never :)</p>
-15:41 <+fox> <blx> what laws?</p>
-15:41  * jrandom assumes you refer to .de/.eu data retention issues</p>
-15:41 < Complication3> Someone in the forum talked of a (proposed) law in Germany</p>
-15:42 < jrandom> (and then the .us ones in a few years)</p>
-15:42 < Complication3> They could have spelled it out better though</p>
-15:42 < jrandom> aye, 'tis just proposed, but not a big suprise</p>
-15:43 < Complication3> I personally think: it's not like data retention laws aren't being broken left and right already</p>
-15:43 < Complication3> Breaking a dozen more of them? I personally wouldn't care much...</p>
-15:44 < Complication3> In short, I want to see how they're going to enforce it</p>
-15:44 < tea> like they did with napster : arrest everyone</p>
-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)</p>
-15:45 <+fox> <LeerokLacerta> That reminds me of a song.</p>
-15:45 <+fox> <LeerokLacerta> http://2ch.ru/mu/src/1163070550597.mp3</p>
-15:46 < tea> turning all data traffic over to anonymous networks might help ...</p>
-15:47 < Complication3> Just ignoring them en masse has worked for plain ordinary pirates...</p>
-15:47 < Complication3> You can arrest one person ignoring you. Can't do that with several hundred thousand.</p>
-15:47 < tea> that's no argument for a german :)</p>
-15:47 <+fox> <modulus> you can</p>
-15:47 <+fox> <modulus> hitler did</p>
-15:48 < Complication3> That's only because nobody bothered removing him</p>
-15:48 < jrandom> *cough*</p>
-15:48 < Complication3> Had they taken up arms, it wouldn't have worked</p>
-15:48 < Complication3> (sorry, far off topic, yes)</p>
-15:48 < tea> still, one does feel important in being paranoid</p>
-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.</p>
-15:48 < jrandom> ok, well, i think we've addressed the i2p-related issue there ;)</p>
-15:48 < tea> sry</p>
-15:49 < jrandom> aye modulus</p>
-15:49 < jrandom> (we already assume individual users are logging everything anyway, as are the isps)</p>
-15:49 <+fox> <modulus> right, so a DR-enabled i2p wouldn't be the end of the world</p>
-15:51 < Complication3> Someone would have to bother forking that, though... :P</p>
-15:52  * jrandom keeps my mouth shut ;)</p>
-15:52 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:53 < jrandom> if not</p>
-15:53  * jrandom winds up</p>
-15:53  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/190.rst b/i2p2www/meetings/190.rst
new file mode 100644
index 00000000..7b9a13e8
--- /dev/null
+++ b/i2p2www/meetings/190.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 21, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/191.log b/i2p2www/meetings/191.log
index 7fc09e70..9e4024df 100644
--- a/i2p2www/meetings/191.log
+++ b/i2p2www/meetings/191.log
@@ -1,58 +1,52 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 191{% endblock %}
-{% block content %}<h3>I2P dev meeting, November 28, 2006</h3>
-<div class="irclog">
-15:14 < jrandom> 0) hi</p>
-15:14 < jrandom> 1) Net status</p>
-15:14 < jrandom> 2) Syndie dev status</p>
-15:14 < jrandom> 3) ???</p>
-15:14 < jrandom> 0) hi</p>
-15:14  * jrandom waves</p>
-15:14 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-November/001320.html</p>
-15:14 < jrandom> (sorry for the delay, small kitchen emergency)</p>
-15:14 < gott> Hello, jrandom.</p>
-15:15 < jrandom> heya gott</p>
-15:15 < jrandom> ok, lets jump in to 1) net status</p>
-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)</p>
-15:16 < gott> I have been able to download my favourite modernist movie Metroland from the Frenchmen in #fr via i2psnark</p>
-15:16 < gott> Going at download rate of 4400 kb/s; upload around the same.</p>
-15:16 < gott> 6 peers.</p>
-15:16 < gott> Very good for the propagation of European modernist fiction.</p>
-15:16 < jrandom> !thwap</p>
-15:17 < jrandom> (or, if you are actually getting 4Mbps, both sides are using 0hop tunnels)</p>
-15:17 < gott> bytes a second.</p>
-15:18 < jrandom> anyone have anything else to bring up for 1) net status?</p>
-15:20 < jrandom> ok, lets jump on over to 2) syndie dev status</p>
-15:20 < gott> Is it possible to make i2p better somehow in this regard?</p>
-15:20 < jrandom> gott: oh, you mean 4400 Bps, not kbps?</p>
-15:20 < jrandom> then i take back the 0hop tunnel thing</p>
-15:21 < jrandom> 4KBps is typical atm, and can be improved with better peer selection and congestion management</p>
-15:22 < jrandom> ok, for syndie dev status, lots of progress going on, as mentioned in the notes</p>
-15:23 < jrandom> there's still a bunch of gaps to fill, but they're largely just filling gaps, not writing new components</p>
-15:24 < jrandom> ok, anyone have anything else on 2) syndie dev status?</p>
-15:25 < jrandom> ok, lets jump on over to 3) ??? then</p>
-15:26 < jrandom> anyone have anything else to bring up in this short meeting?</p>
-15:26 < JosephLeBlanc> Do you need any money?</p>
-15:26 < JosephLeBlanc> oh for fuck sake</p>
-15:26 < JosephLeBlanc> well, do you need any money?</p>
-15:27 < JosephLeBlanc> Do you want a computer?</p>
-15:27 < JosephLeBlanc> Do you want beer?</p>
-15:27 < JosephLeBlanc> What?</p>
-15:27 < jrandom> atm, finances are in pretty good shape, though contributions are always appreciated, of course</p>
-15:27 < JosephLeBlanc> Out with it</p>
-15:27 < JosephLeBlanc> Alright, then</p>
-15:27 <+zzz> post a bounty for emule client :)</p>
-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 ;)</p>
-15:28 < jrandom> lol zzz</p>
-15:28 < JosephLeBlanc> Not everyone is a lesbian snob who has a 40 thousand dollar student loan that needs paying off</p>
-15:28 <+zzz> keep up the good work jr</p>
-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</p>
-15:29 < JosephLeBlanc> Can you implement modulus' lovesoc</p>
-15:29 < JosephLeBlanc> ?</p>
-15:29 < jrandom> thanks zzz, you as well (your services and code definitely help tons!)</p>
-15:29 <+zzz> get the baf lol</p>
-15:30  * jrandom runs to the corner</p>
-15:30  * jrandom winds up</p>
-15:30  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/191.rst b/i2p2www/meetings/191.rst
new file mode 100644
index 00000000..8610f7ce
--- /dev/null
+++ b/i2p2www/meetings/191.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 28, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/192.log b/i2p2www/meetings/192.log
index f14a2d46..b30fb4c3 100644
--- a/i2p2www/meetings/192.log
+++ b/i2p2www/meetings/192.log
@@ -1,58 +1,52 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 192{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 5, 2006</h3>
-<div class="irclog">
-15:00 < jrandom> 0) hi</p>
-15:00 < jrandom> 1) Net status</p>
-15:00 < jrandom> 2) Syndie dev status</p>
-15:00 < jrandom> 3) iToopie</p>
-15:00 < jrandom> 4) ???</p>
-15:00 < jrandom> 0) hi</p>
-15:00  * jrandom waves</p>
-15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2006-December/001321.html</p>
-15:01 < jrandom> (almost two hours before the meeting, too! :)</p>
-15:01 < jrandom> ok, lets jump on in to 1) net status</p>
-15:01 < jrandom> things are going pretty well, no big change on this front</p>
-15:02  * jrandom has been connected to irc here for 20 days now, too (a record, i believe)</p>
-15:03 < jrandom> not much more to add on this front though atm</p>
-15:03 < jrandom> so, if there's nothing else on it, lets jump forward to 2) syndie dev status</p>
-15:04 < jrandom> progress continues here, with more bits and bobs becoming workable</p>
-15:04 < jrandom> its still quite rough though... "utilitarian", but graphically utilitarian ;)</p>
-15:05 < jrandom> the alpha isn't imminent though, but i hope to have it ready soon</p>
-15:07 < jrandom> in any case, more info as it comes about :)</p>
-15:08 < jrandom> ok, lets jump briefly on over to 3) iToopie</p>
-15:08 < jrandom> as mentioned in the notes, Thanks y'all!  :)</p>
-15:08 < jrandom> ok, continuing on in rapid fire to 4) ???</p>
-15:08 < jrandom> anyone have anything they'd like to bring up for the meeting?</p>
-15:10 < jrandom> (its probably been a year or two since our last 10 minute meeting, but perhaps that's for the best)</p>
-15:10 <+fox> <Ch0Hag> Hey wow. Totally by accident I am actually present for an I2P meeting.</p>
-15:11 <+fox> <Ch0Hag> Hi mum!</p>
-15:11 <+fox> <Ch0Hag> This is going in the logs right? :)</p>
-15:11 < jrandom> heh yeah ch0 ;)</p>
-15:12 <+fox> <Ch0Hag> Because of course my mum reads I2P meeting logs...</p>
-15:12 < burl> i was going to ask about the licensing but i just read the answer on www.i2p (why not gpl?)</p>
-15:13 < jrandom> gpl kills babies</p>
-15:13  * jrandom ducks</p>
-15:13 < burl> i have to print them out for my mum. she's not very good with computers</p>
-15:13 < jrandom> heheh</p>
-15:14 < burl> i've been reading all about the free software movement recently. ethically it seems bang on</p>
-15:14 < burl> closed source is evil :)</p>
-15:14 < jrandom> good, evil, they're all the same.  what matters here is that closed source is /insecure/ ;)</p>
-15:15 < jrandom> (syndie license summary @ http://syndie.i2p.net/faq.html#license less religious license info for i2p @ http://www.i2p.net/licenses )</p>
-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?</p>
-15:16 < jrandom> you can't steal whats free</p>
-15:16 < burl> yeah, but i mean made changes to the source and didn't let you see them</p>
-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 ;)</p>
-15:17 < jrandom> but, yeah, i understand.  disagree, but understand</p>
-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</p>
-15:18 < burl> because no-one would trust the closed version so it could never take over in popularity</p>
-15:20 < jrandom> aye</p>
-15:21 < jrandom> licence rants are always good ways to fill up 10m of meeting logs ;)</p>
-15:21 < jrandom> ok, anyone have anything else for the meeting?</p>
-15:23 <+fox> <Ch0Hag> Well if you need more meeting time - why Java?</p>
-15:23 <+fox> <Ch0Hag> I mean ewww!</p>
-15:23 < jrandom> !thwap</p>
-15:24  * jrandom winds up</p>
-15:24  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/192.rst b/i2p2www/meetings/192.rst
new file mode 100644
index 00000000..e412ce8d
--- /dev/null
+++ b/i2p2www/meetings/192.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 5, 2006
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/193.log b/i2p2www/meetings/193.log
index 51b12b4f..82cfb2cf 100644
--- a/i2p2www/meetings/193.log
+++ b/i2p2www/meetings/193.log
@@ -1,26 +1,21 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 193{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 12, 2006</h3>
-<div class="irclog">
-15:03 < jrandom> 0) hi</p>
-15:03 < jrandom> 1) Net status</p>
-15:03 < jrandom> 2) Syndie dev status</p>
-15:04 < jrandom> 3) ???</p>
-15:04 < jrandom> 0) hi</p>
-15:04  * jrandom waves</p>
-15:04 < jrandom> weekly status notes posted up @ http://dev.i2p.net/pipermail/i2p/2006-December/001322.html</p>
-15:04 < jrandom> lets jump on in to 1) net status</p>
-15:05 < jrandom> no real changes here, though its good to note that stability seems quite sufficient on irc, even with long tunnels</p>
-15:05 < jrandom> though, of course, thats not necessarily the case for eveyone, and can vary substantially</p>
-15:05 < jrandom> but, 'tis nice to see anyway</p>
-15:05 < jrandom> ok, anyone have anything to bring up for 1) net status?</p>
-15:07 < jrandom> if not, lets swing over to 2) syndie dev status</p>
-15:07 < jrandom> lots going on here, though summarized in the mailing list post</p>
-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)</p>
-15:11 < jrandom> ok, anyone have anything to discuss for 2) syndie dev status?</p>
-15:11 < jrandom> if not, lets shimmy over to 3) ???</p>
-15:12 < jrandom> anyone have anything else to bring up for the meeting?</p>
-15:16 < jrandom> if not</p>
-15:16  * jrandom winds up</p>
-15:16  * jrandom *baf*s the meeting closed</p>
-{% endblock %}
\ No newline at end of file
+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/193.rst b/i2p2www/meetings/193.rst
new file mode 100644
index 00000000..c11a0795
--- /dev/null
+++ b/i2p2www/meetings/193.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 12, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/194.log b/i2p2www/meetings/194.log
index 39c4c502..7dfbebb0 100644
--- a/i2p2www/meetings/194.log
+++ b/i2p2www/meetings/194.log
@@ -1,160 +1,154 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 194{% endblock %}
-{% block content %}<h3>I2P dev meeting, December 26, 2006</h3>
-<div class="irclog">
-15:02 < jrandom> 0) hi</p>
-15:02 < jrandom> 1) Net status</p>
-15:02 < jrandom> 2) Syndie 1.000a</p>
-15:02 < jrandom> 3) ???</p>
-15:02 < jrandom> 0) hi</p>
-15:02  * jrandom waves</p>
-15:02 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2006-December/001324.html</p>
-15:03 < jrandom> lets jump on in to 1) net status</p>
-15:03 < Complication2> Oh, I entirely forgot it's a Tuesday</p>
-15:03 < jrandom> things are going pretty well, as mentioned, though my router finally had a restart after a 45 day uptime</p>
-15:04 < jrandom> (but frankly, i'd be quite happy if we could consistently get 1+ month uptimes :)</p>
-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</p>
-15:04 < Complication2> Other router is capable of pulling one-month uptimes, but it's not a very high-traffic router</p>
-15:05 < Complication2> Rather modest, in fact</p>
-15:05 < jrandom> stats.i2p has been showing a slightly reduced build success rate in the past week, but that may just be seasonal</p>
-15:07 <+fox> <hottuna> Ive been getting some weird wrapper log messages</p>
-15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles</p>
-15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | INFO: Log age 2006_09_26.request.log</p>
-15:07 <+fox> <hottuna> INFO   | jvm 1    | 2006/12/26 01:00:00 | 2006-dec-26 00:00:00 org.mortbay.util.RolloverFileOutputStream removeOldFiles</p>
-15:07 < jrandom> irc is still doing pretty well though, even with 3 hop tunnels</p>
-15:07 < jrandom> oh interesting hottuna, sounds like some verbose commons-logging stuff</p>
-15:08 < jrandom> (jetty uses their own logger, not ours)</p>
-15:08 <+fox> <hottuna> nothing to worry about then .. </p>
-15:08 <+fox> <hottuna> but still ahven been running my router due to BW starvation</p>
-15:09 < jrandom> starvation being "not enough bw for i2p", or "i2p using too much bw"?</p>
-15:11 <+fox> <hottuna> Well, both but since Im running i2p to donate bw the first alternative fits me best</p>
-15:11 < jrandom> ah heh, ok</p>
-15:11 <+fox> <hottuna> I just started syndie for the first time and Im feling a bit overwhelmed, dont really know where to begin</p>
-15:11 <+fox> <hottuna> nice touch with adding the standard archive though</p>
-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 :)</p>
-15:13 < jrandom> 1.000a is out, download and enjoy!</p>
-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</p>
-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</p>
-15:15 < bar> congratulations on the syndie alpha release, you've been working long and hard on this. respect.</p>
-15:16 < Complication2> Same here. Impressive database and quite promising interface. :)</p>
-15:16 <+fox> <hottuna> Im using syndie right now and reading the epic syndie and i2p direction post</p>
-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" /></p>
-15:16 < jrandom> thanks, there's lots to do to get syndie where it needs to be, but its a start</p>
-15:17 <+fox> <hottuna> there is much work to be done on the usability front but still you have come a long way</p>
-15:17 < jrandom> gloin: aye, 3 of 'em (swt.win32, swt.osx, and swt.linux32) - they're only used for "ant dist"</p>
-15:18 < Complication2> does "ant" default to "ant clean jar", by the way?</p>
-15:18  * Complication2 checks</p>
-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</p>
-15:19 < jrandom> i need your opinions, feedback, and suggestions to improve things</p>
-15:19 < Complication2> Aha, dependency check and jar</p>
-15:19 < Complication2> (without the cleanup part)</p>
-15:19 < jrandom> right Complication2, no 'clean' by default</p>
-15:21 < gloin> does "ant dist" build versions for linux, win32 and so on?</p>
-15:21 < jrandom> gloin: yeah, building installers, .exe files, etc</p>
-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</p>
-15:23 < Complication2> darn, I overlooked the "run" target then</p>
-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/)</p>
-15:23 < Complication2> Cooked up a run.sh :D</p>
-15:24 < Complication2> two-liner, though, so nothing time-consuming</p>
-15:24 < jrandom> that works too :)</p>
-15:24 < Complication2> Yep, "ant run" worked nicely</p>
-15:24 < gloin> ant run seem to work, the install linux32.exe complains about missing swt.</p>
-15:24 < Complication2> Just tested</p>
-15:26 < jrandom> hmm gloin, and swt.jar exists in the installed syndie lib dir?</p>
-15:27 < gloin> yes.</p>
-15:28 < jrandom> and you're running "java -jar /some/path/to/that/syndie/bin/syndie.exe"?  or do you mean the linux installer?</p>
-15:29 < gloin> the installer was fine. it created the syndie-1.000a directory.</p>
-15:31 < gloin> Exception in thread "main" java.lang.UnsatisfiedLinkError: no swt-pi-gtk-3235 in java.library.path</p>
-15:33 < Complication2> One little question (I'm testing out the Linux binary)</p>
-15:33 < jrandom> hmm, did it create the libswt-pi-gtk-3235.so in /tmp/ gloin?</p>
-15:33 < Complication2> Where to obtain the public key "393F2DF9"?</p>
-15:33 < jrandom> thats a good question... </p>
-15:34 < gloin> who? when?</p>
-15:34 < gloin> at the moment, theres no  libswt-pi-gtk-3235.so in /tmp/</p>
-15:35 < jrandom> gloin: the new swt (3.3M4) shipped with syndie extracts the native libs to /tmp/ when it can't find them</p>
-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?</p>
-15:36 < jrandom> Complication2: it'll be up on the various keyservers and the website after the meeting</p>
-15:37 < Complication2> Thanks :)</p>
-15:37 < jrandom> (its on my keyrings which aren't accessible from my windows box)</p>
-15:37 < Complication2> Meanwhile, I found out using more conventional means that my download of the binary *did* abort early</p>
-15:37  * Complication2 fetches the end again</p>
-15:38 < gloin> no. Maybe I rebuild the the installer</p>
-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)?</p>
-15:40 < jrandom> in any case, we'll keep on debugging as things come up</p>
-15:41 < gloin> it's not in it.</p>
-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</p>
-15:42 < jrandom> (there are much smaller downloads for upgrading syndie than the full 4-5+MB ones - see syndie.i2p.net/download.html)</p>
-15:42 <+fox> <hottuna> whats is the i2p syndie archives url on the i2p network ?</p>
-15:43 < jrandom> gloin: could you priv msg me the jar tvf output?</p>
-15:43 < jrandom> hottuna: http://archive.syndie.i2p/</p>
-15:43 <+fox> <hottuna> thank you</p>
-15:45 < jrandom> (note that archive.syndie.i2p / syndie.i2p.net:8080 are just instances of syndie with the built-in HTTP server running)</p>
-15:45 <+fox> <hottuna> oh :) wicked :)</p>
-15:45 <+fox> <hottuna> oh btw the syndie clock doesnt match the clock on my system</p>
-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)</p>
-15:46 < jrandom> syndie clock?</p>
-15:46 <+fox> <hottuna> or the time stamps on messages in syndie</p>
-15:47 <+fox> <hottuna> wait a second. . now they seem to be right..</p>
-15:47 <+fox> <hottuna> a restart later</p>
-15:52 < gloin> how do I build a headless archive server? I assume that the import.cgi is not 'supported' anymore?</p>
-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. </p>
-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 )</p>
-15:55 < gloin> thanks a lot.</p>
-15:56 < jrandom> if you're going to be firing up your archive again, i should be thanking you :)</p>
-15:57 < gloin> puh.. even with a gui, it looks complicated :)</p>
-15:58 < jrandom> aye, y'all've got your work cut out for you - help make it usable and useful :)</p>
-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</p>
-15:59 < jrandom> shimmying on over to 3) ???, anyone have anything else to bring up for the meeting?</p>
-16:00 < Complication2> Tested the Linux binary installer, runs nicely</p>
-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"</p>
-16:00 < Complication2> Along with NetBeans and stuff</p>
-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...</p>
-16:01 < jrandom> ah, yeah.  izpack and the java packagers/installers are still working through the kde integration</p>
-16:02 < Complication2> Anyway, small detail</p>
-16:02 < Complication2> But wanted to mention just in case</p>
-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)</p>
-16:02 < jrandom> hopefully to be fixed when izpack fixes it (its on their radar)</p>
-16:03 < Complication2> Right</p>
-16:03 < Complication2> Either way, the shortcut appeared, and the uninstaller shortcut appeared too</p>
-16:03 < jrandom> wewt</p>
-16:03 < Complication2> And the uninstalled worked nicely too (used it too since I typically compile from sources)</p>
-16:03 < Complication2> =uninstaller</p>
-16:04 < bar> i have two questions, slightly related to each other</p>
-16:04 < bar> 1. any plans yet on when to nuke the old syndie?</p>
-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?</p>
-16:05 < Complication2> On 2, I think it currently would collide</p>
-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" :)</p>
-16:07 < Complication2> ...going to "http://archive.syndie.i2p" through "localhost:4444"</p>
-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</p>
-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</p>
-16:09 < bar> loverly :)</p>
-16:09 < Complication2> oh, you meant the web pages</p>
-16:10 < Complication2> I thought you meant the archive :)</p>
-16:10 < bar> correct Complication2, sorry for not being clear on that</p>
-16:10 < gloin> the own forum is the own identity?</p>
-16:11 < Complication2> There's definitely a default identity / pseudonym created in a new Syndie instance</p>
-16:11 < Complication2> I'm not sure if it auto-creates a forum</p>
-16:11 < jrandom> gloin: every identity has a forum (and every forum is owned by an identity)</p>
-16:12 < jrandom> a forum, in syndie, is just a public key</p>
-16:12 < jrandom> (as is an author)</p>
-16:12 < Complication2> I've forgotten how I went about doing it, and it was in October with the text interface anyway, I think :)</p>
-16:12 < jrandom> ((in the database and code, they're both called 'channels', but the ui talks about forums and authors/nyms))</p>
-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"</p>
-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?</p>
-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</p>
-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)</p>
-16:15 < jrandom> seems reasonable Complication2 & bar</p>
-16:17 < jrandom> gloin: this stuff is definitely not-obvious, and we need to do a lot of work on making it easier</p>
-16:21 < Complication2> Oops, I've not noticed multiple suggestions for I2Phex tuning by striker on the old Syndie</p>
-16:21  * Complication2 makes local copies</p>
-16:23 < jrandom> :)  the old syndie will still remain accessible at syndiemedia.i2p/ and syndie.i2p.net:8000/ </p>
-16:23 < jrandom> ok, anyone have anything else for the meeting?</p>
-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?</p>
-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)</p>
-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</p>
-16:33 < jrandom> (syndie.i2p --> syndie.i2p.net as of now, syndiemedia.i2p still points to syndie.i2p.net:8000/)</p>
-16:33 < jrandom> ok, if there isn't anything else for the meeting</p>
-16:33  * jrandom winds up</p>
-16:33  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/194.rst b/i2p2www/meetings/194.rst
new file mode 100644
index 00000000..05203b89
--- /dev/null
+++ b/i2p2www/meetings/194.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 26, 2006
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/195.log b/i2p2www/meetings/195.log
index d52a9f96..af9678f4 100644
--- a/i2p2www/meetings/195.log
+++ b/i2p2www/meetings/195.log
@@ -1,78 +1,72 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 195{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 2, 2007</h3>
-<div class="irclog">
-15:02 < jrandom> 0) hi</p>
-15:02 < jrandom> 1) Net status and plans</p>
-15:02 < jrandom> 2) Syndie 1.001a</p>
-15:02 < jrandom> 3) ???</p>
-15:02 < jrandom> 0) hi</p>
-15:02  * jrandom waves</p>
-15:02 < jrandom> weekly status notes posted up on http://dev.i2p.net/pipermail/i2p/2007-January/001325.html</p>
-15:03  * mrflibble waves to jrandom</p>
-15:03  * jrandom expects most are still nursing their hangovers, so we'll do this quietly</p>
-15:04 < jrandom> lets jump on in to 1) Net status and plans</p>
-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</p>
-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</p>
-15:06 < jrandom> but, we'll see how it goes as things progress</p>
-15:06 < jrandom> for the time being though, the net seems fairly steady-state, which is Good</p>
-15:07 < jrandom> anyone have anything they'd like to bring up re: net status and plans?</p>
-15:09 < jrandom> if not, lets hop on over to 2) Syndie 1.001a</p>
-15:09 < z^z> anything I can work on on the net - netdb or tunnels?</p>
-15:09  * jrandom hops back</p>
-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</p>
-15:11 < z^z> think about it anyway</p>
-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</p>
-15:12 < z^z> ok thx will poke around and ask questions later</p>
-15:12 < jrandom> perhaps a new flag on the netDb lookup message asking for "give me some floodfill peers"</p>
-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</p>
-15:13 < z^z> ha that will take me into new territory sounds like fun for the new year</p>
-15:13 < jrandom> :)</p>
-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?</p>
-15:15 < jrandom> nope</p>
-15:15 < jrandom> or, not that i recall...</p>
-15:16 < bar> okie</p>
-15:17 < jrandom> (a great spot for that would be KademliaFloodfillNetworkFacade::dropAfterLookupFailed)</p>
-15:18 < jrandom> er, KademliaNetworkDatabaseFacade, that is (floodfill extends it)</p>
-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)</p>
-15:21 < jrandom> ok, anything else on 1) Net status and plans?</p>
-15:23  * jrandom resumes the hopping to 2) Syndie 1.001a </p>
-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</p>
-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 ;)</p>
-15:27 < jrandom> anyone have anything to bring up on syndie 1.001a, or shall we skip on over to 3) ???</p>
-15:27 < jrandom> anyone have anything else they'd like to discuss in the meeting?</p>
-15:28 <+fox> <covracer> are you still not in favor of an ebuild?</p>
-15:29 < jrandom> for syndie, or i2p?  </p>
-15:29 <+fox> <covracer> i2p</p>
-15:29 < jrandom> correct, i am still not in favor of an ebuild</p>
-15:29 < jrandom> (thank you for the offer/suggestion though!)</p>
-15:30 < jrandom> i2p's problems are not related to the size of the network, so increasing the size will not address them</p>
-15:30 < jrandom> instead, it will just force more people to deal with the problems and the upgrade path to address them</p>
-15:30 <+fox> <covracer> yeah</p>
-15:31 <+fox> <covracer> alex has done some good work though on an ebuild</p>
-15:31 <+fox> <covracer> it's in the java-experimental-migration overlay iirc</p>
-15:31 <+fox> * godmode0 is back (gone 01:57:51)</p>
-15:32 <+fox> <covracer> well at any rate it depends on lots improvements in gentoo's handling of java and jetty</p>
-15:32 <+fox> <covracer> and won't get into the main tree any time soon</p>
-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 :)</p>
-15:34 <+fox> <covracer> would a ebuild for syndie be welcomed or should it also be postponed?</p>
-15:34  * jrandom wonders how much shakeup there is going to be in java handling once the sun jvm & libs go gpl</p>
-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</p>
-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</p>
-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</p>
-15:36 < jrandom> kickass, thanks covracer!</p>
-15:37 <+fox> <covracer> easy installation is very important for wide adoption</p>
-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)</p>
-15:37 < jrandom> aye, definitely</p>
-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</p>
-15:40 < jrandom> cool, you likely know more about ebuild writing than I though :)  good luck, and thanks</p>
-15:40 < jrandom> ok, anyone have anything else they'd like to bring up for the meeting?</p>
-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</p>
-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</p>
-15:41 < jrandom> good idea - i'll spam 'em when 1.001a is out</p>
-15:42 < bar> alritey :)</p>
-15:47 < jrandom> ok, if there isn't anything else for the meeting...</p>
-15:47  * jrandom winds up</p>
-15:47  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/195.rst b/i2p2www/meetings/195.rst
new file mode 100644
index 00000000..12c26c79
--- /dev/null
+++ b/i2p2www/meetings/195.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 2, 2007
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/196.log b/i2p2www/meetings/196.log
index aee807ae..23ea4f66 100644
--- a/i2p2www/meetings/196.log
+++ b/i2p2www/meetings/196.log
@@ -1,117 +1,111 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 196{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 9, 2007</h3>
-<div class="irclog">
-15:07 < jrandom> 0) hi</p>
-15:07 < jrandom> 1) Net status</p>
-15:07 < jrandom> 2) I2Phex 0.1.1.38</p>
-15:07 < jrandom> 3) Syndie progress</p>
-15:07 < jrandom> 4) Syndie bug harvesting contest</p>
-15:07 < jrandom> 5) ???</p>
-15:07 < jrandom> 0) hi</p>
-15:07  * jrandom waves</p>
-15:07 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-January/001328.html</p>
-15:09 < jrandom> while y'all continue drooling over the macworld stuff, lets jump on in to 1) net status</p>
-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</p>
-15:09 < jrandom> anyone have anything to add regarding the network status?</p>
-15:09 <+zzz> I'm testing a couple of i2psnark tweaks, nothing major</p>
-15:10 < jrandom> ah cool, regarding the recent bug reports, or other goodies we can look forward to?</p>
-15:11 <+zzz> other - mostly better handling of torrents with > 4 peers</p>
-15:11 < jrandom> wikked</p>
-15:11 <+zzz> also catching a couple of common OOM spots rather than dumping the whole JVM</p>
-15:12 < tea> sounds great, atm i2p-bt seems the best choice for "high"-speed torrents</p>
-15:12 <+zzz> i.e where it grabs a whole 256KB - 1MB chunk to store a piece</p>
-15:13 <+zzz> everybody pick a torrent and pile onto it to help me test :)</p>
-15:14 < jrandom> kickass, let us know when we should try things out zzz</p>
-15:14 < tea> shall someone redo 'casino royale' ? :)</p>
-15:14  * jrandom mentions that this meeting is logged and posted on the web ;)</p>
-15:15 <+void> oh, the meeting</p>
-15:15 < tea> no volunteers, then</p>
-15:16 < jrandom> ok cool, anyone have anything else for 1) Net status?</p>
-15:17 < bar> while we're mentioning i2psnark...</p>
-15:18 < bar> ...would it be possible to start, stop and restart i2psnark from the console?</p>
-15:18 < bar> (rather than restarting the whole router to kill the tunnels)</p>
-15:19 <+zzz> don't know - jrandom you have any thoughts?</p>
-15:20 < jrandom> bar: when you say stop and start, what does that entail beyond stopping and starting the inividual torrents?</p>
-15:21 < bar> killing the i2psnark tunnels that are draining my resources when not torrenting</p>
-15:22 < bar> (the tunnels don't die when you remove the .torrents, iirc)</p>
-15:22 < jrandom> ah, stopping the actual i2p destination for it.  doable without much trouble, the web interface has access to the SnarkManager</p>
-15:23 < jrandom> (an interim workaround could be to set the tunnel lengths to 0 until you need to use them again)</p>
-15:23 < jrandom> but you're right, that would be useful</p>
-15:23 <+void> you could change the tunnels to have 0 depth, although that would be error prone</p>
-15:23 <+zzz> good idea to provide a stop tunnel button on the web page, agreed</p>
-15:23  * jrandom !hi5s void</p>
-15:24 <+void> ack, i'm lagging *that* much?</p>
-15:24 < jrandom> I2PSnarkUtil already has a static .disconnect() too</p>
-15:25 < jrandom> (so calling that from the I2PSnarkServlet should be trivial)</p>
-15:25 < jrandom> zzz: you wanna hit that, or you want me to toss that in there?</p>
-15:27 <+zzz> I don't see a question there so take it</p>
-15:27 < jrandom> ok cool, shall do</p>
-15:27 < jrandom> ok, anyone have anything else on 1) Net status?</p>
-15:29 < jrandom> if not, lets hop over to 2) I2Phex 0.1.1.38</p>
-15:29 < jrandom> Complication: wanna pelt us with the low down?</p>
-15:31 < jrandom> afaik, there's a good summary of changes in the CVS and announcement (http://forum.i2p.net/viewtopic.php?t=2005)</p>
-15:33 < tea> is there a possibility of permantly changing the tunnel lengths ?</p>
-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)</p>
-15:35 < bar> tea: yes, in i2phex.cfg (i2pInboundLength, i2pInboundLengthVariance, i2pOutboundLength, i2pOutboundLengthVariance)</p>
-15:36 < tea> i was thinking of the option tab i2p-rufus has</p>
-15:37 < tea> could something like that be added ? </p>
-15:38 < jrandom> i think complication said that'd be a good idea, so its probably pretty doable</p>
-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 :)</p>
-15:38 < jrandom> oh, nm, seems complication said 'e's working on it</p>
-15:39 < jrandom> http://forum.i2p.net/viewtopic.php?t=2005#9149</p>
-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 ...</p>
-15:42 < jrandom> aye.  ok, anyone have anything else on 2) I2Phex 0.1.1.38?</p>
-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 :)</p>
-15:43  * bar waves</p>
-15:43 < jrandom> aye, congrats ArneBab et al!</p>
-15:45 < tea> maybe they'll wave back one day ...</p>
-15:46 < jrandom> ArneBab and GregorK have had some good feedback on i2phex over the years </p>
-15:46 <+void> the day that i2phex reaches version 3.0?</p>
-15:46 < jrandom> here's hopin :)</p>
-15:47 < bar> we'll be long gone by then, but yeah :)</p>
-15:48 < jrandom> ok, lets jump on over to 3) Syndie progress</p>
-15:48 < jrandom> lots of progress in the last week, including 1.001a hitting the street</p>
-15:50 < jrandom> though most of the discussion on that front is going on within syndie itself</p>
-15:50 < jrandom> so, if you're not on it yet, get on it and find out more :)</p>
-15:51 < jrandom> anyone have anything they'd like to discuss regarding syndie?</p>
-15:53 <+void> well, i just ran sync and it imported one unread message with a bunch of read ones</p>
-15:53 <+void> but i guess we'll debug that after the meeting?</p>
-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</p>
-15:54 < jrandom> ok, lets hop on over to 4) Syndie bug harvesting contest</p>
-15:55 <+void> can you register anonymous egold accounts?</p>
-15:55 < jrandom> aye, no ID necessary</p>
-15:56 <+void> ah, cool</p>
-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</p>
-15:56 < jrandom> but it is more than sufficient to defend against most adversaries</p>
-15:57 <+void> yeah, naturally</p>
-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</p>
-15:58 < jrandom> I'm hoping we'll continue this contest every month</p>
-15:58 <+void> hehe</p>
-15:59 <+void> heheat least it's fun time</p>
-15:59 <+void> arg</p>
-16:00 < jrandom> does anyone have any questions regarding the contest, or suggestions, or frisbees?</p>
-16:01 <+tethra> contest?</p>
-16:01 <+tethra> (i am late)</p>
-16:01  * tethra reads up</p>
-16:01 <+tethra> cool :o</p>
-16:02 < jrandom> so get yer bug reports flowin' :)</p>
-16:03 < jrandom> ok, lets swing on over to 5) ???</p>
-16:03 <+void> they already are :)</p>
-16:03 <+tethra> yessir! ;)</p>
-16:03 < jrandom> aye, thanks!  (yes, I'm counting everything from jan1 to jan31 :)</p>
-16:03 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
-16:04 <+fox> <nony> does it run on java6?</p>
-16:04 < tea> sure</p>
-16:04 <+tethra> come to that, does it compile with gcj?</p>
-16:04 < jrandom> nony: i run it on java6 here, yes</p>
-16:04 < jrandom> tethra: aye, and runs ;)</p>
-16:04 <+tethra> excellent</p>
-16:04 <+tethra> ;)</p>
-16:04 <+fox> <nony> sweet</p>
-16:07 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:09 < jrandom> if not...</p>
-16:09  * jrandom winds up</p>
-16:09  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/196.rst b/i2p2www/meetings/196.rst
new file mode 100644
index 00000000..6b01e20b
--- /dev/null
+++ b/i2p2www/meetings/196.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 9, 2007
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/197.log b/i2p2www/meetings/197.log
index b404b52c..983286d0 100644
--- a/i2p2www/meetings/197.log
+++ b/i2p2www/meetings/197.log
@@ -1,39 +1,33 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 197{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 16, 2007</h3>
-<div class="irclog">
-15:03 < jrandom> 0) hi</p>
-15:03 < jrandom> 1) Net status</p>
-15:03 < jrandom> 2) I2PSnark updates</p>
-15:03 < jrandom> 3) Syndie progress</p>
-15:03 < jrandom> 4) ???</p>
-15:03 < jrandom> 0) hi</p>
-15:03  * jrandom waves</p>
-15:03 < jrandom> weekly status notes up at http://dev.i2p.net/pipermail/i2p/2007-January/001329.html</p>
-15:05 < jrandom> as y'all dig through that, lets jump on in to 1) Net status</p>
-15:05 < jrandom> not much change at the moment on this front</p>
-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</p>
-15:07 < jrandom> zzz: what period is that chart based off?</p>
-15:07 <+zzz> 1 month</p>
-15:07 < jrandom> wow cool</p>
-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</p>
-15:10 < jrandom> ok, anyone have anything else to bring up for 1) net status?</p>
-15:12 < jrandom> if not, lets hop on over to 2) i2psnark updates</p>
-15:12 < jrandom> zzz, wanna give us the low down?</p>
-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.</p>
-15:13 <+zzz> added a stop-all button which usually doesn't work if there is traffic, it seems</p>
-15:13 <+zzz> looking for testers and reports as usual, thanks</p>
-15:14 < jrandom> kickass, thanks zzz</p>
-15:14 < jrandom> when you feel its right, we can package 'er up and ship a new 0.6.1.27 w/ that bundled</p>
-15:15 <+zzz> ok maybe a week or 2</p>
-15:16 < jrandom> sounds good</p>
-15:17 < jrandom> ok lets jump on over to 3) Syndie progress</p>
-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</p>
-15:19 < jrandom> there'll be an announcement when thats out, in syndie, on the web pages, on the forum, and in the list</p>
-15:19 < jrandom> ok, swinging over to 4) ???</p>
-15:20 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-15:23 < jrandom> if not...</p>
-15:23  * jrandom winds up</p>
-15:23  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/197.rst b/i2p2www/meetings/197.rst
new file mode 100644
index 00000000..c4d8f86e
--- /dev/null
+++ b/i2p2www/meetings/197.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 16, 2007
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/198.log b/i2p2www/meetings/198.log
index aedd393e..eecbb9f4 100644
--- a/i2p2www/meetings/198.log
+++ b/i2p2www/meetings/198.log
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 198{% endblock %}
-{% block content %}<h3>I2P dev meeting, January 30, 2007</h3>
-<div class="irclog">
 15:06 < jrandom> 0) hi<p>
 15:06 < jrandom> 1) Net status<p>
 15:06 < jrandom> 2) Syndie status<p>
@@ -10,7 +6,7 @@
 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 <+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>
@@ -52,12 +48,10 @@
 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: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>
-</div>
-{% endblock %}
\ No newline at end of file
diff --git a/i2p2www/meetings/198.rst b/i2p2www/meetings/198.rst
new file mode 100644
index 00000000..9b6731b1
--- /dev/null
+++ b/i2p2www/meetings/198.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 30, 2007
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/199.log b/i2p2www/meetings/199.log
index 2b477f6e..ba4bd456 100644
--- a/i2p2www/meetings/199.log
+++ b/i2p2www/meetings/199.log
@@ -1,241 +1,235 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 199{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 6, 2007</h3>
-<div class="irclog">
-15:02 < jrandom> 0) hi</p>
-15:02 < jrandom> 1) Net status</p>
-15:02 < jrandom> 2) Syndie dev status</p>
-15:02 < jrandom> 3) January bug harvesting contest winners!</p>
-15:02 < jrandom> 4) ???</p>
-15:02 < jrandom> 0) hi</p>
-15:02  * jrandom waves</p>
-15:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001333.html</p>
-15:03 < jrandom> hopping on to 1) Net status</p>
-15:03 < jrandom> I don't really have much to add here (as you can probably tell ;)</p>
-15:03 < jrandom> anyone have anything to bring up regarding the network status?</p>
-15:04 <+void> used to be better, somehow...</p>
-15:04 <+void> but not bad</p>
-15:05 < jrandom> its odd, the last wek or so our build rates have been going back up, per stats.i2p</p>
-15:05 < tethrage> is there a long term pattern?</p>
-15:06 < tethrage> (in build rate change)</p>
-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)</p>
-15:07 < tethrage> i see</p>
-15:08 < tethrage> is there any information that could be provided to help?</p>
-15:08 < tethrage> from just normal routers that is</p>
-15:08 < jrandom> not really, from my point of view</p>
-15:09 < tethrage> i see</p>
-15:09 < jrandom> (basically we just need to implement some code changes before moving forward)</p>
-15:10 < tethrage> i see</p>
-15:11 < jrandom> ok, anyone have anything else for 1) Net status?</p>
-15:12 < jrandom> if not, lets skip on over to 2) Syndie dev status</p>
-15:14 < jrandom> lots going on here, as you can read</p>
-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</p>
-15:14 <+fox> <mk> -d</p>
-15:15 < jrandom> ah, thats a good idea</p>
-15:16 <+void> mk: a forum is an identity :)</p>
-15:16 <+void> and vice versa</p>
-15:17 < jrandom> aye, though we don't want to confuse people too much by making this odd duality visible</p>
-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</p>
-15:18 <+void> ah</p>
-15:18 < jrandom> right - people think of forums differently than they think of identities, so need to make sure we behave as expected</p>
-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</p>
-15:19 <+fox> <mk> (a dropdown for keys)</p>
-15:20 <+void> i'd prefer a global identity dropdown that was visible at all times</p>
-15:20 <+fox> <mk> like, who you're posting under?</p>
-15:20 < jrandom> hmm</p>
-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</p>
-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</p>
-15:22 <+void> though your identity is not used anywhere else other than posting</p>
-15:22 <+fox> <mk> what do you mean?</p>
-15:23 <+void> pushing new posts?</p>
-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</p>
-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)</p>
-15:24 <+void> true</p>
-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</p>
-15:25 < jrandom> perhaps we can find a way to accomplish all of that transparently through the gui though</p>
-15:26 < jrandom> (running with multiple archives locally without having to fire up syndie twice)</p>
-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</p>
-15:27 < tethrage> syndie doesn't aim for anonymity, just security</p>
-15:27 < tethrage> it is the transport layer it runs on that should deal with that, surely? :/</p>
-15:27 < jrandom> syndie aims for anonymity</p>
-15:27 < tethrage> (correct me if i'm wrong)</p>
-15:28 < jrandom> the transport layer only deals with a small portion of the anonymity - we need to deal with the rest</p>
-15:28 < jrandom> s/small//</p>
-15:28 < tethrage> does it? :/</p>
-15:28 <+fox> <mk> yes, that's right. syndie deals especially with information leaks</p>
-15:29 < jadeSerpent> ip address anonymity vs. identity anonymity</p>
-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?</p>
-15:29 < tethrage> (not in the same way as i2p etc, anyway)</p>
-15:29 <+fox> <mk> information security is handled by the redundancy of archives</p>
-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 :)</p>
-15:29 < jrandom> tethra: syndie can be used for things that don't require anonymity</p>
-15:30 < jrandom> but syndie must be usable for things that do</p>
-15:30 < jrandom> (otherwise, there is no point to implement it as part of the i2p project)</p>
-15:31 < tethrage> yeah</p>
-15:31 <+void> jrandom: well, to be fair, there still would be a point if syndie provided anonymity by utilizing i2p</p>
-15:31 <+void> but never mind</p>
-15:31 <+void> c</p>
-15:31 < tethrage> what, other than security against information leaks and dodgy code, does syndie do to keep people anonymous? :/</p>
-15:32 < tethrage> surely unless specified you access the archives directly etc?</p>
-15:32 <+fox> <mk> tethrage, information leaks of all sorts. If you'd like we can go into more detail in a bit</p>
-15:33 < jrandom> tethra: for instance, someone accessing an eepsite with javascript enabled</p>
-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</p>
-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?</p>
-15:34 < tethrage> then again, i suppose i'm just arguing semantics, so i'll stop</p>
-15:34 < tethrage> :/</p>
-15:34 < jadeSerpent> i would argue running your own publically accessible archive increases your anonymity in that respect</p>
-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</p>
-15:34 < jrandom> "security against information leaks" is the core of anonymity - controlling who knows facts about your identity</p>
-15:35 < jrandom> ah kickass mk, thanks!</p>
-15:35 < jrandom> jadeSerpent: certainly</p>
-15:35 < tethrage> i see</p>
-15:35 < tethrage> point taken</p>
-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)</p>
-15:36 < jrandom> and we are alpha after all</p>
-15:38 <+void> jrandom: i don't suppose it's hard to turn the tabbed interface into a windowed interface?</p>
-15:38 <+fox> <mk> yep. and if some people prefer the tabbed-for-all approach, then there's no problem with using that</p>
-15:38 <+fox> <mk> (alongside of the browser tab)</p>
-15:39 < jadeSerpent> please no mdi, i suggest something halfway between tabbed and mdi, eclipse's perspectives</p>
-15:39 <+void> mdi is bad, i agree</p>
-15:40 < jadeSerpent> netbeans has something like that too, forget what it's called</p>
-15:40 < jadeSerpent> views or workbenches or something, been a while</p>
-15:41 < jrandom> .png sketches appreciated :)</p>
-15:41  * jrandom went with the tab-for-all style because everyone loves firefox (/etc)</p>
-15:42 < jadeSerpent> when i finish the icons i might hack on some of that</p>
-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</p>
-15:42 < jrandom> wikked</p>
-15:42 < jadeSerpent> tabs are fine for now imo, they're usable</p>
-15:42 < jrandom> mk: http://syndie.i2p.net/roadmap.html ?</p>
-15:42 < jrandom> (though there are no dates on the roadmap)</p>
-15:43 <+fox> <hottuna> nice :=) ... just posted about it to pending tasks :P</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.</p>
-15:44 < jrandom> ah, good point</p>
-15:45 < jrandom> i've been meaning to collate all the small/mid/high level todo items again</p>
-15:45  * jrandom adds that to the todo list</p>
-15:47 < jrandom> ok, anything have anything else to bring up for 2) Syndie dev status?</p>
-15:48 < jrandom> (of course, we've always got the dev forums in syndie, but irc is useful for quick back & forth)</p>
-15:49 < jrandom> if not, lets jump on over to to 3) January bug harvesting contest winners! </p>
-15:50 < jrandom> congrats Darn, voyde, mk, and Anonymous, and thanks to everyone who helped out</p>
-15:51  * jrandom realizes the contest was originally for the top 3, but the count was so close </p>
-15:51 < jrandom> there's a new contest on for this month too, same rules as before</p>
-15:51 < jadeSerpent> how do you know "Anonymous" was only one person? ;)</p>
-15:51 <+fox> <mk> 225 (by my count) bugs in total - impressive</p>
-15:51 <+void> :)</p>
-15:52 <+fox> <mk> jade, the key, I would think :)</p>
-15:52 < jrandom> jadeSerpent: urn:syndie:meta:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=e :)</p>
-15:53 < jrandom> it could be five people sharing that key though</p>
-15:53 < jrandom> but then they've got to share the $50USD ;)</p>
-15:53 < jrandom> (first one with the private key who signs a message to me specifying what egold acct to send it to wins ;)</p>
-15:53 < jadeSerpent> unless one kills the others</p>
-15:54 < jadeSerpent> but that kind of thing would only happen in romania</p>
-15:54 < tethrage> and russia</p>
-15:54 < jrandom> (and britain, and australia, and...)</p>
-15:55 <+fox> <mk> 50usd is a lotta money...</p>
-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</p>
-15:55 < tethrage> not in gbp ;p</p>
-15:55 <+fox> <mk> I know *I'd* kill for it</p>
-15:55 < tethrage> i suppose asking where you're from wouldn't get an answer, mk?</p>
-15:55 < tethrage> :/</p>
-15:56 <+fox> <dw_g> ok, I'll take it ;)</p>
-15:56 <+fox> <mk> russia originally :D now canada</p>
-15:56 < jadeSerpent> 225 bugs is impressive, how many of those have been closed?</p>
-15:56 < tethrage> ice.</p>
-15:56 < tethrage> +n</p>
-15:57 < jrandom> jadeSerpent: i'd thumb it at maybe 75-80% addressed</p>
-15:57 < jadeSerpent> nice</p>
-15:58 < jrandom> (with maybe another 5-10% invalid/wontfix)</p>
-15:58 < jrandom> but actually, thats one of the higher level todo items - get a real management ui on the bugtracking</p>
-15:58  * jadeSerpent recommends trac</p>
-15:58 < jrandom> (it took me a while to walk through all the posts and count them all up manually)</p>
-15:58 <+fox> <mk> external to syndie?</p>
-15:59 < jrandom> hmm, with a syndie-->track exporting system?</p>
-15:59 < jrandom> s/ck//</p>
-15:59 <+fox> <mk> a nice project would be to hook syndie up to a bug tracker</p>
-15:59 < jadeSerpent> yeah</p>
-15:59  * jrandom bets a few SQL queries & inserts would do the trick</p>
-16:00 < jrandom> it would be quite worthwhile though, at least from a readonly-trac perspective</p>
-16:00 <+void> but syncing updates made to trac back into syndie is bound to be tricky, i think</p>
-16:00 < jrandom> full cycle integration isvery hard</p>
-16:00 < jrandom> right</p>
-16:00 <+fox> <mk> at some point it might be worth considering a 'revision'-type system</p>
-16:00 < jrandom> but being able to query & drill down in trac, and generate reports, etc</p>
-16:01 <+fox> <mk> where posts supercede older ones</p>
-16:01 < jrandom> ah, yeah there are hooks for that, but the Overwrite* headers aren't currently honored</p>
-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</p>
-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</p>
-16:04 <+fox> <mk> seeing the number of bugs filed, I agree with jadeSerpent</p>
-16:05 < jrandom> though on the flip sie, how many bugs were discovered by those using syndie to file the bugs?</p>
-16:05  * jrandom is not entirely oposed to a trac or other bug tracking system</p>
-16:05 < jadeSerpent> those kinds of bugs are going to be discovered anyhow</p>
-16:05 <+void> well, severities, components, versions and closing/opening/reopening bugs can be done with syndie tags</p>
-16:05 < jrandom> right</p>
-16:06 <+void> (and most of those already are)</p>
-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</p>
-16:06 < jrandom> it we can feed a real issue tracker via pseudonymously (and authentic) messages, that would be great</p>
-16:06  * jrandom has received a few private bug reports as well, which include sensitive information, - these are protected by syndie's encryption</p>
-16:07 <+fox> <mk> well, why not keep both?</p>
-16:08 < jadeSerpent> i agree that there is however no issue tracker designed with anonymity or more-than-trivial confidentiality in mind</p>
-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</p>
-16:10 < jadeSerpent> maybe trac could be modded to utilize syndie's features there</p>
-16:10 <+fox> <mk> jade, it'd be hard. browsers don't implement signing</p>
-16:12 < jrandom> hmm.  what we have is originally based off: http://syndiemedia.i2p.net:8000/blog.jsp?blog=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=&entry=ovpBy2mpO1CQ7deYhQ1cDGAwI6pQzLbWOm1Sdd0W06c=/1132012800003</p>
-16:12 < jrandom> plus http://dev.i2p.net/~jrandom/bugsp1.txt and http://dev.i2p.net/~jrandom/bugsp2.txt</p>
-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</p>
-16:13 < jrandom> but i'd like to keep whatever it is minimal if possible, because we're building syndie, not a bug tracker :)</p>
-16:14 < jadeSerpent> yeah well you seem to be managing it for now without one ;)</p>
-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</p>
-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</p>
-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</p>
-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</p>
-16:17 <+fox> <mk> I think we should keep that, but also have that bug tracker</p>
-16:18 < jadeSerpent> read-only access for the short term would be nice</p>
-16:18 < jadeSerpent> i prefer a more bug-oriented search interface</p>
-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</p>
-16:19 < jrandom> s/of r/for/</p>
-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</p>
-16:20 < jrandom> though its great for testing our search capabilities :)  [yeah, ok, i'm convinced]</p>
-16:20 < jrandom> so, one vote for trac.  any other votes?  please post to the syndie dev forum, with rationale, of course</p>
-16:21 < jadeSerpent> two votes for trac, unless you've already counted mine ;)</p>
-16:21 < jrandom> aye, thats what i was counting ;)</p>
-16:21 <+fox> <mk> what are the options? I know nothing about trackers</p>
-16:21 < jadeSerpent> i was hoping that was your own vote, but ok</p>
-16:22 < jadeSerpent> i've worked with trac, great third party support</p>
-16:22 < jadeSerpent> bugzilla i would say blah to</p>
-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 </p>
-16:22 < jrandom> yeah, bugzilla is a beast</p>
-16:22 < jadeSerpent> jira is also good, like trac</p>
-16:23 <+void> trac is probably familiar to lots of people, too</p>
-16:23 < jrandom> aye, and good folks too (they gave i2p a license, though we havent used it yet)</p>
-16:23 < jadeSerpent> you have a jira license?</p>
-16:23 < jrandom> aye, jira and fisheye</p>
-16:24 < jadeSerpent> cool, might as well give it a shot</p>
-16:24 < jadeSerpent> btw eclipse's mylar plugin integrates fully into bugzilla, trac, and jira</p>
-16:24 < jadeSerpent> high praises for its interface</p>
-16:25 < jrandom> damn this netbeans/eclipse battle</p>
-16:25 < bar> (bugs are reported automatically when created? ;)</p>
-16:25 < tethrage> (haha)</p>
-16:26 <+fox> <mk> hah, nice</p>
-16:26 < jadeSerpent> jrandom: netbeans support is on the mylar roadmap iirc</p>
-16:26 < jrandom> cool</p>
-16:26 <+fox> <modulus> that's what comes to those who fanatically support sun :-)</p>
-16:27  * jrandom pelts modulus with javabeans</p>
-16:27 < jadeSerpent> even though mylar is offically under the aegis of eclipse foundation</p>
-16:27 <+fox> * mk can't find a live site for trac</p>
-16:27 <+fox> <modulus> http://trac.wordpress.org/</p>
-16:27 < jrandom> mk: http://feedspace.i2p/ atm</p>
-16:28 <+void> http://trac.edgewall.com/</p>
-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 </p>
-16:29 < jadeSerpent> http://overlays.gentoo.org/proj/alt/wiki</p>
-16:29 <+void> (^ official meta-trac)</p>
-16:29 <+fox> <mk> yeah, it's all the same to me</p>
-16:30  * jrandom will assume thats it for * 3) January bug harvesting contest winners! and move us on to 4) ???</p>
-16:30 < jrandom> anyone have anything else for the meeting?</p>
-16:30 <+fox> <mk> 'best' is overrated. whoever has the most experience with these things should probably flip a coin</p>
-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)</p>
-16:32 < jrandom> tracking issues is the only feature i care about for that</p>
-16:37 < jrandom> ok, if there isn't anything else for the meeting...</p>
-16:37  * jrandom winds up</p>
-16:37  * void hands jrandom the baffer</p>
-16:37  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/199.rst b/i2p2www/meetings/199.rst
new file mode 100644
index 00000000..12e493c1
--- /dev/null
+++ b/i2p2www/meetings/199.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 6, 2007
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/2.log b/i2p2www/meetings/2.log
index 16c39de9..2634cc76 100644
--- a/i2p2www/meetings/2.log
+++ b/i2p2www/meetings/2.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 2{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 2</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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
@@ -490,7 +483,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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
@@ -1088,8 +1081,8 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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: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
@@ -1130,5 +1123,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 07:39  * mids kicks everybody out
 07:40 <@mids> MEETING IS OVER
 --- Log closed Wed May 29 07:40:24 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/2.rst b/i2p2www/meetings/2.rst
new file mode 100644
index 00000000..402f4dfd
--- /dev/null
+++ b/i2p2www/meetings/2.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 29, 2002 @ 00:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/20.log b/i2p2www/meetings/20.log
index 340a2a0e..4e1499fc 100644
--- a/i2p2www/meetings/20.log
+++ b/i2p2www/meetings/20.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 20{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 20</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Nov 19 23:51:34 2002
 23:52 < logger> test
 23:52 -!- mode/#iip-dev [+o mids] by Trent
@@ -409,5 +402,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 02:44 < dd0c> is this rc3 preview useable?
 02:44 < dd0c> heh dumb question
 --- Log closed Wed Nov 20 10:43:44 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/20.rst b/i2p2www/meetings/20.rst
new file mode 100644
index 00000000..2e6f14fb
--- /dev/null
+++ b/i2p2www/meetings/20.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 19, 2002 @ 23:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/200.log b/i2p2www/meetings/200.log
index 24767866..d93e59e7 100644
--- a/i2p2www/meetings/200.log
+++ b/i2p2www/meetings/200.log
@@ -1,79 +1,73 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 200{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 13, 2007</h3>
-<div class="irclog">
-15:04 < jrandom> 0) hi</p>
-15:04 < jrandom> 1) Net status and 0.6.1.27</p>
-15:04 < jrandom> 2) Syndie dev status</p>
-15:04 < jrandom> 3) trac.i2p.net</p>
-15:04 < jrandom> 4) ???</p>
-15:04 < jrandom> 0) hi</p>
-15:04  * jrandom waves</p>
-15:04 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001334.html </p>
-15:05 < jrandom> lets jump on in to 1) Net status and 0.6.1.27</p>
-15:06 < jrandom> zzz: wanna give us the rundown of the main bugfixes/improvements we'll find in i2psnark?</p>
-15:07 <+zzz> um, it's all over the map, see history.txt :)</p>
-15:07 < green> We can't say anything about that since you don't have work on it for a long time, humm !</p>
-15:08 < green> So there isn't new to discuss</p>
-15:08 < jrandom> heh ok zzz, fair 'nuff :)</p>
-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</p>
-15:08 <+zzz> BTW w00t mtg 200</p>
-15:09 < jrandom> zounds</p>
-15:09 < jrandom> ok word</p>
-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)</p>
-15:09 < jrandom> are there any other low hanging fruit i should address before tagging & pushing?</p>
-15:10 <+zzz> that sounds smarter than waiting for me to do it</p>
-15:10 < jrandom> oh, i should disable the old syndie too</p>
-15:11 < jrandom> (or at least its fetching)</p>
-15:11 < jrandom> i've heard some suggestions to disable theepsite tunnel by default as well - any thoughts?  yea nea?</p>
-15:11  * bar beats his not-yet-quite-dead "not have eepsite server tunnels autostart by default" horse</p>
-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</p>
-15:13 < jrandom> it might be worth keeping the content around for a while but killing the syndication</p>
-15:13 < jrandom> ok, if anyone comes up with omething else, lemmie know</p>
-15:14 <+zzz> if you do check to see if the note I added needs updating</p>
-15:14 < jadeSerpent> i agree it shouldn't start serving pages out of box, no other app does that, potential security risk</p>
-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</p>
-15:14 < jrandom> aye</p>
-15:14 <+zzz> and ditto if you disable eepsite tunnel the instructions & default eepsite homepage need to be updated</p>
-15:15 < jrandom> it won't disable already configured tunnels, it'll just affect new users</p>
-15:15 < jrandom> true zzz</p>
-15:15 <+zzz> prob. a good idea</p>
-15:17 < green> but this is just a minor tweak not a improvemnt</p>
-15:17 < jrandom> ok, anyone have anything else for 1) net status and 0.6.1.27?</p>
-15:17 <+zzz> resources/eepsite_index.html "your eepsite is up and running but..."</p>
-15:17 < jrandom> aye</p>
-15:19 < green> jr : Courage, let us flee!</p>
-15:19 < jrandom> ok jumping to 2) Syndie dev status</p>
-15:20 < jrandom> lots going on here, of course</p>
-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</p>
-15:21 <+fox> * thecrypto waves as he returns after a very very long hiatus from this project</p>
-15:21 < jrandom> anyone want to bring up anything for 2) Syndie dev status?</p>
-15:21 < jrandom> woah!</p>
-15:21 < jrandom> wb thecrypto</p>
-15:22 <+fox> <thecrypto> Thank you</p>
-15:22 < jrandom> still hacking on an i2p 0.1 sdk? :)</p>
-15:22 <+zzz> back for the 200th anniversary?</p>
-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 :)</p>
-15:24 < jrandom> heh cool</p>
-15:24 <+fox> * thecrypto takes a seat off to the side to let the rest of the meeting proceed</p>
-15:25 < jrandom> ok, if there's nothing else for 2) Syndie dev status, lets jump to 3) trac.i2p.net</p>
-15:25 < jrandom> by popular (and reasonable) demand, we've migrated from the in-syndie bugtracker to a real bugtracker</p>
-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)</p>
-15:26  * jadeSerpent claps</p>
-15:27 <+fox> <thecrypto> Trac works very well, use it at my day job. Have you integrated CVS into it?</p>
-15:27 < jrandom> monotone (our dvcs), yes</p>
-15:27 < jrandom> https://trac.i2p.net/browser</p>
-15:28 <+fox> <thecrypto> Neat, migrated to DVCS :) Good time for me to rejoin :)</p>
-15:28 < jrandom> mos' def'</p>
-15:29 < jrandom> at the moment, the wiki is basically disabled, but might get some use at times for working through some issues</p>
-15:29 < jrandom> i'm not sure if/when it'll get used though, but we'll see</p>
-15:30 < jrandom> ok, anyone have anything else for 3) trac.i2p.net ?</p>
-15:31 < jrandom> if not, lets jump to good ol' fashioned 4) ???</p>
-15:31 < jrandom> anyone have something else to bring up for the meeting?</p>
-15:33 <+fox> <thecrypto> Glad to be bck</p>
-15:33 < jadeSerpent> does it always get really laggy around meeting time?</p>
-15:35 < jrandom> jadeSerpent: more than usual, yeah, though not that bad (i'm @ 1.46s lag)</p>
-15:35  * jrandom winds up</p>
-15:35  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/200.rst b/i2p2www/meetings/200.rst
new file mode 100644
index 00000000..c6ea88c5
--- /dev/null
+++ b/i2p2www/meetings/200.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 13, 2007
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/201.log b/i2p2www/meetings/201.log
index cc1a4edb..9779d857 100644
--- a/i2p2www/meetings/201.log
+++ b/i2p2www/meetings/201.log
@@ -1,40 +1,34 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 201{% endblock %}
-{% block content %}<h3>I2P dev meeting, February 20, 2007</h3>
-<div class="irclog">
-14:59 < jrandom> 0) hi</p>
-14:59 < jrandom> 1) Net status</p>
-14:59 < jrandom> 2) Syndie dev status</p>
-15:00 <+void> jrandom: fyi, bookmark management is not working as of 8e18877de3908c52daae6d8a85fc8c671cdfb5d5</p>
-15:00 < jrandom> 3) ???</p>
-15:00 < jrandom> 0) hi</p>
-15:00  * jrandom waves</p>
-15:00 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-February/001336.html</p>
-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 :)</p>
-15:01 <+void> ah :)</p>
-15:01 < jrandom> if thats not what you're referring to, please file a bug report</p>
-15:01 <+void> (well, i already filed a bug report for that</p>
-15:01 <+void> )</p>
-15:02 < jrandom> w3wt</p>
-15:02 < jrandom> ok, lets jump into 1) Net status</p>
-15:02 < jrandom> i don't really have much to add beyond whats in the status notes</p>
-15:04 < jrandom> anyone have anything they'd like to add re: 1) Net status?</p>
-15:06 < jrandom> if not, lets shimmy on over to 2) Syndie dev status</p>
-15:06 < bar> jrandom: yeap, Traditional Chinese language support fixed the "china.i2p" issue and Simplified Chinese fixed your "peace" post</p>
-15:06 < jrandom> ah great bar</p>
-15:06 < bar> (oops, sry!)</p>
-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)</p>
-15:10 < jrandom>  (specifically, in the bug report @ urn:syndie:channel:d7:channel44:Ffn4RhCunO6gwMfAYfOoPY7FGwPNDy65dS4DyuyorME=9:messageIdi1171666081846ee )</p>
-15:10 < jrandom> anyway, regarding syndie dev status, lots going on there</p>
-15:10 < jrandom> i expect we'll have a new release out later this week with the latest goodies</p>
-15:12 < jrandom> as always, keep those bug reports and feature requests flowin, and we'll get 'em addressed as soon as possible</p>
-15:12 < jrandom> anyone have anything to add re: 2) Syndie dev status?</p>
-15:15 < jrandom> ok if not, lets slide to 3) ???</p>
-15:15 < jrandom> anyone have anything else to bring up for the meeting?</p>
-15:16 <+Complication> not anything I'd recall in a hurry :)</p>
-15:18 <+Complication> (not yet, at least)</p>
-15:18 < jrandom> heh in that case...</p>
-15:18  * jrandom winds up</p>
-15:18  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/201.rst b/i2p2www/meetings/201.rst
new file mode 100644
index 00000000..31f989c5
--- /dev/null
+++ b/i2p2www/meetings/201.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 20, 2007
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/202.log b/i2p2www/meetings/202.log
index 371ee6af..05517f10 100644
--- a/i2p2www/meetings/202.log
+++ b/i2p2www/meetings/202.log
@@ -1,87 +1,81 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 202{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 13, 2007</h3>
-<div class="irclog">
-16:01 < jrandom> 0) hi</p>
-16:01 < jrandom> 1) Net status and 0.6.1.28</p>
-16:01 < jrandom> 2) Syndie dev status and 1.005a</p>
-16:02 < jrandom> 3) Syndie GUI directions</p>
-16:02 < jrandom> 4) Feb bug harvesting contest results</p>
-16:02 < jrandom> 5) ???</p>
-16:02 < jrandom> 0) hi</p>
-16:02  * jrandom waves</p>
-16:02 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001338.html</p>
-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</p>
-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?</p>
-16:05 <+zzz> ok</p>
-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...</p>
-16:06 <+zzz> like i2psnark users...</p>
-16:06 <+zzz> I'm getting good results in testing so looking forward to getting it out there to all...</p>
-16:07 < jrandom> [w3wt]</p>
-16:07 <+zzz> I have one tweak to make a parameter configurable, as requested by Amiga4000, should get that in soon.</p>
-16:08 <+zzz> And thx for the $$ offer, however please keep it in the bank.</p>
-16:08 <+zzz> EOT :)</p>
-16:08 < jrandom> r0x0r - added to halloffame.html :)</p>
-16:09 <+zzz> haha I'm famous now</p>
-16:10 < jrandom> the changes look pretty promising, and they do seem that they'll have their largest impact once its widely deployed</p>
-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</p>
-16:11 < jrandom> ok, anyone have anything they'd like to bring up re: net status?</p>
-16:13 < jrandom> if not, lets hop on over to 2) syndie dev status</p>
-16:14 < jrandom> lots going on here (as you can see if you're using syndie or following https://trac.i2p.net/timeline )</p>
-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)</p>
-16:15 < TrevorReznik> jrandom: do you have time for a short query?</p>
-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 :)</p>
-16:17 < jrandom> (if its not something for the meeting, hit me as a priv msg)</p>
-16:17 < TrevorReznik> ok ;) ill wait</p>
-16:18 < jrandom> ok, anyone have anything for 2) syndie dev status?</p>
-16:20 < jrandom> if not, lets switch to 3) Syndie GUI directions</p>
-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</p>
-16:20 <+zzz> call me a traditionalist, but I think the current multipane thunderbird-like i/f is pretty good</p>
-16:24 < jrandom> hmm, with the multipane view, would that fit more with mk's mods than our current multitab interface though?</p>
-16:24 < jrandom> do you use the preview tab on the thread view now, for instance?</p>
-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</p>
-16:26 <+zzz> sorry not conversant in the details of mk's mods so can't answer your other question</p>
-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)</p>
-16:27 < jrandom> oh, there's a screencap of mk's proposal up at http://dev.i2p.net/~jrandom/mk_max.png</p>
-16:27 < jrandom> mk: perhaps we could find a way to make the tree above vs. left configurable?</p>
-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</p>
-16:30 < jrandom> i remember reviewing their diagram for that, yeah</p>
-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</p>
-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.</p>
-16:34 < jrandom> do you run syndie fullscreen or only in part of the screen</p>
-16:35 <+zzz> usually full</p>
-16:35 < jrandom> hmm cool</p>
-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</p>
-16:37 < jrandom> ok, for all y-all watching in the background, please post up your thoughts and ideas whenever its convient for you</p>
-16:37 < jrandom> heh aye, makes sense</p>
-16:38  * jrandom is on an 800x600 net cafe box atm</p>
-16:38 <@detonate> hmm, i'm having trouble getting i2p working again</p>
-16:39 <@detonate> it's doing something, using lots of cpu, but the web console doesn't seem to ever start</p>
-16:39 <@detonate> i guess i could try running it in windows</p>
-16:39 < jrandom> anything in the logs?</p>
-16:39 <@detonate> not really, it just says that i need to reseed</p>
-16:39 <@detonate> are the logs quieter than before?</p>
-16:39 <+zzz> wrapper.log NPE's?</p>
-16:41 < jrandom> ok, if there isn't anything else for 3, lets jump on to 4) Feb bug harvesting contest results</p>
-16:42 < jrandom> congrats & thanks to void, Darn, and Anonymous!  </p>
-16:42 < jrandom> (and to everyone else who has helped out, of course)</p>
-16:42 < jrandom> bug reports help us track down these issues and make sure they get taken care of, so please keep 'em coming</p>
-16:43 < jrandom> ok, if there isn't anything on 4), lets jump to 5) ???</p>
-16:43 < jrandom> anyone have anything they want to bring up for the meeting?</p>
-16:45 < bar> there was someone asking in the forums why the graphs displaying bw seem a bit off</p>
-16:45 < bar> thought you might have an idea or two</p>
-16:46 < bar> (basically, they peak at 1.5 x max bw setting)</p>
-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)</p>
-16:47 <@detonate> nm, it's working again :)</p>
-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</p>
-16:49  * jrandom loads</p>
-16:51 < jrandom> hmm, and that includes the upstream avg w/ burst in mind?</p>
-16:52 <+zzz> yes</p>
-16:52 < jrandom> hmm, ill look into it</p>
-16:53 <+zzz> I'll investigate further, guess it doesn't ring a bell for you</p>
-16:53 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:57 < jrandom> if not...</p>
-16:57  * jrandom winds up</p>
-16:58  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/202.rst b/i2p2www/meetings/202.rst
new file mode 100644
index 00000000..76c7f1aa
--- /dev/null
+++ b/i2p2www/meetings/202.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 13, 2007
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/203.log b/i2p2www/meetings/203.log
index 75c07a7d..39ead4a4 100644
--- a/i2p2www/meetings/203.log
+++ b/i2p2www/meetings/203.log
@@ -1,111 +1,105 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 203{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 20, 2007</h3>
-<div class="irclog">
-16:05 < jrandom> 0) hi</p>
-16:05 < jrandom> 1) Net status and 0.6.1.28</p>
-16:05 < jrandom> 2) Syndie dev status</p>
-16:05 < jrandom> 3) ???</p>
-16:05 < jrandom> 0) hi</p>
-16:05  * jrandom waves</p>
-16:05 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001341.html</p>
-16:05  * jrandom only recently posted that, so i'll give y'all a minute to read that exiting note ;)</p>
-16:08 < jrandom> ok, lets jump on into 1) net status and 0.6.1.28</p>
-16:09 < jrandom> things are looking pretty good so far with about half of the net upgraded</p>
-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</p>
-16:10 < jrandom> we'll see how that progresses over the next week or so though</p>
-16:11 < jrandom> ok, anyone have anything to bring up re: net status or 0.6.1.28?</p>
-16:13 < jrandom> ok, if not, lets swing on over to 2) syndie dev status</p>
-16:13 < jrandom> lots going on in that front, as mentioned in the notes</p>
-16:13 < Amiga4000> hi</p>
-16:13 < jrandom> heya Amiga4000 </p>
-16:13 < Amiga4000> which point now?</p>
-16:13 < jrandom> we just hopped over to 2, but if you have something to bring up for 1, hit me ;?</p>
-16:14 < Amiga4000> yeah, posted in syndie right now, I assume my pool isn't working as aspected</p>
-16:14 < jrandom> pool?</p>
-16:14 < Amiga4000> 2 pout tunnels 2 hops, one 70sec and 1300kb, one 250sec and 1000 kb</p>
-16:15 < Amiga4000> ( I refer to the msg in zzz forum on syndie about I2Psnark and pooling inside router)</p>
-16:15 < jrandom> i assume those times are expiration times, right, and data is total transferred so far</p>
-16:15 < Amiga4000> damned, right</p>
-16:15 < jrandom> ok, i replied to that post in syndie - what you see is good</p>
-16:15 < Amiga4000> *fine*</p>
-16:16 < Amiga4000> sry, wqas to fast in read and not understanding</p>
-16:16 < jrandom> if all tunnels expired at the same time, there'd be a rush and a good chance of total failures</p>
-16:16 < Amiga4000> correct, any chance to see the lifteime of a tunnel?</p>
-16:16 < jrandom> 1300KB and 1000KB is pretty good balancing too</p>
-16:16 < jrandom> lifetime is always 10 minutes</p>
-16:17 < Amiga4000> ok, I track some more data :_)</p>
-16:18 < jrandom> w3wt, thanks for asking about it though, its a good question</p>
-16:18 < Amiga4000> ok, and net status: 0.1.28 is fine, although upload of i2psnakr data is slow</p>
-16:19 < jrandom> hmm, you were describing 10-15KBps though, right?</p>
-16:19 < Amiga4000> right, it was 30-40 before the last 2 or 3 changes by zzz</p>
-16:20 < jrandom> hmm, lets see how it progresses as the new-release churn reduces</p>
-16:20 < Amiga4000> yes, lets wait 1-2 weeks more :-)</p>
-16:20 < jrandom> though in my view, 10-15KBps is good enough</p>
-16:21 < Amiga4000> :-)</p>
-16:21 < jrandom> (i was actually using the 10-20 range as my target for reasonable usage, rather than 1-5KBps)</p>
-16:21 < jrandom> of course, more is better, but a solid 10-15 is great news</p>
-16:21 < Amiga4000> I just know it has done the 2-4x of that</p>
-16:21 < _bob> Hmm, i2p is using 120% CPU. ;)</p>
-16:22 < Amiga4000> and I still can grab data from "internet" via the outproxy< in 20-40 kb rate</p>
-16:22 < jadeSerpent> _bob: hope your heatsink/fan is working</p>
-16:22 < jrandom> you're referring to kilobytes per second, right Amiga4000?</p>
-16:22 < Amiga4000> right</p>
-16:23 < jrandom> cool</p>
-16:23 < Amiga4000> and even syndie.i2p is in the 40 range</p>
-16:23 < jrandom> bob: or you've got a dual or quad proc pc ;)</p>
-16:24 < _bob> Didn't know top reported values over 100%.</p>
-16:24 < jrandom> i2p is just magic</p>
-16:24 < jadeSerpent> i guess it's over the top</p>
-16:25 < _bob> Wish I did. Can only route around 150KB/s in each direction as it is now.</p>
-16:25  * jadeSerpent dodges rotten fruit</p>
-16:27 < jadeSerpent> i have a core 2 duo and i sometimes see various processes using >100%</p>
-16:29 < jrandom> ok, anyone have anything else for 1? </p>
-16:30 < jrandom> if not, really moving on to 2 ;)</p>
-16:30 < jrandom> not much more to add to that here beyond whats in the mail and the forum</p>
-16:30 < jrandom> anyone have anything they want to bring up re: 2) syndie dev status?</p>
-16:30 < jadeSerpent> i can't wait to try the new editor widget</p>
-16:30 < jadeSerpent> the current one is driving me nuts</p>
-16:30 < jrandom> heh</p>
-16:31 < jadeSerpent> how were you able to pull in native editors on the various platforms?</p>
-16:31 < Eric> Just a quick question...why does Susimail take so long to check mail or load? Other .i2p pages load quickly.</p>
-16:32 < jadeSerpent> Eric: pop3 is a very verbose protocol, moreseo than http (more packets exchanged per operation)</p>
-16:32 < Eric> Ah, alright.</p>
-16:33 < jrandom> jadeSerpent: import org.eclipse.swt.widget.Text instead of ...swt.custom.StyledText ;)</p>
-16:33 < _bob> Eric = Protocol?</p>
-16:33 < jrandom> Eric: aye, the app runs locally but talks a full pop3 subset to the pop3 server</p>
-16:34 < jadeSerpent> jrandom: ah so swt does interface to com frameworks</p>
-16:34 < Eric> Why not use webmail over HTTP as opposed to a local client fetching and sending via POP/SMTP?</p>
-16:34 < jadeSerpent> nm i'll just read the code</p>
-16:35 < jrandom> jadeSerpent: well, its a native /text/ widget, not the com html editor widget</p>
-16:35 < jadeSerpent> Eric: ask postman that question, and preferably in #i2p-chat ;)</p>
-16:35 < Eric> Okay.</p>
-16:35 < jadeSerpent> jrandom: oh</p>
-16:35  * jadeSerpent was thinking gedit/console/riched32</p>
-16:36 < jadeSerpent> s/console/kate/</p>
-16:36 < jrandom> jadeSerpent: the com html editor widget is easy enough to integrate too, but itd require a lot of issues</p>
-16:36 < jadeSerpent> yeah best do your own parsing for security</p>
-16:36 < jrandom> (eg auditing it for security, especially when quoting content)</p>
-16:39 < jrandom> ok, if there's nothing else on 2), lets jump to 3) ???</p>
-16:39 < jrandom> anyone have anything they want to bring up for the meeting?</p>
-16:40 < jadeSerpent> how's the situation with registerfly</p>
-16:40 < jadeSerpent> is i2p.net saved? ;)</p>
-16:41 < jrandom> eh not yet sorted, hope to get it dealt with soon</p>
-16:41 < jrandom> but y'all have 66.111.51.110 memorized anyway, right?  ;)</p>
-16:41 < _bob> i2p.net will soon serve you ads and ads. ;)</p>
-16:42 < jadeSerpent> yes, it's the same number i use for the combination on my briefcase</p>
-16:42 < jadeSerpent> _bob: that's one of my fears :(</p>
-16:43 < jadeSerpent> or redirect to SiteFinder</p>
-16:43 < jadeSerpent> what a mess registerfly created heh</p>
-16:43 < jrandom> it'll get sorted in the next day or two</p>
-16:44 < Eric> Heh, now I remember where I've seen that IP. It's the outproxy IP address.</p>
-16:44 < snoopy> jr: check this page, re i2p.net: http://www.dyndns.com/news/releases/registerfly_safe_harbor.html</p>
-16:44 < jrandom> aye eric :)</p>
-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)</p>
-16:46  * jrandom just needs to get onto a secure term (tried to earlier today, but the place was closed)</p>
-16:47 < jrandom> ok, anyone have anything else to bring up for the meeting?</p>
-16:49 < jrandom> if not...</p>
-16:49  * jrandom winds up</p>
-16:50  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/203.rst b/i2p2www/meetings/203.rst
new file mode 100644
index 00000000..8df851f9
--- /dev/null
+++ b/i2p2www/meetings/203.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 20, 2007
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/204.log b/i2p2www/meetings/204.log
index d2051733..e0ea9a8c 100644
--- a/i2p2www/meetings/204.log
+++ b/i2p2www/meetings/204.log
@@ -1,81 +1,75 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 204{% endblock %}
-{% block content %}<h3>I2P dev meeting, March 27, 2007</h3>
-<div class="irclog">
-16:02 < jrandom> 0) hi</p>
-16:02 < jrandom> 1) Net status</p>
-16:02 < jrandom> 2) zzz's NTCP/SSU proposals</p>
-16:03 < jrandom> 3) Syndie dev status</p>
-16:03 < jrandom> 4) DNS/registrar status</p>
-16:03 < jrandom> 5) ???</p>
-16:03 < jrandom> 0) hi</p>
-16:03  * jrandom waves</p>
-16:03 < jrandom> weekly status notes posted up at http://dev.i2p.net/pipermail/i2p/2007-March/001342.html</p>
-16:04 < jrandom> jumping into 1) net status</p>
-16:04 < jrandom> things seem pretty good, and as mentioned there's more research to do regarding the latest changes</p>
-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</p>
-16:05 < cervantes>  /mute Complication</p>
-16:05 < jrandom> heh</p>
-16:05 <+Complication> :D</p>
-16:06 <+Complication> Tunnel build success is very nice, though</p>
-16:06  * Complication checks again, just in case</p>
-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 ;)</p>
-16:06 < cervantes> there have been various ISP cockups recently on the irc front - postman is looking into alternative hosting arrangements</p>
-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</p>
-16:06 < cervantes> hopefully we can get some better network redundancy</p>
-16:06 < jrandom> ah ok cervantes </p>
-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</p>
-16:08 < jrandom> ok, anyone have anything else to bring up re: net status?</p>
-16:10 < jrandom> if not, hopping over to 2) zzz's NTCP/SSU proposals</p>
-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)</p>
-16:11 < jrandom> in any case, post up your thoughts in zzz's blog (or read there for more info)</p>
-16:11 < jrandom> anyone have anything to discuss regarding that here now though?</p>
-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)</p>
-16:12 < jrandom> aye</p>
-16:12 <+Complication> I thougt, however, about one approach...</p>
-16:12 <+Complication> Currently the bids are fully deterministic (as opposed to probabilistic with a random component) right?</p>
-16:13 < jrandom> aye, fully deterministic</p>
-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</p>
-16:14 <+Complication> As in "60% chance of getting NTCP, 40% chance of getting SSU"</p>
-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)</p>
-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</p>
-16:15 <+Complication> (assuming of course that both transports are usable for a given link - sometimes they certainly aren't)</p>
-16:15 < jrandom> randomizing it would't help with that, though would offer more room to get data on both transports in the wild</p>
-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)</p>
-16:19 < jrandom> 'tis a method we could use to gather more data, worth keeping in mind</p>
-16:19 < jrandom> ok, as mentioned, post on up to that thread for more stuff :)</p>
-16:20 < jrandom> jumping on over to 3) Syndie dev status</p>
-16:20 < jrandom> i dont have much to add beyond whats in the mail</p>
-16:20 < jrandom> anyone have any questions/comments/concerns?</p>
-16:21 <+Complication> Not yet. :)</p>
-16:22 < jrandom> hehe</p>
-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</p>
-16:22 < jrandom> w3rd, looking forward to both :)</p>
-16:24 < jrandom> ok lets skip past 4 and jump to 5) ???</p>
-16:25 < jrandom> anyone have anything else they want to bring up for the meeting?</p>
-16:26 < TrevorReznik> is there any interest in a hashcash generator for i2p?</p>
-16:26 < TrevorReznik> as in through the browserinterface.</p>
-16:26 < TrevorReznik> i thought about that as kind of way to eliminate possible DoS scenarios inside i2p.</p>
-16:27 < jrandom> hmm, in javascript or c/java?</p>
-16:27 < jrandom> i think there are a few hashcash generators out there</p>
-16:27 < TrevorReznik> in java.</p>
-16:28 <+Complication> well, some research into hashcash schemes is likely to be needed at some point</p>
-16:28 < TrevorReznik> www.hashcash.org has some i think.</p>
-16:28 < TrevorReznik> they are an initiative to establish it for email clients as antispam thing.</p>
-16:28 <+Complication> perhaps not research in a proper sense, but in an implementation and best practise sese</p>
-16:28 <+Complication> =sense</p>
-16:28 < TrevorReznik> they have a collection of implementations in a multitude of languages.</p>
-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.</p>
-16:30 <+Complication> places which could use it: 1) nym registration in Syndie 2) name registration in I2P</p>
-16:30 <+Complication> 3) email, obviously</p>
-16:30  * TrevorReznik agrees.</p>
-16:30 <+Complication> 4) in less optimistic scenarios, ordinary messages in Syndie</p>
-16:31 <+Complication> on the I2P network level itself...</p>
-16:31 <+Complication> hmm</p>
-16:31 < jrandom> its possible to embed them into tunnel creation mesages, but we're already hosed on that cpu front as it is ;)</p>
-16:39 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:41 < jrandom> if not</p>
-16:41  * jrandom winds up</p>
-16:41  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/204.rst b/i2p2www/meetings/204.rst
new file mode 100644
index 00000000..2777a6e3
--- /dev/null
+++ b/i2p2www/meetings/204.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 27, 2007
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/205.log b/i2p2www/meetings/205.log
index 365b59c4..0cf0603a 100644
--- a/i2p2www/meetings/205.log
+++ b/i2p2www/meetings/205.log
@@ -1,88 +1,82 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 205{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 3, 2007</h3>
-<div class="irclog">
-16:01 < jrandom> 0) hi</p>
-16:01 < jrandom> 1) net status</p>
-16:01 < jrandom> 2) syndie dev status</p>
-16:01 < jrandom> 3) ???</p>
-16:01 < jrandom> 0) hi</p>
-16:01  * jrandom waves</p>
-16:01 < jrandom> weekly status notes are not up yet, but there wasn't much in 'em so we can cover it inline here</p>
-16:01 < jrandom> jumping into 1) net status</p>
-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!)</p>
-16:01 < jrandom> there's been some more discussion on zzz's blog regarding the ssu/ntcp ideas - check that out for more info</p>
-16:01 < jrandom> i don't have much to add on that... anyone have anything to bring up on 1) net status?</p>
-16:04 < jrandom> if not, lets move on to 2) syndie dev status</p>
-16:04 < jrandom> some good progress on the desktop gui lately, with a few components propagated back into the tabbed gui as well</p>
-16:04 < jrandom> we've still got some work to do, but i use the desktop gui for most everything atm. </p>
-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</p>
-16:04 <+Complication> indeed, I can also confirm higher IRC sessions persistence</p>
-16:04 < jrandom> w3wt</p>
-16:06 <+Complication> Seems like testing it again might be scheduled then (during my last test, I found it a bit... intimidating)</p>
-16:07 < jrandom> ah yeah, i added labels to most of the buttons now ;)</p>
-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)</p>
-16:07 <+Complication> (especially the lack of labels on the many components)</p>
-16:08 < jrandom> but its still not ready for alpha... i can use it because i know what everything does/is suposed to do</p>
-16:08 <+Complication> over here it's Linux, but good to know, I guess</p>
-16:08 < jrandom> but hopefully in the next week or so</p>
-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?</p>
-16:09 <+Complication> s/is being/be</p>
-16:09 < jrandom> it'll try 5 concurrent fetches per archive</p>
-16:10 < jrandom> (and one async import thread)</p>
-16:10 <+Complication> Over here, its failure rate against most archives has seen a dramatic rise from earlier times</p>
-16:10 < jrandom> hmm</p>
-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</p>
-16:10 <+Complication> "hitting a spare moment" and getting a quality sync done, seems to generally not happen, though</p>
-16:10 < jrandom> so various fetches fail saying "connection reset" or other tcp-like error message?</p>
-16:11 <+Complication> "socket closed" and whatnot</p>
-16:11 < jrandom> ah ok</p>
-16:11 <+Complication> I haven't really counted them</p>
-16:11 <+Complication> This is of course entirely via I2P</p>
-16:11 < jrandom> the servers arent currently that hefty (i think they have very limited handling capacity), and that should get imporved</p>
-16:12 < jrandom> also, as you and $nymFormerlyKnownAsAnonymous said, we should retry those kinds of failures</p>
-16:12 <+Complication> right, that might help too</p>
-16:12 < tapeworm> What are the servers based on?</p>
-16:12 < jrandom> but we definitely need that to be rock solid and transparent, of course</p>
-16:13 < jrandom> tapeworm: homebrew</p>
-16:13 <+Complication> though when I mesured "eepget" performance a while back, comparatively to Syndie, eepget got great performance and reliability</p>
-16:13 < jrandom> (about a dozen lines of code)</p>
-16:13 <+Complication> it pulled 2 x 9 MB from dev.i2p.net while archive.syndie.i2p kept failing on tiny little messages</p>
-16:13 < jrandom> oh, thats not really a fair test though</p>
-16:14 <+Complication> different boxes?</p>
-16:14 < jrandom> and syndie actually /uses/ eepget to fetch</p>
-16:14 < jrandom> fetching from apache is pretty different from fetching lots of small files from a homebrew webserver ;)</p>
-16:14 <+Complication> hmm... I should probably log overzealously while syncing then</p>
-16:15 <+Complication> indeed, and the difference between servers too</p>
-16:17 <+Complication> heh, it seems I managed to initiate a sync in the desktop UI</p>
-16:17 <+Complication> a task which proved too hard last time :)</p>
-16:17 < jrandom> w3wt :)</p>
-16:18 < jrandom> ok, anyone have anything else for 2?  if not, lets jump on over to 3) ???</p>
-16:18 <+Complication> I do have the habits of a heavy taskbar user, though, so it will likely take some getting used to</p>
-16:18 <+Complication> (I usually have the taskbar on auto-hide)</p>
-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 </p>
-16:19 <+Complication> is the desktop gui, in principle, capable of having a "minimize" button?</p>
-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</p>
-16:20 < jrandom> oh, yes, definitely possible - good idea</p>
-16:20 <+Complication> which would send it to background without affecting the order in which other windows below it are arranged?</p>
-16:20 < jrandom> we can toss that into the control menu (top left) or the task menu (top right)</p>
-16:20 <+Complication> Because using alt+tab tends to change that</p>
-16:21 <+Complication> (something... like the "show desktop" button I typically like to have on the taskbar near the KDE / Start button)</p>
-16:21 <+Complication> (another location may prove better, but something of this effect)</p>
-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)</p>
-16:22 <+Complication> Even if admittedly, minimize and show desktop are different things - now that I consider more, minimize seems a bit more logical.</p>
-16:24 <+Complication> As for syncing errors, I currently have 1 instance of HTTP 504, and 4 instances of "socket closed"</p>
-16:24 <+Complication> 2 successes</p>
-16:24  * TrevorReznik encounters like 70% socket closed</p>
-16:24 < jrandom> zounds</p>
-16:24 < jrandom> ok, ill look into that and get an update in there asap</p>
-16:27 < jrandom> ok, in 3) ??? - anyone have anything else for the meeting?</p>
-16:27 <+Complication> I wish I had, but not yet - webcache app still incomplete, since real life ran me over a little</p>
-16:28 < jrandom> damn that reality!</p>
-16:28  * Complication will try to get the 15 annoying things sorted out of the way</p>
-16:32 < jrandom> wr0d</p>
-16:32 < jrandom> ok, if there isn't anything else for the meeting...</p>
-16:32  * jrandom winds up</p>
-16:33  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/205.rst b/i2p2www/meetings/205.rst
new file mode 100644
index 00000000..09bb609c
--- /dev/null
+++ b/i2p2www/meetings/205.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 3, 2007
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/206.log b/i2p2www/meetings/206.log
index 9352186e..ecd81433 100644
--- a/i2p2www/meetings/206.log
+++ b/i2p2www/meetings/206.log
@@ -1,45 +1,39 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 206{% endblock %}
-{% block content %}<h3>I2P dev meeting, April 10, 2007</h3>
-<div class="irclog">
-16:01 < jrandom> 0) hi</p>
-16:01 < jrandom> 1) Net status</p>
-16:01 < jrandom> 2) Syndie dev status</p>
-16:01 < jrandom> 3) ???</p>
-16:01 < jrandom> 0) hi</p>
-16:01  * jrandom waves</p>
-16:01 < jrandom> the brief weekly status notes are posted up at http://dev.i2p.net/pipermail/i2p/2007-April/001343.html</p>
-16:01  * mrflibble waves back</p>
-16:03 < jrandom> as those notes are short enough, lets jump on in to 1) Net status</p>
-16:03 < jrandom> things seem to be going along fairly well lately</p>
-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</p>
-16:03 < jadeSerpent> irc seems to have calmed down finally too</p>
-16:03 < jrandom> cool</p>
-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</p>
-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</p>
-16:07 < jrandom> it won't be the desktop gui, but will include a number of improvements</p>
-16:08 < Complication> anything which helps syndication reliability would be wonderful</p>
-16:08 < Complication> it's been comparatively poor lately</p>
-16:08 < jrandom> aye, that trouble should be easy enough to sort out (to an extent)</p>
-16:09 < jadeSerpent> you know what's causing the failed fetches via i2p?</p>
-16:09 < jrandom> aye, low timeouts</p>
-16:10 < jrandom> (and low handler threads on the servers)</p>
-16:13 < jrandom> ok, if there isn't anything else on 2) Syndie dev status, lets jump over to 3) ???</p>
-16:13 < jrandom> anyone have anything else to bring up for the meeting?</p>
-16:14  * mrflibble waves</p>
-16:14 < mrflibble> sorry, going back  to  point 1 again</p>
-16:15 < mrflibble> <jadeSerpent> irc seems to have calmed down finally too - is this for any particular reason do you think?</p>
-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)</p>
-16:17 < jrandom> the #s for tunnel creation success rates look much better</p>
-16:17 < mrflibble> oh ok, was the servers themselves</p>
-16:17 < mrflibble> what were zzz's imporvements?</p>
-16:19 < Complication> message priorities, to allow tunnel build messages to take priority over tunnel traffic</p>
-16:19 < Complication> and streaming lib adjustments, and the usual array of I2PSnark fixes</p>
-16:19 < mrflibble> ah,  thanks</p>
-16:19 < jrandom> (what Complication said :)</p>
-16:22 < jrandom> ok, anyone have anything else for the meeting?</p>
-16:26 < jrandom> if not</p>
-16:26  * jrandom winds up</p>
-16:26  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/206.rst b/i2p2www/meetings/206.rst
new file mode 100644
index 00000000..f57e96b5
--- /dev/null
+++ b/i2p2www/meetings/206.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, April 10, 2007
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/207.log b/i2p2www/meetings/207.log
index 66fb4015..2150edca 100644
--- a/i2p2www/meetings/207.log
+++ b/i2p2www/meetings/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/207.rst b/i2p2www/meetings/207.rst
new file mode 100644
index 00000000..b345c1fc
--- /dev/null
+++ b/i2p2www/meetings/207.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 10, 2009
+==================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/21.log b/i2p2www/meetings/21.log
index b1df2265..1940021a 100644
--- a/i2p2www/meetings/21.log
+++ b/i2p2www/meetings/21.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 21{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 21</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -463,7 +456,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> "<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
@@ -488,7 +481,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 < 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
@@ -687,5 +680,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/21.rst b/i2p2www/meetings/21.rst
new file mode 100644
index 00000000..b0dd3ba3
--- /dev/null
+++ b/i2p2www/meetings/21.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 26, 2002 @ 23:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/22.log b/i2p2www/meetings/22.log
index 0e110f52..a98a5bac 100644
--- a/i2p2www/meetings/22.log
+++ b/i2p2www/meetings/22.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 22{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 22</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -149,5 +142,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/22.rst b/i2p2www/meetings/22.rst
new file mode 100644
index 00000000..a415c7dd
--- /dev/null
+++ b/i2p2www/meetings/22.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 3, 2002 @ 23:01 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/23.log b/i2p2www/meetings/23.log
index 664d7949..f73b58cd 100644
--- a/i2p2www/meetings/23.log
+++ b/i2p2www/meetings/23.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 23{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 23</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -27,7 +20,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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: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
@@ -215,7 +208,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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}> <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
@@ -336,5 +329,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/23.rst b/i2p2www/meetings/23.rst
new file mode 100644
index 00000000..cf9b2aa7
--- /dev/null
+++ b/i2p2www/meetings/23.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 10, 2002 @ 23:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/25.log b/i2p2www/meetings/25.log
index bac28733..02ca2388 100644
--- a/i2p2www/meetings/25.log
+++ b/i2p2www/meetings/25.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 25{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 25</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Topic for #iip-dev is IIP Meeting - logfiles:
 http://mids.student.utwente.nl/~mids/iip/
 <nemesis> nop, no meeting today?
@@ -146,5 +139,3 @@ stuff 2
 00:32 < mids> :)
 00:32 < nemesis> looool
 --- Log closed Wed Jan 08 00:33:43 2003
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/25.rst b/i2p2www/meetings/25.rst
new file mode 100644
index 00000000..a7a97b81
--- /dev/null
+++ b/i2p2www/meetings/25.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 7, 2003
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/26.log b/i2p2www/meetings/26.log
index 9cdf7963..9c051e54 100644
--- a/i2p2www/meetings/26.log
+++ b/i2p2www/meetings/26.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 26{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 26</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -84,7 +77,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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: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
@@ -137,14 +130,14 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> < 	// 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 < 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.
@@ -265,5 +258,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/26.rst b/i2p2www/meetings/26.rst
new file mode 100644
index 00000000..01d297a3
--- /dev/null
+++ b/i2p2www/meetings/26.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 15, 2003 @ 23:00 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/28.log b/i2p2www/meetings/28.log
index 6086192d..72c1cc2b 100644
--- a/i2p2www/meetings/28.log
+++ b/i2p2www/meetings/28.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 28{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 28</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -145,5 +138,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 00:26 < Bouris> Hooray!
 00:27 <+logger> cya next week
 --- Log closed Wed Jan 29 00:27:06 2003
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/28.rst b/i2p2www/meetings/28.rst
new file mode 100644
index 00000000..7a27bacf
--- /dev/null
+++ b/i2p2www/meetings/28.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 28, 2003 @ 23:00 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/29.log b/i2p2www/meetings/29.log
index 990a9f72..af0ad648 100644
--- a/i2p2www/meetings/29.log
+++ b/i2p2www/meetings/29.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 29{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 29</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -63,7 +56,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> 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.
@@ -201,5 +194,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 00:48 < FillaMent> Oooo.... this is going to ROCK!
 00:48 <@mids> ?
 --- Log closed Wed Feb 05 00:48:36 2003
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/29.rst b/i2p2www/meetings/29.rst
new file mode 100644
index 00000000..98040620
--- /dev/null
+++ b/i2p2www/meetings/29.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 4, 2003 @ 23:00 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/3.log b/i2p2www/meetings/3.log
index 9b0e8f8d..9787cd4f 100644
--- a/i2p2www/meetings/3.log
+++ b/i2p2www/meetings/3.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 3{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 3</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Wed Jun 05 00:38:00 2002
 00:38 <+logger> logging started
 00:38 <@codeshark> already?
@@ -227,7 +220,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> 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
@@ -582,7 +575,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> nop: anything left for discussion>
 02:31 <@codeshark> ?
 02:32 <@nop> not really
 02:32 <@nop> no
@@ -614,5 +607,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 02:35 <+logger> abusive
 02:35 <+logger> logging ended
 --- Log closed Wed Jun 05 02:35:32 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/3.rst b/i2p2www/meetings/3.rst
new file mode 100644
index 00000000..15293c30
--- /dev/null
+++ b/i2p2www/meetings/3.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, June 4, 2002 @ 23:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/30.log b/i2p2www/meetings/30.log
index 4f4c0784..d8ec71d6 100644
--- a/i2p2www/meetings/30.log
+++ b/i2p2www/meetings/30.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 30{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 30</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -178,7 +171,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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
@@ -324,11 +317,11 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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> > INSTALLEXEPATH=$(INSTALLEXEPATH)/bin
 00:55 <@hezekiah> .
 00:55 < _42> ok
 00:56 <@hezekiah> 1.2 is development. :)
@@ -380,7 +373,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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.
@@ -390,7 +383,7 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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.
@@ -453,5 +446,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/30.rst b/i2p2www/meetings/30.rst
new file mode 100644
index 00000000..54be00a7
--- /dev/null
+++ b/i2p2www/meetings/30.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 11, 2003 @ 23:00 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/31.log b/i2p2www/meetings/31.log
index 1161ff5d..05ee9521 100644
--- a/i2p2www/meetings/31.log
+++ b/i2p2www/meetings/31.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 31{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 31</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -381,13 +374,13 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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: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 < 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 :)
@@ -404,12 +397,12 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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 <@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> 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
@@ -442,5 +435,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 01:38 <@mids> cya next week
 01:40 < lonelynerd> bye
 --- Log closed Wed Feb 19 01:40:48 2003
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/31.rst b/i2p2www/meetings/31.rst
new file mode 100644
index 00000000..9c97c99c
--- /dev/null
+++ b/i2p2www/meetings/31.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 18, 2003 @ 23:01 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/32.log b/i2p2www/meetings/32.log
index f4d4d013..4621af6f 100644
--- a/i2p2www/meetings/32.log
+++ b/i2p2www/meetings/32.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 32{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 32</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -258,9 +251,9 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> <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.
@@ -303,5 +296,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/32.rst b/i2p2www/meetings/32.rst
new file mode 100644
index 00000000..7d66c4ea
--- /dev/null
+++ b/i2p2www/meetings/32.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 4, 2003 @ 23:00 UTC
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/33.log b/i2p2www/meetings/33.log
index 307ce1d0..b9c7e1ac 100644
--- a/i2p2www/meetings/33.log
+++ b/i2p2www/meetings/33.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 33{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 33</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -422,5 +415,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 01:23 < hezekiah> Dead.
 01:23 < hezekiah> The meeting is dead. Long live the next meeting.
 01:23 < mihi> ;-) logger is still living
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/33.rst b/i2p2www/meetings/33.rst
new file mode 100644
index 00000000..d71d73f7
--- /dev/null
+++ b/i2p2www/meetings/33.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 12, 2003
+===============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/34.log b/i2p2www/meetings/34.log
index 5810219c..505df318 100644
--- a/i2p2www/meetings/34.log
+++ b/i2p2www/meetings/34.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 34{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 34</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -132,5 +125,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 22:38 <@hezekiah> Bye, all! :)
 22:38 < nop> bye
 --- Log closed Tue Mar 18 22:43:48 2003
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/34.rst b/i2p2www/meetings/34.rst
new file mode 100644
index 00000000..7a93bd04
--- /dev/null
+++ b/i2p2www/meetings/34.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 18, 2003 @ 21:00 UTC
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/35.log b/i2p2www/meetings/35.log
index 9a4b50ef..163aaee1 100644
--- a/i2p2www/meetings/35.log
+++ b/i2p2www/meetings/35.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 35{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 35</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- 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]
@@ -204,5 +197,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/35.rst b/i2p2www/meetings/35.rst
new file mode 100644
index 00000000..6ddad09b
--- /dev/null
+++ b/i2p2www/meetings/35.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 25, 2003 @ 21:00 UTC
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/4.log b/i2p2www/meetings/4.log
index ea20e22c..5ccd4201 100644
--- a/i2p2www/meetings/4.log
+++ b/i2p2www/meetings/4.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 4{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 4</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Jun 11 22:52:16 2002
 22:55 < logger> logging started
 22:55 <@mids> already?
@@ -308,8 +301,8 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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> <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
@@ -424,5 +417,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 02:46 <+BluePaperBoy> bye
 03:08 < logger> logging ended
 --- Log closed Wed Jun 12 03:08:35 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/4.rst b/i2p2www/meetings/4.rst
new file mode 100644
index 00000000..84056819
--- /dev/null
+++ b/i2p2www/meetings/4.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, June 11, 2002 @ 23:00 UTC
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/47.log b/i2p2www/meetings/47.log
index 464a87a2..faababaa 100644
--- a/i2p2www/meetings/47.log
+++ b/i2p2www/meetings/47.log
@@ -1,912 +1,907 @@
-{% extends "_layout.html" %}
-{% block title %}Meeting 47{% endblock %}
-{% block content %}<div class="irclog">
--->	You are now talking on #iip-dev</p>
----	Topic for #iip-dev is IIP Meeting - logfiles:</p>
-	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/</p>
-<al-jebr>	it's 21:13</p>
-<--	wilde has quit (Ping timeout)</p>
----	Trent@anon.iip gives channel operator status to UserX</p>
-<nop>	ok</p>
-<qriff> !time</p>
-<Ambience>	al-jebr: 00:21 here</p>
-<nop>	I believe everyone has settled</p>
-<hezekiah>	Let's go. :)</p>
-<jrand0m>	11:06 here</p>
-<nop>	let's start</p>
-<nop>	anyone get my agenda</p>
-<nop>	so they can play it back</p>
-<nop>	I forgot the order</p>
-<--	leenookx has quit (Ping timeout)</p>
-<Ambience>	my clock is 15 minutes ahead :)</p>
--->	hifi (~MetroPipe@anon.iip) has joined #iip-dev</p>
-<hezekiah>	<nop> on the agenda</p>
-<hezekiah>	<nop> 1) Welcome</p>
-<hezekiah>	<nop> 2)Our Goodbyes</p>
-<hezekiah>	<nop> 3)IIP development now</p>
-<hezekiah>	<nop> 4) IIP development restructuring proposal</p>
-<qriff> actually its xx:13 everywhere...</p>
-<hezekiah>	<nop> 5) Recruiting for services to aid with IIP</p>
-<hezekiah>	<-- Delly has quit (Ping timeout)</p>
-<hezekiah>	<nop> 6) comments suggestions and people who want to help</p>
-<mids>	23:05:28 <@nop> 1) Welcome</p>
-<mids>	23:05:38 <@nop> 2)Our Goodbyes</p>
-<mids>	23:05:43 <@nop> 3)IIP development now</p>
-<mids>	23:05:56 <@nop> 4) IIP development restructuring proposal</p>
-<mids>	23:06:16 <@nop> 5) Recruiting for services to aid with IIP</p>
-<mids>	23:06:53 <@nop> 6) comments suggestions and people who want to help</p>
-<nop>	wow, flood in here ;)</p>
-<nop>	pl</p>
-<LeerokLacerta> Out goodbyes?</p>
-<hezekiah>	lol</p>
-<hifi>	TROLLS !!!</p>
-<nop>	Ok, welcome all</p>
-<nop>	let's settle down now :)</p>
-<hifi>	.</p>
-<Ambience>	settled</p>
--->	wilde (~anon@anon.iip) has joined #iip-dev</p>
-<hifi>	settled</p>
-<al-jebr>	anyone logging?</p>
--->	thecrypto (~thecrypto@anon.iip) has joined #iip-dev</p>
-<hezekiah>	I am (sort of).</p>
-<luckypunk>	mids should be.</p>
-*	jrand0m logs at all times</p>
-<al-jebr>	let's go!</p>
-<nop>	ok</p>
-<hezekiah>	nop: Agenda item number 2?</p>
-<nop>	Our goodbyes</p>
-<LeerokLacerta> Bye!</p>
-<thecrypto>	where is the livelog?</p>
-<nop>	Ok, mids has come to a point where he is moving to other projects</p>
--->	Phiberoptika (~none@anon.iip) has joined #iip-dev</p>
-<mids>	After having worked for IIP for more than I year now, I have decided to</p>
-	  resign as IIP developer.</p>
-<LeerokLacerta> Awww.</p>
-<mids>	It has been fun and an educative experience</p>
-<mids>	but it is time to move on, refresh the spirit and shuffle the cards.</p>
-<Rain>	Will you still be online/around?</p>
-<mids>	I'll keep running Trent as long as needed and possible.</p>
-<mids>	Yes, I do plan to stay around as user</p>
--->	ntk (~blob@anon.iip) has joined #iip-dev</p>
-*	nop is in the corner sobbing</p>
-<nop>	oh, ah hem</p>
-<jrand0m>	many thanks mids, iip w/out trent would be a pita</p>
-<LeerokLacerta> It's so sad.</p>
-<nop>	yes</p>
-<nop>	thank you mids for all your workup</p>
-<nop>	work</p>
-<mids>	Although I'll be off on vacation soon :)</p>
-<mids>	.</p>
----	mids removes channel operator status from mids</p>
-<luckypunk>	:D</p>
-<luckypunk>	Seem's like you've done a great job.  :)</p>
-<Rain>	..how symbolic..</p>
-<nop>	we love you mids!!!</p>
-<nop>	you hear that</p>
-<nop>	that was my window opening</p>
-<thecrypto>	we all do!</p>
-<nop>	fan base out there</p>
--->	w (~w@anon.iip) has joined #iip-dev</p>
----	nop is now known as we</p>
-<luckypunk>	lol, yep.</p>
-<luckypunk>	:D</p>
-*	we love you mids</p>
-<Rain>	Go mids go!</p>
-<jrand0m>	rofl</p>
--->	leenookx (~leenookx@anon.iip) has joined #iip-dev</p>
----	LeerokLacerta has changed the topic to: IIP Meeting - logfiles:</p>
-	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/</p>
-	  | We love you mids!</p>
-<Rain>	weeeeee are the chaaaampins, my frieeeennnndd...</p>
-<Neo>	yes mids, thanks for all your input, collaboration and hard work in code</p>
-	  and doing general developer things for IIP.</p>
----	we is now known as nop</p>
-*	mids bows</p>
-*	Ehud stands up and gives a standing ovation to the commitment, perseverence,</p>
-	  effort, and good hard code that mids has given the project.</p>
-<hifi>	yeah mids take your toys and go to tigertown lol</p>
-<nop>	and don't forget the PR and web management</p>
-<nop>	he's been a vital aspect to IIP</p>
-<nop>	getting it this far would have been hard without his work</p>
--->	ChZEROHag (hag@anon.iip) has joined #iip-dev</p>
-<hifi>	hifi bitches with mids over trolling issue</p>
-<--	hezekiah has quit (Ping timeout)</p>
-<mids>	heh hifi</p>
--->	hezekiah (~hezekiah@anon.iip) has joined #iip-dev</p>
----	Trent@anon.iip gives channel operator status to hezekiah</p>
-<hezekiah>	Back. :)</p>
-<luckypunk>	Yay.</p>
-<hezekiah>	(And in case anyone doubted, Hezekiah == Ehud.)</p>
-<hifi>	i never used frucking trent and don't know what mids did . i only troll .</p>
-<nop>	obviously your hezekiah@anon.iip gave it away</p>
-<--	Ehud has quit (Ping timeout)</p>
-<hezekiah>	Ugh</p>
-<hezekiah>	Item number 3?</p>
-<hezekiah>	(If we're all done sobbing yet ...)</p>
-<hifi>	and i never was pingouted in my life . I am the most disciplined user of</p>
-	  IIP .</p>
-<mids>	3)IIP development now</p>
-<luckypunk>	heh</p>
-<luckypunk>	Ok everyone!  Shhh.  Back on track!</p>
-<hifi>	BUT I CRY that MIDS GO !!!</p>
-<hifi>	ok</p>
-<hifi>	.</p>
-<luckypunk>	IIP development.  Whats the current status of that code snapshot</p>
-	  release?</p>
-<luckypunk>	That was supposed to happen today?</p>
-<hezekiah>	Well, unless UserX has an objection to the tarball I made,</p>
-	  it's done.</p>
-<luckypunk>	Ok.  Post it on the wiki?</p>
-<hezekiah>	UserX? Were there any problems with the tarball?</p>
-<UserX> no problems with the tarball</p>
-<luckypunk>	Yes, but are there any windows compilations?</p>
-<hezekiah>	OK1</p>
-<hezekiah>	http://invisiblenet.net/hezekiah</p>
-<hezekiah>	Get your tarballs there!</p>
-<UserX> there hasn't been a windows compilation on the windows version yet</p>
-<luckypunk>	hm</p>
-<LeerokLacerta> "tarballs" sound like some sort of food...</p>
-*	luckypunk will try and make one.</p>
----	hezekiah has changed the topic to: IIP Meeting - logfiles:</p>
-	  http://wiki.invisiblenet.net/?Meetings - http://www.invisiblenet.net/research/</p>
-- tarballs of the 'unstable' development release are at</p>
-	  http://invisiblenet.net/hezekiah | We love you mids!</p>
-<luckypunk>	They are.  For GCC.</p>
-<luckypunk>	lol</p>
-<Rain>	Sticky food.</p>
-<hezekiah>	There is one 'documented bug'.</p>
-<nop>	I can compile a win32 version if you'd like</p>
-<Rain>	So, could you give a quick describtion of what is new in this release?</p>
-<hezekiah>	If you run isproxy, and it fails to bind the port, then it will</p>
-	  /not/ abort. It will just sit there wasting memory.</p>
-<hezekiah>	Rain: That's too much for me to handle (not to mention I don't</p>
-	  even _know_ all the differences).</p>
-<Ambience>	this one I assume: iip-1.2-dev1.tar.bz2    01-Jul-2003 01:45</p>
-	  292k  tar archive ?</p>
-<hezekiah>	UserX could give a much better description</p>
-<hezekiah>	UserX?</p>
-<nop>	hezekiah/UserX can we get a changelog of the differences by chance</p>
-<nop>	that may be a day before that gets done</p>
-<hezekiah>	Ambience: Yup! Or the Gziped one. There the same tarball.</p>
-<nop>	because there are a log of changes</p>
-<Rain>	Oh, and has the expired IIP signing-key been replaced?</p>
-<Ambience>	hezekiah: ok</p>
-<hezekiah>	nop: I joined IIP after the development branch was already in</p>
-	  progress.</p>
--->	Ehud (~hezekiah@anon.iip) has joined #iip-dev</p>
-<hezekiah>	Rain: No. I had to use my GPG key.</p>
-<nop>	no one has tested the compile of this dev branch in win32 have they?</p>
-<luckypunk>	Hey, is this src is CVS?</p>
-<hezekiah>	Rain: I couldn't contact anyone who had the IIP release key.</p>
-<hezekiah>	luckypunk: Yes.</p>
-*	luckypunk has, but his system didn't work for it.</p>
-<Rain>	hezekiah: Ok, roger.</p>
-<UserX> changes: multi-threading,  bignum support via openSSL or GMP, numerous</p>
-	  inmprovements to the memory management system</p>
-<hezekiah>	luckypunk: Right now that tarball is a copy of what you get when</p>
-	  you check out the hezekiah-dev branch from CVS and run 'make dist-bzip2'.</p>
-<luckypunk>	Gah!  I hate windows.</p>
-<Rain>	UserX: niceties ;)</p>
-<hezekiah>	And of course there are other internal changes that only the</p>
-	  developers see. :)</p>
-<qriff> just as a question for the qurious... what defines the holder for "Trent"...</p>
-<hezekiah>	One simple thing is that now that BigNum is implemented using</p>
-	  either GMP or SSL, login is a LOT faster.</p>
-<Rain>	May i mention a IIP quirk i noticed earlier today?</p>
-*	luckypunk guesses its a yes.</p>
-<hifi>	at wiki search button is absent . only window to type in but nowhere to</p>
-	  click lol .</p>
-<luckypunk>	hit enter.</p>
-<qriff> and what about channel/nick expiration...</p>
----	Ehud is now known as logger</p>
-<qriff> registration that is...</p>
-<Rain>	Ok, it seems to me like you cannot start isproxy from a /path/to/isproxy</p>
-	  command, but intead have to do a cd /path/to and then do a ./isproxy</p>
-<hezekiah>	Rain: Let me guess ... you get a configuration screen or a request</p>
-	  for entropy, right?</p>
-*	jrand0m has a feeling this will be a very.long.meeting</p>
-<Rain>	Is that intentional, or just some quirk of my local system?</p>
-<Rain>	hezekiah: yes.</p>
-<hezekiah>	Rain: You need to make a .iip subdirectory in your home directory.</p>
-<Rain>	It claims that the conf-file is not found.</p>
-<Rain>	with my .conf file?</p>
-<hezekiah>	Rain: If no such directory exists, isproxy will always look for</p>
-	  the config files in the current directory</p>
--->	AmishOne (amishone@anon.iip) has joined #iip-dev</p>
-<Rain>	Ahh. Of course.</p>
-<hezekiah>	OK ...</p>
-<hezekiah>	nop? Was there anything else for item 3?</p>
-<nop>	have we tested it for win32</p>
-<nop>	compile wise</p>
-<hezekiah>	I haven't.</p>
-<nop>	UserX: ?</p>
-<UserX> no</p>
-<nop>	I will test it this week then</p>
-<hezekiah>	luckypunk, tried doing hezekiah-dev recently and complained for</p>
-	  compile errors.</p>
-<nop>	that's key to maintain portability</p>
-<hezekiah>	I suspect there might be problems.</p>
-*	luckypunk tried, it balked.</p>
-<hezekiah>	Yup. There are problems.</p>
-<Ambience>	I'll have to leave for the more dominant one is ordering me to</p>
-	  and I have no choice here. So I'll be off to bed, but will be logging #iip-dev</p>
-	  for future reference.</p>
-<Ambience>	see ya guys!</p>
-<lonelynerd>	later</p>
-<qriff> bye</p>
-<hezekiah>	Bye, Ambience. :)</p>
-<luckypunk>	i'll be back.</p>
-<Ambience>	<--gone (log on)</p>
-<nop>	ok</p>
-<nop>	this topic is done</p>
-<nop>	next on agenda</p>
-<nop>	what's 4?</p>
-<hezekiah>	4) IIP development restructuring proposal</p>
-<nop>	ok</p>
-<nop>	we had a meeting about a discussion and proposal brought to us by jrand0m</p>
-	  for the future development</p>
-<nop>	and as well</p>
-<nop>	I have had a lot of privmessages directed at me</p>
-<nop>	for requests to focus on an arbitrary framework, instead of IRC specific</p>
-<nop>	aka a framework that supports IRC + a whole lot more</p>
-<nop>	so the want is obviously there</p>
-<nop>	and the developers definitely want to go there as well</p>
-<hezekiah>	Amen!</p>
-<nop>	the question of how to go about doing it</p>
-<nop>	and how to make the most productive use of our developers</p>
-<nop>	is up in the air</p>
-<ChZEROHag>	XML</p>
-<mids>	is his framework site available to everybody?</p>
-<nop>	this isn't specifically about language</p>
-<ChZEROHag>	create a communications protocol</p>
-<nop>	ok, please let me finish</p>
-<ChZEROHag>	I've started on that somewhere...</p>
-<nop>	then we can comment</p>
-<ChZEROHag>	My apologies</p>
-<ChZEROHag>	I'm a bit in and out at the moment</p>
-<nop>	ok,</p>
-<nop>	no prob</p>
-<nop>	We are at a stage where there is discussion of an arbitrary communications</p>
-	  protocol</p>
-<nop>	specifically for anonymous and secure communication</p>
-<nop>	at this point jrand0m, any chance we can post the logs of #iip-future</p>
-	  meeting</p>
-<jrand0m>	sure</p>
-<jrand0m>	perhaps those zips I sent you so people don't have to struggle</p>
-	  through freenet for the other pages too</p>
-<nop>	ok</p>
-<nop>	hold</p>
-<nop>	please</p>
-<jrand0m>	(btw, the logs were unedited, so expect the usual occational banter)</p>
-<hezekiah>	lol. Yup! You'll get to see exactly how much I DON'T know about</p>
-	  p2p networks! lol</p>
-<jrand0m>	heh</p>
-<hezekiah>	(And they'll probably have my conspiracy theories about nop</p>
-	  too! So be sure to read the logs! ;-) )</p>
-<--	logger has quit (Ping timeout)</p>
-<hezekiah>	Ugh</p>
-<nop>	ok</p>
-<Neo>	the logs will be a lot to read. can someone summarizze for the meeting</p>
-	  what was covered and some key points of all this?</p>
-<nop>	http://office.invisiblenet.net/iip_future.zip</p>
-<nop>	and</p>
-<hezekiah>	At this point, the 'stable' release is being more unstable than</p>
-	  the 'unstable' one!! Urg.</p>
-<nop>	http://office.invisiblenet.net/meetingPrepnotes.zip</p>
-<nop>	http://office.invisiblenet.net/jrand0mnetwork_protocol.txt</p>
-<jrand0m>	meetingPrepnotes.zip is a small doc that summarizes the meeting,</p>
-	  and the meeting was basically "ok, any thoughts?".</p>
-<--	Delly has quit (EOF From client)</p>
-<jrand0m>	essentially, the proposal is to get going on a generic secure</p>
-	  anonymous message based system, and run iip on top of that</p>
-<mids>	is there a zip with anonCommFramework too?</p>
-<nop>	I didn't see that</p>
-<nop>	jrand0m can you zip and send I'll post to site</p>
-<jrand0m>	sure, h/o</p>
-<--	Phiberoptika has quit (* ciaito mua mua *)</p>
-<Neo>	what is anonCommFramework?</p>
-<jrand0m>	uber-quick summary of the meeting in iip_future.zip is "ok,</p>
-	  here's the proposal, any comments?" and comments were basically "ok, can IIP work</p>
-	  as planned on this?</p>
-<jrand0m>	if you're on freenet, anonCommFramework is at</p>
-	  SSK@MQNd5lT-X5wHA4vONvtVadi6q1IPAgM/anonCommFramework/2//</p>
-*	jrand0m is sending nop a zip of that momentarily</p>
-<Rain>	Did you discuss support for PGP-based nyms?</p>
-<nop>	ah hem, this is early discussions</p>
-<--	ChZEROHag has quit (Ping timeout)</p>
-<jrand0m>	no, endpoints in the framework are not nym based, they're idents</p>
-<Rain>	Right. So nyms an higher level.</p>
-<Rain>	are</p>
-<jrand0m>	(and for lots of reasons, they shouldn't be long term idents</p>
-	  like nyms)</p>
-<jrand0m>	yes</p>
-<Rain>	I was just thinking of something like trent with PGP signarute auth.</p>
-<mids>	trent is central</p>
-<mids>	central=bad</p>
--->	logger (~hezekiah@anon.iip) has joined #iip-dev</p>
-<jrand0m>	briefly, anonCommFramework is a meta-network.  a generic set</p>
-	  of protocols & structures that an anonymous communication network could use to</p>
-	  interoperate to provide militant grade anonymity</p>
-<wilde> what's the one sentence explanation of your ideas on network topology?</p>
--->	ChZEROHag (~hag@anon.iip) has joined #iip-dev</p>
-<ChZEROHag>	that was fun</p>
--->	Delly (dedede@anon.iip) has joined #iip-dev</p>
-<Rain>	mids: Yea. I meant similar services.</p>
-<lonelynerd>	what about having to pay with hashcash to send data? couldn't</p>
-	  that help against flooding?</p>
-<jrand0m>	wilde> heterogeneous.  no one answer solves all problems.</p>
-	  interoperate, balancing latency, bandwidth, anonymity, and reliability to provide</p>
-	  the user's needs</p>
-<Delly> still in 4) ?</p>
-<hezekiah>	Delly: Yup</p>
-<Delly> thx</p>
-<ChZEROHag>	I think when the ircd is removed from the equation, we'll have</p>
-	  far better options than (hash|think|real)cash</p>
-<nop>	jrand0m: any luck sending</p>
-<nop>	;)</p>
-<jrand0m>	uploading to hush now.</p>
-<jrand0m>	ChZEROHag> anonCommFramework has built in support for providing</p>
-	  network use authorization credentials</p>
-<Rain>	There has been a lot of talk of IIP-Freenet interoparability. Will that</p>
-	  fit into the framework, or are we talking application-level again?</p>
-<ChZEROHag>	come again?</p>
-<jrand0m>	app level</p>
-<jrand0m>	what we're discussing is splitting iip into two parts - the irc</p>
-	  part, and the message based secure anonymous network</p>
-<wilde> one solution could be:</p>
-<Rain>	jrand0m: k.</p>
-<wilde> Application <-> SOCKS5 Proxy Interface <-> Onion Wrapper <-> Onion Router</p>
-	  1 <-> ... <-> Onion Router N <-> Exit Relay <-> Public Server</p>
-<jrand0m>	building a DHT on top of the message layer should be fairly easy</p>
-<hezekiah>	DHT?</p>
-<jrand0m>	distributed hash table</p>
-<jrand0m>	(ala freenet)</p>
-<nop>	ok, jrand0m let me clarify</p>
-<ChZEROHag>	wilde: I think the plan is to design it such that the 'public</p>
-	  server' could be removed from the equation at some point</p>
-<nop>	are we talking about splitting irc, or merging to focus on anonymity</p>
-	  framework</p>
-<jrand0m>	well, given unlimited # of developers, splitting and doing both</p>
-	  (well, 3 things ;) in parallel.</p>
-<nop>	what I mean is that the irc part is application layer</p>
-<jrand0m>	given reality, there's prolly only enough dev time to get the</p>
-	  comm system running first, then iip on top</p>
-<jrand0m>	right exactly</p>
-<nop>	and since we have a somewhat viable network working with IIP</p>
-<jrand0m>	irc is just another app running on it</p>
-<nop>	then the idea should be</p>
-<nop>	is to have developers start focusing on framework aspects</p>
-<wilde> ChZEROHag: ok, what I suggested is an anonymizing layer for regular</p>
-	  internet traffic, not a seperate network</p>
-<hezekiah>	(This could get fun.)</p>
-<nop>	wilde there are weaknesses to that</p>
-<nop>	just to let you know</p>
-<nop>	aka the clear text on the outer ends</p>
-<--	AmishOne has quit (EOF From client)</p>
-<wilde> nop: yes, so all connections should be encrypted to the ends</p>
-<nop>	we have an effort as well to have anonymous web browsing possible with</p>
-	  this network</p>
-<jrand0m>	yes.  it must be able to operate without ever leaving the mixnet</p>
-<nop>	but it is not as real time direct as your proposal wilde</p>
-<nop>	it uses some time delay tactics</p>
-<nop>	with caching etc</p>
-<nop>	timing attacks are a serious threat to anonymity</p>
-<hifi>	I WANT ANONYMISER BASED on IIP !! I DON"t TRUST OTHER ANONYSERS THEY ARE</p>
-	  FBI TRAPs !!</p>
-<mids>	http://mids.student.utwente.nl/~mids/anonCommFramework/</p>
-<nop>	hifi, this isn't changing IIP, this is moving us forward</p>
-<nop>	thanks mids</p>
-<jrand0m>	heh word mids, my moz is hanging</p>
-<nop>	ok</p>
-<wilde> although independant mixnets are cool, the real killer apps will probably</p>
-	  be general ip traffic anonymizers</p>
-<nop>	wilde, they are myths</p>
-<wilde> killer apps?</p>
-<nop>	no</p>
-<--	thetower has quit (EOF From client)</p>
-<jrand0m>	wilde> that could be a service built on top of the comm layer</p>
-<nop>	general ip traffic anonymizers</p>
-<wilde> or ip traffic anonymizers?</p>
-<nop>	so far they don't exist</p>
-<nop>	they exist in papers only</p>
--->	thetower (none@anon.iip) has joined #iip-dev</p>
-<jrand0m>	if you build an anonymizing service on top of the comm layer,</p>
-	  however, your outbound routers will get shut down quickly</p>
-<thetower>	Haha, I just noticed I wasn't port forwarding.</p>
-<thetower>	Oop, sorry, wrong chan</p>
-<wilde> nop: what about the ZKS system?</p>
-<nop>	is it still around?</p>
-<nop>	and working</p>
-<wilde> nope, bad business</p>
-<wilde> few people paid</p>
-<wilde> but the framework seemed to work, but all nodes were ZKS:s paid relays</p>
-<nop>	wilde but they were internal and it wasn't complete</p>
-<nop>	it still had certain vulnerabilities</p>
-<nop>	it was a start</p>
-<nop>	I met Ian Goldberg at CodeCon 2k2, and he himself admitted it was incomplete</p>
-	  to what he desired</p>
-<wilde> yes, everything has vulnerabilities, we just raise the cost of tracing</p>
-	  dramatically</p>
-<jrand0m>	right, after the mixnet is up and running, i'd like to see wilde</p>
-	  offer generic outbound proxy services.	that'd be cool</p>
-<jrand0m>	(sincerely)</p>
-<nop>	jrand0m: but again the ultimate would be using that magic mirror concept</p>
-	  for optimum protection</p>
-<ChZEROHag>	Probably the hardest option, but wouldn't freenet be a good</p>
-	  framework to build from?</p>
-<nop>	wilde, maybe you and I can discuss this in another forum at some point</p>
-<jrand0m>	but in any case, the network must be built first</p>
-<ChZEROHag>	Or is that not what we're discussing?</p>
-<jrand0m>	ChZEROHag> no.</p>
-<jrand0m>	freenet doesn't provide hard anonymity</p>
-<ChZEROHag>	aah</p>
-<ChZEROHag>	I should try paying attention</p>
-<nop>	ok, moving forward</p>
-<nop>	UserX you still here</p>
-<wilde> nop: yes, if you have decided on topology there is no need to discuss</p>
-	  this in public</p>
-<UserX> I'm still here</p>
-<nop>	well it's application layer, so that comes after net design etc</p>
-<nop>	ok</p>
-<nop>	where did we leave off at #iip-future meeting</p>
-<--	hezekiah has quit (Ping timeout)</p>
-<nop>	let's start there</p>
----	logger is now known as Ehud</p>
-*	nop is catching up on the meeting logs</p>
-<jrand0m>	[04:31] <jrand0m> I think we're back to your question.	can /</p>
-	  should the irc functionality move forward as its going or move towards this mixnet.</p>
-	  there are significant benefits to move towards the mixnet, but some aspects of</p>
-	  the irc side seem to require some redesign to operate on it.</p>
-<jrand0m>	[04:31] <jrand0m> the right way for the irc development to go is</p>
-	  not for me to say</p>
-<Ehud>	Basically, UserX had some thinking to do about wether IIP could run</p>
-	  satisfactorily on the mixnet.</p>
-<mids>	nite all</p>
-<--	mids (mids@anon.iip) has left #iip-dev (mids)</p>
-<ChZEROHag>	Would it not be an idea to create a replacement irc in parallel</p>
-	  with a mixnet?</p>
-<ChZEROHag>	After all it's going to be damn hard to use a normal ircd</p>
-<jrand0m>	ChZEROHag> given infinite # devs, yes</p>
-<nop>	ok ChZEROHag silence please :)</p>
-<ChZEROHag>	Assume infinite devs</p>
-<ChZEROHag>	Oh is this not a question bit?</p>
--->	hezekiah (hezekiah@anon.iip) has joined #iip-dev</p>
-<nop>	not yet</p>
-<UserX> Unfortuantlely I haven't had time to seriously sit down and think about</p>
-	  how your proposal would fit in with IIP</p>
-<ChZEROHag>	oh</p>
-<ChZEROHag>	oops</p>
-<nop>	just want to get into the discussion</p>
-<nop>	well</p>
-<jrand0m>	UserX> think of the mixnet as a socket</p>
-<nop>	let me suggest something</p>
-<nop>	do we agree that our goal is not just IRC ?</p>
-<lonelynerd>	well</p>
-<Delly> it's a great idea sure</p>
-<hezekiah>	nop: Beyond all doubts, I agree that the goal is an anonymous</p>
-	  network.</p>
-<lonelynerd>	doing something traffic-intensive would have the potential to</p>
-	  ruin the whole project</p>
-<hezekiah>	nop: IRC is just a starting point.</p>
-<nop>	ok, well what we should look at is this</p>
-<jrand0m>	NOT doing something traffic intensive has the potential to get</p>
-	  us to overlook problems :)</p>
-<nop>	instead of saying IIP doesn't fit</p>
-<nop>	or it does fit</p>
-<nop>	let's look at what modifications need to be made for irc to fit with this</p>
-	  mixnet, whether it's a mod to the mixnet itself</p>
-<lonelynerd>	jrand0m: hmm</p>
-<nop>	for instance</p>
-<nop>	UserX has a vision of using channels as endpoints</p>
-<nop>	Jrand0m calls them idents</p>
-<nop>	are they having subtle differences</p>
-<nop>	or are they largely different</p>
-<jrand0m>	there's substance to those differences.</p>
-<nop>	can we review that</p>
-<nop>	on both sides</p>
-<nop>	from jrand0m and UserX</p>
-<--	hezekiah has quit (EOF From client)</p>
-<nop>	actually</p>
-<nop>	read the log</p>
-<nop>	nevermind</p>
-<jrand0m>	;)</p>
--->	hezekiah (hezekiah@anon.iip) has joined #iip-dev</p>
-<jrand0m>	the hesitancy I have w/ sending messages to a channel ident and</p>
-	  having that channel redistribute it to members is that the channel gets plaintext</p>
-<nop>	how does it get plaintext?</p>
-<jrand0m>	instead, I'd suggest having a channel contain just the channel info</p>
-	  (modes, users, topic, etc)</p>
-<jrand0m>	the channel is just an application running on one (well, 3+)</p>
-	  routers listening to one (well, 3+) identities.  when you /msg a channel, you</p>
-	  send a message to that identity (application).	it then resends it out to the N</p>
-	  users in the channel, encrypted to each</p>
-<nop>	well</p>
-<nop>	I had a proposal for that</p>
-<nop>	that would have the channel not contain plaintext</p>
-<nop>	directly</p>
-<jrand0m>	at least, without adding a channel key (which would be managed</p>
-	  by the channel application itself, which defeats the point)</p>
-<nop>	well</p>
-<nop>	we were having channel keys</p>
-<nop>	for private channels</p>
-<nop>	and pub channels are public anyway</p>
-<jrand0m>	right.	there may be ways around it.  y'all know more about irc</p>
-	  than I do.  there are other ways that don't require going this route though</p>
-<nop>	see the neat thing with message channels is this</p>
-<nop>	you scale slightly better than trying to find all idents to send to directly</p>
-<--	luckypunk has quit (Ping timeout)</p>
--->	dd0c (dd0c@anon.iip) has joined #iip-dev</p>
-<jrand0m>	I'm not sure you scale better, but you do redistribute the load</p>
-<jrand0m>	(we can find idents via O(log(n)))</p>
--->	sahara (~sahara@anon.iip) has joined #iip-dev</p>
-<jrand0m>	but thats neither here nor there, this is application layer</p>
-	  design ;)</p>
-<nop>	right</p>
-<jrand0m>	all we need to do, imho, is find some workable ways that *could*</p>
-	  operate on the comm layer and then leave it to the wayside until we get there</p>
-<UserX> jrand0m: messages sent to channels are encrypted with a channel key that</p>
-	  is different to the channel's identity. a channel server can't decrypt a message</p>
-	  unless it has come across the key by othermeans</p>
-<sahara>	did I miss the meeting?</p>
-<jrand0m>	you've got some ways that could work, it sounds like, right?</p>
-<jrand0m>	UserX> how does a user joining a channel get the key?</p>
-<hezekiah>	sahara: Nope. You're right in the middle of it! :)</p>
-<nop>	it's a key exchange</p>
-<jrand0m>	with whom nop?</p>
-<jrand0m>	brand new user joining #anonymous, and the app containing the</p>
-	  list of users on #anonymous doesn't have the key (As userx said)</p>
-<jrand0m>	(all I'm saying is there's a way to get all the functionality</p>
-	  and still avoid having a channel key)</p>
-<UserX> jrand0m: with public channels it is derived from the channel name. with</p>
-	  private channels the user either creates one or a someone gives them the keys to</p>
-	  the channel</p>
-<jrand0m>	'k, cool</p>
-<jrand0m>	so apps managing public channels can read the plaintext (by</p>
-	  deriving from the channel name)</p>
-<jrand0m>	(which is prolly fine)</p>
-<nop>	right</p>
-<wilde> jrand0m: if the apps encrypt the plaintext to each recepient, will it</p>
-	  scale well?</p>
-<jrand0m>	yes wilde, perhaps better (depending on the algorithm used to</p>
-	  nominate channel managers)</p>
-<jrand0m>	(though it will potentially have a nonserialized delivery)</p>
-<jrand0m>	((though i think thats the case with normal irc anyway))</p>
-<--	thecrypto has quit (Ping timeout)</p>
-<jrand0m>	but, getting back on to the question -</p>
-<jrand0m>	nop, what do we hope to have decided by the end of the discussion</p>
-	  of #4?</p>
-<--	Neo has quit (Ping timeout)</p>
--->	d (~sahara@anon.iip) has joined #iip-dev</p>
-<nop>	well</p>
-<--	sahara has quit (EOF From client)</p>
-<hifi>	simple site , problem is i am tech blond but want good things lol</p>
-<nop>	I was hoping that we could re-organize, but this is gonna be a discussion</p>
-	  for later</p>
-<hifi>	sorry OOPS</p>
-<nop>	UserX</p>
-<--	d has quit (Client exiting)</p>
-<nop>	how long will you need to think about certain aspects, and maybe doc them</p>
-	  up as a concern list</p>
-<UserX> hard to say. maybe a week</p>
-<nop>	what I'm thinking jrand0m is that a lot of this needs sorting out, rather</p>
-	  than just plowing into it, or we'll end up at the beginning with nothing to show</p>
-<nop>	so let's push a week into this</p>
-<nop>	and see what concerns are coming into play</p>
-<nop>	because again</p>
-<nop>	we want an adaptable mixnet</p>
-<nop>	any application should be able to survive</p>
-<jrand0m>	absolutely</p>
-<jrand0m>	thats the point of the anon comm framework</p>
-<--	wilde has quit ()</p>
-<nop>	ok, so let's put this off a week, and focus on some realistic proposals</p>
-	  that can fit all of our needs</p>
-<jrand0m>	you say "send message M to location L" and it magically, securely,</p>
-	  anonymously gets delivered</p>
-<nop>	but magic is one thing</p>
-<nop>	science is another</p>
-<nop>	of course you know that :)</p>
-<jrand0m>	the magic is from the app level's perspective ;)</p>
-<nop>	yes</p>
-<nop>	understood</p>
-<jrand0m>	the science is in that 15 page anonCommFramework/2// ;)</p>
-<nop>	ok</p>
-<hezekiah>	lol</p>
-<nop>	UserX, if you can get that in a week that would be helpful</p>
-<nop>	?</p>
-<jrand0m>	I'll aim at revamping the docs & getting comm layer network design</p>
-	  ready for then so we can hit the ground running</p>
-<nop>	well</p>
-<nop>	we haven't agreed on certain aspects</p>
-<nop>	I think that still should be hashed out</p>
-<jrand0m>	what, in the network layer, haven't we agreed on?</p>
-<nop>	personally I agree that maybe you post your anonCommFramework on iip-dev</p>
-<nop>	and have it reviewed and commented</p>
-*	jrand0m isn't on iip-dev</p>
-<Rain>	So, meeting again next tuesday, same bat-time, same bat-channel?</p>
-<nop>	what haven't we agreed on is whether it can support all applications</p>
-<hezekiah>	jrand0m: Just post to iip-dev@invisiblenet.net .</p>
-<hezekiah>	Rain: We are on item #4. There are still other items to go. :)</p>
-<jrand0m>	its ~800k.  if someone could post the URL to mids' mirror that'd</p>
-	  be cool</p>
-<Delly> argh</p>
-<Delly> re</p>
-<Delly> about services, i think if IIP become more easier and friendly, we will see</p>
-	  more users and more nodes. it's why i'm making script for mIRC user, one is a Trent</p>
-	  script, allowing to use Trent and Anonymail with the mouse, the other is a script</p>
-	  allowing to transfer file over iip, staying anonymous (using uuencoding). The</p>
-	  "protocol" used is easy and could be done for lot's irc clients with scripting</p>
-	  support. And so everybody could transfer little files, even between di</p>
-<jrand0m>	nop> I'm 100% certain it can support all applications.</p>
-<Rain>	hezekiah: Right. My missunderstanding.</p>
-<jrand0m>	this layer has been used for over a decade in hundreds of industries</p>
-<Delly> was my thought of the day</p>
-<nop>	well then where do we not agree</p>
-<nop>	if Irc is an issue, then how is it adaptable?</p>
-<jrand0m>	it isn't an issue</p>
-<jrand0m>	y'all just don't understand the layer's abstraction ;)</p>
-<lonelynerd>	Delly: i have a perl script that allows one to use ssh/telnet/etc</p>
-	  over irc</p>
-<jrand0m>	(really, think of it as a socket)</p>
-<Delly> lonelynerd, the goal was just to enhance mirc</p>
-<Delly> for iip network</p>
-<lonelynerd>	Delly: yeah, but if you use base64, i think it's compatible with</p>
-	  this one</p>
-<Delly> could be possible tu use it</p>
-<jrand0m>	ok, we ready for #5 yet?</p>
-<hezekiah>	nop?</p>
-<--	hezekiah has quit (Client exiting)</p>
-<Delly> oups i thought it was 5)  !</p>
-<ChZEROHag>	There's a 5?</p>
--->	hezekiah (hezekiah@anon.iip) has joined #iip-dev</p>
-<--	hezekiah has quit (Client exiting)</p>
--->	hezekiah (hezekiah@anon.iip) has joined #iip-dev</p>
-<nop>	sorry</p>
-<nop>	delly</p>
-<nop>	you guys</p>
-<nop>	this is off topic</p>
-<nop>	please reserve your conversation outside this channel</p>
--->	hezekiah_ (~hezekiah@anon.iip) has joined #iip-dev</p>
-<--	hezekiah has quit (EOF From client)</p>
-<nop>	well</p>
-<nop>	jrand0m</p>
----	hezekiah_ is now known as hezekiah</p>
-<nop>	before I agree to go to 5</p>
-<nop>	the problem I'm seeing is</p>
-<nop>	UserX has a voice</p>
-<nop>	as well</p>
----	Trent@anon.iip gives channel operator status to hezekiah</p>
-<jrand0m>	of course</p>
-<nop>	and if he sees logistical problems</p>
-<nop>	I believe they should be heard</p>
-<nop>	so you can't just say, hey it's gonna work</p>
-<nop>	it has to be "solidly" agreed on both ends</p>
-<nop>	aka he needs convincing</p>
-<jrand0m>	right, but I'm not going to sit on my thumbs waiting for him</p>
-	  to doc them up.  if he does come up with some problems in a week, fantastic,</p>
-	  and we'll revise accordingly</p>
-<nop>	or he needs to convine you</p>
-<nop>	but the idea is this</p>
-<nop>	what I'm trying to propose with this</p>
-<nop>	is to reorganize our dev team to get on your bandwagon</p>
-<nop>	with that</p>
-<nop>	it would put our energy in working on the network design</p>
-<nop>	that's the idea</p>
-<nop>	thus helping all of us get somewhere specific</p>
-<nop>	I'm not trying to slow down</p>
-<jrand0m>	right, i don't expect to have a V1.0 final protocol spec next week.</p>
-	  last night I downloaded about 50 new articles off citeseer to do some more research</p>
-<nop>	ok</p>
-<nop>	so can we post your proposal to iip-dev</p>
-<nop>	and get some review</p>
-<jrand0m>	coo'</p>
-<nop>	also I advise on your own to propose it on cryptography@metzdowd.com</p>
-<nop>	which will get some serious review</p>
-<jrand0m>	sounds good</p>
-<nop>	ok</p>
-<nop>	UserX, you there</p>
-<UserX> i'm here</p>
-<nop>	ok, so jrand0m will work on protocol spec, and can I assume you'll come</p>
-	  up with a concerns list or some additives to the protocol?</p>
-<UserX> yes</p>
-<nop>	ok, let's resume this in a week</p>
-<nop>	what was 5?</p>
-<nop>	sorry If I'm being a pain</p>
-<nop>	just want to organize it</p>
-<nop>	to make sure we're all on same page</p>
-<jrand0m>	recruiting for services...?</p>
-<hezekiah>	5) Recruiting for services to aid with IIP</p>
-<nop>	ok</p>
-<nop>	yes</p>
-<nop>	since mids departure</p>
-<nop>	and cohesions return</p>
-<nop>	we are possibly looking for others to contribute to IIP in some aspect</p>
-<nop>	this does not mean you have to be a hardcore core developer</p>
-<nop>	but additives like maybe a web maintainer would be good,</p>
-<nop>	some PR would be good</p>
-<hezekiah>	luckypunk volunteered to manage the website.</p>
-<hezekiah>	<luckypunk> I wanna help/take over the IIP website.</p>
-<hezekiah>	<luckypunk> :D</p>
-<nop>	and if more people would like to hop on with the upcoming project that</p>
-	  jrand0m is proposing</p>
-<jrand0m>	wikked</p>
-<nop>	even if you just want to review the protocol</p>
-<nop>	that is more than enough help</p>
-<nop>	the reality is this</p>
-<nop>	we have a lot of developers with real time jobs</p>
-<nop>	and it is consuming them at the moment</p>
-<nop>	and any additional help is wanted</p>
-<nop>	since this is a huge endeavor</p>
-<nop>	to take IIP to where it needs to be</p>
-<nop>	aka InvisibleNet at some point</p>
-<nop>	real life jobs ;)</p>
-<nop>	anyway</p>
-<nop>	the idea is</p>
-<nop>	it would be cool if people would love to add to this project in some ways</p>
-<nop>	using their skills, and I know their are some programmers out there</p>
-<nop>	and a few that have some spare tiem</p>
-<nop>	time</p>
-<nop>	luckypunk's reliability will have to be reviewed, no offense, I've had</p>
-	  him offer before with help maintaining a freesite, and no luck there</p>
-<hezekiah>	nop: I can understand that one. ;-)</p>
-<hezekiah>	nop: He just asked me to forward the offer along because he</p>
-	  wouldn't be here.</p>
-<nop>	ok</p>
-<hezekiah>	nop: I did. My part's done. :)</p>
-<nop>	well, either way, anyone who wants to join in</p>
-<nop>	contact one of us</p>
-<nop>	either at iip@invisiblenet.net</p>
-<hezekiah>	One of whom?</p>
-<nop>	or just by nick,</p>
-<nop>	hezekiah, userx, nop,</p>
-<jrand0m>	I hear anyone who volutneers to help iip gets free hookers and blow</p>
-<hezekiah>	What are 'hookers and blow'?</p>
-<hezekiah>	... or do I not want to know?</p>
-<jrand0m>	heh</p>
-<nop>	hezekiah: don't ask</p>
-<hezekiah>	OK.</p>
-<hezekiah>	I don't want to know. :)</p>
-<nop>	hezekiah: enjoy your sheltered life ;)</p>
-<nop>	while you can</p>
-<nop>	cuz college is gonna be fun :)</p>
-<hezekiah>	I'm enjoying it! I'm enjoying it!</p>
-*	jrand0m enjoys the hookers and blow ;)</p>
-<nop>	jrand0m: quick question</p>
-*	w hugs luckypunk and nop</p>
-<jrand0m>	si sr?</p>
-<nop>	jrand0m: are you considering yourself a dev of IIP at some time soon?</p>
-<nop>	since you are offering a merge ;)</p>
-<hifi></p>
-	  http://www.guerrillanews.com/cgi-bin/wwwthreads/showflat.pl?Cat=&Board=gnn&Number=182767&page=0&view=collapsed&sb=5&o=0&part=</p>
-<hifi>	sorry , opps again</p>
-<jrand0m>	nop> a dev of invisiblenet, but I can't contribute to iip</p>
-<nop>	understood</p>
-<nop>	IIP == invisiblenet future projects</p>
-<hezekiah>	jrand0m: Good working!</p>
-<hezekiah>	jrand0m: Wording.</p>
-<nop>	devs wanted for either</p>
-<nop>	to make that clear</p>
-<nop>	specifically cuz jrand0m could use a good team set</p>
-<Addic> I could take a look of the Windows code...</p>
-<jrand0m>	si sr.	once we get rolling into software design, there's going</p>
-	  to be more truckloads of work than one can imagine</p>
-<jrand0m>	word Addic</p>
-<nop>	awesome</p>
-<nop>	ok</p>
-<nop>	I will send this request on iip-dev line as well</p>
-<nop>	anyone interested please don't hesitate to contact</p>
-<nop>	was there a 6?</p>
-<nop>	I believe so</p>
-<jrand0m>	6) comments suggestions and people who want to help</p>
-<jrand0m>	suggestion: < 1.8 hours next time :)</p>
-<jrand0m>	(not that any of the topics could have been condensed any more</p>
-	  than they were)</p>
-<nop>	no comments?</p>
-*	nop thinks everyone's asleep</p>
-<nop>	hehe</p>
-<nop>	we bored them</p>
-<jrand0m>	w3wt</p>
-<Addic> heh, who has been working on the Windows' code this far?</p>
-<nop>	ok</p>
-<hifi>	zzzzzz...</p>
-<nop>	UserX has made it so far portable</p>
-<Rain>	What kind of talents are we looking for?</p>
-<Addic> ok</p>
-<nop>	ok, let me re-iterate</p>
-<nop>	Coders, Graphics dudes, Web devs, PR people, Web maintainers</p>
-<Rain>	Ok, missed that. Sry.</p>
-<nop>	and if you can write biz plans, that helps me too :)</p>
-<nop>	you didn't miss</p>
-<nop>	I didn't go in enough detail</p>
-<jrand0m>	heh</p>
-<--	Ehud has quit (EOF From client)</p>
-<hifi>	I am Born PR people</p>
-<Rain>	Step one: Collect Underpants.</p>
-<Addic> translating to other languages at wiki?</p>
-<nop>	yes</p>
-<nop>	that would be great</p>
-<nop>	translations</p>
-<Addic> ok, i could do that too</p>
-<nop>	documentation</p>
-<nop>	etc</p>
-<--	hezekiah has quit (Ping timeout)</p>
-<nop>	even organization</p>
-<nop>	anyone who wants to be actively involved in helping InvisibelNet/IIP</p>
-<hifi>	I invite ppl to use IIP alll the time</p>
-<nop>	thnx hifi</p>
--->	hezekiah (hezekiah@anon.iip) has joined #iip-dev</p>
-<Rain>	What kind of org skills?</p>
-<nop>	well, maybe help run the meetings, or maybe forcing us dev guys to get</p>
-	  more docs on the protocol</p>
-<nop>	etc</p>
-<nop>	possibly organize interviews and some type of press releases</p>
-<nop>	some ideas for the future of promoting the use of IIP</p>
-<nop>	etc</p>
-<nop>	ok, please contact one of us if you want to help out</p>
-<Rain>	Ok, org question, that I have mentioned before: IIP Signing key? (nag, nag)</p>
--->	Ehud (~hezekiah@anon.iip) has joined #iip-dev</p>
-<hifi>	IIP notification service :) for ppl to knoe I /him is online LOL</p>
-<qriff> just as a question for the qurious... what defines the holder for "Trent"...</p>
-<qriff> and what about channel/nick expiration...</p>
-<qriff> registration that is...</p>
-<--	ChZEROHag has quit (Ping timeout)</p>
-<jrand0m>	trent is a service, not a nick, so trent must have access to the</p>
-	  ircd (i think)</p>
-<nop>	these questions are mids questions for trent, he's an abstract piece</p>
-<nop>	yes jrand0m</p>
-<jrand0m>	iip notification would be cool.  how does anonymail do it?</p>
-<jrand0m>	can clients send a /notify nick to the server and get a msg when</p>
-	  the nick joins?</p>
-<hifi>	IIP SMS notification LOL</p>
-<nop>	actually</p>
-<nop>	we did have IIP SMS as the first version of anonymail</p>
-<nop>	but it tended to flood</p>
-<hifi>	oh</p>
-<nop>	so now we do it as anonymail database delivery</p>
-<hifi>	IIP invitation msg as signature to ordinary e-mails ...</p>
-<hifi>	Kinda " Do yo Yahoo ? Get MSN free " stuff</p>
-<jrand0m>	ooOOoo textAds</p>
-<jrand0m>	but does iip need more users?</p>
-<hifi>	oh</p>
-<jrand0m>	or is getting more users just a "oh cool, lets service more people"?</p>
-<hifi>	no</p>
-<hifi>	dunno</p>
-<hifi>	i just brainstorm</p>
-<--	Mira has quit (Ping timeout)</p>
-<hezekiah>	More people ... more ideas ... more volunteers</p>
-<hifi>	IIP as world standart will be cool</p>
-<hezekiah>	More people ... more problems ... more strain on the network ...</p>
-<hezekiah>	... more floods of #anonymous ...</p>
-<hezekiah>	It's a two sided question.</p>
-<hifi>	more channels lol</p>
--->	Mira (~Mira@anon.iip) has joined #iip-dev</p>
-<hifi>	IIP Eugenics Program LOL Less Population Less Problems</p>
--->	ChZEROHag (~hag@anon.iip) has joined #iip-dev</p>
-<Addic> hmm... going back to the notification question... is it so the /notify</p>
-	  nick does not work here? Or am I not understanding the question...</p>
-<lonelynerd>	Addic: sure it works</p>
-<Addic> well what's the problem then?</p>
-<hifi>	?</p>
-<--	Delly has quit (EOF From client)</p>
-<lonelynerd>	wasn't much following the conversation, but they talked about</p>
-	  having a /notify that wouldn't require the client to poll</p>
-<Addic> ok</p>
-<--	ChZEROHag has quit (Ping timeout)</p>
-<--	w has quit (Ping timeout)</p>
-<--	Rain has quit (I Quit)</p>
--->	w (~w@anon.iip) has joined #iip-dev</p>
-<hezekiah>	Hmmm ...</p>
-<hezekiah>	I think it's about time we adjurne this meeting.</p>
-<hezekiah>	What do you say, nop?</p>
-*	jrand0m thinks he fell asleep too</p>
-<nop>	yeah</p>
-<nop>	ok</p>
-<nop>	later</p>
-<--	jrand0m (jrandom@anon.iip) has left #iip-dev (jrand0m)</p>
-<hezekiah>	Meeting adjurned! :)</p>
-<hezekiah>	*BAF*!</p>
-<--	Addic (anon@anon.iip) has left #iip-dev (Addic)</p>
-<--	LeerokLacerta (~leerok@anon.iip) has left #iip-dev (Client Exiting)</p>
-<--	hezekiah has quit (Client exiting)</p>
-<--	Ehud has quit (Client exiting)</p>
-</div>
-{% endblock %}
\ No newline at end of file
+-->	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/47.rst b/i2p2www/meetings/47.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/47.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/49.log b/i2p2www/meetings/49.log
index 68573bff..29be7821 100644
--- a/i2p2www/meetings/49.log
+++ b/i2p2www/meetings/49.log
@@ -1,746 +1,741 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 49{% endblock %}
-{% block content %}<div class="irclog">
---- Log opened Tue Jul 15 17:46:47 2003</p>
-17:46 < gott> yo.</p>
-17:46 <@nop> just a heads up on my silence</p>
-17:46 <@hezekiah> Tue Jul 15 21:46:49 UTC 2003</p>
-17:47 <@hezekiah> OK. The iip-dev meeting has started.</p>
-17:47 <@hezekiah> Is it the 48th or 49th?</p>
-17:47 < jrand0m> nop> this is why its critical that we get the router</p>
-	 architecture pounded out asap.  I understand that different people have</p>
-	 different rates of speed, and we must segment so different components can</p>
-	 proceed accordingly</p>
-17:47 < mihi> 49th</p>
-17:47 <@hezekiah> OK! Welcome to the 49th iip-dev meeting!</p>
-17:47 < jrand0m> I have three more days at my job, after which 90+ hours /</p>
-	 week will be dedicated to getting this going</p>
-17:48 < jrand0m> I know and don't expect everyone to be able to do that,</p>
-	 which is why we need to segment</p>
-17:48 < jrand0m> hi hezekiah :)</p>
-17:48 <@hezekiah> lol</p>
-17:48 <@nop> to rebutt on that</p>
-17:48 <@hezekiah> I'll wait a minute. Then we can do the agenda. :)</p>
-17:48 <@nop> the security of the router architecture is dependant that you</p>
-	 do not rush as well</p>
-17:49 <@nop> if we do</p>
-17:49 <@nop> we overlook</p>
-17:49 <@nop> which could leave us cleaning up a big mess later</p>
-17:49 -!- Rain [Rain@anon.iip] has quit [I Quit]</p>
-17:49 < jrand0m> nop> disagree.  we can still build app layer and APIs</p>
-	 without implementing the router (or even knowing how the network will operate)</p>
-17:49 <@nop> I agree with that</p>
-17:50 <@nop> I'm specifically talking about the underlying network</p>
-17:50 < jrand0m> if we can agree to the API I sent out, then thats the</p>
-	 segmentation we need</p>
-17:50 < jrand0m> right, router impl and network design still isn't done</p>
-17:50 <@nop> ok</p>
-17:50 <@nop> oh, I can definitely agree with your api so far</p>
-17:51 <@hezekiah> jrand0m: One problem.</p>
-17:51 < jrand0m> shoot hezekiah</p>
-17:51 <@hezekiah> It will look different if you implement it in C.</p>
-17:51 < jrand0m> not too different</p>
-17:51 < gott> oh dear</p>
-17:51 < jrand0m> less capital letters, and replace the objects with structs</p>
-17:51 < gott> what languages are people considering implementing it in?</p>
-17:51 < jrand0m> (for the api)</p>
-17:51 <@hezekiah> Uh, jrand0m? There is no 'byte[]' in C.</p>
-17:51 < jrand0m> gott> read the mail archives for some example answers to that</p>
-17:52 <@hezekiah> You will be using void*'s with an integer to specifiy the</p>
-	 length most likely.</p>
-17:52 < jrand0m> hezekiah> then unsigned int[]</p>
-17:52 < gott> jrand0m: for once, a religious war that I'm not a part of</p>
-17:52 <@hezekiah> If I remember correctly (help me out here nop), you can't</p>
-	 just return an unsigned int[] from a function.</p>
-17:53 <@hezekiah> gott: It's not a religious war. I'm just saying that the</p>
-	 API as a concept might be fine, but in C it would look seriously different.</p>
-17:53 < gott> hezekiah: as opposed to what? pseudocode?</p>
-17:53 < jrand0m> right, syntactic changes.  but yes, if there are real</p>
-	 differences, we need to get them worked out ASAP.  (like, today)  Perhaps</p>
-	 now would be a good tiem to look at the email I sent entitled "high level</p>
-	 router architecture and API" and review?</p>
-17:54 <@hezekiah> nop? UserX? Are you game for that?</p>
-17:54 < jrand0m> not too different, but different none the less, yes.</p>
-	 which is why I said Java API on todays email :)</p>
-17:54 -!- WinBear [WinBear@anon.iip] has joined #iip-dev</p>
-17:55 <@nop> wait</p>
-17:55 <@nop> reading above</p>
-17:55 -!- mihi_2 [~none@anon.iip] has joined #iip-dev</p>
-17:55 -!- mihi is now known as nickthief60234</p>
-17:55 -!- mihi_2 is now known as mihi</p>
-17:55 < jrand0m> wb mihi</p>
-17:55 < gott> btw, is this being live logged?</p>
-17:55 -!- nickthief60234 [~none@anon.iip] has quit [EOF From client]</p>
-17:55 <@hezekiah> gott: Yes.</p>
-17:55 < mihi> redundancy rules ;)</p>
-17:55 < gott> I'll just read it later on then.</p>
-17:55 -!- gott [~gott@anon.iip] has left #iip-dev [gott]</p>
-17:56 <@nop> ok</p>
-17:56 <@nop> yes</p>
-17:56 < WinBear> jrand0m: hi</p>
-17:56 <@nop> definitely differences</p>
-17:56 <@nop> what we need</p>
-17:56 < jrand0m> heya WinBear</p>
-17:56 <@nop> is a team of certain developers to write the main api level</p>
-	 controls for these languages</p>
-17:56 <@nop> we know that jrand0m can handle java</p>
-17:56 <@nop> and probably could team up with thecrypto as well</p>
-17:56 <@nop> and hezekiah and the gang can do C</p>
-17:56 <@nop> and jeremiah if he's willing</p>
-17:56 <@nop> can do python</p>
-17:56 <@hezekiah> I can do C++ too! ;-)</p>
-17:56 <@nop> ok</p>
-17:56 <@nop> C++ as well</p>
-17:57 <@hezekiah> lol</p>
-17:57 <@nop> C++ will probably work</p>
-17:57 <@nop> with C</p>
-17:57 <@nop> if you don't template the crap out of it</p>
-17:57 < jrand0m> heh</p>
-17:57 <@hezekiah> lol</p>
-17:57 <@hezekiah> Actually, while MSVC can link C and C++ object files,</p>
-	 gcc doesn't seem to like that.</p>
-17:57 <@nop> aka, stick to structs that are compatible with C, or is that</p>
-	 not viable</p>
-17:57 < jrand0m> first question, prior to that, is what applications will use</p>
-	 these APIs?  I know of apps that will want to use java, will iproxy be in C?</p>
-17:58 <@hezekiah> nop: I don't think C and C++ are object compatible.</p>
-17:58 <@nop> ok</p>
-17:58 <@hezekiah> nop: C++ won't get along with C much better than Java.</p>
-17:58 <@nop> well maybe USerX could do C</p>
-17:58 <@nop> and you could pull C++</p>
-17:58 <@hezekiah> We don</p>
-17:58 <@nop> ?</p>
-17:58 <@hezekiah> don't even need to _do_ C++ if you don't want to. It's</p>
-	 just that I prefer it.</p>
-17:59 <@nop> well, the thing is</p>
-17:59 <@nop> there are a lot of C++ developers</p>
-17:59 <@nop> especially in the microsoft world</p>
-17:59 <@hezekiah> Even in the Linux world. (see: KDE and Qt.)</p>
-17:59 < jrand0m> C and C++ are binary compatible if you just make .so or .a</p>
-17:59 < jrand0m> (btw)</p>
-18:00 <@nop> can C be a good placement for C++, aka C++ developers would be</p>
-	 able to handle a c api easier than a C++ api with a c developer?</p>
-18:00 <@hezekiah> jrand0m: Yeah. You can probably have libraries ... but if</p>
-	 you can</p>
-18:00 <@hezekiah> jrand0m: can't even use classes, it sorta defeats the</p>
-	 purpose.</p>
-18:00 <@nop> right</p>
-18:00 <@nop> let's stick with C</p>
-18:01 <@nop> because C++ coders can still call a C library rather easily</p>
-18:01 <@hezekiah> If one module needs to call anothers functions, then they</p>
-	 had best both be the same language.</p>
-18:01 <@hezekiah> nop: C++ coders will know C well enough ... though it</p>
-	 might take some work if they never /learned/ C.</p>
-18:02 <@hezekiah> However, C coders wouldn't know C++ since C is just a</p>
-	 subset of C++.</p>
-18:02 -!- logger_ [~logger@anon.iip] has joined #iip-dev</p>
-18:02 -!- Topic for #iip-dev: logfiles will be online after the meeting:</p>
-	 http://wiki.invisiblenet.net/?Meetings</p>
-18:02 [Users #iip-dev]</p>
-18:02 [@hezekiah] [+Ehud    ] [ leenookx] [ moltar] [ tek    ]</p>
-18:02 [@nop     ] [ jeremiah] [ logger_ ] [ Neo   ] [ WinBear]</p>
-18:02 [@UserX   ] [ jrand0m ] [ mihi    ] [ ptsc  ]</p>
-18:02 -!- Irssi: #iip-dev: Total of 14 nicks [3 ops, 0 halfops, 1 voices,</p>
-10 normal]</p>
-18:02 < jrand0m> right</p>
-18:02 -!- Irssi: Join to #iip-dev was synced in 9 secs</p>
-18:02 < jrand0m> (with JMS :)</p>
-18:02 <@nop> yep</p>
-18:03 -!- You're now known as logger</p>
-18:03 < jrand0m> ok, can we review the overall architecture to see whether</p>
-	 the APIs are even relevent first?</p>
-18:03 <@nop> fine  18:04 < jrand0m> :)</p>
-18:04 < jrand0m> ok, see the email I sent w/ the routerArchitecture.png.</p>
-	 any thoughts on that seperation?</p>
-18:04 -!- tek [~tek@anon.iip] has quit []</p>
-18:05 < WinBear> jrand0m: is that on the wiki?</p>
-18:05 < jrand0m> WinBear> no, on the mailing list, though the archives</p>
-	 are down.  lemmie add it to the wikki</p>
-18:06 <@hezekiah> Correct me if I'm wrong ...</p>
-18:07 <@hezekiah> ... but it looks like we're going to have 3 seperate API's</p>
-	 that are as similar as possible.</p>
-18:07 <@hezekiah> Right?</p>
-18:07 < jrand0m> yes hezekiah</p>
-18:07 <@hezekiah> So since each API is in a different language, are they</p>
-	 going all each have seperate implementations?</p>
-18:07 < jrand0m> yes</p>
-18:07 <@hezekiah> Or is there a way for Java or Python to access a C library?</p>
-18:08 < jrand0m> yes, but we don't want to go that route</p>
-18:08 < mihi> for java: JNI</p>
-18:08 <@hezekiah> So this talk about Java, C, C++, Python, etc. working</p>
-	 together is mute since they never will?</p>
-18:08 < jrand0m> how do I attach an image to the wiki?</p>
-18:08 <@hezekiah> Each API has its own backend written in that language.</p>
-18:08 < jrand0m> no hezekiah, look at the diagram</p>
-18:09 <@hezekiah> Oh, duh!</p>
-18:09 <@hezekiah> The API's don't link to a backend.</p>
-18:10 <@hezekiah> They talk via sockets.</p>
-18:10 < jrand0m> si sr</p>
-18:10 <@hezekiah> This is still a little confusing though.</p>
-18:10 <@hezekiah> Give me a sec here. :)</p>
-18:11 <@hezekiah> OK. What is the thing labeled 'transport'?</p>
-18:11 < jrand0m> for example, bidirectional HTTP transport, SMTP transport,</p>
-	 plain socket transport, polling HTTP socket, etc</p>
-18:11 < jrand0m> the thing that moves bytes between routers</p>
-18:12 <@hezekiah> OK.</p>
-18:12 <@hezekiah> So the diagram I'm looking at shows one person's computer.</p>
-18:12 <@hezekiah> He has a router that talks to other people's computers</p>
-	 via the transports.</p>
-18:12 < jrand0m> correct</p>
-18:12 <@hezekiah> Person 1 (Alice) has 2 applications running.</p>
-18:12 <@hezekiah> One is in C, the other in Java.</p>
-18:13 <@hezekiah> Both are linked to a library (that's the API).</p>
-18:13 < jrand0m> both are "linked" to seperate libraries (the APIs)</p>
-18:13 <@nop> simple concept</p>
-18:13 <@nop> yes</p>
-18:13 <@hezekiah> Those libraries, take input from the program encrypt it,</p>
-	 and send it via sockets (unix or TCP) to the router ... which is another</p>
-	 program Alice is running.</p>
-18:13 < jrand0m> correct</p>
-18:14 <@hezekiah> OK. So it's kinda like isproxy being split in two.</p>
-18:14 < jrand0m> bingo :)</p>
-18:14 <@hezekiah> One part is low end and written in C, and the other is</p>
-	 high end and written in whatever.</p>
-18:14 < jrand0m> exactly</p>
-18:14 <@hezekiah> OK. I get it. :)</p>
-18:14 < jrand0m> w00t</p>
-18:14 <@hezekiah> So no language needs to play nice with any other language.</p>
-18:14 < jrand0m> WinBear> sorry, I can't toss it on the wiki as it only</p>
-	 takes text :/</p>
-18:15 <@hezekiah> Since they all comunicate with the router via sockets,</p>
-	 you could write an API in PASCAL for all the design cares.</p>
-18:15 <@nop> yes</p>
-18:15 <@nop> arbitrary</p>
-18:15 < jrand0m> right</p>
-18:15 <@nop> it handles arbitrary sockets</p>
-18:15 < jrand0m> though some things need to be standardized (like the data</p>
-	 structures for Destination, Lease, etc)</p>
-18:15 < WinBear> jrand0m: i get a vague idea based on what hezekiah is saying</p>
-18:15 < jrand0m> word</p>
-18:16 <@hezekiah> jrand0m: Right. The structure and order of the bytes that</p>
-	 go across that socket is set in a design somewhre</p>
-18:16 <@hezekiah> somewhere.</p>
-18:17 <@hezekiah> But you can still implement how those bytes are send and</p>
-	 received any joly way you please.</p>
-18:17 <@nop> WinBear: it's the same exact way that the irc client works</p>
-	 with isproxy</p>
-18:17 < jrand0m> exactly</p>
-18:17 <@hezekiah> Good.</p>
-18:17 <@hezekiah> I understand now. :)</p>
-18:17 -!- moltar [~me@anon.iip] has left #iip-dev [moltar]</p>
-18:17 <@nop> well</p>
-18:17 <@nop> not exactly</p>
-18:17 <@hezekiah> Uh oh.</p>
-18:17 <@nop> but imagine how that works</p>
-18:17 <@nop> and you can understand arbitrary sockets</p>
-18:17 <@nop> isproxy just routes</p>
-18:17 <@nop> and delivers</p>
-18:18 <@nop> now jrand0m</p>
-18:18 <@nop> quick question</p>
-18:18 < jrand0m> si sr?</p>
-18:18 <@nop> is this api designed for only new applications that are designed</p>
-	 to work on this network</p>
-18:18 -!- mode/#iip-dev [+v logger] by hezekiah</p>
-18:18 < WinBear> nop: with the highlevel replacing the irc client?</p>
-18:18 < jrand0m> nop> yes.  though a SOCKS5 proxy could use this API as well</p>
-18:18 <@nop> or can it be able to have a middle man that can allow already</p>
-	 standard clients</p>
-18:18 <@nop> for instance</p>
-18:19 <@nop> so all we would have to do is write the middleman -> api</p>
-18:19 < jrand0m> (but note that there's no 'lookup' service available -</p>
-	 no DNS for this network)</p>
-18:19 < jrand0m> correct</p>
-18:19 <@nop> so that we can support say Mozilla etc</p>
-18:19 <@nop> so they can just code plugins</p>
-18:19 < jrand0m> nop> yes</p>
-18:19 <@nop> ok</p>
-18:19 <@nop> or transports :)</p>
-18:20 < jrand0m> (e.g. the SOCKS5 has the HTTP outproxies hardcoded to</p>
-	 destination1, destination2, and destination3)</p>
-18:20 <@nop> ok</p>
-18:20 < WinBear> i think i get it</p>
-18:21 < jrand0m> w00t</p>
-18:21 < jrand0m> ok, one of the things I had to think about in this design</p>
-	 was keeping the private keys in the app's memory space - the router never</p>
-	 gets a hold of destination private keys.</p>
-18:21 <@hezekiah> So the application can send raw data over the I2P network</p>
-	 by sending it to the API, and it doesn't need to worry about the rest.</p>
-18:22 <@hezekiah> Right?</p>
-18:22 < jrand0m> that means the APIs need to implement the end to end part</p>
-	 of the crypto</p>
-18:22 < jrand0m> exactly hezekiah</p>
-18:22 <@hezekiah> OK.</p>
-18:22 <@nop> yes</p>
-18:22 <@nop> that's the idea</p>
-18:22 <@nop> it does it for you</p>
-18:22 <@nop> you just call the hook</p>
-18:23 <@hezekiah> One quick question:</p>
-18:23 <@hezekiah> This 'router' obviously needs to speak a certain protocol</p>
-	 over it's transports.</p>
-18:23 < jrand0m> correct</p>
-18:23 <@hezekiah> So it is possible to provide multiple implementations of</p>
-	 the router ...</p>
-18:23 < jrand0m> yes</p>
-18:24 <@hezekiah> ... as long as they both speak the same protocol.</p>
-18:24 < jrand0m> (which is why the spec has placeholders for bitbuckets)</p>
-18:24 < jrand0m> right</p>
-18:24 <@hezekiah> So you have a router in Java, and one in C, and one</p>
-	 in PASCAL.</p>
-18:24  * jrand0m cringes</p>
-18:24 < jrand0m> but yeah</p>
-18:24 <@hezekiah> And they all can talk together since they're talking over</p>
-	 TCP/IP using the same protocol.</p>
-18:24  * WinBear jumps</p>
-18:24 <@hezekiah> jrand0m: And yes. I don't remember my PASCAL days overly</p>
-	 fondly either.</p>
-18:25 < jrand0m> well, Pascal can talk to the C one through the TCP transport,</p>
-	 and the C one can talk to the Java one over the HTTP transport, for example</p>
-18:25 <@hezekiah> Right.</p>
-18:25 < jrand0m> (transports talk to other like transports, routers manage</p>
-	 the messages delivered between them but don't deal with how they're delivered)</p>
-18:26 <@hezekiah> The point I was looking to make was that the protocol is the</p>
-	 same, so it doesn't matter what language someone's router is implemented in.</p>
-18:26 < jrand0m> right</p>
-18:26 <@hezekiah> Cool.</p>
-18:26 < jrand0m> now you understand why I said "who cares" to all the C vs</p>
-	 Java vs etc debates?  :)</p>
-18:26 <@hezekiah> Yup.</p>
-18:26 <@hezekiah> lol</p>
-18:27 <@hezekiah> I've got to hand it to you jrand0m. This will make it very</p>
-	 kind for develoeprs to write programs for this network.</p>
-18:27 < jrand0m> heh, well, the API ain't quite original.  this is how</p>
-	 Message Oriented Middleware (MOM) works</p>
-18:27 <@hezekiah> And you could even make routers that specialize in certain</p>
-	 platform specific features (like 64-bit CPU's).</p>
-18:28 < jrand0m> absolutely</p>
-18:28 <@hezekiah> jrand0m: Humble too! ;-)</p>
-18:28 <@hezekiah> Well, it looks good to me.</p>
-18:28 < jrand0m> ok, UserX, nop, does this seperation make sense?</p>
-18:28 <@nop> of course</p>
-18:28 <@nop> is userx still here</p>
-18:29 <@hezekiah> He's been idle for 1:26.</p>
-18:29 < jrand0m> 'k.  so then we have two tasks: design the network, and</p>
-	 design how the API works.</p>
-18:29 <@nop> right</p>
-18:29 <@hezekiah> Quick simple question: The API's do end to end crypto. Do</p>
-	 the routers to node to node crypto ?</p>
-18:29 <@nop> yes</p>
-18:30 < jrand0m> yes</p>
-18:30 < jrand0m> (transport level)</p>
-18:30 <@hezekiah> Good. :)</p>
-18:30 <@nop> hezekiah: it's very similar to what we have so far</p>
-18:30 <@nop> in that aspect</p>
-18:31 < jrand0m> ok.. er, shit, thecrypto aint around for comments on the</p>
-	 performance model.</p>
-18:31 < Neo> and for the paranoid, the apps can do the pgp encryption before</p>
-	 it hits the API ;)</p>
-18:31 < jrand0m> absolutely neo</p>
-18:31 < jrand0m> I was even tempted to leave the end to end crypto out of</p>
-	 the API and leave it up to the apps...</p>
-18:31 <@hezekiah> jrand0m: That would be cruel.</p>
-18:31 < jrand0m> heheh</p>
-18:32 <@hezekiah> BTW, the API's and the router communicate via sockets.</p>
-18:32 <@hezekiah> On UNIX will they be using UNIX sockets or local TCP/IP</p>
-	 sockets?</p>
-18:32 < jrand0m> prolly just local tcp/ip for simplicity</p>
-18:32 <@nop> hold</p>
-18:32 <@hezekiah> (I suppose you could make a router that accepts both.)</p>
-18:33  * hezekiah is really liking this interchangable parts setup</p>
-18:33 <@nop> if you hold on a sec</p>
-18:34 <@hezekiah> Holding ... :)</p>
-18:34 <@nop> I'll call thecrypto at his house</p>
-18:34 <@nop> see if he can get on</p>
-18:34 < jrand0m> hehe word</p>
-18:34 <@hezekiah> lol</p>
-18:34  * hezekiah dons a thick Itallian accent</p>
-18:34 <@hezekiah> Nop ha' got ... CONNECTIONS!</p>
-18:34 < jeremiah> lo</p>
-18:34 <@nop> hey jeremiah</p>
-18:35 < jrand0m> heya jeremiah</p>
-18:35 <@nop> would you be willing at the api level to assist with a python api</p>
-18:35 < jeremiah> sure</p>
-18:35  * jeremiah reads backlog</p>
-18:35 < jrand0m> heh word</p>
-18:35  * nop is calling</p>
-18:36 <@nop> he's not home</p>
-18:36 <@nop> he'll be back in an hour</p>
-18:36 < jrand0m> 'k, has anyone else read the .xls and/or have comments on</p>
-	 the model?</p>
-18:37 <@hezekiah> I read the .xls ... but I don't know much about p2p so</p>
-	 most of it was over my head.</p>
-18:37 <@hezekiah> UserX is good at that stuff.</p>
-18:37 <@nop> I have to read it still</p>
-18:37 < jrand0m> (btw, morphmix had some insane numbers... they were saying</p>
-	 they could expect random hosts on the net to have average 20-150ms ping times,</p>
-	 rather than the 3-500 I was expecting)</p>
-18:37 < jrand0m> coo'</p>
-18:37 <@nop> it's staroffice or openoffice?</p>
-18:37 < jrand0m> openoffice, but I exported it to .xls</p>
-18:37 <@nop> which is excell?</p>
-18:37 < jrand0m> correct</p>
-18:38 <@hezekiah> BTW, concerning the API ...</p>
-18:38 < jrand0m> si sr?</p>
-18:38 <@hezekiah> ... in C the boolean would be int.</p>
-18:38 <@nop> which email</p>
-18:38 <@nop> hezekiah: yes</p>
-18:38 <@hezekiah> The classes would be sent as structure pointers.</p>
-18:38 <@nop> unless you typedef boolean</p>
-18:39 <@hezekiah> And the functions that use byte[] would use a void* with</p>
-	 an additional parameter that specefies the length of the buffer.</p>
-18:39 <@nop> hezekiah: you're being picky :)</p>
-18:39 < jrand0m> nop> I cant access the archives so I'm not sure what the</p>
-	 subject line was, but it was last week...</p>
-18:39 <@nop> save it for a later time</p>
-18:39 <@hezekiah> nop: Picky?</p>
-18:39 < jrand0m> heh, yeah, y'all working on the C api can work that detail out</p>
-18:39  * jeremiah is done reading backlog</p>
-18:39 <@nop> what's the file called</p>
-18:39 <@hezekiah> nop: I'm just trying to find all the stuff that is different,</p>
-	 so we can hammer it out like jrand0m asked.</p>
-18:40 <@hezekiah> I'm trying to be helpful. :)</p>
-18:40 <@nop> hezekiah: yes, probably off meeting time</p>
-18:40 < jrand0m> nop> simple_latency.xls</p>
-18:40 <@hezekiah> boolean sendMessage(Destination dest, byte[] payload);</p>
-18:40 <@hezekiah>  would be</p>
-18:40 <@hezekiah> int sendMessage(Destination dest, void* payload, int length);</p>
-18:40 <@hezekiah> .</p>
-18:40 <@hezekiah> byte[]  recieveMessage(int msgId);</p>
-18:40 <@hezekiah>  that could either be:</p>
-18:41 <@hezekiah> void*  recieveMessage(int msgId, int* length);</p>
-18:41 <@hezekiah>  or</p>
-18:41 <@nop> jrand0m: got it</p>
-18:41 <@hezekiah> void recieveMessage(int msgId, void* buf, int* length);</p>
-18:41 <@hezekiah>  or</p>
-18:41 < jrand0m> hezekia: why not typedef struct { int length; void* data;</p>
-	 } Payload;</p>
-18:41 <@hezekiah> DataBlock* recieveMessage(int msgId)l</p>
-18:41 <@hezekiah> DataBlock* recieveMessage(int msgId);</p>
-18:41 < jeremiah> where's this xls?</p>
-18:41 <@nop> oh iip-dev</p>
-18:41 <@hezekiah> jrand0m: The struct you just mentioned is basically what</p>
-	 DataBlock is.</p>
-18:42 < jrand0m> word hezekiah</p>
-18:42 <@nop> subject more models</p>
-18:42 <@hezekiah> Chances are the C version would have DataBlocks.</p>
-18:43 <@hezekiah> Beyond that the only other thing to note is that each</p>
-	 'interface' would just be a set of functions.</p>
-18:43 <@hezekiah> nop: Did I find all the differences that would exist in</p>
-	 a C API?</p>
-18:43 < jrand0m> right.  perhaps #include "i2psession.h" or something</p>
-18:43 < jeremiah> is there a mockup python api?</p>
-18:44 < jrand0m> no jeremiah, I don't really know python :/</p>
-18:44 <@nop> I would have to re-review the java api, but I would say that</p>
-	 you're right on target</p>
-18:44 < jrand0m> but it would probably be similar to the java, as python is OO</p>
-18:44 < jeremiah> cool, i can derive one from the C one</p>
-18:44  * nop is not a java head</p>
-18:44 < jrand0m> cool jeremiah</p>
-18:44 < jeremiah> is the c api in the thing you sent out a few days ago?</p>
-18:44 <@hezekiah> Yeah. Python should be able to handle the Java api.</p>
-18:44 < jrand0m> jeremiah> that was the Java one</p>
-18:45 < jrand0m> oh, the Java one was today</p>
-18:45 < jrand0m> the older one was language independent</p>
-18:45 <@hezekiah> Hmm</p>
-18:45 <@nop> UserX says he should be able to assist with C api</p>
-18:45 < jrand0m> word</p>
-18:45 <@nop> he's busy at work at the moment</p>
-18:46 < jrand0m> coo'</p>
-18:46 <@hezekiah> One last note: With the C api, each function would probably</p>
-	 take a structure* to the structure that it is an 'interface' of in Java.</p>
-18:46 <@nop> hezekiah: loos good</p>
-18:46 <@nop> looks good</p>
-18:46 <@hezekiah> I2PSession       createSession(String keyFileToLoadFrom,</p>
-	 Properties options);</p>
-18:46 <@hezekiah>  would be:</p>
-18:46 <@nop> java and their non-native data types</p>
-18:46 <@hezekiah> I2PSession* createSession(I2PClient* client, char*</p>
-	 keyFileToLoadFrom, Properties* options);</p>
-18:46 <@nop> ;)</p>
-18:46 < jrand0m> hehe</p>
-18:46 < jrand0m> right hezekiah</p>
-18:47 < jeremiah> are we addressing unicode?</p>
-18:47 <@hezekiah> Anyway, if you can live with those differences, the C and</p>
-	 Java API's should be identical beyond that.</p>
-18:47 <@hezekiah> nop? Unicode? :)</p>
-18:47 < jrand0m> UTF8 if not UTF16</p>
-18:48 <@hezekiah> Perhaps Unicode should be dealt with on the application</p>
-	 level.</p>
-18:48 < jrand0m> right, charset is all the content of the message</p>
-18:48 <@hezekiah> Oh.</p>
-18:48 < jeremiah> ok</p>
-18:48 <@hezekiah> Java String's are done in Unicode, aren't they jrand0m?</p>
-18:48 < jrand0m> the bitbuckets'll all be bit defined</p>
-18:48 < jrand0m> yes hezekiah</p>
-18:48 < jrand0m> (unless you explicitly instruct them to change charsets)</p>
-18:49 <@hezekiah> So the string sent to the Java API would be different than</p>
-	 the one sent to the C API unless the C API implements strings using Unicode.</p>
-18:49 < jrand0m> not relevent</p>
-18:49 <@hezekiah> OK.</p>
-18:49 < jrand0m> (app->API != API->router.  we only define API->router)</p>
-18:49 <@hezekiah> What I'm saying is this, jrand0m:</p>
-18:50 <@hezekiah> If I set my password with the Java API, it goes to the</p>
-	 router out someplace else.</p>
-18:50 < jrand0m> password?  you mean you create a Destination?</p>
-18:50 <@hezekiah> Then it find another router, which sends it to another API</p>
-	 (?) which is implemented in C.</p>
-18:50 <@hezekiah>   void            setPassphrase(String old, String new);</p>
-18:50 <@hezekiah> That function.</p>
-18:51 < jrand0m> hezekiah> thats the administrative password to access the</p>
-	 administrative methods of the router</p>
-18:51 <@hezekiah> Ah</p>
-18:51 <@hezekiah> Do any functions in the API which use Java String's end</p>
-	 up with that String being sent to another API?</p>
-18:51 < jrand0m> 99.9% of apps will only use I2PSession, not I2PAdminSession</p>
-18:51 <@nop> also, anything carried with the router gets converted for</p>
-	 network travel correct?</p>
-18:51 <@hezekiah> If so, we should probably use Unicode.</p>
-18:51 <@nop> unicode wouldn't be releavant</p>
-18:52 < jrand0m> hezekiah> no.  all inter-router info will be defined by</p>
-	 bit buckets</p>
-18:52 <@hezekiah> OK.</p>
-18:52 < jrand0m> correct nop, at the transport level</p>
-18:52 <@hezekiah> (I'm assuming a bit bucket is just a binary buffer, right?)</p>
-18:53 < jrand0m> a bit bucket is a statement that the first bit means X,</p>
-	 the second bit means Y, bits 3-42 mean Z, etc</p>
-18:53 < jrand0m> (e.g. we may want to use X.509 for the certificates bitbucket)</p>
+--- 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.</p>
-18:54 <@hezekiah> I'll worry about it when I get there. :)</p>
-18:54 < jrand0m> heh word</p>
-18:55 < jrand0m> ok, the four things I wanted us to hit today: *router</p>
-	 architecture, *performance model, *attack analysis, *psyc.  We've done</p>
-	 the first, thecrypto is offline so perhaps we delay this (unless you have</p>
-	 thoughts on the model nop?)</p>
-18:57 <@hezekiah> Um ... jrand0m. I have yet another question.</p>
-18:57 < jeremiah> jrand0m: where's the latest version of the network spec? is</p>
-	 it what you sent out on the 13th?</p>
-18:57 < jrand0m> si sr?</p>
-18:57 <@hezekiah> Well the router architecture has the API's handle keys</p>
-	 /sent to them by the Application/.</p>
-18:57 < jrand0m> jeremiah> yes</p>
-18:57 <@nop> I don't at this time</p>
-18:58 <@hezekiah> Now ... the only way I see that the API gets the key is</p>
-	 from createSession.</p>
-18:58 < jrand0m> hezekiah> the router  gets public keys and signatures,</p>
-	 not private keys</p>
-18:58 < jrand0m> right</p>
-18:58 <@hezekiah> But that requires a file.</p>
-18:58 < jrand0m> the keys are stored in a file or in the API's memory</p>
-18:58 < jrand0m> yes</p>
-18:58 <@hezekiah> Now if the application generates a key, why can't it just</p>
-	 send it to the API via a buffer?</p>
-18:59 <@hezekiah> Must it really store it in a file, and then provide the</p>
-	 file name?</p>
-18:59 < jrand0m> no, it can be in memory if you'd like</p>
-18:59 <@hezekiah> There is not function to all that in the API though.</p>
-18:59 <@hezekiah> It's just a thought.</p>
-19:00 <@hezekiah> If the key is supposed to be generated only once and used</p>
-	 many, many times (like GPG keys), then a file makes sense.</p>
-19:00 -!- mihi [none@anon.iip] has quit [bye all, it's getting late...]</p>
-19:00 <@hezekiah> But if it will be generated more often, then perhaps some</p>
-	 way to directly send it to the API via a structure or buffer of some sort</p>
-	 might be nice</p>
-19:00 <@hezekiah> .</p>
-19:01 < jrand0m> yes, its generated once and only once (unless you're wearing</p>
-	 a tinfoil hat)</p>
-19:02 < jrand0m> though the createDestination(keyFileToSaveTo) lets you</p>
-	 create that key</p>
-19:02 <@hezekiah> OK.</p>
-19:02 <@hezekiah> So there's really no need for transfer directly from the</p>
-	 App to the API. A file will suffice.</p>
-19:03 <@hezekiah> So where were we before I so rudely interupted? :)</p>
-19:06 < jeremiah> so right now we're just working on the router API, not</p>
-	 the client one, right?</p>
-19:06 < jrand0m> well, we're skipping on performance analysis for now</p>
-	 (hopefully we can get some chatter re: it on the mailing list before next</p>
-	 week?).  and probably the same wrt attack analysis (unless anyone read the</p>
-	 new spec and has comments)</p>
-19:07 <@hezekiah> So we're since we're skipping that, what are we supposed</p>
-	 to be talking about now?</p>
-19:07 <@hezekiah> Psyc?</p>
-19:07 < jrand0m> unless anyone else has other comments to bring up...?</p>
-19:08 <@hezekiah> Well, for once, my comment hole (also notoriously known</p>
-	 as my mouth) is empty.</p>
-19:08 < jrand0m> hehe</p>
-19:09 < jrand0m> ok, anyone have any thoughts on how the IRC side of things</p>
-	 will work, and whether psyc may be relevent or useful?</p>
-19:09 < jeremiah> sidenote (that pissed me off): wired's "Wired, Tired,</p>
-	 Expired" list had Waste as 'wired'</p>
-19:09 < jrand0m> heh</p>
-19:09 < jrand0m> do you realize how much we're going to blow everyone away?</p>
-19:09 < jeremiah> yep</p>
-19:09 <@hezekiah> jrand0m: That assumes we get this to work.</p>
-19:10 < jrand0m> I guarantee it will work.</p>
-19:10 <@hezekiah> There are a lot of other failed efforts out there.</p>
-19:10 < jrand0m> I quit my job to work on this.</p>
-19:10 <@hezekiah> Then we're going to blow everyone away. :)</p>
-19:10 <@hezekiah> Yeah. How is bread getting on the table when you do that?</p>
-19:10 <@hezekiah> GPL code doesn't pay well. ;-)</p>
-19:10 < jrand0m> heh</p>
-19:11 <@hezekiah> As for psyc ... let me put it this way:</p>
-19:11 <@hezekiah> The first time I heard of it was when you emailed us</p>
-	 about it.</p>
-19:11 < jrand0m> shit, I wasn't the one who found it :)</p>
-19:11 <@hezekiah> However, IRC is probably one of the most (if not /the/</p>
-	 most) prolific chat protocols around.</p>
-19:11 <@hezekiah> People will want IRC apps LONG before they even /know/</p>
-	 what psyc is.</p>
-19:11 <@hezekiah> jrand0m: Oops. Sorry. I forgot that detail. :)</p>
-19:12 < jrand0m> not according to psyc.  their history goes back to 86 I think</p>
-19:12 <@hezekiah> The point is that the supperiority of the protocol, isn't</p>
-	 really as relevant as to who uses it.</p>
-19:12 <@hezekiah> Their _history_ may go back that far.</p>
-19:12 <@hezekiah> But how many people _use_ Psyc?</p>
-19:12 < jeremiah> yeah if they've been around since a year after I was born</p>
-	 (ahem) and they aren't that big yet</p>
-19:12 <@hezekiah> My point is that even if it's a better protocol, most</p>
-	 people _use_ IRC.</p>
-19:13 <@hezekiah> We can make the best I2P network on the planet ...</p>
-19:13 -!- Ehud [logger@anon.iip] has quit [Ping timeout]</p>
-19:14 < jeremiah> can someone explain briefly why we care? I thought IRC</p>
-	 would only be one possible application but that the network is flexible to</p>
-	 support psyc as well if it wanted to</p>
-19:14 <@hezekiah> Right.</p>
-19:14 <@hezekiah> Psyc can be made ...</p>
-19:14 <@hezekiah> ... but I'm saying we should do IRC first because more</p>
-	 people use it.</p>
+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</p>
-	 use it unless it has something they want.</p>
-19:14 < jrand0m> jeremiah> the reason psyc is interesting is that we may</p>
-	 want to implement IRC in the same vein that psyc works</p>
-19:15 <@hezekiah> Hence we should provide them with a 'killer-app'.</p>
-19:15 < jeremiah> ok</p>
-19:15 < jrand0m> right, IIP is invisible IRC project, and will allow people</p>
-	 to run IRC</p>
-19:16 < jrand0m> with no central server (or any server at all, actually),</p>
-	 theres a lot of thinking to be done to figure out how IRC will work.</p>
-	 psyc has a possible answer to that</p>
-19:16 < jrand0m> though there are others</p>
-19:17 <@hezekiah> As I said, psyc might do better, but people want to use IRC,</p>
-	 not psyc.</p>
-19:17 < jrand0m> and they will</p>
-19:17 < jrand0m> they'll use irc</p>
-19:17 <@hezekiah> It's all about marketing, baby! ;-)</p>
-19:17 < jeremiah> I'll try to read the spec and some stuff on psyc tonight</p>
-19:17 < jrand0m> word</p>
-19:17 <@hezekiah> lol</p>
-19:17 < jeremiah> planning to meet at 5:00 UTC tommorow?</p>
-19:17 <@hezekiah> No?</p>
-19:18 < jeremiah> or whenever</p>
-19:18 < jrand0m> I'm on iip 24x7 :)</p>
-19:18 < jeremiah> yeah but i eat</p>
-19:18 <@hezekiah> jrand0m: I noticed.</p>
-19:18 < jrand0m> 05:00 utc or 17:00 utc?</p>
-19:18 <@hezekiah> jeremiah: LOL!</p>
-19:18 <@hezekiah> Well the iip-dev meeting officially starts at 21:00 UTC.</p>
-19:18 -!- Ehud [~logger@anon.iip] has joined #iip-dev</p>
-19:19 < jeremiah> ok, i just said 05:00 UTC because I was talking out of my ass</p>
-19:19 < jeremiah> where's mids?</p>
-19:19 <@hezekiah> mids, left the project for a while.</p>
-19:19 <@hezekiah> Weren't you there a few meetings back?</p>
-19:19 < jeremiah> ok</p>
-19:19 < jeremiah> guess not</p>
-19:19 <@hezekiah> We had a goodbye party of sorts as part of the agenda.</p>
-19:19 < jeremiah> oh</p>
-19:20 <@hezekiah> OK ...</p>
-19:20 <@hezekiah> Is there anything still on the agenda?</p>
-19:20  * jrand0m doesn't have any left on mine</p>
-19:20 < jeremiah> about psyc:</p>
-19:20 < jeremiah> if this is a psyc feature, I know you mentioned it a</p>
-	 while ago</p>
-19:20  * hezekiah never had an agenda in the first placve</p>
-19:21 <@hezekiah> pace</p>
-19:21 <@hezekiah> place</p>
-19:21 < jeremiah> I don't think having each user send a message to every</p>
-	 other use in the room is s smart idea</p>
-19:21 <@hezekiah> There!</p>
-19:21 < jrand0m> jeremiah> so you'd have redundant nominated pseudoservers</p>
-	 redistribute the messages?</p>
-19:21 < jrand0m> (pseudoservers = peers in the channel who have the list</p>
-	 of users)</p>
-19:21 < jeremiah> I don't think 'broadcasting' is that smart either, but it</p>
+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</p>
-	 a modem, and with the lag from sending say... 20 messages separately would</p>
-	 screw up conversation</p>
-19:21 < jeremiah> I don't know the best solution, maybe that would be one</p>
-19:22 < jeremiah> I think direct messaging would be good if you wanted it,</p>
-	 but there are cases where it's probalby not that important</p>
-19:22 <@hezekiah> The message would need to be signed by the authors private</p>
-	 key to garuntee authenticity.</p>
-19:22 <@hezekiah> Though this issue won't matter for a long time still,</p>
-	 I think jeremiah has a point</p>
-19:22 < jrand0m> hezekiah> that requires users wanting provable comm :)</p>
-19:23 < jrand0m> definitely.</p>
-19:23 <@hezekiah> If I had to send a message to 100 users in a channel ...</p>
-19:23 < jeremiah> although my average message is only a few hundred bytes,</p>
-	 so sending it to hundreds of users might not be so hard</p>
-19:23 <@hezekiah> ... well, my conversation would be /very/ slow.</p>
-19:23 < jeremiah> especially if you didn't wait for a response</p>
-19:23 <@hezekiah> 20K to send one message.</p>
-19:23 <@hezekiah> I don't think so. :)</p>
-19:23 < jrand0m> well, if there are 100 users in a channel, *someone* has</p>
-	 to send out 100 messages</p>
-19:23 < jeremiah> it's 20k?</p>
-19:23 < jeremiah> oh, right</p>
-19:23 <@hezekiah> 200 users</p>
-19:24 < jeremiah> hmm</p>
-19:24 < jeremiah> wouldn't the routers be good at that?</p>
-19:24 < jeremiah> we can somewhat safely assume they have decent bandwith,</p>
-	 right?</p>
-19:24 <@hezekiah> I thought each person had a 'router implementation'</p>
-19:24 < jrand0m> not really.  if there are relays, the nomination mechanism</p>
-	 needs to take that into consideration</p>
-19:24 < jrand0m> yes hezekiah</p>
-19:24 < jeremiah> i haven't read the spec</p>
-19:25 < jrand0m> a router is your local router</p>
-19:25 <@hezekiah> Ugh!</p>
-19:25 <@hezekiah> I'm still mixing your nicks up!</p>
-19:25 <@hezekiah> lol</p>
-19:25 < jrand0m> hehe</p>
-19:25 <@hezekiah> Um ... where'd nop go?</p>
-19:25 <@hezekiah> Oh.</p>
-19:26 <@hezekiah> He's still here.</p>
-19:26 <@hezekiah> I thought he was gone for a moment,</p>
-19:26 < jrand0m> but jeremiah is right, psyc has some ideas we may want to</p>
-	 consider, though we may want to reject them</p>
-19:26 <@hezekiah> Let's just get the network running first.</p>
-19:26  * jrand0m drinks to that</p>
-19:26 <@hezekiah> If you strech your vision to the finish line, you'll trip</p>
-	 over the rock 3 inches in front of you.</p>
-19:27  * jeremiah feels inspired</p>
-19:27 <@hezekiah> lol</p>
-19:27 < jrand0m> I think what would be really great if we could aim to review</p>
-	 the network spec by next week, sending out emails to iip-dev whenever anyone</p>
-	 has thoughts or comments.  am I out of my mind?</p>
-19:27 <@hezekiah> nop? Do you have anything else to add to the agenda,</p>
-	 or do we adjurn?</p>
-19:27 <@hezekiah> jrand0m: Well, I don't know if I could read all that by</p>
-	 next week, but I can try. :)</p>
-19:27 < jrand0m> heh</p>
-19:28 < jrand0m> its a grueling 15 pages ;)</p>
-19:28 <@hezekiah> 15 pages?</p>
-19:28 <@hezekiah> It looked more like 120!</p>
-19:29 < jrand0m> heh, well, depends on your resolution I suppose ;)</p>
-19:29 < jeremiah> he has a lot of anchors in there, makes it look like</p>
-	 it's huge</p>
-19:29 < jrand0m> hehe</p>
-19:29 <@hezekiah> The left side has a LOT more than 15 links, budy!</p>
-19:29 <@hezekiah> 'Fess up!</p>
-19:29 <@hezekiah> It's more than 15. :)</p>
-19:29 <@hezekiah> Oh!</p>
-19:29 <@hezekiah> Those aren't pages! They're just anchors!</p>
-19:29 <@hezekiah> I'm saved!</p>
-19:30  * hezekiah feels like a seaman just rescued from drowning</p>
-19:30 < jeremiah> class turn to volume 4 chapter 2 Message Byte Structure</p>
-19:30 < jrand0m> lol</p>
-19:30 <@hezekiah> lol</p>
-19:30 <@nop> adjourn</p>
-19:30 <@hezekiah> *baf*!</p>
-19:30 <@hezekiah> Next week, 21:00 UTC, same place.</p>
-19:30 <@hezekiah> See y'all there. :)</p>
-19:30 < jeremiah> seeya</p>
---- Log closed Tue Jul 15 19:30:51 2003</p>
-</div>
-{% endblock %}
\ No newline at end of file
+	 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/49.rst b/i2p2www/meetings/49.rst
new file mode 100644
index 00000000..32f526eb
--- /dev/null
+++ b/i2p2www/meetings/49.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 15, 2003 @ 21:46 UTC
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/50.log b/i2p2www/meetings/50.log
index 4b74dce0..2d07e192 100644
--- a/i2p2www/meetings/50.log
+++ b/i2p2www/meetings/50.log
@@ -1,597 +1,594 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 50{% endblock %}
-{% block content %}<div class="irclog">--- Log opened Tue Jul 22 15:56:06 2003</p>
-15:56 <@hezekiah> jrand0m: Righto!</p>
-15:56 -!- mode/#iip-dev [+o jrand0m] by hezekiah</p>
-15:56 <@cohesion> log enabled</p>
-15:56 <@jrand0m> w00t</p>
-15:56 <@nop> we need to add cohesion and remove mids on dev list</p>
-15:56 <@hezekiah> Excelent. :)</p>
-15:56 <@hezekiah> What dev list?</p>
-15:56 <@cohesion> nop: i tried CVS and it wouldn't accept my user/pass</p>
-15:56 <@nop> ok, I'll add you</p>
-15:56 <@nop> hold</p>
-15:56 <@nop> what is your sf id</p>
-15:56 <@cohesion> cohesion</p>
-15:56 <@nop> pmsg me if you need</p>
-15:56 <@nop> ok</p>
-15:57 <@cohesion> i think</p>
-15:57 -!- thecrypto [thecrypto@anon.iip] has joined #iip-dev</p>
-15:57 <@hezekiah> BTW, everyone I will be leaving around 22:15.</p>
-15:57 <@hezekiah> UTC</p>
-15:57 <@cohesion> yea</p>
-15:57 <@cohesion> hezekiah: okay</p>
-15:58 <@nop> cohesion: you're in</p>
-15:58 <@nop> we need to update website</p>
-15:58 <@cohesion> nop: okay</p>
-15:58 <@cohesion> nop: i'll try it now</p>
-15:58 <@nop> and we need to start modelling the IIP with an I2P</p>
-15:58 < thecrypto> hey</p>
-15:58 < thecrypto> i made it</p>
-15:58 <@nop> ok</p>
-15:58 <@nop> werd</p>
-15:58 <@nop> ;)</p>
-16:00 <@hezekiah> jrand0m? I just looked at your revision to the</p>
-development schedual.</p>
-16:00 <@jrand0m> si sr?</p>
-16:00 <@hezekiah> The graph with the bars and lines gets chopped off at</p>
-the right hand side; I can't see the rest of it.</p>
-16:01 <@jrand0m> yeah, ganttproject isn't quite perfect, but its better</p>
-than doing it by hand.</p>
-16:01 <@jrand0m> the things at the far right are the last tasks -</p>
-nothing is after them</p>
-16:01 <@hezekiah> But I can</p>
-16:01 <@jrand0m> the tasks there are listed, in order, on the</p>
-index-tasks.html</p>
-16:01 <@hezekiah> can't even see what the tasks are.</p>
-16:02 <@hezekiah> OK. :) I'll just have to settle for text.</p>
-16:02 <@hezekiah> nop: Are we going to start soon? I'm going to have to</p>
-leave at 22:15 UTC, but I'd like to catch as much of the meeting as</p>
-possible.</p>
-16:02 <@jrand0m> let me see if I can make a big task to fix that...</p>
-16:02 <@hezekiah> jrand0m: Thanks. :)</p>
-16:03 <@nop> yes</p>
-16:03 <@nop> alright</p>
-16:03 <@nop> agenda</p>
-16:03 <@nop> 1)</p>
-16:03 <@nop> welcome</p>
-16:03 <@nop> 2)</p>
-16:03 <@nop> Website future</p>
-16:03 <@nop> 3)</p>
-16:03 <@nop> bug fixes with 1.1</p>
-16:03 <@nop> 4)</p>
-16:03 <@nop> I2P</p>
-16:03 <@nop> 5)</p>
-16:03 <@nop> Suggestions and comments</p>
-16:03 <@nop> welcome all</p>
-16:04 <@nop> moving to 2</p>
-16:04 <@nop> website</p>
-16:04 <@nop> cohesion, are your maintanance website skills up to par?</p>
-16:04 <@cohesion> aye</p>
-16:04 <@cohesion> XHTML and CSS are my specialties</p>
-16:04 <@nop> ok, we are assuming you can do website stuff, changes etc</p>
-16:04 <@nop> ok</p>
-16:04 <@cohesion> yep</p>
-16:05 <@cohesion> granted that i can get CVS to cooperate :)</p>
-16:05 <@nop> easy</p>
-16:05 <@nop> export CVS_RSH=ssh</p>
-16:05 <@nop> and don't use pserver</p>
-16:05 <@nop> use d:ext</p>
-16:05 <@cohesion> i'm using gruntspud to CVS interfacing</p>
-16:05 <@nop> ok</p>
-16:05 <@cohesion> it's part of my text editor</p>
-16:05 <@cohesion> it should work</p>
-16:05 <@cohesion> we can talk about that later though</p>
-16:05 <@cohesion> i'm trying it now</p>
-16:05 -!- thecrypto [thecrypto@anon.iip] has quit [Ping timeout]</p>
-16:05 <@nop> if you have issues let me know right away if you can, so I</p>
-can assist this because I have a bunch of tasks</p>
-16:06 <@nop> also</p>
-16:06 <@nop> we need to look at making an I2P section</p>
-16:06 <@nop> since it's going to be the next big project</p>
-16:06 <@nop> I'll talk to ellison to see if he's contribute a bit of his</p>
-web design skills to add to that for a template</p>
-16:06 <@hezekiah> Should I2P be a section of invisiblenet.net or</p>
-invisiblenet.net/iip? (I vote for the former.)</p>
-16:06 <@nop> and we can get that hashed out</p>
-16:06 <@cohesion> ok</p>
-16:06 <@nop> former as well</p>
-16:06 <@jrand0m> former</p>
-16:06 <@nop> it would be under projects</p>
-16:07 -!- thecrypto [~thecrypto@anon.iip] has joined #iip-dev</p>
-16:07 <@nop> iip is one project</p>
-16:07 <@nop> i2p is another</p>
-16:07 <@hezekiah> So, invisiblenet.net/i2p</p>
-16:07 <@nop> yes</p>
-16:07 <@hezekiah> Right. That's the way I see it too. :)</p>
-16:07 <@nop> anyone here good at making a logo?</p>
-16:07 <@nop> volunteers are welcome</p>
-16:07 <@nop> just submit to iip-dev list</p>
-16:07 <@nop> ok moving on</p>
-16:07 <@nop> bug fixes in 1.1</p>
-16:07 <@jrand0m> h/o</p>
-16:07 * hezekiah would like to point out that his skills at the GIMP are</p>
-to be avoided like WMD.</p>
-16:08 <@jrand0m> would it be possible to keep the i2p stuff off the web</p>
-until we're ready for beta?</p>
-16:08 <@cohesion> i suggest we use the wiki for collaborating on the i2p</p>
-documents</p>
-16:08 <@nop> yes</p>
-16:08 <@cohesion> i can set up a restricted area</p>
-16:08 <@nop> that's possible</p>
-16:08 <@hezekiah> jrand0m: Are you thinking of a big smash announcement</p>
-on /. or something once we have it in good order?</p>
-16:08 <@nop> cohesion: I concur</p>
-16:08 <@jrand0m> yes hezekiah</p>
-16:08 <@jrand0m> word cohesion</p>
-16:09 <@nop> ok</p>
-16:09 <@nop> let's look at 1.1 for a sec</p>
-16:09 <@nop> hezekiah you made a discovery, that has not to do with</p>
-focus?</p>
-16:09 <@nop> or what?</p>
-16:10 <@hezekiah> The code is fine.</p>
-16:10 <@hezekiah> The problem is communication, not code.</p>
-16:10 <@hezekiah> The user has to move the mouse aroung _inside_ the</p>
-dialog box.</p>
-16:10 < mihi> the dialog lacks a progress bar to give feedback if the</p>
-user does it correctly</p>
-16:10 <@nop> yes that's true</p>
-16:10 <@hezekiah> He can move the mouse around _outside_ the dialog box</p>
-until he's blue in the face, but it won't gather entropy. (Which is what</p>
-these users are doing.)</p>
-16:10 <@nop> it does lack a dialog box</p>
-16:11 <@hezekiah> A progress bar would be a plus.</p>
-16:11 <@hezekiah> And should be somewhat easy to implement ... if I</p>
-could understand the tangle that UI code in IIP is.</p>
-16:11 <@cohesion> or even some feedback</p>
-16:11 <@hezekiah> Anyway, I posted my suggestions to the mailing list.</p>
-16:12 <@nop> it's in win32 api</p>
-16:12 <@nop> ;)</p>
-16:12 <@hezekiah> Either capture the mouse (I couldn't get M$ to</p>
-cooperate to do that), or make the dialog box message explain to the</p>
-user he needs to move the mouse around _inside_ the dialog box.</p>
-16:12 <@hezekiah> nop: I know.</p>
-16:12 <@nop> fine hezekiah be that way :)</p>
-16:12 <@hezekiah> What?</p>
-16:12 <@hezekiah> What did I do?</p>
-16:12 * hezekiah is confused</p>
-16:12 < thecrypto> how about just maximize the dialog box?</p>
-16:12 <@nop> hezekiah: I'm just messin' with ya</p>
-16:13 <@hezekiah> nop: OK. :)</p>
-16:13 <@hezekiah> Where's UserX? He knows more about the IIP UI code</p>
-than I do.</p>
-16:14 <@hezekiah> thecrypto: As for maximizing, well, the user might not</p>
-like a rabid dialog box consuming his entire screen.</p>
-16:14 <@hezekiah> Mouse capture is ideal, but as I said, I couldn't get</p>
-M$ to do it.</p>
-16:14 <@jrand0m> many other apps don't capture the mouse</p>
-16:14 <@jrand0m> a status bar plus explaination seems typical</p>
-16:15 <@hezekiah> Anyway, that's the 'bug'.</p>
-16:15 <@hezekiah> How do you want it fixed nop?</p>
-16:15 <@nop> well</p>
-16:15 <@nop> I would think if possible we could have a meter that shows</p>
-the entropy gathering for sure</p>
-16:16 <@hezekiah> OK.</p>
-16:16 <@nop> and definitely fixes the language. Have you exhausted the</p>
-research on capturing the mouse movements?</p>
-16:16 <@hezekiah> To the point of my patience.</p>
-16:16 <@hezekiah> Seriously, what I did _should_ work.</p>
-16:16 <@nop> I assume that's a lot?</p>
-16:16 <@hezekiah> Well, I didn't get much sleep last night.</p>
-16:17 <@nop> hmm</p>
-16:17 <@nop> let's try to get a meter bar and the language fixed</p>
-16:17 <@nop> that will give us an idea</p>
-16:17 <@hezekiah> Because it isn't working, I'm assuming the M$ docs are</p>
-lieing to me (very possible) or something 'unknown' is happening in the</p>
-IIP UI code.</p>
-16:17 <@nop> right</p>
-16:17 <@hezekiah> Righto. :)</p>
-16:17 * hezekiah now gets down on his knees and prays that UserX wrote</p>
-UI code for a progress bar.</p>
-16:19 <@nop> haha</p>
-16:19 <@nop> if not go to planet-source-code.com</p>
-16:19 <@nop> there's a lot of samples there</p>
-16:19 <@hezekiah> The win32 API I can manage (though I detest it.)</p>
-16:19 <@nop> I hate it as well</p>
-16:19 <@hezekiah> But UserX/whoever-originally-wrote-this made a wrapper</p>
-around it.</p>
-16:19 <@hezekiah> It's the wrapper I'm worried about.</p>
-16:19 * nop is coding in it right now for work</p>
-16:19 <@hezekiah> I'm looking into it now.</p>
-16:20 <@hezekiah> Let's move on to the next agenda item.</p>
-16:20 -!- jeremiah-gym is now known as jeremiah</p>
-16:20 <@nop> ok</p>
-16:20 <@nop> next item is i2p</p>
-16:20 < jeremiah> hi</p>
-16:20 <@nop> hi</p>
-16:20 <@nop> jrand0m you start</p>
-16:20 <@hezekiah> jeremiah: Just in time!</p>
-16:20 < jeremiah> hezekiah: nop and I are oddly time synced, as you'll</p>
-learn</p>
-16:20 <@jrand0m> 'k, has everyone had a chance to check out the roadmap?</p>
-16:21 <@hezekiah> Yeah.</p>
-16:21 <@jrand0m> its obviously draft, and things after the 1.0 milestone</p>
-are largely up in the air, but its something to start from</p>
-16:21 <@jrand0m> I've updated it beyond whats on the list to include</p>
-hezekiah jumping on the C api (w00t!)</p>
-16:22 -!- jeet [~miteymous@anon.iip] has joined #iip-dev</p>
-16:22 <@jrand0m> basically, after this coming friday, we'll have the API</p>
-protocol spec'ed out, which will mean we can parallelize a lot</p>
-16:22 < jeet> hello ;)</p>
-16:22 <@jrand0m> 'lo jeet</p>
-16:23 < jeet> hey if i make a server is it possible to change anon.iip</p>
-to whatever i want</p>
-16:23 <@jrand0m> rough gut question: how insane does the r2 roadmap</p>
-sound? are schedules insane, are there things missing, are things in the</p>
-wrong order or dependencies not represented?</p>
-16:23 <@nop> yes</p>
-16:23 < jeet> kewl</p>
-16:24 <@hezekiah> jrand0m: I would concur the entire thing is insane.</p>
-However, I think (until I get to college) it should be doable.</p>
-16:24 <@jrand0m> heh</p>
-16:24 < jeet> this is a very cool thing you guys have done ;X</p>
-16:24 <@hezekiah> Though I'm not sure nop and UserX can design that IRC</p>
-protocol even in 21 days.</p>
-16:24 <@hezekiah> nop: ;-)</p>
-16:24 <@nop> no</p>
-16:24 <@jrand0m> ok, you're off to uni in late august? mid august? when</p>
-should we pencil you in for less activity?</p>
-16:24 <@hezekiah> Around August 20th I'm of.</p>
-16:24 <@hezekiah> off.</p>
-16:25 <@jrand0m> 'k</p>
-16:25 <@hezekiah> Until then I'm a rabid nermal! :)</p>
-16:25 < jeremiah> I'm off about the same time</p>
-16:25 < jeremiah> (to univ)</p>
-16:26 <@nop> ok</p>
-16:26 <@jrand0m> so we'll have to get more resources on the 'implement</p>
-IRC' task or just drop the task from the 1.0 release</p>
-16:26 <@hezekiah> I wouldn</p>
-16:26 <@hezekiah> wouldn't make the 1.0 release dependant on IRC.</p>
-16:26 <@nop> I believe that we will need to delay the task</p>
-16:26 < jeet> [17:23] -anon.iip- CTCP (except ACTION) and DCC are</p>
-disabled <- how can i stop this from poppiing up every 3 minutes?</p>
-16:26 <@hezekiah> Do the IRC, but let i2p 1.0 come out when it's ready.</p>
-16:27 < thecrypto> wow, i'm half way through college as two others just</p>
-start :)</p>
-16:27 <@jrand0m> lol</p>
-16:28 <@jrand0m> I concur hezekiah</p>
-16:28 <@hezekiah> Cool. I still think i2p will be it's own killer app.</p>
-:)</p>
-16:28 <@jrand0m> so that basically means all I2P 1.0 requires after</p>
-august is a month of debugging and documentation to go from alpha to</p>
-beta to 1.0</p>
-16:29 <@jrand0m> hezekiah> definitely. we need to get a demo app out on</p>
-it first - does the instant messenger app + file transfer sound good to</p>
-people for that?</p>
-16:29 -!- jeet [~miteymous@anon.iip] has quit [ircN 7.27 + 7.0 for mIRC</p>
-(2002/01/10 00.00)]</p>
-16:29 <@hezekiah> Well, you said it best: 'demo'. From my view, it</p>
-doesn't need to be special. It just needs to prove the network is worth</p>
-developing on.</p>
-16:30 <@hezekiah> So the IM client would be a good demo, in my opinion.</p>
-16:30 < Zwolly> file transfer is one thing i really would like to see so</p>
-gimme a demo</p>
-16:30 <@hezekiah> Zwolly: lol</p>
-16:30 <@nop> yes</p>
-16:30 < Zwolly> and see me as an "normal" user</p>
-16:31 <@hezekiah> Zwolly: You can be our guniea pig! ;-)</p>
-16:31 * hezekiah starts mixing poisinous code in his lab. ;-)</p>
-16:31 < Zwolly> hmmm yummie</p>
-16:32 <@jrand0m> ok, one last thing on i2p</p>
-16:32 <@nop> sure</p>
-16:33 <@jrand0m> nop> any chance we can get a non sourceforge trusted</p>
-cvs server?</p>
-16:34 <@jrand0m> sourceforge has more problems than these college</p>
-student's exams</p>
-16:34 <@nop> yes</p>
-16:34 <@nop> I will arrange that and have it up by next week</p>
-16:34 <@jrand0m> awesome. thanks</p>
-16:34 <@nop> also</p>
-16:34 <@nop> I may be able to get a compile farm</p>
-16:34 <@nop> that is not sf</p>
-16:34 <@nop> with vpn access to it</p>
-16:35 <@hezekiah> Compile farm!?</p>
-16:35 <@jrand0m> compile farm? bah, we can just run ant :)</p>
-16:35 <@hezekiah> jrand0m: All code is not Java.</p>
-16:35 <@hezekiah> I personally love compile farms.</p>
-16:35 <@hezekiah> :)</p>
-16:35 <@jrand0m> ant == make. it can run gcc / etc</p>
-16:35 <@nop> hezekiah: send me a list of viable platforms we'll need to</p>
-test on</p>
-16:35 <@jrand0m> 'k, if we really need the cpu power of a compile farm,</p>
-thats great</p>
-16:36 < wilde> what license are you planning to use?</p>
-16:36 <@nop> GPL</p>
-16:36 <@jrand0m> GPL cool with everyone for this?</p>
-16:36 < wilde> k nice</p>
-16:36 <@hezekiah> I'm very pro GPL.</p>
-16:36 <@hezekiah> But one warning</p>
-16:36 <@hezekiah> For the API's we will probably need LGPL. Otherwise</p>
-all programs made for this network MUST be GPL</p>
-16:36 <@jrand0m> we may want to go LGPL down the line</p>
-16:37 <@jrand0m> yeah</p>
-16:37 <@jrand0m> we MUST not require all apps using I2P to be GPL'ed</p>
-16:37 <@hezekiah> So the router should be GPL, but the API's will</p>
-probably need to be LGPL at some time.</p>
-16:37 <@hezekiah> jrand0m: Then we'll need an LGPL API.</p>
-16:37 <@hezekiah> The only problem that poses is getting a good crypto</p>
-kit for C that is compatible with LGPL.</p>
-16:38 <@hezekiah> I don't think Cryptlib's Sleepycat license is.</p>
-16:38 <@hezekiah> I could email the author and ask for an exception or</p>
-something if I need to when the time comes.</p>
-16:38 <@jrand0m> hezekiah> not need, want. the API comm layer will be an</p>
-open spec, so anyone can write their own and not link to any of our</p>
-libraries</p>
-16:38 <@hezekiah> Right.</p>
-16:38 <@nop> right</p>
-16:38 <@hezekiah> So for now we can even make GPL API's if we need to.</p>
-16:39 <@hezekiah> OK, one question for jrand0m:</p>
-16:39 < jeremiah> but we should try to have non-viral ones asap</p>
-16:39 <@hezekiah> I agree.</p>
-16:39 < wilde> http://www.virtualunlimited.com/products/beecrypt/</p>
-16:40 < wilde> Bee Crypt is LGPL, i've used once</p>
-16:40 <@hezekiah> wilde: Beecrypt is far beneath what is required</p>
-unfortunately.</p>
-16:40 <@nop> yes</p>
-16:40 <@nop> I don't think we should use a crypto lib like Beecrypt</p>
-16:40 <@jrand0m> word wilde</p>
-16:40 <@cohesion> hezekiah: there's tons of crypto code in</p>
-GnuPrivacyGuard that's all GPL'd</p>
-16:40 <@cohesion> you might check and see where it came from</p>
-16:40 <@hezekiah> cohesion: The problem is we'll need an LGPL C API that</p>
-uses Crypto.</p>
-16:41 <@hezekiah> I'll work it out when I get to it.</p>
-16:41 <@hezekiah> For now, I have two questions for jrand0m: (It's gone</p>
-up one!) :)</p>
-16:41 <@jrand0m> we have lots of options. we'll figure it out</p>
-16:41 <@jrand0m> heh fire away</p>
-16:42 <@hezekiah> 1.) When the client API spec is done on the 25th will</p>
-it detail the byte-by-byte structure of the messages sent over the</p>
-network, and will it detail the specifics on how the crypto is</p>
-implemented?</p>
-16:42 -!- ion [ion@anon.iip] has joined #iip-dev</p>
-16:42 <@jrand0m> yes</p>
-16:42 <@hezekiah> 2.) Will be we using Twofish? ;-)</p>
-16:43 <@jrand0m> no, prolly aes, unless someone has a really good reason</p>
-16:43 <@hezekiah> jrand0m: Was that yes to both questions, or just</p>
-question 1?</p>
-16:43 -!- nemesis [nemesis@anon.iip] has joined #iip-dev</p>
-16:43 <@hezekiah> OK.</p>
-16:43 <@jrand0m> hezekiah> yes to both</p>
-16:43 <@nop> well</p>
-16:43 < nemesis> uuuh, since when there are here ops? :)</p>
-16:43 <@hezekiah> I really like twofish, but unfortunately AES is easier</p>
-to find a good lib for.</p>
-16:44 <@nop> hold</p>
-16:44 <@hezekiah> nemesis: The English structure of that sentence was</p>
-too garbled for me to decipher? Whould you like to restate your</p>
-question?</p>
-16:44 <@jrand0m> whats special about twofish? why not go with the</p>
-advanced encryption Standard?</p>
-16:44 <@hezekiah> nop: Holding ... :)</p>
-16:44 * jrand0m holds</p>
-16:44 <@nop> I prefer that we have a suite of encryption options</p>
-16:44 <@nop> not just aes</p>
-16:44 <@nop> there are opinions about AES that some people do not feel</p>
-comfortable using</p>
-16:44 <@nop> and would rather go with Twofish etc</p>
-16:44 <@nop> so maybe we can have it be a selection</p>
-16:44 < wilde> do both :)</p>
-16:44 <@nop> yes</p>
-16:44 <@nop> wilde: exactly</p>
-16:45 <@jrand0m> nop> suites would mean not everyone can send messages</p>
-to everyone</p>
-16:45 < jeremiah> but then wouldn't each router have to support both?</p>
-that seems painful</p>
-16:45 <@jrand0m> doing both is definitely the case for transport layer,</p>
-where things can be negotiated</p>
-16:45 <@nop> not really</p>
-16:45 <@nop> I would not agree with AES then</p>
-16:45 <@nop> as if you are paranoid</p>
-16:45 <@hezekiah> Right. But let's try to too enclude things that are</p>
-weakening like 3DES.</p>
-16:45 <@hezekiah> A chain is only as strong as its weakest link.</p>
-16:45 <@nop> then you'll realize why</p>
-16:45 <@nop> with the US gov't approvals</p>
-16:46 <@jrand0m> I don't support AES because it has govt approval, I</p>
-support AES because it has cryptographers, scientists, and</p>
-mathematicians approvals.</p>
-16:46 <@jrand0m> if there is a better one, we can go with that.</p>
-16:46 <@jrand0m> but I don't want to go with something because its</p>
-different</p>
-16:46 <@nop> but the approval of twofish is strong as well amongst</p>
-cryptographers</p>
-16:46 <@hezekiah> Well, the last three AES candidates were Rijndael,</p>
-Twofish, and Serpent.</p>
-16:46 <@nop> exactly</p>
-16:47 <@hezekiah> Rijndael was the fastest.</p>
-16:47 <@hezekiah> Personally, I have more faith in Twofish than</p>
-Rijndael.</p>
-16:47 <@jrand0m> nop I think I heard you say there were problems with</p>
-serpent?</p>
-16:47 < wilde> use multiple layers of encryption if you have CPU for it</p>
-16:48 <@jrand0m> wilde> there will be, but thats on a different aspect</p>
-of things.</p>
-16:48 <@nop> all I'm saying is that we could have both supported</p>
-16:48 <@nop> doesn't hurt</p>
-16:48 <@jrand0m> actually it does hurt</p>
-16:48 <@jrand0m> segmentation attack</p>
-16:48 < wilde> ok twofish wrapped in AES could be overkill</p>
-16:48 <@nop> haha</p>
-16:48 <@nop> not twofish wrapped in AES</p>
-16:49 < jeremiah> should we standardize each transport as having one</p>
-specific set of characteristics (network setup, encryption)?</p>
-16:49 <@nop> alright for the sake of argument</p>
-16:49 <@nop> let's do rijndael for this part</p>
-16:49 < jeremiah> and then we could have one TCP transport supporting</p>
-AES, one with Twofish, but not one that has to juggle both?</p>
-16:49 <@jrand0m> jeremiah> yes, particular transports will have</p>
-particular characteristics, but we're covering the end to end message</p>
-crypto done in the api atm</p>
-16:49 <@nop> let's do end to end AES</p>
-16:49 < jeremiah> jrand0m: ah</p>
-16:49 <@nop> then node to node twofish option</p>
-16:50 <@nop> and if you can, do AES-counter mode</p>
-16:50 <@jrand0m> 'k, sounds good. we can always change later on before</p>
-release (during peer review, etc)</p>
-16:50 < wilde> but all crypto algorithms have failed in the past, using</p>
-double encryption would at least buy time in case of a crypto</p>
-breakthrough</p>
-16:50 < jeremiah> not really</p>
-16:50 <@jrand0m> wilde> the truly paranoid can encrypt with their own</p>
-system prior to sending messages over the I2P network</p>
-16:50 <@hezekiah> wilde: If one algorithm is found to be weak, we'll</p>
-replace it.</p>
-16:51 <@jrand0m> I2P will just transparently encrypt</p>
-16:51 < wilde> jrand0m: yes, you're right, there should be a limit to</p>
-paranoia</p>
-16:52 <@nop> yes</p>
-16:52 <@nop> we could go on all day</p>
-16:52 <@nop> arguing about it</p>
-16:52 <@nop> AES end to end</p>
-16:52 <@jrand0m> ok, I don't have anything else on I2P stuff</p>
-16:52 <@nop> Twofish and others node to node</p>
-16:52 <@jrand0m> coo'</p>
-16:53 <@jrand0m> any other I2P stuff, or are we on the next agenda item?</p>
-16:54 <@hezekiah> I'm done. :)</p>
-16:54 < wilde> what about A2A, anonymous 2 anonymous?</p>
-16:54 <@hezekiah> I</p>
-16:55 <@hezekiah> I've never heard of that. What are you talking about,</p>
-wilde?</p>
-16:55 <@jrand0m> I2P is anonymous to anonymous communication</p>
-16:55 <@jrand0m> I2P = "Invisible Internet Project"</p>
-16:55 < nemesis> jrand0m: can you send the roadmap as an attechment, and</p>
-not as inline?</p>
-16:55 <@jrand0m> (dont make us say I^2P)</p>
-16:55 <@nop> hushmail has an encrypted messenger</p>
-16:55 <@nop> neat</p>
-16:56 <@jrand0m> nemesis> hmm, I tried to - hushmail said it was</p>
-attached :/</p>
-16:56 <@hezekiah> nemesis: I got it as attached.</p>
-16:56 <@jrand0m> nemesis> you can d/l from</p>
-http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/290</p>
-16:56 < nemesis> i'm sorry, i can't copy&paste it</p>
-16:56 <@hezekiah> nemesis: Perhaps your mail reader is the problem? (He</p>
-sent it as a zip file.)</p>
-16:56 < nemesis> its inline</p>
-16:56 < nemesis> theres a zip file...</p>
-16:56 -!- UserX [~User@anon.iip] has joined #iip-dev</p>
-16:57 <@jrand0m> 'lo userx</p>
-16:57 < nemesis> -Hush_boundarfy-31fda3d62329b</p>
-16:57 <@nop> did anyone log this</p>
-16:57 < nemesis> Content-Transfer-Encoding: base64</p>
-16:57 <@hezekiah> cohesion was supposed to.</p>
-16:57 <@jrand0m> I log all IRC</p>
-16:57 <@cohesion> i have it all</p>
-16:57 < thecrypto> yes</p>
-16:57 <@jrand0m> word</p>
-16:58 < Zwolly> my ISP also logs all the IRC chatting so what is new</p>
-16:58 <@jrand0m> lol Zwolly</p>
-16:58 < Zwolly> hehe</p>
-16:59 <@hezekiah> Zwolly: Your ISP won't have logs of this. :)</p>
-16:59 < Zwolly> i hope not if so you guys do a louzy job</p>
-16:59 <@hezekiah> lol</p>
-17:00 <@hezekiah> So, I'm assuming we move on to the next agenda item</p>
-now since we've stopped talking about i2p for a while.</p>
-17:00 <@nop> yes</p>
-17:00 <@nop> comments</p>
-17:00 <@nop> suggestions</p>
-17:01 <@jrand0m> we, should, like, do some drugs, man</p>
-17:01 <@hezekiah> jrand0m: Sorry. I refuse to ruin a good mind with such</p>
-substances.</p>
-17:01 < wilde> question: isn't the release plan a bit optimistic=</p>
-17:01 < wilde> ?</p>
-17:02 <@hezekiah> wilde: lol. Well, my term would be 'insane'. But I</p>
-think it might be feasible.</p>
-17:02 <@jrand0m> wilde> good question. it should be plausible, and if</p>
-any devs on there want to adjust tasks they are working on, we will.</p>
-17:03 < thecrypto> we can do it!</p>
-17:04 <@jrand0m> go TEAM!</p>
-17:04 < wilde> aim high that's good, but it should be realistic</p>
-17:04 < wilde> do you guys have time enough for the actual programming?</p>
-17:04 * jrand0m quit his job to work on this, and a few people have</p>
-summer break coming up</p>
-17:05 < wilde> i mean september-october that's like 60-90 days</p>
-17:05 < wilde> ok that's sounds good</p>
-17:05 <@jrand0m> but don't believe us. we'll release when its ready.</p>
-17:05 <@hezekiah> jrand0m: BTW, since you quit your job, how are you</p>
-going to eat while you code this?</p>
-17:05 < jeremiah> wilde: we're going to be implementing lots of it in</p>
-high-level languages and then re-coding in C later</p>
-17:05 <@jrand0m> hezekiah> I eat code</p>
-17:05 <@hezekiah> I was afraid you'd say something like that.</p>
-17:06 <@jrand0m> ;)</p>
-17:06 <@hezekiah> I just hope you've got a good nest egg to live on.</p>
-17:06 < jeremiah> jrand0m: my code eats random numbers</p>
-17:06 < jeremiah> that might make a bad loop</p>
-17:06 <@hezekiah> ROTFL!</p>
-17:07 < wilde> drinking java, eating python, roasted ant, could go</p>
-17:07 <@jrand0m> but bugs have lots of protien</p>
-17:07 * jrand0m !thwaps self</p>
-17:07 <@jrand0m> ok, do we have other questions / comments /</p>
-suggestions?</p>
-17:07 <@hezekiah> Well, I've got to go now.</p>
-17:07 <@hezekiah> Bye everyone. :)</p>
-17:07 <@jrand0m> or are we actually finishing up in under an hour?</p>
-17:07 -!- hezekiah [hezekiah@anon.iip] has quit [Client exiting]</p>
-17:07 <@jrand0m> lol wilde</p>
-17:08 <@jrand0m> nop> got anything or we done?</p>
-17:10 -!- UserX [~User@anon.iip] has quit [Ping timeout]</p>
-17:10 -!- wilde [anon@anon.iip] has quit []</p>
-17:10 <@cohesion> ok, i'm ending the meeting</p>
-17:11 < nemesis> STOP!</p>
-17:11 <@cohesion> nop: i'll get with you about CVS tomarrow</p>
-17:11 * jrand0m stops</p>
-17:11 < nemesis> ganttproject-1.9.7.jar</p>
-17:11 <@cohesion> GO!</p>
-17:11 < nemesis> how it works?</p>
-17:11 <@nop> ok</p>
-17:11 <@nop> also</p>
-17:11 <@nop> aes</p>
-17:11 <@jrand0m> nemesis> just double click on it with java 1.4.2</p>
-installed</p>
-17:11 <@nop> we should use 256 bit as a norm</p>
-17:11 < nemesis> i have java 1.4.2...</p>
-17:11 <@jrand0m> nemesis> I'll email out the xml with the project info</p>
-17:12 <@jrand0m> word nop, definitely</p>
-17:13 < nemesis> Could not find the main class. Program will exit!</p>
-17:13 < nemesis> hm.. i think my java are broken.... Title of the</p>
-Window: Java Virtual Machine Launcher...</p>
-17:14 <@jrand0m> weird nemesis, works for me... make sure its loading it</p>
-with the 1.4.2 jvm and not the windows jvm</p>
-17:14 <@jrand0m> ah, try running from the cmd.exe command line</p>
-17:14 < nemesis> eh?</p>
-17:14 < nemesis> k</p>
-17:14 < nemesis> then i write a .bat for it, like for columba :)</p>
-17:14 <@cohesion> ok, i'm closing the logs</p>
-17:14 <@jrand0m> (and type java -version first to make sure it uses the</p>
-right one)</p>
-17:14 <@jrand0m> heh word</p>
-17:14 <@cohesion> everyone say "cheese"</p>
-17:14 <@jrand0m> queso</p>
-17:14 < thecrypto> cheese</p>
-17:15 < Zwolly> chesse</p>
-17:15 < Zwolly> cheese</p>
-17:15 < nemesis> E:\Sytemprogramme\server\Projektverwaltung>java</p>
-ganttproject-1.9.7.jar</p>
-17:15 < nemesis> Exception in thread "main"</p>
-java.lang.NoClassDefFoundError: ganttproject-1/9/7/ja</p>
-17:15 < nemesis> r</p>
-17:16 <@jrand0m> java -jar ganttproject-1.9.7.jar</p>
-17:16 < nemesis> java version "1.4.2-beta"</p>
-17:16 < nemesis> Java(TM) 2 Runtime Environment, Standard Edition (build</p>
-1.4.2-beta-b19)</p>
-17:16 < nemesis> Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed</p>
-mode)</p>
-17:16 < nemesis> hm... why with -jar?</p>
-17:16 < nemesis> now it works...</p>
-17:17 -!- ion [ion@anon.iip] has quit [Ping timeout]</p>
-17:17 < nemesis> thx jrand0m</p>
-17:17 <@jrand0m> without -jar asks it to load the class</p>
-ganttproject-1/9/7/jar</p>
-17:17 <@jrand0m> np</p>
-17:17 < jeremiah> is cvs working?</p>
-17:17 < jeremiah> i checked out earlier today, but it's weird now</p>
-17:17 <@jrand0m> sourceforge is being a pain atm</p>
---- Log closed Tue Jul 22 17:18:14 2003</div></p>
-{% endblock %}
\ No newline at end of file
+--- 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/50.rst b/i2p2www/meetings/50.rst
new file mode 100644
index 00000000..f0373e4c
--- /dev/null
+++ b/i2p2www/meetings/50.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 22, 2003
+==============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/51.log b/i2p2www/meetings/51.log
index c0143226..4307e81b 100644
--- a/i2p2www/meetings/51.log
+++ b/i2p2www/meetings/51.log
@@ -1,886 +1,881 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 51{% endblock %}
-{% block content %}<div class="irclog">
---- Log opened Tue Jul 29 16:54:31 2003</p>
-17:11 <@hezekiah> Tue Jul 29 21:11:18 UTC 2003</p>
-17:11 <@hezekiah> The 51th (I think) iip-dev meeting.</p>
-17:11 <@hezekiah> Agenda:</p>
-17:11 <@hezekiah> 1.) Welcome</p>
-17:11 <@hezekiah> 2.) jrand0m's stuff</p>
-17:11 <@hezekiah> 3.) Any of the other developer's stuff</p>
-17:11 <@hezekiah> 4.) Anything nop adds when/if he gets here</p>
-17:12 <@hezekiah> 5.) Questions and Comments from the ever eager unwashed</p>
-	 masses. ;-)</p>
-17:12 <@hezekiah> OK!</p>
-17:12 <@hezekiah> Welcome everyone to the 51th (I think) iip-dev meeting</p>
-17:12 <@hezekiah> Item number 2!</p>
-17:12 <@hezekiah> jrand0m's stuff</p>
-17:12 -!- thetower [none@anon.iip] has joined #iip-dev</p>
-17:12  * hezekiah hands the mike to jrand0m</p>
-17:12 <@jrand0m> sub-agenda:</p>
-17:12 <@jrand0m> 2.1) I2CP spec & dev status</p>
-17:12 < co> Where are the logs for meeting 50?</p>
-17:12 <@jrand0m> 2.2) SDK plans</p>
-17:12 <@jrand0m> 2.3) crypto</p>
-17:12 <@jrand0m> 2.4) roadmap / network proto status</p>
-17:13 <@hezekiah> co: cohesion is working on getting them up</p>
-17:13 <@jrand0m> (btw, its "mic", for microphone)</p>
-17:13 <@hezekiah> jrand0m: Sorry. :)</p>
-17:13 <@hezekiah> jrand0m: (And this mistake from a sound tech guy!)</p>
-17:13 -!- luckypunk [~yetalohe@anon.iip] has joined #iip-dev</p>
-17:13 -!- odargur [odargur@anon.iip] has joined #iip-dev</p>
-17:13 <@jrand0m> 2.1) I2CP: the spec is committed to CVS with a slight mod</p>
-	 to one of the messages (MessageStatusMessage)</p>
-17:14 <@jrand0m> Comments are always welcome on I2CP, but the sooner the</p>
-	 better.</p>
-17:14 <@hezekiah> jrand0m: Where's the spec in CVS? ... and is it on the SF</p>
-	 CVS too?</p>
-17:14 <@jrand0m> The reason for sooner the better is that we'll have a</p>
-	 working Java client implementation by friday.</p>
-17:14 -!- some_random_guy [~dan@anon.iip] has joined #iip-dev</p>
-17:14  * thecrypto crosses fingers on that one</p>
-17:14 <@jrand0m> Plus a local only router by the end of the weekend, I'm hoping</p>
-17:15 <@jrand0m> no hez, only on the cathedral</p>
-17:15 <@jrand0m> good point thecrypto.</p>
-17:15 <@jrand0m> Caveat:</p>
-17:15 <@hezekiah> Ugh. I still can't get CVS to work with cathedral.</p>
-17:15 <@jrand0m> some crypto isn't 100%, but its all stub'ed to let us plug</p>
-	 in more complete or other implementations later</p>
-17:15 <@jrand0m> hezekiah> we'll get you up after the meeting.</p>
-17:15 <@hezekiah> jrand0m: Thanks. :)</p>
-17:16 <@jrand0m> the spec is in the</p>
-	 i2p/doc/specs/data_structure_spec/datastructures.html</p>
-17:16 <@jrand0m> thecrypto> do you have anything to add re: java impl?</p>
-17:16 -!- ArdVark [simple1@anon.iip] has joined #iip-dev</p>
-17:16 <@jeremiah> the local-only router you mentioned was the python one,</p>
-	 right? or is there a java one too?</p>
-17:17 <@jrand0m> that all depends :)</p>
-17:17 <@jrand0m> jeremiah/hezekiah> how goes the python client and local-only</p>
-	 router?</p>
-17:17 <@thecrypto> not really, except for the crypto issue i think we'll</p>
-	 talk about in a bit</p>
-17:17 <@jrand0m> word thecrypto.</p>
-17:17 <@hezekiah> jrand0m: It's coming. I finally got the TCP transport</p>
-	 stuff working yesterday.</p>
-17:17 <@jeremiah> it seems ok, i think most of it will be dependent on</p>
-	 hezekiah's dev speed more than mine</p>
-17:17 <@hezekiah> jrand0m: Jeremiah has some nice stuff going with the</p>
-	 message strcutures.</p>
-17:18 <@hezekiah> hezekiah: I'm hoping that we can make the deadline.</p>
-17:18 <@jrand0m> cool.</p>
-17:18 <@jeremiah> also... friday is my birthday, so I plan on not being</p>
-	 around the computer then</p>
-17:18 <@hezekiah> jeremiah: Understandable. :)</p>
-17:18 <@hezekiah> jeremiah: And happy birthday in advance. :)</p>
-17:18 <@jeremiah> thanks</p>
-17:18 <@jrand0m> jumping slightly to agenda 2.4> when would we expect to be</p>
-	 able to have the python local only router?  realistically?</p>
-17:19 <@jrand0m> word, if you code on friday I'll kick your ass</p>
-17:19 <@jrand0m> virtually, at least</p>
-17:19 <@hezekiah> jrand0m: I thought that's what I'm coding. The Python</p>
-	 local only router.</p>
-17:19 <@jrand0m> si, that you are</p>
-17:19 <@hezekiah> Well the deadline is August 1st.</p>
-17:19 <@jeremiah> right now we're working on message to-from binary format</p>
-	 stuff</p>
-17:19 <@hezekiah> That's not that hard.</p>
-17:19 <@jeremiah> right</p>
-17:19 <@hezekiah> I'm hoping to have that done in a day or two.</p>
-17:20 <@jrand0m> thats friday :)</p>
-17:20 <@jrand0m> awesome</p>
-17:20 <@hezekiah> I hope it will be done by August 1st. Realistically it</p>
-	 might be a few days late, but I hope not.</p>
-17:20 <@jrand0m> 'k, I'll hold off on touching any java local only stuff</p>
-	 then and work on the network spec after the java client api is set.</p>
-17:20 <@hezekiah> Yes. Specs are good.</p>
-17:21 <@hezekiah> They make my job a LOT easier! :)</p>
-17:21 <@jrand0m> word.</p>
-17:21 <@jrand0m> I'll write up a quick 2 paragraph run through of the java</p>
-	 I2CP test harness too</p>
-17:21 <@jrand0m> I'll get that out tonight</p>
-17:22 <@hezekiah> jrand0m: I love how you get these specs written so fast.</p>
-17:22 <@hezekiah> This is fun. :)</p>
-17:22 <@jrand0m> Ok, hez/jeremiah/thecrypto> anything else on I2CP?</p>
-17:22 <@jrand0m> lol</p>
-17:22 -!- dm [~hifi@anon.iip] has joined #iip-dev</p>
-17:22 <@hezekiah> Um ...</p>
-17:22 <@hezekiah> I want the crypto spec!</p>
-17:22 < dm> welcome</p>
-17:22  * hezekiah pouts like a baby</p>
-17:22 <@hezekiah> ;-)</p>
-17:23 <@hezekiah> Seriously, ... I can't think of anything.</p>
-17:23 <@jrand0m> thats agenda item 2.3</p>
-17:23 <@thecrypto> still waiting for 2.3 to come up</p>
-17:23 <@hezekiah> If I do, I'll just come online and pester you with questions,</p>
-	 jrand0m. :)</p>
-17:23 <@jrand0m> word.</p>
-17:23 <@jrand0m> ok.  2.2) SDK plans</p>
-17:23 <@hezekiah> What agenda point did we just finish?</p>
-17:23 <@hezekiah> 2.4?</p>
-17:23 <@hezekiah> And have we finished 2.1 yet?</p>
-17:23 <@jrand0m> 2.1</p>
-17:24 <@jrand0m> now 2.2> the SDK</p>
-17:24 <@hezekiah> OK.</p>
-17:24 < dm> agenda has decimal point in it now? I see progress already.</p>
-17:24 <@hezekiah> I'm found now (as opposed to lost).</p>
-17:24 <@thecrypto> we might have 2 decimal points :)</p>
-17:25 <@jeremiah> what makes up the SDK apart from the various APIs?</p>
-17:25 <@jrand0m> the SDK is: the client API (as many as we have available), the</p>
-	 local only router, a trivial sample app, and some docs on how to use the APIs.</p>
-17:25 <@hezekiah> jrand0m: Would I be correct in assuming that you're writing</p>
-	 the docs? :)</p>
-17:26 <@jrand0m> I'd like to have the SDK released asap, so that 3rd (or</p>
-	 even 2nd or 1st) party developers can write and test applications that will</p>
-	 run over I2P, so once the network is operational, we'll hit the ground running.</p>
-17:26 <@jrand0m> hezekiah> I'd actually prefer not to.</p>
-17:26 <@jrand0m> hezekiah> and I say that not because I don't want to document,</p>
-	 but because I'm too close to it.</p>
-17:26 <@hezekiah> jrand0m: OK.</p>
-17:26 <@jrand0m> we should have somone who *doesn't* actually implement the</p>
-	 code write that doc, so it can be understandable to people who didn't write</p>
-	 the I2CP spec</p>
-17:26 <@hezekiah> jrand0m: We'll cross that bridge when we get there.</p>
-17:26 <@jrand0m> but if need be, I'll jump on it.</p>
-17:26 <@jrand0m> word.</p>
-17:27 < dm> what incentive do people have to write apps without an operational</p>
-	 network, and how would they even test their app.</p>
-17:27 <@hezekiah> jrand0m: Or why don't someone who designed the protocol</p>
-	 write it, and then have someone who never worked with it go over it until</p>
-	 it makes sense?</p>
-17:27 <@jrand0m> Ok, there has been some discussion of a simple 'talk'</p>
-	 style app.</p>
-17:27 <@jrand0m> dm> people will be able to test with the SDK.</p>
-17:27 <@thecrypto> actully, i was wondering what would be the use of that</p>
-	 if it's local only</p>
-17:28 <@jeremiah> dm: the idea is to implement a simple network that isn't</p>
-	 fully functional but can pass messages</p>
-17:28 <@thecrypto> you'd only be able to talk to yourself</p>
-17:28 <@jeremiah> it's not actually local-only, but it only includes</p>
-	 client-router, not router-router code</p>
-17:28 <@jrand0m> thecrypto> you can talk to other Destinations. I2P is</p>
-	 location independent - local is the same as remote.</p>
-17:29 <@thecrypto> okay</p>
-17:29 < dm> nice and all, I just don't see anyone (besides you 3-4) writing</p>
-	 anything if you can only test locally. But anyway, doesn't matter.</p>
-17:29 <@jrand0m> so a talk app can open up two instances of the application</p>
-	 and talk to oneself, etc</p>
-17:30 <@thecrypto> but when we add the remote stuff, the app should just work</p>
-17:30 <@jrand0m> dm> right, this is just a prereq for having other people</p>
-	 write apps.</p>
-17:30 <@jrand0m> exactly.</p>
-17:30 <@jrand0m> the app will work with absolutely NO changes</p>
-17:30 < co> dm: This is a test application. Once the router-router code is</p>
-	 written, you will be able to talk to others.</p>
-17:30 <@jeremiah> having local-only just lets us develop in parallel</p>
-17:30 < dm> yes, but if the app assumes 10 ms latency, and it ends being 12</p>
-	 seconds, it won't work too well :)</p>
-17:31 <@jrand0m> agreed dm</p>
-17:31 < dm> any estimates on latency btw? :)</p>
-17:31 <@jrand0m> if we have 12 second latency, we have work to do.</p>
-17:31 <@jrand0m> we won't have that though.</p>
-17:31 <@jrand0m> estimates are .6-2.7sec</p>
-17:31 <@jrand0m> for a 5,000,000 router network.</p>
-17:31 <@hezekiah> BTW, that reminds me. We need to talk about ElGamal.</p>
-17:31 <@thecrypto> the longest time is setup</p>
-17:31 <@jrand0m> (see iip-dev archives for the rudimentary models)</p>
-17:31 < dm> lower or higher for smaller networks?</p>
-17:32 <@jrand0m> hezekiah> 2.3: crypto.</p>
-17:32 <@thecrypto> after that the time the drops dramatically</p>
-17:32 <@jrand0m> dm> lower.</p>
-17:32 <@thecrypto> hezekiah: you prolly have the same question as i</p>
-17:32 <@jrand0m> thecrypto> exactly, setup time is offline for message</p>
-	 delivery though [aka set up tunnels prior to sending messages]</p>
-17:32 < dm> ok, just checking you ;)</p>
-17:32 <@jrand0m> heh</p>
-17:33 <@jrand0m> ok.  last part of the SDK - the app</p>
-17:33 <@jrand0m> co/thecrypto: thoughts on a java talk impl?  workable?</p>
-	 time?  plans?  interest?</p>
-17:34 <@thecrypto> once the API is up, we can prolly have a talk done in</p>
-	 about a week or so, 2 tops, co agrre?</p>
-17:34 <@jeremiah> chat could be built in as a jabber router, right?</p>
-17:34 < co> That should be fairly easy to do.</p>
-17:34 < co> thecrypto: I agree.</p>
-17:34 <@jrand0m> jeremiah> I don't know jabber, but if jabber can run over</p>
-	 the api, cool</p>
-17:35 <@jrand0m> word co & thecrypto</p>
-17:35 <@jrand0m> jeremiah> note that this is just a trivial app to do proof</p>
-	 of concept with, not a Kickass Anonymous IM System :)</p>
-17:35 <@jeremiah> not yet ;)</p>
-17:35 <@thecrypto> we can add that functionallity later</p>
-17:35 <@jeremiah> k</p>
-17:36 <@jrand0m> heh</p>
-17:36 <@thecrypto> let's start small</p>
-17:36  * jrand0m puts in the schedule "add feature: be kickass"</p>
-17:36 < some_random_guy> heh</p>
-17:36 < some_random_guy> nice feature :)</p>
-17:36 -!- dm2 [~hifi@anon.iip] has joined #iip-dev</p>
-17:37 <@jeremiah> jrand0m: I think I missed this in 2.1, but any thoughts</p>
-	 on kademlia as a DHT? it requires less upkeep than Chord</p>
-17:37 -!- nop [nop@anon.iip] has joined #iip-dev</p>
-17:37 < nop> sorry</p>
-17:37 <@jrand0m> plus one of these days we need to get someone on the IIP</p>
-	 redesign to run over this.</p>
-17:37 -!- dm [~hifi@anon.iip] has quit [Ping timeout]</p>
-17:37 < nop> what?</p>
-17:37 < nop> who</p>
-17:37 < nop> where</p>
-17:37 < nop> when</p>
-17:37 < nop> ?</p>
-17:37 -!- dm2 is now known as dm</p>
-17:37 <@jrand0m> hey, speakin of the devil</p>
-17:37 < WinBear> why?</p>
-17:37 < WinBear> nm</p>
-17:37 < nop> I'm an angel actually</p>
-17:37 <@hezekiah> lol</p>
-17:38 <@thecrypto> someone hand nop a log</p>
-17:38 < WinBear> azrel</p>
-17:38 <@jrand0m> jeremiah> kademila is a good DHT, and we will definitely</p>
-	 review that plus the chord/tapestry crew, along with sloppy dhts in the</p>
-	 network spec.</p>
-17:38 <@jeremiah> jrand0m: cool</p>
-17:38 <@hezekiah> thecrypto: I'm working on it. :)</p>
-17:38 < nop> I was hearing of one that kicks but</p>
-17:38 < nop> called chord/middle</p>
-17:38 -!- hif [~hifi@anon.iip] has joined #iip-dev</p>
-17:39 < nop> but you know who is good to talk to his brandon wiley</p>
-17:39  * jrand0m !thwaps nop</p>
-17:39 < nop> I knew that would hurt</p>
-17:39 <@hezekiah> lol</p>
-17:39 <@hezekiah> Who's Brandon Wiley?</p>
-17:39 < nop> someone I'm sure jrand0m has been in numerous discussions with</p>
-17:39 < nop> :)</p>
-17:39 < nop> someone email me a log</p>
-17:39 < dm> Brandon is jrandom's real name, busted!</p>
-17:39 <@hezekiah> I'm working on it.</p>
-17:40 <@hezekiah> Hold you horses, nop. :)</p>
-17:40 < nop> haha</p>
-17:40 < dm> Brandon Wiley is the first Freenet programmer, having</p>
-17:40 < dm> co-founded the development effort with the system's inventor,</p>
-	 Ian Clarke</p>
-17:40 < nop> is userx here or there</p>
-17:40 < WinBear> you can talk to my brandon wiley</p>
-17:40 <@hezekiah> OK. It's on the way ... if my mail client will cooperate</p>
-	 and send a 15K attachement.</p>
-17:41 <@thecrypto> we've talked alot :)</p>
-17:41 <@hezekiah> nop: UserX is niether hither or thither.</p>
-17:41 <@hezekiah> OK!</p>
-17:41 <@hezekiah> The log is sent nop! Go read. :)</p>
-17:41 <@thecrypto> and now we wait</p>
-17:41 <@jrand0m> ok, anyone have any SDK thoughts while we give nop a min</p>
-	 to catch up? ;)</p>
-17:41 <@hezekiah> jrand0m: Now that I've gotten that log business done</p>
-	 ... what's kademlia?</p>
-17:42 <@jrand0m> Yet Another Academic DHT :)</p>
-17:42 <@hezekiah> And where I can get a link to kademlia's webpage?</p>
-17:42 -!- Erazerhead [JohnDoe@anon.iip] has joined #iip-dev</p>
-17:42 <@jeremiah> http://kademlia.scs.cs.nyu.edu/</p>
-17:42 <@hezekiah> Thanks. :)</p>
-17:42 <@thecrypto> YAADHT?</p>
-17:42 <@hezekiah> lol</p>
-17:42 <@hezekiah> Names these days ... I tell ya'!</p>
-17:43 <@jrand0m> and if there's ever any CS stuff mentioned that you don't</p>
-	 understand, go to citeseer.nj.nec.com/cs</p>
-17:43 < WinBear> klamidia?</p>
-17:43 <@hezekiah> OK.</p>
-17:43 < nop> jrand0m: I was just about to say citeseer</p>
-17:43 < dm> what's the ETA on the SDK?</p>
-17:44  * jrand0m avoids injecting the clap into I2P</p>
-17:44  * jrand0m hopes the SDK will be out next week.  perhaps next friday?</p>
-17:44  * thecrypto crosses another pair of fingers</p>
-17:45 <@jrand0m> ok.  moving on to 2.3) Crypto.</p>
-17:45  * hezekiah imagines thecrypto with about 13 sets of fingers crossed</p>
-	 ... and then realized that he must have run out by now.</p>
-17:45 <@hezekiah> Yay!</p>
-17:45  * jrand0m pokes nop to make sure he's here</p>
-17:45 <@hezekiah> Crypto!</p>
-17:45 <@hezekiah> I have something to start us off with. :)</p>
-17:46 <@thecrypto> i have something too</p>
-17:46 <@thecrypto> Dibs! :)</p>
-17:46  * jrand0m doesn.t so you two fight it out</p>
-17:46 <@hezekiah> thecrypto can go first. :)</p>
-17:46 <@jrand0m> thecrypto> speak</p>
-17:46 <@jrand0m> :)</p>
-17:46 <@thecrypto> Ok, on Elgamal</p>
-17:47 <@thecrypto> We have to figure out whether or not we have common p</p>
-	 and alpha</p>
-17:47 -!- some_random_guy [~dan@anon.iip] has quit [BitchX: the original</p>
-	 point-and-click interface.]</p>
-17:47 <@thecrypto> the problem with a common p and alpha is that we'd have</p>
-	 to find someway to change everyone's keys at the same time</p>
-17:48 <@jrand0m> aka: really bad.</p>
-17:48 < co> thecrypto: Sorry, what are p and alpha?</p>
-17:48 <@thecrypto> the advantage is that we can pick specially optimized</p>
-	 ones and the amount of data transmitted for a public key is very small</p>
-17:48  * jrand0m sees no good reason to use common p and alpha, beyond saving</p>
-	 a few bits</p>
-17:48 <@thecrypto> co: for all intensive purposes, special big numbers</p>
-17:49 <@jrand0m> thecrypto> we can still optimize for commonly encrypted to</p>
-	 destination's p and alpha</p>
-17:49 <@thecrypto> or should i go into an explaination of how elgamal workds</p>
-17:49 <@thecrypto> jrand0m: yes</p>
-17:49 < co> thecrypto: OK.</p>
-17:49 <@thecrypto> we can also have everyone have a different p and alpha</p>
-17:50 <@jeremiah> for those who are interested:</p>
-	 http://www.wikipedia.org/wiki/ElGamal_discrete_log_cryptosystem</p>
-17:50 <@thecrypto> this means that the amount of data transmitted is much</p>
-	 larger and we have to figure out how to pack it in</p>
-17:50 <@jrand0m> word, thanks jeremiah</p>
-17:50 <@jrand0m> much larger?</p>
-17:50 <@jrand0m> I thought with varying p and alpha we can use smaller p</p>
-	 and alpha?</p>
-17:51 <@thecrypto> instead of 160 bit numbers we are now talking 2 1024 bit</p>
-	 and 1 160</p>
-17:51 <@thecrypto> or overall 2308</p>
-17:51 <@hezekiah> 288 bytes</p>
-17:51 <@hezekiah> Big deal.</p>
-17:52 <@jrand0m> ok, thats not too bad.  we've planned on 256bytes</p>
-17:52 <@hezekiah> These keys aren't transfered all that often, are they?</p>
-17:52 <@jrand0m> another 32 doesn't hurt</p>
-17:52 <@jrand0m> hezekiah> they're inserted into the DHT</p>
-17:52 <@hezekiah> Ah!</p>
-17:52 <@hezekiah> That's why we wanted it small.</p>
-17:53 <@thecrypto> also, another problem about elgamal we might also have</p>
-	 to worry about</p>
-17:53 <@jrand0m> well, it doesn't really hurt if the RouterInfo structure</p>
-	 is about 10K or so</p>
-17:53 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev</p>
-17:53 <@jrand0m> 'k, s'up thecrypto?</p>
-17:53 <@thecrypto> message expansion is 2, the size of an encryption or a</p>
-	 signature is twice the size of the message</p>
-17:54 <@jrand0m> ElG encryption is only of the AES key</p>
-17:54 <@jrand0m> ElG signature is only of the SHA256 hashes</p>
-17:55 <@thecrypto> okay, it's just something to bring up as well</p>
-17:55 <@hezekiah> jrand0m: Which makes me _really_ puzzled.</p>
-17:55 <@thecrypto> now back to the original issue, do we want to have a</p>
-	 shared p and alpha or do we want everyone to have different p and alphas?</p>
-17:55 <@jrand0m> hezekiah> hmm?  you read the data structure spec for</p>
-	 #Payload ?</p>
-17:55 <@jrand0m> any thoughts/questions on that hezekiah?</p>
-17:55  * dm now understands how DHTs work.</p>
-17:55 <@jrand0m> nop> thoughts?</p>
-17:55 <@jrand0m> awesome dm</p>
-17:55 <@hezekiah> If a signature is twice the size of the data signed,</p>
-	 then why does the IC2P spec say a signature is 128 bytes?</p>
-17:56 < nop> no</p>
-17:56 < nop> shared p</p>
-17:56 <@hezekiah> Shouldn't it bee 512?</p>
-17:56 <@thecrypto> the hash of the bytes</p>
-17:56 < nop> and alphas</p>
-17:56 < dm> seems like a lot of work is required when joining a DHT, but I</p>
-	 guess it works.</p>
-17:56 < nop> shared base, shared p</p>
-17:56 <@jrand0m> hezekiah> bits / bytes.</p>
-17:56 < nop> this will eliminate a lot of risk</p>
-17:56 <@thecrypto> then how big do we want it?</p>
-17:56 <@hezekiah> Hmm</p>
-17:56 <@jrand0m> nop> in 3 years, will we want to have everyone change their</p>
-	 p and alpha at the same time?</p>
-17:56 < nop> and hold our protocol to standards</p>
-17:57 <@thecrypto> since it does open up that p and alpha huge attacks</p>
-17:57 < nop> jrand0m: there is such a thing called cooked primes, at this</p>
-	 time, and this is the time I'm looking at</p>
-17:57 <@thecrypto> which if completed bring the entire network down</p>
-17:57 < nop> I believe we can modify with the times</p>
-17:57 < nop> but a static oakley approved prime is advised</p>
-17:57 < nop> as they have been reviewed thoroughly as secure</p>
-17:58 < nop> and that is a better basis than any of our assumptions about</p>
-	 primes being generated (probable at that)</p>
-17:58 <@thecrypto> if it's not prime, encryption or signatures won't work</p>
-	 so we just throw it our</p>
-17:59 <@jrand0m> agreed, they have better primes.  so when one of those</p>
-	 primes are factored, everyone using them is exposed, correct?</p>
-17:59 < dm> hmmm, I gotta go. This is logged right?</p>
-17:59 < nop> jrand0m: yes</p>
-17:59 <@thecrypto> yup</p>
-17:59 < nop> jrand0m: when that happens we'll all know</p>
-17:59 < nop> I don't want to risk prime generation</p>
-17:59 -!- dm [~hifi@anon.iip] has quit [it better be]</p>
-17:59 <@thecrypto> how will we know?</p>
-17:59 < nop> plus it adds to our calculation time</p>
-17:59 -!- hif [~hifi@anon.iip] has quit []</p>
-17:59 < nop> thecrypto: if you use a standard defined Oakley prime set,</p>
-	 you will know when it's been cracked</p>
-18:00 <@thecrypto> how?</p>
-18:00 < nop> as it will be very public news</p>
-18:00 <@jrand0m> nop> we'll know unless the NSA cracks it.</p>
-18:00 < co> nop: How many of those primes are there? If not many, using them</p>
-	 is a risk.</p>
-18:00 <@thecrypto> yeah, passive evesdropping is still a threat</p>
-18:00 <@thecrypto> and i can make a program to generate ps and alphas and</p>
-	 test them in about an hour</p>
-18:00 <@jrand0m> nop> it would be very public news unless it was a threat</p>
-	 to national security.</p>
-18:00 < co> Wait... no, that's a stupid question. Never mind.</p>
-18:01 < nop> this is true, but I believe from numerous contacts in the</p>
-	 cryptography community that if it's solved it will be solved before the NSA</p>
-	 does it</p>
-18:01 < nop> our prime generation will not secure that either way</p>
-18:01 < nop> if they solve those primes</p>
-18:01 < nop> you may as well figure out a new algo to use</p>
-18:01 <@jrand0m> 'k.</p>
-18:02 < nop> please use static, it will relieve problems with cryptanalysis,</p>
-	 and reduce the risks of mistake in our crypto</p>
-18:02 <@jrand0m> I was on the fence, and I'm fine with going with shared</p>
-	 known good primes.</p>
-18:02 <@thecrypto> okay, then let's pick a prime then</p>
-18:02 <@jrand0m> nop> we've still got you penciled in the ganttchart for</p>
-	 crypto spec</p>
-18:02 <@thecrypto> and do they have generators for these primes?</p>
-18:02 < nop> yes</p>
-18:02 < nop> yes I do</p>
-18:03 < nop> 2</p>
-18:03 < nop> that is a primitive root of the primes I will have</p>
-18:03 < nop> what size primes do you guys want?</p>
-18:03 <@thecrypto> i'm thinking somewhere between 2048-4096</p>
-18:03 <@hezekiah> We're using a 2048 key, right?</p>
-18:03 < nop> yes, so use a 4096 or higher prime</p>
-18:04 <@thecrypto> because the sharedness means we're out in the open</p>
-18:04 <@thecrypto> and if this takes off, it would be a very valuble prime</p>
-	 to break</p>
-18:04  * cohesion missed the meeting</p>
-18:04 < co> You are using this prime within ElGamal, though, right?</p>
-18:04 <@hezekiah> So the keys will be 4096 bits?</p>
-18:04 <@cohesion> did someone log?</p>
-18:04 < nop> co yes</p>
-18:04 < nop> no hezekiah</p>
-18:04 < nop> the keys will be 2048</p>
-18:04 <@cohesion> ok</p>
-18:04 < nop> the prime will be higher than 4096</p>
-18:04  * cohesion goes back to his work</p>
-18:04 <@hezekiah> OK. Please forgive my horribe understanding here. :)</p>
-18:04 < nop> brb</p>
-18:05 <@thecrypto> p and alpha can be fixed, alpha will be 2 and p will be</p>
-	 the prime we pick</p>
-18:05 < nop> ok, let me email the prime candidates</p>
-18:05 < nop> give me a couple of hours I have some work to do</p>
-18:05  * jeremiah wanders to dinner, will read logs later</p>
-18:05 <@thecrypto> the serect key is a, a number between 0 and p - 2</p>
-18:05 <@thecrypto> the public key is 2^a mod p</p>
-18:06 < nop> can we move to next topic and come back so I can be here for</p>
-	 that, I'll be right back, at work and have to do a task real quick</p>
-18:06 <@hezekiah> OK, so you call my 'x' as 'a'</p>
-18:06 <@hezekiah> ... and my 'g' as 'alpha'.</p>
-18:06 < nop> please move the algo talk explanations to a private message</p>
-18:06 <@hezekiah> thecrypto: Right?</p>
-18:06 <@thecrypto> yes</p>
-18:06 <@jrand0m> ok.  so thecrypto, nop, and hezekiah will work out the</p>
-	 details of the algo later.</p>
-18:06 < nop> ok</p>
-18:06 < nop> for sure</p>
-18:06 <@hezekiah> OK ... so thecrypto, are you done with your question?</p>
-18:06 <@thecrypto> so let's move on</p>
-18:06 < nop> I'll email our primes</p>
-18:06 <@thecrypto> ye</p>
-18:06 <@thecrypto> s</p>
-18:06 <@hezekiah> OK. My turn! :)</p>
-18:07 <@hezekiah> Why on earth are we using ElGamal for signing?</p>
-18:07 <@jrand0m> ok.  2.4) roadmap / network proto status</p>
-18:07 <@jrand0m> not yet hez :)</p>
-18:07 <@jrand0m> oh hez</p>
-18:07 <@hezekiah> When do I get to ask it?</p>
-18:07 -!- dm [~hifi@anon.iip] has joined #iip-dev</p>
-18:07 <@jrand0m> what would you recommend, when we have ElG public keys?</p>
-18:07 <@thecrypto> when nop gets back</p>
-18:07 <@jrand0m> no, you're right, I'm wrong.  now is the right time.</p>
-18:07 < co> Next topic, please.</p>
-18:07 <@hezekiah> jrand0m: Well, the problem is this:</p>
-18:07 <@hezekiah> speed</p>
-18:08 <@hezekiah> I was playing around with the crypto stuff today, and got</p>
-	 a nasty shock.</p>
-18:08 <@hezekiah> ElGamal was _astronomically_ slower at verifying a signature</p>
-	 than DSA or RSA.</p>
-18:08 <@jrand0m> hezekiah> is that a library implementation problem or</p>
-	 the algorithm?</p>
-18:08 <@hezekiah> I don't know.</p>
-18:09 <@hezekiah> But I checked Applied Crypto and saw that at least _part_</p>
-	 of the problem is with ElGamal.</p>
-18:09 <@hezekiah> AC has tables of the amount of time it takes for signing</p>
-	 and verification for DSA, RSA, and ElGamal.</p>
-18:09 <@jrand0m> so are you suggesting we go to RSA for encryption, decryption,</p>
-	 and signing?</p>
-18:09 <@hezekiah> I</p>
-18:09 <@hezekiah> I'm not really suggesting much that's definate.</p>
-18:09 <@jrand0m> ...though we *could* add a second signing public key to</p>
-	 the RouterInfo structure</p>
-18:10 <@hezekiah> I'm just saying, that AC lists ElGamal verification at</p>
-9.30 seconds.</p>
-18:10 <@hezekiah> RSA is 0.08 seconds</p>
-18:10 <@thecrypto> for 1024 bits</p>
-18:10 <@jrand0m> damn.</p>
-18:10 <@hezekiah> DSA is 1.27 seconds</p>
-18:10 <@hezekiah> Now you see my problem.</p>
-18:10 <@hezekiah> ElGamal is dirt slow ...</p>
-18:10 <@jrand0m> we need sub <100ms verification.</p>
-18:10 <@jrand0m> if not sub <10ms</p>
-18:10 <@hezekiah> ... and my CPU is 333MHz.</p>
-18:11 <@hezekiah> BTW, these calculations were done on a SPARC II</p>
-18:11 <@hezekiah> I've got an AMD K6-2 333MHz.</p>
-18:11 <@jrand0m> a sparc 2 is a 40Mhz machine.</p>
-18:11 <@hezekiah> Verifying an ElGamal sig with my Python module (which uses</p>
-	 a C backend but smells a little fishy).</p>
-18:11 < luckypunk> god</p>
-18:11 < luckypunk> well</p>
-18:11 <@hezekiah> jrand0m: OK. I have no clue about SPARC's.</p>
-18:11 <@hezekiah> Anyway, it took about 20 seconds.</p>
-18:12 <@hezekiah> If not a little more.</p>
-18:12 < luckypunk> anyone with a 1 ghz -2 ghz proc doesn't need to worry.</p>
-18:12 < co> hezekiah: On modern computers, then, the verification should be</p>
-	 acceptably fast.</p>
-18:12 <@hezekiah> DSA and RSA were nearly instantainious.</p>
-18:12 <@jrand0m> hezekiah> I do.  sparc 2 was fast in '92</p>
-18:12 <@hezekiah> Anyway, that's why I bring all this up.</p>
-18:12 <@hezekiah> We could add a DSA key, but that would meen 2 keys</p>
-18:12 <@thecrypto> we should still wonder about people who don't have the</p>
-	 uber fast machines</p>
-18:12 <@hezekiah> Or we could go with RSA.</p>
-18:12 <@jrand0m> my memory of our rationale for ElG as opposed to RSA was</p>
-	 the preference was not very strong.</p>
-18:13 <@hezekiah> Or we can live with the long verification time and use ElG.</p>
-18:13 <@jrand0m> thecrypto> absolutely.</p>
-18:13 <@thecrypto> nop was the one to say, let's use elgamal</p>
-18:13 <@hezekiah> thecrypto: Precisely. Mom and Pop will eventually be</p>
-	 transparently using I2P.</p>
-18:13 <@jrand0m> we're going to want bootable distros for 386s, as well as</p>
-	 in-applet implementations.</p>
-18:13 <@hezekiah> Mom and Pop won't have state of the art hardware.</p>
-18:13 < luckypunk> oh god</p>
-18:14 < luckypunk> everyone who would want this has at least a p100 or so.</p>
-18:14 < co> Let's not compromise security by choosing a weaker algorithm</p>
-	 that is faster.</p>
-18:14 <@hezekiah> co: I'm not suggesting we do.</p>
-18:14 <@thecrypto> elgamal and DSA are equivilent</p>
-18:14 <@jrand0m> ok.  so we're going to revisit the RSA/ElG choice.  the code</p>
-	 changes shouldn't be a problem.</p>
-18:14 < luckypunk> they can suffer.</p>
-18:14 <@hezekiah> co: RSA and DSA are just as reputable as ElGamal.</p>
-18:14 < luckypunk> lol</p>
-18:14 < luckypunk> if you're concerned about anonyminity</p>
-18:14 <@hezekiah> thecrypto: And nothing could be farther from the truth.</p>
-18:14 < luckypunk> you won't care about speed too much.</p>
-18:14 <@thecrypto> hezekiah: they are both implementations of the same</p>
-	 general algorithim</p>
-18:14 < dm> the obvious step here is for someone to figure out for certain</p>
-	 what the CPU usages for the two are :)</p>
-18:14 <@jrand0m> luckypunk> you listen to the complaints wrt freenet much?</p>
-18:15 <@hezekiah> thecrypto: DSA can't encrypt. It's only a sig algo, and</p>
-	 it's a lot faster than ElG.</p>
-18:15 <@thecrypto> hezekiah: it just happens that the signing and verification</p>
-	 equations for DSA are faster</p>
-18:15 <@jrand0m> dm> if Applied Crypto benchmarked RSA verification at</p>
-1/100th ElG, thats enough for me.</p>
-18:15 <@thecrypto> we can use ElG for encryption/decryption and DSA for</p>
-	 signing/verification</p>
-18:15 <@jrand0m> the options are go to RSA or add a DSA key (~256bytes more)</p>
-	 to the RouterInfo structure</p>
-18:15 <@hezekiah> Right. But now the DHT has 2 public keys in it.</p>
-18:16 <@jrand0m> so?</p>
-18:16 < co> Let's have one public key. That will be less confusing.</p>
-18:16 <@hezekiah> co: It would only be 'confusing' for developers ... and</p>
-	 we need to know what we're doing. :)</p>
-18:16 <@thecrypto> i think it's time to wait for nop on this one too</p>
-18:16 <@hezekiah> Right.</p>
-18:16 <@jrand0m> but if its 100times a slow...</p>
-18:16 <@jrand0m> anyway, we'll continue the crypto design discussion offline.</p>
-18:17 <@hezekiah> jrand0m: Email the mailing list, will ya'?</p>
-18:17 < luckypunk> jrand0m: god, i don't mind, if you cant wait 40 sseconds</p>
-	 for your page to load, fuck off.</p>
-18:17 <@thecrypto> or after the main part of the meeting</p>
-18:17 <@jrand0m> shit, I email the list daily :)</p>
-18:17 <@jrand0m> heh lucky</p>
-18:17 -!- hif [~hifi@anon.iip] has joined #iip-dev</p>
-18:17 <@jrand0m> right.</p>
-18:17 <@jrand0m> ok> 2.4) roadmap / network proto status</p>
-18:17 -!- hif is now known as dm2</p>
-18:18 <@jrand0m> I have done very little wrt the network proto beyond</p>
-	 responding to co's messages, as I've been working on the java and I2CP.</p>
-18:18 <@jrand0m> roadmap still seems on target.</p>
-18:18 <@jrand0m> any changes to the roadmap?</p>
-18:19 <@jrand0m> ok.  if there are, whenever there are, just mail the list.</p>
-18:19 <@hezekiah> Right.</p>
-18:19 -!- dm [~hifi@anon.iip] has quit [Ping timeout]</p>
-18:19 <@jrand0m> the roadmap.xml is now in the i2p cvs module</p>
-	 i2p/doc/projectPlan</p>
-18:19 -!- dm2 is now known as dm</p>
-18:20 <@hezekiah> jrand0m: Let me guess ... that's on cathedral too?</p>
-18:20 < nop> back</p>
-18:20 < nop> sorry bout that</p>
-18:20 <@jrand0m> ok, thats it for that (though we can come back to network</p>
-	 protocol questions in the questions section).</p>
-18:20 <@jrand0m> I have no more subitems</p>
-18:20 <@jrand0m> hezekiah> I don't use sf</p>
-18:20 <@thecrypto> well, now that nop is back we can go back to the speed</p>
-	 issue quickly</p>
-18:20 <@hezekiah> Right.</p>
-18:21 < nop> which speed issue</p>
-18:21 <@thecrypto> Elgamal is slow to verify</p>
-18:21 < nop> that's true</p>
-18:21 < nop> but so is rsa</p>
-18:21 <@jrand0m> nop> Applied Crypto benchmarked RSA verification at 1/100th</p>
-	 ElG for signing.</p>
-18:21 < nop> hmm</p>
-18:22 <@hezekiah> RSA and DSA are instantanious for me.</p>
-18:22 <@hezekiah> ElG takes 20 seconds.</p>
-18:22 < nop> DSA is el gamal</p>
-18:22 <@jrand0m> So we can either jump to RSA or add a DSA key to the</p>
-	 RouterInfo structure</p>
-18:22 < nop> DSA</p>
-18:22 < nop> I have anything with R's in it</p>
-18:22 < nop> ;)</p>
-18:22  * jrand0m doesn't remember a really strong reason for ElG as opposed</p>
-	 to RSA</p>
-18:22  * jrand0m resents that</p>
-18:22 <@hezekiah> nop: Will you enlighten us? Why don't we use RSA?</p>
-18:23 <@hezekiah> In all the gory detials. :)</p>
-18:23 < nop> for the reasons of this, and it's debatable, but</p>
-18:23 < dm> someone msg me the URL to the iip-dev again when you get a chance.</p>
-18:23 < nop> factoring primes is how to solve RSA</p>
-18:23 < dm> iip-dev list that is.</p>
-18:23 < luckypunk> RSA has been cracked.</p>
-18:23 < luckypunk> practically.</p>
-18:23 < nop> yes, 512 bit RSA has been cracked</p>
-18:23 < luckypunk> or was it DES?</p>
-18:23 < luckypunk> bah.</p>
-18:23 <@hezekiah> DES has been cracked.</p>
-18:23 < nop> it was DES I think you're talking about</p>
-18:23 < co> luckypunk: Keys of certain size have been cracked.</p>
-18:23 <@hezekiah> RSA is not quite there yet.</p>
-18:24 < nop> anyway</p>
-18:24 < luckypunk> but it might.</p>
-18:24 < nop> back to my point</p>
-18:24 <@hezekiah> But the question is: is a 2048 or 4096 RSA key secure today?</p>
-18:24 <@thecrypto> hold one second</p>
-18:24 < nop> 512 bit RSA keys have been cracked with office computers</p>
-18:24 <@jrand0m> we're looking at 2048bit RSA or ElG</p>
-18:24 < nop> hezekiah: it would be, but here's the fun part</p>
-18:24 < nop> if you can factor primes</p>
-18:24 < nop> you can crack RSA</p>
-18:24 < nop> if you can compute discrete logarithms you can solve RSA and</p>
-	 EL gamal</p>
-18:24 < nop> we're closer to factoring</p>
-18:24 < nop> than we are with computing discrete logs</p>
-18:24 < nop> at this time</p>
-18:24 < luckypunk> isn't discrete logs a bit harder?</p>
-18:25 <@hezekiah> If you can factor primes _quickly_ you can crack RSA.</p>
-18:25 <@hezekiah> luckypunk: That's what nop's saying.</p>
-18:25 < luckypunk> quantum computers.</p>
-18:25 < luckypunk> are damned near to functional.</p>
-18:25 <@hezekiah> lol</p>
-18:25 < nop> and the ratio of bit sizes for pub keys for discrete logs is</p>
-	 stronger than RSA's keys</p>
-18:25 < nop> for instance 768 bit key is not advised by diffie-hellman</p>
-	 variants, but it has not been provably cracked</p>
-18:25 <@hezekiah> So, the end of it is that we add a DSA key.</p>
-18:25 <@thecrypto> nop, don't do a bill gates, it's factor large n where n = pq</p>
-18:25 < nop> as 512 bit RSA keys have</p>
-18:25 <@thecrypto> since factoring prime numbers is easy</p>
-18:25 < nop> thnx</p>
-18:25 < nop> sorry</p>
-18:25 <@jrand0m> hezekiah> thats what its looking like.</p>
-18:26 < nop> I was trying to let everyone understand</p>
-18:26 < nop> sorry</p>
-18:26 <@thecrypto> just a bit of a clarification</p>
-18:26 <@jrand0m> word nop, thats cool, gracias</p>
-18:26 <@hezekiah> OK.</p>
-18:26 < nop> so DSA</p>
-18:26 < nop> then</p>
-18:26 <@hezekiah> So we're adding a DSA key?</p>
-18:26 < nop> which is a diffie-hellman variant as well</p>
-18:26 <@jrand0m> ok, given that, we'll continue crypto details offline.</p>
-18:26 < nop> I'm in favor of logs over factors</p>
-18:27 < nop> ;)</p>
-18:27 <@hezekiah> BTW, what do we still need to continue?</p>
-18:27 < co> dm: That URL is</p>
-	 http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel</p>
-18:27 <@thecrypto> hezekiah: picking the magic prime</p>
-18:27 <@hezekiah> Oh, right!</p>
-18:27 < dm> thanks co, I found jrand0m's specs. Now all I need is a printer</p>
-	 with lots of toner.</p>
-18:27 < nop> I'll send that out</p>
-18:27 <@jrand0m> hezekiah> update the data structure spec, add info wrt the</p>
-	 DSA, specify key size for dsa, etc.</p>
-18:27 < nop> let's do that offline</p>
-18:27 <@jrand0m> lol dm.</p>
-18:28 <@hezekiah> OK, so do you have anything left, jrand0m?</p>
-18:28 <@jrand0m> ok, I'm done with my stuff.  hezekiah> you had # 3?</p>
-18:28 <@hezekiah> Yeah.</p>
-18:28 < dm> hmmm. pictures are not showing up.</p>
-18:28 <@hezekiah> 3.) Whatever nop wants to add to the agenda.</p>
+--- 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</p>
-2003.07.23' with pictures included?</p>
-18:29 < co> dm: Yes, I have had that problem, too.</p>
-18:29 <@jrand0m> dm/co> get the first rev of the network spec (two weeks</p>
-	 prior in the zip), which includes the png.</p>
-18:30 <@jrand0m> (its in cvs too, but thats not anon/public yet)</p>
-18:30 < arj> when will it be? :)</p>
-18:30 <@hezekiah> Wow!</p>
-18:30 <@hezekiah> CVS is fast now!</p>
-18:31 <@jrand0m> arj> we're doing our best to avoid hype, so once its ready</p>
-	 we're going to put things public, but keep it largely quiet until.</p>
-18:31 < nop> hezekiah: what the cathedral one?</p>
-18:31 <@jrand0m> arj> however, everything we're doing is GPL, at least so far.</p>
-18:31 <@hezekiah> nop: Yeah</p>
-18:31 <@hezekiah> !</p>
-18:31 < dm> two weeks prior in which zip?</p>
-18:31 <@jrand0m> oh word, you got it working hezekiah?</p>
-18:31 < arj> jrand0m: just wanted to read the latest specs</p>
-18:31 <@jrand0m> dm> network_spec_*.zip iirc</p>
-18:31 <@hezekiah> jrand0m: Yup! :)</p>
-18:31 < dm> same here, with pictures!</p>
-18:31 <@thecrypto> iip-dev has most of it</p>
-18:32 <@jrand0m> arj></p>
-	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/292 has</p>
-	 all but one tiny change.</p>
-18:32 <@jrand0m> (well, except for the Client Access Layer, which is in a</p>
-	 different spec now)</p>
-18:33 < arj> ok thanx</p>
-18:33 <@jrand0m> the client access layer spec is</p>
-	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/298</p>
-18:33 < dm> ok, and the link to the zip with the pictures?</p>
-18:33 <@jrand0m> ok.  nop you have anything, or we "5) opening up to</p>
-	 questions/thoughts from the masses"?</p>
-18:34 -!- mihi [none@anon.iip] has quit [Ping timeout]</p>
-18:34  * jeremiah is back and has read the backlog</p>
-18:34 <@jrand0m> dm> h/o, pulling it up</p>
-18:34 <@jrand0m></p>
-	 http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/269</p>
-18:35 < dm> ty</p>
-18:35 <@jrand0m> ok, any questions / thoughts?</p>
-18:35 -!- arj [anders@anon.iip] has quit [EOF From client]</p>
-18:35 < co> yes.</p>
-18:35 <@jrand0m> np</p>
-18:35 < co> Are we on item 5 now?</p>
-18:35  * jrand0m knew you'd have some co :)</p>
-18:35 < co> Currently, communication between client and router (outgoing)</p>
-	 is not encrypted.</p>
-18:35 <@jrand0m> yes, since nop is slow :)</p>
-18:35 <@jrand0m> (damn people with jobs and stuff)</p>
-18:36 <@hezekiah> lol</p>
-18:36 < co> Suppose I have a trusted friend and want to use his router for</p>
-	 outgoing messages.</p>
-18:36 <@hezekiah> jrand0m: Well, you know. Not everyone can aford not having</p>
-	 a life.</p>
-18:36 <@jrand0m> co> largely correct.  message payloads are encrypted,</p>
-	 but the rest of I2CP isn't</p>
-18:36 < co> Wouldn't that put me at risk of having my messages captured.</p>
-18:37 <@hezekiah> Yeah. They would be transfered in the clear over the wire.</p>
-18:37 <@hezekiah> Unless you ssh tunnel to his router or something.</p>
-18:37 <@jrand0m> if you have a trusted friend and connect to their router,</p>
-	 they can know that you sent or recieved a message, but they can't know what</p>
-	 you sent.</p>
-18:37 <@jeremiah> wouldn't the messages still go under public key encryption?</p>
-18:37 <@hezekiah> Oops.</p>
-18:37 <@hezekiah> My bad.</p>
-18:37 < dm> I'm gonna use I2P as a way to learn new stuff to prevent 9to5</p>
-	 (windows admin, VB tools) job from turning me into a zombie.</p>
-18:37 <@jrand0m> I'm fine with adding SSL listener support, as opposed to</p>
-	 just TCP listener.</p>
-18:37 <@hezekiah> I forgot that clients to end to end encryption.</p>
-18:37 < co> Your assumption is that I run a local trusted router, but as</p>
-	 stated above, I might not want to do that so that messages would not be</p>
-	 connected to me.</p>
-18:37 <@jrand0m> yes jeremiah, but thats only for the payload</p>
-18:37 <@jrand0m> heh word dm</p>
-18:37 -!- mihi [none@anon.iip] has joined #iip-dev</p>
-18:38 <@jrand0m> hmm.</p>
-18:38 <@hezekiah> jrand0m: Why not add support later on for client-to-router</p>
-	 comm to be encrypted?</p>
-18:38 <@jrand0m> you really always should have a local trusted router.</p>
-	 you can have it connect to another known non-local trusted router too.</p>
-18:39 < co> True, but I would like to second hezekiah's suggestion.</p>
-18:39 <@jrand0m> hezekiah> I'm fine with adding it later (where later:</p>
-	 t=0...releaseDate ;)</p>
-18:40 <@jrand0m> I have absolutely no qualms with even adding support for</p>
-	 DH+AES for I2CP</p>
-18:40 < nop> good</p>
-18:40 <@jrand0m> actually, those features can be added on per-router basis</p>
-	 as well</p>
-18:41 < nop> jrand0m: also I believe the polymorphic key rotation will be</p>
-	 needed as well as chaffe traffic</p>
-18:41 < nop> I'm sure we're looking at that at a later meeting</p>
-18:41 < nop> just my side comment</p>
-18:41 < nop> using key sets</p>
-18:41 <@jrand0m> yes, when we touch the router-router comm.</p>
-18:41 <@jrand0m> (1-2 weeks off)</p>
-18:41 < co> nop: Currently, I don't see chaffe traffic in the spec, but it</p>
-	 would be good to add.</p>
-18:42 <@jrand0m> there is chaffe, in the sense that routers and tunnel</p>
-	 participants test themselves and their peers.</p>
-18:42 -!- arj [~anders@anon.iip] has joined #iip-dev</p>
-18:42 <@jrand0m> plus DHT requests are chaffe wrt payload messages</p>
-18:42 < nop> jrand0m: well I'll dive into some research on evading some</p>
-	 traffic analysis and giving away any known plaintext</p>
-18:42 <@jrand0m> *and* individual transports will have hteir own chaffe styles</p>
-	 (e.g. http transport will query google for "cute puppy dogs" periodically,</p>
-	 or whatever)</p>
-18:43 < nop> well, that chaffe is nice, but I also mean encrypted chaffe</p>
-18:43 < nop> this helps rotate the session keys</p>
-18:43 < nop> and keep your node busy even when inactive</p>
-18:43 < dm> maybe change that to hard child porn for more realistic chaffe</p>
-18:43 <@jrand0m> word.</p>
-18:43 < dm> just kidding!</p>
-18:43 <@hezekiah> dm: Good. Otherwise I'd have to !thwack you.</p>
-18:43 <@hezekiah> :)</p>
-18:44 <@jrand0m> DHT (link encrypted) and test messages (free route mix,</p>
-	 ala onion/garlic) won't have known plaintext problems</p>
-18:44 < nop> since newer nodes will have less traffic when starting out</p>
-18:44 <@jrand0m> plus we'll have support for constant bitrate transports</p>
-18:44 < nop> garlic rocks</p>
-18:44 < nop> :)</p>
-18:44 < nop> jrand0m: DC net style :)</p>
-18:44  * jrand0m is making some pasta w/ lots of garlic after this meeting</p>
-	 is over</p>
-18:45 < nop> jrand0m: I meant garlic routing</p>
-18:45 <@hezekiah> lol!</p>
-18:45 <@jrand0m> i know ;)</p>
-18:45 < nop> jrand0m: anyway, constant bitrate could be forced with the</p>
-	 block encryption since AES generates 128 bit blocks</p>
-18:45 < nop> ;)</p>
-18:45 < nop> so we could just pad all data to be 16 bytes per message</p>
-18:45 <@jrand0m> co> did my answers to your email make sense?</p>
-18:47 <@jrand0m> *ping*</p>
-18:47 <@hezekiah> *pong*</p>
-18:47 <@thecrypto> *pong</p>
-18:47 <@thecrypto> *</p>
-18:47 <@jrand0m> any other questions from anyone, or has my iproxy</p>
-	 disconnected?</p>
-18:47 <@jrand0m> heh word</p>
-18:47 <@hezekiah> thecrypto: Fragmented packet!</p>
-18:47 <@hezekiah> lol</p>
-18:48 <@thecrypto> lost that tail end there</p>
-18:48 <@thecrypto> smaller MTU here :)</p>
-18:48 <@hezekiah> jrand0m: Well, I have no questions.</p>
-18:48 < co> jrand0m: Yes, the answers made sense.</p>
-18:48 < co> I have no more questions.</p>
-18:48 < dm> I shall create questions when I read the specs tomorrow.</p>
-18:49 <@jrand0m> well, I hope you have more later :)</p>
-18:49 <@jrand0m> awesome dm</p>
-18:49 < dm> awesome initially maybe.</p>
-18:49 < dm> well, i'm off. good luck people!</p>
-18:49 -!- dm [~hifi@anon.iip] has quit []</p>
-18:50 <@jrand0m> we *do* still have the big 2 week peer review period in</p>
-	 the schedule, but review before then is appreciated (even though all the</p>
-	 details haven't yet been put in)</p>
-18:51 <@jrand0m> ok.  any other questions, or are we going to wrap up #52</p>
-	 as a 102 minute meeting?</p>
-18:52 <@thecrypto> #51</p>
-18:52 <@hezekiah> Uh, I read 1:57 minutes.</p>
-18:52 <@hezekiah> Duh.</p>
-18:52 <@hezekiah> I'm stupid</p>
-18:52 <@hezekiah> Never mind me.</p>
-18:52 <@hezekiah> I have no questions ...</p>
-18:52 <@hezekiah> Questions!</p>
-18:52  * jrand0m could never add...</p>
-18:52 <@hezekiah> Speak now or hold you peace until next Tuesday!</p>
-18:52 <@hezekiah> Going once!</p>
-18:53 <@hezekiah> ... Going twice!</p>
-18:53 <@thecrypto> Sold to the guy in a button down shirt</p>
-18:53 <@hezekiah> Gone!</p>
-18:53  * jrand0m goes to the kitchen to make some long overdue dinner</p>
-18:53 <@jrand0m> gracias srs y srtas</p>
-18:53 <@hezekiah> Goodbye everyone!</p>
-18:53 <@jeremiah> I should checkout the source before I wander off</p>
-18:53 <@hezekiah> See you next Tuesday!</p>
---- Log closed Tue Jul 29 18:53:55 2003</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/51.rst b/i2p2www/meetings/51.rst
new file mode 100644
index 00000000..f20c1544
--- /dev/null
+++ b/i2p2www/meetings/51.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 29, 2003 @ 21:11 UTC
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/52.log b/i2p2www/meetings/52.log
index 19f599ca..fbe15fd8 100644
--- a/i2p2www/meetings/52.log
+++ b/i2p2www/meetings/52.log
@@ -1,381 +1,376 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 52{% endblock %}
-{% block content %}<div class="irclog">
-<nop>	ok, meeting started</p>
-<nop>	what's on the agenda</p>
--->	logger (logger@anon.iip) has joined #iip-dev</p>
--->	Anon02 (~anon@anon.iip) has joined #iip-dev</p>
-<hezekiah>	Tue Aug  5 21:03:10 UTC 2003</p>
-<hezekiah>	Welcome to the Nth iip-dev meeting.</p>
-<hezekiah>	What's on the agenda?</p>
-<thecrypto>	Tue Aug  5 21:02:44 UTC 2003</p>
-<thecrypto>	synced to a NTP stratum 2 :)</p>
-<hezekiah>	Tue Aug  5 21:03:13 UTC 2003</p>
--->	ptm (~ptm@anon.iip) has joined #iip-dev</p>
-<hezekiah>	Just synced to NIST. :)</p>
-<mihi>	this sync does not help w/ iip delays ;)</p>
-<jrand0m>	nop: things I want to see covered: java dev status, java crypto</p>
-	  status, python dev status, sdk status, naming service</p>
-<hezekiah>	(We're going into the naming service _already_?)</p>
-<jrand0m>	not design you wanker, thats co's schpeel.  just talk about stuff</p>
-	  if there's stuff to talk about.</p>
-<hezekiah>	Ah</p>
-*	jrand0m puts LART away</p>
-<jrand0m>	anything else on the agenda?</p>
-<jrand0m>	or shall we dig in?</p>
-<hezekiah>	Well, I can't think of anything else to add.</p>
-<hezekiah>	Ah!</p>
-<hezekiah>	Oh!</p>
-<jrand0m>	ok.  java dev status:</p>
-<hezekiah>	Good.</p>
-<--	mrflibble has quit (Ping timeout)</p>
-<nop>	ok</p>
-<nop>	agenda</p>
-<nop>	1) Welcome</p>
-<jrand0m>	as of today, there is a java client API with a stub java router</p>
-	  that can talk to each other.  in addition, there is an application called ATalk</p>
-	  allowing anonymous IM + file transfer.</p>
-<nop>	2) IIP 1.1 blackouts</p>
-<nop>	3) I2P</p>
-<nop>	4) The End with comments and stuff</p>
-*	jrand0m goes back to corner</p>
-<nop>	sorry</p>
-	  joeyo jrand0m Aug 05 17:08:24 * hezekiah gives jrand0m a dunce hat to wear in</p>
-	  the corner. ;-)</p>
-<nop>	sorry about that</p>
-<nop>	didn't see you started there</p>
-<nop>	maybe I should go in corner</p>
-<hezekiah>	lol</p>
-<jrand0m>	no worry.  item 1)</p>
-*	hezekiah hands nop a dunce hat too. :)</p>
-<nop>	ok welcome everybuddy</p>
-<nop>	blah blah</p>
-<nop>	2) IIP 1.1 blackouts</p>
--->	mrflibble (mrflibble@anon.iip) has joined #iip-dev</p>
-<hezekiah>	52nd iip-dev meeting and all that good rot!</p>
-<nop>	the server recently had some issues with the hard drive sectors and has</p>
-	  been replaced</p>
-<nop>	I plan to be moving the darn server into a more stable environment with</p>
-	  redundancy</p>
-<nop>	and possibly lend out control of multiple ircd servers</p>
-<nop>	dunno</p>
-<nop>	that's something to be discussed</p>
-<--	Anon02 has quit (EOF From client)</p>
-<nop>	hopefully our servers should stay up now since the harddrive was replaced</p>
-<nop>	sorry about the inconvenience folks</p>
-<nop>	3) I2P - Jrand0m take it away</p>
-<nop>	come out of the corner jrand0m</p>
-*	hezekiah goes over to the corner, pulls jrand0m off his chair, drags him</p>
-	  to the podium, takes away his dunce hat, and hands him the mic.</p>
-*	nop goes into that corner to fill his place</p>
-<hezekiah>	lol!</p>
-<jrand0m>	sorry, back</p>
-*	nop grabs dunce hat from hezekiah</p>
-*	nop puts it on his head</p>
-*	nop applauds for jrand0m</p>
-*	jrand0m just watches the show</p>
-<jrand0m>	er... um ok</p>
-<hezekiah>	jrand0m: i2p, java status, etc. Talk man!</p>
-<jrand0m>	so, as of today, there is a java client API with a stub java</p>
-	  router that can talk to each other.  in addition, there is an application called</p>
-	  ATalk allowing anonymous IM + file transfer.</p>
-<hezekiah>	File transfer already!?</p>
-<jrand0m>	si sr</p>
-<hezekiah>	Wow.</p>
-<hezekiah>	I'm sure behind the times.</p>
-<jrand0m>	but not the most graceful</p>
-<hezekiah>	lol</p>
-<jrand0m>	it takes a file and tosses it in a message</p>
-<hezekiah>	Ouch.</p>
-<nop>	how long did 1.8 mb local transfer take?</p>
-<jrand0m>	I've tested with a 4K file and a 1.8Mb file</p>
-<jrand0m>	a few seconds</p>
-<nop>	nice</p>
-<nop>	:)</p>
-<hezekiah>	Does the java stuff do real encryption yet, or does it still</p>
-	  fake that?</p>
-<nop>	fake</p>
-<nop>	even I know that</p>
-<nop>	:)</p>
-<jrand0m>	I warmed it up by talking to myself first [e.g. one window to</p>
-	  another, saying hi] so it didn't deal with the overhead of the first elg</p>
-<jrand0m>	right, its faked largely</p>
-<thecrypto>	most of the encryption is fake</p>
-<thecrypto>	that's being worked on though</p>
-<hezekiah>	Of course. :)</p>
-<jrand0m>	definitely.</p>
-<jrand0m>	on that front, wanna give us an update thecrypto?</p>
-<thecrypto>	well, right now i'm done with ElGamal and SHA256</p>
-<thecrypto>	right now I'm working on generating primes for DSA</p>
-<thecrypto>	I'll send out 5 and then we can just pick one</p>
-<hezekiah>	nop: Didn't you have prime(s) coming for use with DSA?</p>
-<thecrypto>	We also have some benchmarks on ElGamal and SHA256</p>
-<thecrypto>	And they are all fast</p>
-<jrand0m>	latest benchmarks w/ elg:</p>
-<jrand0m>	Key Generation Time Average: 4437	total: 443759	min:</p>
-	  872	   max: 21110	   Keygen/second: 0</p>
-<jrand0m>	Encryption Time Average    : 356	total: 35657	min:</p>
-	  431	   max: 611	   Encryption Bps: 179</p>
-<jrand0m>	Decryption Time Average    : 983	total: 98347	min:</p>
-	  881	   max: 2143	   Decryption Bps: 65</p>
+<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?</p>
-<jrand0m>	note that the Bps isn't really useful, as we only encrypt/decrypt</p>
-	  64 bytes</p>
-<thecrypto>	ms</p>
-<jrand0m>	no, sorry, those are all milliseconds</p>
-<hezekiah>	Cool. :)</p>
-<hezekiah>	And this is done in java?</p>
-<thecrypto>	yes</p>
-<thecrypto>	pure java</p>
-<hezekiah>	OK. I am officiall impressed. :)</p>
-<jrand0m>	100%.  P4 1.8</p>
-<thecrypto>	they are about the same on my 800 Mhz</p>
-<hezekiah>	How can I do the same tests?</p>
-<jrand0m>	sha256 benchmark:</p>
-<jrand0m>	Short Message Time Average  : 0 total: 0	min: 0	max:</p>
-	  0  Bps: NaN</p>
-<jrand0m>	Medium Message Time Average : 1 total: 130	min: 0	max:</p>
-	  10 Bps: 7876923</p>
-<jrand0m>	Long Message Time Average   : 146	total: 14641	min:</p>
-	  130	   max: 270	   Bps: 83037</p>
-<thecrypto>	run the ElGamalBench program</p>
-<hezekiah>	OK.</p>
-<hezekiah>	I'll go find it.</p>
-<jrand0m>	(short size: ~10 bytes, medium ~10KB, long ~ 1MB)</p>
-<jrand0m>	java -cp i2p.jar ElGamalBench</p>
-<jrand0m>	(after running "ant all")</p>
-<hezekiah>	jrand0m: Thanks. :)</p>
-<jrand0m>	np</p>
-<thecrypto>	The NaN thing means it's so fast that we end up dividing by 0</p>
-	  it's so fast :)</p>
-<hezekiah>	What's the sha bench?</p>
-<jrand0m>	java -cp i2p.jar SHA256Bench</p>
--->	Neo (anon@anon.iip) has joined #iip-dev</p>
-<hezekiah>	OK.</p>
-<jrand0m>	we'll probably want to move those to be main() methods of the</p>
-	  associated engines, but they're good where they are atm</p>
-<hezekiah>	Let's see how fast all this is on an AMD K6-2 333MHz (which is</p>
-	  a chip not well know for its integer math.)</p>
-<jrand0m>	heh</p>
-<jrand0m>	ok so we have DSA and AES left, right?</p>
-<jrand0m>	this is all wikked thecrypto.  nice work.</p>
-<thecrypto>	yup</p>
-<jrand0m>	can I nag you for an ETA on the other two?  ;)</p>
-<hezekiah>	If this is anywhere near as fast on my box as it is on yours,</p>
-	  you have to show me how you do that. ;-)</p>
-<thecrypto>	DSA should be done almost as soon as i have primes ready</p>
-<nop>	hezekiah have you tried the sslcrypto for python</p>
-<thecrypto>	copying some code around from the prime generator and things like</p>
-	  that and it's done</p>
-<nop>	the one off that link</p>
-<hezekiah>	nop: sslcrypto won't do us any good.</p>
-<hezekiah>	nop: It doesn't implment ElGamal _or_ AES _or_ sha256.</p>
-<thecrypto>	AES is mostly done except that there is some error somewhere that</p>
-	  i'm still trying to pick out and destroy, once i have that, it'll be done</p>
-<jrand0m>	thecrypto> so by friday, DSA keygen, sign, verify, and AES encrypt,</p>
-	  decrypt for arbitrary size inputs?</p>
-<nop>	the one on McNab's site does not?</p>
-<thecrypto>	yeah</p>
-<nop>	darn</p>
-<thecrypto>	should be friday</p>
-<thecrypto>	most likey thursday</p>
-<jrand0m>	thecrypto> does that include the UnsignedBigInteger stuff?</p>
-<thecrypto>	i'll be missing next weeks meeting because of summer camp, and</p>
-	  i'll be back after that</p>
-<thecrypto>	jrand0m: prolly not</p>
-<jrand0m>	ok.</p>
-<jrand0m>	so for the time being, interoperability between java and python</p>
-	  is b0rked.</p>
-<jrand0m>	for crypto, that is.</p>
----	Notify: jeremiah is online (anon.iip).</p>
--->	jeremiah (~chatzilla@anon.iip) has joined #iip-dev</p>
-<jrand0m>	(aka for signatures, keys, encryption, and decryption)</p>
+<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++</p>
-<thecrypto>	well, once we get it working completely we can then make sure</p>
-	  both java and python can speak to each other</p>
-<jrand0m>	while you're out I'll look into the unsigned stuff.</p>
-<jeremiah>	can someone email me a backlog? jeremiah@kingprimate.com</p>
-<hezekiah>	jeremiah: Give me a minute. :)</p>
-<jrand0m>	nop> do we have devs for C/C++?</p>
-<nop>	I have one guy yes</p>
-<nop>	and Hezekiah we know could do it</p>
-<jrand0m>	or perhaps we can get a python dev status update from hezekiah +</p>
-	  jeremiah to see when we'll have more people for the c/c++ dev</p>
-<jrand0m>	right, of course.  but hez+jeremiah are working on python atm</p>
-	  (right?)</p>
-<hezekiah>	Yeah.</p>
-<--	mrflibble has quit (Ping timeout)</p>
-<hezekiah>	I'm sort of giving poor jeremiah lots of trouble.</p>
-<nop>	I was just saying if python won't be fast speeds</p>
-<hezekiah>	Python is mainly for me to understand this network.</p>
-<nop>	ahh</p>
-<hezekiah>	Once, I get it to basically follow the complete spec, I intend</p>
-	  to hand it off to jeremiah to do with as he sees fit.</p>
-<hezekiah>	It's not meant to be a killer implementation of the spec.</p>
-<hezekiah>	(If I wanted that, I'd use C++.)</p>
-<jeremiah>	well there aren't any really processor intensive parts of the app,</p>
-	  iirc, aside from crypto, and ideally that will be handled in C anyways, right?</p>
-<jrand0m>	sure jeremiah.	all depends on the app</p>
--->	mrflibble (mrflibble@anon.iip) has joined #iip-dev</p>
-<hezekiah>	jeremiah: In theory.</p>
-<jrand0m>	so where are we on the python side?  client api, local only</p>
-	  router, etc?</p>
-<jeremiah>	the python implementation will also let us know what optimizations</p>
-	  we could make from the start... I'd like to keep it up to date or, possibly,</p>
-	  ahead of the C implementation as I can</p>
-<hezekiah>	jrand0m: OK. Here's what I've got.</p>
-<hezekiah>	In _theory_ the router should be able to handle all non-admin</p>
-	  messages from a client.</p>
-<hezekiah>	However, I don't have client yet, so I haven't been able to debug</p>
-	  it (i.e. there are still bugs.)</p>
-<hezekiah>	I'm working on the client right now.</p>
-<jrand0m>	'k.  if you can disable signature verification, we should be able</p>
-	  to run the java client against it now</p>
-<hezekiah>	I'm hoping to have that done except for admin messages in a day</p>
-	  or two.</p>
-<jrand0m>	we can test that out after the meeting</p>
-<hezekiah>	jrand0m: OK.</p>
-<jeremiah>	I've been dealing with real-world stuff mostly since the last</p>
-	  meeting, I can work on the client API, just been trying to sync my thinking</p>
-	  with hezekiah's</p>
-<jrand0m>	cool</p>
-<hezekiah>	jeremiah: You know what, just wait.</p>
-<hezekiah>	jeremiah: I'm probably throwing in too much new stuff for you to</p>
-	  deal with right now.</p>
-<jeremiah>	hezekiah: right, what I was going to say is that you should</p>
-	  probably just go ahead and implement the base stuff</p>
-<hezekiah>	jeremiah: In a little while, it will be stabalized and you can</p>
-	  start refining it. (There are lots of TODO comments that need help.)</p>
-<jeremiah>	and then I can extend it later once I get the picture</p>
-<hezekiah>	Exactly.</p>
-<hezekiah>	You get to maintain all this code. :)</p>
-<jrand0m>	cool.  so eta 1-2 weeks for a working python router + client api?</p>
-<hezekiah>	I'm going on vacation next week so probably.</p>
-<hezekiah>	Are we going to have more details on router to router soon?</p>
-<jrand0m>	no.</p>
-<jrand0m>	well, yes.</p>
-<jrand0m>	but no.</p>
-<hezekiah>	lol</p>
-<jeremiah>	hezekiah: how long is the vacation?</p>
-<hezekiah>	1 week.</p>
-<jeremiah>	ok</p>
-<jrand0m>	(aka as soon as the SDK goes out, 100% of my time goes into I2NP)</p>
-<hezekiah>	I'm hoping to have all non-admin functionality written before I</p>
-	  go on vacation</p>
-<hezekiah>	.</p>
-<jrand0m>	but then soon after you get back you're off to college, right?</p>
-<hezekiah>	I2NP?</p>
-<hezekiah>	Right.</p>
-<jrand0m>	network proto</p>
-<hezekiah>	I have about 1 week after vacation.</p>
-<hezekiah>	Then I'm gone.</p>
-<hezekiah>	And my free time drops like a stone.</p>
-<jrand0m>	so that 1 week should only be debugging</p>
-<jeremiah>	I can work on the code while hez is gone though</p>
-<jrand0m>	word</p>
-<jrand0m>	whats your summer look like jeremiah?</p>
-<hezekiah>	jeremiah: Perhaps you can get those admin functions working?</p>
+<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</p>
-	  on things</p>
-<jrand0m>	having a life, or being like the rest of us l00sers?  :)</p>
-<jeremiah>	maybe</p>
-<hezekiah>	100sers?</p>
-<hezekiah>	What's a 100ser?</p>
-<jeremiah>	i leave for college on the 22nd, other than that I can dev</p>
-<mihi>	hezekiah: a loser</p>
-<jeremiah>	and the last week before I leave all my friends will be gone... so</p>
-	  I can go into hyperdev mode</p>
-<hezekiah>	mihi: Ah!</p>
-<jrand0m>	hehe</p>
-<hezekiah>	OK. So where were we on the agenda?</p>
-<hezekiah>	i.e. What's next?</p>
-<jrand0m>	sdk status</p>
-<jrand0m>	sdk == one client impl, a local only router impl, an app, and docs.</p>
-<jrand0m>	I'd like to have that out by next tuesday.</p>
-<hezekiah>	jeremiah: That backlog is on the way. Sorry I forgot you there. :)</p>
-<jeremiah>	thanks</p>
-<jrand0m>	ok, co isn't around, so the naming service stuff is prolly a bit</p>
-	  off base</p>
-<jrand0m>	we can discuss the naming service after he puts out specs or</p>
-	  he's around</p>
-<jrand0m>	ok, thats it for I2P stuff</p>
-<jrand0m>	anyone else have I2P stuff, or we on to: <nop> 4) The End with</p>
-	  comments and stuff</p>
-<hezekiah>	I can't think of anything.</p>
-<jrand0m>	I assume everyone's seen</p>
-	  http://www.cnn.com/2003/TECH/internet/08/05/anarchist.prison.ap/index.html ?</p>
-<thecrypto>	not here</p>
-<jrand0m>	(nop posted it here earlier)</p>
-<hezekiah>	The thing about the guy who got arrested for linking to a bomb</p>
-	  building site?</p>
-<jrand0m>	yes</p>
-<jrand0m>	relevence to the need to get I2P up ASAP should be aparent ;)</p>
-<hezekiah>	OK! jeremiah, those logs are now sent.</p>
-<jeremiah>	thanks</p>
-<jrand0m>	anyone have any questions / comments / thoughts / frisbees,</p>
-	  or are we having a record breaking short meeting?</p>
-*	thecrypto tosses a frisbee</p>
-<--	logger has quit (Ping timeout)</p>
-<jrand0m>	damn y'all are quiet today ;)</p>
-<mihi>	question:</p>
-<mihi>	where can non devs get yout java code?</p>
-<jrand0m>	si sr?</p>
-<thecrypto>	not yet</p>
-<mihi>	404</p>
-<jrand0m>	that'll be made available once we're release ready.  aka the</p>
-	  source will go out with the SDK</p>
-<jrand0m>	heh</p>
-<jrand0m>	yeah, we don't use SF</p>
-<hezekiah>	nop: Is it possible that we can get anonymous cvs working some tiem?</p>
-<hezekiah>	time?</p>
-<--	mrflibble has quit (Ping timeout)</p>
-<nop>	well, I would open up a non-standard port</p>
-<jrand0m>	hezekiah> we'll have that once the code has the GPL license on there</p>
-<nop>	but I am working on viewcvs</p>
-<jrand0m>	aka not now since the gpl doc hasn't been added to the code yet</p>
-<hezekiah>	jrand0m: It's in all the python code directories and all python</p>
-	  source files speceify licensing under GPL-2.</p>
-<jrand0m>	hezekiah> is that on the cathedral?</p>
-<hezekiah>	Yes.</p>
-<jrand0m>	ah word.  i2p/core/code/python ?  or a different module?</p>
-*	jrand0m hasn't seen it in there</p>
-<hezekiah>	Each python code directory has a COPYING file in it with the</p>
-	  GPL-2 and each source file has the license set a GPL-2</p>
-<hezekiah>	It's i2p/router/python and i2p/api/python</p>
-<jrand0m>	'k</p>
-<jrand0m>	so, yeah, by next tuesday we'll have the SDK + public source access.</p>
-<hezekiah>	Cool.</p>
-<hezekiah>	Or as you like to say, wikked. ;-)</p>
-<jrand0m>	heh</p>
-<jrand0m>	nada mas?</p>
-<hezekiah>	nada mas? What's that mean!?</p>
-<jeremiah>	nothing more</p>
-*	jrand0m suggests you learn a lil espanol en universidad</p>
--->	mrflibble (mrflibble@anon.iip) has joined #iip-dev</p>
-<hezekiah>	Questions anyone?</p>
-<hezekiah>	Going once!</p>
-<--	ptm (~ptm@anon.iip) has left #iip-dev (ptm)</p>
-<hezekiah>	Going twice!</p>
-<--	mrflibble has quit (mr. flibble says "game over boys")</p>
-<hezekiah>	Speak now .. or wait until you feel like speaking later!</p>
-<thecrypto>	okay, i'm going to be optimizing the elgamal even more, so expect</p>
-	  even faster elgamal benches in the future</p>
-<jrand0m>	please focus on DSA and AES before tuning... puhleeeease :)</p>
-<thecrypto>	i will</p>
-<hezekiah>	The reason he's doing that is 'cause I'm causing trouble for</p>
-	  people again. ;-)</p>
-<thecrypto>	i'm making DSA primes</p>
--->	mrflibble (mrflibble@anon.iip) has joined #iip-dev</p>
-<thecrypto>	well, at least making the program to make DSA primes right now</p>
-<hezekiah>	ElGamal in Java doesn't like an AMD K-6 II 333MHz.</p>
-<hezekiah>	OK.</p>
-<hezekiah>	Question round is over!</p>
-<jrand0m>	ok hez, we're done.  you wanna powow on getting the java client</p>
-	  and the python router work?</p>
-<hezekiah>	See you all next week citizens!</p>
-*	hezekiah smashes down the *baf*er</p>
-</div>
-{% endblock %}
\ No newline at end of file
+<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/52.rst b/i2p2www/meetings/52.rst
new file mode 100644
index 00000000..6bfa4525
--- /dev/null
+++ b/i2p2www/meetings/52.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 5, 2003 @ 21:02 UTC
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/53.log b/i2p2www/meetings/53.log
index 28d964c1..21ca3b19 100644
--- a/i2p2www/meetings/53.log
+++ b/i2p2www/meetings/53.log
@@ -1,113 +1,108 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 53{% endblock %}
-{% block content %}<div class="irclog">
-[21:09] <jrand0m> ok.  21:00 UTC esta ahora</p>
-[21:09] <jrand0m> welcome to the um meeting</p>
-[21:09] <jrand0m> we have a lot of people out today (nop, hezekiah, thecrypto, and userx), so we'll keep it brief</p>
-[21:10] <jrand0m> agenda: 1) hi 2) sdk 3) status 4) questions</p>
-[21:10] <jrand0m> 1) hi</p>
-[21:10] <jrand0m> hello.</p>
-[21:10] <jrand0m> 2) sdk</p>
-[21:11] <jrand0m> the I2P SDK 0.1 is ready for quiet release.  </p>
-[21:11] <mihi> quiet release?</p>
-[21:11] <jrand0m> basically we're not publicizing it except for people in the know, and those trusted by people in the know</p>
-[21:12] <jrand0m> it is however fully ready to do application design, development, and testing with</p>
-[21:12] <jrand0m> If you're on #iip-dev, you're in the know</p>
-[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</p>
-[21:13] * UserX has joined #iip-dev</p>
-[21:13] <jrand0m> hey, its UserX</p>
-[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</p>
-[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.</p>
-[21:16] <mihi> september that never ended? ;)</p>
-[21:16] <jrand0m> (rather than having the network up and running with no applications)</p>
-[21:16] <jrand0m> heh</p>
-[21:16] <jrand0m> no, we're actually beating the schedule I posted to iip-dev a few weeks back in the ganttproject document</p>
-[21:16] <jrand0m> not by much (5 days), but beating it none the less.</p>
-[21:17] <jrand0m> I'm quite confident that we'll be 1.0alpha in september.</p>
-[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.</p>
-[21:18] <jrand0m> Then, hopefully next week we can have some internal review and revisions, after which we can go into peer review.</p>
-[21:18] * shardy_ is now known as shardy</p>
-[21:18] <jrand0m> 'lo shardy</p>
-[21:18] <shardy> hiya.</p>
-[21:18] <shardy> how goes?</p>
-[21:19] <jrand0m> wikked.  </p>
-[21:19] <jrand0m> I hear rumors we might be able to get some of your time for some .net client lib stuff?</p>
-[21:19] * jrand0m may be misinformed</p>
-[21:20] * ion has quit IRC (Ping timeout)</p>
-[21:21] <shardy> .net? nope, that's not me...</p>
-[21:21] <jrand0m> ah 'k, my bad</p>
-[21:21] <jrand0m> soy muy tonto</p>
-[21:21] <jrand0m> well, hi anyway :)</p>
-[21:21] <jrand0m> I also got some feedback from co wrt the naming service application</p>
-[21:22] * ion has joined #iip-dev</p>
-[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: </p>
-[21:22] <jrand0m> 1. Client program to interact with naming service.</p>
-[21:22] <jrand0m> 2. Program for the naming service itself.</p>
-[21:22] <jrand0m> 3. Administrative utilities for the naming service.</p>
-[21:22] <jrand0m> 4. A Certificate Authority (CA) component."</p>
-[21:23] <jrand0m> That's co's status report</p>
-[21:23] <jrand0m> I think that may be it for status, unless someone has something to add.</p>
-[21:24] <shardy> neat.</p>
-[21:24] <jrand0m> definitely neat</p>
-[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.</p>
-[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.</p>
-[21:25] <jrand0m> I'll be posting a new version probably on friday.</p>
-[21:25] <jrand0m> (and as this project only began in earnest maybe a month ago, we're open for variations in how we work)</p>
-[21:26] <jrand0m> oh wait, now I remember, you're the ecc guy :)</p>
-[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.</p>
-[21:27] <jrand0m> oh nice.  we're currently using generic prngs, and will want a better way to deal with random data</p>
-[21:27] <jrand0m> ok</p>
-[21:27] <shardy> generic ones? nop mentioned using yarrow, which seems pretty good.</p>
-[21:28] <shardy> I'm doing implementation work on a new prng now. trying to reduce the theory and practice gap somewhat. :)</p>
-[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)</p>
-[21:28] <jrand0m> heh</p>
-[21:29] <mihi> be careful w/ yarrow from freenet, it does heisenbugs ;)</p>
-[21:29] <jrand0m> lol</p>
-[21:29] <jrand0m> well, thats fixed now that its synchronized</p>
-[21:29] * jrand0m opens the floor to any questions</p>
-[21:30] * mihi gets DNF for the key mentioned above :(</p>
-[21:30] <jrand0m> shite.  I inserted it a dozen times at htl 25</p>
-[21:30] <jrand0m> I'll reinsert it yet again</p>
-[21:32] <jrand0m> anyone have any questions, other than "why won't freenet find the SDK's key?"</p>
-[21:33] * mihi did not ask that ;) and does not have any other questions until he looks @ it ;)</p>
-[21:33] <jrand0m> heh</p>
-[21:33] <mihi> who puts the log onto the wiki this time? /me has it completely this time.</p>
-[21:33] <jrand0m> awesome, go for it</p>
-[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.</p>
-[21:34] * jrand0m really likes active discussion on iip-dev, even if its everyone saying how my docs suck</p>
-[21:34] <mihi> your java sux, jrandom ;) (HHOK)</p>
-[21:35] <jrand0m> thats more like it</p>
-[21:35] <jrand0m> I'm reinserting the .zip from freenet's CLI, so it'll probably have a different CHK</p>
-[21:36] <jrand0m> I'll msg people with it after I reinsert it a few times</p>
-[21:36] <jrand0m> mihi wants it.  anyone else I should msg?</p>
-[21:36] <jrand0m> (or anyone can ask at another time, as well)</p>
-[21:36] <mihi> you could mail it to me...</p>
-[21:36] <jrand0m> 1.1Mb</p>
-[21:37] <mihi> if it is not *too* large.</p>
-[21:37] <mihi> erm, okay then not.</p>
-[21:37] * mihi is not kind on fetching splitfiles anyway</p>
-[21:37] <mihi> s/kind/keen/</p>
-[21:37] <jrand0m> heh, are you going to suggest I insert it without FEC?</p>
-[21:38] <mihi> i guess it won't have any chance in current freenet.</p>
-[21:38] <jrand0m> ok, I'll see about getting it web accessible with a private URL</p>
-[21:39] * jrand0m feels kind of weird with this quiet release thing, but I think its for the best</p>
-[21:40] <mihi> just put it on some webspace and put some gpg conventional encryption around it - and tell the passphrase here.</p>
-[21:40] <mihi> or use the key mentioned above as passphrase</p>
-[21:40] <mihi> btw - shall i strip that one from the log?</p>
-[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 ;)</p>
-[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)</p>
-[21:43] <mihi> thx. "this evening" regarding which time zone? (me will go to bea in about 1 hour)</p>
-[21:43] <mihi> s/bea/bed</p>
-[21:46] <jrand0m> heh, evening for nop, which is california</p>
-[21:46] <jrand0m> ok, I've got to jet.  </p>
-[21:46] * jrand0m !thwaps meeting to an end</p>
-[21:46] <jrand0m> gracias srs y srtas</p>
-[21:46] * mihi hands jrandom the *baf*er</p>
-[21:47] * jrand0m *baf*s  mihi on the head</p>
-[21:47] * shardy has quit IRC (EOF From client)</p>
-[21:48] <ion> 2 blocks downloading above url</p>
-[21:48] <jrand0m> nice</p>
-[21:48] * shardy has joined #iip-dev</p>
-[21:48] * mihi drops dead.</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/53.rst b/i2p2www/meetings/53.rst
new file mode 100644
index 00000000..4ef46f4b
--- /dev/null
+++ b/i2p2www/meetings/53.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE @ 21:00 UTC
+=================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/54.log b/i2p2www/meetings/54.log
index e9ba7ffe..2756d75b 100644
--- a/i2p2www/meetings/54.log
+++ b/i2p2www/meetings/54.log
@@ -1,441 +1,436 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 54{% endblock %}
-{% block content %}<div class="irclog">
---- Log opened Tue Aug 19 16:56:12 2003</p>
-17:00 -!- logger [logger@anon.iip] has joined #iip-dev</p>
-17:00 -!- Topic for #iip-dev: Weekly IIP development meetings, and other</p>
-	 conversations among developers are held here.</p>
-17:00 [Users #iip-dev]</p>
-17:00 [ cohesion] [ leenookx  ] [ mihi] [ shardy_  ] [ UserXClone]</p>
-17:00 [ Ehud    ] [ logger    ] [ nop ] [ thecrypto] [ velour    ]</p>
-17:00 [ hezekiah] [ lonelynerd] [ Rain] [ UserX    ] [ WinBear   ]</p>
-17:00 -!- Irssi: #iip-dev: Total of 15 nicks [0 ops, 0 halfops, 0 voices,</p>
-15 normal]</p>
-17:00 -!- Irssi: Join to #iip-dev was synced in 7 secs</p>
-17:00 < hezekiah> Alright! :)</p>
-17:00 < hezekiah> Both loggers are in place. :)</p>
-17:01 < thecrypto> yah!</p>
-17:03 < hezekiah> Hmmm ...</p>
-17:03 < hezekiah> This meeting was supposed to start 3 minutes ago.</p>
-17:03 < hezekiah> I wonder what's up.</p>
-17:04 < thecrypto> well, whose idle</p>
-17:04 < hezekiah> jrand0m's not even online.</p>
-17:04 < hezekiah> nop's been idle 15 minutes.</p>
-17:05 < nop> hi</p>
-17:05 < nop> sorry</p>
-17:05 < nop> I'm super busy at work</p>
-17:05 < mihi> [22:36] * jrand0m is off to dinner but i'll be back within</p>
-	 the half hour for the meeting</p>
-17:05 -!- jrand0m [~jrandom@anon.iip] has joined #iip-dev</p>
-17:05 < hezekiah> Hi, jrand0m.</p>
-17:05 < nop> hi</p>
-17:05 < nop> ok, here's the thing</p>
-17:05 < nop> I can't be seen on IIP at work right now</p>
-17:05 < nop> so I'll check in with yall later</p>
-17:05 < nop> got slack about it yesterday</p>
-17:05 < nop> so</p>
-17:05 < hezekiah> Bye, nop.</p>
-17:05 < thecrypto> bye</p>
-17:06 < nop> I'll hang in the channel</p>
-17:06 < nop> just won't be obvious :)</p>
-17:06 < hezekiah> jrand0m? Since you do the most talking these days, is</p>
-	 there anything you want on the agenda for this meeting?</p>
-17:07 < jrand0m> back</p>
-17:08 < jrand0m> ok, the pesto pasta was good.</p>
-17:08 < jrand0m> lemmie pull up the agenda-ish stuff</p>
-17:09 -!- Lookaround [~chatzilla@anon.iip] has joined #iip-dev</p>
-17:09 < jrand0m> x.1) i2cp sdk mods x.2) i2np review x.3) polling http</p>
-	 transport x.4) dev status x.5) todo x.6) plan for next two weeks</p>
-17:09 < jrand0m> (place x at whatever # in the agenda it fits)</p>
-17:10 < thecrypto> you are the agencda</p>
-17:10 < hezekiah> jrand0m: I don't have anything to say, and nop can</p>
-17:10 < hezekiah> can't talk.</p>
-17:10 < jrand0m> lol</p>
-17:10 < hezekiah> UserX most likely won't be adding anything (he usually</p>
-	 doesn't), so as far as I'm concerned it's all yours. :0</p>
-17:10 < hezekiah> :)</p>
-17:10 < jrand0m> 'k.  we logging?</p>
-17:10 < jrand0m> heh</p>
-17:10 < hezekiah> I'm logging everything.</p>
-17:10 < jrand0m> cool.  ok.  0.1) welcome.</p>
-17:10 < jrand0m> hi.</p>
-17:11 < jrand0m> 0.2) mailing list</p>
-17:11 < jrand0m> the list is down atm, back asap.  you'll know when it is :)</p>
-17:11 < jrand0m> for the meantime, wiki or use iip to convo.</p>
-17:11 < jrand0m> 1.1) i2cp sdk mods</p>
-17:12 < jrand0m> the SDK has been updated with some bugfixes, plus some new</p>
-	 things in the spec have been introduced.</p>
-17:12 < jrand0m> I posted to the list yesterday with the info.</p>
-17:13 < jrand0m> hezekiah/thecrypto/jeremiah> any questions on what I posted,</p>
-	 or thoughts on a plan to implement the changes?  (or other alternatives I</p>
-	 haven't considered?)</p>
-17:13 < hezekiah> I've been running around like the chicken with my head</p>
-	 cut off getting ready for college.</p>
-17:13 < jrand0m> word, understood.</p>
-17:13 < hezekiah> I had a cursory look at what you wrote, but haven't actually</p>
-	 looked at the changes to the spec.</p>
-17:13 < jrand0m> we barely have any more of your time left, do we...</p>
-17:13 < hezekiah> Not until I get to college.</p>
-17:14 < hezekiah> Once I do, then I will probably be unheard from for at</p>
-	 least a week while I adjust.</p>
-17:14 < jrand0m> and once you get there you'll have a lot of settling in to do</p>
-	 (iirc from when i went to school ;)</p>
-17:14 < jrand0m> heh word.</p>
-17:14 < hezekiah> Then by then, I should be a bit more efficient and have</p>
-	 more time so I can code.</p>
-17:14 < jrand0m> cool</p>
-17:14 < thecrypto> i'm just doing crypto, so the data structures are my real</p>
-	 worry, once i have the CTS mode done, i'll go work on that prolly</p>
-17:14 < hezekiah> Anyway, that's my guess.</p>
-17:14 < jrand0m> awesome thecrypto</p>
-17:15 < jrand0m> ok, the good thing is the SDK works perfectly fine (with</p>
-	 the bugs mihi found being fixed [yay mihi!]) without the update to the spec.</p>
-17:15 -!- arsenic [~none@anon.iip] has joined #iip-dev</p>
-17:16 < jrand0m> ok, on to 1.2) i2np review</p>
-17:16 < jrand0m> anyone read the doc?</p>
-17:16 < jrand0m> ;)</p>
-17:16 < hezekiah> Not I, yet.</p>
-17:16 < hezekiah> As I said, I'm currently a chicken with its head cut off.</p>
-17:17 < hezekiah> BTW jrand0m, it appears you like sending PDF's.</p>
-17:17 < jrand0m> can everyone read openoffice .swx?</p>
-17:17 < hezekiah> I can.</p>
-17:17 < jrand0m> [if so, I'll send swx]</p>
-17:17 -!- abesimpson [~k@anon.iip] has joined #iip-dev</p>
-17:17 < thecrypto> i can</p>
-17:17 < hezekiah> I can't search for text in a PDF with KGhostView.</p>
-17:17 < hezekiah> So that really hurts.</p>
-17:17 < jrand0m> that sucks hezekiah</p>
-17:17 -!- mrflibble [mrflibble@anon.iip] has joined #iip-dev</p>
-17:17 < hezekiah> The linux version of Adobe Acrobat isn't very friendly eiter.</p>
-17:18 < jrand0m> ok, openoffice format it is instead of pdf.</p>
-17:18 < hezekiah> Cool.</p>
-17:18 < jrand0m> um, ok.  i2np has a few minor changes to the LeaseSet</p>
-	 structure (reflecting the i2cp change posted earlier), but other than that,</p>
-	 largely in place.</p>
-17:19 < hezekiah> jrand0m: Are all these docs in cathedral's CVS?</p>
-17:19 < nop> oh</p>
-17:19 < nop> can I interject</p>
-17:19 < hezekiah> i.e. copies of the PDF files you've been sending to the</p>
-	 list, etc.</p>
-17:19 < hezekiah> nop: Go ahead.</p>
-17:19 < nop> this is offtopic but important</p>
-17:19 -!- ChZEROHag [hag@anon.iip] has joined #iip-dev</p>
-17:19 < nop> IIP-dev and the mail are kind of screwy right now</p>
-17:19 < hezekiah> I noticed.</p>
-17:19 < nop> so bear with us for a bit</p>
-17:20 < nop> we're trying to get it up and going</p>
-17:20 < nop> but it has spam assassin built in</p>
-17:20 < nop> which is the good news</p>
-17:20 < nop> :)</p>
-17:20 < nop> and a lot of other features</p>
-17:20 < jrand0m> any eta nop for the list?</p>
-17:20  * ChZEROHag pokes his nose in</p>
-17:20 < jrand0m> (i know you're busy, not nagging, just wondering)</p>
-17:20 < nop> hopefully by tomorrow</p>
-17:20 < jrand0m> cool</p>
-17:20 < nop> the mail admin is working on it</p>
-17:21  * hezekiah notes that jrand0m _really_ likes the iip-dev list. ;-)</p>
-17:21 < nop> haha</p>
-17:21 < hezekiah> Go delta407!</p>
-17:21 < nop> anyway</p>
-17:21 < jrand0m> its best to document decisions publicly hezekiah ;)</p>
-17:21 < nop> back to our regularly scheduled meeting</p>
-17:21 < jrand0m> heh</p>
-17:21 -!- nop is now known as nop_afk</p>
-17:21 < hezekiah> jrand0m: So where were we?</p>
-17:21 < jrand0m> ok, to your equestion hezekiah> some are, but the latest</p>
-	 aren't.  I'll switch to placing in the openoffice format.</p>
-17:21 < jrand0m> rather than the pdfs</p>
-17:22 < hezekiah> OK.</p>
-17:22 < hezekiah> It'd be really cool if all the docs were in CVS.</p>
-17:22 < jrand0m> definitely, and they will be</p>
-17:22 < hezekiah> Then I can just update, and I know I have the latest edition.</p>
-17:22 < jrand0m> (there are the three drafts that aren't so far)</p>
-17:22 < hezekiah> (BTW, a little off topic, but is anonymous access to</p>
-	 cathedral up yet?)</p>
-17:23 < jrand0m> not yet.</p>
-17:23 < jrand0m> ok, by friday, I hope to have another draft of I2NP in</p>
-	 full form [aka no more ... for the kademlia explanation sections, and sample</p>
-	 implementation details]</p>
-17:24 < jrand0m> there are no significant changes.  just more filling</p>
-	 clarifying things.</p>
-17:24 < hezekiah> Sweet.</p>
-17:24 < hezekiah> Will there be byte layout for data structures avalible in it?</p>
-17:24 < jrand0m> 1.3) I2P Polling HTTP Transport spec.</p>
-17:24 < jrand0m> no, byte layouts go in the data structures spec, which</p>
-	 should be converted to the standard format instead of html</p>
-17:25 < jrand0m> (though I2NP already has all the necessary byte layouts)</p>
-17:25 < jrand0m> ((if you read it *cough* ;)</p>
-17:25 < hezekiah> Good.</p>
-17:25 < hezekiah> lol</p>
-17:25 < hezekiah> Sorry about that.</p>
-17:25 < hezekiah> As I said, I've been really busy.</p>
-17:25 < jrand0m> heh no worry, you're heading off to college shortly, you're</p>
-	 supposed to be partying :)</p>
-17:25 < hezekiah> Partying?</p>
-17:25 < jrand0m> ok, 1.3) I2NP Polling HTTP Transport spec</p>
-17:25 < hezekiah> Hmmm ... I guess I'm just odd.</p>
-17:25 < jrand0m> heh</p>
-17:26 < jrand0m> ok, I tried sending this out earlier, but I'll commit</p>
-	 it shortly.  its a quick and dirty transport protocol fitting in with I2NP</p>
-	 to allow routers to send data back and forth without direct connections</p>
-	 (e.g. firewalls, proxies, etc)</p>
-17:27 < jrand0m> I'm *hoping* someone can see how this works and build</p>
-	 similar transports (e.g. bidirectional TCP, UDP, direct HTTP, etc)</p>
-17:27 -!- mihi [none@anon.iip] has quit [Ping timeout]</p>
-17:27 < hezekiah> Hmmm, well I don</p>
-17:27 < jrand0m> before putting I2NP out for review, we need to include</p>
-	 sample transports so people can see the full picture</p>
-17:27 < hezekiah> don't think _I'll_ be building any transports soon. ;-)</p>
-17:27 -!- WinBear_ [~WinBear@anon.iip] has joined #iip-dev</p>
-17:27 < hezekiah> TCP is working for Java and Python.</p>
-17:27 < hezekiah> (At least client-to-router is.)</p>
-17:27 < jrand0m> no worry, I'm just putting it out there as a todo for people</p>
-	 who want to contribute</p>
-17:28 < hezekiah> Right.</p>
-17:28 < jrand0m> right, client-router has different requirements than the</p>
-	 router-router.</p>
-17:28 < jrand0m> ok, anyway, 1.4) dev status</p>
-17:28 < jrand0m> how we doing with CBC thecrypto?</p>
-17:28 < thecrypto> CBC is committed</p>
-17:28 < jrand0m> w00000t</p>
-17:28 < thecrypto> CTS is almost done</p>
-17:28 < hezekiah> thecrypto: What's CTS?</p>
-17:29 < thecrypto> i just have to figure out how to implement i nicely</p>
-17:29 < jrand0m> cts being cyphertext stealing :)</p>
-17:29 < hezekiah> Ah!</p>
-17:29 < thecrypto> CipherText Stealing</p>
-17:29 -!- WinBear [WinBear@anon.iip] has quit [EOF From client]</p>
-17:29 < jrand0m> did you pull nop's reference on that?</p>
-17:29 < hezekiah> OK. We're using CBC with CTS instead of padding.</p>
-17:29 < hezekiah> Hmm.</p>
-17:29 < thecrypto> basically, it makes the message exaclty right length</p>
-17:29 < jrand0m> is that workable for the python side hezekiah?</p>
-17:29 < hezekiah> I might need to slap the Python crypto lib I'm using upside</p>
-	 the head to make it us CTS properly.</p>
-17:30 < hezekiah> I've always prefered CTS over padding, but I don't know</p>
-	 what PyCrypt does.</p>
-17:30 < jrand0m> what can python do out of the box to allow exact message</p>
-	 size recovery?</p>
-17:30 < thecrypto> all you need to do is change how you process the last</p>
-	 two blocks</p>
-17:30 < hezekiah> I have a feeling that library is going to get some serious</p>
-	 rewritting.</p>
-17:30 < hezekiah> jrand0m: The CBC stuff in python is transparent. You just</p>
-	 send the buffer to the AES objects encrypt function.</p>
-17:31 < hezekiah> It spits out cipher text.</p>
+--- 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.</p>
-17:31 < jrand0m> does D(E(data,key),key) == data, byte for byte, exact</p>
-	 same size?</p>
-17:31 < hezekiah> So if it has the wacky idea of using padding instead of CTS,</p>
-	 then I might need to get in its guts and fix it.</p>
-17:31 < jrand0m> (regardless of input size?)</p>
-17:31 -!- mihi [~none@anon.iip] has joined #iip-dev</p>
-17:31 < hezekiah> jrand0m: Yes. It should.</p>
-17:31 < jrand0m> hezekiah> if you could look into exactly what algorithm it</p>
-	 uses to do the padding, that'd be great</p>
-17:32 < hezekiah> Right.</p>
-17:32  * jrand0m is hesitant at requiring a mod to a python crypto lib if</p>
-	 the lib already uses a standard and useful mechanism</p>
-17:32 < hezekiah> One way or another, CBC with CTS sounds good.</p>
-17:32 < hezekiah> jrand0m: This python crypto lib stinks.</p>
-17:32 < jrand0m> heh 'k</p>
-17:33 < thecrypto> i just have to calculate how to mess with the two blocks</p>
-17:33 < hezekiah> jrand0m: ElGamal will need to be completely rewritten in</p>
-	 C just to make it fast enough to use.</p>
-17:33 < jrand0m> hezekiah> whats the benchmark for python elg of 256bytes?</p>
-	 its only done once per dest-dest comm...</p>
-17:34 < jrand0m> (if you know offhand, that is)</p>
-17:34 < hezekiah> I'd have to test it.</p>
-17:34 < hezekiah> Encryption is only a second or two I think</p>
-17:34 < jrand0m> < 5 sec, < 2 sec, > 10 sec, > 30 sec?</p>
-17:34 < thecrypto> i'll prolly do some work with it</p>
-17:34 < hezekiah> Decrypton might be some place between 5 or 10 seconds.</p>
-17:34 < jrand0m> cool.</p>
-17:35 < jrand0m> hezekiah> have you spoken with jeremiah or do you have any</p>
-	 news about the status of the python client api?</p>
-17:35 < hezekiah> thecrypto: All you should need to do is write a C module</p>
-	 that works with Python.</p>
-17:35 < hezekiah> I have no clue what he's been up to.</p>
-17:35 < hezekiah> I haven't spoken to him since I got back.</p>
-17:35 < jrand0m> 'k</p>
-17:35 < jrand0m> any other dev status thoughts?</p>
-17:36 < hezekiah> Um, not really from me.</p>
-17:36 < hezekiah> I've already explained my current free time status.</p>
-17:36 < jrand0m> word.  understood</p>
-17:36 < hezekiah> My only plans are to get the C API up and the python router</p>
-	 back up to spec.</p>
-17:37 < jrand0m> 'k</p>
-17:37 < hezekiah> Oh my goodness!</p>
-17:37 < jrand0m> 1.4) todo</p>
-17:37 < jrand0m> si sr?</p>
-17:37 < hezekiah> The Python crypto lib doesn't implement CTS or padding!</p>
-17:37 < hezekiah> I'll have to do that manually.</p>
-17:37 < jrand0m> hmm?  it requires data to be mod 16 bytes?</p>
-17:37 < hezekiah> Yup.</p>
-17:38 < jrand0m> heh</p>
-17:38 < jrand0m> oh well.</p>
-17:38 < hezekiah> Currently the Python router uses padding.</p>
-17:38 < jrand0m> ok.  here are some oustanding items that need to get done.</p>
-17:38 < hezekiah> I remember that now.</p>
-17:38 < hezekiah> Well, let</p>
-17:38 < hezekiah> let's be frank about one thing.</p>
-17:38 < hezekiah> The Python router is never really meant to be used.</p>
-17:39 < hezekiah> It's primarily meant for me to be very familiar with the</p>
-	 spec and it also accomplishes something else:</p>
-17:39 < hezekiah> It forces the Java router to comply _exactly_ with the spec.</p>
-17:39 < jrand0m> both very important goals.</p>
-17:39 < hezekiah> Sometimes the Java router doesn't quite comply, and then</p>
-	 the Python router screams bloody murder.</p>
-17:39 < hezekiah> So it doesn't really need to be fast or stable.</p>
-17:39 < jrand0m> plus I'm not sure it won't ever be used in the sdk</p>
-17:39 < jrand0m> right.  exactly.</p>
-17:39 < jrand0m> the python client api is a different thing though</p>
-17:39 < hezekiah> The Python client API on the other hand needs to be decent.</p>
-17:40 < jrand0m> exactly.</p>
-17:40 < hezekiah> But that's jeremiah's problem. :)</p>
-17:40 < hezekiah> I've left that to him.</p>
-17:40 < jrand0m> the SDK local only routers are client dev use only</p>
-17:40 < jrand0m> lol</p>
-17:40 < jrand0m> ok, as I was saying... ;)</p>
-17:40 < hezekiah> ;-)</p>
-17:41 < jrand0m> - we need someone to start working on a small web page</p>
-	 for i2p that will be used for putting out the various I2P related specs for</p>
-	 peer review.</p>
-17:41 < jrand0m> I'd like this to be ready before 9/1.</p>
-17:41 < hezekiah> OK. I am stating right now that you don't want me to do that.</p>
-17:41 < hezekiah> I'm not a good webpage designer. :)</p>
-17:41 < jrand0m> nor I, if anyone here has seen my flog ;)</p>
-17:41 < jrand0m> cohesion?  ;)</p>
-17:41 < hezekiah> lol</p>
-17:42 < hezekiah> Poor cohesion, always stuck with the dirty work. :-)</p>
-17:42  * cohesion reads the back log</p>
-17:42 < hezekiah> ;)</p>
-17:42 < jrand0m> heh</p>
-17:42 < cohesion> jrand0m: I will do it</p>
-17:42 < cohesion> me@jasonclinton.com</p>
-17:42 < cohesion> send me the specs</p>
-17:42 < jrand0m> 'k, gracias.</p>
-17:42 < jrand0m> the specs aren't all done yet.</p>
-17:43 < jrand0m> but the contents that will need to be there are:</p>
-17:43 < cohesion> well, what you have an what you would like to have put up</p>
-17:43 < jrand0m> -I2CP spec, I2NP spec, Polling HTTP Transport spec, TCP</p>
-	 Transport spec, Security analysis, Performance analysis, Data structure spec,</p>
-	 and a readme/intro</p>
-17:44 < jrand0m> (those 7 documents will be in pdf and/or text format)</p>
-17:44 < cohesion> k</p>
-17:44 < jrand0m> barring the readme/intro</p>
-17:45 < jrand0m> I'm hoping that all of those docs will be ready by next week</p>
-	 (8/26).  will that give you enough time to get together a small page for a</p>
-9/1 release?</p>
-17:46 < jrand0m> ok.  another thing that will need to come down the pipe is</p>
-	 an I2P network simulator.</p>
-17:46 < jrand0m> do we have anyone looking for a CS project?  ;)</p>
-17:46 < hezekiah> lol</p>
-17:46 < cohesion> jrand0m: yea, that's doable</p>
-17:47 < hezekiah> I'm not for another few years. ;-)</p>
-17:47 < jrand0m> cool cohesion</p>
-17:47 < thecrypto> not for a year</p>
-17:47  * cohesion goes back to work</p>
-17:47 < jrand0m> tnx cohesion</p>
-17:48 < jrand0m> ok, 1.6) next two weeks.  on my plate is getting these specs,</p>
-	 docs, and analysis up.  I'll post & commit as soon as I can.</p>
-17:48 < jrand0m> PLEASE READ THE SPECS AND COMMENT</p>
-17:48 < jrand0m> :)</p>
-17:48 < hezekiah> jrand0m: Right. Once I get time, I will start reading. :)</p>
-17:48 < jrand0m> I'd prefer people to post comments to the list, but if</p>
-	 people want to be anon, send me comments privately and I'll post replies to</p>
-	 the list anonymously.</p>
-17:49 < hezekiah> (What do you think the eta for OpenOffice files for the</p>
-	 docs being on CVS is?)</p>
-17:49 < jrand0m> I can commit the latest revs within 10 minutes of this</p>
-	 meeting being over.</p>
-17:49 < hezekiah> Awesome. :)</p>
-17:50 < jrand0m> ok, thats it for 1.*.</p>
-17:50 < jrand0m> 2.x) comments/questions/concerns/rants?</p>
-17:50 < jrand0m> how's the sdk mod working out mihi?</p>
-17:51 < jrand0m> or anyone else?  :)</p>
-17:51 < hezekiah> jrand0m: What is this sdk mod you're talking about?</p>
-17:52 < jrand0m> hezekiah> two bugfixes to the sdk, commited (& posted)</p>
-	 the other day</p>
-17:52 < hezekiah> Ah</p>
-17:52 < hezekiah> Neato.</p>
-17:52 < jrand0m> (rotate the message IDs, synchronize writes)</p>
-17:52 < hezekiah> Just the java side, or the python side too?</p>
-17:52 < jrand0m> yo no hablo python.</p>
-17:53 < hezekiah> lol</p>
-17:53 < jrand0m> not sure if the bugs exist there.  do you rotate message</p>
-	 ids every 255 messages, and synchronize your writes?</p>
-17:54 < hezekiah> I think the Python router does both</p>
-17:54 < jrand0m> cool.</p>
-17:54 < jrand0m> we'll let you know if it doesn't ;)</p>
-17:54 < hezekiah> What exactly do you mean by "synchronize your writes"?</p>
-17:55 < jrand0m> aka make sure multiple messages aren't written to a client</p>
-	 at the same time if there are multiple clients trying to send messages to</p>
-	 it at the same time.</p>
-17:55 < hezekiah> All the data sent over the TCP connection gets sent in</p>
-	 the order it originated.</p>
-17:56 < hezekiah> So you won't be 1/2 of message A and then 1/3 of message B.</p>
-17:56 < jrand0m> 'k</p>
-17:56 < hezekiah> You'll get message A and then message B.</p>
-17:56 < hezekiah> OK ... if no one else is going to talk, I suggest we</p>
-	 adjurne the meeting.</p>
-17:56 < mihi> my simple TCP/IP over I2p seems to work...</p>
-17:56 < jrand0m> niiiiice!!</p>
-17:56  * mihi was idling a bit sorry</p>
-17:57 < hezekiah> Anyone else have anything to say?</p>
-17:57 < jrand0m> mihi> so we'll be able to run pserver over that?</p>
-17:57 < mihi> as long as you do not try to create lotas connections at once.</p>
-17:57 < mihi> jrand0m: i guess so - i could ge tgoogle through it</p>
-17:57 < jrand0m> niiiice</p>
-17:57 < jrand0m> mihi++</p>
-17:57 < mihi> jrand0m-ava</p>
-17:57 < jrand0m> so you have an outproxy and an inproxy?</p>
-17:58 < mihi> exactly.</p>
-17:58 < jrand0m> cool</p>
-17:58 < mihi> the destination needs keys, the source generates them on demand</p>
-17:58  * hezekiah hands jrand0m the *baf*er. Smash the thing when you're</p>
-	 done, man.</p>
-17:58 < jrand0m> right.  hopefully co's naming service could help with that</p>
-	 once its ready.</p>
-17:59 < jrand0m> ok cool.  mihi, let me or anyone else know if there's</p>
-	 anything we can do to help :)</p>
-17:59 < mihi> fix that thing with the 128 msgids or build a better GUARANTEED</p>
-	 support</p>
-17:59  * jrand0m *baf*s nop_afk over the head for having a real job</p>
-18:00 < mihi> jrand0m: baf abuse costs 20 yodels</p>
-18:00 < jrand0m> lol</p>
-18:00 < jrand0m> better guaranteed support?</p>
-18:00 < jrand0m> (aka better performance than the one described?  we'll fix</p>
-	 that in impl)</p>
-18:00 < mihi> did you test my test case with start_thread=end_thread=300?</p>
-18:01 < mihi> it generates lots of messages in one direction, and that causes</p>
-	 all msgids to be eaten...</p>
-18:01 < jrand0m> hmm, no, hadn't seen that message</p>
-18:01 < hezekiah> jrand0m: Would it be reasonable to make msgid 2 bytes?</p>
-18:01  * jrand0m tried the 200 / 201, but thats fixed with the latest</p>
-18:01 -!- cohesion [cohesion@anon.iip] has quit [off to the lug meeting]</p>
-18:01 < mihi> which latest?</p>
-18:01 < hezekiah> Then they would have 65535 msgids (if you don't could</p>
-	 msgid 0)</p>
-18:01 < hezekiah> .</p>
-18:02 < jrand0m> 2 byte message ids wouldn't hurt.  I'm comfortable with</p>
-	 that change.</p>
-18:02 < jrand0m> mihi> the one I mailed you</p>
-18:02 < mihi> if you have a more latest than the one you sent me, send it</p>
-	 (or give me cvs access)</p>
-18:03 < mihi> hmm, that one fails for me with 200/201 (as well as with 300)</p>
-18:03 < jrand0m> hmm.  I'll do some more testing and debugging and mail you</p>
-	 what I come up with.</p>
-18:03 < mihi> thx.</p>
-18:04 < jrand0m> ok.</p>
-18:04  * jrand0m declares the meeting</p>
-18:04 < jrand0m> *baf*'ed</p>
-18:04  * hezekiah hangs the *baf*er reverantly on its special rack.</p>
-18:05  * hezekiah then spins around walks out the door, slamming it behind</p>
-	 him. The baffer falls off the rack.</p>
-18:05 < hezekiah> ;-)</p>
---- Log closed Tue Aug 19 18:05:36 2003</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/54.rst b/i2p2www/meetings/54.rst
new file mode 100644
index 00000000..cc071c2b
--- /dev/null
+++ b/i2p2www/meetings/54.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 19, 2003
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/55.log b/i2p2www/meetings/55.log
index 6a88781d..0cc0b5a2 100644
--- a/i2p2www/meetings/55.log
+++ b/i2p2www/meetings/55.log
@@ -1,214 +1,209 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 55{% endblock %}
-{% block content %}<div class="irclog">
-[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 </p>
-[23:00] <jrand0m> is x == 0 or 1 or 2? </p>
-[23:00] <jeremiah> 22/7</p>
-[23:01] <thecrypto> i think it's 0</p>
-[23:01] * jrand0m always logs, so wtf, why not.</p>
-[23:01] <jrand0m> 0.0: welcome. </p>
-[23:01] <jrand0m> hi. </p>
-[23:01] <jrand0m> 0.1: spec questions </p>
-[23:01] <jrand0m> anyone read the specs?  :) </p>
-[23:02] * mihi did. at least tried to</p>
-[23:02] <jrand0m> w0ah word </p>
-[23:02] <jeremiah> nope</p>
-[23:02] <jeremiah> what are the new ones?</p>
-[23:02] <thecrypto> occasionally</p>
-[23:02] <jrand0m> mihi> tried to, hard to read, bad language, incomprehensible organization, or just boring as fuck? </p>
-[23:03] <mihi> i'm just not familiar enough with crypto. the first part was very interesting.</p>
-[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 </p>
-[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 ;)</p>
-[23:04] <jeremiah> sweet</p>
-[23:04] <jrand0m> lol mihi </p>
-[23:05] <mihi> although the format had its problems as well -don't have open office here, just ol' staroffice 5.2</p>
-[23:05] <jrand0m> does star office 5.2 not read it?  would you prefer .pdf or kludged html? </p>
-[23:05] <jrand0m> (or .txt?  though txt wouldn't have pics or real formatting) </p>
-[23:05] <mihi> i'd prefer "old" .sdw format.</p>
-[23:05] <jeremiah> pdf if at all possible</p>
-[23:05] <mihi> or pdf</p>
-[23:06] <jrand0m> pdf is a one click solution. </p>
-[23:06] * jrand0m edits in open office, reads in pdf</p>
-[23:06] <jeremiah> or appleworks</p>
-[23:06] <jeremiah> ;)</p>
-[23:06] <mihi> sxw is supported only in staroffice 6.0 and above</p>
-[23:06] <jrand0m> ah ok mihi </p>
-[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</p>
-[23:07] <jrand0m> (or maybe .doc if i'm feeling dirty) </p>
-[23:07] <mihi> i would not mind .sdw.zip or .sdw.gz or .sdw.bzw either...</p>
-[23:07] <mihi> s/bzw/bz2/</p>
-[23:07] <jrand0m> heh, zipped up, for sure. </p>
-[23:08] <jrand0m> the data structures spec may require a mod, and the network proto requires some fixed urls before release. </p>
-[23:08] <jrand0m> anyone have any questions on any of the four specs? </p>
-[23:09] <thecrypto> not at the momemet</p>
-[23:10] <jrand0m> ok.  0.2: elg issues </p>
-[23:10] <jrand0m> we're having some probs w/ elgamal encryption as specified on p13 of the data structures spec. </p>
-[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. </p>
-[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. </p>
-[23:12] <jrand0m> if its implementation or key generation related, we can publish the spec and fix the sdk when resolved. </p>
-[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) </p>
-[23:14] <thecrypto> i'm trying to figure it out at the moment</p>
-[23:15] *** Signoff: mihi (Ping timeout)</p>
-[23:15] *** mihi_ (~none@anon.iip) has joined channel #iip-dev</p>
-[23:15] <jrand0m> 'k </p>
-[23:15] *** mihi_ is now known as mihi</p>
-[23:15] <thecrypto> i have to run some math and through some other implementation and figure it out</p>
-[23:15] <thecrypto> i never had a problem with elgamal</p>
-[23:15] <thecrypto> last time i tested</p>
-[23:16] *** Signoff: mihi ((null))</p>
-[23:17] <thecrypto> with that benchmark</p>
-[23:17] <jrand0m> right, but the benchmark only tried one key </p>
-[23:17] <thecrypto> ahh</p>
-[23:17] <jrand0m> i can quite repeatedly get the error without any mods to the elg impl </p>
-[23:17] <thecrypto> didn't we have a wrong key message that came up?</p>
-[23:18] <jrand0m> yes, those still come up </p>
-[23:18] *** mihi_ (~none@anon.iip) has joined channel #iip-dev</p>
-[23:18] <jrand0m> periodically (usually 2-4 times per keygen) </p>
-[23:18] *** mihi (~none@anon.iip) has joined channel #iip-dev</p>
-[23:18] *** mihi is now known as mihi_backup</p>
-[23:18] *** mihi_ is now known as mihi</p>
-[23:18] <thecrypto> and we still get bad keys?</p>
-[23:19] <jrand0m> or something. </p>
-[23:19] <jrand0m> all that wrong size tests is "if ( (k0.length == PublicKey.KEYSIZE_BYTES) && (k1.length == PrivateKey.KEYSIZE_BYTES) ) {" </p>
-[23:19] <jrand0m> no value evaluation, etc. </p>
-[23:20] <thecrypto> one second</p>
-[23:23] <thecrypto> can you check if x the private key is < p</p>
-[23:23] <jrand0m> if (m.compareTo(CryptoConstants.elgp) >= 0) </p>
-[23:23] <jrand0m> already done. </p>
-[23:23] <jrand0m> (throw new IllegalArgumentException("ARGH.  Data cannot be larger than the ElGamal prime.  FIXME");)  that exception is never thrown. </p>
-[23:23] <jrand0m> er x?  hmm.   </p>
-[23:24] <jrand0m> 'k.  perhaps we may want to steal bouncycastle's or another impl's elg key gen algo </p>
-[23:25] <jrand0m> ok.  0.3> sdk issues </p>
-[23:26] <jrand0m> elg is pending, but other than that the sdk is very close to 0.8 (aka release matching specs) </p>
-[23:26] <jrand0m> (only the elg issue plus the LeaseSet modification is left) </p>
-[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. </p>
-[23:27] <jrand0m> or even whether we need to include SDK 0.1 with the spec release. </p>
-[23:27] <thecrypto> gah! annoying</p>
-[23:28] <thecrypto> miracl which nop pointed me too does the exact same thing we do</p>
-[23:28] <thecrypto> and they have no checks</p>
-[23:28] <jrand0m> unsigned though. </p>
-[23:28] <jrand0m> (since miracl is in c) </p>
-[23:28] * jrand0m assumes</p>
-[23:28] <thecrypto> yes</p>
-[23:29] <thecrypto> but still, i make sure we never have a signed biginteger</p>
-[23:30] <jrand0m> biginteger.toByteArray() returns a signed byte array </p>
-[23:30] <thecrypto> sorry, continue</p>
-[23:30] <jrand0m> 'k </p>
-[23:30] <jrand0m> any movement on the python front jeremiah? </p>
-[23:31] <jeremiah> hey</p>
-[23:31] <jeremiah> sorry I was reading the backlog</p>
-[23:31] <jrand0m> heh hi </p>
-[23:31] <jeremiah> nope, I'm still getting used to classes</p>
-[23:31] <jrand0m> coo' </p>
-[23:31] <jrand0m> no prob </p>
-[23:31] <jeremiah> I think I'm gonna sleep for a bit actually</p>
-[23:31] <jrand0m> 'k </p>
-[23:32] <jrand0m> 0.4: release plan </p>
-[23:32] <jrand0m> we need the sdk issues resolved in the next day or so, one way or another. </p>
-[23:32] <jrand0m> we need to get working on wiki-fiying the security model </p>
-[23:32] <jrand0m> (wiki, where art thou) </p>
-[23:33] <jrand0m> we need to get the performance model up (not a prob, ill have it in a day or so) </p>
-[23:33] <jrand0m> we need to update the specs to include any elg mods, plus real URLs to other specs. </p>
-[23:33] <nop> miracl</p>
-[23:33] <nop> has a port</p>
-[23:33] <nop> to java</p>
-[23:33] <jrand0m> perhaps we need to host the specs && / || sdk outside the US for export regulations [not that i care] </p>
-[23:34] <jrand0m> right, but miracl's java port doesnt have elg encryption last i checked. </p>
-[23:34] <jrand0m> i'll check again. </p>
-[23:34] <nop> jrand0m, we don't care, but we'll worry about that later</p>
-[23:34] <nop> jrand0m if it has bigdig() and modexp()</p>
-[23:34] <nop> you're fine</p>
-[23:34] *** yodel (~yodel@anon.iip) has joined channel #iip-dev</p>
-[23:34] <thecrypto> one second</p>
-[23:34] <thecrypto> i think i found our problem</p>
-[23:35] <jrand0m> word, whats up thecrypto? </p>
-[23:35] <nop> can you check jrand0m</p>
-[23:35] <thecrypto> our k isn't being checked for relitive prime</p>
-[23:36] <jrand0m> will that cause the problems described thecrypto?  i thought that would just render the encryption insecure (a problem, nonetheless) </p>
-[23:36] <thecrypto> but that would mean only some messages with the key would fail</p>
-[23:36] <thecrypto> it's something in keygen</p>
-[23:36] <jrand0m> nop> we'll find something to solve it.  but i outlined some specific questions in my email that are implementation independent </p>
-[23:36] <jrand0m> ok thecrypto, we'll work through that after the meeting </p>
-[23:37] <nop> the double ciphertext question?</p>
-[23:37] <thecrypto> okay</p>
-[23:37] <jrand0m> nop> thats one of the questions </p>
-[23:37] * nop goes to read</p>
-[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? </p>
-[23:40] <thecrypto> quick q jrand0m: where does it fail, the benchmark runs perfectly and it makes a new keypair every time?</p>
-[23:41] <nop> let me get it up, hold</p>
-[23:41] <mihi> wiki.invisiblenet.net == jasonclinton.com [64.91.236.103]</p>
-[23:41] <jrand0m> gracias mihi </p>
-[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 </p>
-[23:42] <thecrypto> can i see this ElGamalAESEngine?</p>
-[23:42] <thecrypto> just commit it to CVS and i'll see what the problem is</p>
-[23:43] <nop> ok wiki is cname'd</p>
-[23:43] <nop> should propagate in a bit</p>
-[23:43] * jrand0m doesnt commit things that don't work, but I'll email you</p>
-[23:43] <jrand0m> thanks nop </p>
-[23:43] <nop> it's up</p>
-[23:43] <nop> ;)</p>
-[23:43] <nop> (Link: http://wiki.invisiblenet.net)http://wiki.invisiblenet.net</p>
-[23:43] <jrand0m> not on my box it aint </p>
-[23:43] <jrand0m> ;) </p>
-[23:44] <nop> what are we wiki'ing</p>
-[23:44] <nop> ?</p>
-[23:44] <jrand0m> the security doc, plus a place to distro the specs. </p>
-[23:44] <jrand0m> perhaps even the i2p website prior to 1.0 release, but at least the security doc. </p>
-[23:45] *** Signoff: sirk ((null))</p>
-[23:45] *** Signoff: shardy_ (Ping timeout)</p>
-[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. </p>
-[23:46] *** shardy_ (~shardy@anon.iip) has joined channel #iip-dev</p>
-[23:46] <nop> I have a grphx guy working on the website</p>
-[23:47] <nop> for i2p</p>
-[23:47] <jrand0m> any problems with that for a deadline?  [friday deadline, fallback only if Bad Things Happen] </p>
-[23:47] <nop> sure</p>
-[23:47] <thecrypto> jrand0m: sent?</p>
-[23:47] <jrand0m> 'k, so just the security docs and the i2p spec distro location </p>
-[23:47] <jrand0m> no thecrypto, there are half a dozen files.  i'll send after the meeting. </p>
-[23:47] <thecrypto> okay</p>
-[23:48] <thecrypto> i'd like them sooner because we're moving tables around today so i need to move computers soon</p>
-[23:48] <nop> jrand0m, I'll need to look at your email and I'll respond shortly</p>
-[23:48] <nop> multi-tasking</p>
-[23:49] <jrand0m> 'k. </p>
-[23:49] <jrand0m> 0.5> apps </p>
-[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] </p>
-[23:49] <jrand0m> mihi has an awesome awesome i2ptunnel app </p>
-[23:50] *** Signoff: WinBear_ (EOF From client)</p>
-[23:50] <mihi> strip one or two `awesome's ;)</p>
-[23:50] <jrand0m> heh </p>
-[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 </p>
-[23:51] <mihi> it relies on too many things i cannot see from the spec (e.g. that GUARANTEED packets are delivered in order)</p>
-[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. </p>
-[23:52] <jrand0m> ideally, it'd be cool if it FEC'ed or had built in ordering & reconstruction or something </p>
-[23:52] <jrand0m> (so that it didn't block on send and didn't require GUARANTEED) </p>
-[23:53] <mihi> that's a bot too many ifs i think...</p>
-[23:53] <mihi> s/bot/bit/</p>
-[23:55] <mihi> but perhaps i'll have some time to add reordering/resending to it...</p>
-[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) </p>
-[23:55] <jrand0m> word </p>
-[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? </p>
-[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)</p>
-[23:57] <nop> hmm</p>
-[23:57] <thecrypto> test</p>
-[23:57] <jrand0m> tset </p>
-[23:57] <thecrypto> still connected?</p>
-[23:57] <jrand0m> si sr </p>
-[23:58] <thecrypto> we're unplugging phonelines right now</p>
-[23:58] <nop> IIP, it defies phone lines</p>
-[23:58] <jrand0m> heh </p>
-[23:58] <nop> :)</p>
-[23:58] <thecrypto> i can get back on the IM front and file transfer</p>
-[23:58] <jrand0m> wikked </p>
-[00:00] <jrand0m> ok.  thats all i have for agenda items. </p>
-[00:00] <jrand0m> any comments/questions/concerns/frisbees? </p>
-[00:00] * thecrypto throws a frisbee</p>
-[00:00] * jrand0m gets a frisbee in the face</p>
-[00:01] <thecrypto> i just want to get this crypto stuff done so i can go back and optimize elg</p>
-[00:01] <thecrypto> and do the same for python hopefully</p>
-[00:01] <jrand0m> word.  I'll get you the code in the next 5 </p>
-[00:02] <thecrypto> that would be good</p>
-[00:03] * jrand0m readies the *baf*er</p>
-[00:03] * jrand0m winds up</p>
-[00:03] * jrand0m *baf*s the meeting to a close.</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/55.rst b/i2p2www/meetings/55.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/55.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/56.log b/i2p2www/meetings/56.log
index e6100436..bbbab398 100644
--- a/i2p2www/meetings/56.log
+++ b/i2p2www/meetings/56.log
@@ -1,215 +1,210 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 56{% endblock %}
-{% block content %}<div class="irclog">
-[22:53] <jrand0m> ok, wtf, why not.  agenda: </p>
-[22:53] <jrand0m> 0) welcome </p>
-[22:53] <jrand0m> 1) spec & sdk release  </p>
-[22:53] <jrand0m> 2) spec & sdk questions  </p>
-[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   </p>
-[22:53] <jrand0m> 4) meeting time change?   </p>
-[22:53] <jrand0m> 5) cvs administravia </p>
-[22:54] <jrand0m> 6) shardy's stuff </p>
-[22:54] <jrand0m> 7) peanut gallery </p>
-[22:54] <jrand0m> thazzit. </p>
-[22:54] <jrand0m> 0) welcome </p>
-[22:54] <w0rmus> hihi</p>
-[22:54] <thecrypto> so welcome everyone to meeting number 55</p>
-[22:54] <thecrypto> 56</p>
-[22:55] <thecrypto> 56 is correct</p>
-[22:55] *** Signoff: mihi (EOF From client)</p>
-[22:55] <jrand0m> hi.  welcome to meeting 56 </p>
-[22:55] <jrand0m> yea </p>
-[22:55] <jrand0m> 1) spec & sdk release </p>
-[22:55] <w0rmus> haha</p>
-[22:55] *** mihi (~none@anon.iip) has joined channel #iip-dev</p>
-[22:55] <jrand0m> the specs are out and the sdk 0.2 is out as well. </p>
-[22:56] <jrand0m> currently, they're only available on freenet [http://localhost:8888/CHK@p1VU1U67UgXYJ7v7cS4Xqn~p4ssLAwI,RvdwV4jZyZYcJgYabpVPOQ/I2P_SDK.zip] </p>
-[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 </p>
-[22:57] <jrand0m> 2) any new questions on the specs or the sdk? </p>
-[22:58] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev</p>
-[22:58] *** terrific (terrific@anon.iip) has joined channel #iip-dev</p>
-[22:58] <jrand0m> well, first question in there is, how goes the progress /reading/ the specs?  :) </p>
-[22:58] <w0rmus> needa do that :)</p>
-[22:58] <thecrypto> slowlyu</p>
-[22:58] <w0rmus> therefore I have no questions</p>
-[22:58] <jrand0m> heh word </p>
-[22:59] <w0rmus> I'll start now then</p>
-[22:59] <jrand0m> suggested order of reading the PDFs is> I2POverview.pdf, then I2NP, then datastructures, then I2CP, then polling HTTP transport </p>
-[22:59] <w0rmus> ok I'll do it in that order then</p>
-[23:00] <jrand0m> ok.  on to # 3 then, unless there are any q's on the specs </p>
-[23:00] <jrand0m> 3.1) co's naming service proposal </p>
-[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 </p>
-[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? </p>
-[23:01] <mihi> how can one get the address of a name server? ;)</p>
-[23:02] <jrand0m> OOB, but good point.  he should toss in a "bootstrapping" section </p>
-[23:03] <thecrypto> OOB?</p>
-[23:03] <jrand0m> out of band.  e.g. from a web site or built into the software </p>
-[23:03] <thecrypto> ahh</p>
-[23:03] *** naphtala (asdf@anon.iip) has joined channel #iip-dev</p>
-[23:04] <jrand0m> (co may actually have different ideas, I'm just assuming thats what he meant.  definitely something to mention on the list) </p>
-[23:04] <mihi> is there any general way to make a text representation of Destinations (e.g. ascii armor)?</p>
-[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 </p>
-[23:06] <jrand0m> perhaps that should be added to the I2P data structures spec.  good idea.   </p>
-[23:06] <jrand0m> does anyone have any qualms with base64? </p>
-[23:07] <jrand0m> ok.  at least for now that'll get added in. </p>
-[23:08] <jrand0m> 3.2) SDK 1.0 criteria </p>
-[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. </p>
-[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.   </p>
-[23:09] <jrand0m> optionally, we may want to include a streaming API as well </p>
-[23:10] <jrand0m> does anyone else have any 1.0 criteria they'd like to see in the SDK? </p>
-[23:11] *** jnk (jnk@anon.iip) has joined channel #iip-dev</p>
-[23:11] <jrand0m> ok.  post to the list if you think of anything </p>
-[23:11] <jrand0m> 3.3) network simulator </p>
-[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 </p>
-[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 ;) </p>
-[23:14] * jrand0m utterly fails to keep a straight face wrt the likelyhood of someone jumping up and writing a simulator</p>
-[23:14] <jrand0m> ok.  3.4) other apps </p>
-[23:14] <w0rmus> haha</p>
-[23:14] *** Signoff: mihi_backup (Ping timeout)</p>
-[23:14] * thecrypto jumps up...and writes something else</p>
-[23:14] <jrand0m> heh </p>
-[23:15] <jrand0m> mihi> any mods/updates/plans for the i2ptunnel?   </p>
-[23:17] <mihi> nope.</p>
-[23:17] <jrand0m> cool, just checkin' in :) </p>
-[23:17] <mihi> if someone writes a TCP layer for I2P, i might use it, but I wont write it.</p>
-[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 </p>
-[23:18] *** Trifixion (~lame-o@anon.iip) has joined channel #iip-dev</p>
-[23:19] <jrand0m> and in a production environ waiting for an ACK before sending the next message is only a ~.4s delay </p>
-[23:19] <jrand0m> <insert caveat on latency models here> </p>
-[23:19] <jrand0m> ok.  next "other apps" </p>
-[23:20] <jrand0m> thecrypto> IM? </p>
-[23:20] <thecrypto> well, i'm working on a UI prototype right now</p>
-[23:20] <thecrypto> as soon as we have some way of communicating with other people, i can just put in the networking stuff</p>
-[23:20] <jrand0m> we /have/ some way of communicating with other people </p>
-[23:21] <jrand0m> (not that I'm against doing it in pieces anyway) </p>
-[23:21] <thecrypto> i'm going to start with just UI</p>
-[23:21] <jrand0m> wikked. </p>
-[23:21] <w0rmus> I do wish to help thecrypto with the IM but I've some reading to do</p>
-[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'</p>
-[23:22] <jrand0m> nice </p>
-[23:22] <thecrypto> and i thought we only had local only unless you want to tunnel?</p>
-[23:22] <jrand0m> will the UI have an address book feature for storing destinations of friends? </p>
-[23:22] <thecrypto> buddy list</p>
-[23:23] <thecrypto> we'll have to poll the name server somehow to check when people are online</p>
-[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 </p>
-[23:23] <jrand0m> hmm, the IM app will depend on the name server? </p>
-[23:23] <jrand0m> or will the IM have a central "presence" server? </p>
-[23:23] <thecrypto> it'll need someway to keep track of everyone</p>
-[23:23] <thecrypto> i'm trying to avoid central anything</p>
-[23:24] <thecrypto> but some sort of distributed presense would have to be thought up and it looks like the NS will do that</p>
-[23:24] <jrand0m> I don't think the NS has presence.  it only says what the Destinations are </p>
-[23:24] <jrand0m> (for each service for each nym) </p>
-[23:25] <thecrypto> but doesn't it have an online offline state?</p>
-[23:25] <jrand0m> no, the NS is just like DNS.  it doesn't tell you if the host is reachable. </p>
-[23:25] <thecrypto> at least i thought it do</p>
-[23:25] *** mihi_backup (~none@anon.iip) has joined channel #iip-dev</p>
-[23:25] <thecrypto> so you have to try it to find out</p>
-[23:26] <thecrypto> then i'll have to come up with my own spec to work out that part</p>
-[23:26] <jrand0m> coo'.  perhaps start without one, and maybe add a rudimentary periodic ping, and then a fully distributed whatever ;) </p>
-[23:27] <thecrypto> well step 1 is UI</p>
-[23:27] <jrand0m> anyway, you know best, whatever works for ya.  if there's anything anyone can do to help, just say the word </p>
-[23:27] <jrand0m> right </p>
-[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? </p>
-[23:28] <thecrypto> well what apps do we have planned already other than IM and NS and Tunnel?</p>
-[23:29] <w0rmus> will file transfer be implemented along with IM or separately?</p>
-[23:29] <w0rmus> separately I imagine</p>
-[23:29] <thecrypto> you will be allowed to file transfer IM, but other people can come up with file transfer only protocols like FTP</p>
-[23:29] <w0rmus> ok so what you're working on will have file transfer as well</p>
-[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 </p>
-[23:30] <thecrypto> IE replace freenet :)</p>
-[23:30] <jrand0m> a multiplexing "outdial" tcp tunnel would be cool too </p>
-[23:30] <jrand0m> naw, freenet is a CDN, this would require having a server to store space on </p>
-[23:31] <thecrypto> okay</p>
-[23:31] <jrand0m> (the outdial would probably require SOCKS integration though) </p>
-[23:32] <jrand0m> that it for the top of my head though.  with mihi's tunnel we can already ssh and cvs over i2p </p>
-[23:32] <jrand0m> ok.  3.5) more transports </p>
-[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. </p>
-[23:33] <jrand0m> but if someone wants to look at the polling HTTP transport and define some other transport, that'd be fantastic </p>
-[23:33] <thecrypto> transports kinda like the jabber transports</p>
-[23:33] <thecrypto> translating one to another?</p>
-[23:34] <jrand0m> hmm?  transports are the actual means of sending bytes from one router to another. </p>
-[23:34] <thecrypto> ahh okay</p>
-[23:34] *** jnk has left #iip-dev</p>
-[23:34] <thecrypto> so instead of just one method of getting the bits from one router to another there are many?</p>
-[23:34] <jrand0m> exactly. </p>
-[23:34] <jrand0m> I2NP does /not/ specify a particular transport </p>
-[23:35] <thecrypto> so if one is firewalled/blocked/slow/... you use another</p>
-[23:35] <jrand0m> exactly </p>
-[23:35] <thecrypto> sweee</p>
-[23:35] <w0rmus> yah that sweet :)</p>
-[23:35] <jrand0m> ok, 3.6) java router reference implementation </p>
-[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. </p>
-[23:36] <jrand0m> then individual subsystems can be stub'ed and implemented in turn (or in parallel).   </p>
-[23:37] *** Signoff: mihi (EOF From client)</p>
-[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 :) </p>
-[23:37] <thecrypto> can do</p>
-[23:38] <jrand0m> w3wt </p>
-[23:38] <w0rmus> hopefully can do :)</p>
-[23:38] <jrand0m> word </p>
-[23:38] <jrand0m> ok.  any other dev status questions / thoughts / comments? </p>
-[23:39] <w0rmus> thecrypto: is anyone else working on the IM with you as of now?</p>
-[23:39] <thecrypto> co should be</p>
-[23:39] <w0rmus> is co cohesion?</p>
-[23:39] <thecrypto> but right now i'm just getting the UI started</p>
-[23:39] * jrand0m thinks co will havea /LOT/ of work with the naming service</p>
-[23:39] <thecrypto> no co == whit</p>
-[23:39] <jrand0m> no, co is wiht, cohesion is a different person :) </p>
-[23:39] <w0rmus> ok thanks</p>
-[23:40] *** mihi (~none@anon.iip) has joined channel #iip-dev</p>
-[23:40] <thecrypto> if it was cohesion then we would use tab compleletion</p>
-[23:40] <jrand0m> heh </p>
-[23:40] <w0rmus> some people are too lazy for even that </p>
-[23:41] <jrand0m> ok.  agenda item 4) meeting time change </p>
-[23:41] <jrand0m> is anyone here further east than GMT+2? </p>
-[23:41] <jrand0m> you don't need to answer that... </p>
-[23:41] <jrand0m> er, is anyone here already pushed to their limit of lateness with 9PM GMT meeting time? </p>
-[23:41] * mihi_backup is gmt+2</p>
-[23:42] <jrand0m> ah cool.  would later work for you mihi, or is 9p best? </p>
-[23:42] * jrand0m doesn't go to bed until after the sun rises in gmt+2</p>
-[23:42] <mihi_backup> not much later. 8p or 7p would be better</p>
-[23:42] <jrand0m> ah 'k </p>
-[23:42] <mihi_backup> but if i can't come; i'll read the log.</p>
-[23:43] *** Signoff: cohesion (class)</p>
-[23:43] <jrand0m> well, we have no hard reason to make it later and its good to have you here ;) </p>
-[23:43] <thecrypto> i say it's perfect where it is</p>
-[23:44] <jrand0m> cool.  I just wanted to bring it up to possibly help out the left coast 'mericans who have jobs :) </p>
-[23:44] <jrand0m> but 9P GMT it is and 9P GMT it stays </p>
-[23:44] <jrand0m> ok.  item 5) cvs administravia </p>
-[23:45] <jrand0m> well, none of the python people are here, and thecrypto and I have already spoken re: cvs module conventions :) </p>
-[23:45] <jrand0m> we still are working on getting anon cvs </p>
-[23:45] <jrand0m> or at the very least nightly snapshots of the cvs on the web. </p>
-[23:45] <jrand0m> that'll be announced once its ready. </p>
-[23:46] <thecrypto> most of the reason for limiting access to to make sure not too many people start getting at it</p>
-[23:46] <thecrypto> before it's ready</p>
-[23:46] <jrand0m> right, but the SDK has the full source of everything in the tree atm anyway ;) </p>
-[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 </p>
-[23:47] <jrand0m> dunno though.  we'll cross that bridge when it comes  </p>
-[23:47] *** Trifixion has left #iip-dev</p>
-[23:48] <jrand0m> item 6) shardy's stuff </p>
-[23:48] * jrand0m waves to shardy</p>
-[23:48] <shardy> hiya</p>
-[23:48] <shardy> um, I don't really have much of anything to say</p>
-[23:48] <shardy> just thought I'd say hi and all</p>
-[23:48] <shardy> seeing as how I've got myself involved in the project latey :)</p>
-[23:48] <shardy> lately.</p>
-[23:48] <w0rmus> hihi</p>
-[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</p>
-[23:49] <shardy> like if you need random code debugged, or crypto implemented, or optimized</p>
-[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</p>
-[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 </p>
-[23:49] <jrand0m> nice </p>
-[23:50] <shardy> I'll be hanging around, so grab me for whatever if you need anything.</p>
-[23:50] <thecrypto> yah</p>
-[23:50] <jrand0m> wikked. </p>
-[23:50] <jrand0m> ok.  7) peanut gallery </p>
-[23:50] <jrand0m> any i2p thoughts / comments / questions / concerns? </p>
-[23:52] <jrand0m> ok then :) </p>
-[23:52] *** naphtala has left #iip-dev</p>
-[23:52] <w0rmus> i2p is neat</p>
-[23:52] <jrand0m> heh </p>
-[23:52] <w0rmus> ;0</p>
-[23:52] * jrand0m pulls the *baf* off the wall...</p>
-[23:53] <jrand0m> ... the wind-up </p>
-[23:53] <jrand0m> and the *baf* </p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/56.rst b/i2p2www/meetings/56.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/56.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/57.log b/i2p2www/meetings/57.log
index 38739a9d..fee52875 100644
--- a/i2p2www/meetings/57.log
+++ b/i2p2www/meetings/57.log
@@ -1,170 +1,165 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 57{% endblock %}
-{% block content %}<div class="irclog">
-[22:57] <jrand0m> ok, buenos noches srs y srtas </p>
-[22:57] <jrand0m> agenda: </p>
-[22:57] <jrand0m> 0) welcome </p>
-[22:57] <jrand0m> 1) cvs </p>
-[22:57] <jrand0m> 4) naming service </p>
-[22:58] <co> You forgot 5) questions.</p>
-[22:58] <jrand0m> 3) dev status </p>
-[22:58] <jrand0m> 2) spec questions? </p>
-[22:58] <jrand0m> 5) other questions? </p>
-[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 </p>
-[22:59] <jrand0m> lets see if I can keep that straight as we go... </p>
-[22:59] <jrand0m> ok, 0) welcome </p>
-[22:59] <shardy> yay for permutation groups!</p>
-[22:59] <jrand0m> welcome to meeting 57 </p>
-[22:59] <jrand0m> yeah, they're all just symbols anyway </p>
-[22:59] <w0rmus> sweet whatup ;0</p>
-[23:00] <w0rmus> I'll help comprise peanut gallery</p>
-[23:00] <jrand0m> 1) cvs is still down, after 10+ days.  we're finding a new host. </p>
-[23:00] <jrand0m> sf.net sucks, and I have no reason to believe gnu's nongnu is better. </p>
-[23:00] <co> jrand0m: Why not make that host have the alias "cvs.invisiblenet.net"?</p>
-[23:00] <jrand0m> nop is leading the charge on finding the new host. </p>
-[23:01] <jrand0m> sure co, once we get the server </p>
-[23:01] <shardy> what do you need for a host?</p>
-[23:01] <jrand0m> shardy> reliable net connection, ssh/cvs access.  and some disk space </p>
-[23:01] <shardy> do you have something lined up?</p>
-[23:01] <shardy> because if not. I may be able to assist.</p>
-[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?) </p>
-[23:02] * w0rmus taps nop</p>
-[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.</p>
-[23:03] <shardy> how much disk space would you need?</p>
-[23:03] <jrand0m> the repository currently comprises ~ 6Mb.  so probably 50M would handle growth for a good while </p>
-[23:04] <shardy> oh. pfft. that's nothing.</p>
-[23:04] <shardy> and the machine wouldn't need to be super fast?</p>
-[23:04] <shardy> you wouldn't be doing big compile jobs on it?</p>
-[23:04] <jrand0m> naw, a 286 would probably do it. </p>
-[23:04] <jrand0m> no, strictly cvs checking / checkout  </p>
-[23:04] <jrand0m> (well, and diff, and log, etc ;) </p>
-[23:05] <jrand0m> "we're java, we don't need compile farms" </fark> </p>
-[23:05] *** Signoff: cohesion (class)</p>
-[23:05] <w0rmus> do people concerned with anonymity access CVS using something like JAP?  I've never used CVS</p>
-[23:05] <jrand0m> w0rmus> I use cvs through a private series of ssh proxies </p>
-[23:05] <co> jrand0m: Keep in mind that a C or C++ implementation may be likely in the future.</p>
-[23:06] <mihi> jap does not allow cvs access AFAIK :(</p>
-[23:06] <w0rmus> ssh tunnelling</p>
-[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.</p>
-[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. </p>
-[23:07] <jrand0m> awesome shardy.  there's anything we can do, just say the word. </p>
-[23:07] <co> jrand0m: You are right. They should be separate.</p>
-[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.</p>
-[23:07] <jrand0m> shardy++ </p>
-[23:07] <w0rmus> yay ;0</p>
-[23:07] <jrand0m> ok, 4) naming service </p>
-[23:08] <jrand0m> co, how goes?   </p>
-[23:08] <co> I am still writing, but would like to say a few words about it.</p>
-[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.</p>
-[23:09] <co> It merely says that a person can be contacted via certain methods, such as AIM.</p>
-[23:09] <co> Second, the client side.</p>
-[23:09] <co> There will be an API which programs can use to make queries to naming servers.</p>
-[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.</p>
-[23:11] <co> The underlying mechanism will also read the destination mechanism for the local router to contact from a file.</p>
-[23:11] <jrand0m> the destination mechanism? </p>
-[23:11] <co> I'm sorry, the destination address.</p>
-[23:11] <jrand0m> ah 'k </p>
-[23:12] <co> That is all at this time.</p>
-[23:12] <jrand0m> cool </p>
-[23:12] <w0rmus> I agree</p>
-[23:12] <w0rmus> ;)</p>
-[23:12] <jrand0m> any ballpark ideas on timelines for various milestones?   </p>
-[23:13] <jrand0m> obviously nothing anyone could hold you to, of course, just wondering </p>
-[23:13] <co> Let's say end of the week for finishing the specification and publishing it and the API.</p>
-[23:14] * mariesofie arrives late</p>
-[23:14] <jrand0m> ah nice co </p>
-[23:14] <co> Then, I will start implementing it. I am not certain how long that will take, though.</p>
-[23:14] <jrand0m> understandable </p>
-[23:15] <jrand0m> anyone else have any naming service questions/thoughts? </p>
-[23:15] <jrand0m> ok, 3) dev status </p>
-[23:16] <jrand0m> dev goes well. </p>
-[23:16] <jrand0m> the java side is up to spec and implements all I2CP and I2NP messages and structures </p>
-[23:17] <jrand0m> the java architecture itself is functional and I'm going to continue stubbing out the various subsystems </p>
-[23:17] <co> Have you tested it?</p>
-[23:17] <jrand0m> the messages & structures?  yes via the TestData harness in net.invisiblenet.i2p.data.test </p>
-[23:17] <co> I mean connecting two different computers with I2P.</p>
-[23:18] <jrand0m> oh, no, thats requires the full implementation of the communication subsystem </p>
-[23:18] <co> I see.</p>
-[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 </p>
-[23:19] <jrand0m> we're probably 2 weeks off from a client sending a message to a client on a different router </p>
-[23:19] * mariesofie cheers</p>
-[23:20] <jrand0m> there's still a lot of work to be done after that before the alpha, but thats progress  </p>
-[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" </p>
-[23:21] <shardy> man. i really need to read up on the specs.</p>
-[23:22] <jrand0m> well, they'll soon be hosted on your machine so it'll be easy :) </p>
-[23:22] <w0rmus> haha</p>
-[23:22] <w0rmus> I have not finished specs either</p>
-[23:23] <mariesofie> i printed the specs, read them so many times it got worn out and i had to print out another copy</p>
-[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 </p>
-[23:23] <w0rmus> heh</p>
-[23:23] <jrand0m> rofl mariesofie </p>
-[23:23] <jrand0m> ok, thats it for 3) dev status </p>
-[23:24] <jrand0m> now for 2) spec questions </p>
-[23:24] <w0rmus> I suppose I'll read them instead of stupid calculus</p>
-[23:24] <co> I am thinking a little bit into the future.</p>
-[23:24] <co> The python and C or C++ implementations will need to have message data readable by the Java implementation.</p>
-[23:24] *** Signoff: mihi (EOF From client)</p>
-[23:25] <jrand0m> correct co </p>
-[23:25] <co> How will you accomplish that?</p>
-[23:25] <jrand0m> the datastructures spec specifically defines the byte layouts </p>
-[23:25] <jrand0m> and everything is big endian and all numbers are unsigned </p>
-[23:25] <mariesofie> what level of technical knowledge are you targetting the specs for? anyone with decent comp. knowledge? college level CS engineer students?</p>
-[23:25] <co> Oh, all right.</p>
-[23:25] *** mihi_ (~none@anon.iip) has joined channel #iip-dev</p>
-[23:26] <mariesofie> i.e. who is the target audience?</p>
-[23:26] *** mihi_ is now known as mihi</p>
-[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 </p>
-[23:26] <jrand0m> we really really need some docs that go in the middle </p>
-[23:27] <mariesofie> i see</p>
-[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</p>
-[23:28] <mariesofie> maybe thats reflective on me more than the documentation :)</p>
-[23:28] <jrand0m> heh geek :) </p>
-[23:29] <jrand0m> ok, any other questions on the specs?  lets move on to 5) other questions  </p>
-[23:29] <jrand0m> anyone have any other questions?  this is our last bullet point on the meeting agenda </p>
-[23:30] <w0rmus> I wonder where thecrypto is with achat</p>
-[23:30] <jrand0m> ah, thecrypto is offline for the next three weeks or so </p>
-[23:30] <mihi> what happens with peer review?</p>
-[23:30] <w0rmus> or atalk</p>
-[23:30] <w0rmus> wow</p>
-[23:30] <mihi> is anyone reviewing it?</p>
-[23:30] <mariesofie> i thought thecrypto has 2hrs per day</p>
-[23:31] <w0rmus> and I can't even see the codes he has :(</p>
-[23:31] <jrand0m> mihi> reviews have been sent to various people for review and as feedback comes it will be addressed. </p>
-[23:31] <jrand0m> w0rmus> do you have any questions on ATalk? </p>
-[23:32] <shardy> I will be reviewing it as soon as I have time :)</p>
-[23:32] <mihi> i meant, did any feedback come till nowß</p>
-[23:32] <w0rmus> I suppose not</p>
-[23:32] <mihi> s/nowß/now?/</p>
-[23:32] <jrand0m> mihi> largely in the form of discussions and clarifications </p>
-[23:32] <jrand0m> awesome shardy :) </p>
-[23:33] <Brownspider> hapy birthday google</p>
-[23:33] <jrand0m> mariesofie> right, but thats not even enough time for him to d/l the java lang docs to continue dev :/ </p>
-[23:33] <w0rmus> ahaha wtf</p>
-[23:35] <jrand0m> ok, any other questions / thoughts? </p>
-[23:35] <w0rmus> I guess I should mention that I've never coded outside of school</p>
-[23:35] <w0rmus> but I gotta start somewhere anyways</p>
-[23:35] <jrand0m> now's a good time to start :) </p>
-[23:35] <jrand0m> word </p>
-[23:35] <w0rmus> ;0</p>
-[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</p>
-[23:35] <w0rmus> I've taken 2 years of java or so</p>
-[23:36] <jrand0m> ok cool mariesofie, just bounce a msg to the list or bounce me a message here whenever </p>
-[23:37] <co> mariesofie: Have you read the discussion on the iip-dev mailing list?</p>
-[23:37] <w0rmus> where is it archived?</p>
-[23:37] <jrand0m> http://news.gmane.org/thread.php?group=gmane.comp.security.invisiblenet.iip.devel </p>
-[23:37] <jrand0m> (fairly low traffic atm) </p>
-[23:38] <Brownspider> jrand0m wants you code something that can not logicly exist, to tear the world usunder, to end the reign of god.</p>
-[23:38] <shardy> my services are still offered if you need any crypto cores or such written or debugged. </p>
-[23:39] *** M123456789 (~no@anon.iip) has joined channel #iip-dev</p>
-[23:39] <co> Brownspider: huh?</p>
-[23:39] <Brownspider> co, it was on his freesite, nevermind</p>
-[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 </p>
-[23:40] <mariesofie> co> i've only read back to about issue #52 or so</p>
-[23:42] <jrand0m> ok.  any last words (as I eye the *baf*er...) </p>
-[23:43] *** mihi_backup_ (~none@anon.iip) has joined channel #iip-dev</p>
-[23:43] *** Signoff: mihi_backup (EOF From client)</p>
-[23:43] *** mihi_backup_ is now known as mihi_backup</p>
-[23:43] <jrand0m> ok great.  next week, same bat time, same bat place. </p>
-[23:44] * jrand0m *baf*s the meeting to an end</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/57.rst b/i2p2www/meetings/57.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/57.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/58.log b/i2p2www/meetings/58.log
index 778cf6d3..835480fc 100644
--- a/i2p2www/meetings/58.log
+++ b/i2p2www/meetings/58.log
@@ -1,314 +1,309 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 58{% endblock %}
-{% block content %}<div class="irclog">
-[22:53] <jrand0m> 0) welcome </p>
-[22:54] <jrand0m> 1) apps: </p>
-[22:54] <jrand0m> 1.1) IM </p>
-[22:54] <jrand0m> 1.2) NS  </p>
-[22:54] <jrand0m> 2) dev status: </p>
-[22:54] <jrand0m> 2.1) subsystems </p>
-[22:54] <jrand0m> 2.2) encryption key persistence </p>
-[22:54] <jrand0m> 2.3) todo </p>
-[22:54] <jrand0m> 3) spec stuff </p>
-[22:54] <jrand0m> 3.1) mods </p>
-[22:54] <jrand0m> 4) administravia: </p>
-[22:54] <jrand0m> 4.1) anon cvs </p>
-[22:54] <jrand0m> 5) ? </p>
-[22:55] <jrand0m> ok, 0) welcome  </p>
-[22:55] <jrand0m> welcome to meeting 58 </p>
-[22:55] <thecrypto> that all</p>
-[22:55] <jrand0m> si sr, unless anyone else has things to add? </p>
-[22:55] * nop notices jrand0m is object oriented with his numbering :)</p>
-[22:56] <nop> 3.1.2.2.4.5.8() ;)</p>
-[22:56] <jrand0m> hey, they could be structs ;) </p>
-[22:56] <nop> haha</p>
-[22:56] <nop> that is definitely true</p>
-[22:56] <jrand0m> ok, 1.1) IM.  thecrypto? </p>
-[22:56] <nop> although</p>
-[22:56] <nop> 2 has inheritance</p>
-[22:57] <nop> ;)</p>
-[22:57] <jrand0m> heh </p>
-[22:57] <nop> nevermind me</p>
-[22:57] <nop> ok</p>
-[22:57] <nop> sorry</p>
-[22:57] <nop> continue</p>
-[22:57] *** mihi_ (~none@anon.iip) has joined channel #iip-dev</p>
-[22:57] <thecrypto> okay, right now i'm uploading some basic specs for IM</p>
-[22:58] <thecrypto> (Link: http://www.thecrypto.org/i2pim.sxw)http://www.thecrypto.org/i2pim.sxw for oowriter</p>
-[22:58] <thecrypto> and i'm working on uploading the pdf</p>
-[22:58] <nop> if you want I can put on i2p site</p>
-[22:59] <thecrypto> give me a second</p>
-[22:59] <thecrypto> sure</p>
-[22:59] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev</p>
-[22:59] <jrand0m> do you want to put that into i2p/apps/IM/doc/ ? </p>
-[22:59] *** mihi_ is now known as mihi_backup</p>
-[23:00] <nop> I can</p>
-[23:00] <nop> yes</p>
-[23:00] <jrand0m> I meant in cvs :) </p>
-[23:00] <thecrypto> i can do that too</p>
-[23:00] <jrand0m> (but on the web is good too) </p>
-[23:00] <nop> oh</p>
-[23:00] <nop> haha</p>
-[23:00] <thecrypto> (Link: http://www.thecrypto.org/i2pim.pdf)http://www.thecrypto.org/i2pim.pdf</p>
-[23:01] <MrEcho> "the file is damaged and could not be repaired"  AR error</p>
-[23:01] <thecrypto> try again</p>
-[23:01] * jrand0m loaded it fine</p>
-[23:01] <co> MrEcho: The PDF file?</p>
-[23:01] <jrand0m> (the sxw) </p>
-[23:01] <thecrypto> only partially uploaded at that time</p>
-[23:01] <MrEcho> now it works</p>
-[23:01] <MrEcho> hehe</p>
-[23:02] <thecrypto> basicall i just put in the presence stuff, online offline messages, and a message message</p>
-[23:02] <thecrypto> i shameless ripped some sections from the I2NP documenty</p>
-[23:02] <thecrypto> :)</p>
-[23:02] <jrand0m> heh I thought some of it looked familiar :) </p>
-[23:02] <thecrypto> i'm also working on uploading the UI i</p>
-[23:02] <thecrypto> i've been working on</p>
-[23:03] <thecrypto> jrand0m: do i need to create the dirs apps/IM/doc</p>
-[23:03] <jrand0m> yes, and cvs add them individually </p>
-[23:03] <thecrypto> -kb?</p>
-[23:03] <jrand0m> yes </p>
-[23:03] <co> thecrypto: I believe apps/ is there now.</p>
-[23:04] <jrand0m> whats a presence? </p>
-[23:05] <thecrypto> let me run update</p>
-[23:05] <thecrypto> but it's getting in there</p>
-[23:05] *** Signoff: shardy (Ping timeout)</p>
-[23:05] <thecrypto> i'm just saying rip apart the specs</p>
-[23:05] <thecrypto> and the UI will be in there soon as well</p>
-[23:05] <thecrypto> and if you have anything that needs to be clarified then anonymail, e-mail, anything me and i'll fix it</p>
-[23:05] <mrflibble> did i miss the meeting?</p>
-[23:05] *** shardy (~shardy@anon.iip) has joined channel #iip-dev</p>
-[23:05] <co> thecrypto: You might want to announce it on the e-mail list, as well, with a link to the documents.</p>
-[23:05] <thecrypto> i thought i put that in there?</p>
-[23:05] <jrand0m> nope still on the first item point mrflibble </p>
-[23:05] <co> mrflibble: Meeting is in progress.</p>
-[23:05] <mrflibble> oh sorry, just couldnt see "logger"</p>
-[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? </p>
-[23:06] <mihi> no mids here, so no logger ;)</p>
-[23:06] <mrflibble> k</p>
-[23:06] * mrflibble goes back to lurking</p>
-[23:06] <jrand0m> oh wait, these are just presence notifications, sorry </p>
-[23:06] <mihi> how can one subscribe to a presence?</p>
-[23:06] <thecrypto> jrand0m: no offline messages</p>
-[23:07] <thecrypto> basically</p>
-[23:07] <thecrypto> the presence just wraps a destination and a name together</p>
-[23:07] <thecrypto> to make things easy</p>
-[23:08] <thecrypto> so if we want to move onto NS we can do that, and we can come back to this later?</p>
-[23:09] <jrand0m> 'k cool </p>
-[23:09] <thecrypto> and you can still message me questions</p>
-[23:09] <jrand0m> actually, one quick question </p>
-[23:09] <thecrypto> shoot</p>
-[23:09] <jrand0m> so the IM is strictly text only? </p>
-[23:10] <thecrypto> with this basic one yes, but i will be adding file support in</p>
-[23:10] <jrand0m> coo' </p>
-[23:10] <thecrypto> i just want the beginnings of the system taken care of and build on it</p>
-[23:10] <jrand0m> (iterative and incremental)++ </p>
-[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? </p>
-[23:11] <co> Version 1.1 (final) of the naming service specification was released earlier today.</p>
-[23:12] <jrand0m> (and there was much rejoicing) </p>
-[23:12] <co> Basically, I finished the sections on the data structures and network messages that the program needs.</p>
-[23:12] <co> I will be releasing the client API on Thursday.</p>
-[23:12] <co> And will begin implementing the NS application.</p>
-[23:12] <jrand0m> great </p>
-[23:13] <co> One idea that has changed is what the CA does when entities register with it.</p>
-[23:13] <thecrypto> co: how will you be implementing it?</p>
-[23:13] <thecrypto> co: the name server or the client?</p>
-[23:14] <co> thecrypto: Well, first I will implement the data structures necessary.</p>
-[23:14] <co> Then, the client, then the server and CA components.</p>
-[23:14] <thecrypto> okay</p>
-[23:15] <co> As I was saying, I now would like the CA to issue a certificate to newly registered entities.</p>
-[23:15] <co> They will present this certificate to naming servers when modifying their records.</p>
-[23:15] <co> I have not specified what the certificate contains in this version; that will go into the next version of the specification.</p>
-[23:16] <co> Does this strike anyone as a bad idea?</p>
-[23:16] <jrand0m> hmm.  wouldn't it be simpler / safer to just have the client use a public key / private key? </p>
-[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 </p>
-[23:16] <jrand0m> (so that hte CA never gets the private key) </p>
-[23:17] <thecrypto> Sidenote: all the I2PIM stuff is now committed to the cvs respository</p>
-[23:17] <jrand0m> great </p>
-[23:17] <co> It may be simpler to do just that. I will re-think this issue. Thank you for the comment.</p>
-[23:17] <co> That is all I have to discuss for the naming service at this time, if you have no other questions.</p>
-[23:18] <jrand0m> its lookin good, I haven't gone through the 1.1 yet but I'll email if I come across something </p>
-[23:19] <co> OK. Next topic?</p>
-[23:19] <jrand0m> ok, 2.1) dev status for subsystems. </p>
-[23:19] *** w0rmus (o0o@anon.iip) has joined channel #iip-dev</p>
-[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) </p>
-[23:21] <co> What do you mean by stupid algorithms?</p>
-[23:21] <w0rmus> not fast?</p>
-[23:21] <jrand0m> eh, the peer management subsystem isn't keeping track of peer performance, its just returning random peers. </p>
-[23:22] <jrand0m> the algorithm will be updated and tuned as things progress to more adequately provide peer selection </p>
-[23:22] <jrand0m> current task on my plate is building and handling garlic messages, which is a PITA. </p>
-[23:23] <jrand0m> but workable, just annoying  </p>
-[23:23] <jrand0m> that actually leads into 2.2) encryption key persistence. </p>
-[23:24] <jrand0m> garlic messages use ElG+AES encryption to wrap the layers of the cloves </p>
-[23:24] <jrand0m> and private keys are used in other places (transport, client management) </p>
-[23:25] *** Signoff: thecrypto (Ping timeout)</p>
-[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) </p>
-[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? </p>
-[23:26] <co> Option 2.</p>
-[23:27] <nop> jrand0m option 2, or do what we said before</p>
-[23:27] <nop> we must trust localhost </p>
-[23:27] *** Signoff: cohesion (class)</p>
-[23:27] <nop> we assume localhost is not compromised</p>
-[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 </p>
-[23:27] <jrand0m> good point nop. </p>
-[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</p>
-[23:28] <nop> depending on paranoia level</p>
-[23:28] <nop> security vs convenience measure</p>
-[23:29] <co> Then I propose having 3 by default, and giving the user the option to use 2.</p>
-[23:29] <nop> exactly</p>
-[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" </p>
-[23:29] <jrand0m> ok, cool, I'll just go with the simple 3) for now then </p>
-[23:30] <jrand0m> ok 2.3) todo </p>
-[23:30] * co would like to revisit the NS topic at the end of the meeting.</p>
-[23:30] * nop needs to finish reading the NS email</p>
-[23:30] <jrand0m> 'k, you're item #5 now </p>
-[23:30] <co> I can wait until the end.</p>
-[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 :) </p>
-[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 </p>
-[23:33] <nop> word</p>
-[23:34] <jrand0m> other todo's... um, I fixed the "Wrong Size generating key" thing this morning plus a few random bugs </p>
-[23:34] <jrand0m> ok, thats it for dev status.  3) spec stuff </p>
-[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. </p>
-[23:35] <jrand0m> 3.2) [I know, this one wasn't on the agenda, but here it is anyway] spec questions </p>
-[23:35] <shardy> (brb, I'm still lurking if you need me)</p>
-[23:35] <jrand0m> anyone have any questions on any of the specs? </p>
-[23:35] <jrand0m> cool shardy </p>
-[23:36] <co> jrand0m: Please tell us again which spec is in which document.</p>
-[23:37] <jrand0m> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs has 'em mapped out </p>
-[23:37] <co> I will look at it.</p>
-[23:38] <jrand0m> (looking at that it reminds me I need to document the secure reliable UDP transport.  yet another todo...) </p>
-[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 </p>
-[23:40] <nop> jrand0m</p>
-[23:40] <jrand0m> si sr? </p>
-[23:41] <nop> do you mean actual UDP as in UDP packets </p>
-[23:41] <nop> or UDP as in a general UDP protocol</p>
-[23:41] <jrand0m> yes, UDP as in UDP packets </p>
-[23:41] <nop> for I2P</p>
-[23:41] *** thecrypt1 (~thecrypto@anon.iip) has joined channel #iip-dev</p>
-[23:41] *** thecrypt1 is now known as thecrypto</p>
-[23:41] <jrand0m> i2p/code/router/java/src/net/invisiblenet/i2p/router/transport/udp for the implementation </p>
-[23:42] <thecrypto> back</p>
-[23:42] <jrand0m> wb </p>
-[23:42] <thecrypto> anyone want to send me what happened while i was gone?</p>
-[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 </p>
-[23:43] <jrand0m> rekeying is supported though not automatic atm </p>
-[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") </p>
-[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) </p>
-[23:45] <nop> of course</p>
-[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" </p>
-[23:45] <nop> good</p>
-[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) </p>
-[23:47] <jrand0m> ok, so, yeah, that needs to get doc'ed up into a spec :) </p>
-[23:48] * jrand0m !thwaps self for coding before specing</p>
-[23:48] <thecrypto> coding before specing helps me</p>
-[23:48] <jrand0m> yeah, it works best iteratively </p>
-[23:48] <jrand0m> (as we're finding problems with the specs by implementing them, etc) </p>
-[23:49] <jrand0m> ok, thats 3) specs.  4) administravia </p>
-[23:49] <jrand0m> 4.1) anon cvs.  thecrypto?  :) </p>
-[23:49] <thecrypto> just in the nick of time</p>
-[23:49] <thecrypto> well, i'm looking into it, i think 2401 is currently blocked</p>
-[23:49] <jrand0m> can you cvs -d :pserver: locally? </p>
-[23:49] <thecrypto> and there might be some inetd stuff to do as well thanks jrandom</p>
-[23:50] <jrand0m> ah coo' </p>
-[23:50] <thecrypto> let me test that i forgot you cood do that :)</p>
-[23:51] <thecrypto> would it just be cvs -d :pserver: ?</p>
-[23:51] <jrand0m> cvs -d :pserver:anonymous@localhost:/home/cvsgroup/cvsroot/ co i2p </p>
-[23:52] <jrand0m> also, it'd be great if we could get a bugzilla on there too </p>
-[23:52] <thecrypto> acvs [checkout aborted]: connect to localhost(127.0.0.1):2401 failed: Connection refused</p>
-[23:52] <jrand0m> 'k, after adding the inetd.conf line and kill -HUP identd? </p>
-[23:52] <thecrypto> let me try that inet line and i'll get back to you</p>
-[23:52] <jrand0m> er, inetd :) </p>
-[23:52] <jrand0m> 'k cool </p>
-[23:53] <thecrypto> does the pserver go on the same line?</p>
-[23:53] <jrand0m> yes, thats all on one line </p>
-[23:55] <jrand0m> ok, thats it for administravia, at least that I can think of </p>
-[23:55] <jrand0m> 5a) co, you're up </p>
-[23:56] <co> When two people want to register the same entity name, the second is refused.</p>
-[23:56] <co> But if we use a signature-based approach,</p>
-[23:56] <co> the person who was refused could send a message to the naming server</p>
-[23:56] <co> anyway, telling it to modify the record.</p>
-[23:56] <co> There are two possibilities:</p>
-[23:57] <co> 1) CA sends the naming server a copy of the public key for the entity that was approved.</p>
-[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.</p>
-[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.</p>
-[23:58] <co> That is what I was thinking.</p>
-[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 </p>
-[00:00] <jrand0m> what you're describing sounds more like symmetric crypto - just using a passphrase, eseentially </p>
-[00:00] <thecrypto> cvs is screwing with me!</p>
-[00:00] <jrand0m> (where the certificate is the shared secret between CAs and the authentic owner of the nym) </p>
-[00:00] *** mrsc (~efgsdf@anon.iip) has joined channel #iip-dev</p>
-[00:01] <jrand0m> whats up thecrypto? </p>
-[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</p>
-[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.</p>
-[00:01] <jrand0m> coo' </p>
-[00:01] *** LeerokLacerta (~leerok@anon.iip) has joined channel #iip-dev</p>
-[00:02] <LeerokLacerta> Konnichiwa.</p>
-[00:02] <jrand0m> hmm thecrypto, I don't think you want an anonymous OS user </p>
-[00:02] <jrand0m> heya LeerokLacerta </p>
-[00:02] <LeerokLacerta> Hello, jrand0m.</p>
-[00:02] <thecrypto> well i stuck on a password and it works now</p>
-[00:03] <co> jrand0m: And if you have any more suggestions after reading the spec, send them to me.</p>
-[00:03] <jrand0m> shall do co </p>
-[00:03] <jrand0m> cool thecrypto.. is /bin/false their shell? </p>
-[00:03] <thecrypto> now i just have to find that section in the cvs manual about how to make a user</p>
--> *thecrypto* whats the pw?</p>
-[00:04] <thecrypto> now it is</p>
-[00:05] <jrand0m> ok, we can work through this after the meeting. </p>
-[00:05] <jrand0m> ok, last point on the agenda: 5b) ? </p>
-[00:05] <jrand0m> any questions / thoughts / concerns? </p>
-[00:05] <thecrypto> just check out the IM app</p>
-[00:06] <thecrypto> right now all it does is make a tree but it shows you what it's starting to look like</p>
-[00:06] <LeerokLacerta> No SOCKS?</p>
-[00:06] <thecrypto> ohh yeah that's what i forgot</p>
-[00:06] <jrand0m> ah cool thecrypto </p>
-[00:06] <jrand0m> SOCKS?  as in, the proxy protocol? </p>
-[00:06] <thecrypto> anyone here good at making icons?</p>
-[00:06] <LeerokLacerta> Yup.</p>
-[00:06] <LeerokLacerta> The answer for all the times I've asked as been "No".</p>
-[00:07] <jrand0m> ah.  yes, we're definitely going to want a socks proxy, but no one is working on it atm. </p>
-[00:07] <LeerokLacerta> Hmm.</p>
-[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 </p>
-[00:07] <mihi> there are enough socks proxies available for free, i'd say ;)</p>
-[00:08] <jrand0m> exactly, we just need to integrate 'em </p>
-[00:08] <mihi> but i don't know any in java.</p>
-[00:08] <jrand0m> the JAP client app might work well, I don't know if its GPL though </p>
-[00:08] <mihi> the jap client does not contain a proxy.</p>
-[00:08] <thecrypto> well I need some icons for the I2PIM project</p>
-[00:09] <thecrypto> Something to represent online offline and a group of people</p>
-[00:09] <mihi> the only proxy is a http/ftp proxy and that is in the last mix.</p>
-[00:10] <mihi> like with iip - isproxy does not know any IRC protocol.</p>
-[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 </p>
-[00:10] <thecrypto> anyone interested?</p>
-[00:11] <co> thecrypto: Could you take the icons from the GPL'd gaim project?</p>
-[00:11] * jrand0m makes horrificly boring graphics in ms paint</p>
-[00:11] <co> Since it's under GPL, and so is this, unless I am mistaken.</p>
-[00:11] <thecrypto> yeah, i could</p>
-[00:11] <jrand0m> if I2PIM uses the sdk's client libs, I2PIM is definitely GPL :) </p>
-[00:12] <thecrypto> ahh the wonderful GPL</p>
-[00:12] <jrand0m> LeerokLacerta> any particular reason you ask, or just wanting to prod us to do it? ;) </p>
-[00:13] <thecrypto> the problem with the gaim ones is they are from the IM apps they are using</p>
-[00:14] <thecrypto> so if someone could make the I2PIM icon that would just be great</p>
-[00:15] * jrand0m thinks we'll have lots of scribbled paint-based images for the time being...</p>
-[00:16] <jrand0m> ok, anyone have any other thoughts / questions / commnets? </p>
-[00:16] <nop> I have commnets</p>
-[00:16] <jrand0m> (other than "wtf is a commnet") </p>
-[00:16] <jrand0m> is that contagious? </p>
-[00:16] *** nixonite (~nixonite@anon.iip) has joined channel #iip-dev</p>
-[00:16] <mrflibble> lol</p>
-[00:17] <jrand0m> 'k, well, if not, that about wraps up the meetin', no more agenda items left </p>
-[00:17] <nixonite> did i miss the meeting?</p>
-[00:17] <jrand0m> yup, 9p GMT </p>
-[00:17] <jrand0m> well, technically you made it for the end :) </p>
-[00:17] <nixonite> oh</p>
-[00:18] <co> nop: Let's hear them.</p>
-[00:18] <thecrypto> so what are the comments</p>
-[00:18] * jrand0m thought nop was just making fun of my typo, but if he has comments, let 'er rip bro</p>
-[00:20] <thecrypto> anon cvs is still not liking me, more work tommorow</p>
-[00:20] <jrand0m> gimmie root and I'll get 'er up </p>
-[00:21] <thecrypto> talk to nop about that one</p>
-[00:21] <jrand0m> heh 'k </p>
-[00:22] <jrand0m> ok, as nop seems to have been dragged back into work... </p>
-[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) </p>
-[00:23] * jrand0m loads up and *baf*s the meeting to an end.</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/58.rst b/i2p2www/meetings/58.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/58.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/59.log b/i2p2www/meetings/59.log
index 6ceb77ca..d6acbf3f 100644
--- a/i2p2www/meetings/59.log
+++ b/i2p2www/meetings/59.log
@@ -1,734 +1,730 @@
-{% extends "_layout.html" %}
-{% block title %}Meeting 59{% endblock %}
-{% block content %}<div class="irclog">
-[22:56] <jrand0m> ok ok </p>
-[22:56] <jrand0m> agenda </p>
-[22:56] <jrand0m> 0.0) welcome </p>
-[22:56] <jrand0m> 1.0) dev status </p>
-[22:56] <jrand0m> 1.1) router </p>
-[22:56] *** Myself248 (~ident@anon.iip) has joined channel #iip-dev</p>
-[22:56] <jrand0m> 1.2) DH precalc </p>
-[22:56] <jrand0m> 2.0) microroadmap </p>
-[22:56] <jrand0m> 3.0) apps / usage </p>
-[22:56] <jrand0m> 4.0) ns </p>
-[22:56] <jrand0m> 5.0) IM </p>
-[22:56] <jrand0m> 6.0) administravia (cvs, bugzilla, cvs list, cvs web) </p>
-[22:56] <jrand0m> 7.0) questions </p>
-[22:57] <jrand0m> (yes, 7 points today.  w00t) </p>
-[22:57] <jrand0m> 0.0) welcome </p>
-[22:57] <jrand0m> hi. </p>
-[22:57] <dm> hey</p>
-[22:57] <jrand0m> 17 users today.  neat </p>
-[22:57] *** Ryan_Singer (chatzilla@anon.iip) has joined channel #iip-dev</p>
-[22:57] <jrand0m> and counting </p>
-[22:57] <jrand0m> ok </p>
-[22:57] <thecrypto> 1~hi</p>
-[22:57] <jrand0m> 1.1) dev status for router </p>
-[22:58] <jrand0m> the java reference impl router is doing very well </p>
-[22:58] *** ChZEROHag (hag@anon.iip) has joined channel #iip-dev</p>
-[22:58] <jrand0m> we can now run applications on different routers and send messages ot each other </p>
-[22:59] <ChZEROHag> Sorry to interrupt, but hopefully it'll just be once</p>
-[22:59] <jrand0m> taking an iterative and incremental approach, the current state is secure, not anonymous, not scalable, and harvestable </p>
-[22:59] <ChZEROHag> Is anyone else working on a C api?</p>
-[22:59] <jrand0m> 'lo ChZEROHag, whats shakin? </p>
-[22:59] <ChZEROHag> Because I am, but very slowly</p>
-[22:59] *** dcat (dirtycat@anon.iip) has joined channel #iip-dev</p>
-[22:59] <jrand0m> oh cool </p>
-[22:59] <jrand0m> shardy will be working on one after toorcon is finished </p>
-[22:59] <jrand0m> perhaps you two could work together on that? </p>
-[23:00] <co> jrand0m: Can you input a destination to send messages to by hand?</p>
-[23:00] <co> Better said, is there an ASCII representation of a destination?</p>
-[23:00] <jrand0m> yes co, to both </p>
-[23:00] <co> Excellent.</p>
-[23:00] <jrand0m> destinations, and all I2P structures, are loadable and serializable in (an alternate alphabet) base 64 </p>
-[23:01] <thecrypto> so it won't be easy to remember, but it will be ascii?</p>
-[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) </p>
-[23:02] <jrand0m> [though that is H(destination).toBase64() </p>
-[23:03] <jrand0m> ChZEROHag> if there's anything we can do to help you with that, just say the word </p>
-[23:03] <jrand0m> ok thats 1.1.  1.2) DH precalc </p>
-[23:03] <ChZEROHag> You could do it for me? :-)</p>
-[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 ;) </p>
-[23:04] <jrand0m> lol ChZEROHag </p>
-[23:04] <ChZEROHag> aah I know what I needed</p>
-[23:04] <ChZEROHag> A netdb implementation</p>
-[23:04] <thecrypto> is it in cvs?</p>
-[23:04] <thecrypto> the dh</p>
-[23:04] <jrand0m> yes thecrypto </p>
-[23:05] <jrand0m> C:\dev\i2p\code\core\java\src\net\invisiblenet\i2p\crypto\DHSessionKeyBuilder.java </p>
-[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</p>
-[23:05] <jrand0m> er, s/C:\\dev/g; s/\\/\//g </p>
-[23:05] *** wax_off (~nomail@anon.iip) has joined channel #iip-dev</p>
-[23:06] <jrand0m> word.  what do you need a netdb impl for? </p>
-[23:06] <ChZEROHag> I don't remember</p>
-[23:06] <jrand0m> we currently have a non-scalable netdb in cvs </p>
-[23:06] <jrand0m> heh </p>
-[23:06] <ChZEROHag> Haven't touched it in at least a week</p>
-[23:06] <jrand0m> you're working on a C I2CP api, right?  not I2NP? </p>
-[23:07] <ChZEROHag> I was just going to do everything</p>
-[23:07] *** wax_off has left #iip-dev</p>
-[23:07] <jrand0m> I2NP is really, really, really significantly more work than I2CP </p>
-[23:07] <ChZEROHag> Once I actually get properly started, it'll just roll out</p>
-[23:07] <jrand0m> but if you impl an I2NP in C that'd rule </p>
-[23:07] <dm> is there a I2NP in anything right now?</p>
-[23:07] <jrand0m> (I2CP:I2NP::FCP:FNP) </p>
-[23:07] <jrand0m> yes dm </p>
-[23:08] * ChZEROHag deminimizes emacs</p>
-[23:08] <jrand0m> the java impl i'm working on has I2NP functioning </p>
-[23:08] <dm> alrighty...</p>
-[23:08] <ChZEROHag> jrand0m: url? I could do with a reference, even if it's in a horrible language.</p>
-[23:08] <jrand0m> heh </p>
-[23:08] <jrand0m> erm, actually thats 6.0 administravia: aka where the fuck is our anon cvs access ;) </p>
-[23:09] <thecrypto> i'm getting the DH stuff</p>
-[23:09] <jrand0m> coo' </p>
-[23:09] <ChZEROHag> Oh right</p>
-[23:09] <Ryan_Singer> jrand0m,  back to schedule, the microroadmap?</p>
-[23:09] * thecrypto hides his face</p>
-[23:09] <ChZEROHag> well I'll wait :)</p>
-[23:09] <jrand0m> heh 'k </p>
-[23:09] <jrand0m> microroadmap </p>
-[23:09] <jrand0m> I have 0.1 through 0.5 mapped out </p>
-[23:09] <dm> followed freenet's roadmap then?</p>
-[23:10] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev</p>
-[23:10] <jrand0m> 0.1) functional, secure, not anonymous, not scalable, harvestable </p>
-[23:10] <dm> development slows down and freezes during 0.5...</p>
-[23:10] <jrand0m> we are now at 0.1.   </p>
-[23:10] <jrand0m> heh I noticed that dm, flinks hosed off at 0.5.2 as well ;) </p>
-[23:10] <co> What are you calling the whole package?</p>
-[23:10] <jrand0m> (strange coincidence) </p>
-[23:10] <co> i.e. version 0.1 of?</p>
-[23:10] <jrand0m> the whole package?  i2p router reference implementation </p>
-[23:10] <ChZEROHag> co: Wonga</p>
-[23:10] * beefbroth joins the meeting</p>
-[23:11] <jrand0m> buenos noches beefbroth </p>
-[23:11] <co> All right. That explains it.</p>
-[23:11] <ChZEROHag> Actually maybe I will call it that. Certainly sounds more interesting than 'i2pd'</p>
-[23:11] <jrand0m> 0.1 has bugs.  thats a given.  and it has no optimizations of note (though the DH precalc helps).   </p>
-[23:11] <jrand0m> heh </p>
-[23:11] <Ryan_Singer> jrand0m,  what's 0.2) then?</p>
-[23:11] <jrand0m> invisible internet police department </p>
-[23:11] <jrand0m> ok, 0.2 </p>
-[23:12] <jrand0m> 0.2 is functional, secure, anonymous, not scalable, harvestable </p>
-[23:12] <jrand0m> 0.2 adds support for non-zero-length tunnels </p>
-[23:12] <jrand0m> I actually implemented most of that last night, but not thoroughly tested </p>
-[23:12] <jrand0m> I think 0.2 will be ready by end of week </p>
-[23:12] <Ryan_Singer> how far away are we from that from a dev perspective?</p>
-[23:13] <Ryan_Singer> great</p>
-[23:13] <jrand0m> 0.3) is functional, secure, anonymous, scalable, harvestable </p>
-[23:13] * thecrypto gets bochs so he can simulate a network to help with this</p>
-[23:13] <jrand0m> 0.3 adds a kademliaDatabaseManager </p>
-[23:13] <jrand0m> right now we use a BroadcastDatabaseManager </p>
-[23:13] <jrand0m> (aka gnunet ;) </p>
-[23:14] <jrand0m> trivial to implement and functional for small networks, but we need the kademlia to scale </p>
-[23:14] <jrand0m> 0.4) is functional, secure, anonymous, scalable, non-harvestable </p>
-[23:14] <jrand0m> that adds trusted links </p>
-[23:14] <Ryan_Singer> jrand0m,  and how much of a dev challenge is it to implement kademlia?</p>
-[23:14] <jrand0m> I have two ideas for trusted links.. one is more easily implementable and usable </p>
-[23:15] <jrand0m> kademlia will probably take a full week </p>
-[23:15] <jrand0m> (to get right) </p>
-[23:15] <jrand0m> note that all of this has lots of room for refactoring and tuning.  I'm aiming functional first, then we tune. </p>
-[23:16] <co> Are you certain you will be able to develop and test that quickly?</p>
-[23:16] <jrand0m> I am certain of nothing </p>
-[23:16] <jrand0m> thats just my estimate </p>
-[23:16] <Ryan_Singer> co, hegets functional, we test</p>
-[23:16] <ChZEROHag> Are you sure?</p>
-[23:16] <ChZEROHag> (sorry)</p>
-[23:16] <co> Ryan_Singer: I see.</p>
-[23:17] * jrand0m <3 people who test :)</p>
-[23:17] <Myself248> When you say "we" test. Is there any place for non-coders to help with the testing?</p>
-[23:17] <jrand0m> Myself248> probably not until 0.4 </p>
-[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)</p>
-[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) </p>
-[23:18] <Myself248> Document, document, document.</p>
-[23:18] <dm> is there any though being put into active monitoring of network internals, or is it straightforward?</p>
-[23:18] <jrand0m> yes dm, absolutely </p>
-[23:18] <jrand0m> one of the key pieces of i2np is the inclusion of stats in the routerInfo strutures published </p>
-[23:18] <mihi> jrand0m: do a s/0./0.0./ ;)</p>
-[23:18] <jrand0m> the initial revs will publish real stats so we can tune </p>
-[23:19] <jrand0m> later revs will either not publish any stats or publish fake ones </p>
-[23:19] * jrand0m does not do 0.0</p>
-[23:19] <shardy> ok, I'm here</p>
-[23:19] <jrand0m> wb shardy </p>
-[23:19] <shardy> sorry for being late, forgot about this window being open, heh</p>
-[23:19] <dm> cool.</p>
-[23:19] <Ryan_Singer> is there a higher level document describing the archetecture for the network under .4?</p>
-[23:19] <jrand0m> off with your head </p>
-[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 </p>
-[23:20] <jrand0m> 0.4 is full i2np as described in the spec, just not optimally implemented </p>
-[23:20] <shardy> oh and jrand0m, I'll check out the DH optimization for you</p>
-[23:20] <jrand0m> word, gracias  </p>
-[23:20] <Ryan_Singer> can I get those docs?</p>
-[23:21] <jrand0m> the overview is at (Link: http://www.invisiblenet.net/i2p/i2p_philosophy.pdf)http://www.invisiblenet.net/i2p/i2p_philosophy.pdf </p>
-[23:21] <beefbroth> they're on the wiki I think?</p>
-[23:21] <jrand0m> hte old overview docs... hmm </p>
-[23:21] <jrand0m> (i2p specs are at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs)http://wiki.invisiblenet.net/iip-wiki?I2PProtocolSpecs) </p>
-[23:21] <co> They are on (Link: www.invisiblenet.net/i2p/.)www.invisiblenet.net/i2p/.</p>
-[23:21] <jrand0m> right beefbroth </p>
-[23:22] <jrand0m> though there are old docs in html format w/ ugly ms paint pictures from before showing how tunnels work... </p>
-[23:22] <beefbroth> I should know, I've read them enough</p>
-[23:22] <jrand0m> hehe </p>
-[23:22] <co> Unless those are older versions or mirrors.</p>
-[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) </p>
-[23:23] <thecrypto> jrand0m: the precalc looks good</p>
-[23:23] <jrand0m> cool </p>
-[23:24] *** pitu (~pitu@anon.iip) has joined channel #iip-dev</p>
-[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 </p>
-[23:25] <jrand0m> ok, thats the microroadmap </p>
-[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 </p>
-[23:26] <dm> that's okay, even that would be the fastest ever implementation of a network of this type ;)</p>
-[23:26] <Ryan_Singer> lol</p>
-[23:26] <beefbroth> when reading jrand0m's time estimates here, please remember that he has been drinking whiskey for the last 4 hours :-P</p>
-[23:26] <jrand0m> heh </p>
-[23:26] <Ryan_Singer> ok...apps/usage?</p>
-[23:26] <jrand0m> good whiskey at that ;) </p>
-[23:26] <jrand0m> ok, apps/usage </p>
-[23:27] <dm> 0.7 in 4 seconds....3...2...1..!!</p>
-[23:27] <jrand0m> I'm aiming for low hanging fruit here - these are things that we can do with 0 or minimal new code. </p>
-[23:27] <ChZEROHag> How are you supposed to code properly if you're stone sober?</p>
-[23:27] <jrand0m> all of these make significant use of mihi's kickass i2ptunnel </p>
-[23:27] <co> ChZEROHag: Easily.</p>
-[23:27] *** mihi has changed the topic on channel #iip-dev to <dm> 0.7 in 4 seconds....3...2...1..!!</p>
-[23:28] <jrand0m> using the i2ptunnel, we can do the following without writing any new code: </p>
-[23:28] <jrand0m> public ww proxy (using i2ptunnel + squid) </p>
-[23:28] * dm tips his hat to mihi.</p>
-[23:28] <jrand0m> JAP (using i2ptunnel + JAP) </p>
-[23:28] <mihi> you cannot kick asses though i2p (not through a tunnel either...)</p>
-[23:28] <jrand0m> browse www anon (i2ptunnel + web browser) </p>
-[23:28] <jrand0m> run an i2p web server (i2ptunnel + httpd) </p>
-[23:29] <co> Very nice. Bravo, mihi.</p>
-[23:29] <jrand0m> cvs outproxy (i2ptunnel) [e.g. cvs outproxy to sourceforge for anon freenet dev] </p>
-[23:29] <jrand0m> cvs client, cvs server </p>
-[23:29] <jrand0m> IM app, pop3 server, imap server, opennap </p>
-[23:29] <jrand0m> those are all really low hanging fruit </p>
-[23:29] <dm> okay, now all we need is i2p :)</p>
-[23:30] <jrand0m> right ;) </p>
-[23:30] <Myself248> wouldn't i2p webserver kinda supplant freenet? :)</p>
-[23:30] * jrand0m thinks that qualifies as a faq I should answer</p>
-[23:30] <Ryan_Singer> jrand0m,  but they are also very valuable</p>
-[23:30] <ChZEROHag> From that list, I'd consider cvs more important/useful</p>
-[23:30] <ChZEROHag> Partly because I wish to remain anonymous, but also because if anonymous www is provided you'll get lusers</p>
-[23:30] <jrand0m> i2p + web doesn't supplant freenet - freenet adds significant value on top of an anon comm framework - content distribution </p>
-[23:31] <ChZEROHag> And at the moment the idea of anonymous email is scary :)</p>
-[23:31] * dm writes down: "no lusers"</p>
-[23:31] <jrand0m> cvs definitely is in the top 3 </p>
-[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.</p>
-[23:31] <Ryan_Singer> ChZEROHag,  if it's scalable thats a goodthing</p>
-[23:31] <ChZEROHag> dm: lusers are only a problem during the early stages, but they tend not to use cvs</p>
-[23:31] <Myself248> okay, add lots of hashcash to any anon email thing.</p>
-[23:31] <ChZEROHag> Or, for that matter, even know what (or that) it is</p>
-[23:31] <co> I think one of the tests that needs to be done is a test attack on the network.</p>
-[23:31] <jrand0m> yes beefbroth, once i2p does what we aim at, freenet will most likely adjust to make use of it </p>
-[23:32] <co> Sorry if that is offtopic.</p>
-[23:32] <mihi> Myself248: just add a redirector to an anon remailer.</p>
-[23:32] <jrand0m> no, thats definitely on topic co - attacking this network is key </p>
-[23:32] <ChZEROHag> Myself248: hashcash is primarily to stop flooding while we're forced to use the ancient protocol that is 'irc'</p>
-[23:32] <ChZEROHag> Not to stop what could be termed 'abuse'</p>
-[23:32] <jrand0m> right mihi.  though perhaps mixminion run over i2p would be useful </p>
-[23:33] <jrand0m> right, hashcash is even built into i2p itself to keep messages from being delivered a single hop unless they "pay up" </p>
-[23:33] <Ryan_Singer> jrand0m,  we could run imap over this easily?</p>
-[23:33] <jrand0m> absolutely </p>
-[23:33] <Ryan_Singer> impressive</p>
-[23:33] <jrand0m> imapd with an i2ptunnel pointing at it, with i2ptunnel on the client pointing at that tunnel's destination </p>
-[23:34] <Myself248> and freenet search engines :)</p>
-[23:34] <mihi> ftp or several non-jabber instant messengers will make problems...</p>
-[23:34] <jrand0m> right, things that require two connections are more complex </p>
-[23:34] <ChZEROHag> jrand0m: hashcash in i2p?</p>
-[23:34] <ChZEROHag> I shall bug you about that when this is over.</p>
-[23:34] <shardy> hashcash in i2p? nice. </p>
-[23:34] <dm> we're getting ahead of ourselves! oh alright, who cares.. QUAKE + IIP!!!!!!</p>
-[23:34] <dm> sorry, I2p :)</p>
-[23:34] <jrand0m> lol dm </p>
-[23:35] <Myself248> Those of us with little CPUs get nervous when someone says hashcash, but as an anti-spamming measure I understand it.</p>
-[23:35] <co> dm: That is *reallY* getting ahead of ourselves.</p>
-[23:35] * mihi is jabber:schierlm@a-message.de ;)</p>
-[23:35] <jrand0m> yes ChZEROHag - Destination == public signing key (DSA) + public encryption key (ElGamal) + certificate (either null or hashcash(keys)) </p>
-[23:35] <beefbroth> is the i2p tunnel static or dynamic on the client end?</p>
-[23:35] <mihi> beefbroth: atm it is all static. but you could use a socks proxy as dest. ;)</p>
-[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 </p>
-[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.</p>
-[23:36] <co> beefbroth: It can be dynamic.</p>
-[23:36] <Ryan_Singer> the potential applications of the "low-hanging fruit"  here are very impressive</p>
-[23:36] <jrand0m> right mihi </p>
-[23:36] <jrand0m> "eleventy".  heh </p>
-[23:36] <ChZEROHag> the low hanging fruit is essentially 'normal' internet apps, but anonymously</p>
-[23:36] <ChZEROHag> right?</p>
-[23:36] <jrand0m> right </p>
-[23:36] <Ryan_Singer> yes</p>
-[23:36] <dm> (quake)</p>
-[23:37] <jrand0m> 0.1 runs them securely, 0.2 runs them anonymously, 0.3 runs them scalably, 0.4 runs them non-harvestably </p>
-[23:37] <jrand0m> (we're @ 0.1 now) </p>
-[23:37] <shardy> what do you mean by non-harvestably?</p>
-[23:37] <co> Sorry, what is harvestable again?</p>
-[23:37] <ChZEROHag> dm: Unfortunately we've ben held back enough that realtime is after more than 30 years still not 'normal'</p>
-[23:37] <Myself248> Phew. I was hoping someone would ask that. ;)</p>
-[23:37] <Ryan_Singer> loggable</p>
-[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 </p>
-[23:38] <Myself248> oh, like you can do with gnutella. :)</p>
-[23:38] <Ryan_Singer> secret-servicy like goons</p>
-[23:38] <jrand0m> right </p>
-[23:39] <shardy> ah, gotcha.</p>
-[23:39] <jrand0m> ok, but yeah, thats the microroadmap. </p>
-[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? </p>
-[23:40] <Ryan_Singer> jrand0m,  and we will see .4 when?</p>
-[23:40] <jrand0m> 0.4 is probably 2 weeks out </p>
-[23:40] * jrand0m is taking a week off (ish) in mid october as I have people coming to visit</p>
-[23:40] *** Signoff: dm (EOF From client)</p>
-[23:40] <mihi> 1.0 should be stable.</p>
-[23:40] <co> Let 1.0 be functional and safe.</p>
-[23:40] <thecrypto> dittos co</p>
-[23:41] <Ryan_Singer> 1.0 should be functional, stable and safe</p>
-[23:41] <ChZEROHag> jrand0m: My philosophy, regarding version numbers, is if in doubt, copy Linux</p>
-[23:41] <Myself248> 5.0 can be "perfect". Free software people are overly afraid of version number bloat.</p>
-[23:41] <jrand0m> word </p>
-[23:41] <mrflibble> jrand0m, v1 of things are never perfect :)</p>
-[23:41] *** dm (~gj@anon.iip) has joined channel #iip-dev</p>
-[23:41] <mrflibble> people dont expect them to be perfect either</p>
-[23:41] <dm> did I miss 1.0?</p>
-[23:41] <ChZEROHag> mrflibble: People don't expect any software to be perfect. People use windows.</p>
-[23:41] <Ryan_Singer> this software will beGPL orLGPL?</p>
-[23:41] <jrand0m> cool, I've already gotten flack for 1.0 being not-perfect yet </p>
-[23:41] <ChZEROHag> That doesn't mean it shouldn't be.</p>
-[23:41] <mrflibble> good point ChZEROHag</p>
-[23:42] <dm> ah shit, I did didn't i..</p>
-[23:42] <mihi> dm: stop kidding</p>
-[23:42] <mrflibble> yup, u did</p>
-[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) </p>
-[23:42] <dm> alright alright I'm sorry :(</p>
-[23:42] <jrand0m> actually, I take that back </p>
-[23:42] <jrand0m> I used the Base64.java from freenet too </p>
-[23:43] <beefbroth> are we still on agenda item 0.3 Apps ?</p>
-[23:43] <jrand0m> so base64 is GPL :) </p>
-[23:43] <thecrypto> and the IM client will be GPL</p>
-[23:43] <jrand0m> oh yeah, we're on 0.3 aren't we </p>
-[23:43] <thecrypto> as soon as i get around to putting comments in the code</p>
-[23:43] *** UserX_ (~User@anon.iip) has joined channel #iip-dev</p>
-[23:43] <jrand0m> heh thecrypto </p>
-[23:43] <ChZEROHag> GPL sounds good to me</p>
-[23:43] <jrand0m> w0ah, 23 users </p>
-[23:43] <Myself248> we're on agenda item 6.02E23, random crap. :)</p>
-[23:43] <Ryan_Singer> jrand0m,  if you get time, I want to talk to you about liscencing and potential consulting gigs</p>
-[23:43] <jrand0m> cool Ryan_Singer </p>
-[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?</p>
-[23:43] <mihi> jrand0m: 22 ;)</p>
-[23:43] <jrand0m> ChZEROHag> read my license on flinks ;) </p>
-[23:43] <Myself248> we need an anonymous court system.</p>
-[23:44] * mihi is here twice</p>
-[23:44] <jrand0m> Myself248> its called yodel ;) </p>
-[23:44] <Myself248> "The court now hears docket number 34534, J. Doe v. J. Doe"</p>
-[23:44] <Ryan_Singer> ChZEROHag,  the reason I ask is for corporations to make use of this software for security against industrialespionage</p>
-[23:44] <co> Naming server will be licensed under GPL as well.</p>
-[23:44] <CCD> lol</p>
-[23:44] <Myself248> "Baliff, aren't those the same parties as the last 34533 cases we've heard?"</p>
-[23:44] <shardy> well</p>
-[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.</p>
-[23:45] <co> shardy: You mean public domain?</p>
-[23:45] <beefbroth> i think that was co's lead in to 0.4 agenda item :-P</p>
-[23:45] <jrand0m> shardy> the specs are public and open.  I have not asserted copyright on the specs. </p>
-[23:45] <Ryan_Singer> shardy,  no, we would like work on the protocol to stay available</p>
-[23:45] <shardy> public domain, bsd license, "do whatever you want just give us credit please" license, etc</p>
-[23:45] <jrand0m> the code is GPL for the router.  one client api implementation in java is GPL </p>
-[23:46] <Ryan_Singer> check out the liberty protocol.... (Link: http://projectliberty.org)http://projectliberty.org</p>
-[23:46] <shardy> jrand0m: ok cool. gotcha.</p>
-[23:46] * jrand0m has thought about "no government use" licenses ;)</p>
-[23:46] <jrand0m> ok, the reason I tossed 3.0) apps into the list of issues is this </p>
-[23:46] <jrand0m> we need help. </p>
-[23:46] <Ryan_Singer> help with what?</p>
-[23:46] <jrand0m> i2ptunnel is good code.  i2p's router will be good code. </p>
-[23:47] <jrand0m> what we need is for people to start figuring out the nuts and bolts of release engineering </p>
-[23:47] <dm> why do you need apps if you can just use i2ptunner?</p>
-[23:47] <ChZEROHag> jrand0m: come again?</p>
-[23:47] <jrand0m> aka, how to actually package something up that joe sixpack can download and browse the web </p>
-[23:47] <ChZEROHag> dm: Why do you need apps if you can just use telnet?</p>
-[23:47] <dm> what?</p>
-[23:47] * dm scratches his head.</p>
-[23:47] <CCD> err, there is something besides telnet?</p>
-[23:48] * jrand0m thinks thats ChZEROHag's point dm ;)</p>
-[23:48] *** Myself248 is now known as myself248</p>
-[23:48] *** Signoff: thecrypto (Ping timeout)</p>
-[23:48] <ChZEROHag> dm: To use i2ptunnel would be like having a working car and then dragging it around on a handcart</p>
-[23:48] <jrand0m> ok, thats just that.  I just wanted to mention in case people had spare time :) </p>
-[23:48] <jrand0m> ok, 4.0) </p>
-[23:48] <jrand0m> naming service </p>
-[23:48] <dm> I can see he's trying to make a point.</p>
-[23:48] <jrand0m> hi co, hows it going?  :) </p>
-[23:48] <co> The naming server must be GPL, since at least the Java implementation uses code from the client library to contact routers.</p>
-[23:49] <dm> but we just spent 20 minutes going: I2Ptunnel + web server!, I2Ptunnel + quake! ;)</p>
-[23:49] <ChZEROHag> Or, in computing terms, like doing all your internet stuff with telnet instead if directly on the ip stack</p>
-[23:49] <co> I did not do much last week. I released the client API, which also needs work.</p>
-[23:49] <ChZEROHag> i2ptunnel is an interrim solution</p>
-[23:49] <co> I will have time this week, though, to begin implementing the naming server.</p>
-[23:49] <jrand0m> cool </p>
-[23:49] <jrand0m> where is the client api again? </p>
-[23:50] <mihi> on the mailing list ;)</p>
-[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.</p>
-[23:50] <jrand0m> ChZEROHag> in some ways its interim </p>
-[23:50] * jrand0m !thwaps self</p>
-[23:50] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev</p>
-[23:50] <dm> so is TCP!</p>
-[23:50] *** yodel (yodel@anon.iip) has joined channel #iip-dev</p>
-[23:50] <jrand0m> 'lo yodel </p>
-[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)?</p>
-[23:50] <co> I will put the naming service specification and client API into CVS.</p>
-[23:50] <jrand0m> wb thecrypto </p>
-[23:50] <ChZEROHag> These have probably been covered before, but how will the ns provide unique names fairly?</p>
-[23:50] * mihi wants to have *.mihi.iip ;)</p>
-[23:50] <jrand0m> beefbroth> with the naming service or without? </p>
-[23:50] <jrand0m> heh mihi </p>
-[23:50] <ChZEROHag> avoiding the squatting, etc. that has plagued DNS</p>
-[23:50] <thecrypto> can someone send me what happened?</p>
-[23:51] <beefbroth> jrand0m: with. i think without would be a long string of numbers.</p>
-[23:51] <co> ChZEROHag: You will register with a group of naming servers, then will use the name of that group to identify yourself.</p>
-[23:51] <co> As in IM.beefbroth.mygroup if you provide IM service.</p>
-[23:51] <mihi> oops, s/iip/i2p</p>
-[23:51] *** godmode0_ (~mode@anon.iip) has joined channel #iip-dev</p>
-[23:51] *** Signoff: godmode0 (EOF From client)</p>
-[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 </p>
-[23:51] <co> Yes, it will be possible for someone to register the username beefbroth with group2.</p>
-[23:51] <thecrypto> in the 4 minutes i was gone</p>
-[23:52] <ChZEROHag> co: So the only issue is the .mygroup uniqueness?</p>
-[23:52] <ChZEROHag> And who gets the group 'com'? :-)</p>
-[23:52] <jrand0m> and that is selected by the client </p>
-[23:52] <mihi> ChZEROHag: i2p is not COMmerical</p>
-[23:52] <jrand0m> (e.g. you tell your ns client lib "group '.com' is group 0123ff33aefcbb34fe </p>
-[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</p>
-[23:52] <co> ChZEROHag: I am not sure who gets the "com" group.</p>
-[23:52] <co> Good question.</p>
-[23:53] <shardy> beefbroth: except the "regular web" is no longer only 3 letter lds</p>
-[23:53] <mihi> beefbroth: or add a .i2p to all addresses.</p>
-[23:53] <ChZEROHag> beefbroth: That illusion is only present in america</p>
-[23:53] <shardy> tlds.</p>
-[23:53] <jrand0m> to start with, we may just want to initially have one group of naming servers, ".i2p" </p>
-[23:53] <co> beefbroth: The naming server software permits you to have up to 32 letters.</p>
-[23:53] <ChZEROHag> Elsewhere we use the 2-letter country codes given us</p>
-[23:53] <shardy> .us is also in use in america.</p>
-[23:53] <co> Actually, I wanted the first group to be "test".</p>
-[23:53] <shardy> as are things like .info and .name</p>
-[23:53] <jrand0m> heh 'k </p>
-[23:54] <ChZEROHag> shardy: yeah, by about 5 people.</p>
-[23:54] <ChZEROHag> But this is perhaps a rant for another time :)</p>
-[23:54] <jrand0m> actually... </p>
-[23:54] <shardy> there's even a .museum</p>
-[23:54] <Ryan_Singer> jrand0m,  using .12p sounds good</p>
-[23:54] <jrand0m> I ran into a distributed DNS based of JXTA the other day </p>
-[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).</p>
-[23:55] <ChZEROHag> YEs that bit makes perfect sense</p>
-[23:55] <mihi> ChZEROHag: (Link: http://www.nic.us/press/audio/dotus-mayEM.wav)http://www.nic.us/press/audio/dotus-mayEM.wav ;)</p>
-[23:55] <jrand0m> co> can't you just say "well, they 'think' they're .com, but I say .com is run by group2"? </p>
-[23:55] <ChZEROHag> What I'm getting at, I suppose, is does it rely on first-come-first-served?</p>
-[23:55] <co> You may configure your client to do anything.</p>
-[23:56] <Ryan_Singer> how does the JXTA name system work?</p>
-[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 </p>
-[23:56] <co> ChZEROHag: In registering your username with a group, yes.</p>
-[23:56] <co> jrand0m: I will look at that after the meeting.</p>
-[23:56] <jrand0m> jxta runs naming servers off rendevous points </p>
-[23:56] <ChZEROHag> mihi: wassat?</p>
-[23:56] <beefbroth> so it is possible someone tries to attack the NS system by mimicing the already existing i2p group of naming servers</p>
-[23:57] *** Signoff: jeremiah (Ping timeout)</p>
-[23:57] <co> beefbroth: I think not.</p>
-[23:57] <mihi> ChZEROHag: listen to it. why xxx million americans prefer .us over .com</p>
-[23:57] <mihi> 68 million</p>
-[23:57] <co> As I envision it, people setting up groups will announce those groups.</p>
-[23:57] <jrand0m> mimicing?  they can't mimic as the servers in the group are authenticated by public key systems </p>
-[23:58] <jrand0m> however, if groups allow non-trusted members to join the group, they can be taken over trivially. </p>
-[23:58] <shardy> but how is the key exchange done?</p>
-[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.</p>
-[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.</p>
-[23:58] <beefbroth> what happens if two groups of naming servers both claim to resolve the .i2p group?</p>
-[23:58] <co> Good question, though, and I will think over it again, carefully.</p>
-[23:58] <ChZEROHag> Anyway, I shall have a listen</p>
-[23:58] <jrand0m> shardy> no key exchange - key publishing </p>
-[23:58] <beefbroth> i see, good point</p>
-[23:58] <ChZEROHag> co: Yeah that's another thing I was trying to get at</p>
-[23:58] <shardy> but keys can still be intercepted if they're published online</p>
-[23:58] <jrand0m> beefbroth> no one claims anything.  your client says "i2p == [dest1, dest2, dest]" </p>
-[23:59] <shardy> what we need is a trust-based dns system :)</p>
-[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</p>
-[23:59] <co> Thank you for bringing this up.</p>
-[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) </p>
-[23:59] <ChZEROHag> Yeah we have one - everyone trusts IANA (or whatever they call themselves) or else.</p>
-[23:59] * shardy ducks</p>
-[23:59] <ChZEROHag> :-D</p>
-[23:59] <mrflibble> they're trying that with dnssec, but of course that's not anonymous</p>
-[00:00] <jrand0m> what this naming service does is get away from root servers </p>
-[00:00] <beefbroth> you could always have an i2p homepage that listed active naming groups and authorites?</p>
-[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...</p>
-[00:00] <co> shardy: I think I covered key exchange in the spec. If not, tell me.</p>
-[00:00] <shardy> but packaging it oob makes it better</p>
-[00:00] <shardy> co: I'll check it out. </p>
-[00:00] <jrand0m> shardy> oh, right.  yes, people need to be able to trust the code they download </p>
-[00:00] <co> beefbroth: Certainly.</p>
-[00:01] <ChZEROHag> aah that reminds me</p>
-[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 </p>
-[00:01] <ChZEROHag> I should create a gpg key for my iipmail</p>
-[00:01] *** yodel has left #iip-dev</p>
-[00:01] * ChZEROHag does so while unexciting stuff happens</p>
-[00:01] <jrand0m> heh ok </p>
-[00:01] <co> Please understand that the naming server specification is still open to suggestions for improvement.</p>
-[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</p>
-[00:02] <co> I do not claim it is perfect or finalized at this time.</p>
-[00:02] <jrand0m> heh I hope its a long flight </p>
-[00:02] <shardy> and it's more productive than playing fft advance the entire time, heh</p>
-[00:02] * jrand0m has found that criticism will more freely come once there is code implementing specs</p>
-[00:02] *** godmode0_ is now known as godmode0</p>
-[00:02] <co> And I have to write the code.</p>
-[00:02] <co> I think we can move on to the next topic now.</p>
-[00:02] <jrand0m> 'k </p>
-[00:02] <jrand0m> 5.0) IM </p>
-[00:03] <jrand0m> hi thecrypto </p>
-[00:03] <mihi> names should not be able to clash with base64 representations.</p>
-[00:03] <thecrypto> hi</p>
-[00:03] <thecrypto> okay</p>
-[00:03] <mihi> and the namin server should transparently return bas64 addressas as is.</p>
-[00:03] <co> mihi: Very well, I will try to avoid that problem.</p>
-[00:03] <thecrypto> first since my e-mail isn't working again (damn spammers)</p>
-[00:03] <jrand0m> (all classes that extend DataStructure have String .toBase64() and .fromBase64(InputStream) ) </p>
-[00:03] <thecrypto> i'll answer whit's questions about me system here</p>
-[00:04] * jrand0m loads up co's email</p>
-[00:04] <mihi> jrandom? why Inputstream and not Reader?</p>
-[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</p>
-[00:04] <jrand0m> if you want a Reader, just run an InputStreamReader, you brat </p>
-[00:04] <mihi> base64 is characters, not bytes in my opinion.</p>
-[00:04] <ChZEROHag> jrand0m: IM == Instant Messaging?</p>
-[00:04] <jrand0m> yes ChZEROHag </p>
-[00:04] <thecrypto> if people have a problem with that, give me a suggestion for what to call it about</p>
-[00:05] <ChZEROHag> jabber?</p>
-[00:05] <thecrypto> IM == my own distributed IM network</p>
-[00:05] <shardy> you should call it "bob"</p>
-[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 </p>
-[00:05] <co> How about IM application?</p>
-[00:05] <ChZEROHag> (anonabber)</p>
-[00:05] <co> jrand0m: I see.</p>
-[00:05] <thecrypto> jabber requires a centerized server</p>
-[00:05] <jrand0m> terminology doesn't matter to me.  I like shardy's idea </p>
-[00:05] <ChZEROHag> thecrypto: Nothing *requires* a centralised server</p>
-[00:05] <thecrypto> and i cannot spell today so bear with me</p>
-[00:06] <ChZEROHag> That's just the way things are written</p>
-[00:06] <jrand0m> (though I prefer Betty) </p>
-[00:06] <thecrypto> so you want me to call it I2PIM bob?</p>
-[00:06] <thecrypto> :)</p>
-[00:06] <jrand0m> how about wilma? </p>
-[00:06] <jrand0m> fred is taken thoug </p>
-[00:06] <co> How about distributed IM?</p>
-[00:06] <jrand0m> DIM, heh </p>
-[00:06] <co> But then, distributed IM *application*?</p>
-[00:06] <dm> AIM, anonymous Instant messaging!</p>
-[00:06] <thecrypto> bad acronym :)</p>
-[00:07] <dm> then we can take over AOL.</p>
-[00:07] <thecrypto> ohh i can just wait for AOL to get wind of that</p>
-[00:07] <ChZEROHag> dm: That would realy piss certain wankers off. I like it.</p>
-[00:07] <jrand0m> heh do it </p>
-[00:07] <Ryan_Singer> thecrypto,  will webe able to implement IM in a decentralised way, or will it have to be centrallized?</p>
-[00:07] <co> dm: Good idea. I would back that acronym.</p>
-[00:07] <jrand0m> the way I've read thecrypto's docs, the IM is fully decentralized </p>
-[00:07] <thecrypto> i am implementing a distributed IM, it's in the CVS</p>
-[00:07] <beefbroth> I would vote against anything that is going to confuse people</p>
-[00:08] <Ryan_Singer> AOL TimeWarner changed it's name to Time Warner</p>
-[00:08] <ChZEROHag> beefbroth: I would too, but the vote to piss AOL off outweighs that.</p>
-[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</p>
-[00:08] <jrand0m> actually, thats a good point </p>
-[00:08] <thecrypto> I2PIM is the name of the application</p>
-[00:08] <jrand0m> being transparently anonymous isn't useful if people don't understand what anonymous is. </p>
-[00:09] <ChZEROHag> Oh wait, I have something like this down on paper</p>
-[00:09] <beefbroth> I like the crypto's idea</p>
-[00:09] <thecrypto> what "network" I2PIM runs on is what I'm looking for</p>
-[00:09] <jrand0m> teaching people how to protect themselves is a really important thing </p>
-[00:09] <thecrypto> i was thinking Presence System?</p>
-[00:09] <Ryan_Singer> hypethe security aspect of anon</p>
-[00:09] <dm> I2M (instant 2 messaging)</p>
-[00:09] <ChZEROHag> Although I only called it XIrc</p>
-[00:10] <jrand0m> you're the man thecrypto, whatever works for ya ;) </p>
-[00:10] <dm> and in the I2M logo, the 2 will be really small :)</p>
-[00:10] <thecrypto> well I2P expands to Invisible ... jrand0m ?</p>
-[00:10] <ChZEROHag> The main thing I liked about it was that everyone was called a Borg and they chatted in Collectives</p>
-[00:10] <jrand0m> i2p = i^2p (invisible internet project) </p>
-[00:10] <co> I thought the P stands for protocol.</p>
-[00:10] <jrand0m> that too </p>
-[00:10] <jrand0m> well, actually, no </p>
-[00:11] <thecrypto> so it's Invisible Internet Project Instant Messaging</p>
-[00:11] <jrand0m> i2np is the protocol </p>
-[00:11] <jrand0m> i2p is the project </p>
-[00:11] <beefbroth> I thought it stood for "poop"</p>
-[00:11] <jrand0m> i2cp is the client proto </p>
-[00:11] <co> thecrypto: You are right, the name does not matter too much.</p>
-[00:11] <dm> i2m = i^2m = instant invisible messaging</p>
-[00:11] <thecrypto> so next topic then</p>
-[00:11] <Ryan_Singer> ok....so, we're drifting off agenda...are we done with IM?</p>
-[00:11] <shardy> if "bob" isn't good enough, we can call it "jimbob"</p>
-[00:11] <jrand0m> 0k, 6.0) administravia </p>
-[00:11] <thecrypto> no, still more here</p>
-[00:12] <thecrypto> sorry</p>
-[00:12] <co> It's administrivia.</p>
-[00:12] <thecrypto> no it's IM</p>
-[00:12] <jrand0m> nop> give me root.  I need to get anon cvs, bugzilla, and cvsweb installed. </p>
-[00:12] <thecrypto> i wasn't finished</p>
-[00:12] <thecrypto> :)</p>
-[00:12] <thecrypto> rewind!</p>
-[00:12] * jrand0m backs up</p>
-[00:12] <jrand0m> 5.1) thecrypto v2 </p>
-[00:12] <Ryan_Singer> what else is there in IM, thecrypto?</p>
-[00:13] <mihi> thecrypto: just talk on; /me idi it the same way as i missed the naming services</p>
-[00:13] <thecrypto> okay, the thing about presences communicating is different</p>
-[00:13] <thecrypto> not everyone knows everyone else</p>
-[00:13] <thecrypto> there is practically no way to "stalk" someone</p>
-[00:13] <thecrypto> you have to ask to be shown</p>
-[00:14] <mihi> in anonymous networks, usually no one knows anyone else ;)</p>
-[00:14] <jrand0m> (as long as people's Destination is random) </p>
-[00:14] *** Signoff: pitu (Lost terminal)</p>
-[00:14] <dm> what do you mean?</p>
-[00:14] <thecrypto> Alice wants to talk to Bob</p>
-[00:14] <jrand0m> mihi> though the naming service allows search by service </p>
-[00:14] <jrand0m> (service being IM, www, etc) </p>
-[00:14] <thecrypto> Alice finds Bobs IM destination some how, prolly by the naming service</p>
-[00:15] <thecrypto> So Alice sends a message to Bobs IM destination</p>
-[00:15] <dm> yes?</p>
-[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</p>
-[00:16] <thecrypto> but there is no central presence server, Alice can also just see her message disappear and not get a response</p>
-[00:16] <dm> ok, like MSN then?</p>
-[00:16] <jrand0m> (though Alice can know that Bob ignored her) </p>
-[00:16] <thecrypto> and Alice can't just put Bob on her buddy list and wait for him</p>
-[00:16] <Ryan_Singer> thecrypto,  ok...how is this different then properly configured Y!, MSN or AIM..apart from the nocentral server bit</p>
-[00:16] <thecrypto> because Bob has to send a message to Alice to see her sign on</p>
-[00:16] <Ryan_Singer> oh</p>
-[00:16] <dm> ok, it doesn't change anything as far as the user is concerned, but I see what you mean.</p>
-[00:17] <jrand0m> thecrypto> not quite true </p>
-[00:17] <Ryan_Singer> got it..no buddylist functionality...</p>
-[00:17] <jrand0m> oh, well, hmm, technically... </p>
-[00:17] <thecrypto> Ryan_Singer: no there is still a buddy list</p>
-[00:17] <dm> how does alice send bob a message if she can't see him?</p>
-[00:17] <dm> you just have to try random contacts in case they are there?</p>
-[00:17] <jrand0m> bob has to send a message to alice's router, which can happen without alice knowing it </p>
-[00:17] <thecrypto> Alice can just randomly try</p>
-[00:18] <dm> that's not very convenient? you go online and have to send everyone a message saying (you there?, you there?)</p>
-[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</p>
-[00:18] * co notes that there can be two Bobs registered with two different naming server groups.</p>
-[00:18] <thecrypto> beefbroth: that was just want i'm saying</p>
-[00:18] <dm> ok, so similar to current scheme but you are invisible by default.</p>
-[00:18] <dm> gotcha.</p>
-[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</p>
-[00:19] <thecrypto> if you want to</p>
-[00:19] <co> So the user controls who can see him/her/it.</p>
-[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"</p>
-[00:20] <Ryan_Singer> when you get off do you first send a msg that says "I'm getting off"?</p>
-[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.</p>
-[00:20] <Ryan_Singer> hopefully</p>
-[00:20] <jrand0m> Ryan_Singer> or just have a periodic "I'm still on" ping </p>
-[00:20] <jrand0m> (and missing ping == off) </p>
-[00:21] <Ryan_Singer> keep-alive type deal?</p>
-[00:21] <beefbroth> It might need to "ping" the other IM user every so often to make sure there wasn't an unintentional disconnect</p>
-[00:21] <thecrypto> if Bob has Alice on his buddy list and Bob recives and Online message from Alice the return message is automatic</p>
-[00:21] <beefbroth> heh</p>
-[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</p>
-[00:21] <dm> ok, so the IM experience is the same as it is now. Just wanted to confirm that.</p>
-[00:22] <thecrypto> just you now have a confirm on buddy adds</p>
-[00:22] <thecrypto> which i think only ICQ has</p>
-[00:22] <jrand0m> will the IM app be a stand alone or will I be able to use trillian? </p>
-[00:22] <dm> yeah, that's how MSN works.</p>
-[00:22] <jrand0m> [etc] </p>
-[00:22] <ChZEROHag> thecrypto: ICQ only pretends to require confirmation</p>
-[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 :)</p>
-[00:23] <thecrypto> jrand0m: i'll make a spec, trillian can either give me a plugin interface or they can write thier own</p>
-[00:23] <thecrypto> i will be writing a plugin for gaim at leasty</p>
-[00:23] <thecrypto> along with a standalong client</p>
-[00:23] <jrand0m> cool </p>
-[00:23] <thecrypto> which is built to be used with the network</p>
-[00:23] <jrand0m> does gaim support file xfer or will that be the benefit of the i2pim client? </p>
-[00:23] <beefbroth> thecrypto: you might want to give a shout to the kopete developers just to let them know</p>
-[00:23] * jrand0m shows his cluelessnesss</p>
-[00:24] <thecrypto> i'll try to make the gaim plugin work as well as the standalong, but i don't know</p>
-[00:24] <co> thecrypto: Let's have the standalone application first.</p>
-[00:24] <thecrypto> gaim file transfer i think only works on AIM</p>
-[00:24] <thecrypto> so it might take some wrangling to get it into a plugin</p>
-[00:24] <Ryan_Singer> ok..I think we all understand this now...any more IM issues?</p>
-[00:25] <thecrypto> and co's final thing</p>
-[00:25] <beefbroth> gaim suffers problems with it's IM xfers for people using NAT</p>
-[00:25] <thecrypto> more than one person can have the same name</p>
-[00:25] <thecrypto> they will have unique destinations</p>
-[00:25] *** Signoff: mihi (Ping timeout)</p>
-[00:25] <co> All right.</p>
-[00:25] * mihi_backup is still here...</p>
-[00:25] <thecrypto> but someone can't masquerde</p>
-[00:26] <jrand0m> heh nice1 mihi_backup </p>
-[00:26] <co> If you use the naming server, it will be "Bob from group1" and "Bob from group2".</p>
-[00:26] <co> With unique destinations.</p>
-[00:26] <jrand0m> right thecrypto.  names are arbitrary.  kind of like dns ;) </p>
-[00:26] *** mihi (~none@anon.iip) has joined channel #iip-dev</p>
-[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?"</p>
-[00:27] <dm> mihi: your backup talked while you were gone.</p>
-[00:27] <thecrypto> if they person is trying to masquerde Bob, you'll know, otherwise, you can alias them out</p>
-[00:27] <mihi> i know...</p>
-[00:27] <jrand0m> "someone called bob"?  says who?  they call themself bob?  or some group calls them bob?  or you call their dest bob? </p>
-[00:27] <thecrypto> there is a feild in the presence called name</p>
-[00:27] <thecrypto> i'm looking at that</p>
-[00:28] * jrand0m likes the way ICQ works with that problem - everyone is a number and you just alias numbers locally to names</p>
-[00:28] <co> As an aside, should I make the NS entity names case insensitive?</p>
-[00:28] <jrand0m> probably co </p>
-[00:28] <mihi> base64 things must be case sensitive still ;)</p>
-[00:28] * jrand0m doesn't want people spoofing Jrand0m</p>
-[00:28] <co> mihi: Entity names, not destinations.</p>
-[00:28] <jrand0m> right right mihi </p>
-[00:29] <jrand0m> (well, people can spoof jrand0m all they want.  I just want jrandom back) </p>
-[00:29] <co> Go on, thecrypto.</p>
-[00:29] *** Signoff: UserX_ (Ping timeout)</p>
-[00:29] <thecrypto> that's all i have</p>
-[00:29] <thecrypto> finally :)</p>
-[00:29] <mihi> co: you should be able to place a destination wherever you can place an entity name.</p>
-[00:29] <mihi> like it is with dns names and IPs</p>
-[00:29] <co> mihi: Good point. I will add that to the specification.</p>
-[00:29] <thecrypto> jrand0m: actully it's kinda like ICQ except you tell people what you'd like your alias to be</p>
-[00:30] <thecrypto> which i think they do now</p>
-[00:30] <co> The idea, though, is that it will be much shorter to type names than destinations.</p>
-[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 </p>
-[00:30] <Ryan_Singer> ok guys...I have a meeting... jrand0m, anonymail me</p>
-[00:30] <jrand0m> 'k adios </p>
-[00:30] <mihi> jrand0m: yes, and it should return that dest itself, and not "not found"</p>
-[00:31] <jrand0m> right </p>
-[00:31] *** Signoff: Ryan_Singer ((null))</p>
-[00:31] <jrand0m> ok.  we're at 7.0)  </p>
-[00:31] <jrand0m> questions </p>
-[00:31] <jrand0m> hi </p>
-[00:31] <co> What about 6.0) Administrivia?</p>
-[00:32] <co> Or were you done with that?</p>
-[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 :) </p>
-[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?</p>
-[00:33] <jrand0m> you volunteering? </p>
-[00:33] <jrand0m> (aka yeah, that'd be great) </p>
-[00:33] <beefbroth> If I learn how to make a package for my distribution :)</p>
-[00:33] <jrand0m> what distro do you use? </p>
-[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?</p>
-[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.</p>
-[00:34] <dm> jr makes for a good manager :)</p>
-[00:34] <jrand0m> yes co, simpler, but not as scalable </p>
-[00:34] *** UserX_ (~User@anon.iip) has joined channel #iip-dev</p>
-[00:34] <thecrypto> yes, but some people don't want IRC</p>
-[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 </p>
-[00:35] <co> thecrypto: Good point, though I2P will anonymize people's IP addresses.</p>
-[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.</p>
-[00:35] <jrand0m> awesome beefbroth </p>
-[00:35] <thecrypto> if we have IM and IRC, more adoption</p>
-[00:36] <mihi> co: the problem is that with irc there is something to shut down (servers).</p>
-[00:36] *** jeremiah (~jeremiah@anon.iip) has joined channel #iip-dev</p>
-[00:36] <jrand0m> thecrypto> instant adoption: opennap </p>
-[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</p>
-[00:36] <dm> IRC is quite tough though isn't it?</p>
-[00:36] <dm> distributed IRC that is...</p>
-[00:36] <co> mihi: Of course. I forgot that. Thank you for reminding me. Objection withdrawn.</p>
-[00:37] <jrand0m> dm> irc can have multiple irc servers (ala efnet, etc) that talk to each other through i2p </p>
-[00:37] <shardy> do you mean an "irc lookalike" chat protocol?</p>
-[00:37] <shardy> or adapting irc?</p>
-[00:37] <jrand0m> with people talking to each other by tunneling to one of the irc servers via i2p </p>
-[00:37] <dm> irc with servers behind i2p is fine, I'm saying without servers. Doesn't matter I guess.</p>
-[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) </p>
-[00:39] <dm> anyway, it's off-topic.</p>
-[00:39] <dm> carry on!</p>
-[00:39] <jrand0m> any other questions?   </p>
-[00:39] <jrand0m> anyone read the specs yet?  ;) </p>
-[00:39] <jrand0m> (other than beefbroth, who has them memorized) </p>
-[00:39] * dm looks at the ceiling.</p>
-[00:40] <jrand0m> ok, 100 minute meeting it is then </p>
-[00:40] <thecrypto> i'm reading the, when i need something :)</p>
-[00:40] <ChZEROHag> specs!</p>
-[00:40] <ChZEROHag> That's what I forgot!</p>
-[00:40] <jrand0m> heh </p>
-[00:41] *** dm has changed the topic on channel #iip-dev to topic1</p>
-[00:41] * jrand0m loads up and...</p>
-[00:41] * jrand0m *baf*s the meeting to an end</p>
-</div>{% endblock %}
\ No newline at end of file
+[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/59.rst b/i2p2www/meetings/59.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/59.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/60.log b/i2p2www/meetings/60.log
index 12262e42..a83edfe4 100644
--- a/i2p2www/meetings/60.log
+++ b/i2p2www/meetings/60.log
@@ -1,279 +1,274 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 60{% endblock %}
-{% block content %}<div class="irclog">
-[22:53] <jrand0m> 0.x) welcome </p>
-[22:53] <jrand0m> 1.x) todo before i2p 0.2: </p>
-[22:53] <jrand0m> 1.1) bw limiting </p>
-[22:54] <jrand0m> 1.2) AES the tcp transport </p>
-[22:54] <jrand0m> 1.3) package up [distro, building, seeding, running] </p>
-[22:54] <jrand0m> 1.4) ElG session ack discussion </p>
-[22:54] * hezekiah is away: Is off eating to keep up is strength for his upcoming tests</p>
-[22:54] <jrand0m> 2.x) apps </p>
-[22:54] <jrand0m> 2.1) ns </p>
-[22:54] <jrand0m> 2.2) i2pim </p>
-[22:54] <jrand0m> 2.3) i2ptunnel </p>
-[22:54] <jrand0m> 3.x) ??? </p>
-[22:54] <jrand0m> 0.x) welcome </p>
-[22:54] <jrand0m> welcome to meeting 60 </p>
-[22:54] <dm> thanks</p>
-[22:55] <mihi> oh. 60. whe have something to celebrate ;)</p>
-[22:55] * jrand0m hands out some beers</p>
-[22:55] *** wiht (anon@anon.iip) has joined channel #iip-dev</p>
-[22:55] * mihi does not like alcohol</p>
-[22:55] <thecrypto> hi</p>
-[22:55] * jrand0m takes back the german beer</p>
-[22:55] <thecrypto> i'm not awake</p>
-[22:55] <mihi> but not asleep either ;)</p>
-[22:55] <jrand0m> heh interesting </p>
-[22:56] <jrand0m> ok, 1.{x,1}) todo before 0.2 </p>
-[22:56] <thecrypto> i just remembered the meeting it today</p>
-[22:56] <thecrypto> i was just discussing wireless cards</p>
-[22:56] <jrand0m> the router is in pretty good shape, and I think 0.2 will be ready for internal dist and testing </p>
-[22:57] *** Signoff: mihi (EOF From client)</p>
-[22:57] <jrand0m> there are three things that need to get implemented first though.  bandwidth limiting, AES on the TCP, and ElG session ack </p>
-[22:57] <jrand0m> the bandwidth limiting will be classless for the moment - just one big honking input limit and output limit. </p>
-[22:58] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev</p>
-[22:58] <jrand0m> the code is committed to tie it in, but the limit is set at infinity atm </p>
-[22:58] <jrand0m> for point 1.2, the TCP transport has key exchange and authentication, but needs encryption </p>
-[22:59] <jrand0m> nop/semi-awake-thecrypto> thoughts on AES for streaming?   </p>
-[22:59] <thecrypto> carefully</p>
-[22:59] <jrand0m> !thwap </p>
-[22:59] <thecrypto> sorry</p>
-[23:00] * CounterRev eats popcorn in the grand stands</p>
-[23:00] <jrand0m> CBC using first 16 bytes of H(sessionKey) work, or should we do something else? </p>
-[23:00] <dm> I can't remember where that originated, exclamation mark before an action.</p>
-[23:00] <thecrypto> i realized when the agenda started being pasted today was tuesday</p>
-[23:00] <jrand0m> dm> some eggdrops use them as command identifiers </p>
-[23:01] <thecrypto> why not use more bits from the DH for that?</p>
-[23:01] <jrand0m> hmm? </p>
-[23:01] <thecrypto> i don't see any problem for that</p>
-[23:01] <thecrypto> for the IV</p>
-[23:01] <jrand0m> more bits of what?  X, Y, x, y? </p>
-[23:02] *** mihi (mihi@anon.iip) has joined channel #iip-dev</p>
-[23:02] <thecrypto> K</p>
-[23:02] <dm> !thwap thecrypto</p>
-[23:02] <thecrypto> what?</p>
-[23:02] <dm> he said X,Y,x or y</p>
-[23:02] <jrand0m> AES 256 only has a 16 byte K </p>
-[23:02] <jrand0m> er, IV </p>
-[23:03] <jrand0m> the session key is 32 bytes </p>
-[23:03] <thecrypto> but you generate many more</p>
-[23:03] <jrand0m> (originally I was stupid and made the IV the first 16 bytes of the key ;) </p>
-[23:03] <thecrypto> so use 48 bytes from the DH</p>
-[23:04] <dm> we all make mistakes.</p>
-[23:04] <jrand0m> hmm ok, pulling more bytes off the modPow will work.  cool.  but why 48?   </p>
-[23:04] <jrand0m> (why not just another 16?) </p>
-[23:05] <thecrypto> i meant 32+16</p>
-[23:05] <jrand0m> ah 'k </p>
-[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 </p>
-[23:06] <jrand0m> (rekey would be just drop the connection and re-DH) </p>
-[23:06] <jrand0m> ok, 1.3) packaging up for 0.2 </p>
-[23:07] <jrand0m> that just means a make / ant script, install / build doc, plus a method for distributing seed routerInfo references  </p>
-[23:07] <jrand0m> (plus, most likely, a set of a few routers for people to connect to) </p>
-[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 </p>
-[23:09] <jrand0m> the one last point holding up 0.2 is the ElG session ack </p>
-[23:09] <dm> can we use 0.2 to talk to each other?</p>
-[23:09] <jrand0m> yes dm </p>
-[23:09] <dm> ok, that's useful.</p>
-[23:10] <mihi> dm: is talking with you really useful? *veg*</p>
-[23:10] <dm> (Killer App: Cyber Sex)</p>
-[23:10] <jrand0m> 0.2 is definitely not even alpha, so it won't be for the faint of heart </p>
-[23:10] <jrand0m> heh </p>
-[23:10] <jrand0m> (but we need to get some testing and experience on some platforms and usage patterns other than my xp box here) </p>
-[23:11] <dm> I'll take care of the marketing for I2P, I have a knack for it.</p>
-[23:11] <jrand0m> lol </p>
-[23:11] <dm> 0.2 code name: CyberSex, features, anonymous CyberSex through text.</p>
-[23:11] <jrand0m> ok, the ElG session ack stuff.   </p>
-[23:11] <wiht> I can test on FreeBSD and Gentoo Linux.</p>
-[23:11] <jrand0m> awesome wiht! </p>
-[23:11] * popopopo can test Debian</p>
-[23:11] <jrand0m> nice </p>
-[23:12] <thecrypto> i can test on mandrake</p>
-[23:12] * dm can test windows XP</p>
-[23:12] <jrand0m> damn we're going to have pretty good coverage :) </p>
-[23:12] * dm stands out from the crowd.</p>
-[23:12] <popopopo> I can test win2k as well I think, although that should be about the same as XP I think</p>
-[23:12] <jrand0m> hopefully </p>
-[23:12] <dm> stick to unix popopopo</p>
-[23:13] * thecrypto plays the trump: I can test win 98 :)</p>
-[23:13] <jrand0m> uuuugh </p>
-[23:13] * dm welcomes his little brother to the crowd.</p>
-[23:13] <popopopo> I have an old DOS disk around here. Will java run on that? :)</p>
-[23:13] <wiht> popopopo: Probably not.</p>
-[23:13] <jrand0m> actually, probably. </p>
-[23:14] <jrand0m> since gcc supports java </p>
-[23:14] <jrand0m> and djgpp runs on dos </p>
-[23:14] <popopopo> I2P on DOS, now that would be an accomplishment</p>
-[23:14] <mihi_backup> popopopo: there is a commercial java version for DOS ;)</p>
-[23:14] * jrand0m is currently hacking around with gjc to see if we can compile to native</p>
-[23:14] <dm> Getting PPP working on DOS would be accomplishment enough.</p>
-[23:14] <mihi> dm: use arachne.</p>
-[23:15] <popopopo> gcj</p>
-[23:15] <mihi> should work via parallel modem.</p>
-[23:15] <nop> oh shit</p>
-[23:15] <nop> it's tuesday</p>
-[23:15] <nop> haha</p>
-[23:15] <jrand0m> ah right popopopo... I always type it wrong </p>
-[23:15] <mihi> oops, serial modem ;)</p>
-[23:15] <jrand0m> wb nop ;) </p>
-[23:15] <thecrypto> nop: you and me both</p>
-[23:15] <nop> haha</p>
-[23:16] <nop> sorry</p>
-[23:16] <nop> my brain is fried this week</p>
-[23:16] <nop> re-cooping</p>
-[23:16] <nop> from this weekend</p>
-[23:16] <thecrypto> nop: you and me both</p>
-[23:16] <jrand0m> ok, the ElG ack stuff. </p>
-[23:16] <jrand0m> (take 4) </p>
-[23:16] * CounterRev could test xp as well "its running.. its running... its stopped"</p>
-[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 </p>
-[23:17] <mihi> and "it's bluescreened, it's autorebooting"</p>
-[23:17] <jrand0m> (these tags are distributed in the streams, and the session keys are distributed in the ElG) </p>
-[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 </p>
-[23:18] <thecrypto> brb, playing magic</p>
-[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 </p>
-[23:19] <jrand0m> there are lots of optimizations and tradeoffs here - one could always ElG and just forget about acks </p>
-[23:19] <jrand0m> (trading cpu for bandwidth) </p>
-[23:19] <jrand0m> or one could always require an ack for the first block, and then AES </p>
-[23:20] <jrand0m> but that breaks if the recipient crashes and loses the session key </p>
-[23:20] * nop is backlogging</p>
-[23:20] <jrand0m> there are a few different patterns that can be used to implement these sessions </p>
-[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 </p>
-[23:22] <dm> like P frames in MPEG!</p>
-[23:22] <jrand0m> 'k, I dont know the MPEG standard really </p>
-[23:22] <dm> sorry, I frames.</p>
-[23:23] <jrand0m> the thing is, these ElG messages are expensive.  ~0.5-1.0 seconds </p>
-[23:23] <jrand0m> (cpu time) </p>
-[23:23] <jrand0m> though, hmm, we could precalculate them </p>
-[23:23] <jrand0m> (if we don't rotate session keys) </p>
-[23:23] <mihi> which cpu? ;)</p>
-[23:23] <dm> sender or reciever cpu time?</p>
-[23:24] <jrand0m> exactly mihi - mine.  p4 1.7g.  so we need some perf tuning on the algorithm </p>
-[23:24] <jrand0m> both dm </p>
-[23:24] <jrand0m> (.5 encrypt, .5 decrypt) </p>
-[23:24] <jrand0m> (hand wavey approx) </p>
-[23:24] * mihi has celeron 700</p>
-[23:24] * dm has PIII 850</p>
-[23:24] <jrand0m> cool.  I'm also getting a sun ultra1 (150Mhz) in a few weeks </p>
-[23:25] <dm> Why you getting a SUN?</p>
-[23:25] <jrand0m> I'm leaving the option open for reevaluating our ElG keysize if we need to </p>
-[23:26] <jrand0m> dm> its free (you can buy a u1 for ~50-100 USD).  I also have a few sparc for various purposes </p>
-[23:26] <dm> sweet.</p>
-[23:27] <jrand0m> ok, unless anyone has any comments on the ElG stuff, on to agenda item 2.x... </p>
-[23:27] <jrand0m> ok, 2.x) apps </p>
-[23:27] <jrand0m> 2.1) ns </p>
-[23:27] <jrand0m> wiht, how goes? </p>
-[23:28] *** Signoff: mihi_backup (Ping timeout)</p>
-[23:30] <wiht> I have not done any coding on the naming server this past week.</p>
-[23:30] <wiht> I should say "of" the naming server.</p>
-[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 </p>
-[23:31] <wiht> But I will be working on it this week, and should have something more to report during the next meeting.</p>
-[23:31] <jrand0m> cool, great </p>
-[23:31] <CounterRev> what is i2p like sans ns?</p>
-[23:32] <jrand0m> icq, I suppose </p>
-[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.</p>
-[23:32] <jrand0m> you need the secret number for contacting someone, but once you have it, you're ok </p>
-[23:33] <mihi> CounterRev: lots of very long destination keys...</p>
-[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 </p>
-[23:33] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev</p>
-[23:33] <jrand0m> ok, 2.2) i2pim... </p>
-[23:33] <jrand0m> thecrypto> you still playing magic?   </p>
-[23:34] <dm> i2pim, is that the name of the IM app?</p>
-[23:34] <jrand0m> yup </p>
-[23:34] <wiht> dm: Yes.</p>
-[23:34] <dm> crap! i2m, Invisible Instant messaging.</p>
-[23:34] <dm> i^2m, just like i^2p!</p>
-[23:34] <jrand0m> sounds like there's a market </p>
-[23:35] <mihi> dm: we had that discussion last meeting...</p>
-[23:35] <dm> fine fine... I'll have to live with it.</p>
-[23:36] <jrand0m> ok, thecrypto is probably still off.  he'll post to the list if there's any news on the i2pim </p>
-[23:36] <jrand0m> (i hope) </p>
-[23:36] <jrand0m> ok, 2.3) i2ptunnel </p>
-[23:36] * jrand0m waves to mihi</p>
-[23:37] <wiht> jrand0m: I see that we have three applications being developed at this time. Have others been proposed?</p>
-[23:37] <mihi> oops...</p>
-[23:37] <mihi> but i have nothing to tell anyway ;)</p>
-[23:37] <mihi> i2p is in cvs; look @ it ;)</p>
-[23:37] <dm> mihi speaks in code.</p>
-[23:38] <jrand0m> heh word.  any updates since you added that config> command? </p>
-[23:38] <dm> or rather, his code speaks for itself.</p>
-[23:38] <mihi> i2ptunnel is in cvs i mean...</p>
-[23:38] * nop proposes ex-lax for i2p</p>
-[23:38] <mihi> jrand0m: nope.</p>
-[23:38] <jrand0m> coo' </p>
-[23:38] <jrand0m> would that be like a LaTeX clone nop? </p>
-[23:39] <jrand0m> wiht> some various discussions, but those three have been the main ones discussed </p>
-[23:39] <jrand0m> (the i2ptunnel enables a shitload of normal apps to operate over it) </p>
-[23:40] <dm> has it been tested with anything?</p>
-[23:40] <mihi> i2ptunnel has been tested extensively with the local router.</p>
-[23:40] <dm> (not locally)</p>
-[23:40] <jrand0m> I've done some web browsing with it, as well as ssh </p>
-[23:40] <jrand0m> (browsing a single site, that is) </p>
-[23:41] * wiht wonders if that website can still track people through cookies.</p>
-[23:41] <dm> great.</p>
-[23:41] <jrand0m> sure wiht, cookies are still sent  </p>
-[23:43] <jrand0m> ok, thats it for apps atm, and on to 3.x) ??? </p>
-[23:43] <jrand0m> any questions, thoughts, concerns, toenail clippers, hedgehogs? </p>
-[23:43] <mihi> a pony? ;)</p>
-[23:43] <jrand0m> yeah, I want a pony! </p>
-[23:43] * dm raises his glass.</p>
-[23:43] <mihi> nop will give you onw...</p>
-[23:43] <dm> TO 0.2!!!</p>
-[23:44] <jrand0m> oh yeah, mihi pointed out that in 17 minutes we miss the deadline I set in my flog a month ago </p>
-[23:44] <jrand0m> to 1.0! </p>
-[23:45] <mihi> 7 minutes ;)</p>
-[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?</p>
-[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 </p>
-[23:45] <jrand0m> yes dm (and files, etc) </p>
-[23:45] <nop> sickening</p>
-[23:45] <jrand0m> there will still be room for performance improvements, of course.  there hasn't been much tuning at all </p>
-[23:45] <nop> sorry, I already spent my budget the next month</p>
-[23:45] <dm> Alrighty, well if that happens, I will applaud.</p>
-[23:45] <nop> pony has to wait</p>
-[23:46] <jrand0m> damnit! </p>
-[23:46] <nop> bought a grand piano instead</p>
-[23:46] <nop> ;)</p>
-[23:46] <jrand0m> heh nice </p>
-[23:47] <mihi> jrand0m: here are some virtual ponies for you: (Link: http://tinyurl.com/p8kx)http://tinyurl.com/p8kx</p>
-[23:47] <dm> estimated latency?</p>
-[23:47] <dm> with network < 30 nodes?</p>
-[23:48] <jrand0m> dm> depends on the sender and receiver's tunnel length </p>
-[23:48] <dm> order of magnitude.</p>
-[23:48] <jrand0m> (e.g. if they have 0 length tunnels, it'll be approx 400ms) </p>
-[23:49] <dm> 0 length tunnels, don't know how I2P works, but 0 length doesn't sound good ;)</p>
-[23:49] <mihi> or (Link: http://tinyurl.com/p8l7)http://tinyurl.com/p8l7</p>
-[23:49] <jrand0m> if they have 2 hop tunnels, the latency should be ~ 1s </p>
-[23:49] <dm> alrighty.</p>
-[23:49] <dm> throughput?</p>
-[23:50] <dm> harder to estimate?</p>
-[23:50] <jrand0m> depends on bandwidth </p>
-[23:51] <dm> Say X is the non I2P bandwidth between 2 nodes, through all the hops I2P uses.</p>
-[23:51] <dm> what is the equation for Y(X) where Y is the throughput of I2P from one node to the other.</p>
-[23:51] <jrand0m> I2P doesn't add a significant overhead to the size of the data </p>
-[23:52] <dm> alrighty.</p>
-[23:52] <dm> wait and see I guess.</p>
-[23:53] <jrand0m> once she's up and running, we'll definitely get some modeling going on </p>
-[23:53] <dm> aye..</p>
-[23:54] * dm raises his glass.</p>
-[23:54] <dm> To women!</p>
-[23:54] <mihi> dm: you forgot to lower it first ;)</p>
-[23:55] <dm> You germans...</p>
-[23:55] <dm> You wacky germans.</p>
-[23:55] <jrand0m> ok, I think thazzabout it </p>
-[23:55] <dm> It's no suprise an american is leading us into the 21st century of anonymous networking.</p>
-[23:55] * mihi /igs dm</p>
-[23:55] <jrand0m> american? </p>
-[23:56] <mihi> jrand0m is spanish i guess.</p>
-[23:56] <dm> I was referring to you!</p>
-[23:56] <mihi> or italian or sth in CET timezone.</p>
-[23:56] <dm> jrand0m, the quiet american.</p>
-[23:56] <wiht> dm: jrand0m seems to be a European.</p>
-[23:56] <dm> !thwap mihi</p>
-[23:57] <dm> !thwap wiht</p>
-[23:57] <dm> jrand0m: your team members don't know you well.</p>
-[23:58] * jrand0m thinks dm has been drinkin a lil too much, but its time for me to do the same. </p>
-[23:58] * jrand0m raises the *baf*...</p>
-[23:58] <dm> nice try jr!</p>
-[23:58] * jrand0m *baf*s the meeting away</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/60.rst b/i2p2www/meetings/60.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/60.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/61.log b/i2p2www/meetings/61.log
index 60699462..59ff0e46 100644
--- a/i2p2www/meetings/61.log
+++ b/i2p2www/meetings/61.log
@@ -1,82 +1,77 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 61{% endblock %}
-{% block content %}<div class="irclog">
-[23:04] <jrand0m> 0.0) welcome </p>
-[23:04] <jrand0m> 1.0) dev status </p>
-[23:04] <jrand0m> 2.0) new server </p>
-[23:04] <jrand0m> 3.0) questions? </p>
-[23:04] <jrand0m> 0.0) welcome to the 61st iip meeting </p>
-[23:04] <jrand0m> hi. </p>
-[23:04] <mihi> hi all</p>
-[23:04] <dm> hi you two ;)</p>
-[23:04] <jrand0m> ok, 1.0) dev status </p>
-[23:05] <jrand0m> we're pretty much ready for 0.2 - which is where people would be able to run i2p.   </p>
-[23:06] <dm> great!</p>
-[23:06] <dm> ETA?</p>
-[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) </p>
-[23:06] <jrand0m> eta: a few days (related point: agenda item 2.0) </p>
-[23:07] <jrand0m> but it will be functional.  I'm able to send messages of 10 bytes as well as 100K in ~10s </p>
-[23:07] <jrand0m> (both on the same CPU, so its cpu contention) </p>
-[23:07] <jrand0m> still some tunnel failback I'm working through, then its time to build the ant scripts, etc </p>
-[23:07] <jrand0m> actually </p>
-[23:08] <jrand0m> a few seconds ago I built everything using Kaffe 1.1.1 on freebsd with not even a warning. </p>
-[23:08] * jrand0m <3 not having to make changes to code</p>
-[23:08] <mihi> but it wasn't working either, was it? ;)</p>
-[23:08] <jrand0m> heh </p>
-[23:09] <jrand0m> no, it works </p>
-[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) </p>
-[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?</p>
-[23:10] <jrand0m> not yet, havent tried i2ptunnel yet either.  but shall tonight </p>
-[23:10] <mihi> try i2ptunnel with a binary connection (like ssh), no text based one.</p>
-[23:11] <jrand0m> 'k </p>
-[23:11] <mihi> what if a node shuts down and does not come up again?</p>
-[23:11] <jrand0m> then communication with it will fail ;) </p>
-[23:12] <jrand0m> (guaranteed delivery now fails correctly and the SDK has been patched to act on that) </p>
-[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. </p>
-[23:13] <jrand0m> 2.0) new server </p>
-[23:13] <jrand0m> we have a new server on a triple homed T3.   </p>
-[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) </p>
-[23:15] *** Signoff: mihi (EOF From client)</p>
-[23:15] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev</p>
-[23:15] <jrand0m> i'll also be tossing on a public isproxy later </p>
-[23:15] <dm> damn, how much is that costing you?</p>
-[23:15] <jrand0m> 65/mo </p>
-[23:15] <jrand0m> 40Gb transfer, 2Gb data </p>
-[23:15] <dm> bandwidth limit?</p>
-[23:15] <dm> cool.</p>
-[23:16] *** mihi_ is now known as mihi</p>
-[23:16] <jrand0m> perhaps that server will become our cvs, but no need to switch right now.   </p>
-[23:16] <jrand0m> ok, 3.0) questions </p>
-[23:17] <jrand0m> [yes, this has been the fastest meeting I've ever seen ;)] </p>
-[23:17] <mihi_backup> do you know anything about naming service progress?</p>
-[23:17] <jrand0m> I hear wiht has committed a few files, but I haven't checked them out yet </p>
-[23:17] <dm> I'd like to offer my (mental) support to all the developers. Stay humble yet determined.</p>
-[23:18] <mihi_backup> they are only dummies afaik.</p>
-[23:18] <jrand0m> clueless wankers, for sure. </p>
-[23:18] <mihi_backup> interfaces to implement against.</p>
-[23:18] <dm> dummies?</p>
-[23:18] <jrand0m> lol </p>
-[23:19] <dm> ah</p>
-[23:19] * jrand0m extends MyParents</p>
-[23:19] <mihi_backup> java does not allow multiple inheritance ;)</p>
-[23:19] <dm> no bastards...</p>
-[23:20] * jrand0m implements MyDad, MyMom // just seems wrong</p>
-[23:20] <mihi_backup> although you do not extend either your mother nor your father (see the liskov (sp?) substitution principle)</p>
-[23:20] * dm implements jrandom'sMom</p>
-[23:20] <dm> ;)</p>
-[23:20] <jrand0m> oh, good point mihi </p>
-[23:20] * dm now implements mihi'smother</p>
-[23:20] <jrand0m> heh </p>
-[23:21] *** Signoff: mihi (Ping timeout)</p>
-[23:21] <mihi_backup> you just need a constructor public Human(Human father, Human mother) throws SameSexException</p>
-[23:22] <dm> nice one</p>
-[23:22] <jrand0m> I think modern science requires a few more constructors </p>
-[23:22] <dm> although it's not public</p>
-[23:22] <dm> it's pubic</p>
-[23:22] *** mihi (mihi@anon.iip) has joined channel #iip-dev</p>
-[23:22] <dm> I crack myself up.</p>
-[23:23] <jrand0m> ok, on that note </p>
-[23:23] <jrand0m> I think we've just gotten away with a 23 minute meeting :) </p>
-[23:23] * jrand0m slips the *baf*er out of my back pocket and *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/61.rst b/i2p2www/meetings/61.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/61.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/62.log b/i2p2www/meetings/62.log
index 99836336..a44b1fc2 100644
--- a/i2p2www/meetings/62.log
+++ b/i2p2www/meetings/62.log
@@ -1,288 +1,284 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 62{% endblock %}
-{% block content %}<div class="irclog">
-[23:01] <jrand0m> agenda </p>
-[23:01] <jrand0m> 0) welcome </p>
-[23:01] <jrand0m> 1) 0.2 status </p>
-[23:01] <jrand0m> 2) www proxy </p>
-[23:01] * dm ponders.</p>
-[23:02] <dm> oh, meeting?</p>
-[23:02] <jrand0m> 3) phttprelay </p>
-[23:02] <jrand0m> 4) i2ptunnel </p>
-[23:02] <jrand0m> 5) installation </p>
-[23:02] <dm> sorry.</p>
-[23:02] <jrand0m> 6) iip feature request </p>
-[23:02] <jrand0m> 7) ??? </p>
-[23:02] <jrand0m> 0) welcome  </p>
-[23:02] <jrand0m> hi. </p>
-[23:02] <jrand0m> meeting 62? is it? </p>
-[23:02] <Dellammo> hi</p>
-[23:02] <jrand0m> (no worry dm, we can forgive you) </p>
-[23:02] <mihi> hi jrand0m</p>
-[23:02] <dm> hi mihi</p>
-[23:02] * mihi thinks so</p>
-[23:03] <jrand0m> 1) 0.2 status </p>
-[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.</p>
-[23:04] <jrand0m> but then we'll be able to run and communicate reliably regardless of NAT, firewall, or HTTP proxy. </p>
-[23:04] * dm has just created I2PSecureRemoteShell 1.0</p>
-[23:04] <dm> cool jr!</p>
-[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) </p>
-[23:05] <jrand0m> the comm across NAT/firewall/HTTP proxy is the PHTTP transport.  its slow, but reliable. </p>
-[23:05] <dm> how does it work? what ports does it use?</p>
-[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 </p>
-[23:06] <jrand0m> there is a LOT that can be tuned and improved on that side of things, which is agenda point 3 :) </p>
-[23:06] <dm> P stands for?</p>
-[23:06] <jrand0m> Polling HTTP </p>
-[23:06] <dm> ok thanks.</p>
-[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 </p>
-[23:07] <jrand0m> (such as not yet handling a lease change during communication) </p>
-[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 </p>
-[23:08] <jrand0m> ok, thats it for 0.2 status </p>
-[23:08] <jrand0m> 2) www proxy. </p>
-[23:09] <jrand0m> moi had a really cool idea for browsing in-i2p www sites. </p>
-[23:09] <jrand0m> wanna explain whats up moi? </p>
-[23:09] * jrand0m puts the spotlight on ya</p>
-*** moi is ~someone@anon.iip (someone) </p>
-*** on channels: #freenet #anonymous #iip #iip-dev </p>
-*** on irc via server anon.iip (Official IIP )</p>
-*** moi has been idle 9 minutes, signed on at Thu Jan 01 01:00:00 1970 </p>
-[23:10] <moi> well</p>
-[23:10] <moi> i am just modifying an HTTP proxy and using mihi's tunnel</p>
-[23:10] <moi> so that you can go to (Link: http://i2p/BASE64KEYHERE)http://i2p/BASE64KEYHERE</p>
-[23:10] <moi> eventually the naming server would be there--</p>
-[23:11] <dm> sweet</p>
-[23:11] *** Signoff: mihi (Ping timeout)</p>
-[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</p>
-[23:11] <Dellammo> so an internal web page or a page outside of i2p?</p>
-[23:11] <dm> i2p resolves to localhost?</p>
-[23:11] <moi> so someone could put up an i2p Google, and go from there.... mabye</p>
-[23:12] <mihi-backup> !thwap dm.</p>
-[23:12] <mihi-backup> a proxy...</p>
-[23:12] <jrand0m> for security, the proxy should 404 all hosts other than (Link: http://i2p/)http://i2p/ </p>
-[23:12] <dm> oops!</p>
-[23:12] <moi> good point</p>
-[23:12] <dm> missed that part</p>
-[23:12] <mihi-backup> although a simple servlet would be nice too</p>
-[23:12] <jrand0m> hmm? </p>
-[23:13] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
-[23:13] <jrand0m> hmm, there may be a problem. </p>
-[23:13] <jrand0m> this would use HTTP 1.0 or 1.1? </p>
-[23:14] <mihi> if the server requests a Host: header?</p>
-[23:14] <jrand0m> [aka, would it have a Host: header?] </p>
-[23:14] <jrand0m> exactly </p>
-[23:14] * mihi wishes for something</p>
-[23:14] <moi> I wonder if we can have the proxy blank that out</p>
-[23:14] <jrand0m> if the server's outbound tunnel is always on the same host, thats fine </p>
-[23:14] <jrand0m> you can set the proxy Host: to 127.0.0.1 </p>
-[23:15] *** dm_backup (~as@anon.iip) has joined channel #iip-dev</p>
-[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 </p>
-[23:15] <jrand0m> right? </p>
-[23:15] *** Signoff: dm (Ping timeout)</p>
-[23:16] * moi hadn't thought that deeply into it yet</p>
-[23:16] <mihi> if you run the server on your own box you can also alias i2p to localhost or sth like that.</p>
-[23:16] <dm_backup> so do people have to run web servers now?</p>
-[23:16] <jrand0m> dm_backup> this is only for people who want to. </p>
-[23:16] *** dm_backup is now known as dm</p>
-[23:16] <Dellammo> like me</p>
-[23:16] <dm> yeah, I mean for this (Link: http://i2p)http://i2p thingie</p>
-[23:17] <mihi> if you want to provide content, yes.</p>
-[23:17] <mihi> but you have to run one to provide content in good ol' www as well.</p>
-[23:18] <Dellammo> why?</p>
-[23:18] <dm> Hmmm, maybe I should build a P2P app for I2P.</p>
-[23:18] <jrand0m> a filesharing app over i2p would rule. </p>
-[23:18] <dm> yes sorry, filesharing.</p>
-[23:19] <moi> I think it would be possible for someone to run an OpenNap server in conjunction with i2ptunnel</p>
-[23:19] <jrand0m> yes. </p>
-[23:19] <jrand0m> (though a native i2p p2p would have better performance) </p>
-[23:19] <mihi> but the downloads will be hard. </p>
-[23:20] <mihi> no way to get to the correct host as all are localhost ;)</p>
-[23:20] <dm> Let's wait till we see PING running over i2ptunnel first.</p>
-[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/' ?</p>
-[23:20] <jrand0m> perhaps just a simple FTP client designed to run over i2p? </p>
-[23:20] <dm> (not ping literally)</p>
-[23:20] <mihi> jrand0m: ftp needs 2 ports...</p>
-[23:20] <jrand0m> designed to run over i2p. </p>
-[23:21] <jrand0m> a general file transfer app, not the FTP protocol, specifically </p>
-[23:21] <mihi> then it's not ftp.</p>
-[23:21] <mihi> ATalk ;)</p>
-[23:21] <jrand0m> (taking advantage of larger message sizes) </p>
-[23:21] <dm> battle of the wise men!</p>
-[23:21] <jrand0m> heh </p>
-[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.</p>
-[23:22] <jrand0m> (kind of) </p>
-[23:22] <jrand0m> you won't want to use an i2ptunnel, specifically.  </p>
-[23:22] <jrand0m> you'll want to use the i2ptunnel protocol, and send messages directly, not via TCP/IP sockets. </p>
-[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? </p>
-*** mihi is mihi@anon.iip (mihi) </p>
-*** on channels: #iip-dev #iip #headlines #german #freenet-opn #freenet #fredisdead #frazaa @#fiw #anonymous </p>
-*** on irc via server anon.iip (Official IIP )</p>
-*** mihi has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 </p>
-*** mihi-backup is ~mihi@anon.iip (mihi) </p>
-*** on channels: #iip-dev </p>
-*** on irc via server anon.iip (Official IIP )</p>
-*** mihi-backup has been idle 12 minutes, signed on at Thu Jan 01 01:00:00 1970 </p>
-[23:25] <mihi> is there any large protocol functionality? I2PTunnelRunner can be used as is.</p>
-[23:25] <mihi> You just have to adjust the client class for your needs.</p>
-[23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket </p>
-[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 </p>
-[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) </p>
-[23:28] <jrand0m> but perhaps switching I2PTunnelRunner to use an InputStream (all it uses is socket.getInputStream) would be easy... </p>
-[23:28] <jrand0m> but then we still need the listen side </p>
-[23:28] *** Signoff: mihi (Ping timeout)</p>
-[23:28] <jrand0m> d'oh </p>
-[23:28] * jrand0m hopes the backup isn't about to ping out...</p>
-[23:28] <dm> backup's gonna die as well ,watch it!</p>
-[23:29] <mihi-backup> ;)</p>
-[23:29] <jrand0m> w00t </p>
-[23:29] <mihi-backup> [23:25] <jrand0m> hmm, not really - i2ptunnelRunner uses a socket</p>
-[23:29] <mihi-backup> [23:25] <mihi> oops, right. and you want to do it completely without sockets?</p>
-[23:29] <mihi-backup> [23:26] <mihi> then there is not much code left from i2ptunnel. most is for handling the sockets.</p>
-[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)</p>
-[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.</p>
-[23:30] <jrand0m> ah 'k.  thanks </p>
-[23:30] <jrand0m> moi> tu sabes? </p>
-[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.</p>
-[23:31] * moi thinks</p>
-[23:31] <dm> toi thinks</p>
-[23:31] <mihi-backup> just forget the tunnelrunner. ;)</p>
-[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()) </p>
-[23:31] *** mihi (mihi@anon.iip) has joined channel #iip-dev</p>
-[23:32] * moi will need to go over this later in detail</p>
-[23:32] <mihi-backup> but that will cause the runner to send a "Connection closed" when the string is sent.</p>
-[23:32] <mihi-backup> as the stream ends.</p>
-[23:32] <jrand0m> right, which is normal HTTP </p>
-[23:33] <mihi-backup> just forget the runner, i said ;)</p>
-[23:33] <jrand0m> 'k </p>
-[23:33] <mihi-backup> jrand0m: nope. the connection is closed when the answer is here, not when the question is out.</p>
-[23:33] <jrand0m> oh yeah </p>
-[23:33] <jrand0m> ;) </p>
-[23:36] <jrand0m> cool moi, we can work through this stuff later on. </p>
-[23:36] <jrand0m> ok, thats agenda item 2).  now for 3) </p>
-[23:36] <moi> ok</p>
-[23:37] <jrand0m> 3) phttprelay </p>
-[23:37] <jrand0m> phttp relay is a set of servlets wrapped in a .war file </p>
-[23:38] <jrand0m> it works out of the box on windows / sun JVM, but I had to hack jetty to run w/ kaffe </p>
-[23:38] <mihi> make .peace not .war</p>
-[23:39] * jrand0m groans</p>
-[23:39] <dm> you can run .war files without a J2ee server?</p>
-[23:39] <dm> good to know.</p>
-[23:39] <jrand0m> .war files run in any servlet container - tomcat, apache w/ mod_jk, jetty, etc </p>
-[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) </p>
-[23:41] <mihi> which ports do you need to redirect if you want to go through a nat without that?</p>
-[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 </p>
-[23:41] <jrand0m> just the I2NP TCP port </p>
-[23:41] <jrand0m> (or the I2NP UDP port) </p>
-[23:41] * mihi does not know if his nat allows udp forwarding</p>
-[23:42] * jrand0m doesn't know if mihi's nat does either</p>
-[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 </p>
-[23:44] <jrand0m> the code is in i2p/code/apps/phttprelay/ for anyone with servlets experience who wants to hack on a small app </p>
-[23:45] <jrand0m> (it should also work transparently with https as well as plain http) </p>
-[23:45] <jrand0m> I'll doc up the PHTTP protocol Real Soon Now.  :) </p>
-[23:45] *** Signoff: mihi (Ping timeout)</p>
-[23:45] <jrand0m> ok, thats it for item 3) phttprelay </p>
-[23:45] <jrand0m> 4) i2ptunnel </p>
-[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) </p>
-[23:46] *** wilde (~anon@anon.iip) has joined channel #iip-dev</p>
-[23:46] <jrand0m> hola wilde </p>
-[23:47] <jrand0m> ok.  that said, item 5 :) </p>
-[23:47] <jrand0m> 5) installation </p>
-[23:48] <jrand0m> to get 0.2 out the door, and beyond, I'm thinking of some ant scripts. </p>
-[23:48] <jrand0m> or should we use another open source installation system? </p>
-[23:48] <jrand0m> anyone have any experiences / thoughts on this? </p>
-[23:49] <Dellammo> hmm</p>
-[23:50] <jrand0m> ant has the benefit of being unified with the build system, platform independent, and has headless operation. </p>
-[23:50] <wilde> hey</p>
-[23:50] <jrand0m> but it requires ant (which requires java).  and it doesn't have a GUI </p>
-[23:51] <Dellammo> i can think of many install programs for windows... i dont know how many are gpl though</p>
-[23:51] <jrand0m> yeah, I have a licensed InstallAnywhere Enterprise installation, but its bad for open source </p>
-[23:51] <jrand0m> NSIS is open source, but has its nuances. </p>
-[23:51] <dm> stupid question: is ant included in java?</p>
-[23:52] <jrand0m> nope. </p>
-[23:52] <jrand0m> oh, though we COULD distribute a GCJ'ed ant </p>
-[23:52] <dm> alright, must have come with eclipse then.</p>
-[23:52] <jrand0m> (compiled to native code) </p>
-[23:52] <jrand0m> definitely dm. </p>
-[23:52] <jrand0m> apache makes ant (ant.apache.org) and its apache licensed. </p>
-[23:52] <jrand0m> oh, yuck. </p>
-[23:52] * jrand0m just read the sentence I typed)</p>
-[23:53] <jrand0m> gpl is not apl friendly, according to the FSF </p>
-[23:53] <jrand0m> we probably can't distribute ant. </p>
-[23:53] <dm> can't we just a script? what needs to be done for it to be installed?</p>
-[23:53] <jrand0m> but we can use it. </p>
-[23:53] <jrand0m> not much at all.  a script is fine. </p>
-[23:53] <jrand0m> but do we want a .bat and a .sh, etc. </p>
-[23:54] *** shardy (~shardy@anon.iip) has joined channel #iip-dev</p>
-[23:54] <dm> what does an installation entail, a couple of questions?</p>
-[23:54] <jrand0m> writing a java installer to do the install platform independent is overkill, so we should ideally use an existing install framework </p>
-[23:54] <jrand0m> yeah, a few questions </p>
-[23:54] <jrand0m> the installation targets I forsee: </p>
-[23:54] <Dellammo> do we get a flashy new logo? whos working on that?</p>
-[23:54] <jrand0m> install-router </p>
-[23:55] <jrand0m> install-www-tunnel, install-www-proxy, install-sdk, install-cvs-tunnel, update-seednodes </p>
-[23:55] <moi> why not use InstallAnywhere? if the code is open that is what matters</p>
-[23:55] * jrand0m thinks YOU are Dellammo :)</p>
-[23:55] <jrand0m> InstallAnywhere isn't open source. </p>
-[23:55] * Dellammo gets to work</p>
-[23:56] <dm> script would probably be enough at this point, but I guess might as well think ahead.</p>
-[23:56] <jrand0m> (its about 4k euro / seat) </p>
-[23:56] <jrand0m> right.  so for tomorrow, I'll probably just write ant scripts, but we need to look into a system </p>
-[23:56] *** Signoff: wilde (Ping timeout)</p>
-[23:56] <jrand0m> so if anyone can help out with that, it'd be appreciated :) </p>
-[23:57] <dm> ah okay, I was thinking shell scripts.</p>
-[23:57] <moi> Some of the package managers could do that on the Linux installs</p>
-[23:57] *** wilde (~anon@anon.iip) has joined channel #iip-dev</p>
-[23:57] <jrand0m> managing different installers for different platforms is a PITA </p>
-[23:59] <dm> java installer? Why is it a PITA?</p>
-[23:59] <jrand0m> a java installer would be great </p>
-[23:59] <mihi-backup> pain in the a**e</p>
-[23:59] <mihi-backup> oops, sorry...</p>
-[23:59] <dm> system.out.println("Please enter where you would like to install I2P") ;)</p>
-[23:59] <mihi-backup> s/tln/t; s/P"/P: "/</p>
-[23:59] <mihi-backup> s/sys/Sys/</p>
-[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! </p>
-[00:00] <dm> mihi's having an epileptic seizure.</p>
-[00:00] * mihi-backup slaps dm around a bit with a large trout</p>
-[00:00] <dm> Tell you what...</p>
-[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.</p>
-[00:01] <mihi-backup> dm: read the ant script ;)</p>
-[00:01] <jrand0m> word dm.  once I get the ant thing working I'll doc 'er up for you </p>
-[00:01] <dm> fair enough, we'll see if I can figure out the ant script once it's out.</p>
-[00:02] *** Signoff: wilde (Ping timeout)</p>
-[00:02] <Dellammo> jrand0m, i2p I2P i^2p or I^2P ?</p>
-[00:02] * jrand0m has some scribbles with a capital I, 2 and a capital P all superimposed on each other...</p>
-[00:03] <Dellammo> hmm</p>
-[00:03] *** wilde (~anon@anon.iip) has joined channel #iip-dev</p>
-[00:03] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
-[00:03] <jrand0m> ok, thats 5) installation </p>
-[00:03] <jrand0m> 6) iip feature request </p>
-[00:04] <jrand0m> someone came on here with a request for auto-nicktheifing </p>
-[00:04] <jrand0m> basically, if someone has registered a nick, no one can stay as that nick unless they're identified </p>
-[00:04] <jrand0m> nop or anyone who has done iip dev - thoughts? </p>
-[00:04] * jrand0m thinks it'd be a great feature to have</p>
-[00:05] * Dellammo draws an illuminati eye with a no 'as in no smoking sign' over it</p>
-[00:05] <jrand0m> heh </p>
-[00:05] <dm> Maybe I'll make an I2P logo as well... for the gui part of my installer ;)</p>
-[00:05] *** Signoff: wilde ((null))</p>
-[00:05] <Dellammo> lets all make them, so we dont get stuck with a sucky logo</p>
-[00:05] <mihi> jrand0m: ask mids - he maintains trent.</p>
-[00:06] <mihi> the trent source is in cvs btw</p>
-[00:06] <Dellammo> the logo is the most important part of any activity</p>
-[00:06] <jrand0m> definitely Dellammo. </p>
-[00:06] * dm dusts off Corel Draw...</p>
-[00:06] <dm> man I love Corel Draw.</p>
-[00:07] <jrand0m> ok, thats it for 6) </p>
-[00:07] <jrand0m> 7) ??? </p>
-[00:07] <jrand0m> any questions / thoughts / frisbees/ toenails? </p>
-[00:07] <dm> Thought: hope it works.</p>
-[00:08] <jrand0m> heh </p>
-[00:08] * jrand0m too.</p>
-[00:09] <mihi> jrand0m: keep the good work!</p>
-[00:09] <dm> yes, keep it up.</p>
-[00:09] <jrand0m> good work?  you obviously haven't seen the code ;) </p>
-[00:09] <dm> Love your code, except for the bliding underscores.</p>
-[00:09] <dm> blinding...bleeding..etc..</p>
-[00:09] <jrand0m> heh, instance variables have _, so we don't ever need to do this.var = var; </p>
-[00:10] <jrand0m> ok... 68 minutes... if I can drag this out for one more minute... </p>
-[00:10] <jrand0m> w00t </p>
-[00:10] * jrand0m *baf*s the meeting closed.</p>
-</div>{% endblock %}
\ No newline at end of file
+[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/62.rst b/i2p2www/meetings/62.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/62.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/63.log b/i2p2www/meetings/63.log
index 582dbbcd..e48fc588 100644
--- a/i2p2www/meetings/63.log
+++ b/i2p2www/meetings/63.log
@@ -1,183 +1,177 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 63{% endblock %}
-{% block content %}<h3>Tuesday, October 28, 2003 21:02:50 UTC</h3>
-<div class="irclog">
-[22:59] <dm> so when IS this meeting?</p>
-[23:00] <jrand0m> now. </p>
-[23:00] <jrand0m> 0) welcome [63] </p>
-[23:00] <jrand0m> 1) roadmap: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap </p>
-[23:00] <jrand0m> 2) 0.2 todo: </p>
-[23:00] <jrand0m> - long lasting comm testing </p>
-[23:00] <jrand0m> - lease rebuilding bugs </p>
-[23:00] <jrand0m> 3) prng (yay) </p>
-[23:00] <jrand0m> 4) apps / questions / etc </p>
-[23:00] <jrand0m> 0) hi </p>
-[23:00] <jrand0m> sorry for being stupid and forgetting about daylight savings time </p>
-[23:00] <jrand0m> welcome to meeting #63 </p>
-[23:01] *** darl_mcbride has left #iip-dev</p>
-[23:01] <jrand0m> 1) roadmap </p>
-[23:01] <jrand0m> the roadmap is at the above url and will be updated whenever necessary. </p>
-[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 </p>
-[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" :) </p>
-[23:03] <jrand0m> 0.2 itself will allow actual useful functionality </p>
-[23:03] *** Signoff: thecrypto (Ping timeout)</p>
-[23:03] <dm> that's good news.</p>
-[23:03] <jrand0m> ok, item 2) 0.2 todo </p>
-[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 </p>
-[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. </p>
-[23:05] <jrand0m> (the problem has been that after a few hours of use, communication with a router or a destination fails) </p>
-[23:05] <dm> what kind of testing rig are you using? Is it all local at this point?</p>
-[23:05] <jrand0m> three routers local, three routers remote </p>
-[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?</p>
-[23:05] <jrand0m> yes </p>
-[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. </p>
-[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 </p>
-[23:07] <jrand0m> however, running three routers plus two active destinations locally is, well, a CPU beast. </p>
-[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) </p>
-[23:09] <jrand0m> ok, thats it for 0.2 todo </p>
-[23:09] <dm> for your testing purposes?</p>
-[23:09] <jrand0m> yeah basically </p>
-[23:09] <jrand0m> (and/or for anyone else who is doing their own testing to add new features / etc ;) </p>
-[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) </p>
-[23:10] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev</p>
-[23:10] <jrand0m> but i think thats a Bad Idea. </p>
-[23:11] <jrand0m> this feature will most certainly get pulled once the AES+SessionTag stuff gets worked out </p>
-[23:11] <jrand0m> ok, 3) prng </p>
-[23:11] <sisr> Are there any suggested minimum CPU and RAM requirements?</p>
-[23:12] <sisr> sorry</p>
-[23:12] <jrand0m> hmm, RAM is minimal (sun's JVM takes 7-10Mb, kaffe 16-22Mb) </p>
-[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 ;) </p>
-[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 </p>
-[23:14] <thecrypto> i might be a little more active if you want me to say somethingh</p>
-[23:14] <dm> alright, say something.</p>
-[23:15] <jrand0m> hiya thecrypto :) </p>
-[23:15] <sisr> Why would anyone run more than one router on the same computer?</p>
-[23:15] <jrand0m> sisr> only a developer would. </p>
-[23:16] <sisr> Ok, so the CPU should not be too bad and we can run some tests over the weeks</p>
-[23:16] <jrand0m> word </p>
-[23:17] <jrand0m> ok, the prng stuff turned out to be a bug in kaffe, which is now fixed.   </p>
-[23:17] <jrand0m> with that, we don't have any hard need to get a yarrow impl, as they use sha1prng </p>
-[23:18] <jrand0m> (but it'd be nice, whenever we get it) </p>
-[23:18] <jrand0m> ok, 4) apps / questions / etc </p>
-[23:18] <jrand0m> I don't have anything else, so... hi :) </p>
-[23:19] <jrand0m> any questions / thoughts / comments on anything else? </p>
-[23:19] <sisr> How is the naming server? I have not seen co for a long time</p>
-[23:19] *** co (anon@anon.iip) has joined channel #iip-dev</p>
-[23:19] <jrand0m> speaking of the devil </p>
-[23:19] <jrand0m> hi co </p>
-[23:19] <sisr> haha</p>
-[23:19] <co> Hello.</p>
-[23:20] <jrand0m> we're at that point where there's not really anything left on the agenda 'cept for questions </p>
-[23:20] <jrand0m> [23:19] <sisr> How is the naming server? I have not seen co for a long time </p>
-[23:20] <jrand0m> [23:19] *** co (anon@anon.iip) has joined channel #iip-dev </p>
-[23:20] <jrand0m> and that happened :) </p>
-[23:20] *** Signoff: godmode0 (EOF From client)</p>
-[23:21] <co> There has been no progress on it. I wrote just a small part of the client, and none of the server.</p>
-[23:22] <jrand0m> coo' </p>
-[23:22] * dm points the shame-stick at co.</p>
-[23:22] <sisr> I believe the HTTP i2p tunnel is working good now</p>
-[23:22] <sisr> i have adapt mihis excellent httpclient so that you type it into your proxy setting</p>
-[23:23] <jrand0m> aweseme! </p>
-[23:23] <sisr> it also does some simple filter of non i2p site</p>
-[23:23] <sisr> i think jrand0m has commit this already, yes?</p>
-[23:23] <jrand0m> do we know what browsers it works with?  I know moz... </p>
-[23:23] <jrand0m> yeah, I think I committed that stuff.. lemmie check </p>
-[23:23] * co is appropriately ashamed.</p>
-[23:23] <sisr> It working with Mozilla and the Konqueror</p>
-[23:24] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev</p>
-[23:24] <jrand0m> dont worry co, I'm already 2 months behind schedule </p>
-[23:24] <sisr> I will try to get the mihi I2P tunnel to work with E-mail server this week</p>
-[23:24] <sisr> Also many wiki pages have updated</p>
-[23:24] <jrand0m> oh yeah!  thanks for that </p>
-[23:25] * jrand0m actually added a caveat to one of the FAQs this afternoon :)</p>
-[23:25] * dm decides to concentrate his awesome analytical brainpower towards determining where sisr is from.</p>
-[23:25] <dm> "Also many wiki pages have updated"</p>
-[23:25] <sisr> Ok go ahead</p>
-[23:25] <dm> mmmm.....MMmmmm.....mmmmmm...</p>
-[23:26] <dm> ah, another clue?</p>
-[23:26] <sisr> But I can not tell you if you are correct</p>
-[23:26] <dm> "..... has commit this already, yes?"</p>
-[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?</p>
-[23:27] <jrand0m> I've found that what I want and what happens isn't always the same thing </p>
-[23:27] <co> I mean release them together.</p>
-[23:27] <sisr> I have a question after co</p>
-[23:27] <jrand0m> the current plan is up at (Link: http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap)http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap </p>
-[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. </p>
-[23:28] <jrand0m> (the installer right now bundles the router, sdk, phttprelay, atalk, and i2ptunnel) </p>
-[23:29] *** Signoff: dm (Ping timeout)</p>
-[23:29] <jrand0m> 'sup sisr? </p>
-[23:29] <co> That page is quite helpful. Thank you.</p>
-[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</p>
-[23:30] <jrand0m> absolutely. </p>
-[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</p>
-[23:31] <sisr> Is it better to try and make I2P web server program, I2P web browser    everything special for the I2P ?</p>
-[23:31] *** dm (~as@anon.iip) has joined channel #iip-dev</p>
-[23:32] <jrand0m> personally, I'd love if the former could happen.  however, there will be performance gains by designing apps native to i2p </p>
-[23:32] <mihi> unix principle: one job, one tool. so don't write new browsers.</p>
-[23:32] <jrand0m> right </p>
-[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</p>
-[23:32] <dm> one job, one tool? silly principle.</p>
-[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</p>
-[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) </p>
-[23:34] <sisr> Haha, ok sisr has a very old computer</p>
-[23:34] <sisr> It seem real slow to me because of this</p>
-[23:34] <dm> what was latency like on the first few real tests? Just out of curiosity.</p>
-[23:35] <jrand0m> I can pull news.google.com with all images in ~ 30-60 seconds </p>
-[23:35] <dm> k</p>
-[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?</p>
-[23:36] <co> And how much time does it take without the tunnel?</p>
-[23:36] <jrand0m> sisr> if I worked on it fulltime, I'd suspect ~ 1 month to get a DHT on top of i2p </p>
-[23:37] <jrand0m> co> ~ 10-15 seconds </p>
-[23:38] <co> So i2ptunnel is 3 times as slow.</p>
-[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 </p>
-[23:39] *** Signoff: thecrypto (Ping timeout)</p>
-[23:39] <co> For you, at least.</p>
-[23:39] <jrand0m> the overhead is in the message wrapping </p>
-[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</p>
-[23:40] <sisr> Like checkbox to set up I2P Tunnel web server with port, and Checkbox for E-mail server, so it real simple</p>
-[23:40] <jrand0m> sisr> I personally really really like its interface atm :)   </p>
-[23:40] <jrand0m> oh, definnitely.  actually </p>
-[23:40] * sisr has never seen the interface but imagines it like the textbox</p>
-[23:40] <sisr> Maybe someone can screencap the I2P tunnel for tutorial</p>
-[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 ...' ) </p>
-[23:42] <sisr> What should we be working on for I2P now</p>
-[23:42] <jrand0m> thats a big question.  short answer is "whatever you can" </p>
-[23:43] <jrand0m> if someone were to go ahead and update the installer to build those .sh and .bat scripts, that would rule </p>
-[23:43] <jrand0m> if anyone has time to work on some of the things on the i2proadmap, that would also rule :) </p>
-[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) </p>
-[23:44] <sisr> How will the Installer be? Install shield or Java?</p>
-[23:44] <jrand0m> the current installer is a single "install.jar" which prompts the user through a few questions </p>
-[23:45] <jrand0m> its a really crappy installer </p>
-[23:45] <jrand0m> but its as platform independent as it gets </p>
-[23:48] <jrand0m> ok cool, the routers are still working, I think this bugfix may have done it. </p>
-[23:48] <jrand0m> oh yeah.  </p>
-[23:48] <jrand0m> the mailing list will be back sometime </p>
-[23:48] <jrand0m> if it isn't back by the time 0.2 is ready, I'll create a new mailing list </p>
-[23:49] <co> I have one other question.</p>
-[23:49] <jrand0m> fire away </p>
-[23:50] <co> Is there a list available of I2P nodes running right now?</p>
-[23:50] <jrand0m> nope. </p>
-[23:50] <jrand0m> no public i2p nodes are open </p>
-[23:50] <co> I see.</p>
-[23:50] <jrand0m> however, one of them will make its list of peers available via http once 0.2 is released </p>
-[23:50] <jrand0m> (and the URL to that list will be in the installer) </p>
-[23:50] <jrand0m> s/will be/is/ </p>
-[23:52] <mihi> it's in my bookmarks as well...</p>
-[23:52] <jrand0m> heh bastard </p>
-[23:52] <mihi> btw: size=777 is 111 bytes too large ;)</p>
-[23:53] <jrand0m> rofl </p>
-[23:53] <jrand0m> I totally didn't notice that. </p>
-[23:53] <jrand0m> they used to be 384 </p>
-[23:53] <jrand0m> but then I added some router sw version info to the routerInfo </p>
-[23:53] <sisr> I think nop can use the I2P tunnel to set up a test IRC server with the 0.2 router?</p>
-[23:54] <jrand0m> that'd be really cool </p>
-[23:54] <sisr> I wonder how the latency comparing to this IIP if nop does that</p>
-[23:54] <jrand0m> though we wouldn't be able to dcc </p>
-[23:54] <jrand0m> i2p would be a lot higher latency </p>
-[23:54] <jrand0m> (as each send would be a few seconds, since we don't have AES+SessionTag yet) </p>
-[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 </p>
-[23:57] <dm> k, night</p>
-[23:57] *** dm has left #iip-dev</p>
-[23:57] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/63.rst b/i2p2www/meetings/63.rst
new file mode 100644
index 00000000..14a774f7
--- /dev/null
+++ b/i2p2www/meetings/63.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, October 28, 2003 @ 21:02 UTC
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/64.log b/i2p2www/meetings/64.log
index f9ac4807..fa0f8f87 100644
--- a/i2p2www/meetings/64.log
+++ b/i2p2www/meetings/64.log
@@ -1,196 +1,189 @@
-{% 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)</p>
-<h3>Tuesday, November 11, 2003 21:02:50 UTC</h3>
-<div class="irclog">
-[22:02] <jrand0m> agenda </p>
-[22:02] <jrand0m> 0) welcome </p>
-[22:02] <jrand0m> 1) i2p router  </p>
-[22:02] <jrand0m> 1.1) status </p>
-[22:02] <jrand0m> 1.2) roadmap changes </p>
-[22:02] <jrand0m> 1.3) open subprojects </p>
-[22:02] <jrand0m> 2) native modPow </p>
-[22:03] <jrand0m> 2) gui installer </p>
-[22:03] <jrand0m> 3) IM </p>
-[22:03] <jrand0m> 4) naming service </p>
-[22:03] <MrEcho> i saw that .c code</p>
-[22:03] <jrand0m> 5) licensing </p>
-[22:03] <jrand0m> 6) other? </p>
-[22:03] <jrand0m> 0) welcome </p>
-[22:03] <jrand0m> hi. </p>
-[22:03] <nop> hi</p>
-[22:03] <jrand0m> meeting 2^6 </p>
-[22:04] <jrand0m> got any agenda items to add to there nop? </p>
-[22:04] <jrand0m> ok, 1.1) router status </p>
-[22:04] <jrand0m> we're 0.2.0.3 and last I heard, its functional </p>
-[22:04] <MrEcho> > 0.2.0.3</p>
-[22:04] <MrEcho> right?</p>
-[22:05] <MrEcho> im running it .. seems fine</p>
-[22:05] <nop> no</p>
-[22:05] <jrand0m> there have been minor commits after the 0.2.0.3 release, nothing release worthy </p>
-[22:05] <nop> I am jus trying to catch up</p>
-[22:05] <jrand0m> coo' </p>
-[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 </p>
-[22:06] <jrand0m> (aka so people can run webservers / etc and it won't eat up their CPU) </p>
-[22:06] <jrand0m> specifically (moving to agenda 1.2): http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap </p>
-[22:06] <MrEcho> what ive noticed is that most routers use: TransportStyle: PHTTP   </p>
-[22:07] <MrEcho> does it auto go to phttp or does it even try tcp first</p>
-[22:07] <jrand0m> hmm, most routers should support PHTTP, and if they can accept incomming connections, should support TCP as well </p>
-[22:07] <jrand0m> if at all possible it uses TCP </p>
-[22:07] <jrand0m> PHTTP is weighted about 1000 times more expensive than TCP </p>
-[22:08] <jrand0m> (see GetBidsJob, which asks each transport how much it thinks it'd cost to send a message to a peer) </p>
-[22:08] <jrand0m> (and see TCPTransport.getBid and PHTTPTransport.getBid for the values used) </p>
-[22:08] <MrEcho> ok</p>
-[22:08] <jrand0m> are you using PHTTP often to send and receive messages? </p>
-[22:09] <jrand0m> (that might be a sign that your TCP listener isn't reachable) </p>
-[22:09] <MrEcho> i didnt put in the urls on my side</p>
-[22:09] <jrand0m> ah 'k.  </p>
-[22:09] <MrEcho> ohh it is</p>
-[22:10] <jrand0m> ok, yeah, my routers have open TCP connections to you </p>
-[22:10] <dm> how hospitable of them.</p>
-[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</p>
-[22:11] <MrEcho> is there a timeout thing if it doesnt connect to the tcp it goes phttp? and whatz the timing on it</p>
-[22:11] <jrand0m> but anyway, the big change to the roadmap is that 0.2.1 will implement the AES+SessionTag stuff </p>
-[22:11] <MrEcho> or could we have that in a setting?</p>
-[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 </p>
-[22:12] <MrEcho> so no retrys</p>
-[22:12] <jrand0m> phttp has a 30 sec timeout iirc </p>
-[22:12] <jrand0m> no need to retry.  you either have an open TCP connection and can send the data or you don't :) </p>
-[22:12] <MrEcho> lol ok</p>
-[22:13] <MrEcho> will it try tcp everytime after that or skip that and just go phttp for the next connection?</p>
-[22:13] <jrand0m> it'll try tcp each time at the moment. </p>
-[22:13] <jrand0m> the transports don't keep histories yet </p>
-[22:13] <MrEcho> ok cool</p>
-[22:14] <jrand0m> (but if a peer fails 4 times they get shitlisted for 8 minutes) </p>
-[22:14] <MrEcho> well once the otherside gets the phttp msg it should connect to the router that sent the msg via tcp right?</p>
-[22:14] <jrand0m> correct.  once any tcp connection is established, it can use it. </p>
-[22:14] <jrand0m> (but if both peers only have phttp, they'll obviously only use phttp) </p>
-[22:15] <MrEcho> that would mean that it couldnt est. a tcp connection to anything</p>
-[22:15] <MrEcho> .. but ya</p>
-[22:16] <MrEcho> i wish there was a way around that</p>
-[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. </p>
-[22:16] <jrand0m> (and then they can send back messages along that TCP connection instead of sending me slower PHTTP messages) </p>
-[22:17] <jrand0m> or is that not what you mean? </p>
-[22:17] <MrEcho> ya i got mixed up</p>
-[22:17] <jrand0m> word, np </p>
-[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) </p>
-[22:18] <jrand0m> ok, 1.3) open subprojects </p>
-[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 </p>
-[22:19] <jrand0m> so if you're bored and looking for code projects... :) </p>
-[22:19] <MrEcho> gezz</p>
-[22:20] <MrEcho> already got 2</p>
-[22:20] <dish> You have a palmpilot this is elite</p>
-[22:20] <MrEcho> mine died</p>
-[22:20] <jrand0m> mihi> there's a line item in there wrt the I2PTunnel describing a thought I had a lil while ago </p>
-[22:20] <MrEcho> dont know whatz up wit hit</p>
-[22:21] <jrand0m> yeah, I used to have palms but just recently had this one donated to the cause ;) </p>
-[22:21] <dish> Could there be an agenda item at the meeting to discuss when the last time userX typed something was</p>
-[22:21] <MrEcho> damm thing doesnt even turn on anymore</p>
-[22:21] <MrEcho> lol</p>
-[22:22] <jrand0m> I don't think UserX has said anything in 4 or 5 months ;) </p>
-[22:22] <MrEcho> is that a bot or something?</p>
-[22:22] <dish> What did they say 5 months ago?</p>
-[22:22] <MrEcho> i bet its a bitchx running on some box he use to have access to .. and forgot about it</p>
-[22:22] <jrand0m> that they'd get back with comments about the anonCommFramework (i2p's old name) next week ;) </p>
-[22:23] <dish> haha</p>
-[22:23] <jrand0m> but I suppose he's busy.  so is life </p>
-[22:23] <jrand0m> ok, 2) native modPow </p>
-[22:23] <MrEcho> i saw that c code</p>
-[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 </p>
-[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  </p>
+[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)</p>
+(insert major iip breakage here)
 
-[22:38] <MrEcho> last thing i saw was: [13:25] <jrand0m> ok, 2) native modPow</p>
-[22:38] <jrand0m> hi MrEcho </p>
-[22:38] <jrand0m> yeah, looks like a main proxy crashed </p>
-[22:39] <jrand0m> I'm giving it another 2 mins before restarting </p>
-[22:39] <MrEcho> k</p>
-[22:39] <MrEcho> for $25 1 time i can get full on java on thenidus.net ... one of my sites</p>
-[22:40] <jrand0m> $25?  they charge you to install software? </p>
-[22:40] <MrEcho> no idea really .. its a package</p>
-[22:40] <MrEcho> talking to my friend right now</p>
-[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 :) </p>
-[22:41] <dm> package of what?</p>
-[22:41] <MrEcho> java - jsp</p>
-[22:41] <jrand0m> ok, resending what I sent before: </p>
-[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  </p>
-[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) </p>
-[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. </p>
-[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) </p>
-[22:43] <dm> frazaa?</p>
-[22:43] <jrand0m> heh, in a way ;) </p>
-[22:44] <jrand0m> ok, 3) gui installer </p>
-[22:44] <jrand0m> MrEcho> hi </p>
-[22:44] <MrEcho> :)</p>
-[22:44] <MrEcho> hehe</p>
-[22:44] <MrEcho> its comming alog</p>
-[22:44] <jrand0m> cool </p>
-[22:44] <MrEcho> nothing fancy</p>
-[22:45] <MrEcho> ive got some really cool ideas to make it really fancy .. but thatz a way off</p>
-[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? </p>
-[22:45] <jrand0m> word </p>
-[22:46] <jrand0m> yeah, we want the installer to be as simple as possible - what fancy stuff were you thinking of? </p>
-[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</p>
-[22:46] <MrEcho> how are we going to make it to were you dbl click the jar file and it loads the gui</p>
-[22:47] <jrand0m> install.jar <-- nongui,  installgui.jar <-- gui </p>
-[22:47] <jrand0m> seperate code, seperate packages </p>
-[22:47] <MrEcho> fancy as in things you might not notice .. but its goingto be nice and clean</p>
-[22:47] <jrand0m> cool </p>
-[22:47] <MrEcho> aww ok</p>
-[22:48] <jrand0m> (or install <-- gui installcli <-- cli.  we'll see how things progress) </p>
-[22:49] <jrand0m> anything else on the gui, or do we jump off to item 4)? </p>
-[22:49] <jrand0m> (any time frame you're thinking?  no pressure, just wondering) </p>
-[22:51] <MrEcho> no idea right now</p>
-[22:51] <jrand0m> coo' </p>
-[22:51] <jrand0m> ok, 4) IM </p>
-[22:51] <jrand0m> thecrypto aint here, so..... </p>
-[22:51] <jrand0m> 5) naming service </p>
-[22:51] <jrand0m> wiht isn't here either... </p>
-[22:51] <jrand0m> ping </p>
-[22:52] <dish> you're off on the number agenda count</p>
-[22:52] <dish> 3) IM</p>
-[22:52] <jrand0m> yeah, I used to have 2 agenda item 2's </p>
-[22:52] <dish> 4) Naming</p>
-[22:52] <dish> ;)</p>
-[22:52] <jrand0m> (native modPow and gui installer) </p>
-[22:52] <jrand0m> see, we're dynamic and stuff </p>
-[22:59] <jrand0m> ok, for the logs I suppose I'll continue </p>
-[22:59] <jrand0m> 6) licensing </p>
-[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. </p>
-[23:00] * dish look at mihi i2p tunnel part of code</p>
-[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 </p>
-[23:01] <jrand0m> (but i2ptunnel is essentially a third party app and can license how it wants) </p>
-[23:02] <jrand0m> (though since the i2p sdk is gpl, he's been forced to be gpl) </p>
-[23:02] <MrEcho> damm about time</p>
-[23:02] <jrand0m> I don't know.  licensing is not my forte, but I'm inclined at least to move to lgpl </p>
-[23:02] * dish release the 10-20 line of change to I2P HTTP Client mihi code as whatever mihi license is</p>
-[23:03] <jrand0m> hehe :) </p>
-[23:06] <jrand0m> anyway, 7) other?   </p>
-[23:07] <jrand0m> anyone have any questions / concerns / ideas wrt i2p? </p>
-[23:07] <dish> Let me ask</p>
-[23:07] <dish> Does the I2P have any group name feature?</p>
-[23:07] <jrand0m> group name feature? </p>
-[23:07] <dm> team discovery channel!</p>
-[23:07] <MrEcho> lol</p>
-[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</p>
-[23:08] <MrEcho> hes thinking of waste</p>
-[23:08] <jrand0m> ah </p>
-[23:08] <dish> I don't know why you would want that, but I am just ask in case</p>
-[23:08] <jrand0m> yes, early on in the network design I was playing with that </p>
-[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  </p>
-[23:09] <dish> Or is that a bad idea because it is better to keep it one large network</p>
-[23:09] <dm> i2pisdead</p>
-[23:09] <jrand0m> heh dm </p>
-[23:10] <nop> shad up</p>
-[23:10] <jrand0m> no dish, its a good idea </p>
-[23:10] <dm> nop: tough guy?</p>
-[23:10] <jrand0m> its essentially what release 0.2.3 is -- restricted routes </p>
-[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) </p>
-[23:15] <jrand0m> ok, anything else? </p>
-[23:15] <nop> nah, I'm just being funny</p>
-[23:18] <dm> funny guy?</p>
-[23:20] <jrand0m> ok, well, /interesting/ meeting, with a few iip crashes in the middle ;) </p>
-[23:21] * jrand0m *baf*s the meeting to a close</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/64.rst b/i2p2www/meetings/64.rst
new file mode 100644
index 00000000..68a41ba3
--- /dev/null
+++ b/i2p2www/meetings/64.rst
@@ -0,0 +1,11 @@
+I2P dev meeting, November 11, 2003 @ 21:02 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
+(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/65.log b/i2p2www/meetings/65.log
index 5ee5fe8d..78f9dcd3 100644
--- a/i2p2www/meetings/65.log
+++ b/i2p2www/meetings/65.log
@@ -1,623 +1,617 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 65{% endblock %}
-{% block content %}<h3>Tuesday, November 18, 2003 21:02:50 UTC</h3>
-<div class="irclog">
-[22:02] <jrand0m> agenda: </p>
-[22:02] <jrand0m> 0) welcome </p>
-[22:02] <jrand0m> 1) i2p dev status </p>
-[22:02] <jrand0m>  - 0.2.1.1 is out (peer and tunnel updating and testing, tuning enhancements, tunnel throttling, a DoS defense)  </p>
-[22:02] <jrand0m>  - don't use bw limiting (still some debugging) </p>
-[22:02] <jrand0m>  - keep your clocks generally correct (30 minute fudge factor) [used for lease expirations and garlics] </p>
-[22:02] <jrand0m> 2) kademlia, 0.3, and idn </p>
-[22:02] <jrand0m> 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? </p>
-[22:02] <jrand0m> 4) app status [ppp2p, i2ptunnel, im, ns, squid] </p>
-[22:02] <duck> 5) why does jrand0m drink cheap local beer?</p>
-[22:02] <jrand0m> 5) comments / questions / etc </p>
-[22:02] <jrand0m> heh </p>
-[22:02] <jrand0m> so yeah, basically that fits under 5 :) </p>
-[22:02] <mihi_> double 5 ;)</p>
-[22:03] <mihi_> oops...</p>
-[22:03] <jrand0m> 0) welcome </p>
-[22:03] * mihi_ did not look 2 the left column</p>
-[22:03] <jrand0m> hi.  65th meeting I suppose. </p>
-[22:03] <jrand0m> hehe </p>
-[22:03] <jrand0m> 1) that code stuff </p>
-[22:04] <jrand0m> 0.2.1.1 came out last night </p>
-[22:04] <jrand0m> lots of goodness in there. </p>
-[22:04] * mihi tests it atm.</p>
-[22:04] <jrand0m> tunnels are tested and fail fast, penalizing all participants so they won't likely get into the rebuild </p>
-[22:05] <jrand0m> messages in i2ptunnel are also throttled to max 64k size (larger messages caused badness) </p>
-[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 </p>
-[22:06] <jrand0m> (i2p doesn't have enough traffic on it to cause real load atm anyway) </p>
-[22:06] <jrand0m> (but bw limiting will be unit tested and fixed for 0.2.1.2) </p>
-[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. </p>
-[22:07] <jrand0m> we may be able to work out a way to not require semi-sync'ed clocks, but its delicate. </p>
-[22:07] <jrand0m> 2) fun stuff </p>
-[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. </p>
-[22:08] <jrand0m> since its planned for replacement in 0.3, might as well at least mention what its being replaced with </p>
-[22:09] <jrand0m> kademlia is a structured distributed hash table (DHT) that lets us insert and fetch in under O(log(N)) time, guaranteed </p>
-[22:09] <jrand0m> [with one small caveat thats still being worked out] </p>
-[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. </p>
-[22:10] <jrand0m> however, things would be simpler if it were implemented seperately - and hence testable seperately. </p>
-[22:10] <jrand0m> (unit testing == good) </p>
-[22:11] <jrand0m> so, whats a simple way to unit test a dht?  to write a simple file store/lookup service on it. </p>
-[22:11] <dm> insert fetch? are we talking about content?</p>
-[22:11] <jrand0m> enter idn: (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN </p>
-[22:11] <Ophite1> dm: No, only routerinfo and leaseset structures.</p>
-[22:12] <jrand0m> dm> i2p's networkDatabase currently contains only two specialized structures, as ophite said </p>
-[22:12] <dm> okay, thanks.</p>
-[22:12] <Ophite1> may or may not be useful to use it for bootstrapping other protocols too, but it's not anonymous itself. (?)</p>
-[22:12] *** grimps (~grimp@anon.iip) has joined channel #iip-dev</p>
-[22:12] <tusko> one question: which protocol is used now for networkDatabase?</p>
-[22:13] <jrand0m> sorry, phone. </p>
-[22:13] *** Signoff: godmode0 (Ping timeout)</p>
-[22:13] <jrand0m> correct, kademlia is not anonymous, but not non-anonymous either </p>
-[22:13] <Ophite1> modified kademlia will scale. random will not.</p>
-[22:13] <jrand0m> tusko> currently we do a flooded broadcast </p>
-[22:13] <duck> what about kademlia getting splitted?</p>
-[22:13] <dm> no cell phones allowed into meeting.</p>
-[22:13] <duck> <insert zooko comments></p>
-[22:13] <Ophite1> flooded broadcast aka gnutella method definitely won't ;)</p>
-[22:13] <jrand0m> Ophite1> right, kademlia doesn't use random ones :) </p>
-[22:13] <duck> Ophite1: works better as freenet routing :)</p>
-[22:14] <jrand0m> duck> exactly (<jrand0m> [with one small caveat thats still being worked out] ) </p>
-[22:14] <Ophite1> duck: i rest my case... ;)</p>
-[22:14] *** Signoff: mihi (Ping timeout)</p>
-[22:14] <tusko> is kademlia some sort of hypercube?</p>
-[22:14] <Ophite1> no, a circle.</p>
-[22:14] *** Signoff: mihi_ (Ping timeout)</p>
-[22:14] <jrand0m> and/or a xor tree :) </p>
-[22:15] <Ophite1> splits/joins... reshuffle tree? can we take a peek at emule's overnetalike for this? :)</p>
-[22:15] <jrand0m> its a fairly easy protocol, but we can definnitely look around. </p>
-[22:16] <jrand0m> icepick has implemented kademlia in python too, for ent (as kashmir) </p>
-[22:16] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
-[22:16] <Ophite1> consider also malicious nodes deliberately fragmenting the tree.</p>
-[22:16] <jrand0m> absolutely.  but its fairly attack resistant </p>
-[22:16] <Ophite1> 256 bit keyspace is more resistant to that though.</p>
-[22:17] <Ophite1> plus would have to make a lot of routeridentity structures = hard.</p>
-[22:17] <tusko> i found interesting the papers of gravepine: (Link: http://grapevine.sourceforge.net/)http://grapevine.sourceforge.net/</p>
-[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 </p>
-[22:17] <Ophite1> so I'm pleased with sec 3 of 0.9 draft.</p>
-[22:17] *** Signoff: nickthief54450 (Excess Flood)</p>
-[22:18] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[22:18] <tusko> look to (Link: http://grapevine.sourceforge.net/tech-overview.php)http://grapevine.sourceforge.net/tech-overview.php</p>
-[22:18] <Ophite1> though I might point out that if message 0, DatabasePing, is inplemented, you might want to include a hashcash in it.</p>
-[22:18] <jrand0m> interesting tusko, I think their economic model might require some revision, as with their sybyl defenses </p>
-[22:19] <Ophite1> (you may already; haven't ready that part)</p>
-[22:19] <jrand0m> absolutely Ophite1.  I was actually thinking about putting hashcash certs into all of the messages (DatabaseLookup included) </p>
-[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?</p>
-[22:21] <jrand0m> well, hashcash verification should be near instantaneous </p>
-[22:21] <jrand0m> and hashcash generation shouldn't be able to be precompiled </p>
-[22:21] <jrand0m> er, precomputed </p>
-[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.</p>
-[22:22] <jrand0m> lol </p>
-[22:22] * dm is not fooled.</p>
-[22:22] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev</p>
-[22:22] <Ophite1> one way of preventing that is to use derivatives of session keys as part of the hashcash..</p>
-[22:22] <jrand0m> right.  and/or put in a nonce and the date </p>
-[22:22] <Ophite1> date leads to those troublesome timing problems though. that could be a real issue.</p>
-[22:22] <Ophite1> unless you feel like rewriting ntp as well ;-)</p>
-[22:22] *** Signoff: mihi (Ping timeout)</p>
-[22:23] <jrand0m> heh </p>
-[22:23] <jrand0m> well, we've already run into that a little bit </p>
-[22:23] <jrand0m> (hence the 30 minute fudge factor) </p>
-[22:23] <jrand0m> a session hash may be workable though.  good idea. </p>
-[22:24] <Ophite1> and no, i'm not jrand0m's clone ;)</p>
-[22:24] <jrand0m> ok, so for idn, I'm probably only going to implement the stuff on that I2PIDN wiki page  </p>
-[22:25] *** Signoff: dm (Ping timeout)</p>
-[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. </p>
-[22:25] <jrand0m> also, I had some ideas about a search network built in parallel as well </p>
-[22:26] <jrand0m> but, well, its probably more useful to i2p that I focus my time on the router </p>
-[22:26] <Ophite1> it runs on top of i2p?</p>
-[22:26] <jrand0m> (making it functional, scalable, and secure) </p>
-[22:26] <jrand0m> yes </p>
-[22:26] <jrand0m> i2p lets idn be anonymous </p>
-[22:27] <Ophite1> what were your search network ideas?</p>
-[22:27] <jrand0m> note: its not written yet, but its looking like its #2 on my task list </p>
-[22:27] <Ophite1> can another dht be built through tunnels?</p>
-[22:27] *** mihi (~mihi@anon.iip) has joined channel #iip-dev</p>
-[22:27] <jrand0m> basically a distributed replicated db, with hashcash inserts and syncs, where people store idn keys along side metadata / etc </p>
-[22:27] *** dm (~as@anon.iip) has joined channel #iip-dev</p>
-[22:28] <jrand0m> hmm, yes, certainly.  but i2p isn't inherently tunnel based - its message based (i2p is IP, i2ptunnel is TCP) </p>
-[22:28] <Ophite1> if ~all node participate = very useful for "discovering" other protocols.</p>
-[22:28] <jrand0m> definitely </p>
-[22:28] <Ophite1> so, should be standard.</p>
-[22:28] <Ophite1> dhcp/zeroconf for the i2p? :)</p>
-[22:28] <jrand0m> idn would be a very good app to bundle with i2p to let people have an 'out of box experience' </p>
-[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".</p>
-[22:29] <jrand0m> :) </p>
-[22:29] <Ophite1> You, of course, probably already know where that comes from. :)</p>
-[22:30] <dm> Where does it come from?</p>
-[22:30] <Ophite1> MS Research's paper: The Darknet and the Future of Content Distribution.</p>
-[22:30] *** Signoff: godmode0 (Ping timeout)</p>
-[22:30] <TC> link?</p>
-[22:30] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
-[22:30] <jrand0m> well, tim may says he invented the term ~11 years ago ;) </p>
-[22:30] <tusko> where is the I2PIDN wiki page?</p>
-[22:30] <dm> (Link: http://crypto.stanford.edu/DRM2002/darknet5.doc)http://crypto.stanford.edu/DRM2002/darknet5.doc</p>
-[22:30] <jrand0m> tusko> (Link: http://wiki.invisiblenet.net/iip-wiki?I2PIDN)http://wiki.invisiblenet.net/iip-wiki?I2PIDN </p>
-[22:30] <Ophite1> also implies that the network works "in the dark" - noone knows who anyone is ;)</p>
-[22:30] <jrand0m> exactly. </p>
-[22:31] *** mihi_ (~mihi@anon.iip) has joined channel #iip-dev</p>
-[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. </p>
-[22:31] <jrand0m> i2ptunnel is the TCP layer, and idn is NFS :) </p>
-[22:31] <Ophite1> i2p is the protocol that allows such a network to be created from something broadly like overnet.</p>
-[22:31] <Ophite1> speaking of which... is there a way to specify priority in messages?</p>
-[22:32] *** mihi is now known as nickthief76430</p>
-[22:32] *** mihi_ is now known as mihi</p>
-[22:32] <jrand0m> funny that you mention that :) </p>
-[22:32] *** nickthief76430 is now known as mihi_backup</p>
-[22:32] <mihi> oops...</p>
-[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 </p>
-[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?</p>
-[22:33] <Ophite1> ah, well that might work better of course =)</p>
-[22:33] <Ophite1> Don't worry about local plausible denability.</p>
-[22:33] <jrand0m> right, i2p assumes the local machine is trusted </p>
-[22:33] *** Signoff: dm (Ping timeout)</p>
-[22:33] <Ophite1> That is a problem to be solved by Rubberhose/Marutukku and Thermite, not I2P.</p>
-[22:34] <jrand0m> exactly.  (otherwise, the software is compromised and it doesn't matter what we do) </p>
-[22:34] * TC hopes his local machine is trusted</p>
-[22:34] <jrand0m> heh </p>
-[22:34] <Ophite1> TC: easy way to find out; make death threats against bush and see if SS agents turn up at your door ;-)</p>
-[22:34] <jrand0m> lol </p>
-[22:34] <TC> done and done</p>
-[22:34] *** Signoff: tonious (Ping timeout)</p>
-[22:34] <jrand0m> hah! </p>
-[22:35] * jrand0m watches my squid proxy get taken down by the fbi</p>
-[22:35] <TC> its a trap!</p>
-[22:35] <jrand0m> get an axe! </p>
-[22:35] <jrand0m> :) </p>
-[22:35] <TC> anybody play uplink?</p>
-[22:35] <Ophite1> completed it. cracked it. released it.</p>
-[22:35] <Ophite1> trained it too ;)</p>
-[22:36] * jrand0m takes that as a "yes"</p>
-[22:36] *** dm (~as@anon.iip) has joined channel #iip-dev</p>
-[22:37] <Ophite1> there may be some dos possibilities in caching, in memory stuff...</p>
-[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 </p>
-[22:37] <jrand0m> oh certainly.  the todo list has 'sync pending and large messages to disk' :) </p>
-[22:37] <dm> shouldn't IDN be implemented after I2P is tested and mature?</p>
-[22:38] <jrand0m> thats one of the problems we ran into testing a large file of TC's eepsite </p>
-[22:38] <Ophite1> dm: not given as it's a testbed for the fancy db.</p>
-[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 </p>
-[22:38] <Ophite1> I do like the hybrid dht nature such a network would provide though.</p>
-[22:39] <dm> aha... </p>
-[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 </p>
-[22:39] <Ophite1> dht node discovery + ngr-like routing = scalability capable of handling critical mass</p>
-[22:39] <dm> what happened to that original milestone list. secure-->anonymous-->not harvestable, etc...</p>
-[22:39] <Ophite1> jrand0m: I will refrain from advertising it to pirates until it's ready. that enough?</p>
-[22:39] <jrand0m> well, minus the ngr-like routing :) we tunnel :) </p>
-[22:39] <TC> as long as we keep the cli</p>
-[22:39] <dm> ah scalable was one of the items in that chain.</p>
-[22:39] <jrand0m> dm> 0.3 is necessary for scalable.  which is before not harvestable </p>
-[22:39] <jrand0m> thanks Ophite1 :) </p>
-[22:40] <jrand0m> definitely TC.  I'll need the cli to test it </p>
-[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?</p>
-[22:40] <jrand0m> (and, c'mon, we'll probably do software distribution / releases with idn) </p>
-[22:40] *** godmode0 (~enter@anon.iip) has joined channel #iip-dev</p>
-[22:40] <dm> alrighty... sounds okay then.</p>
-[22:40] <jrand0m> absolutely ophite. </p>
-[22:40] <Ophite1> suggestion: maximum message size?</p>
-[22:40] <jrand0m> thats the Hard problem </p>
-[22:41] <jrand0m> max message size is currently insanely large (4g) but I'm thinking of trimming it to 64k or 128k </p>
-[22:41] <jrand0m> but I don't want to resort to that yet </p>
-[22:41] * Ophite1 goes digging in notes</p>
-[22:41] <Ophite1> BitTorrent/Scone scalability notes indicate 512K.</p>
-[22:42] <jrand0m> heh ok cool.  (any refs I can dig into?) </p>
-[22:42] <Ophite1> but, think of it like tcp window size.</p>
-[22:42] <jrand0m> right </p>
-[22:42] <Ophite1> not for scone, sorry - friend's research project.</p>
-[22:42] <jrand0m> coo', no worry </p>
-[22:42] *** Signoff: mihi_backup (Ping timeout)</p>
-[22:42] <Ophite1> fwiw, your kademlia is about as good as his though :)</p>
-[22:42] <jrand0m> hehe </p>
-[22:42] <jrand0m> (well, I haven't implemented it yet ;) </p>
-[22:42] <Ophite1> uh, hers I mean :/</p>
-[22:42] <jrand0m> oh wikked </p>
-[22:43] <dm> boner..</p>
-[22:43] *** mihi_backup (~mihi@anon.iip) has joined channel #iip-dev</p>
-[22:43] <jrand0m> heh </p>
-[22:43] <jrand0m> so, thats 2) kademlia, 0.3, and idn </p>
-[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 ;)</p>
-[22:43] <jrand0m> haha </p>
-[22:45] <Ophite1> she's a math.</p>
-[22:45] <jrand0m> even better </p>
-[22:45] <jrand0m> there's a lot of stats gathering / analysis that will be coming up for advanced peer selection </p>
-[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.</p>
-[22:45] <jrand0m> (unfortunately we can't cheat like mnet, mixminion, and tor) </p>
-[22:46] <jrand0m> great to hear </p>
-[22:46] <Ophite1> one comment - dsa?</p>
-[22:46] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[22:46] <Ophite1> dsa 1024 bit, as in SHA-1?</p>
-[22:46] <jrand0m> yea </p>
-[22:47] <Ophite1> 'spose it is tried and tested.</p>
-[22:47] <Ophite1> also small.</p>
-[22:47] <jrand0m> right.  but I'm not 100% tied to our particular crypto impls </p>
-[22:47] <Ophite1> anyway. to roadmap.</p>
-[22:47] <TC> haha, lets name a windows version 'Microsoft Darknet (r)'</p>
-[22:47] <jrand0m> heh tc </p>
-[22:48] <jrand0m> ok, 3) roadmap revise (0.2.3 --> 0.4, 0.2.2 --> 0.3.1)? </p>
-[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 </p>
-[22:48] <TC> its nice not being limmited by trademarks like a normal open source project</p>
-[22:49] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
-[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 </p>
-[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) </p>
-[22:50] <Ophite1> trusted peers is an area that needs some revision imho.</p>
-[22:50] <jrand0m> agreed. </p>
-[22:50] *** dm_backup (~as@anon.iip) has joined channel #iip-dev</p>
-[22:50] <Ophite1> only area that doesn't give me warm fuzzies.</p>
-[22:50] <Ophite1> though that may just be the word "trusted". :)</p>
-[22:50] <jrand0m> basically my current thoughts are to publish tunnels to routers </p>
-[22:50] <jrand0m> heh </p>
-[22:51] <jrand0m> (if we publish tunnels to routers, we can get away with untrusted gateways, which drops the 'trusted' from trusted peers) </p>
-[22:51] *** Signoff: dm (Ping timeout)</p>
-[22:51] *** dm_backup is now known as dm</p>
-[22:51] <Ophite1> need to analyse anonymity implications of that.</p>
-[22:51] <jrand0m> but trusted peers is inherently necessary in a militant grade anon system, where /all/ nodes you can contact are considered attackers. </p>
-[22:52] <Ophite1> don't think that is truly possible...</p>
-[22:52] <jrand0m> certainly.  yet another reason it should get 0.4 </p>
-[22:52] <jrand0m> Ophite1> trusted nodes with timed / triggered self destruct. </p>
-[22:52] <jrand0m> set up a patsy, route through it, kill it </p>
-[22:52] <jrand0m> exactly, if patsies delete their logs after N hours / N bytes / N messages </p>
-[22:52] <Ophite1> I mean if you want me to release a worm that sets up a couple of million...</p>
-[22:53] <Ophite1> logs? what logs?</p>
-[22:53] <jrand0m> :) </p>
-[22:53] <jrand0m> ok, format the disks ;) </p>
-[22:53] * Ophite1 wrote kernel-level stealth trojan</p>
-[22:53] <jrand0m> nice </p>
-[22:53] * dm wrote kernel level outlook calendar plugin.</p>
-[22:53] <Ophite1> ...when I was 19 :)</p>
-[22:53] <Ophite1> still works. :)</p>
-[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 ;)</p>
-[22:54] <dm> when I was 12.</p>
-[22:54] <jrand0m> I don't think i2p will want /that/ large distribution until after 1.0 is stable and heavily peer reviewed </p>
-[22:54] <jrand0m> heh Ophite1 </p>
-[22:54] <jrand0m> heh dm </p>
-[22:54] <Ophite1> frankly, think that is a fluff feature.</p>
-[22:54] <jrand0m> perhaps. </p>
-[22:55] <jrand0m> restricted routes is a necessity though </p>
-[22:55] <jrand0m> its basic functionality for people behind firewalls </p>
-[22:55] <jrand0m> (very restrictive firewalls) </p>
-[22:55] <Ophite1> hello, transports.</p>
-[22:55] <Ophite1> we'll get to that.</p>
-[22:55] <Ophite1> or is now the appropriate time to discuss them?</p>
-[22:55] <jrand0m> sure, lets dig in :) </p>
-[22:56] <jrand0m> we've already run into a problem with an unreachable peer that could be solved with restricted routes </p>
-[22:56] *** tusko has left #iip-dev</p>
-[22:56] <jrand0m> even though it was due to misconfiguration, it could be more common </p>
-[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...</p>
-[22:57] <Ophite1> You can establish a TCP connection between the two firewalled peers that both firewalls think is outbound.</p>
-[22:57] <jrand0m> definitely </p>
-[22:57] <dm> forged IP addresses?!?</p>
-[22:58] <Ophite1> believe me, firewalls are a VERY common problem.</p>
-[22:58] <Ophite1> sometimes they are user-controlled but the user is a doofus. that can be handled with the installer handling the firewall :)</p>
-[22:58] <dm> I2P is gonna use IP spoofing? :)</p>
-[22:58] <jrand0m> definitely.  if i2p can't operate behind firewalls / NATs / proxies, there's no reason to continue. </p>
-[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.</p>
-[22:59] <jrand0m> dm> transport options </p>
-[22:59] <jrand0m> absolutely Ophite1 </p>
-[22:59] <Ophite1> dm: I have a working implementation - in the Direct Connect protocol.</p>
-[22:59] <jrand0m> i2p wants to be the battleground for that code. </p>
-[22:59] <Ophite1> dm: If *that* can handle it, i2p can.</p>
-[22:59] *** Signoff: tonious (Ping timeout)</p>
-[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.</p>
-[23:00] <dm> you can't spoof IPs without native code can you?</p>
-[23:00] <Ophite1> the advantage is that they don't have to route *through*, just help the setup.</p>
-[23:00] <Ophite1> = massive speed boost.</p>
-[23:01] <jrand0m> definitely Ophite1, thats what the RouterInfo.routerAddress[] structure is for </p>
-[23:01] <Ophite1> dm: yeah, like this isn't going to be rewritten?</p>
-[23:01] *** tonious (~Flag@anon.iip) has joined channel #iip-dev</p>
-[23:01] <dm> okay, just checking...</p>
-[23:01] <jrand0m> right dm, I have no qualms whatsoever with including native code in i2p </p>
-[23:01] <Ophite1> I would like to state that I don't think java is a permanent solution.</p>
-[23:01] <Ophite1> And that I regard java router as testbed/prototype.</p>
-[23:01] <jrand0m> thats fine.  if it gets us to 1.0, works out the protocol, etc, good enough. </p>
-[23:02] <Ophite1> ...and hope it doesn't get stuck there as freenet has ;)</p>
-[23:02] <dm> IPAddress.Spoof(192.168.32.1);</p>
-[23:02] *** alient (alient@anon.iip) has joined channel #iip-dev</p>
-[23:02] <jrand0m> lol dm </p>
-[23:02] <dm> import IPSpoofing;</p>
-[23:02] <Ophite1> mmm... raw sockets in java ;)</p>
-[23:02] <jrand0m> fcntl / ioctl in java... mmMMmm </p>
-[23:02] <mihi> hmm, raw sockets require root on unix, don't they?</p>
-[23:02] <dm> women with large breasts lickig my penis.. mmMMmmm</p>
-[23:02] <jrand0m> so we include a rootkit </p>
-[23:03] <jrand0m> ;) </p>
-[23:03] <Ophite1> jrand0m: got it covered =)</p>
-[23:03] <jrand0m> heh </p>
-[23:03] <Ophite1> besides as I said; only a few need it.</p>
-[23:03] <jrand0m> right </p>
-[23:04] <jrand0m> and only for legitimate reasons, of course. </p>
-[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.</p>
-[23:04] <Ophite1> caused a bit of amazement that did.</p>
-[23:04] <jrand0m> hehe </p>
-[23:04] <Ophite1> also got the bot's host shut down, hence my suggestion to perhaps turn it off by default :)</p>
-[23:04] <jrand0m> thats definitely a good feature to have avail </p>
-[23:04] <jrand0m> lol </p>
-[23:05] *** Signoff: nickthief54450 (Excess Flood)</p>
-[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 </p>
-[23:06] <jrand0m> any other thoughts / things that should be in the roadmap that aren't, things that are in the wrong place, etc? </p>
-[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...</p>
-[23:06] <Ophite1> ...someone that can't open a firewall port probably shouldn't be trying it yet.</p>
-[23:06] *** nickthief54450 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[23:06] <jrand0m> right.  and even with firewalls, PHTTP lets them through. </p>
-[23:07] <Ophite1> though need to test phttp against hostile proxies.</p>
-[23:07] * jrand0m is behind a firewall I don't control and I participate fully in i2p</p>
-[23:07] <dm> hax0r</p>
-[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 </p>
-[23:08] <jrand0m> but the phttp relay and transport does have a lot of features needed </p>
-[23:08] <Ophite1> in particular, to examine the future possibilities application level routers might have at detecting/fucking up the protocol.</p>
-[23:08] <jrand0m> hm? </p>
-[23:08] <Ophite1> have some experience with firewall tunnelling though.</p>
-[23:08] <Ophite1> might want to include a GET fallback.</p>
-[23:09] <jrand0m> hmm.  GET goes into logs.  but perhaps as a fallback </p>
-[23:09] <jrand0m> (POST can be to /index.html) </p>
-[23:09] <Ophite1> jrand0m: but it's all signed/encrypted if noderefs are cool...?</p>
-[23:10] <Ophite1> unless the proxy becomes an active attacker too, that's going to be quite hard for it.</p>
-[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 </p>
-[23:10] <jrand0m> right.  phttp proxy as is certainly isn't strong enough to go against an active attacker </p>
-[23:11] *** Signoff: grimps (Leaving)</p>
-[23:12] <jrand0m> I think it'd be great if people posted some alternate transport ideas to the wiki :) </p>
-[23:12] <jrand0m> ok, 4) app status [ppp2p, i2ptunnel, im, ns, squid] </p>
-[23:12] <jrand0m> damn, tusko left </p>
-[23:12] <jrand0m> tusko wrote a python script (ppp2p) to let people run ppp over i2p via i2ptunnel </p>
-[23:13] <Ophite1> Told you someone would do that :)</p>
-[23:13] <dm> ppp over i2p?</p>
-[23:13] <jrand0m> I haven't looked at it, but last I heard he was running a vpn over i2p with 5s ping times </p>
-[23:13] <jrand0m> heh yeah </p>
-[23:13] <Ophite1> dm: of course.</p>
-[23:13] <dm> when could you use that?</p>
-[23:13] <dm> could/would</p>
-[23:13] <jrand0m> dm> anonymous outproxy </p>
-[23:13] <Ophite1> dm: anonymous ANYTHING.</p>
-[23:13] <jrand0m> to, say, run a kazaa node anonymously, or whatever </p>
-[23:13] * Ophite1 points out that anyone running an outbound i2p->ppp link is insane and will probably be blacklisted/hunted down</p>
-[23:13] <dm> ah, I understand.</p>
-[23:13] <jrand0m> definitely Ophite1 </p>
-[23:14] <jrand0m> so right now, its only for trusted peers.   </p>
-[23:14] <Ophite1> see also: the dresden JAP cascade... :)</p>
-[23:14] <jrand0m> which, well, doesnt really make sense for anonymity... </p>
-[23:14] <jrand0m> heh </p>
-[23:14] <Ophite1> also most of the stuff going out of their node will be unencrypted...</p>
-[23:14] * jrand0m thinks about ike over ppp over i2p</p>
-[23:15] * jrand0m watches my head explode</p>
-[23:15] *** fiaga (~po@anon.iip) has joined channel #iip-dev</p>
-[23:15] <Ophite1> jrand0m: why not i2p over ppp over i2p?</p>
-[23:15] <jrand0m> definitely doable.  aint recursion fun? </p>
-[23:15] <soros> i2p over i2p  :-o</p>
-[23:15] <jrand0m> or i2p over ppp over i2p over i2p over freenet over kazaa </p>
-[23:15] <Ophite1> now that's just silly. Freenet wouldn't possibly work ;)</p>
-[23:16] <godmode0> over slow connect :)</p>
-[23:16] <jrand0m> heh it'd have latency issues, certainly :) </p>
-[23:16] <mihi> ... over an icmp tunnel over ...</p>
-[23:16] <Ophite1> ooh yes, loki :)</p>
-[23:16] <Ophite1> 0ldsk00l :)</p>
-[23:17] <Ophite1> I2P addresses, being the public keys, are ... rather long.</p>
-[23:17] <jrand0m> yes. </p>
-[23:17] <jrand0m> actually, since we're on agenda item 4: ns </p>
-[23:17] <Ophite1> As in an I2P www url being actually too long to paste into any sane place (>512 chars?!!)</p>
-[23:17] <mihi> co promised to write a naming service...</p>
-[23:17] <jrand0m> yeah. </p>
-[23:17] <jrand0m> I think with idn implemented, it would be very easy for someone to adapt the kademlia code into a distributed dns  </p>
-[23:17] <mihi> Ophite1: post them to the eepsite forum.</p>
-[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.</p>
-[23:18] *** Signoff: fiaga (Ping timeout)</p>
-[23:18] <jrand0m> (just toss on a CA or WoT CAs, and voila.  (Link: www.mihi.i2p)www.mihi.i2p) </p>
-[23:18] <jrand0m> not necessarily. </p>
-[23:18] <Ophite1> please enlighten me with your better ideas then.</p>
-[23:18] <jrand0m> Ophite1> check out co/wiht's specs on the iip-dev list.   </p>
-[23:19] <Ophite1> best I could come up with is root key creates signed namespaces. dnssec stylee.</p>
-[23:19] <jrand0m> he doesn't go the full route with a dht, but he manages groups </p>
-[23:19] <jrand0m> just like how we do now - we /all/ can choose who our root dns servers are. </p>
-[23:19] <jrand0m> in the same vein, we /all/ should be able to choose who our CA (or CA WoT) is </p>
-[23:20] <jrand0m> so I guess technically there /could/ be collisions, but only once there are multiple CA groups that don't interact </p>
-[23:20] * Ophite1 notes that is unlikely</p>
-[23:20] <jrand0m> agreed </p>
-[23:20] <Ophite1> you either trust the root CA or you don't.</p>
-[23:20] <jrand0m> and if you don't trust the root, you create your own </p>
-[23:21] <jrand0m> (or find another) </p>
-[23:21] <Ophite1> and if you don't trust the root CA it's for a reason, a reason that will rapidly get around.</p>
-[23:21] <jrand0m> exactly </p>
-[23:21] <jrand0m> especially when there's anonymous publishing :) </p>
-[23:21] <Ophite1> being as CA's only real purpose is to insure anti-collision - like Trent...</p>
-[23:21] <jrand0m> right </p>
-[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.</p>
-[23:22] * jrand0m notes verisign's "trustworthiness"</p>
-[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</p>
-[23:23] <jrand0m> self signed certs+++ </p>
-[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.</p>
-[23:24] <Ophite1> It's for servers, really.</p>
-[23:24] <jrand0m> heh </p>
-[23:24] <jrand0m> right </p>
-[23:24] <Ophite1> Servers don't scale. That problem will be in i2p as much as in IP.</p>
-[23:24] <Ophite1> so, I think that the usage in practice will actually be surprisingly limited.</p>
-[23:24] <jrand0m> the idn ("darknet") would keep references to destinations - the full 387 bits of their keys, not some pretty name </p>
-[23:24] <jrand0m> agreed. </p>
-[23:25] <jrand0m> except / until someone writes a distributed outproxy system </p>
-[23:25] <jrand0m> aka o-r / freedom  over i2p </p>
-[23:25] <TC> how many diffrent keys can we have?</p>
-[23:25] * jrand0m looks forward to that day</p>
-[23:25] <jrand0m> tc> 2^2048 </p>
-[23:25] <Ophite1> jrand0m: at which point the root key signs them a namespace: .proxy.i2p</p>
-[23:26] <dm> This must be the most hypothetical/megalomaniac open source development meeting ever :)</p>
-[23:26] <jrand0m> aint subspaces grand :) </p>
-[23:26] <jrand0m> lol dm </p>
-[23:26] <jrand0m> hey, we're alowed to aim high, aint we? </p>
-[23:26] <dm> I'm sure most devl meetings are like: "So, do we put 3 bits for the mpeg-5 header or 4?"</p>
-[23:26] <Ophite1> jrand0m: oddly as it may seem, not every number works for elgamal ;-)</p>
-[23:26] <TC> dm, youve seen debian meetings right?</p>
-[23:26] <jrand0m> awww c'mon, 000000000000000000000000000 is a secure key </p>
-[23:26] * Ophite1 hands out Chocolate Digestives</p>
-[23:26] <dm> TC: no, what are the like?</p>
-[23:26] <Ophite1> jrand0m: ooh, identity.</p>
-[23:26] <TC> dm, i dont know, i was asking</p>
-[23:27] <jrand0m> ok.  thecrypto isn't here either... anyone have im thoughts? </p>
-[23:27] <Ophite1> damn, I was about to ask about that.</p>
-[23:27] <Ophite1> quite an important app.</p>
-[23:27] <dm> Anyway, this type of meeting is more lurker-friendly, so I'm all for it.</p>
-[23:27] * dm is entertained.</p>
-[23:27] <jrand0m> heh </p>
-[23:27] <TC> where is co?</p>
-[23:27] <Ophite1> as many people will expect i2p to be iip's successor.</p>
-[23:28] <jrand0m> iip over i2p is fairly easy, if we don't want dcc </p>
-[23:28] <Ophite1> (I guess it could be, if we just run an iip irc server over i2p...)</p>
-[23:28] <jrand0m> iip over i2p with dcc requires a new app </p>
-[23:28] <jrand0m> exactly Ophite1 </p>
-[23:28] <jrand0m> 0 coding </p>
-[23:28] <TC> cant we just run irc over i2p?</p>
-[23:28] <Ophite1> I don't like that idea 'cause ... well, it doesn't give us anything we don't already have :)</p>
-[23:28] <jrand0m> but last I heard, thecrypto was doing some work on an IM app </p>
-[23:28] <jrand0m> certainly tc </p>
-[23:29] <jrand0m> right Ophite1, and it doesn't scale </p>
-[23:29] <jrand0m> (all the traffic gets funneled to the ircd) </p>
-[23:29] <Ophite1> Also the IRCd can spy on traffic.</p>
-[23:29] <TC> ah, goodpoint</p>
-[23:29] <jrand0m> (this would be when UserX should show up and discuss his ideas for iip2.0) </p>
-[23:29] <jrand0m> right Ophite1 </p>
-[23:29] <jrand0m> all the problems of the current iip </p>
-[23:29] <Ophite1> jrand0m: And absolutely nothing different.</p>
-[23:29] <jrand0m> more lag. </p>
-[23:30] <Ophite1> except it's in java. lovely. :)</p>
-[23:30] <jrand0m> heh </p>
-[23:30] <Ophite1> Now, shitloads of people have cut their undergraduate teeth trying and failing to build distributed chat applications.</p>
-[23:30] <jrand0m> ok, so someone should either help thecrypto out or push him along some more :) </p>
-[23:30] * Ophite1 points out IRC3</p>
-[23:30] <jrand0m> yeah, its a perfect school project </p>
-[23:30] <Ophite1> ..and SILC...</p>
-[23:30] <Ophite1> ...and...</p>
-[23:31] <Ophite1> well about a gazillion others.</p>
-[23:31] <jrand0m> 'zactly </p>
-[23:31] <Ophite1> Literally all of these, I might add, are pre-DHT as far as I can tell.</p>
-[23:31] <jrand0m> yup </p>
-[23:31] <Ophite1> That's disappointing 'cause that's a freakishly useful structure.</p>
-[23:31] <jrand0m> a DHT for lookup / P3P, and then direct con for IM </p>
-[23:31] <jrand0m> group chat is harder though, but not too hard </p>
-[23:31] <Ophite1> well, direct in the i2p sense :)</p>
-[23:31] <jrand0m> heh right </p>
-[23:32] <Ophite1> what about darkmail/i2pmail?</p>
-[23:32] <soros> group sex too</p>
-[23:32] <dm> soros: agreed.</p>
-[23:32] <jrand0m> group sex isn't that hard soros ;) </p>
-[23:32] <jrand0m> lol </p>
-[23:32] <jrand0m> email over i2p is easy.  someone just needs to run a pop server </p>
-[23:32] <jrand0m> or webmail </p>
-[23:32] <jrand0m> hahah </p>
-[23:33] <Ophite1> jrand0m: sure, as long as literally everyone is okay with bloody pgp :)</p>
-[23:33] * Ophite1 gets CKT nightmares again</p>
-[23:33] <jrand0m> oh, true.  that'd expose the contents to hte server ;) </p>
-[23:33] <Ophite1> Also... spam.</p>
-[23:33] <jrand0m> yup </p>
-[23:33] <Ophite1> We have this thing called hashcash.</p>
-[23:33] <Ophite1> They sort of fit together, no?</p>
-[23:34] <jrand0m> ok, so yeah, someone should get working on an i2p specific email app :) </p>
-[23:34] <Ophite1> obviously that would work best as part of the im.</p>
-[23:34] <Ophite1> What, after all, is the distinction between irc and email?</p>
-[23:34] <jrand0m> true, like an IM VMB </p>
-[23:34] <Ophite1> Whether or not you can page up and see what you missed after you rejoin...</p>
-[23:34] <jrand0m> placed into the dht </p>
-[23:34] <jrand0m> good point </p>
-[23:35] * jrand0m wishes we had a team of a dozen coders</p>
-[23:35] <Ophite1> note, however, that mail requires storage, as it is offline communication. irc requires no storage, as it is online communication.</p>
-[23:35] <dm> also email has a lot more penis enlargement adverts.</p>
-[23:35] <Ophite1> jrand0m: ask around for funding.</p>
-[23:35] <Ophite1> dm: see above re: hashcash.</p>
-[23:35] <jrand0m> right, the P3P could contain pending messages </p>
-[23:36] <Ophite1> dm: A primitive that was not available to the bloke who hacked up email in a night.</p>
-[23:36] <Ophite1> (At least we won't have to use ! paths to specify the tunnel manually. heh. heh. heh.)</p>
-[23:36] * dm is gonna miss clear-text dead simple protocols.</p>
-[23:36] <jrand0m> jrandom%ophite!dm!mihi </p>
-[23:37] <Ophite1> no, this is i2p. Insert ~520 garbage characters between the bangs then you're closer ;)</p>
-[23:37] <jrand0m> haha </p>
-[23:37] <Ophite1> several of these things *are* sort of related.</p>
-[23:37] <jrand0m> true, 387 bytes base64 encoded... </p>
-[23:38] <Ophite1> or to put it another way, ELONGURL :)</p>
-[23:38] <jrand0m> heh </p>
-[23:38] <Ophite1> [does IE chop at 512?]</p>
-[23:38] <jrand0m> naw, works fine </p>
-[23:38] <Ophite1> you admit to using IE?</p>
-[23:38] <Ophite1> To browse anonymously?!</p>
-[23:38] <jrand0m> ;) </p>
-[23:38] * Ophite1 pulls out six of Liu De Yiu's best and waits =)</p>
-[23:38] * jrand0m uses ie for eppsites, moz for squiding</p>
-[23:39] <duck> what item are we now?</p>
-[23:39] <duck> 4?</p>
-[23:39] <jrand0m> yeah, ok ok </p>
-[23:39] <Ophite1> still 4 I think.</p>
-[23:39] <jrand0m> i2ptunnel.  still kicks ass. </p>
-[23:39] <jrand0m> any thoughts?  any comments mihi? </p>
-[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  </p>
-[23:40] * mihi just waits for naming service...</p>
-[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 </p>
-[23:41] <mihi> btw: are there any other public dests except your squid and tc's eepsite?</p>
-[23:41] <jrand0m> i2pcvs.dest </p>
-[23:41] <jrand0m> (points at the i2p cvs pserver) </p>
-[23:41] <jrand0m> (but isn't always up) </p>
-[23:41] *** yodel (yodel@anon.iip) has joined channel #iip-dev</p>
-[23:41] <jrand0m> hola yodel </p>
-[23:41] <yodel> hela</p>
-[23:42] <jrand0m> ok, I think thats it for 4) apps </p>
-[23:42] <jrand0m> 5) comments / questions / etc </p>
-[23:42] <mihi> gui installer?</p>
-[23:42] <TC> hi yodel</p>
-[23:43] <yodel> I have to start experimenting putting the xml-rpc over i2p</p>
-[23:43] <yodel> should work with httptunnel</p>
-[23:43] <jrand0m> good question mihi.  last I heard MrEcho had some of it working </p>
-[23:43] <jrand0m> awesome yodel </p>
-[23:43] <jrand0m> definitely. </p>
-[23:43] <jrand0m> how large are the streams? </p>
-[23:43] <jrand0m> (aka how chatty is the protocol?) </p>
-[23:44] * Ophite1 plans to try BitTorrent over I2P as a stress test</p>
-[23:44] <yodel> xml over http</p>
-[23:44] <yodel> the ssl layer wont be needed with i2p</p>
-[23:44] <Ophite1> so, uh, very chatty? :)</p>
-[23:44] <jrand0m> ah cool, large POST or large replies? </p>
-[23:44] <jrand0m> (or just small and small?) </p>
-[23:45] <jrand0m> damn you Ophite1 :) </p>
-[23:45] <yodel> equal sizes</p>
-[23:45] <yodel> does httptunnel support gzipped http?</p>
-[23:45] <jrand0m> but doesn't bt use IP addresses? </p>
-[23:45] <jrand0m> hmm, httptunnel doesn't have any inherent compression, its just a bitstream </p>
-[23:45] <TC> hmm, package i2p+ppp\vpn+gui as a security solution for wireless windows shares</p>
-[23:45] <yodel> so should work...</p>
-[23:45] <godmode0> jrand0m> you test i2p in nntp news server ?</p>
-[23:45] <jrand0m> yup yodel </p>
-[23:45] <yodel> 500-1000 byte send, same for reply</p>
-[23:46] <jrand0m> hmm I haven't tested that yet godmode0 </p>
-[23:46] <yodel> much less when zipped</p>
-[23:46] <jrand0m> oh cool yodel, that'll work without any problem </p>
-[23:46] <yodel> what is the latency for a single msg/package/whatever?</p>
-[23:46] <jrand0m> 2-5s, sometimes up to 10s </p>
-[23:46] <jrand0m> (currently) </p>
-[23:46] <Ophite1> not bad for a pre-dht :)</p>
-[23:46] <yodel> so 20s roundtime?</p>
-[23:47] <jrand0m> I usually pull up a web page in 5-10s </p>
-[23:47] <yodel> ah</p>
-[23:47] <yodel> goo</p>
-[23:47] <yodel> +d</p>
-[23:48] <jrand0m> damn, we're coming up to the 2 hour mark.  anyone have any other questions / thoughts? </p>
-[23:48] <Ophite1> Pie is good.</p>
-[23:48] <duck> jrand0m: why do you drink cheap local beer?</p>
-[23:48] <Ophite1> Orgy and pie is better.</p>
-[23:48] <jrand0m> rofl duck </p>
-[23:49] <Ophite1> duck: It's better than Tesco Value Lager?</p>
-[23:49] * Ophite1 spits from reflex</p>
-[23:49] <jrand0m> heh </p>
-[23:49] * duck is concerned about jrand0m's health</p>
-[23:49] <jrand0m> you're concerned about my cheap beer habits but not my good whiskey habits? </p>
-[23:50] * Ophite1 reminds about the single malt on Cary Sherman's head</p>
-[23:50] <duck> do you eat well?</p>
-[23:50] <godmode0> corona</p>
-[23:50] <duck> do you do your daily exercises?</p>
-[23:50] <jrand0m> well, i'm one of those veggies </p>
-[23:50] <Ophite1> Isn't that a personal question, duck?</p>
-[23:50] <jrand0m> does typing count? </p>
-[23:50] <duck> you did drink that much already?</p>
-[23:50] <duck> that you became a veggie</p>
-[23:50] <jrand0m> heh </p>
-[23:50] <Ophite1> cheap beer will do that.</p>
-[23:51] <duck> Ophite1: jrand0m's health should concern us all, since it is essential for I2P</p>
-[23:51] *** Signoff: mihi_backup (mihi hands jrand0m the *BAF*er)</p>
-[23:51] <jrand0m> heh ok ok mihi </p>
-[23:51] * jrand0m winds up</p>
-[23:51] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/65.rst b/i2p2www/meetings/65.rst
new file mode 100644
index 00000000..98526126
--- /dev/null
+++ b/i2p2www/meetings/65.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 18, 2003 @ 21:02 UTC
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/66.log b/i2p2www/meetings/66.log
index acb50913..7defbf8f 100644
--- a/i2p2www/meetings/66.log
+++ b/i2p2www/meetings/66.log
@@ -1,477 +1,471 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 66{% endblock %}
-{% block content %}<h3>Tuesday, November 26, 2003 22:00:00 CET</h3>
-<div class="irclog">
-[22:04] <jrand0m> agenda: </p>
-[22:04] <jrand0m> 0) welcome </p>
-[22:04] <jrand0m> 1) status </p>
-[22:04] <jrand0m> 2) transport futures </p>
-[22:05] <jrand0m> 3) peer stats for selection </p>
-[22:05] <jrand0m> 4) apps </p>
-[22:05] <jrand0m> 5) ...? </p>
-[22:05] <jrand0m> 0) </p>
-[22:05] <jrand0m> hi. </p>
-[22:05] <jrand0m> 66 is it? </p>
-[22:05] <duck> 7) what brand of whiskey does jrand0m drink?</p>
-[22:06] <jrand0m> bushmills, glenlivit </p>
-[22:06] <jrand0m> (for whiskey and whisky, respectively) </p>
-[22:06] <TC> yey, i made the meating</p>
-[22:06] <jrand0m> woot </p>
-[22:06] <jrand0m> ok, 1) status </p>
-[22:06] <jrand0m> the kademlia stuff is coming along very well. </p>
-[22:07] <jrand0m> I've build a little simulator that runs a network of five nodes and puts them through the basic tests </p>
-[22:07] <jrand0m> also the idn stuff is implemented with some tests as well </p>
-[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 </p>
-[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. </p>
-[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 ;) </p>
-[22:10] <TC> idn is the stuff for the distributed storage?</p>
-[22:10] <jrand0m> roadmap has been updated as well - http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap </p>
-[22:10] <jrand0m> yes </p>
-[22:10] <jrand0m> idn = Invisible Distribution Network </p>
-[22:10] <jrand0m> (free open source anonymous akamai, basically) </p>
-[22:11] <TC> is there a non anonymous public akamai implemintation i could play with?</p>
-[22:11] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev</p>
-[22:12] <jrand0m> mnet is probably up that alley </p>
-[22:12] *** Signoff: nickthief60934 (Excess Flood)</p>
-[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. </p>
-[22:13] *** dm (~sd@anon.iip) has joined channel #iip-dev</p>
-[22:14] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[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 </p>
-[22:14] <TC> would it be posible do image grabs do idn from an i2ptunnel eepsite?</p>
-[22:15] <jrand0m> hmm? </p>
-[22:15] <jrand0m> oh, like <img src="idn:blah">? </p>
-[22:15] <TC> i was just thinking of bandwidth saving, yes</p>
-[22:15] <Ophite1> protocol would be the obvious way to go, yes.</p>
-[22:16] <jrand0m> hmm Ophite1? </p>
-[22:17] <jrand0m> (sorry, I'm sick again so might not be quite on top of my game today) </p>
-[22:17] <dm> how many LOC have you written jr?</p>
-[22:17] <TC> Ophite1, could i2p tunnel be modified to redirect?</p>
-[22:18] <TC> or could the browser do it on its own somehow?</p>
-[22:18] <jrand0m> dm> "find . -exec grep \\\; {} \; | wc -l" currently puts the sdk ~8kloc, the router ~11kloc </p>
-[22:18] <dm> okay thanks.</p>
-[22:19] <jrand0m> idn would want to support receiving requests from browsers. </p>
-[22:19] <Ophite1> would mean integrating idn into i2ptunnel. very ugly.</p>
-[22:19] <jrand0m> currently idn has a so-god-damn-easy api. </p>
-[22:19] <jrand0m> the api is the file system. </p>
-[22:19] <jrand0m> aka:  </p>
-[22:19] <jrand0m> command=get </p>
-[22:19] <jrand0m> key=zGb1tPM6ARNRTWZLCWK4XXco2Ngk8ccx-ciDUCom~9U </p>
-[22:19] <jrand0m> saveAs=testGetOutput.txt </p>
-[22:20] <jrand0m> place that in a file in a directory, and voila. </p>
-[22:20] <jrand0m> (that was the easiest possible for me to implement and test with.  certainly better ones can be found and made) </p>
-[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. </p>
-[22:22] <jrand0m> that'll include the first integration of the kademlia stuff, tunnel fixes, and i2cp updates. </p>
-[22:23] <jrand0m> ok, 2) transport futures </p>
-[22:23] <jrand0m> I don't like our tcp transport.  and our udp transport is disabled.  and our phttp transport is tweaky. </p>
-[22:23] * jrand0m would like to see the tcp transport replaced with tls / ssl / some-other-standard</p>
-[22:24] <Ophite1> link-level encryption is a requirement?</p>
-[22:24] <jrand0m> absolutely. </p>
-[22:25] <Ophite1> tls is _hell_ though. ask openssl.</p>
-[22:25] <tonious> ssh?</p>
-[22:25] <Ophite1> that, too.</p>
-[22:25] <jrand0m> yeah, I followed the nasty discussions on the cryptography list last month, with interest. </p>
-[22:25] <jrand0m> ssh is definitely a possibility. </p>
-[22:26] <jrand0m> safe, too, since we already essentially have the certificates (in the RouterInfo.publicKey) </p>
-[22:26] <Ophite1> but we're in java. we'd have to code it ourselves? :/</p>
-[22:26] <jrand0m> naw, there are ssl, tls, and ssh java libs </p>
-[22:26] *** Signoff: nickthief60934 (Ping timeout)</p>
-[22:26] <tonious> There's already at least one java ssh client.  Dunno about servers.</p>
-[22:26] <Ophite1> re: security of such libs, given numerous high profile holes in openssl, openssh, et al?</p>
-[22:27] <jrand0m> Ophite1> most likely better than custom built code. </p>
-[22:27] <jrand0m> not that I have any reason to think there are exploits in the tcp transport as written. </p>
-[22:27] <jrand0m> but it has not been reviewed. </p>
-[22:28] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[22:28] <jrand0m> in any case, updating the transports isn't really on deck until january (after the 0.3 release goes out) </p>
-[22:28] <jrand0m> but if anyone wants to look into it and do some research, that'd be great </p>
-[22:29] <TC> how many devs do we have activly coding?</p>
-[22:29] <dm> 1! :)</p>
-[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 </p>
-[22:29] <tonious> But he's got the strength of ten men....</p>
-[22:30] <jrand0m> mihi has been cleaning up some of my messes, thankfully :) </p>
-[22:30] <dm> haha, it's all jrandom :)</p>
-[22:30] <dm> nice way of saying "just me"</p>
-[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.</p>
-[22:31] <jrand0m> heh </p>
-[22:31] <Ophite1> people like that are very, very useful :)</p>
-[22:32] <jrand0m> quite </p>
-[22:32] <dm> "who's writing all these catch statements who do nothing ;)" -mihi</p>
-[22:32] <jrand0m> d'oooh </p>
-[22:33] <Ophite1> it's cause of reminders like that the code won't get as bad as freenet (we hope?) :)</p>
-[22:33] <jrand0m> if in 5 years any of the current i2p code is still in use, I'll be shocked. </p>
-[22:34] <jrand0m> (it had better be ported into finely tuned ASM code by then!) </p>
-[22:34] * Ophite1 makes his "java implementation is just a prototype" speech</p>
-[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 :)</p>
-[22:34] <TC> heh, comment it out and leave it in place</p>
-[22:35] <dm> is there a link to see the source on the web? not just the changes.</p>
-[22:35] <jrand0m> yes dm, http://i2p.dnsalias.net/ </p>
-[22:35] <dm> nm, found it.</p>
-[22:35] <jrand0m> :) </p>
-[22:35] <jrand0m> ok, 4) peer stats for selection </p>
-[22:36] <jrand0m> calling this a nebulus topic is one hell of an understatement. </p>
-[22:36] <jrand0m> doctoral theses could be written (and some have been) on how to choose what peers to use in an untrusted environment. </p>
-[22:36] <dm> public interface Job</p>
-[22:36] <dm> oops, meeting. Sorry didn't realize.</p>
-[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. </p>
-[22:37] <jrand0m> (thats the kademlia stuff) </p>
-[22:38] <jrand0m> the part thats left is the selection of peers to participate in tunnels, to route garlics, and to bounce replies through </p>
-[22:38] *** Signoff: dm (EOF From client)</p>
-[22:38] *** Signoff: TC (EOF From client)</p>
-[22:38] *** Signoff: leenookx (EOF From client)</p>
-[22:38] <jrand0m> what I'm thinking for 0.3 is just going to be a simple history of each peer, tested periodically </p>
-[22:39] *** TC (~TC@anon.iip) has joined channel #iip-dev</p>
-[22:39] *** leenookx (~leenookx@anon.iip) has joined channel #iip-dev</p>
-[22:39] <jrand0m> stats revolving around  latency and uptime </p>
-[22:39] *** Signoff: soros (Client exiting)</p>
-[22:39] <Ophite1> suggest you be wary of including accurate information about bandwidth usage and latency in that stats.</p>
-[22:40] <Ophite1> as per my drunken questions.</p>
-[22:40] <Ophite1> perhaps a more indirect route, but it's an area that needs very careful, well considered attention.</p>
-[22:40] <jrand0m> hmm, with the intent of keeping the accurate info unknown, or to defeat predictabilities? </p>
-[22:40] <jrand0m> right </p>
-[22:41] <jrand0m> this discussion is for a release that won't go out until at least jan 1 </p>
-[22:42] * jrand0m understands and agrees that we want to avoid the predictabilities</p>
-[22:42] <jrand0m> but I think we want to gather and use as accurate info as we can, /then/ adjust for entropy </p>
-[22:42] <Ophite1> mere entropy alone may not be enough.</p>
-[22:43] <Ophite1> but, I need more research on this :/</p>
-[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 </p>
-[22:44] <jrand0m> no rush, just wanted to plant the subject in the minds of those out there :) </p>
-[22:44] <jrand0m> ok, 4) apps </p>
-[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 :)</p>
-[22:45] <jrand0m> w00t :) </p>
-[22:45] <Ophite1> inclusion of accurate or accurate+some%entropy statistics may make some attacks work though.</p>
-[22:46] <TC> oh, before apps i have a question</p>
-[22:46] <jrand0m> well, its always easy enough to simply discard accurate info as necessary </p>
-[22:46] *** Signoff: nickthief60934 (Excess Flood)</p>
-[22:46] <jrand0m> sure tc, whats up? </p>
-[22:46] <jrand0m> (stats will also (hopefully) make it easier to debug the network's operation while in development) </p>
-[22:46] <TC> when are manditory minium hop counts (or something like it) going to start?></p>
-[22:47] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[22:47] <jrand0m> right now the default minimum tunnel length is one non-local hop </p>
-[22:47] *** dm (~sd@anon.iip) has joined channel #iip-dev</p>
-[22:47] * TC didnt know that</p>
-[22:48] <Ophite1> which is okay as long as the non-local hop doesn't KNOW it's the only non-local hop.</p>
-[22:48] <jrand0m> that will be up'ed to 2-4 once things are more reliable </p>
-[22:48] <jrand0m> right Ophite1 </p>
-[22:48] <Ophite1> still one better than a gnunet shortcut, so it's cool :)</p>
-[22:48] <TC> oh, and how do speed improvements look?</p>
-[22:48] * jrand0m is basing that 2-4 # on o-r comments</p>
-[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.</p>
-[22:49] <jrand0m> hmm, speed improvements will come through more reliable and faster peer selections, which is the 0.3 release </p>
-[22:49] <dm> jeez, I forgot how jr's code looks like it was written by a robot.</p>
-[22:49] <dm> Hmmm, that would explain a lot.</p>
-[22:50] <Ophite1> and through more scalable routing, which is next weeks' :)</p>
-[22:50] <jrand0m> heh sorry dm, I'll try to be more inconsistent ;) </p>
-[22:50] <Ophite1> (did I just mean discovery?)</p>
-[22:50] <jrand0m> right, its discovery, not routing, really. </p>
-[22:51] <jrand0m> i2p is scale free for normal comm. </p>
-[22:51] <jrand0m> (and o(log(n)) for discovery) </p>
-[22:51] <TC> i think your average ai who lives on the net would be pro i2p, what do you think dm?</p>
-[22:52] <dm> I think the average method size in this code is the smallest I've ever seen is what I think.</p>
-[22:53] <Ophite1> dm: clean. very good for a proto :)</p>
-[22:53] <dm> Do you comment as you go or do you go back and put those descriptions?</p>
-[22:53] <jrand0m> I comment when I get confused </p>
-[22:54] <jrand0m> (I really can't wait until collections are typesafe) </p>
-[22:54] <jrand0m> but, yeah, 4) apps :) </p>
-[22:54] <jrand0m> (unless anyone else has router / network questions?) </p>
-[22:55] <TC> pnope</p>
-[22:55] <jrand0m> ok, wiht isn't here, anyone else have any naming service thoughts / comments (mrecho?) </p>
-[22:55] <TC> a distributed naming server?</p>
-[22:56] <dm> is wiht ever here?</p>
-[22:56] <tonious> It could probably just sit on top of IDN.</p>
-[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 </p>
-[22:56] <TC> did co die?</p>
-[22:56] <jrand0m> exactly tonious </p>
-[22:57] <jrand0m> perhaps you're right, it could be an app that /uses/ idn, not just uses the code.  hmmm... </p>
-[22:57] <jrand0m> that'd be Good. </p>
-[22:57] <tonious> Mebbe have a key fingerprint associated in case of collisions.</p>
-[22:57] <jrand0m> naw, co/wiht is around every few days </p>
-[22:57] <tonious> Wouldn't even necessarily need a centralized CA?</p>
-[22:57] <jrand0m> we'd need a CA if nyms are unique. </p>
-[22:58] <Ophite1> The CA signing chain should elminiate collisions.</p>
-[22:58] <jrand0m> (and we need nyms to be unique to do naming, really) </p>
-[22:58] <Ophite1> of course this makes CA key very important.</p>
-[22:58] <TC> how about dys dns? can i make my host file redirect to a eepsite?</p>
-[22:59] <tonious> TC: Not really.  The OS doesn't even see i2p.</p>
-[22:59] <jrand0m> though we could have $nym.$ca be the thing looked up for </p>
-[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</p>
-[22:59] <jrand0m> right, though with tusko's ppp2p we can get i2p to IP mappings </p>
-[23:00] <tonious> I dunno.  The idea of a CA in an essentially distributed system disagrees with me.</p>
-[23:00] <tonious> Not bein' a developer though I'm not gonna make a fuss :)</p>
-[23:01] <TC> dns really isnt that importent</p>
-[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) </p>
-[23:01] <Ophite1> if you can think of a better way?</p>
-[23:02] <Nostradumbass> i have another question - its sort of spans the network-application area.</p>
-[23:02] <jrand0m> (thats really the degenerate case of a WoT) </p>
-[23:02] <Ophite1> what I said, sort of - get a root key to sign domains...</p>
-[23:02] <jrand0m> agreed tc </p>
-[23:02] <jrand0m> fire away Nostradumbass </p>
-[23:02] <Ophite1> someone gets com.i2p or nym.i2p...</p>
-[23:02] <Nostradumbass> has any thought been goven to guaranteed latency?</p>
-[23:02] <Ophite1> allow them to sign jrand0m.nym.i2p, or whatever.</p>
-[23:02] <Nostradumbass> i'm thinking of VoIP.</p>
-[23:03] <jrand0m> Ophite1> we wouldn't even need a .i2p key with that </p>
-[23:03] <tonious> Ophite1: What if the com ca gets taken out by an RIAA hitsquad or something?</p>
-[23:03] <jrand0m> Nostradumbass> you mean VoI2P?  :) </p>
-[23:03] <Ophite1> then once you're done, destroy the master CA.</p>
-[23:03] <Nostradumbass> yes</p>
-[23:03] <Ophite1> tonious: then there's still the others.</p>
-[23:04] <Ophite1> or some system that requires conspiring groups to get the nym signing key?</p>
-[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. </p>
-[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.</p>
-[23:04] <Ophite1> and a really freakin' big hashcash?</p>
-[23:04] <jrand0m> definitely Nostradumbass </p>
-[23:04] <tonious> Ophite1: Mebbe a majority signing protocol?</p>
-[23:04] *** Signoff: dm (Ping timeout)</p>
-[23:04] <jrand0m> tonious> majority is dangerous with sybil </p>
-[23:05] <Ophite1> tonious: otoh, it HAS to be non-repudiatory, and has to be able to guarantee non-collision.</p>
-[23:05] <Ophite1> and majority couldn't do that.</p>
-[23:05] <Ophite1> a majority of well known users maybe.</p>
-[23:05] <Ophite1> if it's a consolation, the internet has problems with this too (think Verisign).</p>
-[23:05] <jrand0m> right, WoT :) </p>
-[23:06] <Ophite1> but then WoT means that different people might have different ideas of who to trust, which violates non-collision maybe?</p>
-[23:06] *** thecrypto (~thecrypto@anon.iip) has joined channel #iip-dev</p>
-[23:06] <jrand0m> Nostradumbass> now if we could get some coders to work on a high performance RTSP over i2p tunnel... ;) </p>
-[23:06] <Ophite1> it's important, given the length of an "I2P address", but also hard.</p>
-[23:06] *** Drak0h (~Dr4k0h@anon.iip) has joined channel #iip-dev</p>
-[23:07] <Ophite1> Nostradumbass: not guaranteed.</p>
-[23:07] <TC> so how do we secure alias identification (important for commerce and seting up multiple eepsites)?</p>
-[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? </p>
-[23:07] <jrand0m> yes Nostradumbass, QoS can be done transparently within i2p, but unfortunately thats (I hate saying this) > 1.0 </p>
-[23:07] <tonious> Say we take root CAs out of it.  You generate your key and sign your aliases.</p>
-[23:08] *** Signoff: thecrypto (EOF From client)</p>
-[23:08] <Ophite1> Nostradumbass: also, troublesome re some potential attacks?</p>
-[23:08] <tonious> You also specify who's keys you trust, ala PGP.  I think redundancy is more important than collision.</p>
-[23:08] <Ophite1> tonious: so which jrand0m.nym.i2p did you want again?</p>
-[23:08] * jrand0m attacks the ns dht to get my nym back</p>
-[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.</p>
-[23:09] <Ophite1> and it would probably allow freenet-KSK-style collision wars.</p>
-[23:09] <jrand0m> right.  either the naming service has CA signed nyms, or it just distributes H(destination) --> destination mappings </p>
-[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?</p>
-[23:10] <jrand0m> (and H(destination) == 42 chars as opposed to ~500 chars for a destination) </p>
-[23:10] <Ophite1> tonious: if you're going to give it public keys, you might as well just sling around I2P addresses.</p>
-[23:10] <Ophite1> now that's an interesting ideal</p>
-[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.</p>
-[23:10] *** dm (~sd@anon.iip) has joined channel #iip-dev</p>
-[23:11] <Ophite1> I smell kademlia again.</p>
-[23:11] <jrand0m> :) </p>
-[23:11] <Ophite1> It can also be simply checked.</p>
-[23:11] <jrand0m> and there's existing code to reuse. </p>
-[23:11] <Ophite1> somehow, that makes sense. why weren't we doing this already? :)</p>
-[23:11] <jrand0m> because we want nyms </p>
-[23:12] <Ophite1> nyms for hosts?</p>
-[23:12] <jrand0m> but, I suppose, 42 chars is a good enough starting point </p>
-[23:12] <Ophite1> need a root CA for that :/</p>
-[23:12] <jrand0m> right </p>
-[23:12] <Ophite1> in the case where you don't want to trust a root ca?</p>
-[23:12] <Ophite1> 42 chars is short enough to paste.</p>
-[23:12] <jrand0m> you don't need a root CA, you can have a forest instead of a tree </p>
-[23:12] <Ophite1> 520 chars isn't :)</p>
-[23:12] <jrand0m> heh </p>
-[23:13] <Ophite1> but if you have a forest, how does anyone know which tree you're talking about?</p>
-[23:13] <Ophite1> you could slap a key in there, but then, ooh, we've got huge strings of random garbage again.</p>
-[23:13] <jrand0m> common suffix.  $nym.$ca </p>
-[23:13] <Ophite1> well, I'd like $nym.$ca.i2p :)</p>
-[23:13] <Ophite1> avoid confusion :)</p>
-[23:13] <jrand0m> right.  I mean, there are possible attacks.  I dunno.  I'm with TC though  </p>
-[23:13] <jrand0m> good 'nuff for me  </p>
-[23:14] <jrand0m> ok, /other/ apps :) </p>
-[23:14] <Ophite1> how do you know which ca is which?</p>
-[23:14] <Ophite1> you have a list? what signs the list?</p>
-[23:14] <jrand0m> i2pns.config </p>
-[23:14] *** Signoff: Drak0h (Ping timeout)</p>
-[23:14] <Ophite1> how're you going to get that?</p>
-[23:14] <TC> if i could make my own dns list, hostfile style i would be happy</p>
-[23:14] <jrand0m> on install </p>
-[23:15] <Ophite1> how are you going to verify those are the "right" keys?</p>
-[23:15] <Ophite1> ca substitution?</p>
-[23:15] <jrand0m> right tc, we can even do that without any distributed naming service </p>
-[23:15] <TC> because i say they are Ophite1</p>
-[23:15] <jrand0m> Ophite1> you aren't, any more than you're verifying that the source code is running the "real" i2p </p>
-[23:15] <TC> and if you trust me, you can download them off my eepsite</p>
-[23:16] <Ophite1> I suppose at the end of the day you can only reduce that to trust in one key being right, so :)</p>
-[23:16] <Ophite1> works for me, yeah.</p>
-[23:16] <Ophite1> as long as I get o1.i2p ;)</p>
-[23:16] <jrand0m> heh </p>
-[23:17] <tonious> Hmm.  Revised threshold scheme:  Each CA works the entire namespace, but a majority of CAs must agree before handing out subspace?</p>
-[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 </p>
-[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</p>
-[23:17] <Ophite1> tonious: back to majority again...</p>
-[23:17] <jrand0m> scary for attacks tonious </p>
-[23:17] <jrand0m> thats true TC </p>
-[23:17] <jrand0m> (and the value of such a community should not be underestimated) </p>
-[23:18] <Ophite1> tc: arpanet stylee?</p>
-[23:18] <tonious> Sigh. :)</p>
-[23:18] <Ophite1> I guess seeds have gotta come from somewhere, so yeah ;)</p>
-[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</p>
-[23:19] <jrand0m> sounds like that'd be a heavily retrieved key from idn :) </p>
-[23:19] <Ophite1> smells vaguely ca-like too :)</p>
-[23:19] <TC> you could even have a fight, with more then one file</p>
-[23:19] <Ophite1> the fidonet nodelist!</p>
-[23:19] <tonious> And in case of a netsplit there'd be multiple patchfiles.</p>
-[23:19] <Ophite1> ...doesn't scale.</p>
-[23:19] <jrand0m> with under a few hundred domains, its maintainable manually </p>
-[23:20] <TC> after a few hundred you go trusted</p>
-[23:20] <jrand0m> right Ophite1.  this would just be until we argue out the Right Way. </p>
-[23:20] <tonious> It might be enough to jumpstart a WoT.</p>
-[23:20] <jrand0m> (or we convince people that CAs aren't that bad ;) </p>
-[23:20] <jrand0m> true tonious </p>
-[23:20] <Ophite1> if you're trusting someone to agree that someone is someone else, that's a CA, not just a nodelist :)</p>
-[23:21] <tonious> Heh.  Sorry for bein' the skeptic.</p>
-[23:21] <TC> jrand0m, in the end i dont whant to be dependent on CA's</p>
-[23:21] <Ophite1> just allow people to give space below theirs...</p>
-[23:21] <Ophite1> castyle -- and those on the nodelist to be the cas.</p>
-[23:21] <Ophite1> course then it's all "which ca is jrand0m on?"</p>
-[23:21] <jrand0m> CA's aren't necessarily choke points.  if they're unsatisfactory, we replace them.   </p>
-[23:22] <tonious> Ophite1: I like that.</p>
-[23:22] <Ophite1> point. CA being crapped out would be Big Enough News for someone to simply replace them.</p>
-[23:22] <Ophite1> tonious: so is it slashdot.org or slashdot.com? goatse.cx? :)</p>
-[23:22] <dm> what does CA stand for? :)</p>
-[23:22] <Ophite1> certification authority.</p>
-[23:23] <dm> k, thanks.</p>
-[23:23] <tonious> Heh.  That's where your own WoT comes in, Ophite1.</p>
-[23:23] <Ophite1> tonious: yes, but I still have to see goatse once before I realise it's the wrong bloody one. :)</p>
-[23:23] <tonious> 'I trust Ophite1 not to show that horrible asshole, and he signed slashdot.org'</p>
-[23:23] <jrand0m> lol </p>
-[23:24] <Ophite1> so essentially you're trusting a limited subset of people, not to be horrible assholes.</p>
-[23:24] * jrand0m reserves the right to be an asshole at times</p>
-[23:24] <Ophite1> and to hand out domains to the rest.</p>
-[23:24] <Ophite1> at least one of which ought, really, to be a trent-style first-comes-first-served bot.</p>
-[23:24] <Ophite1> (with.. yes... hashcash.)</p>
-[23:24] <tonious> Yeah.  And there may be namespace collisions by people who are outside my WoT...</p>
-[23:25] <jrand0m> yup, and another should be something like thetower's tfee/subpage redirects </p>
-[23:25] <Ophite1> tonious: something that you can actually USE might be appreciated. it's just a naming system. :)</p>
-[23:25] <tonious> Heh.</p>
-[23:25] <Ophite1> the good thing about multiple cas is that they can do their own thing re: that kind of thing - different policies.</p>
-[23:26] *** Signoff: nickthief60934 (Ping timeout)</p>
-[23:26] <jrand0m> ok, other apps... </p>
-[23:26] <jrand0m> IM? </p>
-[23:26] <Ophite1> finally :)</p>
-[23:26] <Ophite1> signed nyms! :)</p>
-[23:26] <tonious> Sorry Ophite1 :)</p>
-[23:26] <jrand0m> !thwap Ophite1 </p>
-[23:27] <Ophite1> what, what are you all looking at? :)</p>
-[23:27] <Ophite1> yes, WoT would be appropriate for _that_ :)</p>
-[23:27] <dm> I think I remember who was doing IM... thecrypto?</p>
-[23:27] <Ophite1> in fact... elgamal 2048-bit... dsa 1024-bit... sha-256... sounds kind of familiar. openpgp?</p>
-[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 </p>
-[23:27] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[23:28] <tonious> I've managed to get SOAP going on mine, too.</p>
-[23:28] <jrand0m> yup dm </p>
-[23:28] <tonious> No useful apps, beyond 'Yep, it works' so far.</p>
-[23:28] <jrand0m> hehe </p>
-[23:29] *** Signoff: nickthief60934 (Excess Flood)</p>
-[23:29] <Nostradumbass> tonious: so SOAP over i2p = Black SOAP?</p>
-[23:29] * jrand0m really wants to get idn up and running so we can use i2p as an IP layer, not a TCP layer</p>
-[23:29] <jrand0m> lol Nostradumbass </p>
-[23:29] <Ophite1> nicename :)</p>
-[23:29] <tonious> Nostradumbass: Yep, you got it.</p>
-[23:30] <tonious> Now I can set up my own I2P casino. w00t!</p>
-[23:30] *** nickthief60934 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[23:30] <jrand0m> w33wt </p>
-[23:30] <jrand0m> ok, I think thats 'bout it for the apps </p>
-[23:30] <jrand0m> 5) ...? </p>
-[23:31] <jrand0m> hi </p>
-[23:31] <Ophite1> tonious: cool. we could use a few of those. donate a percentage to the i2p project? :)</p>
-[23:31] <TC> merchandising</p>
-[23:31] <tonious> Has anybody thought of a C implementation of I2P?</p>
-[23:31] <jrand0m> yeah, rent out colo boxes and run routers :) </p>
-[23:32] <jrand0m> tonious> lets wait until we get the router protocol implemented and thoroughly reviewed before porting ;) </p>
-[23:32] <tonious> Or anonymous colo: Behind an I2P router and no internet routing :)</p>
-[23:32] <Ophite1> merchandising = logo.</p>
-[23:32] <TC> stickers, t-shirts, hats, we need the logo</p>
-[23:32] <Ophite1> tonious: after it's working and anonymous and stuff? of course.</p>
-[23:32] <tonious> Yeah, but I'm still running my P2 and I'm a poor guy.</p>
-[23:32] <tonious> :(</p>
-[23:32] <Ophite1> i2p needs a good logo.</p>
-[23:32] <Nostradumbass> yes</p>
-[23:32] <Ophite1> I mean, the internet doesn't have a logo, but that's just bad marketing. :)</p>
-[23:32] <dm> I like the one on the WIKI.</p>
-[23:32] <TC> also, each made-for-i2p program needs its own tweeked version, or take off of the logo</p>
-[23:32] <jrand0m> how about a transparent logo... it'd, be, like, everywhere, dood </p>
-[23:33] <Ophite1> an invisible logo. heh.</p>
-[23:33] <tonious> A 1 pixel by 1 pixel blank gif?</p>
-[23:33] <jrand0m> definnitely </p>
-[23:33] <Ophite1> tonious: we'd be sued for copyright infringment? :)</p>
-[23:33] <tonious> Ha!</p>
-[23:33] <Ophite1> ("Hey, that's OUR blank gif!")</p>
-[23:33] <jrand0m> lol </p>
-[23:33] <Ophite1> Hey, if John Cage can do it...</p>
-[23:33] <tonious> So we leave our names in the comments field :)</p>
-[23:33] <Nostradumbass> Ophite1: how about a stream roller paving over the Internet?</p>
-[23:33] <jrand0m> heh we're just rendering his audio </p>
-[23:34] <Ophite1> that one on the bottom looks the best imho.</p>
-[23:34] <tonious> I like the one on the top.  It's simple.  Like me.</p>
-[23:34] <Ophite1> with the arc design.</p>
-[23:35] <Ophite1> something that is small, very simple, and above all would work well as an icon, or in the system tray :)</p>
-[23:35] <Ophite1> and yes, which can be customised and used as a basis for logos of apps.</p>
-[23:35] <jrand0m> right </p>
-[23:35] <dm> How about a black circle with white fill.</p>
-[23:35] <Ophite1> that arc would be a good start (colour changes?)</p>
-[23:35] <dm> or a triangle, maybe a square!</p>
-[23:35] <dm> a parallelogram!</p>
-[23:37] <tonious> Heh.  Open up a cafepress store...</p>
-[23:37] <Ophite1> god no, not cafepress.</p>
-[23:37] <dm> a white cloud!</p>
-[23:37] <Ophite1> we demand class.   ... thinkgeek. ;-)</p>
-[23:37] <dm> little fluffy cloud.</p>
-[23:38] <TC> it would look toomuch like a cumpuddle in minature</p>
-[23:38] * jrand0m associates clouds with the sky, thankyouverymuch</p>
-[23:38] <tonious> Ophite1: First we've gotta convince 'em that we're whitehat.</p>
-[23:39] <TC> no, lets be black hat</p>
-[23:39] <jrand0m> tonious> can militant anarchists be whitehats too? </p>
-[23:39] * TC doesnt like ppl in hats</p>
-[23:39] <tonious> Dunno.</p>
-[23:39] * tonious wears a grey fedora FWIW.</p>
-[23:39] <Nostradumbass> how about a white and a black hat?</p>
-[23:39] <TC> and modulus would say somthing about class distinction or something</p>
-[23:40] <dm> a small picture of uncle sam's face?</p>
-[23:40] <TC> checkered hat?</p>
-[23:40] <jrand0m> heh tc </p>
-[23:40] <Nostradumbass> or white and a black wizzard hats</p>
-[23:40] <Ophite1> I am NOT a white hat. How dare you insinuate that. I want an apology.</p>
-[23:41] <TC> or a black dunce hat</p>
-[23:41] <jrand0m> well, anyway... </p>
-[23:42] <tonious> "i2p inside"?</p>
-[23:42] <jrand0m> heh </p>
-[23:42] <dm> I, too, pee...</p>
-[23:42] <jrand0m> dm> on a calvin sticker! </p>
-[23:42] <Ophite1> "i2p ... somewhere"</p>
-[23:42] <TC> so, logo ppl, come on!  so can nop set us up a i2p cafepress site?</p>
-[23:43] * jrand0m repeats the mantra No PR until its ready.</p>
-[23:43] <Nostradumbass> dm: yeah, make it a "Concentration" style chrade logo-gram.</p>
-[23:43] <Nostradumbass> <eye> 2 and a pee-ing penis.</p>
-[23:44] <dm> Let's set a date.</p>
-[23:44] <jrand0m> heh, yeah, and you'll have your mother click on that icon? </p>
-[23:44] <dm> March 1st.</p>
-[23:44] <Nostradumbass> grab it, in fact :)</p>
-[23:44] <tonious> My mother disapproves of encryption :)</p>
-[23:44] *** UserX (~User@anon.iip) has joined channel #iip-dev</p>
-[23:44] <dm> Slashdot article! No matter how far (or not) jrand0m has gotten!</p>
-[23:44] <dm> Let's pile on the pressure.</p>
-[23:44] <Ophite1> nooooooo.</p>
-[23:44] <Ophite1> not yet!</p>
-[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 </p>
-[23:45] * dm slaps Ophite1</p>
-[23:45] <dm> i said march 1st.</p>
-[23:45] <Ophite1> the appropriate time to promote is when we have a cool shiny thing to wave at them.</p>
-[23:45] <Nostradumbass> please, no slashdot till the network is ready for the onslaught.</p>
-[23:45] <jrand0m> right </p>
-[23:45] <dm> I'm good, what can I say.</p>
-[23:45] <Ophite1> I call launch date April 4th.</p>
-[23:45] <Ophite1> 04/04/04 ;)</p>
-[23:45] <jrand0m> no PR until AFTER 1.0 comes out. </p>
-[23:45] <Nostradumbass> Mojo was almost destroyed by /.</p>
-[23:46] <dm> no, none of this rational thinking. March 1st, end of story.</p>
-[23:46] <jrand0m> ooOOo Ophite1 </p>
-[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</p>
-[23:46] <Ophite1> no, don't do that. malda doesn't give a shit, and he'll post THAT :)</p>
-[23:46] <jrand0m> heh </p>
-[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"</p>
-[23:47] <jrand0m> anyway, as things progress, http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap will be updated </p>
-[23:48] <dm> time to pack.</p>
-[23:49] <jrand0m> (and some day I'm going to take a week off and go snowboarding) </p>
-[23:49] *** soros (~soros@anon.iip) has joined channel #iip-dev</p>
-[23:49] <jrand0m> yeah, we're about the 2hour mark. </p>
-[23:49] <jrand0m> time to... </p>
-[23:49] * jrand0m *baf*'s the meeting closed.</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/66.rst b/i2p2www/meetings/66.rst
new file mode 100644
index 00000000..107bd0e3
--- /dev/null
+++ b/i2p2www/meetings/66.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, November 26, 2003 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/68.log b/i2p2www/meetings/68.log
index 74b73af0..4f9acffa 100644
--- a/i2p2www/meetings/68.log
+++ b/i2p2www/meetings/68.log
@@ -1,281 +1,274 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 68{% endblock %}
-{% block content %}<h3>Tuesday, December 9, 2003 22:00:00 CET</h3>
-<div class="irclog">
-[22:02] <jrand0m> 0) welcome to $num </p>
-[22:02] <jrand0m> 1) iip status </p>
-[22:02] <jrand0m> 2) kademlia stuff + idn </p>
-[22:02] <jrand0m> 3) peer profiling stuff </p>
-[22:02] <jrand0m> 4) i2p services  </p>
-[22:02] <jrand0m> 5) stuff </p>
-[22:02] <jrand0m> 0) welcome  </p>
-[22:02] <jrand0m> hi </p>
-[22:03] <jrand0m> this is meeting 67 or 68...  </p>
-[22:03] <jrand0m> 1) iip status </p>
-[22:03] <jrand0m> I dunno.  anyone know what the situation has been as of late? </p>
-[22:04] <jrand0m> the iip devs aren't here, so... dunno. </p>
-[22:04] <jrand0m> [ping] </p>
-[22:04] <jrand0m> (last week I typed for probably 10 minutes before my client pinged me out...) </p>
-[22:05] <jrand0m> (i'm not going to type anything else until I get a p0ng, damnit ;) </p>
-[22:05] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev</p>
-[22:05] <jrand0m> 'lo Nostradumbass </p>
-[22:06] <Nostradumbass> hi :)</p>
-[22:06] <jrand0m> ok cool, so I haven't pinged out, people are just lurking.  cool :) </p>
-[22:06] * jrand0m hops on to the next agenda item</p>
-[22:06] <Nostradumbass> how's i2p coming?</p>
-[22:06] <Nostradumbass> sorry?</p>
-[22:06] <jrand0m> good lead in ;) </p>
-[22:07] <jrand0m> agenda item 3) i2p 0.2.3 status :) </p>
-[22:07] *** nerox (~nerox@anon.iip) has joined channel #iip-dev</p>
-[22:07] <jrand0m> there's been a lot of progress, even though I'm offline.  commited a truckload of code a few hours ago </p>
-[22:07] <jrand0m> that includes an implementation of the kademlia netDb </p>
-[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) </p>
-[22:08] <jrand0m> there have been a few more variations on the kademlia proto though to make things more relevent for i2p </p>
-[22:09] <jrand0m> we will always have a very, very, /very/ sparse kademlia tree. </p>
-[22:09] <jrand0m> 2^256 possible slots, and 1-10 values per peer in the network. </p>
-[22:09] <jrand0m> so, thinking insanely overzealous, we still wont be using jack shit, and everything will be in the furthest out kbucket </p>
-[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 </p>
-[22:10] <jrand0m> idn, however, is dead in the water. </p>
-[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 </p>
-[22:11] <jrand0m> and has been promptly abandonded. </p>
-[22:11] <jrand0m> idn is still generally a good idea, but I'm not going to spend my i2p dev time working on it </p>
-[22:12] *** tusko (~tusko@anon.iip) has joined channel #iip-dev</p>
-[22:12] <jrand0m> but part of the 0.2.3 changes include a dramatic revamp of how we choose peers and organize router stats </p>
-[22:12] <jrand0m> heya tusko </p>
-[22:12] <jrand0m> that brings us to agenda item 3) peer profiling </p>
-[22:12] <jrand0m> I've been pretty silly...and finally did some of the math </p>
-[22:13] <jrand0m> the stats being gathered now are immense. </p>
-[22:13] <jrand0m> about 6000 data points /per peer/ </p>
-[22:13] <duck> what is peer profiling?</p>
-[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 </p>
-[22:13] <duck> ah</p>
-[22:13] <jrand0m> (aka fast routers, reliable routers, etc) </p>
-[22:13] <duck> the process that eats up my memory :)</p>
-[22:14] <jrand0m> heh actually that part isn't toooo bad </p>
-[22:14] <jrand0m> though 6000 data points won't scale. </p>
-[22:14] <jrand0m> 1000 routers @ 6000 data points each @ 4 bytes / data point = 24Mb </p>
-[22:15] <jrand0m> though keeping detailed stats on a few hundred peers is probably fine, even as the net grows beyond that </p>
-[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. </p>
-[22:16] <jrand0m> we could probably get away in the long term with just keeping track of a hundred or so peers. </p>
-[22:16] <jrand0m> but, for now, I'm going to say fuckit. </p>
-[22:16] <jrand0m> keep stats on all peers </p>
-[22:16] <duck> ping</p>
-[22:16] <jrand0m> p0ng </p>
-[22:17] <duck> will it try to learn about all peers?</p>
-[22:17] <jrand0m> right now, yes </p>
-[22:17] <duck> oh wait, your last lines covered that</p>
-[22:17] <jrand0m> we also have some code for coallescing and running calculations on the peer profiles </p>
-[22:18] <jrand0m> so one of those calculators will determine what peers to drop </p>
-[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 </p>
-[22:19] <jrand0m> (you'll notice lots of 0s :) </p>
-[22:19] <jrand0m> I've written up a rough manifesto for peer selection and profiling, but need to get that onto the wiki </p>
-[22:20] <jrand0m> but thats all 0.3 stuff, really.  0.2.3 just uses a little of it </p>
-[22:21] <jrand0m> ok, thats it for the peer profiling.  lots more later, just giving a lil view into whats up </p>
-[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) </p>
-[22:22] <jrand0m> ok, 4) i2p services </p>
-[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 :) </p>
-[22:23] <jrand0m> there's also duck's jabber server, which works fairly easily with the instructions posted to tc's board </p>
-[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) </p>
-[22:24] <jrand0m> the squid proxy is generally offline, since I'm offline too much to babysit my kaffe routers :/ </p>
-[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 </p>
-[22:25] <jrand0m> what services would be cool to show up next? </p>
-[22:25] <duck> I did try to run an ircd over i2ptunnel</p>
-[22:25] <duck> but before it got the full MOTD after logging in, I got ping timeouted already</p>
-[22:26] <jrand0m> d'oh </p>
-[22:26] <duck> and that was on the same router</p>
-[22:26] <duck> so in the wild performance will be even worse</p>
-[22:26] <jrand0m> on the local router it pinged out?! </p>
-[22:26] <jrand0m> local router should never ping anything out </p>
-[22:26] <jrand0m> oh, except for that race bug </p>
-[22:26] <jrand0m> (which is probably what it was, since it was local and the race is faster there) </p>
-[22:26] <duck> irc client pinged out for not responding in time</p>
-[22:27] <duck> I'll retry with 0.2.3</p>
-[22:27] <jrand0m> word </p>
-[22:27] <duck> though jabber is nice for now</p>
-[22:27] <jrand0m> totally </p>
-[22:27] <jrand0m> and long term, irc is not the way to go </p>
-[22:27] <duck> tc, jrandom and me are there to chat with!</p>
-[22:27] <jrand0m> hehe :) </p>
-[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 </p>
-[22:28] <jrand0m> (aka iip 2.0) </p>
-[22:28] <jrand0m> now would be a nice time for userx to come back into the fold ;) </p>
-[22:29] * jrand0m stops holding breath</p>
-[22:29] <jrand0m> an nntp server would /also/ really really rule. </p>
-[22:29] <duck> I'll try that tomorrow</p>
-[22:29] <jrand0m> r0x0r </p>
-[22:30] <duck> jabber is really nice to run other things over</p>
-[22:30] <duck> check out the jabber rpc specs</p>
-[22:30] <duck> (Link: http://www.pipetree.com/jabber/jrpc/)http://www.pipetree.com/jabber/jrpc/</p>
-[22:30] <duck> other services?</p>
-[22:30] <jrand0m> thats interesting - doing jabber as a naming service, essentially </p>
-[22:31] <duck> you mean:</p>
-[22:31] <jrand0m> there will always be more services to add - with mail (usenet), chat (jabber) and publishing/browsing (eepsites), there's good coverage </p>
-[22:31] <duck> name server has a jabber client through which you can register names (provided token)</p>
-[22:31] <duck> also use it to query?</p>
-[22:31] <jrand0m> naw </p>
-[22:32] <jrand0m> jabber's registry being the naming service </p>
-[22:32] <duck> ok</p>
-[22:32] <jrand0m> its centralized but it works </p>
-[22:32] <jrand0m> just like hosts.txt :) </p>
-[22:33] <duck> are there mail solutions that are better suited for there environments than smtp and pop/imap ?</p>
-[22:33] <jrand0m> thats a really good question </p>
-[22:33] <duck> cause I dont think that it will just work when you hook up mail servers</p>
-[22:34] <jrand0m> yeah, it'd probably need either a gateway (ala freemail) or the naming service doing some interesting tap dancing </p>
-[22:34] <jrand0m> or it reverts back to centralized single POP3/IMAP server with everyone on the same server </p>
-[22:35] <duck> I spoke with aum (author of freemail) yesterday</p>
-[22:35] <duck> he was talking about reimplementing fred in python</p>
-[22:35] <jrand0m> lol nice </p>
-[22:35] *** mrflibble (mrflibble@anon.iip) has joined channel #iip-dev</p>
-[22:35] <duck> so I did suggest him to work on the python routers for i2p instead</p>
-[22:35] <jrand0m> ooh that would TOTALLY rule! </p>
-[22:35] <duck> then he got totally upset about the pdf documents</p>
-[22:36] <jrand0m> hey, if he wants the openOffice originals, or even a txt export I'll export </p>
-[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</p>
-[22:36] <duck> well, you were a fuckhead for not doing a html export or something</p>
-[22:36] <jrand0m> naw, I tried that ;) </p>
-[22:36] <duck> I lost my patience and told him to talk to you</p>
-[22:36] <jrand0m> the openOffice html export SUCKS </p>
-[22:37] <duck> hm</p>
-[22:37] <mrflibble> true jr</p>
-[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. </p>
-[22:37] <duck> wiki has most info though</p>
-[22:37] <jrand0m> exactly </p>
-[22:37] <mrflibble> i tried using that for that kevin mitnick book. it was worse than ms office</p>
-[22:37] <duck> oh well</p>
-[22:37] <jrand0m> zactly. </p>
-[22:37] <duck> he might appear here once</p>
-[22:37] <jrand0m> that'd be awesome </p>
-[22:38] <duck> but maybe it is better with his attitude to join the freenet gang</p>
-[22:38] <duck> ...</p>
-[22:38] <jrand0m> well, effort on freenet is always a good thing </p>
-[22:38] * duck goes back to beeing friendly</p>
-[22:38] <jrand0m> :) </p>
-[22:38] <duck> aums work rocks</p>
-[22:38] <duck> hopefully he'll rock on i2p</p>
-[22:39] <jrand0m> yeah whenever someone talked about searching on freenet, I always just said "well just do a McNabb" </p>
-[22:39] <jrand0m> we need the help, certainly </p>
-[22:39] <duck> which brings me to the following question:</p>
-[22:39] <duck> are the changes to I2P that you do specced?</p>
-[22:39] <duck> or is the java source the documentation for the latest info</p>
-[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 </p>
-[22:40] <jrand0m> feb is doc-month for jrandom. </p>
-[22:40] <jrand0m> (and qa, and bugfixing) </p>
-[22:41] <jrand0m> ((and benders ;)) </p>
-[22:41] <jrand0m> the specs are still pretty much correct, there are just more details. </p>
-[22:41] <duck> awesome</p>
-[22:41] <jrand0m> but the datastructures have had more changes </p>
-[22:42] <jrand0m> ok, anything else for services?   </p>
-[22:43] <jrand0m> ok, 5) stuff </p>
-[22:43] <jrand0m> hi </p>
-[22:43] <duck> hi!</p>
-[22:43] <jrand0m> how's tricks? </p>
-[22:43] <jrand0m> [any questions / thoughts / issues / etc go here] </p>
-[22:43] <duck> the base64 tricks should be added to the i2ptricks pages</p>
-[22:44] <jrand0m> ooh good point </p>
-[22:44] <duck> might be some other tricks too that I dont know yet</p>
-[22:44] <duck> will grep the sources for 'main'</p>
-[22:44] <jrand0m> I feel guilty for not having the installer let someoene automatically fetch hosts.txt and reseed </p>
-[22:44] <jrand0m> lol </p>
-[22:44] <jrand0m> there are lots and lots of main() methods, but they're mostly test functions </p>
-[22:45] <jrand0m> oh! </p>
-[22:45] <jrand0m> one thing.  DONT run the current code from cvs and expect it to work with normal routers. </p>
-[22:45] *** joda (--@anon.iip) has joined channel #iip-dev</p>
-[22:45] <joda> hi</p>
-[22:45] <jrand0m> the db messages changed :) </p>
-[22:45] <jrand0m> hi joda </p>
-[22:45] <joda> sorry, if I interrupt something</p>
-[22:45] <duck> I got a bit upset that I couldnt get cvs to work</p>
-[22:45] <duck> but then I did remember that this isnt freenet</p>
-[22:45] <joda> I was just wondering what happend to "anonymail" ?</p>
-[22:46] <duck> so you dont need latest cvs to be able to use it</p>
-[22:46] <jrand0m> joda> the user who runs it doesn't seem to be online at the moment.  should be back soon </p>
-[22:46] <jrand0m> hehe duck - did it fail for you today after I committed, or do you mean from before today? </p>
-[22:46] <duck> last week somewhere</p>
-[22:46] <joda> jrand> thx :)</p>
-[22:46] <joda> cu :)</p>
-[22:46] <jrand0m> ah 'k duck </p>
-[22:46] <jrand0m> l8r joda </p>
-[22:47] <jrand0m> yeah, I only endorse running the released code </p>
-[22:47] <duck> will 0.2.3 put the version files in a directory? :)</p>
-[22:47] <jrand0m> 0.2.3 gets rid of the version files :) </p>
-[22:47] <jrand0m> (lots and lots and lots of changes) </p>
-[22:47] <jrand0m> but that means 0.2.3 (and beyond) will require g enerally correct clocks </p>
-[22:48] <jrand0m> (current Router.CLOCK_FUDGE_FACTOR = 30 minutes) </p>
-[22:48] <duck> what will the fudge facter be for 0.2.3?</p>
-[22:48] <jrand0m> probably the same </p>
-[22:49] *** joda has left #iip-dev</p>
-[22:49] <duck> oh, current = your code</p>
-[22:49] <jrand0m> that time will be used to expire db entries </p>
-[22:49] <duck> k</p>
-[22:49] <jrand0m> ah, right, yeah :) </p>
-[22:49] <jrand0m> (in 0.2.2 that clock_fudge_factor is spread out throughout half a dozen files) </p>
-[22:49] <duck> maybe the installer could be a bit more userfriendly</p>
-[22:49] <duck> as in less questions</p>
-[22:49] *** Signoff: nickthief66282 (Excess Flood)</p>
-[22:50] <duck> default phttp urls included, no bandwidth limiting etc</p>
-[22:50] <jrand0m> I guess we could autoguess random ports too </p>
-[22:50] <jrand0m> you're right </p>
-[22:50] <jrand0m> want commit privs?  :) </p>
-[22:50] *** Signoff: nerox (EOF From client)</p>
-[22:50] <jrand0m> (if not I can update it for 0.2.3) </p>
-[22:51] <duck> an argument against it can be that users will take settings too easily for granted</p>
-[22:51] <duck> and everybody uses the same phttp relay</p>
-[22:51] *** nickthief24373 (~chatzilla@anon.iip) has joined channel #iip-dev</p>
-[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 </p>
-[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 </p>
-[22:52] <jrand0m> (though thats because i know what all the text says and didn't read it...) </p>
-[22:52] <duck> I dont like the long keys</p>
-[22:53] <duck> especially not if you have to copy&paste them</p>
-[22:53] <duck> better use them as file</p>
-[22:53] <jrand0m> hmm? </p>
-[22:53] <duck> but distributing the binary files are a pain</p>
-[22:53] <duck> so you have to do the base64 trick..</p>
-[22:53] <duck> could the i2ptunnel read base64 destination keys too?</p>
-[22:53] <duck> from a file that is</p>
-[22:53] <jrand0m> I was just typing that ;) </p>
-[22:53] <jrand0m> yeah, that wouldnt be much work </p>
-[22:54] <jrand0m> perhaps even 1 line </p>
-[22:54] <duck> also, what about armouring?</p>
-[22:54] <duck> with a header&footer</p>
-[22:54] <duck> like pgp etc</p>
-[22:55] <jrand0m> true, it would be useful to have that sort of validation </p>
-[22:55] <duck> ofcourse that is a gadget</p>
-[22:55] <duck> but it could be helpful for those who want to use the tunnel</p>
-[22:55] <jrand0m> though the Destination structure itself is pretty picky </p>
-[22:55] <jrand0m> but you're right, a raw base64 isn't the most intuitive or safe thing to pass around </p>
-[22:56] <jrand0m> we need a bugzilla </p>
-[22:56] <jrand0m> so things like this can get posted as todo </p>
-[22:56] <jrand0m> i'd move off my palm's todo list for that </p>
-[22:56] <duck> bugzilla has nazi registration requirements</p>
-[22:56] <duck> with emails etc..</p>
-[22:56] <jrand0m> true </p>
-[22:57] <duck> but better as nothing</p>
-[22:57] <duck> other bugtrackers all have their shortcomings</p>
-[22:57] <jrand0m> yeah, every company i've worked at has pretty much ended building their own </p>
-[22:58] <jrand0m> we'll see.  we need a bugtracker by the time we start doing full on qa (once 0.3 comes out) </p>
-[22:58] <jrand0m> so we've got a few weeks ;) </p>
-[22:58] <jrand0m> but if someone did some research and found a really nice one, that'd be great </p>
-[22:59] <jrand0m> [not you specifically duck, anyone who's reading these meeting logs at home ;)] </p>
-[22:59] <duck> so far phpBugTrackers has been okay for me</p>
-[22:59] <jrand0m> hmm haven't used that </p>
-[22:59] <duck> yes, I am not talking to jrandom either</p>
-[22:59] <jrand0m> lol </p>
-[22:59] <duck> but to the group of I2P code developers :)</p>
-[22:59] * jrand0m is actually 12 people acting under a single nym</p>
-[23:00] <jrand0m> ok, 1 hour, on the dot </p>
-[23:00] <jrand0m> anyone else have anything before I get the *baf*er out? </p>
-[23:01] * duck demands 1 more minute</p>
-[23:01] <duck> since we did start on 21:02</p>
-[23:01] <jrand0m> yeah yeah </p>
-[23:01] <jrand0m> la la la </p>
-[23:01] <jrand0m> what should i have for dinner? </p>
-[23:01] <jrand0m> there's a nice falafel place next door... </p>
-[23:01] <jrand0m> had gnocci for lunch too </p>
-[23:01] <jrand0m> hmm... </p>
-[23:01] <jrand0m> maybe a liquid dinner </p>
-[23:02] <duck> soup?</p>
-[23:02] <jrand0m> ooOooo whiskey soup! </p>
-[23:02] * jrand0m *baf*'s the meeting closed on that note</p>
-
-</div>
-{% endblock %}
\ No newline at end of file
+[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/68.rst b/i2p2www/meetings/68.rst
new file mode 100644
index 00000000..ec870eb3
--- /dev/null
+++ b/i2p2www/meetings/68.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 9, 2003 @ 22:00 CET
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/69.log b/i2p2www/meetings/69.log
index 1c9c109f..d837d72d 100644
--- a/i2p2www/meetings/69.log
+++ b/i2p2www/meetings/69.log
@@ -1,250 +1,244 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 69{% endblock %}
-{% block content %}<h3>Tuesday, December 16, 2003 22:00:00 CET</h3>
-<div class="irclog">
-[22:04] <jrand0m> 0) hi </p>
-[22:04] <jrand0m> 1) iip </p>
-[22:04] <jrand0m> 2) 0.2.3 & 0.2.3.1 </p>
-[22:04] <jrand0m> 3) hi </p>
-[22:04] <jrand0m> 0) hi </p>
-[22:04] <jrand0m> welcome to the ... something'th meeting </p>
-[22:05] <jrand0m> (68?  69?) </p>
-[22:05] <MrEcho> damm its 1pm here</p>
-[22:05] <jrand0m> GMT-8? </p>
-[22:05] <duck> 69</p>
-[22:05] <jrand0m> h0t. </p>
-[22:06] <jrand0m> ok, 1) iip </p>
-[22:06] *** Signoff: tusko (EOF From client)</p>
-[22:06] * MrEcho compiles a kernel for the meeting</p>
-[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. </p>
-[22:06] <jrand0m> anyone have any more info they want to share with the class? </p>
-[22:06] *** mids (mids@anon.iip) has joined channel #iip-dev</p>
-[22:06] <MrEcho> no info from nop</p>
-[22:07] <mids> this morning I was told that I could start Trent again</p>
-[22:07] <mids> (I did do so already last night)</p>
-[22:07] <jrand0m> wikked </p>
-[22:07] <jrand0m> gracias </p>
-[22:07] <mids> so that indicates that nop believes that IIP is more stable again</p>
-[22:07] <mids> if that is worth anything...</p>
-[22:07] <mids> *cough*</p>
-[22:07] <jrand0m> ok cool </p>
-[22:08] <jrand0m> [woot roommate just handed me a glass of wine for the meeting] </p>
-[22:08] <MrEcho> lol</p>
-[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 </p>
-[22:09] <jrand0m> 2) 0.2.3 & 0.2.3.1 </p>
-[22:09] <mids> what specific question do you want to ask him?</p>
-[22:09] <protocol> when is the meeting</p>
-[22:09] <jrand0m> specific question> when will he make an official announcement describing the past problems and how the future ones will be addressed? </p>
-[22:09] <jrand0m> the meeting is now </p>
-[22:10] <jrand0m> (aka, at what point should we explore non-iip means of communication) </p>
-[22:10] <mids> if I get an answer I'll let you know.</p>
-[22:10] <jrand0m> thanks </p>
-[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. </p>
-[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 </p>
-[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 </p>
-[22:12] <MrEcho> what about client connect times to routers?</p>
-[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</p>
-[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. </p>
-[22:13] <MrEcho> ok cool</p>
-[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. </p>
-[22:13] <MrEcho> its hard to work on the dns with that damm bug .. i have to restrt the dns server alot</p>
-[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? </p>
-[22:15] <MrEcho> no</p>
-[22:15] <jrand0m> could you send me debug logs for that? </p>
-[22:15] <MrEcho> already deleted</p>
-[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. </p>
-[22:16] <MrEcho> its doing the samething as before .. client gets msg that its sent .. but never makes it to the client</p>
-[22:16] <MrEcho> to the other client</p>
-[22:17] <MrEcho> ya .. ill see what i can do</p>
-[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 </p>
-[22:17] <jrand0m> gracias </p>
-[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 </p>
-[22:18] <protocol> shine on you crazy diamond</p>
-[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?</p>
-[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. </p>
-[22:20] * FireRabbit will be an insane vollunteer</p>
-[22:20] <jrand0m> right now i've got to battle with kaffe & jetty for updates on i2p.dnsalias.net </p>
-[22:20] <duck> what species?</p>
-[22:20] * MrEcho already is</p>
-[22:20] *** tusko (~tusko@anon.iip) has joined channel #iip-dev</p>
-[22:20] <jrand0m> y'all already are insane (and very helpful) volunteers :) </p>
-[22:20] <FireRabbit> thank you!</p>
-[22:20] <FireRabbit> :)</p>
-[22:21] *** TC (~TC@anon.iip) has joined channel #iip-dev</p>
-[22:21] <jrand0m> hey if it aint tc </p>
-[22:21] * MrEcho wips TC .. your late</p>
-[22:21] <TC> hey</p>
-[22:21] <TC> we back up and running?</p>
-[22:21] <MrEcho> ya i can type todya...</p>
-[22:22] <jrand0m> iip seems up... </p>
-[22:22] <TC> yay</p>
-[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) </p>
-[22:23] *** wiht (anon@anon.iip) has joined channel #iip-dev</p>
-[22:23] <TC> what was the cause?</p>
-[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</p>
-[22:23] *** Signoff: wiht ((null))</p>
-[22:23] <TC> FireRabbit, how much memmory do you have?</p>
-[22:24] <FireRabbit> that computer has 128 i believe</p>
-[22:24] <FireRabbit> you think it could be the paging file?</p>
-[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 </p>
-[22:24] <TC> because i have 512 and i2p gave me an 'out of memmory' error last night</p>
-[22:24] <jrand0m> really?  shite </p>
-[22:24] <FireRabbit> oh, intresting</p>
-[22:25] <MrEcho> wow</p>
-[22:25] <jrand0m> yeah, thats #3 on the list of bugs left to crack (though thats not a 0.2.3.1 showstopper) </p>
-[22:25] <jrand0m> OOMs don't use all 512 </p>
-[22:25] <TC> but it seems to be running fine now</p>
-[22:25] <jrand0m> they only use what java's given (e.g. 64M) </p>
-[22:26] <TC> yes</p>
-[22:26] <duck> Memory: In use: 8187KB</p>
-[22:26] <jrand0m> word </p>
-[22:26] <duck> that is not much!</p>
-[22:26] <duck> yet</p>
-[22:26] <MrEcho> Memory: In use: 8908KB Free: 4088KB </p>
-[22:27] <jrand0m> right, there is something growing in there, i hope to have it tracked down by 0.3  </p>
-[22:27] <jrand0m> cool, free means it used to use 12.9M, now it only uses 8.9 </p>
-[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</p>
-[22:27] <jrand0m> yeah, kaffe does that for me tc </p>
-[22:28] <jrand0m> ok, in any case, people should subscribe to the i2p mailing list </p>
-[22:28] * FireRabbit is thinking when he gets home today hes going to rewrite the meshwork lib since it has some problems</p>
-[22:28] <FireRabbit> sigh</p>
-[22:28] <jrand0m> ((Link: http://i2p.dnsalias.net/pipermail/i2p/)http://i2p.dnsalias.net/pipermail/i2p/) </p>
-[22:28] <jrand0m> d'oh FireRabbit </p>
-[22:28] <FireRabbit> this thing is never going to gte done</p>
-[22:28] <TC> yah, and memory is no biggy for the most part</p>
-[22:28] <jrand0m> heh, no project goes as easily as one hopes </p>
-[22:28] <FireRabbit> nope</p>
-[22:28] <protocol> jrand0m: the maillist triggers Yahoo! spam protection</p>
-[22:28] <protocol> just a heads up</p>
-[22:28] <jrand0m> really protocol? </p>
-[22:29] <protocol> yeah</p>
-[22:29] <jrand0m> perhaps thats what triggered the spam guard when i cc'ed iip-dev </p>
-[22:29] * jrand0m will write my isp</p>
-[22:29] <jrand0m> (or perhaps its the .dnsalias.net thing) </p>
-[22:30] <protocol> i didn't get any mailings so far, and i emptied my bulk mail b4 i could check</p>
-[22:30] <duck> or the jrandom nicknam</p>
-[22:30] <jrand0m> lol duck </p>
-[22:30] <FireRabbit> :)</p>
-[22:30] <jrand0m> that'd be awesome if my nick was filtered :) </p>
-[22:30] <FireRabbit> hehe</p>
-[22:30] *** wiht (anon@anon.iip) has joined channel #iip-dev</p>
-[22:30] <jrand0m> wb wiht </p>
-[22:30] <jrand0m> speaking of which, I suppose I should inject 3.1) apps :) </p>
-[22:31] <jrand0m> hey MrEcho, how goes the battle? </p>
-[22:31] <wiht> jrand0m: Hello.</p>
-[22:31] <MrEcho> the day somone writes a autodetect program for the linux compile config</p>
-[22:31] <MrEcho> well its on its way</p>
-[22:31] <duck> knoppix uses some autodetect thing, isnt it?</p>
-[22:31] <jrand0m> ./configure ; make ; make check ; make install ; reboot </p>
-[22:31] <duck> </offtopic></p>
-[22:31] <MrEcho> ive pritty much maped out how i want to do everything</p>
-[22:31] <jrand0m> word </p>
-[22:32] <jrand0m> do you have a clear view on how i2ptunnel could be updated to make use of what you're doing MrEcho? </p>
-[22:32] <FireRabbit> i think knoppix uses hotplug</p>
-[22:32] <MrEcho> 0.1 wont be/might be locked down .. dont know yet</p>
-[22:32] <jrand0m> coo' </p>
-[22:33] <TC> oh jrand0m, i have a question about the cvs</p>
-[22:33] <jrand0m> que tal? </p>
-[22:33] <MrEcho> for dns querys im going to have a server port on the Client and RS side for Names querys</p>
-[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</p>
-[22:33] <MrEcho> and im going to build a lib for any app to use</p>
-[22:33] <jrand0m> FireRabbit> src, dest </p>
-[22:34] <FireRabbit> humm</p>
-[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</p>
-[22:34] <jrand0m> definitely tc </p>
-[22:34] <FireRabbit> this is a pretty big class, i think id want to go a little more specific than that</p>
-[22:34] * jrand0m should get you a cvs account</p>
-[22:34] <TC> im just wondering how to connect to it</p>
-[22:34] <duck> TC: you want (Link: http://www.tortoisecvs.org/)http://www.tortoisecvs.org/</p>
-[22:34] <duck> easiest CVS client for windows that I know</p>
-[22:35] * MrEcho uses the dos ver :)</p>
-[22:35] <mihi> duck: for windows != win9x ;)</p>
-[22:35] * FireRabbit uses the cvs command line port</p>
-[22:35] <duck> mihi: I did test it with win9x</p>
-[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) </p>
-[22:35] * mihi uses either WinCVS or the cygwin cvs</p>
-[22:35] * jrand0m uses cvs.exe</p>
-[22:35] <TC> ok, so i use that client and set up the proxy?</p>
-[22:35] <TC> no, ive never used cvs before</p>
-[22:35] <jrand0m> ok, i'll walk you through the setup after the meeting </p>
-[22:36] <TC> sure, thanks</p>
-[22:36] <duck> about cvs-ing through the tunnel:</p>
-[22:36] <duck> wouldnt the double messages be a big problem?</p>
-[22:36] *** Signoff: wiht (Ping timeout)</p>
-[22:37] <duck> especially for commits</p>
-[22:37] <jrand0m> yes duck, but I haven't run into that problem (cvs messages are typically small) </p>
-[22:37] <jrand0m> >64k messages (e.g. the specs .pdf or .sxw) should for now be done through the normal internet </p>
-[22:38] <duck> jabber msges get also duplicated quite often</p>
-[22:38] <jrand0m> you're right though, in that its not a rock solid solution for cvs yet </p>
-[22:38] <duck> even though they are XML, they are not that big</p>
-[22:40] <jrand0m> right, lost acks are one of the bitches of the current lost i2psessionimpl2 bugs :/ </p>
-[22:40] <duck> k</p>
-[22:41] <duck> (that was a partly lost ack)</p>
-[22:41] <jrand0m> (with the network this size, there should be no resends ever, unless that the peer is offline) </p>
-[22:42] <jrand0m> hmm ok, any other i2p stuff? </p>
-[22:42] <mihi> jrand0m: how about adding some kinda sequence number into the i2p packets?</p>
-[22:43] <jrand0m> i2ptunnel packets? </p>
-[22:43] <mihi> this would help with the doubling things.</p>
-[22:43] <mihi> no, i2pnp packets</p>
-[22:43] <mihi> okay, one could do it on i2ptunnel level as well.</p>
-[22:43] <TC> so jrand0m did you get your conncetion back or are you still at a cafe?</p>
-[22:43] <mihi> just if you get twice the same number, disregard the second one.</p>
-[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 </p>
-[22:44] <jrand0m> right, currently we keep a history of the last 1000 msgIds to drop dups </p>
-[22:44] <mihi> okay, if anyone volunteers to write a good tcp impl for i2p, that would be better ;)</p>
-[22:44] <jrand0m> yes! :) </p>
-[22:44] *** Nostradumbass (nostradum@anon.iip) has joined channel #iip-dev</p>
-[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</p>
-[22:45] <duck> win a 1 hour private chat session with UserX!</p>
-[22:45] <jrand0m> lol </p>
-[22:45] <MrEcho> lol</p>
-[22:46] <jrand0m> ok, any other i2p things, or iip things, or anything else for this, the 69th iip-dev meeting? </p>
-[22:46] <jrand0m> (other than userx pinup girl comments) </p>
-[22:47] <duck> any other apps that duck inc. should run?</p>
-[22:47] <jrand0m> bluebeep! </p>
-[22:47] <TC> 1. jrand0m did you fix your connection issues? 2. what do you think of my new eepsite?</p>
-[22:47] <TC> bluebeep?</p>
-[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 :) </p>
-[22:48] <duck> TC: I like the new design</p>
-[22:48] <TC> hmm, i should change the board as well to cut down on the load time</p>
-[22:48] <duck> only think you should try to disable the email function in the phpboard, now you get an error each time</p>
-[22:48] <TC> thanks duck</p>
-[22:48] <jrand0m> dropping images would be a plus </p>
-[22:49] <TC> good idea</p>
-[22:49] <jrand0m> (bluebeep is an old wardialer) </p>
-[22:49] <MrEcho> ya</p>
-[22:49] <jrand0m> (and all around fun toy) </p>
-[22:49] <duck> please keep in mind that the average age is 16 here</p>
-[22:50] * MrEcho is 24</p>
-[22:50] * duck ducks</p>
-[22:50] * jrand0m doubts there are too many 3 year olds to balance out the geriatrics among us ;)</p>
-[22:50] *** wiht (anon@anon.iip) has joined channel #iip-dev</p>
-[22:50] <MrEcho> lol</p>
-[22:50] * TC built a blackbox once</p>
-[22:50] <jrand0m> w3wt </p>
-[22:50] <lonelynerd> is the meeting already over?</p>
-[22:50] <duck> last Q:</p>
-[22:50] *** protocol is now known as proto_afk</p>
-[22:51] <duck> how can we read the kademlia stats?</p>
-[22:51] * jrand0m hasn't !baf'ed yet lonelynerd, so ask away :)</p>
-[22:51] * MrEcho kills pcmcia support in the kernel</p>
-[22:51] <duck> just so that we understand what routerConsole.html dumps</p>
-[22:51] <MrEcho> im getting pissed</p>
-[22:51] <jrand0m> ok, the JobQueue stats I assume you mean? </p>
-[22:52] * duck guesses that it is all obvious probably</p>
-[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 </p>
-[22:52] <jrand0m> (those are the jobs that usually take the longest, and when the pending side of things gets large, everything suffers) </p>
-[22:53] <lonelynerd> (actually, i better read the logs first)</p>
-[22:53] <duck> gotcha</p>
-[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 </p>
-[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  </p>
-[22:54] <jrand0m> (we resend randomly if it isn't local) </p>
-[22:54] <jrand0m> (no more than once every 5 minutes though) </p>
-[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) </p>
-[22:56] <duck> thanks</p>
-[22:57] <jrand0m> any other comments / questions / concerns / frisbees? </p>
-[22:59] <jrand0m> in that case </p>
-[22:59] * jrand0m winds up</p>
-[22:59] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/69.rst b/i2p2www/meetings/69.rst
new file mode 100644
index 00000000..279bf286
--- /dev/null
+++ b/i2p2www/meetings/69.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 16, 2003 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/7.log b/i2p2www/meetings/7.log
index 11767d08..17768cf4 100644
--- a/i2p2www/meetings/7.log
+++ b/i2p2www/meetings/7.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 7{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 7</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Wed Jul 03 00:33:19 2002
 00:33 <+logger> logging started
 00:47 -!- mode/#iip-dev [+o nop] by mids
@@ -454,5 +447,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 02:22 < UnDeRToW> bye
 10:12 -!- UserX_ is now known as UserX
 --- Log closed Wed Jul 03 10:29:14 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/7.rst b/i2p2www/meetings/7.rst
new file mode 100644
index 00000000..816a6329
--- /dev/null
+++ b/i2p2www/meetings/7.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 3 2002
+============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/70.log b/i2p2www/meetings/70.log
index b1dda7c8..e602bfd4 100644
--- a/i2p2www/meetings/70.log
+++ b/i2p2www/meetings/70.log
@@ -1,164 +1,158 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 70{% endblock %}
-{% block content %}<h3>Tuesday, December 23, 2003 22:00:00 CET</h3>
-<div class="irclog">
-[22:01] <jrand0m> 0) hi </p>
-[22:01] <jrand0m> 1) administravia </p>
-[22:01] <jrand0m> 2) dev status </p>
-[22:02] <jrand0m> 3) services on i2p </p>
-[22:02] <jrand0m> 4) app status [ns, im, i2ptunnel, ...] </p>
-[22:02] <jrand0m> 5) ??? </p>
-[22:02] <thecrypto> wow, i picked a good time</p>
-[22:02] <jrand0m> 0) hi </p>
-[22:02] <jrand0m> yes you did thecrypto :) </p>
-[22:02] <jrand0m> hi </p>
-[22:02] <jrand0m> welcome to meeting 70 </p>
-[22:02] <TC> woot</p>
-[22:03] <jrand0m> 1) administravia </p>
-[22:03] <thecrypto> w00t!</p>
-[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/ </p>
-[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 </p>
-[22:04] <jrand0m> i think thats it for administravia </p>
-[22:05] <jrand0m> (note that i'm just talking i2p stuff here, i don't see any iip things on the agenda) </p>
-[22:05] <jrand0m> 2) dev status </p>
-[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 </p>
-[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. </p>
-[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) </p>
-[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 </p>
-[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. </p>
-[22:08] <jrand0m> y'all rule, I really appreciate the help </p>
-[22:09] * thecrypto pulls out the "APPLAUSE" sign</p>
-[22:09] <jrand0m> ;) </p>
-[22:09] <jrand0m> the # of routers have also been increasing... on avg we're at around 9-12 </p>
-[22:09] <jrand0m> (up from 3-5 a week ago, and 6-8 in 0.2.2 times) </p>
-[22:10] <jrand0m> the next release will improve the reliability dramatically </p>
-[22:10] <jrand0m> (aka it won't get out the door until it does) </p>
-[22:10] <jrand0m> ok, 3) services on i2p </p>
-[22:11] <jrand0m> fillament started hosting his flog on i2p :) </p>
-[22:12] <FillaMent> and I've got another trick up my sleeve =)</p>
-[22:12] <jrand0m> ooOOoo :) </p>
-[22:12] <luckypunk> tw</p>
-[22:12] <luckypunk> hm</p>
-[22:12] <luckypunk> hello.</p>
-[22:12] <luckypunk> Does it work yet?</p>
-[22:12] <jrand0m> duck started a new irc server on i2p with dcc disabled (for security reasons) plus some ident-ish features </p>
-[22:13] <luckypunk> lol</p>
-[22:13] <jrand0m> luckypunk> people with 350Mhz machines will need to wait until 0.3 is out before being able to use it effectively ;) </p>
-[22:13] <luckypunk> yes, but is i2p reliable enough for that?</p>
-[22:13] <jrand0m> (but subscribe to the i2p mailing list so you can get announcements) </p>
-[22:13] <luckypunk> i overclocked to 377</p>
-[22:13] <luckypunk> does that help?</p>
-[22:13] <luckypunk> lol</p>
-[22:13] <jrand0m> i was chatting on that irc server the other day, until my irc client b0rked </p>
-[22:14] <jrand0m> but yes, things are a bit unreliable at the moment while the tunnel management subsystem is rebuilt </p>
-[22:14] <luckypunk> well, im happy my computer didn't molassify overnight again.</p>
-[22:15] <jrand0m> any other new services i've missed?   </p>
-[22:15] <luckypunk> well, when .3 comes out...t here'll be a yahooish service.</p>
-[22:15] <luckypunk> ;)</p>
-[22:15] <jrand0m> cool </p>
-[22:15] <TC> i should run somthing else</p>
-[22:16] <TC> whats a service we need that doesnt require messing with apache?</p>
-[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 </p>
-[22:16] <jrand0m> you could run a telnet based games server (e.g. adventure, etc) </p>
-[22:16] <luckypunk> lol</p>
-[22:16] <TC> hah</p>
-[22:16] <FillaMent> MUSH</p>
-[22:17] <luckypunk> i'll do that... it's low demand.</p>
-[22:17] <luckypunk> and i already had about 300k of tinymush code.</p>
-[22:17] <jrand0m> yeah, the whole mush/mud/moo/ style thaang </p>
-[22:17] <luckypunk> heh</p>
-[22:17] <TC> what about ultima online?</p>
-[22:18] <thecrypto> ooh that's be fun</p>
-[22:18] <luckypunk> "Slay FreeNet Databugs!"</p>
-[22:18] <luckypunk> TC: =|</p>
-[22:18] <thecrypto> we need to get a telnet client then</p>
-[22:18] <luckypunk> maybe if we all obtained 6 ghz computers with oc-128 lines. :D</p>
-[22:18] <jrand0m> thecrypto> /bin/telnet + i2ptunnel </p>
-[22:18] <thecrypto> ...yeah</p>
-[22:18] <thecrypto> i'm sloew</p>
-[22:19] <thecrypto> :)</p>
-[22:19] <jrand0m> any other low hanging fruit for services?  a mail server (pop3/imap without internet mail) would rule </p>
-[22:19] <jrand0m> (and if it could /receive/ internet email that'd rule too) </p>
-[22:21] <jrand0m> ok, 4) app status </p>
-[22:21] <jrand0m> naming service </p>
-[22:21] <jrand0m> wiht / co was here earlier, but not now </p>
-[22:21] <jrand0m> MrEcho> how goes? </p>
-*** MrEcho is echo@anon.iip (Digital_Light) </p>
-*** on channels: #iip-dev #anonymous </p>
-*** on irc via server anon.iip (Official IIP )</p>
-*** MrEcho has been idle 3 minutes, signed on at Thu Jan 01 01:00:00 1970 </p>
-[22:23] <jrand0m> ok, perhaps we'll get back to that </p>
-[22:23] <jrand0m> hosts.txt has been growing as destinations have come online </p>
-[22:23] <jrand0m> there's a bot on the jabber server that will let you register / fetch entries </p>
-[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) </p>
-[22:24] <jrand0m> next up, IM </p>
-[22:24] <jrand0m> hi thecrypto :) </p>
-[22:24] <jrand0m> welcome back </p>
-[22:25] <thecrypto> hi</p>
-[22:25] <thecrypto> i2pim is being started from scratch</p>
-[22:25] <thecrypto> i need to figure out how this network works but tearing apart ATalk and slowly putting it back together</p>
-[22:25] <thecrypto> so it's slowly coming along</p>
-[22:25] <jrand0m> word </p>
-[22:25] <thecrypto> i don't know if i can get group chat working</p>
-[22:25] <thecrypto> but it's an idea</p>
-[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 </p>
-[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</p>
-[22:26] <jrand0m> hehe </p>
-[22:26] <jrand0m> cool </p>
-[22:27] <jrand0m> yeah, starting off with one on one (perhaps with send/receive file) would probably be prudent </p>
-[22:27] <thecrypto> yeah, the only problem would be syncronizing the baton will be difficult</p>
-[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</p>
-[22:27] <thecrypto> nety</p>
-[22:27] <TC> token-ring-chat?</p>
-[22:27] <jrand0m> yup, voting systems are a pain.   </p>
-[22:28] <jrand0m> right, good ol' 2phaseCommit </p>
-[22:28] <thecrypto> TC: no, basically the IM network has no central presence server</p>
-[22:28] <thecrypto> so what i'm thinking about doing is have a virtual server baton</p>
-[22:29] <duck> ok, using a bootdisk from now on...</p>
-[22:29] <jrand0m> the other option is to do group chat fully distributed: "group" just being "send these messages to peer X, Y, Z" </p>
-[22:29] <jrand0m> d'oh duck </p>
-[22:29] <thecrypto> yeah, but that's network by broadcast</p>
-[22:29] <jrand0m> not really </p>
-[22:29] <thecrypto> which is usually the stupidest idea</p>
-[22:29] <jrand0m> the messages have to get sent to peer X, Y, Z from someone sometime </p>
-[22:30] <jrand0m> its actually 1 less message than the (temporary) server based model </p>
-[22:30] <thecrypto> yes, but then each person has to keep track of the group</p>
-[22:30] <jrand0m> (and the UI can make the group 'pretty') </p>
-[22:30] <thecrypto> and now there has to be messages passed around about what the group is current</p>
-[22:30] <jrand0m> right, perhaps a control message stating "I think group A is X, Y, Z" </p>
-[22:31] <jrand0m> instead of the voting protocol </p>
-[22:31] <jrand0m> right, I'm not sure what way is best </p>
-[22:31] <jrand0m> just saying there's an option </p>
-[22:31] <jrand0m> no lo se  </p>
-[22:31] <thecrypto> yeah</p>
-[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 </p>
-[22:32] <thecrypto>  well, i need code for there to be bugs in first</p>
-[22:32] <jrand0m> ;) </p>
-[22:33] <thecrypto> so wait a bit and i'll have something to put on bugzilla</p>
-[22:34] <jrand0m> cool, whenever, its trivial to add </p>
-[22:35] <jrand0m> ok, i2ptunnel </p>
-[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 </p>
-[22:36] <jrand0m> plus there's a thing wrt some browsers b0rking on missing trailing / </p>
-[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) </p>
-[22:37] <jrand0m> other than that, the things are minor, i2ptunnel is behaving a lot better than the router :) </p>
-[22:38] <jrand0m> ok, any other apps? </p>
-[22:39] <jrand0m> there was some discussion about NAT/SOCKS the last few days on the channel </p>
-[22:39] <jrand0m> a socks enabled proxy that would let people ftp, bittorrent, etc would be really great </p>
-[22:39] <jrand0m> plus there's the discussion aum started on the i2p list wrt file sharing / cdn </p>
-[22:40] <jrand0m> (i swear i didn't tell him to make that post ;) </p>
-[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' </p>
-[22:44] <jrand0m> ok, thats it for apps </p>
-[22:44] <jrand0m> 5) ??? </p>
-[22:44] <jrand0m> hi </p>
-[22:44] <jrand0m> any comments / questions / concerns / etc? </p>
-[22:45] <ardvark> I think everyone fell asleep ;)</p>
-[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 </p>
-[22:46] <duck> oh, meeting</p>
-[22:46] <jrand0m> yeah, exciting, aint it ;) </p>
-[22:46] * jrand0m slings mud at duck</p>
-[22:46] * mihi did not follow, sorry. he will stand in the corner for the next 5 minutes...</p>
-[22:46] <jrand0m> hehe </p>
-[22:47] <jrand0m> ok, thats about it. </p>
-[22:48] * jrand0m *baf*s the meeting to a close</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/70.rst b/i2p2www/meetings/70.rst
new file mode 100644
index 00000000..349de89d
--- /dev/null
+++ b/i2p2www/meetings/70.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 23, 2003 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/71.log b/i2p2www/meetings/71.log
index 10593a29..a90913b2 100644
--- a/i2p2www/meetings/71.log
+++ b/i2p2www/meetings/71.log
@@ -1,336 +1,330 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 71{% endblock %}
-{% block content %}<h3>Tuesday, December 30, 2003 22:00:00 CET</h3>
-<div class="irclog">
-<jrandom> 0) hi</p>
-<jrandom> 1) router status</p>
-<jrandom> 2) i2ptunnel</p>
-<jrandom> 3) im</p>
-<jrandom> 4) 0.3 plans</p>
-<jrandom> 5) time synchronization</p>
-<jrandom> 6) ???</p>
-<jrandom> hello mihi, polo</p>
-<polo> hello !</p>
-<mihi> hi jrandom</p>
-<jrandom> 0) hi</p>
-<jrandom> :)</p>
-<rsk> hi</p>
-<i2p> <duck> hi</p>
-<jrandom> 1) router status</p>
-<jrandom> 0.2.3.3 is out, and it seems to be working</p>
-<jrandom> still lots to do, of course</p>
-<jrandom> but this should be the last 0.2 release</p>
-<jrandom> 0.3 is going to add the peer profiling to allow routers to avoid bad routers</p>
-<jrandom> (and 0.3.1 is a revamp of the transports)</p>
-<jrandom> hola Ophite1</p>
-<Ophite1> Heya.</p>
-<rsk> so more overhead for 0.3?</p>
-<jrandom> yes and no</p>
-<jrandom> it will have peer testing, but its going to be more focused</p>
-<rsk> will we see a speed up with path selection?</p>
-<jrandom> yes</p>
-<jrandom> there are those 'liveliness' calculators, and there will be new latency and throughput calculators added</p>
-<jrandom> plus people will be able to tweak their own preferences for particular peers</p>
-<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</p>
-          some random points</p>
-<mihi> will there be a clean shutdown? *g*</p>
-<jrandom> thats actually a good question mihi</p>
-<jrandom> i2p is getting to the point where it needs an admin interface.</p>
-<jrandom> the longest Job thats holding up its operation is the GenerateStatusConsoleJob</p>
-<jrandom> which can now take up to 4-6 seconds</p>
-<jrandom> (holding everything else up)</p>
-<jrandom> that needs to go async and on demand.</p>
-<jrandom> but i dont want to write a web listener / etc.</p>
-<jrandom> perhaps the reverse - a servlet that starts the router and communicates with it</p>
-<mihi> you don't need a full web server. just when you see GET, return your data.</p>
-<jrandom> right</p>
-<jrandom> you're right, that stuff should be in 0.3 as well.</p>
-<mihi> and when you see something else (like SHUTDOWN), do as you please. of course only from localhost ;)</p>
-<jrandom> aww c'mon</p>
-<mihi> then someone can make a nice admin program</p>
-<jrandom> right</p>
-<mihi> you had some triggers by files, didn't you? are they documented somewhere?</p>
->>> mihi [~mihi@ags9-d9ba536a.pool.mediaWays.net] requested PING 1072820995 from jrandom</p>
-<jrandom> those were in IDN, not the router itself</p>
-<jrandom> but that might be a good way to go</p>
-<jrandom> its a trivially easy system</p>
-<jrandom> good idea, lets go that way</p>
-<jrandom> (and i can just reuse that code :)</p>
-<i2p> <duck> this magical filestuff starts to look like plan9</p>
-<jrandom> lol</p>
-<mihi> but file triggers require polling</p>
-<jrandom> right mihi, reading a directory every 30s aint that bad</p>
-<mihi> but a ServerSocket#accept is cheaper.</p>
-<mihi> as it won't eat any time. (provided a good OS)</p>
-<mihi> okay, file triggers are better than nothing, sure.</p>
-<jrandom> server socket would allow remote admin</p>
-<jrandom> (when appropriate)</p>
-<jrandom> dunno.</p>
-<jrandom> something to be worked out.</p>
-<jrandom> (or if someone wants to jump on it and code... :)</p>
-<mihi> and server socket could deliver the routerConsole as well.</p>
-<jrandom> right</p>
-<jrandom> ok, 2) i2ptunnel</p>
-<jrandom> :)</p>
-<jrandom> i2ptunnel still rules, and its looking like we want to add a socket based API to control it</p>
-<i2p> <anon> aum's ic2cp2pc plans are off for now?</p>
-<jrandom> yes, ci2cp is dead in the water, replaced with the socket based API to control I2PTunnel</p>
-<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</p>
-<mihi> just use a socket, make in.readLine() and feed that line to runCommand() ;)</p>
-<rsk> what does the api give i2p?</p>
-<jrandom> pretty much mihi (except it formats the results and send them back in a standard way)</p>
-<mihi> with an appropriate "logger" to send the commands back.</p>
-<mihi> s/commands/results/</p>
-<jrandom> rsk> it lets application developers build client and server sockets over i2p without dealing with I2CP's</p>
-          encryption needs</p>
-<jrandom> right right</p>
-<jrandom> i2ptunnel /does/ have an overhead for situations where there are lots of i2ptunnels</p>
-<jrandom> regardless of the JVM</p>
-<jrandom> i2ptunnel clients create a new destination per client contacted, and the router will perform much worse as</p>
-          the number of local destinations grows.</p>
-<rsk> ah</p>
-<jrandom> this is due to the anonymity needs of the network tied to how our encryption works</p>
-<jrandom> for applications who just want to open a tunnel or two to a peer, this new api will RULE</p>
-<jrandom> but for applications that need to talk to lots of other peers, I2CP is the way to go.</p>
-<jrandom> (since that is a single destination, multiplexed by i2cp)</p>
-<jrandom> I suppose its the old TCP vs UDP balance, in a way</p>
-<jrandom> mihi> do you have any thoughts, or some ideas for the future of i2ptunnel?</p>
-<rsk> hows the work on the ip over i2p, or the vpn stuff going?</p>
-<mihi> jrandom: someone write a good streaming api, and then lets i2ptunnel use it.</p>
-<mihi> same for naming server.</p>
-<mihi> perhaps add some sequence numbers if no one does the things above.</p>
-<mihi> which will mean an incompatible change.</p>
-<jrandom> incompatible changes aren't bad, we're early in dev</p>
-<jrandom> (if we could increase the size of of the IDs too to two or four bytes per side as well?)</p>
-<mihi> the streaming api will be an incompatible change nevertheless. and if i2p worked, we don't need sequence</p>
-          numbers.</p>
-<jrandom> rsk> on hold, until someone has time to run with it?</p>
-≡ rsk/#i2p thinks incompatible chages are the best kind</p>
-<jrandom> right mihi</p>
-<mihi> ID should be 3 byte atm, so why *increase* to 2 bytes?</p>
-<jrandom> mihi> actually, I'd like to slowly deprecate mode=GUARANTEED and implement that in the streaming api</p>
-≡ mihi/#i2p too</p>
-<jrandom> leaving i2p = IP, not TCP or UDP</p>
-<jrandom> damnit I wish I had another 14 hours in the day.</p>
-<mihi> only 14? ;)</p>
-<jrandom> ;)</p>
-<jrandom> aren't the 3 byte ids derived by both sides of the con?  or maybe i'm just confused</p>
-<mihi> each side has an ID of 3 bytes, hovever, only one must be sent at a time.</p>
-<jrandom> perhaps I'll implement the streaming API, rip out GUARANTEED, and add that socket controller next.</p>
-<jrandom> ah ok</p>
-<mihi> see /apps/i2p/i2ptunnel/java/src/protocol.txt</p>
-<jrandom> right right</p>
-<mihi> btw, who misplaced that file *there*?</p>
-≡ jrandom blames eco ;)</p>
-<jrandom> wait, naw, you put 'em there</p>
-<jrandom> didnt you?</p>
-<jrandom> oh wait, no I imported them</p>
-≡ jrandom blames self for being stupid.</p>
-<jrandom> (la la la)</p>
-<jrandom> damn.  ok, yeah, working on the streaming API and the socket controller will allow me to mull over the peer</p>
-          testing / profiling / selection manifesto</p>
-<jrandom> I'll post that in a few days for comment</p>
-<jrandom> (and it'll get my head out of the router.  variety++)</p>
-<jrandom> mihi> anything else on i2ptunnel?</p>
-<mihi> not that i know</p>
-<jrandom> coo'</p>
-<jrandom> (thanks again for taking the time to chime in on this stuff, I know you're busy with fiw and the rest)</p>
-<jrandom> ok, thecrypto isn't here, but he's making progress on the IM app.</p>
-<jrandom> (thats agenda item 3)</p>
-<jrandom> 4) 0.3 plans</p>
-<jrandom> 0.3.0 ~= peer profiling stuff, and now it'll also include the streaming api and that socket controller for</p>
-          i2ptunnel</p>
-<jrandom> but, if you couldn't guess, its not going to be released on jan 1</p>
-<jrandom> jan 15 is an outside possibility.  we'll see how things go.</p>
-<jrandom> 0.3.1 isn't a full month of work, so it may not need to get bumped.</p>
-<jrandom> other than that, the roadmap is still pretty much on track and representative of where we're moving</p>
-<jrandom> 5) time synchronization</p>
-<jrandom> a new faq is posted at http://wiki.invisiblenet.net/iip-wiki?I2PTiming</p>
-<jrandom> mihi, you had a suggestion about the fourth option there (building our own in-i2p timing)?</p>
-<jrandom> hi brawl</p>
-<mihi> yep.</p>
-∙φ∙ brawl is now known as eco_</p>
-<eco_> hi guys</p>
-<jrandom> oh heya eco</p>
-<mihi> you should connect 3 random nodes and remember the diff between the avg time and local time.</p>
-<jrandom> we just discussed the streaming API / tunnel api</p>
-<mihi> and then hack up your own getTimeMillis that corrects that.</p>
-<Ophite1> mihi: No, you shouldn't.</p>
-<jrandom> mihi> so if an attacker creates 1000 nodes with the wrong time, everyone gets screwed</p>
-<jrandom> (since avg would skew randomly in between)</p>
-<mihi> if an attacker creates 1000 nodes, everyone gets screwed anyway...?</p>
-<rsk> wouldnt that be self corecting?</p>
-<Ophite1> mihi: OK, 3.</p>
-<jrandom> no, we should be able to handle that mihi.</p>
-<mihi> okay, then only use avg, if standard deviation is lower than 1sec or so.</p>
-<rsk> if everyone has the same time your ok, even if that time is wrong, right?</p>
-<jrandom> rsk> if all 1000 nodes were in sync, but what if they're all random</p>
-<mihi> only use times that are close enough together. if not, take 3 new nodes.</p>
-<jrandom> mihi> right, we could implement NTP (which basically does what you say, using a series of candidate averages</p>
-          to iteratively close in on the correct time</p>
-<mihi> but we need not care of everything (like ping latencies), as ntp does.</p>
-<Ophite1> if we did not, mihi, time would slowly creep backwards.</p>
-≡ mihi/#i2p thinks that is better than let users set their time individually.</p>
-<jrandom> so anyone who randomly picks 3 of those skewed nodes gets sent onto their own private network?</p>
-<jrandom> what about that third option -</p>
-<jrandom> i2p has a component that checks with a real NTP server via NTP or SNTP</p>
-<mihi> if you have only skewed notes in your netDB, you are on that private net as well...</p>
-<jrandom> rather than reimplementing the wheel</p>
-<Ophite1> while I partially like that one...</p>
-<Ophite1> NTP isn't signed, it's subject to an MITM attack.</p>
-<Ophite1> or dns cache poisoning for, say, time.nist.gov</p>
-<jrandom> right Ophite1, though with 200,000+ SNTP or NTP hosts, thats a large set to attack.</p>
-<jrandom> we would definitely not sync of time.nist.gov.</p>
-<Ophite1> connections from i2p to the NSA's time server might raise a few eyebrows, ne? :)</p>
-<jrandom> and if an attacker goes after time.nist.gov, everyone everywhere is affected</p>
-<jrandom> heh</p>
-<mihi> then we combine both. ask a "real" ntp server and your neighbor. if both say the same, it's okay.</p>
-<jrandom> so even /more/ code ;)</p>
-<jrandom> but yeah, thats reasonable.</p>
-<Ophite1> That's interesting. And if they don't?</p>
-<Ophite1> pick another ntp server?</p>
-<jrandom> refuse the peer.</p>
-<mihi> try other ntp server and another peer.</p>
-<mihi> until you have a match. then refuse all prev peers.</p>
-≡ mihi/#i2p types slower than jrandom :(</p>
-<Ophite1> match within a certain threshold, say 1sec?</p>
-<jrandom> 1s would be good.</p>
-<jrandom> accepting peers up to 30s or so (to deal with lag)</p>
-<Ophite1> is 1 sec okay on HEAVILY LADEN connections?</p>
-<jrandom> 1s for syncing, 30s for comm.</p>
-<Ophite1> I've seen latency on DSL get to 5 seconds when doing evil things to it.</p>
-<jrandom> with tcp or udp?</p>
-<Ophite1> but then, in that case, that host might not be the one you want to sync time to anyway ;)</p>
-<jrandom> right</p>
-<Ophite1> udp.</p>
-<jrandom> hmm 'k</p>
-<Ophite1> you'd have thought it'd get dropped :)</p>
-<i2p> <duck> I think that the problem is more letting the user know that there is a problem</p>
-<jrandom> duck> that is true.</p>
-<i2p> <duck> only after walking through big logs they see that their clock is off (if they find it)</p>
-<Ophite1> Maybe. Sort of.</p>
-<i2p> <duck> or that the port is already bound</p>
-<jrandom> an admin interface would be nice.</p>
-<i2p> <duck> the world is better with everybody using NTP connected to their local stantrum (sp) 2 server</p>
-CTCP Cloaking is now [On]</p>
-<jrandom> perhaps we'll have a 0.4 release with a bunch of cleanups and end user things, prior to going 1.0?</p>
-<jrandom> right (stratum)</p>
-<i2p> <duck> only windows clients are not likely to have that</p>
-<i2p> <duck> but they are also not likely to be stable</p>
-<jrandom> windows has NTP</p>
-<i2p> <duck> so who cares</p>
-<Ophite1> duck: Windows XP and Windows Server 2003 include NTP.</p>
-<jrandom> a shitload easier than with unix too</p>
-<Ophite1> sync'ed by default to time.windows.com iirc.</p>
-<jrandom> with drop down options for others</p>
-<Ophite1> It's an essential part of Windows Product Activation.</p>
-<Ophite1> can't expire if you don't know the time :)</p>
-<jrandom> heh</p>
-<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</p>
-          anyway...</p>
-<Ophite1> mihi: i2p should try especially hard to work in such a situation...</p>
-<jrandom> mihi> awesome!  you can help test out the hidden operation :)</p>
-<jrandom> as an aside, I'm going to be doing some traveling this summer</p>
-<jrandom> i'll likely be offline, without my laptop.</p>
-<i2p> <duck> sidethought: ntp.duck.i2p :)</p>
-<Ophite1> Look at it like this: Brianna Kazaa downloads cool new anonymous filesharing client which her best friend</p>
-          told her was really cool and lets you chat to people secretly and stuff. Do we want to tell her that she</p>
-          needs to set her clock within 30 seconds (how will she get some?)? Or do we want it to just work?</p>
-<jrandom> but I'm going to make sure I can still be on I2P with just public terminals.</p>
-CTCP Cloaking is now [Off]</p>
-<jrandom> no brainer Ophite1.  just work (with docs for geeks)</p>
-<jrandom> duck> bootstrap ;)</p>
-<jrandom> and i2p will /not/ require root.</p>
-<Ophite1> That's my point.</p>
-<Ophite1> jrandom: would you run a router on a box you didn't have root to?</p>
-<jrandom> so yeah, a mix between option 3 and 4</p>
-<Ophite1> option 3.5 sounds cool to me ;)</p>
-<jrandom> Ophite1> i'd run a hundred of them :)</p>
-<mihi> option 3.1415926...</p>
-<jrandom> (and move on to the next lab, run a hundred more)</p>
-<Ophite1> Ooh. Pie. Tasty.;)</p>
-<Ophite1> jrandom: I said you didn't have root on. Amateur. :)</p>
-<jrandom> lol</p>
-<jrandom> so thats basically where we're looking.</p>
-<jrandom> until the time stuff is implemented, everyone should use option 1 or 2.</p>
-<jrandom> for option 2, if someone could write up some docs, I'd appreciate it</p>
-<Ophite1> that's acceptable for now as we are Not Yet Ready for Brianna Kazaa et al ;)</p>
-<mihi> jftr: i won't test "hidden operation". my univ account has already been disabled once and i don't want it</p>
-          another time blocked...</p>
-<Ophite1> mihi: You are the best test we could possibly have.</p>
-<jrandom> Ophite1 > not for test.</p>
-<jrandom> 'k mihi, we'll find a way, and once its ready you'll be able to use it.</p>
-<Ophite1> OK, maybe not test. Some unis get shirty enough to chuck you out rather than just block you.</p>
-<Ophite1> I know someone at the most anti-filesharing pro-RIAA university in the USA. He runs a 2gbit dumpsite.</p>
-<jrandom> lol nice</p>
-<Ophite1> I appreciate that very, very few people are this ballsy.</p>
-<jrandom> ok, thats it for time synchronization.</p>
-<jrandom> eco_> hi.  any bt stuff you want to talk about?  {or save till next week}</p>
-<Ophite1> but bear in mind the majority of the internet is in future probably going to become university/corporate.</p>
-          i2p might be banned. i2p might WELL be considered abuse by major ISPs. i2p will have to work anyway.</p>
-<Ophite1> I have a few interesting ideas along that angle I will present at a future date.</p>
-<jrandom> word</p>
-<Ophite1> (transport)</p>
-<rsk> i2p is considered abuse by major ISPs, read your contract</p>
-<Ophite1> rsk: running a distributed proxy cache?</p>
-<rsk> running any 'server'</p>
-<Ophite1> rsk: Not unless it relays to SMTP or WWW.</p>
-<jrandom> running services of any time</p>
-<jrandom> right</p>
-<Ophite1> rsk: Hehe, I have a solution to that ;)</p>
-<eco_> jrandom: can give a brief update</p>
-<jrandom> floor is yours :)</p>
-<eco_> i'm porting the java-based bittorrent client snark (www.klomp.org/snark) to get aquainted with i2p</p>
-<eco_> first port runs on top of i2ptunnel, directly calling the java classes</p>
-<eco_> current state: does work with 2 peers, things get messed up with > 2, tunnels aren't cleaned up, so restarting</p>
-          is painful</p>
-<eco_> eta: this weekend</p>
-≡ eco_/#i2p realises that this might be considered > 2003</p>
-<jrandom> w00t!</p>
-≡ jrandom hacks time.nist.gov</p>
-<eco_> a "real" port would probably cut the overhead of the tunnels, but that's a next step</p>
-<jrandom> cool</p>
-≡ eco_/#i2p gives floor back to mc jrandom</p>
-<jrandom> 'k, I think that was it</p>
-<jrandom> 6) ???</p>
-<jrandom> anyone have anything else?</p>
-≡ eco_/#i2p would like to express his thanks for the job well done by jrandom cs up to now</p>
-<eco_> and that sleep has some use for home sapiens, though jrandom seems to prove this false</p>
-<jrandom> ;)</p>
-<jrandom> what are y'all's thoughts on meeting here as opposed to iip, until i2p is reliable enough?</p>
-<jrandom> personally, I'm tired of meetings being cut to shreds every week.</p>
-<i2p> <anon> lilo sucks!</p>
-<eco_> we might be shutting people out by going here</p>
-<jrandom> we are, I know.</p>
-<jrandom> if we can get an iip<-->here bridge</p>
-<i2p> <duck> IIP is shutting ppl out each day</p>
-<jrandom> that'd be good.</p>
-<jrandom> right.</p>
-<jrandom> iip is, unfortunately, unusable for a reliable development community.</p>
-<i2p> <duck> http://banaan.zeelandnet.nl/open/changate.html</p>
-<i2p> <duck> that is the code where eyeKon etc is based on</p>
-<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</p>
-          essential</p>
-≡ rsk/#i2p is writing a windows update script</p>
-<i2p> <duck> theoretically it could connect to 3 servers and mirror each of them</p>
-<jrandom> word duck, perhaps I'll try to get one running on i2p.dnsalias.net</p>
-<jrandom> ping flood from hell ;)</p>
-<eco_> irc at duck.i2p was pretty good today, beat iip</p>
-<jrandom> agreed</p>
-<jrandom> dropped me a few times though.</p>
-<jrandom> perhaps it'll be more reliable next week</p>
-<eco_> it's in your hands :-)</p>
-<jrandom> reliability probably won't improve until 0.3, which is ~2 weeks out</p>
-<jrandom> (1 week to do the tunnel/streaming stuff, 1 week for peer profiling / testing)</p>
-<jrandom> then there'll be whatever bugs that introduces :)</p>
-<jrandom> though I should say I was really excited to stream audio from aum last night</p>
-<jrandom> and ardvark was able to stream for 42 minutes without buffering!</p>
-<jrandom> so perhaps we can be reliable enough</p>
-<jrandom> (my local router is phttp only, which is probably a slight cause)</p>
-<jrandom> ok, anyone have anything else?</p>
-<i2p> <duck> cant thing of anything</p>
-≡ eco_/#i2p can't either</p>
-≡ jrandom winds up...</p>
-≡ jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+<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/71.rst b/i2p2www/meetings/71.rst
new file mode 100644
index 00000000..3bd5286c
--- /dev/null
+++ b/i2p2www/meetings/71.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, December 30, 2003 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/72.log b/i2p2www/meetings/72.log
index fee4905e..40292672 100644
--- a/i2p2www/meetings/72.log
+++ b/i2p2www/meetings/72.log
@@ -1,659 +1,653 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 72{% endblock %}
-{% block content %}<h3>Tuesday, Jan 6, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:02] <jrand0m> agenda:</p>
-[22:02] <jrand0m> 0) hi</p>
-[22:02] <jrand0m> 1) http://i2p.dnsalias.net/pipermail/i2p/2004-January/000069.html</p>
-[22:02] <jrand0m> 2) [discussion]</p>
-[22:02] <wiht> Can I add installer to agenda?</p>
-[22:02] <jrand0m> 0) hi</p>
-[22:02] <jrand0m> oh yes, certainly!</p>
-[22:02] <jrand0m> we're trying something new this week</p>
-[22:03] <wiht> You can put it at the end of the agenda.</p>
-[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</p>
-[22:03] * mihi_ has joined #i2p</p>
-[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</p>
-[22:04] <jrand0m> such as a new installer</p>
-[22:05] <jrand0m> so, that said, people should start by checking out that email/post and we'll go from there :)</p>
-[22:05] * mihi_away is now known as mihi</p>
-[22:05] * kaji reads the post</p>
-[22:05] * mihi_ is now known as mihi_backup</p>
-[22:06] <jrand0m> 27 users with only one dup!  w0w</p>
-[22:07] * dm is now known as dup</p>
-[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?</p>
-[22:07] <mihi> jrand0m: where do you know from that there are no more dupes?</p>
-[22:07] <jrand0m> heh thanks dm</p>
-[22:07] <jrand0m> mihi> I installed keyloggers on everyone's computers (bwhahahaha)</p>
-[22:07] <wiht> I would like to add installer as topic 10, and possibly naming service as topic 11.</p>
-[22:07] * mihi sent the followup to the wrong address :(, resending...</p>
-[22:08] <jrand0m> good call wiht</p>
-[22:09] <MrEcho> mrecho's new dns is in the works</p>
-[22:09] <jrand0m> cool mihi, yeah I was wondering ;)</p>
-[22:09] <kaji> how is dns coming along? - ah</p>
-[22:09] <jrand0m> MrEcho> your post, right?</p>
-[22:09] <MrEcho> working on the post</p>
-[22:10] <jrand0m> ok, in the meantime, anyone have anything on 1) streaming? or should we jump to 2) I2PTunnel, TunnelManager, and i2pmgr?</p>
-[22:10] <lucky> good lord... i could spend the rest of my life attempting to figure out these dependecnies.</p>
-[22:10] <wiht> So let's say DNS/NS as topic 11.</p>
-[22:10] <jrand0m> sounds good wiht</p>
-[22:10] * duck walks in</p>
-[22:11] <jrand0m> ev'nin duck</p>
-[22:11] <mihi> ad 1, i committed code for i2ptunnel using the streaming api</p>
-[22:11] <jrand0m> ah right, awesome mihi :) </p>
-[22:11] <lucky> hi duck</p>
-[22:11] * twosandals has quit IRC (Leaving)</p>
-[22:11] <kaji> jrand0m can several sevices use the same key if they are on diffrent ports?</p>
-[22:11] <jrand0m> no kaji</p>
-[22:11] <mihi> btw: why do your ant files always delete the jar before rebuilding it?</p>
-[22:11] <jrand0m> mihi> paranoia</p>
-[22:12] <mihi> stealing me time with debugging, i'd say ;)</p>
-[22:12] <jrand0m> kaji> in i2p, a key /is/ a port, essentially</p>
-[22:12] <jrand0m> heh</p>
-[22:12] <kaji> ah</p>
-[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</p>
-[22:13] <mihi> if the file is newer than all files in it, and could skip it otherwise.</p>
-[22:13] <jrand0m> right</p>
-[22:13] <mihi> and for paranoia it is better to add a <depends> task</p>
-[22:13] <jrand0m> agreed</p>
-[22:13] <FillaMent> yo yo</p>
-[22:13] <jrand0m> 'lo FillaMent</p>
-[22:14] <jrand0m> ok, 2) i2ptunnel / tunnelmanager / i2pmgr</p>
-[22:14] * TC has joined #i2p</p>
-[22:15] <human> i did a little hacking to make the TunnelManager return the job ids when "openclient" or "openserver" commands are called</p>
-[22:16] <jrand0m> kickass :)</p>
-[22:16] <human> this way, apps using the TunnelManager know which job to close later, without parsing the "list" output</p>
-[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</p>
-[22:17] <jrand0m> we'll get that patch in there right after the meeting.  gracias human :)</p>
-[22:17] <human> it involved making I2PTunnel.runCommand return some stuff (currently a Property)</p>
-[22:17] <human> s/Property/Properties/</p>
-[22:17] <jrand0m> oh right, there's some things to modify in that before getting it into the code</p>
-[22:18] <human> but mihi would prefer to add some asynchronous callbacks to the Logging clas, as far as i understand...</p>
-[22:19] <jrand0m> right - so that things can get information from the tasks immediately, without waiting for it to finish</p>
-[22:20] * mihi has quit IRC (EOF From client)</p>
-[22:20] <human> jrand0m: the idea is: let's I2PTunnel.runCommand() return immediately, and eventually use callbacks to get more info, right?</p>
-[22:21] <jrand0m> right</p>
-[22:21] <jrand0m> so the tasks fire callbacks whenever there is data to distribute</p>
-[22:21] * mihi has joined #i2p</p>
-[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)</p>
-[22:22] * mihi uses it via the gui</p>
-[22:22] <human> (well, "all" means the TunnelManager and apps parsing the Tunnel manager output)</p>
-[22:22] <jrand0m> right, the gui will hang while the command is executed</p>
-[22:22] <mihi> and entering the next 3 tunnel open commands is blocked while the first is running</p>
-[22:23] <human> mihi: ok, i didn't know about your app... then we need some solution :-)</p>
-[22:24] <human> mihi: asynchronous .runCommand() behaviour would require to revise the TunnelManager</p>
-[22:24] <mihi> human: when (iyo) should runCommand terminate? when the tunnel is built, when the connection got through?</p>
-[22:25] <mihi> "destination unreachable" will be known *after* the first connection attempt was made.</p>
-[22:25] <jrand0m> the command pattern would have the execute() return only after it was complete.</p>
-[22:26] <mihi> what does *complete* mean?</p>
-[22:26] <jrand0m> (so if we're following the command pattern, runCommand would block until everything required to do that command was complete)</p>
-[22:26] <human> mihi:  eheh, that's the question :-)</p>
-[22:26] <jrand0m> complete for "server 1234 privkeys" would be when the server can accept connections on port 1234</p>
-[22:26] <human> mihi: well, for TunnelServer's IMHO it should return after tunnel creation</p>
-[22:27] <jrand0m> complete for "client 234 peer" would be complete when a connection to port 234 would successfully reach peer</p>
-[22:27] <jrand0m> at least, thats my take</p>
-[22:27] <mihi> how can you determint the latter?</p>
-[22:27] <jrand0m> I really don't feel strongly either way</p>
-[22:27] <jrand0m> perhaps a ping?</p>
-[22:27] * Sciatica has joined #i2p</p>
-[22:28] <mihi> and if the peer goes down just after the ping?</p>
-[22:28] <mihi> imo it is impossible to do network apps without callbacks</p>
-[22:28] <jrand0m> right</p>
-[22:28] <mihi> or lotsa threads, and i prefer callback on threads synchronized to death</p>
-[22:29] <jrand0m> perhaps it should only return after its able to /attempt/ to connect?  </p>
-[22:29] <jrand0m> or maybe the command pattern isn't the desired pattern</p>
-[22:29] <mihi> that's what it's doing now. and what result should it return then?</p>
-[22:30] <mihi> the point is that you want to have a result (different from an int for the connection id)</p>
-[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</p>
-[22:30] * mihi cannot think of any other info that is known at that point.</p>
-[22:30] <jrand0m> agreed, me neither.</p>
-[22:31] <dup> 0!</p>
-[22:31] <mihi> and genkey should wait? okay, if you think so.</p>
-[22:31] <human> mihi: well, something like a status ("ok" or "error") and error messages...</p>
-[22:31] <mihi> human: error messages will be "too late" imo</p>
-[22:31] <mihi> but do what you want...</p>
-[22:32] <mihi> as long as you make it work with the streaming api afterwards as well...</p>
-[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</p>
-[22:32] <dup> mihi is wise.</p>
-[22:32] <human> human: some can be communicated immediately (e. g. when the tunnel port is still in use)</p>
-[22:32] <mihi> human is talking to himself ;)</p>
-[22:32] <human> oops! :-)</p>
-[22:35] <human> maybe we should see what kind of applications are being built upon I2PTunnel</p>
-[22:35] <human> the asynchronous interface is the Right Thing(TM), but it's more complicated to use</p>
-[22:35] <jrand0m> I think it would be best if we could keep the same functionality for the current software - including the gui.</p>
-[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)</p>
-[22:35] <FillaMent> smake me as needed</p>
-[22:35] <FillaMent> smack</p>
-[22:36] * jrand0m smake's FillaMent</p>
-[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)</p>
-[22:36] * kaji has a completely off-topic idea</p>
-[22:36] * FillaMent resigns himself to advocacy =)</p>
-[22:37] <human> but if mihi application needs to monitor the tunnels state, then the asynchronous interface is a Must(TM)</p>
-[22:37] <jrand0m> human> java -jar lib/I2PTunnel.jar\n.  We need to support async.</p>
-[22:37] <kaji> i2p as a java applet so you can run it from strange computers quickly by going to a website</p>
-[22:37] * Sciatica has quit IRC (EOF From client)</p>
-[22:37] <human> jrand0m: yes, then we must rework the TunnelManager :-)</p>
-[22:37] <jrand0m> kaji> i2p 3.0 :)</p>
-[22:38] <jrand0m> agreed human, the tunnelmanager implementation was a quick and dirty impl</p>
-[22:38] <jrand0m> do you think you could look into how that'd need to proceed?</p>
-[22:38] * human can volunteer to adapti the TunnelManager to the asynchronous interface, when ready</p>
-[22:38] <jrand0m> w00t :)</p>
-[22:40] <jrand0m> ok, are we ready for agenda item 3) I2COCP</p>
-[22:40] <human> otherwise, it would be possible to create sync and async methods for I2PTunnel</p>
-[22:40] <jrand0m> true</p>
-[22:40] <jrand0m> but duplication might be overkill when a little refactoring would serve the purpose</p>
-[22:41] * baffled has quit IRC (Leaving)</p>
-[22:41] <duck> personal concern about the tunnels: apps not closing them, so your whole tunnelmanager becomes flooded</p>
-[22:41] <human> jrand0m: yes, we should choose the easiest solution between reworking the TunnelManager or adding new APIs to I2PTunnel :-)</p>
-[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!])</p>
-[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?)</p>
-[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</p>
-[22:43] <jrand0m> (and hence the old ones wont work)</p>
-[22:44] * MrEcho 's email sent</p>
-[22:46] <jrand0m> anything else for the tunnel discussion?  (this obviously isn't the end of tunnel discussions overall ;)</p>
-[22:47] * dup is now known as dm</p>
-[22:47] <jrand0m> ok, I2COCP</p>
-[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 :)</p>
-[22:48] <wiht> That is a somewhat long name, even abbreviated.</p>
-[22:48] * jrand0m now calls I2COCP "Wilma"</p>
-[22:48] <human> jrand0m: well, i was going to write the same words :-)</p>
-[22:48] <jrand0m> heh cool</p>
-[22:49] <jrand0m> ok, jumping on to 4) roadmap</p>
-[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</p>
-[22:49] <jrand0m> agreed</p>
-[22:49] <jrand0m> the intent is that they'd use I2CP</p>
-[22:50] <jrand0m> (as all java apps, i2ptunnel and the streaming library included, use that)</p>
-[22:50] <human> jrand0m: yes</p>
-[22:50] <MrEcho> I2PDNS "Janessa"</p>
-[22:50] <jrand0m> but you're right, they'd want streaming too, so either tunnelmanager->i2ptunnel or i2cocp->streaming lib</p>
-[22:50] * jrand0m has never met a Janessa</p>
-[22:51] * Sciatica has joined #i2p</p>
-[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</p>
-[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</p>
-[22:52] <MrEcho> human, sounds good</p>
-[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</p>
-[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 :-)</p>
-[22:53] * w0rmus has quit IRC (Lost terminal)</p>
-[22:53] <jrand0m> word.  that'd be best for now</p>
-[22:54] <jrand0m> ok, any comments on the roadmap?  </p>
-[22:55] <jrand0m> [nothing to see here, la la]</p>
-[22:55] <jrand0m> ok, 5) i2pIM</p>
-[22:55] <jrand0m> thecrypto isn't here, so we can just wait for a post to i2p@ with updates :)</p>
-[22:55] <wiht> We have Jabber now, if I am not mistaken. Do we still need i2pIM?</p>
-[22:55] <jrand0m> yes</p>
-[22:55] <jrand0m> jabber has a server that gets cleartext.</p>
-[22:56] <wiht> Oh. Very well, then; I was not aware of this.</p>
-[22:56] <jrand0m> thats two strikes (a server, and cleartext)</p>
-[22:56] <jrand0m> its a good solution for some things though, certainly</p>
-[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.</p>
-[22:57] <jrand0m> (but once thing at a time)</p>
-[22:57] <jrand0m> actually, speaking of the devil, 6) i2psnark :)</p>
-[22:57] <human> jrand0m: i sometimes used jabber with gnupg...</p>
-[22:57] <jrand0m> for >2 person chats?</p>
-[22:58] <jrand0m> for one on one, I totally agree there are existing solutions</p>
-[23:01] <jrand0m> ok, on to a fun one, 7) introducing I.Toopie :)</p>
-[23:01] <human> how would you implement encrypted >2 people chats? a shared private key?</p>
-[23:01] <jrand0m> yes human</p>
-[23:01] <jrand0m> or through n! shared keys in the group</p>
-[23:02] <human> well, maybe it could be done above the existing jabber protocol...</p>
-[23:02] <mihi> human: a shared symmetric key sent to all participants</p>
-[23:02] <jrand0m> the hard part is dealing with joins & leaves - key rotation /etc</p>
-[23:03] * Sciatica has quit IRC (Ping timeout)</p>
-[23:03] <jrand0m> its in no way a trivial issue.  its really really really hard.</p>
-[23:03] * mihi acks</p>
-[23:03] * human agrees</p>
-[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)</p>
-[23:04] <jrand0m> but thecrypto can best describe his plans</p>
-[23:04] <jrand0m> (though its my understanding he's still open to ideas for how to deal with groups)</p>
-[23:05] * Sciatica has joined #i2p</p>
-[23:06] <jrand0m> ok, moving on :)  [further discussion on i2p@, etc]</p>
-[23:06] <wiht> What is I.Toopee, though?</p>
-[23:06] <lucky> the mascot...</p>
-[23:06] <jrand0m> I.Toopie is a guy holding a yellow mask in front of his face</p>
-[23:06] * lucky shudders.</p>
-[23:07] <lucky> uh huh.</p>
-[23:07] <lucky> can i see it?</p>
-[23:07] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?I2PLogo</p>
-[23:07] * mihi_backup has quit IRC (EOF From client)</p>
-[23:07] <lucky> i have added java to my compile queue...</p>
-[23:07] <lucky> but.. lol</p>
-[23:07] <lucky> i already have 7 things running</p>
-[23:07] <lucky> it'll be a while.</p>
-[23:08] <lucky> aw, cute :P</p>
-[23:08] <MrEcho> lol</p>
-[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.</p>
-[23:08] <jrand0m> and, yeah, its cute ;)</p>
-[23:08] <mihi> are some imgs broken or is my browser buggy?</p>
-[23:08] <jrand0m> yeah, some are broken</p>
-[23:09] <jrand0m> (they were put on temporary hosting sites 3 months ago)</p>
-[23:09] <MrEcho> I.Toopie's stick is now all yellow ... </p>
-[23:09] <MrEcho> changed lastnight</p>
-[23:09] <jrand0m> it is?</p>
-[23:09] <jrand0m> people should UPDATE THE WIKI then </p>
-[23:09] <jrand0m> ;)</p>
-[23:09] <MrEcho> hehe</p>
-[23:09] <MrEcho> i dont have the pic anymore .. sorry</p>
-[23:10] <wiht> I see the pictures with Opera, but not with Mozilla somewhy.</p>
-[23:10] <jrand0m> you can see http://img.villagephotos.com/p/2003-10/437060/badass.jpg ?</p>
-[23:10] <jrand0m> (thats one of the images on that page)</p>
-[23:11] <duck> Access Denied (User Account Disabled)</p>
-[23:11] <jrand0m> yeah, same here.</p>
-[23:11] <MrEcho> i can see it</p>
-[23:11] <jrand0m> but yes, DrWoo has done some kickass stuff with I.Toopie</p>
-[23:11] <MrEcho> moz 1.5</p>
-[23:11] * soros has quit IRC (EOF From client)</p>
-[23:11] * mihi_away has joined #i2p</p>
-[23:11] * lucky has quit IRC (EOF From client)</p>
-[23:12] <jrand0m> same here MrEcho.   strange.</p>
-[23:12] <wiht> MrEcho: I am using Mozilla 1.4.</p>
-[23:12] <jrand0m> (same as in I'm on moz 1.5 and I'm getting access denied)</p>
-[23:13] * jrand0m looks forward to a tray icon w/ i.toopie :)</p>
-[23:13] <jrand0m> ok, moving on to 8) chess server</p>
-[23:14] * Sciatica has quit IRC (Ping timeout)</p>
-[23:14] * ion has quit IRC (Ping timeout)</p>
-[23:14] <jrand0m> the latest hosts.txt (http://i2p.dnsalias.net/i2p/hosts.txt) contains the reference for chess.fillament.i2p</p>
-[23:14] <jrand0m> you can use any old FICS client or just telnet to that and play away :)</p>
-[23:14] <jrand0m> (yay)</p>
-[23:15] <kaji> is there a goog fics client for windows?</p>
-[23:15] <jrand0m> dunno, I ended up using telnet</p>
-[23:15] <wiht> Does eboard work?</p>
-[23:15] <jrand0m> (which had some fairly tough rampup to learn the commands)</p>
-[23:15] * ion has joined #i2p</p>
-[23:16] <jrand0m> dunno</p>
-[23:16] * BpX has joined #i2p</p>
-[23:16] <wiht> I will try it later.</p>
-[23:16] <jrand0m> cool, if you could post up what you find, that'd be great</p>
-[23:17] <jrand0m> ok, 9) DHT</p>
-[23:17] * wilde has quit IRC (Ping timeout)</p>
-[23:17] <jrand0m> we still don't have a dht, but perhaps this is a lead for something we can start to port</p>
-[23:18] <jrand0m> (it uses UDP so getting it to use I2CP wouldn't be hard)</p>
-[23:18] <MrEcho> dht???</p>
-[23:18] <MrEcho> im blanking on that one</p>
-[23:18] <jrand0m> MrEcho> see [10] in the email ;)</p>
-[23:18] <jrand0m> http://wiki.invisiblenet.net/iip-wiki?DHT</p>
-[23:18] <Nightblade> entropy is a good enough temporary solution</p>
-[23:18] <jrand0m> agreed</p>
-[23:19] <jrand0m> though I think we need to look at a long term solution as well</p>
-[23:19] * soros has joined #i2p</p>
-[23:19] * lucky has joined #i2p</p>
-[23:20] * human is worried about gcj/kaffe compatibility with DHTs like Bamboo (http://bamboo-dht.org/)</p>
-[23:20] <jrand0m> yeah, bamboo is 1.4</p>
-[23:20] <MrEcho> afk</p>
-[23:20] <jrand0m> thats the glory of i2cp though - the router & tunnels can be gcj'ed, while things that access them can be whatever</p>
-[23:21] <jrand0m> it /is/ purely for an app though - not as part of the core</p>
-[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</p>
-[23:22] <jrand0m> (being able to post uncensorable content anonymously would be a good useful thing)</p>
-[23:22] <jrand0m> s/uncensorable/very censorship resistant/</p>
-[23:23] <human> jrand0m: ah, ok - i thought that bamboo was going to replace Kademlia for the NetworkDB :-)</p>
-[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</p>
-[23:23] <jrand0m> Nightblade> right, but the squid isn't scalable</p>
-[23:24] <Nightblade> yeah i think it would be interesting to have a kind of distributed JAP</p>
-[23:24] <jrand0m> agreed</p>
-[23:24] <jrand0m> so that's also another thing that would be great if people could check into :)</p>
-[23:24] <mihi> Nightblade: the prob is abuse handling - i won't open my box for any outgoing http</p>
-[23:24] <jrand0m> I'm sure some people will though</p>
-[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</p>
-[23:25] <Nightblade> yeah i think it would have to have some kind of access controls</p>
-[23:25] <Nightblade> blacklist or whitelist</p>
-[23:25] <jrand0m> right</p>
-[23:25] <Nightblade> of domain names</p>
-[23:26] <jrand0m> its the "exit policy" system.  though this is a whole project in and of itself</p>
-[23:27] <MrEcho> it could ride on the DNS system... i guess</p>
-[23:27] <jrand0m> certainly</p>
-[23:27] <wiht> mihi: What if you limit the bandwidth used? Or is it the websites accessed that could get you in trouble?</p>
-[23:27] <MrEcho> at a very later date lol</p>
-[23:27] <jrand0m> wiht> many providers explicitly disallow running servers of any kind</p>
-[23:28] <MrEcho> verizon fucks with port 21 for sure...</p>
-[23:28] <wiht> jrand0m: Oh. Yes, that is a problem.</p>
-[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</p>
-[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</p>
-[23:29] <jrand0m> agreed.  though broadcast isn't possible without brute forcing a ~2^2300 keyspace ;)</p>
-[23:30] <jrand0m> right mihi, people in oppresive regimes would not be able to safely run outproxies</p>
-[23:30] <wiht> mihi: What was the lawsuit? I do not remember.</p>
-[23:30] * dm has quit IRC (Ping timeout)</p>
-[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</p>
-[23:30] <jrand0m> right Nightblade</p>
-[23:30] <Nightblade> request broadcast i mean</p>
-[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</p>
-[23:31] <jrand0m> people may want to check out crowds or rewebber to see other projects that worked on this same task</p>
-[23:31] <wiht> mihi: Ah. Thank you for the explanation. I see understand you are concerned now.</p>
-[23:31] * mihi_away has quit IRC (Ping timeout)</p>
-[23:31] <mihi> and made that change to the jap software that makes it possible to catch people. which was removed later</p>
-[23:32] <wiht> Er, I understand why you are concerned.</p>
-[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...</p>
-[23:32] <Nightblade> yeah but didn't the police seize the information anyway?</p>
-[23:32] <jrand0m> yes</p>
-[23:33] <mihi> they did...</p>
-[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</p>
-[23:34] <mihi> and they cannot give it backk, can they?</p>
-[23:34] * BpX has quit IRC (Ping timeout)</p>
-[23:36] * Sciatica has joined #i2p</p>
-[23:36] <jrand0m> ok, anything else for point 9? or are we on to 10/11) NS/DNS?</p>
-[23:36] <wiht> I would like to make a brief comment about the installer after topic 10.</p>
-[23:37] <jrand0m> 'k perhaps lets hit that now, since NS/DNS might not be uber-brief? ;)</p>
-[23:37] <wiht> All right. The router has a start script and a stop script.</p>
-[23:37] <jrand0m> right</p>
-[23:37] <wiht> I would like all of the services to be done that way--to have both a start and a stop script.</p>
-[23:37] <jrand0m> most of them do</p>
-[23:37] <jrand0m> don't they?</p>
-[23:38] <jrand0m> oh, not stop scripts</p>
-[23:38] <wiht> No, just the router.</p>
-[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.</p>
-[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</p>
-[23:38] <wiht> Let's say I want to start the eep and nntp on bootup. Currently, I can't do that.</p>
-[23:39] <jrand0m> right, you'd need to nohup startEepProxy.sh &</p>
-[23:39] <wiht> All right. By the way, where are these scripts in CVS?</p>
-[23:39] <MrEcho> k im back</p>
-[23:39] * mihi_away has joined #i2p</p>
-[23:39] <jrand0m> wiht> the scripts are in the Install.java (aka hacked)</p>
-[23:39] <wiht> jrand0m: Thanks./</p>
-[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</p>
-[23:41] <jrand0m> ok, on to 10/11) ns/dns</p>
-[23:41] <MrEcho> well check my email</p>
-[23:41] <MrEcho> theres a few things i forgot about putting in there</p>
-[23:41] <jrand0m> unfortunately your email didn't really go through to the web interface well :/</p>
-[23:41] <MrEcho> like "temp" names</p>
-[23:41] <MrEcho> ??</p>
-[23:42] * Sciatica has quit IRC (Ping timeout)</p>
-[23:42] * ion has quit IRC (Ping timeout)</p>
-[23:42] <jrand0m> MrEcho> http://i2p.dnsalias.net/pipermail/i2p/2004-January/000072.html</p>
-[23:42] <MrEcho> because of the gif or something</p>
-[23:42] <MrEcho> shit .. i singed it</p>
-[23:43] <MrEcho> sorry</p>
-[23:43] <jrand0m> the mailing list is really intended to be text only.  pgp sigs are fine (others have posted signed things)</p>
-[23:43] <kaji> whats a good free small antivirus?</p>
-[23:43] * ion has joined #i2p</p>
-[23:43] <jrand0m> kaji> linux</p>
-[23:43] * Sciatica has joined #i2p</p>
-[23:43] <wiht> LOL.</p>
-[23:43] <kaji> that runs with my hardware</p>
-[23:43] <wiht> kaji: Try AVG Antivirus for Windows.</p>
-[23:44] * MrEcho_ has joined #i2p</p>
-[23:44] * MrEcho has quit IRC (EOF From client)</p>
-[23:44] <MrEcho_> fuckign iip</p>
-[23:44] <jrand0m> MrEcho / (and anyone else interested in the NS/DNS issue)> have you read http://zooko.com/distnames.html ?</p>
-[23:44] <MrEcho_> j, should i resend the email?</p>
-[23:44] <jrand0m> it went through to the list fine, it just didn't get web archived correctly</p>
-[23:44] <MrEcho_> ya</p>
-[23:45] <wiht> jrand0m: I did not read it yet.</p>
-[23:45] <MrEcho_> ill take a look at it later</p>
-[23:45] * mrflibble has joined #i2p</p>
-[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</p>
-[23:46] <MrEcho_> thanks J</p>
-[23:46] <kaji> its gay, it wants an email adress</p>
-[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.</p>
-[23:47] <jrand0m> kaji> email lists usually want an email address, yeah ;)</p>
-[23:47] <kaji> i mean AVG Antivirus</p>
-[23:47] <jrand0m> oh ;)</p>
-[23:48] <wiht> MrEcho has several good ideas that I did not have in my specification, such as a ban list for bad clients.</p>
-[23:49] <MrEcho_> not really a ban list</p>
-[23:49] <jrand0m> once there are 1000 clients, does that mean that it would take 125 lookups to find a value?</p>
-[23:49] <MrEcho_> no</p>
-[23:49] <wiht> Not a list, but banning bad clients is something I did not have.</p>
-[23:50] <MrEcho_> 2-4 clients for checking</p>
-[23:50] <jrand0m> so every client will have 250 entries?</p>
-[23:50] * mihi_away is now known as mihi_backup</p>
-[23:50] <MrEcho_> no</p>
-[23:50] <wiht> With what I have, it would be one lookup, possibly forwarded a couple of times to reach an authoritative server.</p>
-[23:50] <MrEcho_> clients will only have what they need</p>
-[23:51] <MrEcho_> it will keep querying other Clients untill they get data that matches for the check</p>
-[23:51] <jrand0m> so with 4 peers, it'd do a random search and on average it'd take 125 lookups</p>
-[23:51] <jrand0m> (1000/4/2)</p>
-[23:51] <jrand0m> or are the peers a DHT?</p>
-[23:52] <jrand0m> (with some maintenance protocol?)</p>
-[23:52] <jrand0m> or a search tree?</p>
-[23:52] <MrEcho_> in a way yes</p>
-[23:52] <MrEcho_> ill have a cut off on client searches, it will just query the MS</p>
-[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?</p>
-[23:54] <MrEcho_> if it doesnt find / or get enough data from Clients within a set range it will then just query the MS.</p>
-[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.</p>
-[23:54] <MrEcho_> cany u stop typing for a sec</p>
-[23:54] * jrand0m stops typing.</p>
-[23:55] <MrEcho_> its going to work .. it will have scalability, it will have security</p>
-[23:56] <MrEcho_> the more users the better it will get</p>
-[23:56] <jrand0m> so "trust me", 'eh?</p>
-[23:56] <MrEcho_> do you trust the Internet DNS system?</p>
-[23:56] <jrand0m> for some tasks.</p>
-[23:57] <jrand0m> for many, no.</p>
-[23:57] <jrand0m> (its quite easy for govts / etc to get records changed - court cases order registrars to update all the time)</p>
-[23:58] <MrEcho_> only other way of doing it is having big ass lists of Names and lots of crypto on every client</p>
-[23:58] <MrEcho_> and being dynamic .. forget about it</p>
-[23:59] * mrflibble has quit IRC (EOF From client)</p>
-[23:59] <jrand0m> I suggest reviewing zooko's paper before proceeding further, and answering his final point 5 ("why I'm wrong")</p>
-Session Time: Wed Jan 07 00:00:00 2004</p>
-[00:01] <jrand0m> ok, thats probably about it for point 10/11 (lots of future discussion still left on that, of course)</p>
-[00:02] <jrand0m> anyone have any other thoughts, etc?</p>
-[00:02] <wiht> Yes.</p>
-[00:03] <jrand0m> care to share with the class?  :)</p>
-[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.</p>
-[00:03] <jrand0m> ah cool</p>
-[00:03] <jrand0m> (same concerns go for the spec you wrote too - if you could answer zooko's last question, that'd be key :)</p>
-[00:03] * mrflibble has joined #i2p</p>
-[00:03] <wiht> Let MySQL or a similar server manage data storage, and let Java query that server.</p>
-[00:04] <duck> huh ? zooko specs?</p>
-[00:04] <wiht> I think that will be easier to implement.</p>
-[00:04] <jrand0m> duck> naw, I'm just pointing people at his old article "Names: Decentralized, Secure, Human-Meaningful: Choose Two"</p>
-[00:04] <duck> ah that</p>
-[00:04] <Nightblade> wiht: what specification is that (i missed a lot of the meeting)?</p>
-[00:04] * MrEcho has joined #i2p</p>
-[00:04] <jrand0m> (a lot easier than rehashing why supernode/centralized servers are scary security issues ;)</p>
-[00:05] * MrEcho_ has quit IRC (EOF From client)</p>
-[00:05] * mihi 'd have something for the log as well ;)</p>
-[00:05] <mihi> something longer ;)</p>
-[00:05] <mihi> *** I2Ping results:</p>
-[00:05] <mihi> + + +   eco.i2p</p>
-[00:05] <mihi> + - -   jabber.duck.i2p</p>
-[00:05] <mihi> - + +   i2pcvs.i2p</p>
-[00:05] <mihi> - + +   duck.i2p</p>
-[00:05] <mihi> - + -   jap.eco.i2p</p>
-[00:05] <jrand0m> Nightblade> it was posted to iip-dev back in... august?</p>
-[00:05] <mihi> - + +   irc.duck.i2p</p>
-[00:05] <mihi> - + +   human.i2p</p>
-[00:06] <mihi> - - +   nntp.duck.i2p</p>
-[00:06] <mihi> - - -   tc.i2p</p>
-[00:06] <mihi> - - -   dyad.i2p</p>
-[00:06] <mihi> - - -   bozo.i2p</p>
-[00:06] <mihi> - - -   ogg.aum.i2p</p>
-[00:06] <mihi> - - -   fcp.entropy.i2p</p>
-[00:06] <mihi> - - -   http.entropy.i2p</p>
-[00:06] <Nightblade> jrandom: oh, before my time.. :)</p>
-[00:06] <mihi> - - -   www.mail.i2p</p>
-[00:06] <mihi> - - -   mp3.aum.i2p</p>
-[00:06] <mihi> - - -   smtp.mail.i2p</p>
-[00:06] <wiht> Nightblade: I posted it on September 15th.</p>
-[00:06] <mihi> - - -   pop.mail.i2p</p>
-[00:06] <mihi> - - -   mp3.tc.i2p</p>
-[00:06] <mihi> - - -   lp.i2p</p>
-[00:06] <mihi> - - -   kaji.i2p</p>
-[00:06] <mihi> - - -   nm.i2p</p>
-[00:06] <mihi> - - -   squid.i2p</p>
-[00:06] <mihi> - - -   chess.fillament.i2p</p>
-[00:06] <mihi> - - -   mesh.firerabbit.i2p</p>
-[00:06] <mihi> - - -   nightblade.i2p</p>
-[00:06] <mihi> - - -   aum.i2p</p>
-[00:06] <MrEcho> gezz is anyone up and running?</p>
-[00:06] <mihi> - - -   fillament.i2p</p>
-[00:06] <mihi> *** Finished.</p>
-[00:06] <mihi> why are so many hosts down...?</p>
-[00:06] * jrand0m isn't running my servers atm</p>
-[00:07] <FillaMent> I can connect to myself on both eep and chess</p>
-[00:07] * mrflibble has quit IRC (Ping timeout)</p>
-[00:07] <jrand0m> oh wait, i2pcvs is up, neat</p>
-[00:07] <Nightblade> mihi: mine isn't up because the i2ptunnel crashes for me after a few hours</p>
-[00:07] <mihi> so my router is broken (or it's usual I2P problems...)</p>
-[00:08] <jrand0m> really Nightblade?  please report i2ptunnel crashes (bugzilla would be nice)</p>
-[00:08] <Nightblade> it is in the bugzilla</p>
-[00:08] <lucky> hi</p>
-[00:08] <Nightblade> hold..</p>
-[00:08] <FillaMent> Nightblade: what JVM?</p>
-[00:08] <Nightblade> #39</p>
-[00:08] <wiht> My router has been running for more than 12 hours now, although it had a problem in registering itself.</p>
-[00:09] <Nightblade> java version "1.4.2-p5"</p>
-[00:09] <Nightblade> on freebsd...  it could be a jvm problem, i don't know. java support isn't too good on freebsd</p>
-[00:09] <jrand0m> you're right Nightblade, my bad</p>
-[00:09] <jrand0m> thats the fairly infrequent i2cp bug </p>
-[00:09] <jrand0m> is that consistent for you?</p>
-[00:09] <Nightblade> the router is very stable for me, just the i2ptunnel server tunnel gives me problems</p>
-[00:09] <Nightblade> yeas it happened several times</p>
-[00:10] <Nightblade> i haven't tried it recently though</p>
-[00:10] * jrand0m just pulled fillament's eepsite</p>
-[00:10] <jrand0m> (first try, just noticed the window was complete)</p>
-[00:10] <FillaMent> Yeah,, I just jabbered with duck, wiht's trying to hit chess</p>
-[00:10] <jrand0m> ah cool</p>
-[00:10] <jrand0m> but yes, there are still reliability issues to be dealt with in the network.</p>
-[00:10] * FillaMent nudges people with the included winking, "He'll probably be wanting to play."</p>
-[00:10] * human 's eepsite is still up - it means that 'killall java' really helped... :-)</p>
-[00:10] <wiht> I just successfully connected to chess server.</p>
-[00:10] <duck> yeah?</p>
-[00:11] <jrand0m> lol FillaMent</p>
-[00:11] * mrflibble has joined #i2p</p>
-[00:12] <Nightblade> is it safe to run the cvs version of i2p</p>
-[00:12] <jrand0m> /me succesfully fetches human's 1984-2004: twenty years of GNU! :-) </p>
-[00:12] <jrand0m> yes Nightblade</p>
-[00:12] <FillaMent> could not get eco...</p>
-[00:12] <Nightblade> ok maybe i'll give that a try</p>
-[00:12] <duck> with freenet you should always run the latest cvs version!</p>
-[00:13] <duck> only then it is bugfree</p>
-[00:13] <duck> s/freenet/i2p/</p>
-[00:13] * jrand0m pulled eco.i2p</p>
-[00:13] <FillaMent> just got duck</p>
-[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... "</p>
-[00:13] <jrand0m> d'oh</p>
-[00:13] <duck> well, it worked actually</p>
-[00:13] <duck> ardvark could snark something from me</p>
-[00:14] <jrand0m> bt precreates the files - were the files actually valid?</p>
-[00:14] <duck> but ze did find out the next day</p>
-[00:14] <duck> because it was obscured in the logs</p>
-[00:14] <jrand0m> what, you mean the logs i2p generates are fairly insane?  nawwwwww</p>
-[00:14] <duck> no</p>
-[00:14] <duck> the i2psnark output</p>
-[00:14] <jrand0m> ah</p>
-[00:15] <duck> additionally, I suspect that snark does too much churning (sp?)</p>
-[00:15] <duck> the normal bittorrent client seems to be more easy</p>
-[00:15] <duck> also the high delays on i2p might cause premature blocks</p>
-[00:16] * mrflibble has quit IRC (Ping timeout)</p>
-[00:16] <duck> last thing is that we had to restart i2ptunnel a few times :/</p>
-[00:16] <jrand0m> agreed</p>
-[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?</p>
-[00:16] <jrand0m> so, yeah, lots of work to do</p>
-[00:16] <human> 1. let's accept it to make the TunnelManager work until the new asynchronous architecture will be roxoring</p>
-[00:17] <human> 2. your patch plain sucks, fuck off, and fuck the TunnelManager</p>
-[00:17] <human> 3. ...</p>
-[00:17] * MrEcho_ has joined #i2p</p>
-[00:17] * mihi is for 3 ;)</p>
-[00:17] * MrEcho has quit IRC (EOF From client)</p>
-[00:17] <jrand0m> 4. lets see how we can update the tunnel manager to go async?  shouldn't be too hard</p>
-[00:17] <jrand0m> the patch is good, but mihi has a point</p>
-[00:18] <human> jrand0m: yes, i agree</p>
-[00:18] <jrand0m> we still have 1+ weeks until 0.3, so we've got time until the next full release</p>
-[00:18] <human> jrand0m: but my doubt is: how long will it take to have the async interface to be implemented in the TunnelManager?</p>
-[00:18] <jrand0m> tunnelmanager itself was 2 hours, I could add async tonight</p>
-[00:19] <jrand0m> (all that needs to happen is an update to the BufferedLogging to accept .set calls)</p>
-[00:19] <human> jrand0m: (with "to have" i also mean "to have it implemented even in I2PTunnel)</p>
-[00:19] <jrand0m> (or .nofity/etc)</p>
-[00:19] <jrand0m> right</p>
-[00:19] * mrflibble has joined #i2p</p>
-[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</p>
-[00:21] <human> jrand0m: i could add the async interface to TunnelManager myself, but the interface still doesn't exist :-)</p>
-[00:22] <jrand0m> right, just add public void notifyEvent(String eventName, Object value); to Logging.java</p>
-[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"</p>
-[00:23] <jrand0m> 0.3 is still a ways off</p>
-[00:23] <mihi> 0.3 should have the streaming api anyway, shouldn't it?</p>
-[00:23] <human> jrand0m: i'm talking about the worst case</p>
-[00:23] <wiht> jrand0m: Maybe there should be another version before 3.0 to settle these issues?</p>
-[00:23] <jrand0m> yes mihi</p>
-[00:23] <mihi> human: the worst case is "cvs rollback && patch -p0 your.patch"</p>
-[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?</p>
-[00:26] <FillaMent> jrand0m: do you have a job?</p>
-[00:27] <jrand0m> i2p</p>
-[00:27] <duck> get 1.0 done!</p>
-[00:27] <FillaMent> I mean a source of income</p>
-[00:27] <jrand0m> :)</p>
-[00:27] <FillaMent> that you have to work for</p>
-[00:27] <jrand0m> income is overrated.</p>
-[00:27] * jrand0m fired my boss</p>
-[00:27] <Nightblade> "will code for food"  - that's my motto</p>
-[00:27] <Nightblade> lol</p>
-[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...</p>
-[00:28] <human> jrand0m: ok, i'll work on your changes later/tomorrow</p>
-[00:28] <FillaMent> Job/Money, sleep/hygiene, food, side projects, social life: Choose any 3</p>
-[00:29] * jrand0m only choses one.</p>
-[00:29] <jrand0m> word human</p>
-[00:30] <FillaMent> Anyone have any other ideas for "just tunnel to" services that would be nice to have on the network?</p>
-[00:30] * jrand0m still wants a telnet based Adventure :)</p>
-[00:30] <jrand0m> or a waffle bbs</p>
-[00:30] * duck is now known as enduser</p>
-[00:30] * jrand0m kicks enduser</p>
-[00:31] <jrand0m> (damn, no ops)</p>
-[00:31] <FillaMent> For OS/2 there was a comm driver that could map a comm port to a TCP port =)</p>
-[00:31] <enduser> what difference will I see as enduser when I2PTunnel uses the SteamingAPI?</p>
-[00:31] * enduser is now known as duck</p>
-[00:31] <jrand0m> none</p>
-[00:31] <human> lol</p>
-[00:31] <FillaMent> FillaMent: friend of mine ran a BBS that way for a while</p>
-[00:31] <jrand0m> performance, and perhaps anonymity</p>
-[00:31] * human would like a I2P tunnel to a rootshell</p>
-[00:32] <human> any volunteer? :-)</p>
-[00:32] <duck> rootshell on a UML</p>
-[00:32] <jrand0m> chroot'ed rootshells would be good</p>
-[00:32] <jrand0m> or UML'ed :)</p>
-[00:32] <FillaMent> human: had I a spare boxen, I'd do it</p>
-[00:32] <jrand0m> hehe FillaMent</p>
-[00:32] <duck> vnc connection to my vmware win98?</p>
-[00:32] <FillaMent> seriously though guys...</p>
-[00:32] <wiht> E-mail server would be a good one as well. Or do we have that already?</p>
-[00:32] <FillaMent> wiht: think TC has pop and SMTP</p>
-[00:33] <jrand0m> thats aum, but they're offline, as his box is offline</p>
-[00:33] * human could offer telnet accounts on his GNU/Hurd system...</p>
-[00:33] <jrand0m> ooOOoo</p>
-[00:33] <FillaMent> well, I'm not too keen on setting up open SMTP access yet</p>
-[00:33] <jrand0m> understandable</p>
-[00:34] <FillaMent> maybe when the network is more stable and I've got money to up my bandwidth</p>
-[00:34] <wiht> How about a PGP keyserver?</p>
-[00:34] <mihi> FillaMent: you could set up a tunnel pointing to a cleartext remailer</p>
-[00:34] <FillaMent> wiht: now THAT's a great idea =)</p>
-[00:35] <FillaMent> mihi heh... I could just point the tunnel to my ISP SMTP box =)</p>
-[00:35] <mihi> FillaMent: this would make *you* be resposible for abuse...</p>
-[00:35] <mihi> s/be//</p>
-[00:35] <duck> http://www.mit.edu/people/marc/pks/pks.html</p>
-[00:36] <duck> seriously, should duck enterprises consider running a pgp keyserver?</p>
-[00:37] <FillaMent> duck: I was poking into that myself... you want to handle it?</p>
-[00:37] <duck> we have been one of the most stable service providers according to mihi's independent ping logs</p>
-[00:37] <jrand0m> hehe</p>
-[00:37] <wiht> duck: Yes, please consider it.</p>
-[00:37] <jrand0m> btw duck, how do you do that?  do you restart periodically or just run on a reliable OS and JVM?</p>
-[00:38] <FillaMent> question: does the JVM cache DNS resolves?</p>
-[00:38] <duck> restarting is for kernel updates</p>
-[00:38] <jrand0m> yes, but you can do some nasty trickery to avoid it FillaMent</p>
-[00:38] * wiht notes that the meeting has gone on for 2h40m now.</p>
-[00:38] <jrand0m> oh yeah,</p>
-[00:39] * mrflibble sticks his hand up</p>
-[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</p>
-[00:39] <jrand0m> sup mrflibble?</p>
-[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...</p>
-[00:39] <FillaMent> how would that affect my router's presence on the network?</p>
-[00:40] <mrflibble> my box could be availalbe for some kind of demony thing</p>
-[00:40] <jrand0m> cool FillaMent, shouldn't be much of a problem, as long as you point to your dyndns</p>
-[00:40] <wiht> mrflibble: demony?</p>
-[00:40] <mrflibble> i guess it depends how much bandwidth the thing would use</p>
-[00:40] <mrflibble> daemony</p>
-[00:40] <jrand0m> w3rd mrflibble - has the router been working reliably for you, or are you just being a good sameritan?  :)</p>
-[00:41] <mrflibble> not really, but that's because my local bw is saturated atm</p>
-[00:41] <mrflibble> im not running it on my colo yet</p>
-[00:41] <mrflibble> want to play around with it locally first</p>
-[00:41] <jrand0m> ah cool.  yeah, i2p isn't really ready for wide deployment, still for testing mainly</p>
-[00:42] <FillaMent> Heh.. I'll point a tunnel to my CUPS server and you can have anonymous printing =)</p>
-[00:42] <jrand0m> rofl</p>
-[00:42] <mrflibble> if there's something that u want me to run that would use <40gb bw a month, lmk</p>
-[00:42] <FillaMent> just include a banner page so I know where to mail the hardcopy =)</p>
-[00:42] <mrflibble> hehe</p>
-[00:43] <jrand0m> wikked mrflibble, I'm sure we'll take you up on that :)</p>
-[00:43] <mihi> banner | lpr ? ;)</p>
-[00:43] <FillaMent> mihi you cah set up CUPS with a banner page</p>
-[00:43] <mrflibble> oky doky!</p>
-[00:43] <mihi> banner will most likely create lots of pages ;)</p>
-[00:43] <jrand0m> ok, before we get to the mixminion->printer->post office gateway discussion, lets close this meeting ;)</p>
-[00:44] * jrand0m readies the *baf*'er</p>
-[00:44] * jrand0m *baf*'s the meeting closed.</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/72.rst b/i2p2www/meetings/72.rst
new file mode 100644
index 00000000..d3eb7625
--- /dev/null
+++ b/i2p2www/meetings/72.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 6, 2004 @ 22:00 CET
+============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/73.log b/i2p2www/meetings/73.log
index 49234fac..0780e290 100644
--- a/i2p2www/meetings/73.log
+++ b/i2p2www/meetings/73.log
@@ -1,143 +1,137 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 73{% endblock %}
-{% block content %}<h3>Tuesday, Jan 13, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:01] <jrand0m> 0) hi</p>
-[22:01] <jrand0m> 1) 0.2.3.4</p>
-[22:01] <jrand0m> 2) 0.3</p>
-[22:01] <jrand0m> 3) streaming library, I2COCP, CI2CP</p>
-[22:01] <jrand0m> 4) apps</p>
-[22:01] <jrand0m> 5) ???</p>
-[22:01] <jrand0m> 0) hi</p>
-[22:01] <jrand0m> hi everyone</p>
-[22:01] <jrand0m> y'all seen http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html?</p>
-[22:01] <jrand0m> if not, now's your chance :)</p>
-[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 </p>
-[22:02] <MrEcho> .</p>
-[22:02] <jrand0m> w3rd</p>
-[22:02] <jrand0m> ok, moving on, 1) 0.2.3.4</p>
-[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</p>
-[22:03] <jrand0m> e.g. tunnelmanager isn't in 0.2.3.3 yet</p>
-[22:03] <MrEcho> col</p>
-[22:03] <jrand0m> it'll be backwards incompatible, because i'm mean</p>
-[22:04] <jrand0m> jumping onto 2) 0.3</p>
-[22:04] <MrEcho> :P</p>
-[22:04] <jrand0m> that'll be out fairly soon, but obviously not on thursday</p>
-[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</p>
-[22:05] <MrEcho> cool</p>
-[22:05] <jrand0m> well, moving right along to 3) streaming lib / etc</p>
-[22:05] <jrand0m> well, thats all spelled out in the email :)</p>
-[22:05] * eco has joined #i2p</p>
-[22:05] * mihi_away is now known as mihi</p>
-[22:05] <jrand0m> if anyone wants to get involved in it, please let me know</p>
-[22:06] * ion has joined #i2p</p>
-[22:06] <jrand0m> 'lo eco, mihi, ion</p>
-[22:06] <jrand0m> ok, moving on to 4) apps </p>
-[22:06] <jrand0m> anyone working on an app that will run over i2p that has anything to add?</p>
-[22:07] * wiht has joined #i2p</p>
-[22:07] <MrEcho> re ask the quest j</p>
-[22:07] <jrand0m> well, we're at the last agenda item, so might as well :)</p>
-[22:08] <MrEcho> wiht .. get my email?</p>
-[22:08] <jrand0m> anyone have anything to bring up outside the http://i2p.dnsalias.net/pipermail/i2p/2004-January/000082.html post?</p>
-[22:08] <wiht> Yes, let me read it.</p>
-[22:08] <jrand0m> MrEcho> have you read zooko's naming page yet?</p>
-[22:08] * jar has joined #i2p</p>
-[22:08] <MrEcho> no .. lost the link</p>
-[22:09] <jrand0m> (from the logs last week, http://zooko.com/distnames.html)</p>
-[22:10] <jrand0m> anyone have anything to add, or are we at a record breaking 10 minute meeting?</p>
-[22:10] <MrEcho> still working on my dns idea</p>
-[22:10] <jrand0m> coo'</p>
-[22:10] <wiht> MrEcho: Yes, I would like to work together on naming service.</p>
-[22:10] <MrEcho> sweet</p>
-[22:11] <wiht> But I will not have time until next Wednesday.</p>
-[22:11] <MrEcho> ok</p>
-[22:11] <MrEcho> will give me some time to finish up on a few things</p>
-[22:11] <mrflibble> how long till the meet?</p>
-[22:11] <jrand0m> -11 minutes</p>
-[22:11] <mrflibble> oops</p>
-[22:11] * mrflibble is v late</p>
-[22:11] <mrflibble> :)</p>
-[22:12] <jrand0m> (we've gone through the 5 agenda items very very quicky :)</p>
-[22:12] * mrflibble goes back to lurking and the backscroll</p>
-[22:12] <jrand0m> heh</p>
-[22:12] <wiht> jrand0m: Have you measured how much CPU is used per tunnel by the server?</p>
-[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?</p>
-[22:15] <jrand0m> they shouldn't consume 20% of the cpu, or even 1%</p>
-[22:15] <jrand0m> (for client tunnels - server tunnels may consume more)</p>
-[22:15] <wiht> Server tunnels.</p>
-[22:16] * eco has quit IRC (Ping timeout)</p>
-[22:16] <wiht> But that will probably be dependent on your CPU speed, so that was a badly stated question.</p>
-[22:16] <jrand0m> server tunnels before the streaming lib will require cpu load whenever a new peer connects </p>
-[22:18] <wiht> All right.</p>
-[22:19] <duck> are we at #5 already?</p>
-[22:19] * ion has quit IRC (Ping timeout)</p>
-[22:19] <jrand0m> yup</p>
-[22:20] * duck mentions the hosting options that home.duck.i2p provides</p>
-[22:20] <jrand0m> ooOOoo</p>
-[22:20] <duck> it hasnt been tested by anybody besides me though</p>
-[22:20] <duck> waiting for betatester Ardvark to show up</p>
-[22:20] <jrand0m> so the hosting lets someone run apache / etc?</p>
-[22:21] <jrand0m> (or do they have to run the i2p router?</p>
-[22:21] <duck> neither</p>
-[22:21] <duck> they can put their html files on /home/username/public_html/</p>
-[22:21] <duck> and it will show up on http://home.duck.i2p/~username/</p>
-[22:21] <jrand0m> ah nice</p>
-[22:21] <jrand0m> php support?  cgi / .pl / etc?  or just html?</p>
-[22:22] <jrand0m> (thats kick fucking ass, in any case)</p>
-[22:22] <duck> php and html</p>
-[22:22] <jrand0m> wwwwwwwwwicked</p>
-[22:22] <mihi> duck: won't that compromize your anonymity?</p>
-[22:22] <duck> how?</p>
-[22:22] <mihi> phpshell?</p>
-[22:22] <mihi> or is the full apache in a vmware/UML box?</p>
-[22:22] <duck> system, exec, etc are disabled</p>
-[22:23] <duck> plus the host cant connect to the outsite</p>
-[22:23] * wilde has joined #i2p</p>
-[22:23] <duck> (it is inside an UML box)</p>
-[22:23] <duck> (pl and other cgis are too difficult to debug without shell access, plus they often break)</p>
-[22:23] * mihi_backup has joined #i2p</p>
-[22:23] <jrand0m> jsp access?  :)</p>
-[22:23] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))</p>
-[22:23] <duck> ofcourse not</p>
-[22:24] <mihi> and why not ssh access as well, when it's an UML box?</p>
-[22:24] <duck> because the average IIP user will start running forkbombs</p>
-[22:24] <jrand0m> with ssh access, they could traceroute i2p.dnsalias.net</p>
-[22:24] <mihi> man ulimit</p>
-[22:24] <jrand0m> ah true</p>
-[22:24] <mihi> man limiting cpu time on uml boxes.</p>
-[22:25] <mihi> (okay, it will crash apache, shit...)</p>
-[22:25] <duck> man run your own host :)</p>
-[22:25] <jrand0m> hehe</p>
-[22:25] <lucky> hi</p>
-[22:25] <duck> I'll add it on the todo</p>
-[22:25] <jrand0m> a reliable hosting service provider will RULE</p>
-[22:25] <kaji> now all we need is a wiki</p>
-[22:25] * wiht has left #i2p (wiht)</p>
-[22:26] * lucky has a reliable net connection...</p>
-[22:26] <duck> you already have a wiki</p>
-[22:26] <jrand0m> kaji> duck.i2p has one</p>
-[22:26] <duck> wiki.invisiblenet.net</p>
-[22:26] <jrand0m> that too</p>
-[22:26] <kaji> oh sweet then</p>
-[22:26] <jrand0m> (yeah, the main i2p wiki is http://wiki.invisiblenet.net/iip-wiki?I2P )</p>
-[22:26] * dm has quit IRC (Ping timeout)</p>
-[22:28] * mihi is now known as mihi_away</p>
-[22:28] * mihi_backup has quit IRC (Ping timeout)</p>
-[22:29] <jrand0m> 'k, anything else before we close out the meeting?</p>
-[22:29] <kaji> doh, i missed the meeting?</p>
-[22:29] <jrand0m> we're not quite done yet, but about it</p>
-[22:29] <lucky> meeting?</p>
-[22:29] <lucky> Oh, thats so not fair</p>
-[22:29] <lucky> i just got home.</p>
-[22:29] <wilde> are there logs anywhere?</p>
-[22:29] <wilde> meeting log</p>
-[22:30] * lucky has a log...</p>
-[22:30] <kaji> can some one write a howto for using wget over i2p in windows?</p>
-[22:30] <jrand0m> meeting logs at http://wiki.invisiblenet.net/iip-wiki?Meetings</p>
-[22:30] <jrand0m> kaji you'll probably need to add the http_proxy to the environment</p>
-[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 :)</p>
-[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</p>
-[22:32] <jrand0m> word kaji!</p>
-[22:32] * jrand0m *baf*s the meeting closed on that note</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/73.rst b/i2p2www/meetings/73.rst
new file mode 100644
index 00000000..1c4d0d08
--- /dev/null
+++ b/i2p2www/meetings/73.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 13, 2004 @ 22:00 CET
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/74.log b/i2p2www/meetings/74.log
index f715f41d..5ddaf6ba 100644
--- a/i2p2www/meetings/74.log
+++ b/i2p2www/meetings/74.log
@@ -1,190 +1,184 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 74{% endblock %}
-{% block content %}<h3>Tuesday, Jan 20, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:07] <jrand0m> agenda:</p>
-[22:07] <jrand0m> 0) hi (read http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html)</p>
-[22:07] <jrand0m> 1) router dev status</p>
-[22:07] <jrand0m> 2) twisted-i2p</p>
-[22:07] <jrand0m> 3) unit tests</p>
-[22:07] <jrand0m> 4) network testing / monitoring</p>
-[22:07] <jrand0m> 5) ???</p>
-[22:07] <jrand0m> 0) hi</p>
-[22:07] <jrand0m> hi</p>
-[22:07] * jrand0m waves</p>
-[22:07] <dm> ohhhh meeting!</p>
-[22:07] * dm waves back.</p>
-[22:07] <jrand0m> 9p gmt every tuesday :)</p>
-[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</p>
-[22:08] <jrand0m> 1) router dev status</p>
-[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</p>
-[22:09] <duck> reading...</p>
-[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)</p>
-[22:11] * jnk has joined #i2p</p>
-[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</p>
-[22:11] <jrand0m> ok, moving on</p>
-[22:12] <jrand0m> 2) twisted+i2p</p>
-[22:12] <duck> I do have errors</p>
-[22:12] <duck> but probably due to others</p>
-[22:12] <jrand0m> dropped messages and unknown tunnels, right?</p>
-[22:12] <duck> checking</p>
-[22:13] <jrand0m> (those are the errors I see with one of my 'live' routers but not on the test network)</p>
-[22:13] <duck> 22:13:15.371 ERROR [ Sender 1148] er.transport.phttp.PHTTPSender: Error sending the message</p>
-[22:13] <jrand0m> ah ok, yeah, i've been smacking around the phttp relay too</p>
-[22:13] <duck> 21:01:01.509 ERROR [JobQueue28  ] eDatabaseSearchReplyMessageJob: Invalid router info returned from [Rout</p>
-[22:14] <jrand0m> hmm that one is funky - could you bounce me the stacktrace?</p>
-[22:14] <duck> I'll put it up.</p>
-[22:14] <duck> .</p>
-[22:14] <jrand0m> gracias</p>
-[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</p>
-[22:16] <jrand0m> ok, back to 2)</p>
-[22:16] <jrand0m> human has put together a way to use i2p via python and the twisted framework (yay!)</p>
-[22:17] <jrand0m> see his email for more info (http://i2p.dnsalias.net/pipermail/i2p/2004-January/000100.html) </p>
-[22:17] <jrand0m> anything to add human?  (if you're here)</p>
-[22:17] <duck> it is _so_ cool</p>
-[22:17] <jrand0m> yeah, the sample code for the echo server and client look kick-ass</p>
-[22:18] <jrand0m> ok, moving on to 3) unit tests</p>
-[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.  </p>
-[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) </p>
-[22:21] <duck> probably it is difficult to test more complex things</p>
-[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</p>
-[22:21] <jrand0m> right, the unit tests as is just test the basics</p>
-[22:21] <duck> like routing, tcp stuff etc</p>
-[22:21] <jrand0m> right</p>
-[22:21] * dm sees a debate on value of unit testing coming.</p>
-[22:21] <jrand0m> but things like the AESInputStream can be tested in collaboration with AESOutputStream</p>
-[22:22] <duck> unit test = kickass</p>
-[22:22] <jrand0m> (and for those watching their logs closely, there's been some funky "pushed back" behavior during decrypt streaming)</p>
-[22:22] <jrand0m> definitely.</p>
-[22:23] <jrand0m> unit tests are just for the, er, units.  not for the larger components (which is what agenda item 4 is about ;)</p>
-[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)</p>
-[22:24] * mihi_away is now known as mihi</p>
-[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.</p>
-[22:25] <jrand0m> wikked!</p>
-[22:25] <dm> No promises though.</p>
-[22:25] <jrand0m> right right</p>
-[22:25] <jrand0m> ok, moving on to 4) network testing / monitoring</p>
-[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</p>
-[22:26] * Frontier has joined #i2p</p>
-[22:27] * jrand0m gives people time to digest</p>
-[22:27] * dm says...</p>
-[22:28] <Frontier> digest wat?</p>
-[22:28] <dm> C) but not with automatic sending.</p>
-[22:28] <dm> i.e. you type emaillogstojrandom.sh (.bat)</p>
-[22:28] <dm> email or post, or whatever.</p>
-[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.</p>
-[22:29] <jrand0m> so basically B</p>
-[22:29] <jrand0m> (or A)</p>
-[22:29] <dm> Yeah, user-friendly B) :)</p>
-[22:29] <jrand0m> thats one of the tricks wrt the data... that log grows to tens of megs per night</p>
-[22:29] <jrand0m> right </p>
-[22:30] <dm> sorry, didn't see history=false for C.</p>
-[22:30] <jrand0m> Frontier) we're discussing section 4 of http://i2p.dnsalias.net/pipermail/i2p/2004-January/000101.html?</p>
-[22:30] <mihi> jrand0m: man bzip2</p>
-[22:30] <dm> So history=false with a script to post on command.</p>
-[22:30] <dm> sorry, history=true :)</p>
-[22:30] <dm> god, I've made a mess of it.</p>
-[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?</p>
-[22:32] <dm> I wouldn't worry about the size, 10s of megs for the small group of people you have here is fine.</p>
-[22:32] <Ophite1> I vote C.</p>
-[22:32] <dm> As long as it gets archived when you run the script to submit.</p>
-[22:32] <Ophite1> This is a debug client.</p>
-[22:32] <Ophite1> A in a production client of course :)</p>
-[22:32] <mihi> jrand0m: then use GZipOutputStream</p>
-[22:32] <jrand0m> right right Ophite1 ;)</p>
-[22:33] <jrand0m> mihi> people might like to read these files ;)</p>
-[22:33] <duck> yeah, opt-in for debugging participation, but once you join, make it as easy as possible for the user (so C)</p>
-[22:33] <mihi> man zcat ;)</p>
-[22:33] <Ophite1> jrandom: gzcat | less ;-)</p>
-[22:33] <mihi> Ophite1: zless ;)</p>
-[22:33] <jrand0m> C:\Documents and Settings\dev>man</p>
-[22:33] <jrand0m> 'man' is not recognized as an internal or external command,</p>
-[22:33] <jrand0m> operable program or batch file.</p>
-[22:33] <jrand0m> ;)</p>
-[22:34] <mihi> cd \cygwin <Ctrl+T> call cygwin.bat</p>
-[22:34] * dm twiddles his thumbs.</p>
-[22:34] <Ophite1> double-click -> winrar -> view</p>
-[22:34] <jrand0m> ok, so we have one B, two C, whats your take mihi?</p>
-[22:34] <jrand0m> (and anyone else?)</p>
-[22:34] <dm> twiddle thumbs, pick nose, click click.</p>
-[22:34] <mihi> double-click - 7zop - view. I'd say C.</p>
-[22:35] <mihi> s/7zop/7zip/</p>
-[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</p>
-[22:36] <jrand0m> i'll see if i can implement both c and b</p>
-[22:36] <dm> Looks like C it is.</p>
-[22:36] <dm> Don't waste your time, the B person is on dialup and would offer very little data anyway ;)</p>
-[22:36] <jrand0m> hehe</p>
-[22:36] <jrand0m> well, c is probably going to be implemented on top of b, so it won't take any more work</p>
-[22:37] <jar> for me : just like Ophite1 said ! A for prod client, C for debug ...</p>
-[22:37] <jrand0m> word jar</p>
-[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ...</p>
-[22:37] <Ophite1> obviously not anything other than A for prod client...</p>
-[22:37] <jar> just like Ophite1 said ! A for prod client, C for debug ...</p>
-[22:37] <Ophite1> that's a no-brainer :)</p>
-[22:37] <jar> sorry ... :(</p>
-[22:37] <jrand0m> s'all good jar, we won't kickban you (... this time ;)</p>
-[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)</p>
-[22:39] <jrand0m> ok, moving on to 5) ???</p>
-[22:39] <jrand0m> anyone have anything else?  questions, thoughts, concerns?</p>
-[22:39] * duck offers free hosting</p>
-[22:39] * dm accepts free hosting</p>
-[22:39] <jrand0m> oh word.  yeah, people should host sites on host.duck.i2p, its nice having reachable pages </p>
-[22:39] <jrand0m> (of course people should also feel free to host for themselves too ;)</p>
-[22:40] <duck> sure, just for those who can't stay online 24/7</p>
-[22:40] <jrand0m> right</p>
-[22:40] <mihi> what happened (will happen?) to the streaming api?</p>
-[22:40] <jrand0m> mihi> its in the task list, but getting the network functioning reliably is higher priority at the moment :/</p>
-[22:41] <mihi> but it is not dropped completely? (that's what i wanna know...)</p>
-[22:41] <jrand0m> i'll get back to the streaming api for the 0.3.1 release (perhaps sooner, but not sure)</p>
-[22:41] <jrand0m> its definitely NOT dropped completely.</p>
-[22:41] <jrand0m> it will be done.</p>
-[22:41] <dm> What's this streaming API? A different way of exposing the network to clients?</p>
-[22:42] <jrand0m> dm> http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary</p>
-[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 :)</p>
-[22:43] <jrand0m> (the insanely awesome benefit of that mistake was mihi coming along and writing i2ptunnel :)</p>
-[22:44] * wn-user has joined #i2p</p>
-[22:44] <jrand0m> anyone else have anything?</p>
-[22:44] * dm gets it.</p>
-[22:45] <jrand0m> w3rd</p>
-[22:45] <dm> Hmmm, too early to end meeting, ain't it?</p>
-[22:45] <duck> what about the hosts.txt</p>
-[22:45] <duck> it is growing and growing</p>
-[22:45] <jrand0m> well, 45 mins.  two weeks ago we had 20 mins</p>
-[22:45] <jrand0m> ah, true that</p>
-[22:45] <duck> but 75% is offline</p>
-[22:45] <duck> and it looks like 50% is permanently offline</p>
-[22:45] <jrand0m> prolly</p>
-[22:46] <jrand0m> I dunno</p>
-[22:46] <duck> just keep it growing, to raise the incentive for a DNS solution :)</p>
-[22:46] <jrand0m> heh exactly</p>
-[22:46] <Ophite1> I'm all for a little delay, I'm having a lot of fun with all kinds of Windows problems...</p>
-[22:46] <dm> Ophite1: windows is the devil!</p>
-[22:46] <Ophite1> You never really understand just how awful Windows is, until you write software for it.</p>
-[22:47] <jrand0m> reason #941 to use java </p>
-[22:47] <dm> Unless you're using .NET.</p>
-[22:47] <dm> also known as java++</p>
-[22:47] <Ophite1> dm/jrand0m: it's still running *on* Windows, and there are still some things you just keep running into.</p>
-[22:47] <duck> jrand0m: those last patches, would they solve disconnects? or more connection problems</p>
-[22:47] <Ophite1> Path lengths for example. Bloody unicode.</p>
-[22:48] <mihi> Or not to use \n in file names ;)</p>
-[22:48] <mihi> which will crash cvs anyway (on *nix, BTDT)</p>
-[22:48] <jrand0m> duck> no patches today are critical</p>
-[22:48] <duck> from yesterday I mean</p>
-[22:49] <dm> What happens if you use \n in a filenamE? :)</p>
-[22:49] <mihi> dm: try it ;) on *nix, nothing happens, as long as you don't try to run cvs update afterwards.</p>
-[22:49] <jrand0m> oh, yesterday there were Good patches that would solve some (most? all?) i2ptunnel Peer unreachable messages.  not i2cp disconnects though</p>
-[22:50] <dm> I think it would throw an exception.</p>
-[22:50] <jrand0m> (which is one of the reasons 0.2.3.5 is coming out)</p>
-[22:51] <mihi> dm: it works w/ local repository, but not w/ pserver or ssh.</p>
-[22:51] <mihi> something like 'protocol error'.</p>
-[22:51] <mihi> (the protocol terminates file names by \n ;) )</p>
-[22:51] <Ophite1> sort of like what happens with direct connect if you have filenames with $ and | in them. I hate DC.</p>
-[22:51] <duck> .</p>
-[22:52] <Ophite1> No matter what I code, ever, it could never be that bad :)</p>
-[22:52] <jrand0m> naw, you c devs just treat \0 as special instead of $ ;)</p>
-[22:52] <jrand0m> ok, anything else on i2p or we good to go?</p>
-[22:53] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))</p>
-[22:54] <jrand0m> 'k thazzit</p>
-[22:54] * jrand0m *baf*s the meeting to a close</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/74.rst b/i2p2www/meetings/74.rst
new file mode 100644
index 00000000..707c8702
--- /dev/null
+++ b/i2p2www/meetings/74.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 20, 2004 @ 22:00 CET
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/75.log b/i2p2www/meetings/75.log
index 0715ceb3..ee9bca18 100644
--- a/i2p2www/meetings/75.log
+++ b/i2p2www/meetings/75.log
@@ -1,104 +1,98 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 75{% endblock %}
-{% block content %}<h3>Tuesday, Jan 27, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:03] <jrand0m> 0) hi</p>
-[22:03] <jrand0m> 1) router dev status (0.2.4)</p>
-[22:03] <jrand0m> 2) RTCP</p>
-[22:03] <jrand0m> 3) i2p.net</p>
-[22:03] <jrand0m> 4) ???</p>
-[22:03] <jrand0m> 0) hi</p>
-[22:03] * jrand0m waves</p>
-[22:03] <jrand0m> this is meeting $num</p>
-[22:03] <duck> .</p>
-[22:03] * mihi_backup has joined #i2p</p>
-[22:03] <jrand0m> logs will go up onto the wiki once we're through</p>
-[22:03] * Robert has quit IRC (Ping timeout)</p>
-[22:04] * baffled has quit IRC (Ping timeout)</p>
-[22:04] <jrand0m> ok, moving on (hopefully battling ping timeouts)... 1) router dev status</p>
-[22:04] * baffled has joined #i2p</p>
-[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</p>
-[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?</p>
-[22:06] <duck> yes</p>
-[22:06] <jrand0m> sup?</p>
-[22:06] <duck> seems that still after a while the whole tunnel thing locks up</p>
-[22:07] <duck> then madman2003 and human have to shout at me</p>
-[22:07] <duck> and restart everything</p>
-[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)</p>
-[22:08] * jar has joined #i2p</p>
-[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</p>
-[22:08] <jrand0m> that means that whenever you build a tunnel through them, your tunnel is unreachable</p>
-[22:09] * DrWoo has quit IRC (Ping timeout)</p>
-[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</p>
-[22:09] * DrWoo has joined #i2p</p>
-[22:09] <duck> ok, so that is phttp part?</p>
-[22:09] <jrand0m> (the 'con' camp being led by "upgrading sucks")</p>
-[22:10] <jrand0m> hmm?  the phttp code has been patched in cvs</p>
-[22:10] <duck> what con camp?</p>
-[22:10] <jrand0m> madman2003> I think baffled might be looking at that :)</p>
-[22:10] <madman2003> upgrading is easy :)</p>
-[22:10] <kaji> upgrading rox</p>
-[22:10] <madman2003> with i2pmgr it's even easier</p>
-[22:11] <madman2003> just a touch of a button :)</p>
-[22:11] * Robert has joined #i2p</p>
-[22:11] <baffled2> I'm looking at it madman might be a while!</p>
-[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</p>
-[22:11] <jrand0m> if thats fine, i can wrap up a 0.2.3.6 quite easily</p>
-[22:11] <duck> updating makes me happy</p>
-[22:12] <kaji> what does .6 fix?</p>
-[22:12] <baffled2> I'd say go for it most of us don't have any problem with upgrading regularly.</p>
-[22:12] <madman2003> i'd upgrade every 24 hours if that does it</p>
-[22:12] <jrand0m> 0.2.3.6 fixes PHTTP to be, er, functional</p>
-[22:12] <jrand0m> ok cool</p>
-[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</p>
-[22:13] <jrand0m> (as well as here)</p>
-[22:13] * Masterboy has quit IRC (Ping timeout)</p>
-[22:14] <jrand0m> ok, anything else for the dev status, or shall we jump to 2) RTCP</p>
-[22:15] * jrand0m jmp 2</p>
-[22:15] <madman2003> you can always get back to it</p>
-[22:15] <jrand0m> right right</p>
-[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</p>
-[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</p>
-[22:16] <jrand0m> but, well, that essentially grows into IRC, or another full on anon network</p>
-[22:17] <madman2003> you mean totally eliminating PHTTP?</p>
-[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)</p>
-[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</p>
-[22:18] <madman2003> (i'd intergrate in the router, because that would spread the load of the relaying)</p>
-[22:18] <jrand0m> agreed</p>
-[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</p>
-[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)</p>
-[22:20] <madman2003> or use multiple relays if the there are more relays then people who need relays</p>
-[22:20] <baffled2> How would folks find the various rtcp relays?</p>
-[22:20] <madman2003> phttp :)</p>
-[22:20] <jrand0m> right, thats a good point - routers can create targets on multiple relays</p>
-[22:20] <jrand0m> baffled> rtcp relays will be listed in a router's RouterInfo (published in the networkDb)</p>
-[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</p>
-[22:23] <madman2003> something i just thought off: auto restart of tunnels every 12 or 24 hours</p>
-[22:23] <madman2003> and an auto restart of router + the rest every few days</p>
-[22:24] * jrand0m is working on making it so that wouldn't be necessary</p>
-[22:24] <jrand0m> one of my routers on a linux box has been up without interruption for several days</p>
-[22:24] <mihi> madman2003: you can add your own threads to the jvm to quit it after 12 hours</p>
-[22:24] <jrand0m> (and it only went offline when I upgraded it)</p>
-[22:24] * madman2003 has to go</p>
-[22:25] <jrand0m> l8r madman2003</p>
-[22:25] <madman2003> have a nice meeting</p>
-[22:25] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))</p>
-[22:25] <jrand0m> ok, anything else on rtcp?</p>
-[22:26] <duck> no, sounds good</p>
-[22:26] <jrand0m> ok, moving on to a brief one</p>
-[22:26] <jrand0m> 3) i2p.net.  </p>
-[22:26] <jrand0m> nuff said</p>
-[22:26] <jrand0m> 4) ???</p>
-[22:26] <jrand0m> anyone have anything else?</p>
-[22:28] <duck> .</p>
-[22:28] * jrand0m senses a record breaking 26 minute meeting</p>
-[22:29] <Reskill> lol</p>
-[22:29] * Reskill ambles in</p>
-[22:29] <jrand0m> 'mornin Reskill</p>
-[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</p>
-[22:30] <jrand0m> if there is nothing further...</p>
-[22:30] <Reskill> Oo...</p>
-[22:30] <baffled2> Okay, I'll see you all when I get home.</p>
-[22:30] * jrand0m *baf*'s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/75.rst b/i2p2www/meetings/75.rst
new file mode 100644
index 00000000..46745fc1
--- /dev/null
+++ b/i2p2www/meetings/75.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, January 27, 2004 @ 22:00 CET
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/76.log b/i2p2www/meetings/76.log
index eb3b265a..e6cf5970 100644
--- a/i2p2www/meetings/76.log
+++ b/i2p2www/meetings/76.log
@@ -1,520 +1,514 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 76{% endblock %}
-{% block content %}<h3>Tuesday, Feb 3, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:01] <jrand0m> 0) hi</p>
-[22:01] <jrand0m> 1) testnet</p>
-[22:01] <jrand0m> 2) updated roadmap</p>
-[22:01] <jrand0m> 3) updated application list</p>
-[22:01] <jrand0m> 4) volunteers needed</p>
-[22:01] <jrand0m> 5) ???</p>
-[22:01] <jrand0m> 0) hi</p>
-[22:01] * jrand0m waves</p>
-[22:01] * mihi waves back</p>
-[22:02] * jrand0m has to warn that i've been up for too long, so may be a little out of it</p>
-[22:02] <jrand0m> but anyway, as we proceed, everyone should read (or have read) http://i2p.dnsalias.net/pipermail/i2p/2004-February/000132.html</p>
-[22:02] <jrand0m> lets jump right into 1) testnet</p>
-[22:03] <mihi> you should change the subject for each mail... they all get sorted into one thread here</p>
-[22:03] <jrand0m> hah nice</p>
-[22:03] * jrand0m tried for consistency (for ease of filtering)</p>
-[22:03] <jrand0m> would you like me to add the date to it?</p>
-[22:03] <madman2003> how is the testent really doing?(pessimistic opnion please)</p>
-[22:03] <jrand0m> madman2003> poorly, but better than before</p>
-[22:04] <mihi> jrand0m: date (or meeting number) would be great</p>
-[22:04] <jrand0m> 'k mihi, consider it done</p>
-[22:04] <jrand0m> (anyone other than me want to give some feedback to madman2003's question?)</p>
-[22:04] <duck> madman2004: baffled and me have been connected for 4h now</p>
-[22:04] <baffled> Really that long?</p>
-[22:04] <duck> before test3 the maximum time was 10 min</p>
-[22:05] <jrand0m> w00t</p>
-[22:05] <duck> baffled: since 18:15:07 CET</p>
-[22:05] <jrand0m> yeah i had a 90m session the other day too</p>
-[22:05] <duck> but maybe we are directly hopped</p>
-[22:05] <madman2003> and you're sure the link is intact?</p>
-[22:05] <jrand0m> duck> all tunnels are 2 hop (unless your router is failing, in which case your tunnels will break at least once)</p>
-[22:06] <jrand0m> madman2003> when the tunnels fail, they fail hard</p>
-[22:06] <madman2003> how's general latency on the testnet?</p>
-[22:06] * Ophite1 has joined #i2p</p>
-[22:06] * jrand0m usually gets 2-10s latency through the squid</p>
-[22:06] * lucky has joined #i2p</p>
-[22:06] <jrand0m> 5-20s latency through irc</p>
-[22:07] <madman2003> is the 30 secs delay on local sites fixed yet?</p>
-[22:07] <jrand0m> duck> can you /ping duck on your ircd?  how long does it take to reply with a CTCP refused error?</p>
-[22:07] <jrand0m> (or baffled>)</p>
-[22:08] <jrand0m> madman2003> there have been significant bugfixes that would account for 30s+ delays locally</p>
-[22:08] <jrand0m> (jobs got locked up causing insane delays)</p>
-[22:08] <duck> response to admin request to baffleds ircd is ~8s</p>
-[22:08] <jrand0m> duck> to local?</p>
-[22:09] <duck> fido ping/pong is 3 seconds, which is local</p>
-[22:09] <jrand0m> coo'</p>
-[22:09] <duck> for local eepsites it also seems to be ~3s</p>
-[22:09] <jrand0m> (still much higher than i'd like, but <<30s)</p>
-[22:09] <duck> initial request longer, might be ~30s</p>
-[22:10] <jrand0m> interesting</p>
-[22:10] <duck> ,</p>
-[22:10] <jrand0m> ok, so there's definitely still work to be done on the testnet, but there's been progress</p>
-[22:10] <madman2003> is the testnet going to run until poor performance becomes perfect, what is the exact requirement of succes?</p>
-[22:11] <madman2003> (i know about 3 days of working good)</p>
-[22:11] <jrand0m> success == 3 consecutive days of things that should succeed succeeding.</p>
-[22:11] <jrand0m> human has volunteered to help out and implement something along the lines of what I posted in the email</p>
-[22:11] * mihi floods the testnet with pings ;)</p>
-[22:11] * leenookx has quit IRC (Ping timeout)</p>
-[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</p>
-[22:12] <jrand0m> (yay human!)</p>
-[22:12] <mihi> hmm, if there is no netsplit, i2p is working, but you cannot make the other way conclusion...</p>
-[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</p>
-[22:13] <madman2003> why don't you focus on making local delay <1s?</p>
-[22:13] <jrand0m> that i will.</p>
-[22:13] <madman2003> good chance that will solve some other problems too</p>
-[22:13] <jrand0m> the cause of >1s delay is likely the load</p>
-[22:14] <jrand0m> for routers with no peers, local only requests are near instantaneous</p>
-[22:14] <jrand0m> (but as the testnet is actually showing some load, we're stressing different things)</p>
-[22:15] <duck> baffled and me also had a little chat about making statsbots, but if human wants to do it; cool for me</p>
-[22:15] <madman2003> maybe delays have to do with requests being send to other routers</p>
-[22:15] <madman2003> before it see that it's local</p>
-[22:15] <jrand0m> oh word duck</p>
-[22:15] <jrand0m> naw, doesn't work that way madman2003</p>
-[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)</p>
-[22:16] * madman2003 wonders where all that load is coming from</p>
-[22:16] <jrand0m> france.</p>
-[22:16] <jrand0m> er, germany.</p>
-[22:16] <jrand0m> (since *someone* is pinging everyone ;)</p>
-[22:17] <duck> kuala lumpur</p>
-[22:17] * duck hopes nobody gets that joke</p>
-[22:17] * jrand0m is pleased to meet duck's hopes</p>
-[22:17] <mihi> all that pings made my local box thrashing as well... (with no router!)</p>
-[22:18] <jrand0m> mihi> the i2cp lib does the crypto ;)</p>
-[22:18] * wiht has joined #i2p</p>
-[22:18] <madman2003> doesn't i2p protect from ping floods?</p>
-[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)</p>
-[22:19] <madman2003> grain sync?</p>
-[22:19] <mihi> jrand0m: congrats: seems that ping -ns does not only produce - - - now</p>
-[22:20] <jrand0m> lol mihi :)</p>
-[22:20] <mihi> why lol? ping -ns never worked for me. (only the synchronized one)</p>
-[22:20] <duck> synchronized one never worked for me...</p>
-[22:20] <jrand0m> oh really?  word, -ns has been working well for me</p>
-[22:21] <jrand0m> madman2003> its a tradeoff of memory and CPU vs concurrency</p>
-[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)</p>
-[22:22] * TrueSeeker has quit IRC (Leaving)</p>
-[22:22] * mihi will post ping stats in #flood in a few secs</p>
-[22:22] * ion has quit IRC (Ping timeout)</p>
-[22:23] <lucky> bah.</p>
-[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.</p>
-[22:23] <lucky> miserably day.</p>
-[22:23] <lucky> stupid capitalist pigs</p>
-[22:23] <lucky> taking all my money..</p>
-[22:24] <baffled> looks like there a are new goodies in cvs, how long before test4?</p>
-[22:24] <jrand0m> not today, hopefully tomorrow</p>
-[22:24] * jrand0m is going to bed after the meeting :)</p>
-[22:25] <baffled> cool.</p>
-[22:26] <madman2003> bye everyone</p>
-[22:26] <jrand0m> later madman2003</p>
-[22:26] <madman2003> don't forget the other points of the meeting :)</p>
-[22:26] <jrand0m> ok, so thats testnet.  anything else on that, or shall we move to 2) updated roadmap?</p>
-[22:26] <jrand0m> hehe</p>
-[22:26] <baffled> Are there other stressers we need on the test net?</p>
-[22:26] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))</p>
-[22:26] <duck> what date is it?</p>
-[22:27] <jrand0m> Feb 3</p>
-[22:27] <baffled> 3rd here.</p>
-[22:27] <mihi> 2004-02-03</p>
-[22:27] * leenookx has joined #i2p</p>
-[22:27] <duck> ah, thanks</p>
-[22:27] <jrand0m> baffled> actually, has anyone tried out i2psnark on testnet?</p>
-[22:27] <wiht> baffled: What do you mean by stressers?</p>
-[22:28] <mihi> wiht: i guess people stressing the testnet</p>
-[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.</p>
-[22:28] * mihi 'd like a public echo service set up by anyone - would allow good latency checks</p>
-[22:28] <baffled> so those two items I guess.</p>
-[22:28] <jrand0m> we've had a good crew hitting the squid</p>
-[22:28] <jrand0m> oh, nntp would rule, as would an ogg stream!</p>
-[22:29] * jrand0m doesn't recall asking y'all to stop (except maybe temporarily during an update?)</p>
-[22:29] <jrand0m> agreed mihi</p>
-[22:29] * jrand0m checks what port 'echo' is</p>
-[22:29] <jrand0m> 7</p>
-[22:29] <mihi> afaik 9</p>
-[22:29] <mihi> oops ;)</p>
-[22:29] <baffled> You may been frazelled about something else at the time.</p>
-[22:30] <wiht> Port 7.</p>
-[22:30] <duck> 4</p>
-[22:30] * ion has joined #i2p</p>
-[22:30] <jrand0m> prolly baffled ;)</p>
-[22:30] <duck> echo            4/ddp                           # AppleTalk Echo Protocol</p>
-[22:30] <jrand0m> echo            7/tcp</p>
-[22:30] <jrand0m> echo            7/udp</p>
-[22:30] <jrand0m> echo            4/ddp                           # AppleTalk Echo Protocol</p>
-[22:30] <wiht> Port 7 for TCP and UDP.</p>
-[22:30] <mihi> duck: we want [0-9]*/tcp</p>
-[22:30] * duck ducks</p>
-[22:31] * Synonymous has joined #i2p</p>
-[22:31] <jrand0m> so, anyone want to wrap up human's test app (the echo server and client)?</p>
-[22:32] <jrand0m> (though running twisted does seem a bit much for that ;)</p>
-[22:32] <duck> the non-twisted one would work</p>
-[22:33] <duck> .</p>
-[22:33] * jrand0m didn't realize his i2p code could work w/out twisted</p>
-[22:33] <jrand0m> but anyway, anyone wnat to volunteer to run point on getting an echo service up?</p>
-[22:33] * duck sits on his hands</p>
-[22:33] <wiht> Reachable through I2P, or reachable through regular Internet?</p>
-[22:34] <jrand0m> through i2p</p>
-[22:34] <baffled> I can look into it with some specific specs.</p>
-[22:34] <mihi> duck: do ducks have hands? i thougt wings ;)</p>
-[22:34] <jrand0m> spec: receive a line of text and echo it back :)</p>
-[22:34] <baffled> oh, okay no prob.</p>
-[22:34] <lucky> bah... i have to start filing taxes next year!</p>
-[22:34] <mihi> jrand0m: s/line/byte chunk/</p>
-[22:34] <lucky> Stupid, damn government...</p>
-[22:35] <jrand0m> mihi> line is so much easier to parse ;)</p>
-[22:35] <duck> lucky: hush</p>
-[22:35] <jrand0m> baffled++</p>
-[22:35] <jrand0m> ok, moving on to 2) updated roadmap</p>
-[22:35] * jrand0m directs people's attention to http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap</p>
-[22:36] <mihi> jrand0m: why? while (len=in.read(b) != -1) {o.write(b,0,len);}</p>
-[22:36] <jrand0m> (which, of course, y'all have already read)</p>
-[22:36] * MrEcho has joined #i2p</p>
-[22:36] <jrand0m> mihi> single byte messages vs nagle, etc</p>
-[22:37] <jrand0m> but anyway, whatever baffled implements to do echoing to support testing is Good </p>
-[22:37] <jrand0m> (or you and he can work out what works best for you)</p>
-[22:37] * wiht has quit IRC (Ping timeout)</p>
-[22:37] <baffled> If you have requirements write them down and let me know later mihi and I'll try.</p>
-[22:38] * ion has quit IRC (Ping timeout)</p>
-[22:38] <mihi_backup> baffled: not really. if needed adding a newline after a timestamp is no problem at all.</p>
-[22:38] * jar_ has quit IRC (Ping timeout)</p>
-[22:38] <duck> (netsplit after 4:20)</p>
-[22:38] <jrand0m> heh</p>
-[22:39] <jrand0m> not good :/</p>
-[22:39] <jrand0m> well, iterative and incremental.</p>
-[22:39] <mihi> 22:38:09.430 ERROR [WrC1->Pz83  ] .i2p.i2ptunnel.I2PTunnelRunner: Error sending</p>
-[22:39] <mihi> message to peer.  Killing tunnel runner</p>
-[22:39] <jrand0m> are all 9/10 routers up atm?</p>
-[22:39] <jrand0m> (or did one go down?)</p>
-[22:40] <jrand0m> i only see 8</p>
-[22:40] <jrand0m> 22:41:02.758 ERROR [TCP Read [9]] er.transport.tcp.TCPConnection: Error reading from stream to [RouterIdentity:</p>
-[22:40] <jrand0m>         Hash: 4Sb3aJoFusrhpHgYA2xCZCkn0P5jBo822qu9C0wsE1w=</p>
-[22:40] * duck did just update</p>
-[22:40] <duck> where goes the i2cp admin stuff fit in the roadmap?</p>
-[22:41] <duck> afaik that isnt implemented, but 0.2.5 talks about finalizing the spec</p>
-[22:41] <jrand0m> current plan is to make I2CP the plain client protocol, leaving admin functionality seperate</p>
-[22:41] <jrand0m> (e.g. through the :7655 admin web port)</p>
-[22:41] <duck> ok</p>
-[22:42] <jrand0m> (and rip out all that other crap)</p>
-[22:42] * jar_ has joined #i2p</p>
-[22:42] * ion has joined #i2p</p>
-[22:42] <jrand0m> ((shrinkingCodebase)++)</p>
-[22:43] <jrand0m> does anyone have any thoughts on the two Big Issues?</p>
-[22:43] <jrand0m> = aborting the current PHTTP transport (until 2.0)</p>
-[22:43] <jrand0m> = keeping support for a restricted route topology at 2.0</p>
-[22:43] <baffled> Well gang, gotta boogie so I'll have to read the logs later.</p>
-[22:43] <jrand0m> cool, glad you could make it, l8r</p>
-[22:43] * baffled has quit IRC (Leaving)</p>
-[22:44] <duck> secure i2cp would lower the direct need for restricted route topology a bit</p>
-[22:44] <duck> so thats fine</p>
-[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)</p>
-[22:46] <jrand0m> the only difference from the current i2cp is a little update to the authentication protocol / structure</p>
-[22:46] <jrand0m> ((well, the $client can't detect $n, since messages are padded randomly.  nm)</p>
-[22:46] <jrand0m> er, $sniffer, not $client</p>
-[22:47] * wiht has joined #i2p</p>
-[22:47] <jrand0m> (of course that doesn't defeat a global passive adversary)</p>
-[22:48] <jrand0m> anyone have any other concerns / suggestions / ideas / comments?</p>
-[22:48] <jrand0m> (on the roadmap)</p>
-[22:49] <duck> no</p>
-[22:49] <jrand0m> nor do i</p>
-[22:49] * jrand0m hops on to 3) updated application list</p>
-[22:49] <jrand0m> [insert "mihi rules" rant here]</p>
-[22:50] <duck> help jrand0m to say no!</p>
-[22:50] <jrand0m> mihi> any thoughts on the muffin thing?  http://wiki.invisiblenet.net/iip-wiki?I2PApplications</p>
-[22:50] <jrand0m> heh</p>
-[22:51] <mihi> jrand0m: you know what i think about that...</p>
-[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)</p>
-[22:52] <mihi> httpclient has to get out of i2ptunnel, since i2ptunnel is for stream forwarding and httpclient does content forwarding</p>
-[22:52] <mihi> hacking that into i2ptunnel would be just more hackish.</p>
-[22:52] <jrand0m> word, so the app down below [Scalable web proxies]</p>
-[22:52] <jrand0m> that makes sense</p>
-[22:53] <jrand0m> (apps that do One Thing and One Thing Well)++</p>
-[22:53] <mihi> jrand0m: you misunderstood me...</p>
-[22:53] <jrand0m> whaddimiss?</p>
-[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.</p>
-[22:54] <mihi> httptunnel forwards everything except the first few lines.</p>
-[22:54] <jrand0m> ah you're right</p>
-[22:55] * jrand0m doesn't quite have head screwed on correctly</p>
-[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)</p>
-[22:55] <jrand0m> right - perhaps just have MUFFIN as a standalone </p>
-[22:55] <jrand0m> (filtering whatever comes out of the httpclient)</p>
-[22:55] <mihi> so i'd say, an extra app for that. but that would require streaming lib... (or sth like that)</p>
-[22:56] * duck likes how you can do proxies xmlrpc/soap with httpclient though</p>
-[22:56] <wiht> jrand0m: I did not see an entry for "muffin" on the list of applications.</p>
-[22:56] <jrand0m> wiht> http://muffin.doit.org/</p>
-[22:56] <mihi> muffin is a http content filter</p>
-[22:57] <mihi> if we have a content filter, we could drop that shitty "proxy" thingy.</p>
-[22:57] <jrand0m> duck> hopefully the muffin filter would be set to pass through xmlrpc/soap, only filtering things like VBScript / etc</p>
-[22:57] <wiht> I see.</p>
-[22:57] <jrand0m> hm, mihi?</p>
-[22:57] <duck> ah wait, xmlrpc/soap would be content type xml</p>
-[22:57] <jrand0m> mihi> wouldn't it still need to do the name translation, at the least?</p>
-[22:58] <mihi> sure, but not as a proxy. http://localhost:12345/duck.i2p/ would work much better.</p>
-[22:58] <Synonymous> muffin is gpl, u have to be careful in a public domain project to use gpl code, its still copyrighted ;)</p>
-[22:58] <mihi> since you can link to that from the regular web</p>
-[22:58] <jrand0m> hrm mihi.</p>
-[22:58] <mihi> Synonymous: i2ptunnel is gpl anyway</p>
-[22:58] <jrand0m> Synonymous> I2PTunnel is GPL</p>
-[22:58] <Synonymous> ya</p>
-[22:59] * jrand0m is well aware of the fact that some people consider copyrights valid, and tries to accomodate them.</p>
-[22:59] <Synonymous> make sure to put that up where it is visible (if you use muffin) it already says that iptunnel is gpl</p>
-[22:59] <jrand0m> of course, if we use muffin it'd get attributed and marked as gpl.</p>
-[22:59] <Synonymous> ya thats what i said, becareful about it</p>
-[23:00] <jrand0m> (we're not going to get into the copyright discussion here)</p>
-[23:00] <jrand0m> ok, any other thoughts on the apps listed?</p>
-[23:00] <Synonymous> then don't, and my comment was not intended to start one</p>
-[23:00] * duck laughts at http://muffin.doit.org/demo/evil/</p>
-[23:01] <jrand0m> what do y'all think will be necessary app functionality for 1.0?</p>
-[23:01] <jrand0m> heh duck</p>
-[23:01] <jrand0m> (or are we already there, and 1.0 app functionality == things proxied through i2ptunnel :)</p>
-[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</p>
-[23:02] <mihi> an IM and a naming service are still missing</p>
-[23:02] <jrand0m> mihi> irc over i2p?</p>
-[23:02] <wiht> Yes, naming service should be in place by 1.0 version of I2P.</p>
-[23:03] <duck> eep</p>
-[23:03] <mihi> jrand0m: irc over i2p would be okay as well, but a naming service ;)</p>
-[23:03] <jrand0m> wiht> do you have any thoughts on whether a naming service will be implemented and ready to go live by April?</p>
-[23:03] * jrand0m really doesn't think a naming service is necessary. useful, yes</p>
-[23:04] <jrand0m> (all we *need* is a way to easily update a hosts.txt file)</p>
-[23:04] <kaji> or a distributed vpn layer</p>
-[23:04] <jrand0m> heh</p>
-[23:04] <mihi> jrand0m: for me even that (if automated) is a naming service</p>
-[23:04] <wiht> jrand0m: Probably by the middle of April.</p>
-[23:05] <jrand0m> kaji> a distributed vpn layer is a solid month of 1-2 devs ;)</p>
-[23:05] <wiht> I want to make it scalable for accomodating many more entries than we have in hosts.txt now.</p>
-[23:05] <jrand0m> 1.0-->3.0 wont have millions of entries</p>
-[23:05] <wiht> MrEcho: Do you have any thoughts on this?</p>
-[23:05] <jrand0m> thousands, yeah</p>
-[23:06] <jrand0m> Synonymous> freenet like app would be cool, but then we need to recruit someone to implement :)</p>
-[23:07] <jrand0m> Synonymous> tools to set up services - definitely.  hopefully i2pmanager or i2pmole will do</p>
-[23:07] <Synonymous> that might be hard, esp since freenet doesnt work hehe</p>
-[23:07] <wiht> Speaking of which, what is the progress of I2PManager?</p>
-[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)</p>
-[23:08] <jrand0m> i've used the gui, and aum's logged a few bugs on the tunnelmanager that are still outstanding</p>
-[23:08] <jrand0m> (due to large #s of tunnels being created, not due to a small #)</p>
-[23:08] <wiht> I think I2PManager should be an application for 1.0.</p>
-[23:09] <jrand0m> i hope so too</p>
-[23:09] <jrand0m> (especially since that would mean we can throw out the kludged installer, since i2pmanager has that built in)</p>
-[23:09] <jrand0m> so, people with python experience should get in touch with aum to see how they can help :)</p>
-[23:09] <human> re</p>
-[23:09] <jrand0m> wb human</p>
-[23:10] * human read about the muffin proxy</p>
-[23:10] <human> i know about another privacy-oriented personal proxy called privoxy</p>
-[23:11] <jrand0m> yeah, privoxy was another one i had been looking at.  good potential as well</p>
-[23:11] <jrand0m> (reason i leaned towards muffin was the ease of integration, since its java)</p>
-[23:12] * jrand0m won't be the one who implements / integrates it, so my view is only a suggestion</p>
-[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</p>
-[23:13] <jrand0m> agreed</p>
-[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)</p>
-[23:13] <Synonymous> the channel would be the 'board' ?</p>
-[23:13] <jrand0m> Synonymous> duck has actually done some neat stuff</p>
-[23:13] <Synonymous> kool</p>
-[23:14] <duck> which is: users login with a secret password to the ircd, the ircd publishes the sha1 of the password</p>
-[23:14] <jrand0m> Synonymous> in his modified ircd, you can provide a password that has its hash shown in the ident </p>
-[23:14] <Synonymous> it would also be like waste i guess, even though I didnt usei t</p>
-[23:14] <jrand0m> duck> though if anyone else creates their own ircd, they can spoof that :/</p>
-[23:14] <duck> so others can check the sha1 against a local list, without requiring a centralized database</p>
-[23:15] <duck> sure</p>
-[23:15] <jrand0m> but people could just remember what ircd someone usually connects from, i suppose</p>
-[23:15] <jrand0m> would it be possible to have a nickserv?</p>
-[23:15] * jrand0m doesn't know much about how irc nets work</p>
-[23:16] <duck> yes, but I didnt want that</p>
-[23:16] <duck> because Trent was made as a temporary hack</p>
-[23:16] <jrand0m> right, it'd be Good if we could do without</p>
-[23:16] <jrand0m> hehe</p>
-[23:16] <jrand0m> until iip 2.0, right?  ;)</p>
-[23:16] <duck> now it is the longest running joke in the world</p>
-[23:17] <duck> .</p>
-[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?</p>
-[23:18] <@Nightblade> yeah</p>
-[23:18] <jrand0m> (obviously it'd be fantastic if we could include i2psnark, naming, I2PIM, and the other apps)</p>
-[23:19] <duck> with irc you mean native i2pirc?</p>
-[23:19] <duck> or if not, why not nntp etc too</p>
-[23:19] <jrand0m> oh, right</p>
-[23:19] <jrand0m> of course</p>
-[23:20] * jrand0m !thwaps self.</p>
-[23:20] <duck> not too much ofcourse</p>
-[23:20] * duck thinks that the pgp keyserver is silly</p>
-[23:20] <jrand0m> i just meant that its easy to overwhelm people with options</p>
-[23:20] <duck> ah, sure</p>
-[23:20] <duck> as in officially bundeled stuff</p>
-[23:20] <jrand0m> "why should I use I2P" "well you can [.............]"</p>
-[23:20] <jrand0m> right</p>
-[23:20] * duck agrees</p>
-[23:21] <jrand0m> with i2ptunnel, we can support all that we've seen (and more :)</p>
-[23:21] <jrand0m> ok, in that case, I don't think we need to worry too much about the i2papps</p>
-[23:21] <mihi> btw: we should deprecate the -nogui option of I2PTunnel...</p>
-[23:22] <jrand0m> to default to -nogui?</p>
-[23:22] <jrand0m> (or you trying to get us all to use awt?  ;)</p>
-[23:22] <mihi> no. not to use -nogui at all. -cli and -nocli are more "transparent"</p>
-[23:22] <Synonymous> you should also package all these options in 1 distro if you can</p>
-[23:22] <jrand0m> ah ok mihi</p>
-[23:22] <Synonymous> unlike freenet, which mentions no otehr utilities and its up to you to go find them out</p>
-[23:22] <jrand0m> Synonymous> definitely</p>
-[23:22] <jrand0m> Synonymous> have you used i2pmgr yet?</p>
-[23:23] <mihi> -nogui acts differently whether you use -e "run configfile" or use "configfile"</p>
-[23:23] <Synonymous> no, i couldnt get it working :)</p>
-[23:23] <jrand0m> (its still pre-alpha, but functional)</p>
-[23:23] <jrand0m> ah ok</p>
-[23:23] <Synonymous> from before but it didnt try the gui</p>
-[23:23] <Synonymous> i might try now that it has one</p>
-[23:23] <Synonymous> :)</p>
-[23:23] <jrand0m> word, its been makin progress</p>
-[23:23] * duck suppresses a yawn</p>
-[23:24] <jrand0m> yeah yeah yeah duck, ok ;)</p>
-[23:24] <jrand0m> i think thats it for apps - unless someone else has something?</p>
-[23:24] <jrand0m> moving on to 4) Volunteers needed</p>
-[23:25] <jrand0m> we're making good progress, and the pace is fine and imho sustainable</p>
-[23:25] <jrand0m> but we've all been talking about some really neat things that we'd like added on</p>
-[23:25] <jrand0m> if there were another N hours in the day, yadda yadda yadda</p>
-[23:26] <duck> what do you mean with 'development bandwidth'?</p>
-[23:26] <jrand0m> more hours of developer activity</p>
-[23:26] <duck> aye</p>
-[23:27] <jrand0m> (e.g. 2 developers == 16/20 hours/day)</p>
-[23:27] <jrand0m> my gut feeling is of the 'if you build it, they will come' variety</p>
-[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)</p>
-[23:28] * duck doesnt think that hiring cheap indians will work</p>
-[23:28] <jrand0m> heh</p>
-[23:29] <duck> product marketing != developer marketing</p>
-[23:29] <jrand0m> right, i agree</p>
-[23:29] <jrand0m> i just meant as an analogy</p>
-[23:30] <jrand0m> we'll see how things progress.  i just wanted to throw that stuff out there</p>
-[23:30] <@Nightblade> it is a complex program which makes it harder to find people who can figure it out</p>
-[23:31] <jrand0m> agreed Nightblade</p>
-[23:31] * greasyaxelsex__ has joined #I2P</p>
-[23:31] <jrand0m> Nightblade> thats what 1.0 release criteria #3 on the roadmap is for: " Javadoc and code walkthrough / guidebook updated"</p>
-[23:32] * dm has joined #i2p</p>
-[23:32] * wiht has quit IRC (EOF From client)</p>
-[23:32] <jrand0m> we currently have a generally up to date wiki providing an overview of the java impl</p>
-[23:32] <mihi> hi dm</p>
-[23:32] <jrand0m> but i will definintely need help with the documentation</p>
-[23:32] <dm> hello mihi.</p>
-[23:33] <jrand0m> (since what makes sense to me != what makes sense to people learning the code)</p>
-[23:33] * dm accuses jrand0m of using terms he's invented when explaining things.</p>
-[23:34] <jrand0m> occationally ;)</p>
-[23:34] <Synonymous> i will help wtih the webpage if u want</p>
-[23:34] <jrand0m> (though the only thing i knowingly have coined wrt i2p is 'militant grade anonymity' ;)</p>
-[23:34] <Synonymous> i already have a template</p>
-[23:34] <dm> How far are we from a bugless 0.2.x? I get my broadband in less than a week's time.</p>
-[23:34] * wiht has joined #i2p</p>
-[23:34] <Synonymous> the website needs major owkr</p>
-[23:34] <Synonymous> im working on my own anonymous p2p website, but you can borrow mine :)</p>
-[23:35] <jrand0m> hehe</p>
-[23:35] <Synonymous> its modeled after freenet's</p>
-[23:35] <Synonymous> but better</p>
-[23:35] <Synonymous> :P</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?</p>
-[23:35] <dm> Synonymous: are you building a p2p app, or just the website?</p>
-[23:35] <Synonymous> just the website</p>
-[23:35] <jrand0m> (and if that traffic grows, we'll move to something like i2p-www@)</p>
-[23:36] <duck> ROFL at anonymous p2p website boilerplates</p>
-[23:36] <jrand0m> dm> roadmap updated at http://wiki.invisiblenet.net/iip-wiki?I2PRoadmap with 0.2.4 slated for February 14</p>
-[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</p>
-[23:36] <mihi> dm> bugless sw does not exist</p>
-[23:36] <jrand0m> duck> gotta keep the anonymity set large ;)</p>
-[23:36] <Synonymous> also links to the other website that does that</p>
-[23:37] <dm> mihi: does too!</p>
-[23:37] <jrand0m> mihi> i worked on one project a few years ago that actually shipped with 0 bugs.  no p1 or even p5s</p>
-[23:37] <dm> func addints(int a, int b) { return a + b; }</p>
-[23:37] <mihi> jrand0m: they just did not find them...</p>
-[23:37] <mihi> dm: which language?</p>
-[23:37] <jrand0m> mihi> then its not a bug ;)</p>
-[23:37] * greasyaxelsex__ has left #I2P (greasyaxelsex__)</p>
-[23:37] <dm> pseudo-language</p>
-[23:38] <mihi> and how does this pseudo-language react on an overflow?</p>
-[23:38] <wiht> dm: In a project with thousands of lines of code, having no bugs is much less likely.</p>
-[23:38] <duck> .</p>
-[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.</p>
-[23:39] <dm> input is never over max_value /2</p>
-[23:39] <jrand0m> (we're currently ~20KLOC, using the "grep \; | wc -l" algorithm)</p>
-[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)</p>
-[23:40] <dm> that's a lotta lines.</p>
-[23:40] <dm> Java bloat!</p>
-[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</p>
-[23:40] * jrand0m kicks dm</p>
-[23:40] <jrand0m> java bloat is when the jvm uses ram.  you're suggesting OO bloat</p>
-[23:40] <dm> What a project leader jrand0m is.</p>
-[23:40] <Synonymous> well, how will u know if ppl are interested if there is no knowledge of it, thats a contradiction</p>
-[23:41] <Synonymous> and by 'recruit' i mean email them, not pubically anounce on say, zeropaid, about i2p</p>
-[23:41] <Synonymous> like someone did ;)</p>
-[23:41] <jrand0m> Synonymous> what are your thoughts on the explanation of that issue from the email?</p>
-[23:41] <dm> Right OO bloat.</p>
-[23:41] <jrand0m> yeah, I was pissed when someone told me about that zp article</p>
-[23:41] <Synonymous> ya your the one that did the interview</p>
-[23:41] <jrand0m> (you can read the august iip-dev messages)</p>
-[23:41] <Synonymous> they just quoted you?</p>
-[23:41] <jrand0m> "interview"?  more like some random person on iip asking me questions</p>
-[23:42] <dm> mihi: are you working on the streaming lib?</p>
-[23:42] <Synonymous> ah :)</p>
-[23:42] <mihi> dm:no</p>
-[23:42] <mihi> Standard@laptop /cygdrive/c/eigenes/notback/cvsprojects/i2p/i2p/code</p>
-[23:42] <mihi> $ grep \; `find . -name "*.java"` | wc -l</p>
-[23:42] <mihi>   30593</p>
-[23:42] <jrand0m> ah.</p>
-[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"</p>
-[23:42] <mihi> 30kLOC ;)</p>
-[23:42] <jrand0m> grep -v \^import</p>
-[23:43] <jrand0m> Synonymous> stealing project leads == bad form ;)</p>
-[23:43] <jrand0m> (there are many good projects, and while I obviously think i2p is important, others are too)</p>
-[23:44] <Synonymous> not stealing, and i dont think the 'leader' can be stolen, he would just desolve the project</p>
-[23:44] * jrand0m cant believe we're at 30kloc</p>
-[23:44] <jrand0m> heh</p>
-[23:46] <jrand0m> ok, moving on to 5) ???</p>
-[23:46] <duck> 2 eepsite proposals, for those who dont know what to do: 1) meshmx FE tunnel (with stunnel) 2) pastebin.de site</p>
-[23:46] <jrand0m> anyone have anything else to discuss / bring up?</p>
-[23:46] <jrand0m> oh word duck</p>
-[23:46] <jrand0m> whats pastebin.de?</p>
-[23:46] <jrand0m> (similar?)</p>
-[23:47] <duck> site where you can paste code/logs/stuff publically</p>
-[23:47] <duck> for irc debugging</p>
-[23:47] <duck> http://pastebin.de/</p>
-[23:47] <jrand0m> interesting</p>
-[23:47] * @Nightblade just prefers flooding channels with code</p>
-[23:48] <jrand0m> wow that is one hell of an innovative idea</p>
-[23:48] <jrand0m> insanely simple.</p>
-[23:48] <jrand0m> focused.</p>
-[23:48] <jrand0m> practical.</p>
-[23:48] <dm> Only python though?</p>
-[23:48] <jrand0m> oh reall?</p>
-[23:48] <jrand0m> :/</p>
-[23:48] <duck> I think this one has python highlighting</p>
-[23:48] * jrand0m takes back 'practical' ;)</p>
-[23:48] <duck> but I have also seen php ones etc</p>
-[23:48] <duck> and you might have a general approach</p>
-[23:48] <dm> I think I've seen one which accepts any language.</p>
-[23:49] <dm> Good idea, mind you.</p>
-[23:49] <duck> anyway, just something simple</p>
-[23:49] <duck> you dont need highlighting at all</p>
-[23:49] <duck> online linenrs would be useful</p>
-[23:49] * dm looks at python code.</p>
-[23:49] <dm> What's so special about this again?</p>
-[23:50] <jrand0m> its got a y</p>
-[23:50] * Nightblade sets mode: +o jrand0m</p>
-[23:50] <@jrand0m> w00t</p>
-[23:50] * Trent@anon.iip sets mode: +o mihi</p>
-[23:50] <duck> there is nothing special about it,</p>
-[23:51] <dm> A lot of people really like it, I think.</p>
-[23:51] <duck> oh, you mean about python</p>
-[23:51] <dm> yes, sorry.</p>
-[23:52] * duck moves that to 6) offtopic</p>
-[23:52] <duck> :)</p>
-[23:52] <@jrand0m> heh</p>
-[23:52] <@jrand0m> [beuler, beuler]</p>
-[23:52] <dm> Sorry, didn't realize you guys were having a meeting.</p>
-[23:52] <@jrand0m> every tuesday 9p gmt :)</p>
-[23:53] <duck> ok, php stuff: http://pastebin.com/pastebin.php?showsource=php</p>
-[23:53] <@jrand0m> anyone have anything else they want to bring up wrt i2p, etc?</p>
-[23:54] <@mihi> i2p rocks!</p>
-[23:54] <@jrand0m> (if only it were more reliable..)</p>
-[23:55] <@mihi> it is more reliable than freenet for me ;)</p>
-[23:55] <@jrand0m> heh :)</p>
-[23:55] <@jrand0m> if i just hadn't fucked with your i2ptunnel to set the retry count to 0 we'd be fine ;)</p>
-[23:56] <@jrand0m> (corrupt a lil data here and there, but that never hurt no one...er......)</p>
-[23:56] <@jrand0m> ok</p>
-[23:56] <dm> don't baf</p>
-[23:56] * @jrand0m isn't going to try to drag it out 4 more minutes to reach 2 hours</p>
-[23:57] <dm> do not baf</p>
-[23:57] * @jrand0m denies dm and *baf*'s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/76.rst b/i2p2www/meetings/76.rst
new file mode 100644
index 00000000..a24e4a82
--- /dev/null
+++ b/i2p2www/meetings/76.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 3, 2004 @ 22:00 CET
+=============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/77.log b/i2p2www/meetings/77.log
index a10534c3..c4cbf715 100644
--- a/i2p2www/meetings/77.log
+++ b/i2p2www/meetings/77.log
@@ -1,502 +1,496 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 77{% endblock %}
-{% block content %}<h3>Tuesday, Feb 10, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:00] <jrand0m> <incoming></p>
-[22:00] <jrand0m> 0) hi</p>
-[22:00] <jrand0m> 1) testnet status</p>
-[22:00] <jrand0m> 2) naming in i2p</p>
-[22:00] <jrand0m> 3) minwww and i2cp</p>
-[22:00] <jrand0m> 4) i2p.net website</p>
-[22:00] <jrand0m> 5) ???</p>
-[22:00] <dm> I was thinking the other day, that we could make a .NET interface to I2P. Anyway.. </p>
-[22:00] <FireRabbit> well there will be one</p>
-[22:00] <madman-away> hello</p>
-[22:00] <jrand0m> -1) .net interface would be cool</p>
-[22:00] <jrand0m> 0) hi</p>
-[22:00] * madman-away is now known as madman2003</p>
-[22:00] <jrand0m> hey y'all</p>
-[22:00] <wilde> hi</p>
-[22:00] <FireRabbit> <-- will write a .net interface</p>
-[22:00] <FireRabbit> anyway hi</p>
-[22:00] <jrand0m> r0x0r.</p>
-[22:00] <dm> awesome</p>
-[22:01] <jrand0m> welcome to the 70somethingth meeting</p>
-[22:01] <FireRabbit> <-- needs that URL with the client protocol</p>
-[22:01] * ion has joined #i2p</p>
-[22:01] <jrand0m> i2p.net/ has links to the wiki, you'll probably want to use the tunnelManager</p>
-[22:01] <FireRabbit> ok</p>
-[22:01] <jrand0m> (people should review http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html for this weeks status update)</p>
-[22:01] <FireRabbit> and that works good in the latest release?</p>
-[22:02] <jrand0m> yup, aum uses it (and i just fixed a bug he was running into a few hours ago)</p>
-[22:02] <jrand0m> (specs @ http://wiki.invisiblenet.net/iip-wiki?I2PTunnelManager)</p>
-[22:02] <jrand0m> ok, movin' on</p>
-[22:02] <jrand0m> 1) testnet status</p>
-[22:02] <FireRabbit> okc ool yes,</p>
-[22:03] <jrand0m> i hate sounding like a broken record here, but... testnet is making progress.  </p>
-[22:04] <jrand0m> we're still not there, but we have multihour sessions without hiccup on the latest build</p>
-[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</p>
-[22:04] <FireRabbit> excellent</p>
-[22:04] <baffled> We're at least populating the net with animals</p>
-[22:05] <jrand0m> hehe</p>
-[22:05] <jrand0m> dog, cat, mouse, duck...</p>
-[22:05] * wiht has joined #i2p</p>
-[22:05] <FireRabbit> rabbit!</p>
-[22:05] <baffled> maybe I should become a bafflo</p>
-[22:05] <human> human!</p>
-[22:05] <jrand0m> !!</p>
-[22:05] <jrand0m> #animalfarm</p>
-[22:06] <dm> dm</p>
-[22:06] <jrand0m> but, yeah, thats basically what i've got to say about the testnet status (beyond whats in that status email)</p>
-[22:06] <wilde> people will read the logs offline so stay on topic please</p>
-[22:06] <jrand0m> heh sorry dad ;)</p>
-[22:07] <jrand0m> i think we're still on track for the roadmap</p>
-[22:07] <wiht> How many more testnet releases do you plan to distribute?</p>
-[22:07] <jrand0m> (plus i've been getting some future things done while running tests, such as the >2 hop tunnels)</p>
-[22:07] <jrand0m> wiht> as many as it takes</p>
-[22:08] <jrand0m> we're quite close to being done with this round of the testnet though, in my opinion</p>
-[22:08] <dm> isn't >2 hop tunnels just a setting?</p>
-[22:08] <jrand0m> yes</p>
-[22:08] <jrand0m> but in the past it wasn't well tested</p>
-[22:08] <dm> cool</p>
-[22:09] <jrand0m> while the testnet has been going on, i've had my own seperate testnet on my laptop doing other things</p>
-[22:09] * human is open to suggestions to make the ircmonitor more useful</p>
-[22:09] <jrand0m> <dreaming>an http listener to render .png on demand?</dreaming></p>
-[22:09] <jrand0m> (or just a /msg cat renderPNG)</p>
-[22:10] <human> jrand0m: ok, it should be feasible</p>
-[22:10] <baffled> I'd still like to see text summaries.</p>
-[22:10] <jrand0m> human++</p>
-[22:10] <baffled> on the ircmonitor.</p>
-[22:10] <jrand0m> yes, (text summaries)++ too</p>
-[22:10] <human> jrand0m: i was still thinking to make it use gnuplot to generate graphs (instead of gnu plotutils)</p>
-[22:11] <jrand0m> potato, potato</p>
-[22:11] <jrand0m> (ah, the glory of accents on irc)</p>
-[22:11] <FireRabbit> lol</p>
-[22:11] <human> jrand0m, baffled: could you give me an example of a text summary?</p>
-[22:11] <baffled> If you leave it with me a bit.</p>
-[22:11] * dm read that as "potato, potato"</p>
-[22:12] <jrand0m> period: 4 hours avg latency: 5.3s missed messages: 95 missed message frequency: 1 every 49 seconds</p>
-[22:12] <jrand0m> (perhaps max & min latency)</p>
-[22:12] <human> jrand0m: oh, ok</p>
-[22:12] <jrand0m> if thats possible / not too much trouble</p>
-[22:13] <jrand0m> (at least thats what i think of when i hear text summary)</p>
-[22:13] <wilde> max latency, min latency</p>
-[22:13] <mihi> human: look @ the summary i give for the ping tester</p>
-[22:13] <mihi> hmm, anyone running an echo server this week?</p>
-[22:13] <jrand0m> not to my knowledge</p>
-[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</p>
-[22:14] <jrand0m> kickass</p>
-[22:14] <baffled> Sorry mihi, I've been meaning to set yours up but keep forgetting.</p>
-[22:14] <jrand0m> i think this will be a good part of the overall functional testing that will grow with us</p>
-[22:15] <jrand0m> ok, do we have anything else for the testnet discussion?</p>
-[22:16] * jrand0m moves on to 2) naming in i2p</p>
-[22:16] <wilde> what's the biggest issue with testnet right now?</p>
-[22:16] <jrand0m> biggest issue in testnet is two fold -</p>
-[22:16] <jrand0m> 1) finding and fixing the cause of router disconnect</p>
-[22:17] <jrand0m> 2) determining the cause of the frequent inter-ircd disconnects</p>
-[22:17] <mihi> 1b) coping w/ the fact that routers may disconnect sometimes</p>
-[22:17] <jrand0m> right</p>
-[22:17] <jrand0m> well, thats not really part of this testnet.</p>
-[22:17] <jrand0m> 0.3.x is a series of updates to deal with unreliable routers</p>
-[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</p>
-[22:18] <wiht> So you are assuming reliable routers for now, right?</p>
-[22:18] <jrand0m> in the 0.2.3.6 testnet, yes</p>
-[22:18] <jrand0m> (it recovers from failure, but not quickly enough)</p>
-[22:19] <jrand0m> (more graceful recovery will be with multiple leases per destination, increased peer profiling, replay prevention, and retries on alternate lease targets)</p>
-[22:20] <jrand0m> ok, moving towards 2) naming in i2p</p>
-[22:21] <jrand0m> wiht brings up the core of the issue - global names are really useful, and people like them</p>
-[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)</p>
-[22:22] <wiht> People are used to them, perhaps more than to local names (such as your ICQ analogy).</p>
-[22:22] <jrand0m> i'm not sure.</p>
-[22:22] <jrand0m> lets say for instance that my name is John.</p>
-[22:22] <jrand0m> John isn't global.</p>
-[22:22] <jrand0m> not even John Q. Random is global.</p>
-[22:22] <jrand0m> nor is John Q. Random born in 1942 in Argentina.</p>
-[22:23] <human> well, it has been said that the naming system could have more than one flavor</p>
-[22:23] <jrand0m> thats true </p>
-[22:23] <human> people could choose a trusted "registration authority" to pick unique names from</p>
-[22:23] <jrand0m> absolutely.</p>
-[22:24] <jrand0m> though there is the danger there</p>
-[22:24] <wiht> The scheme I originally proposed allows for multiple certification authorities, as I recall.</p>
-[22:24] <human> jrand0m: of course, it's the tradeoff between comfort and security</p>
-[22:24] <FireRabbit> i think someone should write up a quick "centrlized" dns system for the time being then worry about security</p>
-[22:24] <human> jrand0m: :-)</p>
-[22:24] <FireRabbit> just to make testing easyer</p>
-[22:25] <jrand0m> multiple CAs works more easily without the global naming</p>
-[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.</p>
-[22:25] <baffled> There isn't really any problem until a conflict occures right?</p>
-[22:25] <jrand0m> FireRabbit> I have a strong feeling that what we start with will stay in place for 12+ months.</p>
-[22:25] <jrand0m> correct baffled, in any of the plans</p>
-[22:25] <wiht> baffled: That is the problem, yes.</p>
-[22:25] <jrand0m> wiht> not if there are multiple CAs</p>
-[22:25] <FireRabbit> suppose</p>
-[22:25] <wilde> eepsites will be a mess if there is local naming, links will not work</p>
-[22:25] <baffled> so you only need an authority in the case of conflict resolution.</p>
-[22:26] <jrand0m> yes they will wilde</p>
-[22:26] <jrand0m> names to be shared and used by others should be fully qualified - self certified - names</p>
-[22:26] <wiht> jrand0m: Could you give an example of a self-certified name?</p>
-[22:27] <jrand0m> from my email -   http://i2pref/[base64 of the NameReference]</p>
-[22:27] <wilde> so when I link to your site, and there are three jrandoms out there...which one will be used?</p>
-[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</p>
-[22:28] <jrand0m> you link with the fully qualified name - which includes the actual Destination *in it*.</p>
-[22:28] <jrand0m> (the NameReference structure from my email)</p>
-[22:28] <wilde> so it's like base64 linking</p>
-[22:28] <jrand0m> right human - it gets rid of that attack point</p>
-[22:28] <wiht> So people will have to type many characters again? That seems self-defeating.</p>
-[22:28] * madman2003 has quit IRC (EOF From client)</p>
-[22:29] <jrand0m> no one types base64 names</p>
-[22:29] <jrand0m> (well, maybe mihi does)</p>
-[22:29] <jrand0m> <a href="http://i2pref/[base64 of the NameReference]">jrandom's page</a></p>
-[22:29] <wiht> Oh. That makes sense.</p>
-[22:30] * mihi does not *type* anything he can copy&paste</p>
-[22:30] <jrand0m> :)</p>
-[22:30] <wilde> ok but basically it's long URLS</p>
-[22:30] <jrand0m> within eepsites, yes</p>
-[22:30] * dm has quit IRC (Ping timeout)</p>
-[22:30] <wilde> k that was the question</p>
-[22:30] <jrand0m> there are several other scenarios worth looking at though</p>
-[22:31] <jrand0m> such as when people want to browse or search for new sites</p>
-[22:31] <jrand0m> those are situations where having servers that contain a lot of name references is useful</p>
-[22:31] <baffled> Could I propose the idea of a history server rather than an authority.</p>
-[22:31] <jrand0m> history server?</p>
-[22:32] <jrand0m> ah, so whoever was first "gets it"?</p>
-[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.</p>
-[22:32] <human> maybe an archive to see how a domain name changed during time?</p>
-[22:32] <baffled> The conflict can then be resolved by the two parties providing they are both available.</p>
-[22:33] <wiht> baffled: What if the new domain's operator is sleazy and continues to hold that already-taken domain name?</p>
-[22:33] <baffled> If one party is not available the the conflict goes o the available party in some amount of time.</p>
-[22:33] <human> of course it implies to give some trust to the server operator</p>
-[22:33] <wilde> that's just authority but in another way</p>
-[22:33] <jrand0m> right</p>
-[22:34] <baffled> Any arbitrator is either going to act as an authority.</p>
-[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</p>
-[22:34] <jrand0m> right, right</p>
-[22:34] <baffled> I don't expect it will become a major problem.</p>
-[22:34] <jrand0m> (but why do we need an arbitrator?  can't there be two johns in the world?)</p>
-[22:35] <jrand0m> if i2p is used for commerce or other such activities, I expect the names to be heavily attacked</p>
-[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.</p>
-[22:35] <wilde> I vote for the cryptic nameref solution´</p>
-[22:35] <wiht> Again, that would be fine, as long as _new_ users would understand the implications and which John they want to contact.</p>
-[22:35] <jrand0m> (since someone would be able to hijack and get money, etc)</p>
-[22:36] <jrand0m> right - its likely we're always going to bundle some name references with the software</p>
-[22:36] <jrand0m> (ala the current hosts.txt)</p>
-[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.</p>
-[22:37] <jrand0m> why would domain names want to expire again?</p>
-[22:37] <baffled> They're tired of life?</p>
-[22:37] <jrand0m> oh, to replace the Destination included?</p>
-[22:37] <jrand0m> heh</p>
-[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.</p>
-[22:38] <jrand0m> hmm, but without uniqueness, there really isnt such a thing as ownership</p>
-[22:38] <jrand0m> its not scarce</p>
-[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"</p>
-[22:39] <wilde> so the nameref is protected by one key, the destination is another</p>
-[22:39] <jrand0m> the nameref is signed by the destination's signing key</p>
-[22:40] <wilde> you may want another key just for namerefs if possible</p>
-[22:40] <jrand0m> hm, i understand and agree, but that'd mean Destination gets yet another 1024bit segment</p>
-[22:40] <wilde> so even if a machine gets compromised you can keep the nameref key on a paper</p>
-[22:41] * wiht has quit IRC (Ping timeout)</p>
-[22:41] <jrand0m> (and Destination is used all over the place)</p>
-[22:41] <jrand0m> hmm not sure I follow the compromised part?</p>
-[22:42] <wilde> the destination privkey is on the machine all the time</p>
-[22:42] <jrand0m> ah right right</p>
-[22:42] <wilde> the nameref private key doesn't to be, they can be kept on paper in the wallet</p>
-[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)?</p>
-[22:43] <wilde> but that maybe overkill</p>
-[22:43] <wilde> i just don't like keeping the most valuable keys on the machine if isn't necessary</p>
-[22:44] <jrand0m> right - we need the Destination signing key and the destination decryption key, but nothing else, functionally.</p>
-[22:44] <jrand0m> hmm</p>
-[22:45] <jrand0m> perhaps the name reference could have a 1024bit public key on it as well</p>
-[22:45] <jrand0m> and we'd use that to verify via DSA</p>
-[22:45] <jrand0m> rather than the destination's public key</p>
-[22:45] <jrand0m> yeah, that'd fly</p>
-[22:45] <jrand0m> additional 32bytes, but only for nameReference, not for Destination</p>
-[22:46] * jrand0m doesnt know why I thought that'd imply it goes in the Destination</p>
-[22:46] <wilde> lots of keys :) but extra security and flexibility</p>
-[22:46] <jrand0m> right</p>
-[22:46] <jrand0m> (though, c'mon, we know everyone is going to keep their key in the same dir)</p>
-[22:46] <jrand0m> ((but maybe commerce shops wont))</p>
-[22:47] <wilde> you can hand over a "domain" but not the destination, or change to someone elses destination</p>
-[22:47] <jrand0m> well, ok.  i wish MrEcho and wiht were here</p>
-[22:47] <jrand0m> right</p>
-[22:48] <jrand0m> well, this is all fine and good, and I think it'll fly</p>
-[22:48] <jrand0m> but it needs to get coded :)</p>
-[22:49] <jrand0m> so, well, perhaps we'll have additional discussions about it later, but until that time, hosts.txt it is</p>
-[22:49] <wilde> hire some indians</p>
-[22:50] * jrand0m /dcc gets a grant to hire a team of 80 to work on i2p</p>
-[22:51] <wilde> :)</p>
-[22:51] <jrand0m> ok, do we have anything else for naming, or for the time being are we covered?</p>
-[22:51] <baffled> Skip on brother.</p>
-[22:52] * wiht has joined #i2p</p>
-[22:52] * jrand0m does a hop, skip, and a jump to 3) minwww and i2cp</p>
-[22:52] <jrand0m> d'oh, wb wiht</p>
-[22:52] <baffled> 1, 2, 5 uh 3 sitr.</p>
-[22:52] <wiht> I had trouble getting back on IIP network. I will read logs later.</p>
-[22:53] <jrand0m> cool wiht, and we can continue later on the list, etc</p>
-[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)</p>
-[22:54] <jrand0m> (reference the wiki at http://wiki.invisiblenet.net/iip-wiki?MinWWW )</p>
-[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</p>
-[22:56] * sheer has joined #i2p</p>
-[22:56] <duck> did the meeting already start?</p>
-[22:57] <jrand0m> yeah, 56 mins ago</p>
-[22:57] * jrand0m sends duck to the corner</p>
-[22:57] <duck> so I am right on time</p>
-[22:57] * wilde has quit IRC (Ping timeout)</p>
-[22:57] <jrand0m> heh</p>
-[22:57] <baffled> No doubt about it, he's gotta get a new clock.</p>
-[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?</p>
-[22:58] * wiht has quit IRC (Ping timeout)</p>
-[22:59] <jrand0m> that'd increase the number of outproxies available, decreasing the load</p>
-[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</p>
-[22:59] * wiht has joined #i2p</p>
-[23:00] <jrand0m> or should we just have something like a small set list of outproxies (thats periodically updated)?</p>
-[23:01] <jrand0m> (or is the idea not worth looking too much into?)</p>
-[23:01] * wilde has joined #i2p</p>
-[23:02] <jrand0m> (or i've timed out and no one can read anything i've said)</p>
-[23:02] <wilde> jrand0m: can see</p>
-[23:02] <jrand0m> 'k coo'</p>
-[23:02] <baffled> I'll need to understand it better but for now I have another appointment in ten minutes so I'll bbl.</p>
-[23:02] <jrand0m> word, l8r</p>
-[23:03] <jrand0m> yeah, there's still the absolutely key functionality of i2ptunnel to handle 8bit clean streams</p>
-[23:03] <jrand0m> thats necessary for e.g. irc over i2p and such</p>
-[23:03] <mihi> jrand0m: don't forget ss[lh]</p>
-[23:04] <jrand0m> but for message oriented protocols, such as http, smtp, bittorrent, etc, i2cp may be more appropriate</p>
-[23:04] <jrand0m> right, absolutely</p>
-[23:04] <jrand0m> (well, more like 'telnet', since ssh over i2p is a bit of an overkill)</p>
-[23:04] <wilde> ssh -X</p>
-[23:05] <jrand0m> true</p>
-[23:05] <jrand0m> (plus certs, etc)</p>
-[23:05] <wilde> there is never too much crypto</p>
-[23:05] <jrand0m> but if we're pulling web pages through squid in 5-10s, using i2cp would drop that to .5-2s</p>
-[23:06] <jrand0m> (without any subsequent tuning of the network, and would reduce overal network load)</p>
-[23:06] <wilde> how many man hours does it take to make i2cp?</p>
-[23:07] <jrand0m> imho, i2cp has a fairly simple API, bundled into the java i2p SDK</p>
-[23:07] <jrand0m> mihi can more fairly say how much effort it is to use / learn it</p>
-[23:08] * wiht has quit IRC (Ping timeout)</p>
-[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.</p>
-[23:09] * ion has quit IRC (Ping timeout)</p>
-[23:09] <jrand0m> we can obviously improve upon the sdk, i just based it off the JMS api</p>
-[23:10] <jrand0m> (and i'd be more than willing to help out anyone who wanted to hack around with it to get familiar)</p>
-[23:11] <jrand0m> ok, do we have anything else on the minwww/i2cp?</p>
-[23:11] <jrand0m> if not, moving on to 4) i2p.net website</p>
-[23:11] <jrand0m> (and there was much rejoicing)</p>
-[23:11] <jrand0m> ok</p>
-[23:12] <duck> about search functionality</p>
-[23:12] <duck> wikipedia uses google for search functionality</p>
-[23:12] <jrand0m> thats true. and we're already the #1 result for i2p :)</p>
-[23:13] <duck> so a nifty thing might not be needed for searching.</p>
-[23:13] <mihi> duck: atm yes ;)</p>
-[23:13] <duck> I mean for internal searching</p>
-[23:13] <mihi> #1 is www.crestron.com/company_info/i2p/ </p>
-[23:13] <jrand0m> ah yeah, i forgot to bribe the pigeons this week</p>
-[23:14] <duck> LeaseSet site:wiki.invisiblenet.net</p>
-[23:14] <jrand0m> nice</p>
-[23:14] <jrand0m> yeah, absolutely.</p>
-[23:14] <wilde> drupal has internal search, and you can filter on content types</p>
-[23:15] <wilde> it's also VERY google friendly with the clean urls, no index.php?Zillions of arguments</p>
-[23:15] <wilde> everything looks like directories</p>
-[23:16] * ion has joined #i2p</p>
-[23:16] <wilde> ok I've played around with different CMS:s so far and Drupal is my current favourite</p>
-[23:16] <duck> I prefer Ian's home-baked solution</p>
-[23:16] <duck> :)</p>
-[23:16] <jrand0m> what does it use for a backend?  mysql/bdb/txt/?</p>
-[23:16] <wilde> it's used by http://kerneltrap.org/ http://www.debianplanet.org/ http://www.linuxgazette.com/</p>
-[23:16] <wilde> for example</p>
-[23:17] <wilde> it can take heavy loads</p>
-[23:17] <wilde> their designs sucks though</p>
-[23:17] <wilde> but a nice CSS stylesheet fixes that</p>
-[23:17] <wilde> here some other somewhat better looking ones:</p>
-[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.</p>
-[23:17] <wilde> http://www.sudden-thoughts.com/</p>
-[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)</p>
-[23:18] <wilde> http://www.codemonkeyx.net/</p>
-[23:18] <wilde> http://www.disguast.org/index.php</p>
-[23:18] <wilde> http://trip.ee/</p>
-[23:18] <wilde> http://www.blainepeterson.com/image</p>
-[23:18] <wilde> .</p>
-[23:19] * jrand0m gets the feeling wilde is a raving drupal fan :)</p>
-[23:19] <wilde> I'm starting to become that yes, as I like the information management ideas behind it</p>
-[23:19] <wilde> everything is a node</p>
-[23:20] <wilde> great taxonomy system</p>
-[23:20] <wilde> you can create vocabularies for Geographic location, content type, language, etc</p>
-[23:20] <wilde> and create custom urls that filters on content those</p>
-[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?</p>
-[23:21] <wilde> and it's updated often and the changes are good</p>
-[23:21] <duck> in other words we are stupid that we dont have drupal already</p>
-[23:21] <wilde> we have duck</p>
-[23:21] <wilde> drupal.i2p.net</p>
-[23:21] <jrand0m> :)</p>
-[23:21] <wilde> you're so in the 90:s duck</p>
-[23:22] <duck> that is good</p>
-[23:22] <wilde> the design sucks of course</p>
-[23:22] <duck> cause that design is so in the 80:s</p>
-[23:22] <jrand0m> lol</p>
-[23:22] * wilde mud wrestles with duck</p>
-[23:22] <jrand0m> right, there are 3 different things that need to get worked out - the tech, the IA, and the graphic design</p>
-[23:23] <wilde> you could try the user interface</p>
-[23:23] <wilde> login: test pw: test</p>
-[23:23] <duck> warning: Bad arguments to implode() in /var/www/html/i2p/modules/project/issue.inc on line 360.</p>
-[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</p>
-[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.</p>
-[23:23] <jrand0m> search still doesn't work wilde, right?</p>
-[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</p>
-[23:24] <jrand0m> oh nice1 duck</p>
-[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</p>
-[23:24] <duck> sucky</p>
-[23:24] <jrand0m>  AND () AND</p>
-[23:24] <wilde> whoops, i had some problems with search i must admint</p>
-[23:25] <duck> .</p>
-[23:25] <wilde> there is some full text indexing cron script not yet configured</p>
-[23:25] <wilde> 2 minutes and duck crashed my life work</p>
-[23:25] <jrand0m> (!hi5 duck)</p>
-[23:26] <jrand0m> but i do think its worth looking at</p>
-[23:26] <wilde> what did you do duck?</p>
-[23:26] <jrand0m> i don't know if we're at the point where we want to commit to some CMS yet</p>
-[23:26] <wilde> no</p>
-[23:26] <jrand0m> (s/some/some specific/)</p>
-[23:27] <duck> jrand0m did already make an overview of the requires features didnt he</p>
-[23:27] <jrand0m> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html</p>
-[23:27] <duck> so now all parties should come with proposals and the price</p>
-[23:28] <duck> ofcourse the winning solution will be paid in i2p stocks</p>
-[23:28] <jrand0m> which, let me tell you, is quite valuable</p>
-[23:28] <jrand0m> *cough*</p>
-[23:29] <jrand0m> you'll get your own @i2p.net email</p>
-[23:29] <jrand0m> and chicks will love you</p>
-[23:29] <jrand0m> (or guys, whatever)</p>
-[23:30] <wilde> we had some CMS options</p>
-[23:30] <wilde> we should go for some CMS</p>
-[23:30] <wilde> and wiki isn't really a long term solution</p>
-[23:30] <jrand0m> yeah some listed in point 4 @ http://i2p.dnsalias.net/pipermail/i2p/2004-February/000142.html</p>
-[23:30] <jrand0m> agreed, for the website itself</p>
-[23:31] <jrand0m> a wiki based section of the site might be good though, perhaps for the user guide / hackers guides</p>
-[23:31] <jrand0m> (but not for everything)</p>
-[23:32] <wilde> what about the hosting?</p>
-[23:32] <jrand0m> there's always the 53 entries at http://dmoz.org/Computers/Software/Internet/Site_Management/Content_Management/Open_Source/</p>
-[23:32] <wilde> it should survive a slashdot</p>
-[23:32] <jrand0m> hosting?  </p>
-[23:32] <jrand0m> ah, right.</p>
-[23:33] <jrand0m> thats actually a really huge draw of plain HTML in and of itself</p>
-[23:33] <jrand0m> (dirt easy to mirror)</p>
-[23:33] <wilde> and on</p>
-[23:33] <wilde> http://www.oscom.org/</p>
-[23:33] <jrand0m> i2p.net is at a colo that is used by several large sites</p>
-[23:34] <jrand0m> ah right</p>
-[23:34] * jrand0m would love if people would keep at it and find the Right solution</p>
-[23:35] <wilde> http://www.opencms.org/ is interesting</p>
-[23:35] <wilde> but's maybe too corporate</p>
-[23:35] <wilde> with workflows, projects, etc</p>
-[23:35] <wilde> I really liked, used it for one project</p>
-[23:36] <jrand0m> interesting</p>
-[23:36] <wilde> but its java ;)</p>
-[23:36] <jrand0m> hmm, and xml</p>
-[23:36] <wilde> jsp templates etc</p>
-[23:36] <wilde> tomcat</p>
-[23:36] <jrand0m> (or jetty)</p>
-[23:36] <jrand0m> ((or resin))</p>
-[23:37] <duck> (((lisp)))</p>
-[23:37] <wilde> I would never use if for this project, it's really too heavy</p>
-[23:37] <jrand0m> wilde> would you be willing to look over the main CMSes and map out pros and cons?</p>
-[23:38] <wilde> i have :), and chose Drupal ;)</p>
-[23:38] * jrand0m should have known</p>
-[23:38] <wilde> I've tried about ten of the major ones</p>
-[23:38] <wilde> for some earlier projects</p>
-[23:38] <wilde> different CMS works for different projects</p>
-[23:39] <duck> so say drupal is used</p>
-[23:39] <wilde> Zope and friends are nice too</p>
-[23:39] <duck> is the structure clear?</p>
-[23:39] <duck> is the next step doing the gui?</p>
-[23:40] <wilde> it's really just a CSS template that's needed for the gui, some changes to the xtemplate to prettify things</p>
-[23:41] <wilde> www.csszengarden.com could be an inspiration</p>
-[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?</p>
-[23:41] <jrand0m> basically I want to avoid dev blog entries pushing news & announcements off the main stage</p>
-[23:42] <wilde> jrand0m: don't know, gonna check, blogs doesn't have to go front page, i configured it that way</p>
-[23:42] <jrand0m> ah cool</p>
-[23:42] <wilde> we can change to just stories go front page</p>
-[23:42] <wilde> everything that is a node could be frontpage, polls, stories, book pages, articles etc,</p>
-[23:43] <jrand0m> would it be possible to have stories at the top, with latest N blog entries below?</p>
-[23:43] * jrand0m stops micromanaging</p>
-[23:43] <wilde> blogs are linked to the bottom left right now,</p>
-[23:44] * godmode0 has joined #i2p</p>
-[23:44] <wilde> there are nice galleries as plugin, good for screenshots</p>
-[23:44] <jrand0m> word</p>
-[23:44] <wilde> the filestore plugin would be nice too</p>
-[23:45] <wilde> and more cvs, developer plugins too</p>
-[23:45] <wilde> and mailinglist</p>
-[23:45] <jrand0m> I'm no CMS expert, and it sounds like you've done your homework and are enthusiastic about it</p>
-[23:45] <jrand0m> w0ah nice</p>
-[23:45] <wilde> jrand0m: i need people pulling the brake for me sometimes :)</p>
-[23:46] <wilde> but the design really must be fixed, who are the design gurus here?</p>
-[23:46] * wilde can't stand poor design, wikis and current drupal kills him</p>
-[23:46] * jrand0m points at DrWoo and frontier</p>
-[23:46] <wilde> anyone here now?</p>
-[23:47] <duck> no, I left</p>
-[23:47] * jrand0m stares at the lurkers</p>
-[23:47] <wilde> so what should the site communicate?</p>
-[23:47] <duck> http://i2p.dnsalias.net/pipermail/i2p/2004-February/000133.html</p>
-[23:47] <wilde> this is a bit broader, we have marketing and donations to think of</p>
-[23:48] <jrand0m> (what duck said)</p>
-[23:48] <wilde> yeah i've read that, but we are more people here :)</p>
-[23:48] <jrand0m> :)</p>
-[23:48] <duck> but the puny humans dont matter!</p>
-[23:48] * wilde attaches to the borg collective</p>
-[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"</p>
-[23:49] <duck> ok; I am falling asleep</p>
-[23:49] <duck> enjoy</p>
-[23:49] <jrand0m> heh cool duck, g'night</p>
-[23:49] <duck> wilde: cool work on the CMS stuff</p>
-[23:49] * wilde remembers the thing about 80:s design, 5 months of work!</p>
-[23:50] <jrand0m> well, good thing we have 2 months then ;)</p>
-[23:50] <wilde> night duck</p>
-[23:50] <duck> oh yes, the design should BEG for peer reviews and useful comment</p>
-[23:50] * ion has quit IRC (Ping timeout)</p>
-[23:50] <jrand0m> agreed</p>
-[23:50] <wilde> about the toopie</p>
-[23:51] <jrand0m> i like 'im, he's humorous, simple, and topical</p>
-[23:51] <wilde> doesn't toopie look a bit ... hmm... stupid </p>
-[23:51] <jrand0m> (and he can serve as an icon with nearly any purpose)</p>
-[23:51] * ion has joined #i2p</p>
-[23:51] <wilde> he squints</p>
-[23:52] <jrand0m> heh i think we can wrestle up a top-left-logo-quality toopie</p>
-[23:52] <jrand0m> there've been a lot of revs going around for different purposes</p>
-[23:53] <wilde> i like him, but he must meet a personality consultant</p>
-[23:53] * jrand0m suggests bouncing some ideas off DrWoo, both for the design and toopie stuff</p>
-[23:54] <wilde> agreed</p>
-[23:54] <wilde> ok maybe we should leave it there</p>
-[23:54] <jrand0m> there's no rush, lots to digest and churn through</p>
-[23:54] <wilde> but please it you find this new kickass CMS, scream out</p>
-[23:54] <duck> can we have this as background: http://www.artchive.com/artchive/B/bruegel/death.jpg</p>
-[23:55] <jrand0m> but I agree with duck, nice work setting up a drupal to work off</p>
-[23:55] <jrand0m> that is so going straight to my desktop</p>
-[23:55] <jrand0m> wow I wonder what text over that would look like</p>
-[23:55] <wilde> cool picture</p>
-[23:55] <jrand0m> actually, on that note, 5) ???</p>
-[23:56] <jrand0m> anyone have anything else to add?</p>
-[23:56] * jrand0m prods the peanut gallery</p>
-[23:56] <wilde> it's been very quiet in here today</p>
-[23:56] <wilde> everyone comes here to listen to messiah Jrandom</p>
-[23:57] <duck> 2h is a bit longish</p>
-[23:57] <mihi> *ggg*</p>
-[23:57] * jrand0m is just here for the beer</p>
-[23:57] <duck> maybe you could try 2 weekly meetings of 30 min each</p>
-[23:57] <wilde> nah</p>
-[23:57] <duck> and then the layoffs at friday afternoon</p>
-[23:57] <wilde> that's too often</p>
-[23:58] <jrand0m> i do think 2h meetings are very excessive</p>
-[23:58] <jrand0m> (unless they're specifically topical.  e.g. a meeting discussing the web page design, or some router functionality, etc)</p>
-[23:58] <jrand0m> (hey look, we're meta)</p>
-[23:59] <jrand0m> perhaps I should shut up more and limit it to 1h?</p>
-[23:59] <jrand0m> or perhaps the bulk of the 'meeting' should go to the mailing list, with #i2p for discussion?</p>
-[23:59] * godmode0 has quit IRC (Ping timeout)</p>
-[23:59] <wilde> the mailinglist could be used more for discussions</p>
-Session Time: Wed Feb 11 00:00:00 2004</p>
-[00:00] <duck> I think that the heavy email pre-logs are already good</p>
-[00:01] <jrand0m> so maybe the weekly meetings turn more into "ok guys, whats up?  anyone have anything to discuss?"</p>
-[00:01] <jrand0m> (but open ended meetings like that are a danger in and of themselves)</p>
-[00:01] * godmode0 has joined #i2p</p>
-[00:02] <jrand0m> ok, maybe we can move this meta to the list or to later</p>
-[00:02] <jrand0m> we've already broken the 2h mark</p>
-[00:02] <jrand0m> so...</p>
-[00:02] * jrand0m winds up...</p>
-[00:02] <fidd> :)</p>
-[00:02] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/77.rst b/i2p2www/meetings/77.rst
new file mode 100644
index 00000000..aa65d696
--- /dev/null
+++ b/i2p2www/meetings/77.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 10, 2004 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/78.log b/i2p2www/meetings/78.log
index 83e4c0dc..feed6844 100644
--- a/i2p2www/meetings/78.log
+++ b/i2p2www/meetings/78.log
@@ -1,290 +1,286 @@
-{% 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</p>
-feeling very well, here are my logs of the meeting from slightly</p>
-before it started to sometime after it ended.  I have edited out the</p>
-kick offs and start screens from iip restarting at least twice during</p>
-that period.  If someone else has better logs feel free to replace</p>
-these. (baffled)</p>
+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</p>
-<human> baffled: just focus your mind on him, and help us</p>
-> Don't we have to hold hands or something like that?</p>
-<human> baffled: if it helps you focusing your mind... well, yes</p>
-> Cool, gimme your hand I'm commensing to focus!</p>
-<UL ></p>
-<li> human gives his hand to baffled </p>
-</UL></p>
-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</p>
-thecrypto (~thecrypto@anon.iip) has joined channel #i2p</p>
-<UL ></p>
-<li> baffled whipes the sacred potato-chip oil off his fingers and takes humans hand.</p>
-</UL></p>
-<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</p>
-<human> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>: er... why me?</p>
-Rain (Rain@anon.iip) has joined channel #i2p</p>
-<human> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>: (i didn't see any meeting agenda, though)</p>
-<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> human: why not, you're sober</p>
-<wilde> let's make an agenda ourselves</p>
-<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> yeah you guys know the general issues</p>
-<wilde> there are many topics to discuss</p>
-<UL ></p>
-<li> human will direct the meeting in exchange of the sacrifice of the first daughter of every participant</p>
-</UL></p>
-<wilde> funding, strategy, marketing, website, recruiting more developers and powerusers, etc</p>
-<human> wilde: i agree, we could informally talk about the recent history of I2P</p>
-<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> wilde: open a text window and quickly make a numbered agenda</p>
-<UL ></p>
-<li> human agrees with wilde </p>
-</UL></p>
-> As the first item don't we need to add massive responsibilites to jrandom in absentia?</p>
-Signoff: wilde (Ping timeout)</p>
-Signoff: ion (Ping timeout)</p>
-<UL ></p>
-<li> human agrees with baffled, too</p>
-</UL></p>
-wilde (~anon@anon.iip) has joined channel #i2p</p>
-<wilde> back</p>
-> you're the first to say anything your in charge.</p>
-<wilde> who? me?</p>
-jar (jar@anon.iip) has joined channel #i2p</p>
-> quit looking surprised.</p>
-<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> you guys are funny :)</p>
-> hey jar.</p>
-<jar> 'lo baffled :)</p>
-<jar> 'lo i2p !</p>
-ion (ion@anon.iip) has joined channel #i2p</p>
-<UL ></p>
-<li> human started logging the meeting (or whatever it will be)</p>
-</UL></p>
-> We elected wild to run the meeting because he was the first to say anything after meeting time.</p>
-<wilde> ok</p>
-jrand0m (jrand0m@anon.iip) has joined channel #i2p</p>
-<wilde> 1. Hello</p>
-<wilde> 2. Status I2P</p>
-<wilde> 3. How to help I2P Project</p>
-<wilde> 4. Recruiting more developers</p>
-<wilde> 5. Raising money (donations, selling t-shirts)</p>
-<wilde> 6. General discussion</p>
-<human> jrand0m: has appeared!!!</p>
-<wilde> hey jrand0m!</p>
-> I'll take a t-shirt.</p>
-<human> our experiment succeeded!!!</p>
-<jrand0m> shit thought I missed it :)</p>
-<UL ></p>
-<li> jrand0m leaves the floor to wilde ;)</p>
-</UL></p>
-> You better look back through the log jrandom.</p>
-<wilde> ok boss you could modify the agenda as you like</p>
-<jrand0m> <a href="http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html">http://i2p.dnsalias.net/pipermail/i2p/2004-February/000144.html</a></p>
-<UL ></p>
-<li> jrand0m just posted</p>
-</UL></p>
-> Are the t-shirts good?</p>
-<jrand0m> they had better be</p>
-<UL ></p>
-<li> jrand0m apologizes for being late, been avoiding looking at the monitor today (killer headache)</p>
-</UL></p>
-> No apology necessary or expected.</p>
-<wilde> np, we prepared an emergency plan</p>
-<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</p>
-Signoff: ion (Ping timeout)</p>
-<jrand0m> hah nice</p>
-<jrand0m> perhaps we can jump into that agenda, or are we on 1, 2, 3, 6?</p>
-<wilde> 0.</p>
-<wilde> 1. Hello</p>
-<wilde> Hello I2P</p>
-<fidd> hi</p>
-<jrand0m> hi</p>
-<jar> hi</p>
-<kaji> ah, i made it</p>
-<wilde> last hellos? going once, going twice...</p>
-<kaji> hi</p>
-> Which agenda the one you posted or the oone wild posted?</p>
-<jrand0m> perhaps I can help out with agenda 2) status</p>
-<wilde> 2. Status I2P</p>
-<jrand0m> the router, as is, is nonfunctional</p>
-<wilde> so how are we post-testnet?</p>
-> can we cote on that?</p>
-<jrand0m> post testnet, yes, but I introduced two bugs in the process</p>
-> vote.</p>
-<jrand0m> vote on whether its nonfunctional?</p>
-> Right.</p>
-<UL ></p>
-<li> jrand0m wonders if we vote hard enough it'll be functional again</p>
-</UL></p>
-<kaji> its dead for me</p>
-> oh, nevermind.</p>
-> well, we held hands and you appeared.</p>
-<jrand0m> hey, worth a shot ;)</p>
-<UL ></p>
-<li> jrand0m starts a bug-excorcism seance</p>
-</UL></p>
-> does that make them bogobugs?</p>
-<UL ></p>
-<li> DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a> sprinkles dried blood on the floor</p>
-<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</p>
-</UL></p>
-> oh wooooow!</p>
-<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</p>
-<wilde> so there's a short i2p vacation</p>
-<jrand0m> none, I use that build on xp</p>
-<jrand0m> the bug is programmer error, probably a trivial one too</p>
-<jrand0m> (but quite fatal)</p>
-<jrand0m> right wilde</p>
-<jrand0m> but after that, I've been making a bunch of progress on the docs for 0.2.5 and 0.3</p>
-<jrand0m> so I don't think they'll be a full two weeks out</p>
-<jrand0m> but we'll cross that bridge when we come to it.</p>
-<wilde> nice, any application improvments anyone?</p>
-<jrand0m> one idea - on the testnet, we focused a lot on irc and echo, more than eepsites</p>
-<UL ></p>
-<li> wilde notes in the black book who hasn't done todays homework, a cool I2P application</p>
-</UL></p>
-> Do you think they suffered for that? I certainly do.</p>
-<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</p>
-<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) </p>
-Signoff: Robert (Ping timeout)</p>
-> What do you consider a lot of clients on one router?</p>
-<jrand0m> I dont know, I would like once 0.2.4.x is out and usable that we can use both IRC and eepsites</p>
-<jrand0m> that depends on the computer</p>
-<wilde> so what's best for now? eepsites or irc?</p>
-<UL ></p>
-<li> jrand0m wants both, and we will have both functional in the mid and long run</p>
-</UL></p>
-<jrand0m> anyway, we can see as 0.2.4.x comes out.  perhaps both will be fine again.</p>
-<wilde> yeah but what's most useful for debugging? continous connections or sporadic ones?</p>
-<jrand0m> both ;)</p>
-<wilde> lighweight irc, or eep graphics?</p>
-<jrand0m> i2p needs to support long term streaming connections and short term bursty ones</p>
-<kaji> what about heavy long downloads?</p>
-<jrand0m> right, long term streaming connections</p>
-<jrand0m> (though I do think filesharing over i2p would best be served with i2psnark via messages, ala udp)</p>
-<wilde> the question really is: you suggested narrowing the test scope, was that to IRC or EEP?</p>
-<wilde> (or something else)</p>
-<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)</p>
-lucky (~lucky@anon.iip) has joined channel #i2p</p>
-<wilde> ok, that's probably wise</p>
-<jrand0m> anyone have any dev status for client apps?</p>
-<wilde> so the focus should be on services that can us some statistics, like the irc scripts</p>
-<jrand0m> that is definitely key.</p>
-Newsbyte (~fredisdea@anon.iip) has joined channel #i2p</p>
-<jrand0m> woah</p>
-<jrand0m> hi Newsbyte</p>
-<Newsbyte> ah, jran</p>
-<UL ></p>
-<li> wilde looks at the clock and at Newsbyte, late arrival, that will cost you an apple</p>
-</UL></p>
-<Newsbyte> huh?</p>
-<Newsbyte> I never come here</p>
-<jrand0m> also, the echo server and client app is great at gathering stats, and doesn't have any irc-specific dependencies. </p>
-<wilde> nothing</p>
-<Newsbyte> besides, what's an I2P meeting without nop? ;-)</p>
-<DrWoo<a href="iip-wiki?action=edit&id=DrWoo" class=wikipageedit>?</a>> wilde: heh somehow I dont think hes here for the meeting :)</p>
-<human> would an eepsite monitoring tool be useful?</p>
-<Newsbyte> no nop, no meeting</p>
-<UL ></p>
-<li> Newsbyte can summarise</p>
-</UL></p>
-<wilde> jrand0m: is there something else you'd like to have statistics in the network?</p>
-<jrand0m> human> certainly - perhaps some way to do periodic pings of eepsites, maybe keeping track of changes even?</p>
-<human> jrand0m: keeping track of what changes?</p>
-<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</p>
-<jrand0m> content on the page changing </p>
-<Newsbyte> yes, and use more then one server</p>
-<wilde> a kb/s meter, I2P Pirate Radio someone?</p>
-<jrand0m> hmm?  right, when the net is up we usually have between 4-10 servers</p>
-<human> jrand0m: it's doable but... how would you use the content change information?</p>
-<kaji> i ran a shoutcast stream for a while</p>
-<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])</p>
-<jrand0m> nice kaji</p>
-<jrand0m> yeah, aum's streams were up periodically as well</p>
-<human> jrand0m: oh, ok, now i understand</p>
-<mihi> jrand0m: a chargen service? ;)</p>
-<madman2003> bye everyone, good luck with i2p</p>
-<wilde> so throuhput is one stat that would be interesting/useful</p>
-<jrand0m> later madman2003</p>
-<wilde> cya madman2003</p>
-Signoff: madman2003 (..12(. www...nnscript...de .12.::. .N.o.N.ame.S.cript 3...8 .12.::. www...XLhost...de. .12.).)</p>
-> Well, I have another meeting at five as usual so I'll bbl.  Remember to put me down for a t-shirt.</p>
-<jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler)</p>
-baffled (~kirk@anon.iip) has joined channel #i2p</p>
-mrflibble (mrflibble@anon.iip) has joined channel #i2p</p>
--Trent@anon.iip- The nickname baffled is not registered</p>
-Ocelot (~Ocelot@anon.iip) has joined channel #i2p</p>
-Rain (~Rain@anon.iip) has joined channel #i2p</p>
-nickthief61599 (~chatzilla@anon.iip) has joined channel #i2p</p>
-lucky (~lucky@anon.iip) has joined channel #i2p</p>
-backup (~ypo@anon.iip) has joined channel #i2p</p>
-Sonax (~Sonax@anon.iip) has joined channel #i2p</p>
-jar (jar@anon.iip) has joined channel #i2p</p>
-wilde (~anon@anon.iip) has joined channel #i2p</p>
-Signoff: backup (Ping timeout)</p>
-<wilde> hey</p>
-<wilde> is the network unstable?</p>
-<wilde> I just couldn't get back on</p>
-Signoff: thecrypto (Leaving)</p>
-<lucky> yea</p>
-<lucky> its a bit... ugh.</p>
-<lucky> recently.</p>
-<wilde> what happened to the meeting?</p>
-<lucky> probably got decimated</p>
-<wilde> ok lucky what was the last thing you saw from the meeting? (msg me)</p>
-<lucky> <wilde> cya madman2003</p>
-<lucky> <-- madman2003 has quit (( www.nnscript.de :: NoNameScript<a href="iip-wiki?action=edit&id=NoNameScript" class=wikipageedit>?</a> 3.8 :: www.XLhost.de ))</p>
-<lucky> <jrand0m> yes mihi, that'd work (but streaming .ogg sounds cooler)</p>
-Galaxy (yogi@anon.iip) has joined channel #i2p</p>
-<wilde> ok that's where it ended for me too</p>
-<fidd> me2</p>
-Signoff: Sonax (EOF From client)</p>
-Sonax (~Sonax@anon.iip) has joined channel #i2p</p>
-<kaji> the meeting got nuked</p>
-kaji has changed the topic on channel #i2p to nuked</p>
-<kaji> ping?</p>
-<jar> pong!</p>
-<kaji> ok</p>
-<kaji> ithough it crashed again</p>
-<jar> yep :(</p>
-Signoff: wilde ()</p>
-<kaji> so... meeting?</p>
-<jar> ending brutaly ...</p>
-<jar> more signs of jrandom, it seems it's all for the moment</p>
-<jar> next move on 0.2.4.2 in few days ....</p>
-<jar> (one or two as said jr)</p>
-mihi_backup (~mihi@anon.iip) has joined channel #i2p</p>
-jar is now known as jar_</p>
-sheer (sheer@anon.iip) has joined channel #i2p</p>
-<kaji> wilde said something about funding, but last time i asked jran he said i2p wasnt in a position to need money atm</p>
-Signoff: Ranma ()</p>
-Robert (~chatzilla@anon.iip) has joined channel #i2p</p>
-Sonax is now known as JaSiger<a href="iip-wiki?action=edit&id=JaSiger" class=wikipageedit>?</a></p>
-JaSiger<a href="iip-wiki?action=edit&id=JaSiger" class=wikipageedit>?</a> is now known as Sonax</p>
-Signoff: Rain (I Quit)</p>
-zathras (~zathras@anon.iip) has joined channel #i2p</p>
-Ranma (ranma@anon.iip) has joined channel #i2p</p>
-mihi (mihi@anon.iip) has joined channel #i2p</p>
-<mihi> hmm, what happened to the meeting?</p>
-<UL ></p>
-<li> mihi has an idea</p>
-</UL></p>
-<mihi> ;)</p>
-Mode change "+o mihi" on channel #i2p by Trent@anon.iip</p>
-Mode change "-o duck" on channel #i2p by mihi</p>
-<mihi> no one knowing anything about the meeting?</p>
-<UL ></p>
-<li> mihi notices that no one fears ops any longer ;)</p>
-</UL></p>
-Signoff: zathras (Ping timeout)</p>
-mihi_backup has been kicked off channel #i2p by mihi (mihi)</p>
-zathras (~zathras@anon.iip) has joined channel #i2p</p>
-Signoff: Sonax (Client exiting)</p>
-<lucky> mihi, we lall got kicked for the meoeting</p>
-hacktic4ever (~hacktic4e@anon.iip) has joined channel #i2p</p>
-Signoff: hacktic4ever ()</p>
-<mihi> ok, nite</p>
-<duck> hello</p>
-Signoff: sheer (EOF From client)</p>
-Signoff: mihi (let's have more luck next week...)</p>
-<duck> did I miss anything?</p>
-Signoff: jnk (Ping timeout)</p>
-{% endblock %}
\ No newline at end of file
+<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/78.rst b/i2p2www/meetings/78.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/78.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/79.log b/i2p2www/meetings/79.log
index 640658db..c63dca94 100644
--- a/i2p2www/meetings/79.log
+++ b/i2p2www/meetings/79.log
@@ -1,187 +1,181 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 79{% endblock %}
-{% block content %}<h3>Tuesday, Feb 24, 2004 22:00:00 CET</h3>
-<div class="irclog">
-[22:00] <jrand0m> 0) hi</p>
-[22:00] <jrand0m> 1) 0.2.4.2/0.2.5</p>
-[22:00] <jrand0m> 2) docs</p>
-[22:00] <jrand0m> 3) ???</p>
-[22:00] <jrand0m> 0) hi</p>
-[22:00] <human> hi</p>
-[22:00] * jrand0m waves to the newly-restarted iip-ircd :)</p>
-[22:01] <jrand0m> (and, uh, to you :)</p>
-[22:01] <jrand0m> weekly status notes (that we're running off) located at http://i2p.dnsalias.net/pipermail/i2p/2004-February/000148.html</p>
-[22:01] <jrand0m> (and posted to the mailing list, obviously)</p>
-[22:01] <jrand0m> 1) 0.2.4.2/0.2.5</p>
-[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</p>
-[22:03] <jrand0m> the key functionality that will provide will be increased reliability and functional anonymity</p>
-[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</p>
-[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</p>
-[22:06] <jrand0m> (bugfixes underway)</p>
-[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</p>
-[22:07] * mihi has joined #i2p</p>
-[22:07] <jrand0m> heya mihi</p>
-[22:07] * protocol has quit IRC (Ping timeout)</p>
-[22:07] <jrand0m> ok, thats it for the router dev status, moving on to 2) docs</p>
-[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)</p>
-[22:07] <jrand0m> hm</p>
-[22:08] <human> maybe we could talk about it after the meeting...</p>
-[22:08] <jrand0m> in reliability terms, latency, CPU, bandwidth?</p>
-[22:08] * protocol has joined #i2p</p>
-[22:08] <mihi> hi jrand0m, hi all</p>
-[22:08] <human> jrand0m: i can't reach any eepsite or I2P service (with few temporary exceptions)</p>
-[22:08] * mihi seconds human</p>
-[22:09] <jrand0m> most eepsites are down - duck, baffled, madman2003 are the most consistently up lately</p>
-[22:09] <human> jrand0m: i can't reach them, nor irc.*.i2p</p>
-[22:09] <jrand0m> squid I use constantly for all my web browsing - are you unable to use that?</p>
-[22:09] <human> jrand0m: nope</p>
-[22:09] <jrand0m> hm</p>
-[22:10] <madman-away> well an uptime of about 8 hours daily for my i2p site</p>
-[22:10] <human> jrand0m: we could talk about it after the meeting, i don't want to monopolize the discussion :-)</p>
-[22:10] * madman-away is now known as madman2003</p>
-[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 :(</p>
-[22:10] <Janonymous> me too</p>
-[22:10] <human> jrand0m: just to point out that some problems seems to exist (that weren't shown before)</p>
-[22:10] <Janonymous> mine should be up now</p>
-[22:11] <madman2003> what destination?</p>
-[22:11] <jrand0m> well, 'k, if things are going backwards in reliability we need to address that before moving on to 0.2.5</p>
-[22:11] * mihi hates babelfish's english :(</p>
-[22:11] <jrand0m> heh</p>
-[22:12] <jrand0m> (well, it got the Thank you for your understanding. sentence correct at least...)</p>
-[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)</p>
-[22:12] <jrand0m> 0.2.4.0 was shit, as was 0.2.4.1</p>
-[22:12] * wilde has joined #i2p</p>
-[22:13] <human> jrand0m: i know, and it worries me...</p>
-[22:13] <wilde> hey i2p</p>
-[22:13] <jrand0m> heya wilde</p>
-[22:13] <madman2003> one thing i noticed is that tunnels tend to get unstable more often</p>
-[22:13] <human> jrand0m: i didn't change too much with 0.2.4.2 (at least for me)</p>
-[22:13] <human> jrand0m: s/ i / it /</p>
-[22:14] <jrand0m> madman2003> thats easily due to routers going on and offline (which will be a big problem until 0.3)</p>
-[22:14] <jrand0m> hmm ok</p>
-[22:14] <wilde> jrand0m: does that mean we should avoid running transients for now?</p>
-[22:15] * mihi has quit IRC (Ping timeout)</p>
-[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.</p>
-[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)</p>
-[22:16] <jrand0m> but as long as routers generally stay up or generally down, they're fine</p>
-[22:17] <jrand0m> (just not up 10 minutes, down 10 minutes, up 30, down 30, etc)</p>
-[22:17] <madman2003> i do have one request: an option for the router(and tunnels) to be reastablished</p>
-[22:17] <baffled> i2p is an equal router opertunity organization?</p>
-[22:17] <jrand0m> heh baffled</p>
-[22:18] <jrand0m> madman2003> router to be reestablished?  your router is shutting down still?</p>
-[22:18] <madman2003> i mean reconnecting everything</p>
-[22:18] <madman2003> sort of a warm restart of the router</p>
-[22:18] <madman2003> without pissing of the other routers</p>
-[22:18] <madman2003> (i have to restart router and tunnels a lot)</p>
-[22:18] <jrand0m> you can safely restart your client apps (e.g. i2ptunnel eepproxy, etc) without touching the rotuer</p>
-[22:19] <jrand0m> you should /never/ need to restart your router.</p>
-[22:19] <jrand0m> (almost all config settings are updated dynamically)</p>
-[22:19] * Trix has joined #i2p</p>
-[22:19] <jrand0m> hi Trix</p>
-[22:19] <Trix> hi</p>
-[22:19] <madman2003> usually restarting the tunnels does the trick</p>
-[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.</p>
-[22:22] <jrand0m> (in fact, restarting tunnels can cause temporary problems, depending on the type of tunnel)</p>
-[22:22] <madman2003> sometimes i just don't know if i'm causing problems or if someone else is</p>
-[22:22] <jrand0m> if your router console doesn't have any of the red warnings, its the network (or someone else)</p>
-[22:22] * jnk has joined #i2p</p>
-[22:23] <jrand0m> patience fixes more of the current i2p bugs than restarts do ;)</p>
-[22:24] <jrand0m> but we'll have another series of bugfix releases after 0.2.5</p>
-[22:24] <jrand0m> (like testnet, except without the restrictions on the userbase)</p>
-[22:25] <jrand0m> (and, as always, whenever things break, logs are appreciated :)</p>
-[22:25] <jrand0m> anyway, moving on to 2) docs</p>
-[22:26] <jrand0m> as posted in http://i2p.net/pipermail/i2p/2004-February/000147.html there've been some new overview docs</p>
-[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</p>
-[22:28] <madman2003> i read them and i hope you were right about the possibilty to safely reduce the amount of crypto</p>
-[22:29] <wilde> layers of crypto or # of bits?</p>
-[22:29] <jrand0m> I'm not convinced that the crypto is the bottleneck, but its a possibility</p>
-[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</p>
-[22:30] <madman2003> the problem is finding your way</p>
-[22:30] <jrand0m> hmm?</p>
-[22:31] <madman2003> a static path is usually well found</p>
-[22:31] <madman2003> a more dynamic one is more difficult to establish</p>
-[22:32] <madman2003> (i'm talking about the inability to properly handle routers going offline)</p>
-[22:32] <jrand0m> ah, thought you were talking about crypto</p>
-[22:32] <jrand0m> its going to be fairly easy to handle unreliable routers, its just the 0.3 code</p>
-[22:33] * jrand0m has ~30 pages of notes on different techniques, its all workable, just lots to do</p>
-[22:33] * protocol has quit IRC</p>
-[22:34] <madman2003> maybe an idea to have backup routes ready</p>
-[22:34] <madman2003> tunnel redundancy</p>
-[22:34] <jrand0m> right, thats 0.2.5 - multiple leases</p>
-[22:35] <jrand0m> (lease == declaration that a destination can be reached through a specific tunnel)</p>
-[22:35] <madman2003> i'll be awaiting that :)</p>
-[22:36] <jrand0m> w3rd</p>
-[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</p>
-[22:38] <jrand0m> ok, moving on at a rapid pace to 3) ???</p>
-[22:38] <jrand0m> anything people want to bring up and discuss?</p>
-[22:39] <DrWoo> potatoes are fucking cheap yet potatoe chips are expensive, what's up with that?</p>
-[22:39] <DrWoo> :)</p>
-[22:39] <jrand0m> its a conspiracy!</p>
-[22:40] * DrWoo thinks jrand0m has the answer for most anything :)</p>
-[22:40] <jrand0m> of course, you can blame anything on conspiracies.</p>
-[22:40] <jrand0m> ok</p>
-[22:40] <wilde> Stego ?</p>
-[22:40] * human accepts suggestions about how to expose I2CP-like message-oriented functionality to non-java apps</p>
-[22:41] <wilde> how I2P will implement Stego so an ordinary portscan will reveal nothing </p>
-[22:41] <wilde> not even random bytes</p>
-[22:41] * human may (does?) sound repetitive... he's thinking about VPNs over I2P with http://openvpn.sf.net/</p>
-[22:41] <jrand0m> well, for one, PHTTP.</p>
-[22:42] <jrand0m> openvpn does look very interesting - I hadn't realized tun/tap had windows ports</p>
-[22:42] <jrand0m> a simple message oriented socket bridge for I2CP should be very easy</p>
-[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)</p>
-[22:43] * madman2003 has quit IRC (12( www.nnscript.de 12:: NoNameScript 3.8 12:: www.XLhost.de 12))</p>
-[22:43] <baffled> okay as usual I have another appointment in 15m so I'll catch up later.</p>
-[22:43] <jrand0m> right, if we wanted to integrate with a webserver/etc to silent bob, we could</p>
-[22:43] <jrand0m> cool, later baffled</p>
-[22:44] <jrand0m> (but silent bob doesnt prevent portscan detection, it just makes it look like another service)</p>
-[22:44] <wilde> I rather not have random people or ISP:s portscan me and find ports open</p>
-[22:44] <wilde> ok</p>
-[22:44] <human> jrand0m: ok, i'll work on it when I2P will work again on my PC :-)</p>
-[22:44] <jrand0m> UDP would work as well</p>
-[22:44] <jrand0m> :) human</p>
-[22:45] * kaji has joined #i2p</p>
-[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</p>
-[22:46] <wilde> is there a way of hiding an open port from java program, without messing with the OS or firewall</p>
-[22:46] <human> w00t!</p>
-[22:47] <jrand0m> you mean to have a listening TCP socket that can't be portscanned?  no, not directly from Java.</p>
-[22:47] <wilde> ok</p>
-[22:48] <jrand0m> (i dont even know how to do that in other langs)</p>
-[22:48] <jrand0m> udp would probably be the best way to go for that</p>
-[22:48] * human invites people to try to telnet human.i2p (tunneled TCP echo server) and type something in</p>
-[22:48] <wilde> that would be a little C program filtering and forwarding to another port maybe</p>
-[22:49] * kaji_ has joined #i2p</p>
-[22:49] <jrand0m> if it accepts TCP connections, its already too late, if I understand your concern correctly.</p>
-[22:49] <Janonymous> how do you telnet?</p>
-[22:49] <kaji_> finaly</p>
-[22:50] <kaji_> that took forever, iip usability sucks dick atm</p>
-[22:50] * kaji has quit IRC (Ping timeout)</p>
-[22:51] <duck> if you are concerned about open ports, you could use rTCP / PHTTP / whatever couldnt you?</p>
-[22:51] <Janonymous> damn...  hey, jr, are those new docs accessable from the main i2p page?</p>
-[22:51] <human> Janonymous: java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 12221 human.i2p"</p>
-[22:51] <jrand0m> no Janonymous, just from the links on that email</p>
-[22:51] <human> Janonymous: then telnet localhost 12221</p>
-[22:51] <jrand0m> duck> right</p>
-[22:52] <Janonymous> k</p>
-[22:52] <duck> (ofcourse whatever can be a silentbob/stealth/stego transport)</p>
-[22:52] <jrand0m> human> Message send failed after 61226ms with 391 bytes</p>
-[22:53] <human> jrand0m: and it means that...?</p>
-[22:53] <jrand0m> that means I cant reach your echo</p>
-[22:53] <duck> -nogui is depricated :)</p>
-[22:53] <jrand0m> can you reach duck.i2p?</p>
-[22:54] <wilde> scary, i googled for rtcp: http://dret.net/glossary/rtcp</p>
-[22:54] <jrand0m> right, rtcp is taken :/</p>
-[22:54] <human> jrand0m: i'm trying, but i can't reach duck.i2p since a looong time ago...</p>
-[22:54] <jrand0m> wilde> http://wiki.invisiblenet.net/iip-wiki?RelayingTCP</p>
-[22:54] <wilde> "Wilde's WWW Online Glossary"</p>
-[22:55] <jrand0m> hehe oh yeah :)</p>
-[22:55] <jrand0m> human> thats a definite Bad Thing, as its up almost always - could you bounce me your log-*.txt?</p>
-[22:56] <human> Started on:  Tue Feb 24 10:21:22 GMT 2004</p>
-[22:56] <human> Version: Router: 0.2.4.2 / SDK: 0.2.4.2</p>
-[22:56] <human> Bandwidth used: 56096295 bytes sent, 34308394 bytes received (avg 1.44KBps sent 0.88KBps received)</p>
-[22:56] <human> jrand0m: ok, logs coming on meshmx</p>
-[22:56] <jrand0m> gracias</p>
-[22:56] <jrand0m> ok, anyone have anything else to bring up?</p>
-[22:58] * jrand0m winds up</p>
-[22:58] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/79.rst b/i2p2www/meetings/79.rst
new file mode 100644
index 00000000..5bec831f
--- /dev/null
+++ b/i2p2www/meetings/79.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, February 24, 2004 @ 22:00 CET
+==============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/8.log b/i2p2www/meetings/8.log
index cece81c3..e73f9c5c 100644
--- a/i2p2www/meetings/8.log
+++ b/i2p2www/meetings/8.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 8{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 8</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Tue Aug 13 23:58:45 2002
 23:58 [Users #iip-dev]
 23:58 [@logger] 
@@ -145,5 +138,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 01:26 < Robert> No sir.
 01:27 <@mids> then I'll end my monologue :)
 --- Log closed Wed Aug 14 01:28:33 2002
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/8.rst b/i2p2www/meetings/8.rst
new file mode 100644
index 00000000..4e770e04
--- /dev/null
+++ b/i2p2www/meetings/8.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 13, 2002 @ 23:00 UTC
+============================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/80.log b/i2p2www/meetings/80.log
index 3e3cb91c..9c6e7fc2 100644
--- a/i2p2www/meetings/80.log
+++ b/i2p2www/meetings/80.log
@@ -1,358 +1,352 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 80{% endblock %}
-{% block content %}<h3>Tuesday, Mar 2, 2004 13:00:00 PST</h3>
-<div class="irclog">
-13:07 < jrandom> 0) hi</p>
-13:07 < jrandom> 1) Dev status</p>
-13:07 < jrandom> 2) Cascades</p>
-13:07 < duck> I'll stop</p>
-13:07 < jrandom> 3) Roadmap</p>
-13:07 < jrandom> 4) Website</p>
-13:07 < jrandom> 5) ???</p>
-13:07 < jrandom> 0) hi</p>
-13:07  * jrandom waves to the first over-i2p i2p dev meeting :)</p>
-13:07 < ughabugha> nick is Janonymous.</p>
-13:08 < ughabugha> Ok.</p>
-13:08 < duck> hi</p>
-13:08 < jrandom> weekly status notes are posted to the mailing list (online at http://i2p.net/pipermail/i2p/2004-March/000155.html)</p>
-13:08 < ughabugha> hi.</p>
-13:08 < jrandom> as usual, we'll be following that as a guide</p>
-13:08 < nick> hello</p>
-13:09 < jrandom> jumping into 1) Dev status</p>
-13:09  * jrandom repeats mantra of "Progress is being made"</p>
-13:10 < jrandom> 0.2.5 has some Good Stuff, and we're finding long hidden bugs</p>
-13:10 < jrandom> latest one is db related, but thats not fixed up yet, so no need to track CVS HEAD</p>
-13:11 < jrandom> echo tests show pretty good results, but there's still issues to be worked out wrt irc and snark</p>
-13:12 < jrandom> how has eepsite retrieval been for people?</p>
-13:12 < jrandom> (and/or squid?)</p>
-13:12 < nick> here and there</p>
-13:12 < duck> generally okay with janonymous or ugha</p>
-13:13 < duck> sometimes janonymous goes down etc</p>
-13:13 < ughabugha> Yeah.</p>
-13:13 < duck> <mihi_backup> jrandom: you *really* know how to make me angry...</p>
-13:13 < jrandom> d'oh</p>
-13:13 < nick> I've been putting new content</p>
-13:13 < jrandom> whats up mihi?</p>
-13:13 < jrandom> nice nick</p>
-13:14 < jrandom> er janonymous</p>
-13:15 < nick> eh?</p>
-13:15 < nick> :)</p>
-13:15 < ughabugha> IIP <ughabugha> I started a two-way relay now.</p>
-13:15 < jrandom> ah cool</p>
-13:15 -!- nick [~Janonym@localhost] has quit [Client closed connection]</p>
-13:15 < jrandom> whats up mihi?</p>
-13:15 < ughabugha> IIP <ughabugha> Automatic.</p>
-13:16 < ughabugha> IIP <ughabugha> :)</p>
-13:16 < ughabugha> :)</p>
-13:16 < ughabugha> IIP <ughabugha> Oops, a bug.</p>
-13:16 < ughabugha> Oops, a bug.</p>
-13:16 < jrandom> heh is he still there or is there anything else wrt dev status?</p>
-13:17 < duck> lets go on</p>
-13:17 < jrandom> 'k</p>
-13:17 < jrandom> jumping to 2) Cascades</p>
-13:17 < ughabugha> IIP <ughabugha> * mihi_backup is now known as mihi_away</p>
-13:17 < ughabugha> * mihi_backup is now known as mihi_away</p>
-13:17 < ughabugha> IIP <ughabugha> Argh, relaying for my own text doesn't work.</p>
-13:17 < ughabugha> Argh, relaying for my own text doesn't work.</p>
-13:17 < jrandom> ;)</p>
-13:18 < ughabugha> IIP <ughabugha> No, wait.</p>
-13:18 < ughabugha> No, wait.</p>
-13:18 < madman> then don't speak :)</p>
-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</p>
-13:19 < ughabugha> IIP <ughabugha> Test</p>
-13:19 < ughabugha> Test</p>
-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</p>
-13:19  * jrandom senses an incoming recursive echo...</p>
-13:19 < ughabugha> IIP <ughabugha> Damn!</p>
-13:19 < ughabugha> Damn!</p>
-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</p>
-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</p>
-13:21 < ughabugha> Ok, it should work _now_.</p>
-13:21 < ughabugha> IIP <ughabugha> Say something.</p>
-13:21 < ughabugha> IIP <Janonymous> I move to not go after a mix net implementation within the current roadmap, and leave that for later</p>
-13:21 < ughabugha> Yeah, it works now.</p>
-13:21 -!- wilde [~anon@localhost] has joined #i2p</p>
-13:22 < jrandom> janymous> well, i2p /is/ a mixnet, just not a mix cascade</p>
-13:22 < madman> i'm going offline</p>
-13:22 < jrandom> 'k, ttyl madman</p>
-13:22 < jrandom> heya wilde</p>
-13:22 < madman> so bye</p>
-13:22 < ughabugha> IIP <wilde> finally</p>
-13:22 < ughabugha> IIP <wilde> hello meeting</p>
-13:22 < jrandom> but I concur, I don't think mix cascade functionality needs to be on the roadmap</p>
-13:23 < ughabugha> IIP <madman2003> bye everyone</p>
-13:24 < jrandom> ok, anything else on cascades, or should we move to 3) Roadmap?</p>
-13:26 < ughabugha> Hi, wilde@IIP</p>
-13:26 < ughabugha> Bye, madman@IIP</p>
-13:26 -!- madman [~a@localhost] has quit [( www.nnscript.de :: NoNameScript 3.8 :: www.XLhost.de )]</p>
-13:26 < ughabugha> IIP <Janonymous> Just seems like it could be implemented later, like a DHT might be. High Wilde</p>
-13:26 < ughabugha> IIP <Janonymous> bye Madman</p>
---- Log closed Tue Mar 02 13:27:07 2004</p>
---- Log opened Tue Mar 02 13:27:52 2004</p>
-13:27 -!- jrandom [~jrandom@localhost] has joined #i2p</p>
-13:27 -!- Irssi: #i2p: Total of 3 nicks [0 ops, 0 halfops, 0 voices, 3 normal]</p>
-13:27 -!- wilde [~anon@localhost] has joined #i2p</p>
-13:27 < jrandom> back</p>
-13:28 < ughabugha> Uhoh, jrandom quitted.</p>
-13:28 < ughabugha> IIP <Janonymous> bah</p>
-13:28 < jrandom> ok last I saw was 13:26:08 < ughabugha> IIP <Janonymous> bye Madman</p>
-13:28 -!- Irssi: Join to #i2p was synced in 36 secs</p>
-13:28 < jrandom> (irssi missed a ping so it dropped it)</p>
-13:29 < ughabugha> You missed IIP <Janonymous> Roadmap</p>
-13:29 < ughabugha> IIP <Janonymous> ah.. We all agreed to go onto the roadmap ;)</p>
-13:29 < jrandom> w3rd</p>
-13:29 < jrandom> ok, the roadmap change is likely why mihi hates me now</p>
-13:30 < ughabugha> Uh, then you missed alot more than that.</p>
-13:30 < ughabugha> Just a second.</p>
-13:30 < ughabugha> [23:23 39] <ughabugha> IIP <wilde> oh we have to camps now, the iip gang and the I2P hood</p>
-13:30 < ughabugha> [23:23 47] <ughabugha> IIP <wilde> two</p>
-13:30 < ughabugha> [23:23 50] <ughabugha> Hehe.</p>
-13:30 < ughabugha> [23:23 54] <ughabugha> IIP <Janonymous> :) got a relay going</p>
-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.</p>
-13:30 < ughabugha> [23:24 44] <ughabugha> IIP <Janonymous> It works</p>
-13:30 < ughabugha> [23:25 18] <ughabugha> Ok, concentrate on I2P now, not the relay.</p>
-13:30 < ughabugha> [23:25 39] <ughabugha> IIP <Janonymous> So, mix cascades could feasably implemented quite well over i2p</p>
-13:30 < ughabugha> Sorry for the flood.</p>
-13:30 < duck> this is chaos</p>
-13:31 < ughabugha> IIP <Janonymous> but i think we can emphasize /over/</p>
-13:31 < ughabugha> Ok, 3) Roadmap</p>
-13:31 < ughabugha> duck: Pretty much.</p>
-13:31 < jrandom> this aint nothing compared to meeting 67 ;)</p>
-13:31 < jrandom> ok, on to 3</p>
-13:31 < jrandom> anyone have any thoughts wrt the roadmap?</p>
-13:32 < jrandom> the changes / views / concerns?</p>
-13:32 < ughabugha> IIP <Janonymous> Multi-tunneling</p>
-13:32 < jrandom> janonymous> we've already got that</p>
-13:32 < jrandom> (as of 0.2.5)</p>
-13:32 < jrandom> if I understand you correctly</p>
-13:33 < ughabugha> IIP <Janonymous> but, as in, sending one file over two tunnels to accelerate transmission?</p>
-13:33 < ughabugha> IIP <Janonymous> at the same time</p>
-13:34 < jrandom> i2p doesn't deal with files, but yes, each individual i2p message can now go down multiple tunnels</p>
-13:34 < ughabugha> IIP <Janonymous> I think that would be a great addition for the 2.0 area</p>
-13:34 < jrandom> e.g. first 32kb sent down tunnel X, next 32kb sent down tunnel Y</p>
-13:35 < ughabugha> IIP <Janonymous> right.. thats what I'm getting at.. that seems very necessary to me</p>
-13:35 < jrandom> but i2psnark with i2cp support would be able to maximize things</p>
-13:35 < jrandom> janonymous> we do that now</p>
-13:36 < ughabugha> IIP <Janonymous> oh. I2PSnark will utilize multiple tunnels for point to point communication?</p>
-13:36 < jrandom> all messages can go down multiple tunnels.</p>
-13:36 < duck> theoretically</p>
-13:37 < jrandom> not just theoretically - if a message takes > 15s, its sent down the other available lease</p>
-13:37 < jrandom> and if it takes > 30s, the leaseSet is dropped and refetched, with subsequent messages going down found leases</p>
-13:37 < jrandom> BUT</p>
-13:38 < jrandom> i2ptunnel (any anything else that uses i2p's mode=guaranteed) waits until each message is delivered before sending the next one</p>
-13:38 < jrandom> native i2cp apps don't need to do that</p>
-13:38 < jrandom> (nor will any apps that use the socket library, once the socket library is both implemented and supports SACK)</p>
-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</p>
-13:38 < ughabugha> IIP <Janonymous> and keeping strain off individual tunnels</p>
-13:39 < jrandom> agreed</p>
-13:39 < jrandom> ok, anything else on the roadmap?</p>
-13:40 < jrandom> (anyone going to bitch me out for dropping the socket lib?  mihi?  :)</p>
-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</p>
-13:42 < jrandom> pretty much</p>
-13:42 < jrandom> (though one's on-ramp is always the same number of lanes ;)</p>
-13:42 < duck> if mihi is angry he can do the socket api cant he?</p>
-13:43 < jrandom> sure, and/or anyone else.  the socket lib is Good</p>
-13:43 < jrandom> (but hard, and imho not functionally essential to the operation / security of the network)</p>
-13:44 < jrandom> i just wish i had the time to do it and keep moving on the core i2p code</p>
-13:44 < jrandom> but, c'est la vie</p>
-13:45 < ughabugha> IIP <Janonymous> looks like mihis not here</p>
-13:45 < ughabugha> Ok, i'm back now.</p>
-13:45 < jrandom> coo'</p>
-13:45 < jrandom> ok, moving on to 4) website</p>
-13:46 < ughabugha> IIP <Janonymous> big on ramp == cable / small on ramp == dialup ??</p>
-13:46 < ughabugha> Hmm</p>
-13:46 < ughabugha> What was the socket library going to do?</p>
-13:46 -!- nick [~Janonym@localhost] has joined #i2p</p>
-13:46 < jrandom> right nanonymous</p>
-13:46 < jrandom> er, janonymous</p>
-13:46 < jrandom> (no matter what, i2p cant make your local net connection faster)</p>
-13:46 < jrandom> ughabugha: http://wiki.invisiblenet.net/iip-wiki?I2PSocketLibrary</p>
-13:47 < ughabugha> I mean a socket library for Java? Don't you already have one?</p>
-13:47 < jrandom> the socket lib factors out the TCP-esque code out of i2p, letting i2p specialize in IP-like messages</p>
-13:47 < nick> yup</p>
-13:47 -!- nick [~Janonym@localhost] has quit [Client closed connection]</p>
-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)</p>
-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)</p>
-13:49 < ughabugha> But why drop it? Does it really take that much work?</p>
-13:49 < jrandom> yes, to get right</p>
-13:49 < jrandom> there's some code thats part way implemented, but i dont have time to maintain and test it</p>
-13:49 < ughabugha> Ok. You're the man.</p>
-13:50 < jrandom> well, $devWhoImplements it is the man ;)</p>
-13:50 < jrandom> anyway, moving on to 4) website</p>
-13:50 < ughabugha> :)</p>
-13:51 < ughabugha> Any volunteers?</p>
-13:51 < ughabugha> IIP <Janonymous> research on implementations of anonymous p2p</p>
-13:51  * jrandom echoes ughabugha's question :)</p>
-13:51 < jrandom> hmm janonymous?</p>
-13:51 < ughabugha> Janonymous: This will be covered under 5) ???</p>
-13:51 < jrandom> :)</p>
-13:52 < ughabugha> IIP <Janonymous> wll its content that goes on the site</p>
-13:52 < jrandom> ah, yeah, I agree</p>
-13:52 < jrandom> (see item 7 on http://i2p.net/pipermail/i2p/2004-February/000133.html)</p>
-13:53 < jrandom> and item 8</p>
-13:53 < jrandom> or is that not what you mean?</p>
-13:53 < jrandom> I'll probably post up the truckload of papers i dug through last summer when researching and designing i2p</p>
-13:53 < jrandom> (or at least pointers to their citeseer entries)</p>
-13:54 < ughabugha> IIP <Janonymous> Ok. Were we going to discuss the next CMS for I2P?</p>
-13:54 < ughabugha> jrandom allready chose the CMS.</p>
-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</p>
-13:55 < ughabugha> IIP <ughabugha> /topic #i2p</p>
-13:55 < ughabugha> IIP <Janonymous> Ok.. well, as far as what to put there.. We need a presentation</p>
-13:55 < jrandom> if we need to migrate to another one, wilde assures me its simple enough to export content</p>
-13:55 < jrandom> a presentation?</p>
-13:56 < ughabugha> IIP <Janonymous> with lots of illustrations and a step by step introduction to I2P</p>
-13:56 < jrandom> we do need the graphic design implemented</p>
-13:56 < jrandom> ah right</p>
-13:56 < jrandom> a user's intro</p>
-13:56 < jrandom> the wiki intro is generally a technie intro</p>
-13:56 < ughabugha> IIP <Janonymous> Almost like a multimedia presentation</p>
-13:56 < ughabugha> IIP <jrand0m> w0ah</p>
-13:56 < ughabugha> IIP <Janonymous> right</p>
-13:57 < ughabugha> IIP <ughabugha> Yay!</p>
-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</p>
-13:57 < ughabugha> IIP <Janonymous> In it, there should be more pictures, than words. :)</p>
-13:57 < jrandom> right</p>
-13:58 < ughabugha> IIP <Janonymous> righto</p>
-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</p>
-13:58 < ughabugha> This is not the top priority right now.</p>
-13:58 < ughabugha> IIP <Janonymous> certainly not. but for those of us not programming...</p>
-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</p>
-14:00 < ughabugha> IIP <Janonymous> I've got a month to spare. Think it would be time well spent.</p>
-14:00 < jrandom> w00t :)</p>
-14:00  * jrandom marks Janonymous down as a volunteer... for content design & content creation?</p>
-14:00 < wilde> back</p>
-14:00 < ughabugha> Well, I could do HTML, CSS and the technical stuff, but I'm not much of a writer, nor a designer.</p>
-14:01 < jrandom> r0x0r</p>
-14:01 < ughabugha> IIP <Janonymous> right.. I'm not so good at the designing part yet</p>
-14:01 < ughabugha> IIP <Janonymous> I could try to write, but not without some good critique.. I've never writen editorial type things</p>
-14:01 < ughabugha> I can also use Photoshop and other tools as long as I'm given specific instructions on what to do. ;)</p>
-14:01 < wilde> I'll take care of drupal and features</p>
-14:02 < ughabugha> IIP <Janonymous> I've got some good ideas for you ughabugha</p>
-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</p>
-14:02 < ughabugha> Heh, ok. :)</p>
-14:02 < jrandom> r0x0r0r</p>
-14:02  * jrandom marks down wilde and ughabugha as volunteers :)</p>
-14:02 < ughabugha> Looking forward to them.</p>
-14:02 < ughabugha> IIP <Janonymous> there's a shaby picture I made that can be found linked to the new I2POverview doc on I2p</p>
-14:03 < jrandom> word, yeah janonymous, that pic is pretty good, some minor tech issues with it, but quite useful</p>
-14:03 < ughabugha> IIP <Janonymous> It would look alot nicer in photoshop I'm sure</p>
-14:04 < ughabugha> Heh.</p>
-14:04 < ughabugha> Janonymous: Let's discuss that privately tomorrow.</p>
-14:04 < ughabugha> IIP <Janonymous> eh, actually I may have accidentally deleted it :/</p>
-14:04 < jrandom> ok, anything else for the website, or can we move on to 5) ???</p>
-14:04 < ughabugha> IIP <Janonymous> ok</p>
-14:07 < wilde> ok one thing:</p>
-14:07 < ughabugha> Anything else on website?</p>
-14:07 < wilde> what is the first feeling you should get on the site?</p>
-14:07 < wilde> keywords please</p>
-14:07 < jrandom> wilde> see http://i2p.net/pipermail/i2p/2004-February/000133.html (the "rom a branding perspective" paragraph :)</p>
-14:08 < jrandom> i do like the anonymous bit by bit thing</p>
-14:08 < ughabugha> I suppose not. Should we go on to 5) ??? ?</p>
-14:08 < ughabugha> IIP <Janonymous> should we make a more detailed user roadmap?</p>
-14:08 < ughabugha> IIP <Janonymous> one describing the long term goals in more detail</p>
-14:08 < ughabugha> wilde: Only positive emotions.</p>
-14:09 < jrandom> janonymous> agreed, the current roadmap is really just tech notes for tech tasks ;)</p>
-14:09 < jrandom> ok, 5) ??</p>
-14:09 < jrandom> anything y'all want to bring up?</p>
-14:10 < wilde> itoopie isn't really in line with simple and secure</p>
-14:10 < wilde> it's more of a cartoon feeling</p>
-14:10 < wilde> that's why i asked</p>
-14:10 < ughabugha> IIP <Janonymous> yea, might want to build some more anticipation</p>
-14:10 < ughabugha> IIP <Janonymous> for the users to get involved</p>
-14:10 -!- kaji [~booky5@localhost] has joined #i2p</p>
---- Log closed Tue Mar 02 14:11:08 2004</p>
---- Log opened Tue Mar 02 14:12:12 2004</p>
-14:12 -!- jrandom_ [~jrandom@localhost] has joined #i2p</p>
-14:12 -!- Irssi: #i2p: Total of 6 nicks [0 ops, 0 halfops, 0 voices, 6 normal]</p>
-14:12 < jrandom_> back</p>
-14:12 < ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there</p>
-14:12 < jrandom_> wilde> I'm open to suggestions</p>
-14:12 < ughabugha> * jrandom_ (~jrandom@localhost) has joined #i2p</p>
-14:12 < jrandom_>  <Janonymous> yea, might want to build some more anticipation</p>
-14:12 < jrandom_> hmm?</p>
-14:14 < ughabugha> You missed these:</p>
-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</p>
-14:14 < ughabugha> [00:12 07] <ughabugha> IIP <Janonymous> like, it should work for them without them even knowing its there</p>
-14:14 < jrandom_> janonymous> already implemented.</p>
-14:14 < jrandom_> i2p already transparently balances end to end communication over multiple tunnels</p>
-14:15  * jrandom_ kicks jrandom</p>
-14:15 -!- jrandom [~jrandom@localhost] has quit [Ping timeout]</p>
-14:15 -!- Irssi: Join to #i2p was synced in 231 secs</p>
-14:15 < wilde> participation?</p>
-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</p>
-14:15 < kaji> is iip up?</p>
-14:15 -!- kaji [~booky5@localhost] has quit [Client closed connection]</p>
-14:15 < ughabugha> IIP <Janonymous> And we may want to distribute the load anyway.. and that should all be transparent to the client apps</p>
-14:15 -!- You're now known as jrandom</p>
-14:16 -!- protocol [~iip@localhost] has joined #i2p</p>
-14:16 < ughabugha> IIP <Janonymous> ok</p>
-14:16 < ughabugha> IIP <Janonymous> cool</p>
-14:16 < jrandom> :)</p>
-14:17 < ughabugha> jrandom: Don't use ACTION, it's not relayed ;)</p>
-14:17 < jrandom> hah ok sorry</p>
-14:17  * jrandom says something they cant see</p>
-14:17 < jrandom> ;)</p>
-14:17 < jrandom> ok, anyone else have anything else?</p>
-14:18 < jrandom> i think after the current netDb bugs are fixed we may want to try the i2psnark tests again</p>
-14:20 -!- kaji [~booky5@localhost] has joined #i2p</p>
-14:20 -!- wilde [~anon@localhost] has quit [Ping timeout]</p>
-14:20 < ughabugha> But does the 15-second wait really distribute the load?</p>
-14:20 < ughabugha> That's not how I see it.</p>
-14:20  * protocol says iip is for lusers</p>
-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.</p>
-14:20 < ughabugha> Through all the tunnels, I mean.</p>
-14:20 -!- nick [~Janonym@localhost] has joined #i2p</p>
-14:20 -!- kaji [~booky5@localhost] has quit [Client closed connection]</p>
-14:21 < jrandom> ughabugha: each message is ideally only sent over one tunnel, but each individual message is balanced over all of them</p>
-14:21 < ughabugha> IIP <Janonymous> me and duck ran a test over I2PSnark</p>
-14:21 < ughabugha> IIP <Janonymous> earlier today.</p>
-14:21 < jrandom> ughabugha: if we sent it over all tunnels always, that'd be a significant amount of wasted traffic</p>
-14:21 -!- nick [~Janonym@localhost] has quit [Client closed connection]</p>
-14:21 < ughabugha> IIP <Janonymous> Is everyone happy with the "I2P" name?</p>
-14:21 -!- kaji [~booky5@localhost] has joined #i2p</p>
-14:21 -!- wilde [~anon@localhost] has joined #i2p</p>
-14:22 < jrandom> janonymous> i2p is the name.</p>
-14:22 < jrandom> you can call it betty, but i2p is the name ;)</p>
-14:22 < ughabugha> kaji: Why are you blinking like this?</p>
-14:22 < jrandom> ughabugha: kaji likes messing with us</p>
-14:22 < ughabugha> jrandom: Yeah, I understand that. I guess it works just as I imagine it.</p>
-14:23 < kaji> i dont know</p>
-14:23 < kaji> is iip up?</p>
-14:23 < ughabugha> IIP <Janonymous> cool</p>
-14:23 < ughabugha> IIP <Janonymous> is for me</p>
-14:23 < ughabugha> It is for some people, and it's not for others.</p>
-14:23 < ughabugha> So I'm running a relay.</p>
-14:24 < jrandom> ughabugha++</p>
-14:24 < ughabugha> To connect the networks.</p>
-14:24 < kaji> cool</p>
-14:24 < jrandom> the details of the parallel/serial sending is in net.invisiblenet.i2p.router.message.OutboundClientMessageJob</p>
-14:24 < ughabugha> :)</p>
-14:24 < jrandom> (for anyone who wants to know more details of how it works)</p>
-14:25 < jrandom> ok, anything else people want to bring up?</p>
-14:25 < kaji> so how is i2p dev? :) (Mirc sez 'lag=30 seconds')</p>
-14:25 < jrandom> kaji> we're making progress ;)</p>
-14:26 < jrandom> irssi here has bounced between 80s and 1s lag</p>
-14:26 < jrandom> (two disconnects in the last 90 minutes)</p>
-14:26 < ughabugha> IIP <Janonymous> is there any more ideas on content for the new site?</p>
-14:27 < ughabugha> IIP <kaji> sweet</p>
-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</p>
-14:27 < ughabugha> No disconnects for me for 80 minutes.</p>
-14:27 < jrandom> nice ughabugha </p>
-14:27 < kaji> hmm now the lag is down to a few seconds</p>
-14:27 < jrandom> yeah, it varies kaji</p>
-14:28 < ughabugha> IIP <Janonymous> oh, me and ugha talked on my chat room over eep today :)</p>
-14:28 < jrandom> nice1!</p>
-14:28 < ughabugha> Janonymous: I wouldn't call that talking. ;)</p>
-14:28 < ughabugha> It was more like shouting over a distance of a few kilometers.</p>
-14:28 < jrandom> wait, y'all did voice?</p>
-14:29 < ughabugha> IIP <Janonymous> :) it was one message</p>
-14:29 < ughabugha> :)</p>
-14:29 < ughabugha> Well, I caused all the lag.</p>
-14:30 < ughabugha> Anyway, if somebody has a proposition for discussion, do it now, because I have to go.</p>
-14:30 < jrandom> word, 90m is a good meeting length to end at too...</p>
-14:30 < jrandom> anything else can be taken up on the mailing list</p>
-14:30 < jrandom> (and/or iip/i2p later)</p>
-14:31  * jrandom winds up the *baf*er...</p>
-14:31  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/80.rst b/i2p2www/meetings/80.rst
new file mode 100644
index 00000000..6f85e67f
--- /dev/null
+++ b/i2p2www/meetings/80.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 2, 2004 @ 13:00 PST
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/81.log b/i2p2www/meetings/81.log
index 2a32609b..d7d47e34 100644
--- a/i2p2www/meetings/81.log
+++ b/i2p2www/meetings/81.log
@@ -1,405 +1,399 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 81{% endblock %}
-{% block content %}<h3>Tuesday, Mar 16, 2004 13:00:00 PST</h3>
-<div class="irclog">
-13:12 < jrandom> agenda:</p>
-13:12 < jrandom> 0) hi</p>
-13:12 < jrandom> 1) administravia</p>
-13:13 < jrandom> 2) 0.3 status</p>
-13:13 < jrandom> 3) peer profiling / selection</p>
-13:13 < jrandom> 4) web architecture</p>
-13:13 < jrandom> 5) ???</p>
-13:13 < jrandom> 0) hi</p>
-13:13  * jrandom waves to the gang</p>
-13:14 < deer> * jrandom_ waves from i2p</p>
-13:14 < deer> * wilde hi5s</p>
-13:15 < deer> <ughabugha> Hi!</p>
-13:15 < deer> * duck is reading</p>
-13:15 < deer> <human> yo!</p>
-13:16 < jrandom> w0rd, sorry for the delay getting those status notes up at (http://i2p.net/pipermail/i2p/2004-March/000165.html)</p>
-13:18 < jrandom> 1) administravia</p>
-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</p>
-13:19 < deer> <duck> (amazing!)</p>
-13:19 < jrandom> iip's #i2p, the duck/baffled i2p irc network's  #i2p, and freenode's #i2p</p>
-13:19 < jrandom> :)</p>
-13:19 < deer> <baffled> who's paranoid?</p>
-13:20 < deer> <ughabugha> Ok, done reading the status notes.</p>
-13:20 < deer> <ughabugha> jrandom: What about it?</p>
-13:20 < deer> <ughabugha> Or them?</p>
-13:21 < jrandom> just mentioning it, so people who have trouble with one can use another</p>
-13:21 < deer> <mihi> fine. done with status notes as well</p>
-13:21 < jrandom> also, the drupal box should be back online this weekend (crossing fingers)</p>
-13:22 < deer> <ughabugha> Oh, ok. Is there anything to discuss on 1)?</p>
-13:22 < deer> <ughabugha> Or are we waiting for people to finish reading?</p>
-13:22 < deer> <ughabugha> jrandom: Good. :)</p>
-13:22 < jrandom> nope, unless anyone has any administravia they'd like to bring up?</p>
-13:23 < deer> * mihi wants to set a flag at point 3</p>
-13:23 < jrandom> flag set ;)</p>
-13:23 < deer> * duck at point 2</p>
-13:23 < deer> <duck> err, what index do we use?</p>
-13:24  * jrandom supposes we can move on to agenda item 2) 0.3 status</p>
-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?</p>
-13:25 < deer> <ughabugha> Go on.</p>
-13:26 < deer> <duck> why do the ElGamal/AES+SessionTag decryptions fail too often?</p>
-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</p>
-13:27 < deer> <duck> k</p>
-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</p>
-13:28 < deer> <duck> somehow that sentence made me believe that there was a cause besided the overload/lag</p>
-13:28 < deer> <tro|l> ce zi e azi?</p>
-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</p>
-13:29 < deer> <kaji> wow it works!</p>
-13:29 < jrandom> (and a failed ElG is probably the most CPU intensive thing i2p does)</p>
-13:30 < deer> <jrandom_> heh welcome to i2p #i2p :)</p>
-13:30 < deer> * kaji praises 0.2.5.1</p>
-13:30 < deer> <jrandom_> 0.2.5.1?  sheeit, get thee 0.2.5.4 :)</p>
-13:30 < jrandom> ok, anything else for 0.3 status?</p>
-13:31 < deer> <kaji> ..</p>
-13:31 < deer> <duck> .</p>
-13:31 < deer> <kaji> ping?</p>
-13:31 < jrandom> p0ng</p>
-13:31 < mihi> pung</p>
-13:31 < deer> <mihi_backup> pung2</p>
-13:32 < deer> <Pellinore> prawn</p>
-13:32 < jrandom> ok, moving on to 3) peer profiling / selection</p>
-13:32  * mihi moves the flag to the other number 3 ;)</p>
-13:32 < jrandom> (man, its kind of funny that there isn't any vegetarian seafood substitutes...)</p>
-13:32 < deer> * kaji praises 0.2.5.4.1</p>
-13:32 < deer> <duck> the whole peer profiling thing looks at magic, how do you plan to debug that?</p>
-13:32 < deer> <Pellinore> There is vegetarian crabmeat.</p>
-13:32 < jrandom> ah, true pellinore.</p>
-13:32 < deer> <wilde> jrandom: and veg sushi</p>
-13:33 < jrandom> duck> what part of it looks like magic?</p>
-13:33 < deer> <duck> the whole classification etc</p>
-13:33 < deer> <Pellinore> And I could have sworn that I had seen some chik-type fish fillet substitute, but I could be wrong.</p>
-13:33 < deer> <duck> I mean, how do you know that you are doing optimal things?</p>
-13:33 < jrandom> the peer organizer (which moves profiles into the different groups) is a very simple and seperable component</p>
-13:33 < jrandom> oh, thats a good point.</p>
-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</p>
-13:34 < jrandom> (organizing == runningthe calculators and moving them between groups)</p>
-13:34 < jrandom> profiles also consume only ~3-4KB for a full profile, and a minimal profile takes ~200 bytes</p>
-13:35 < deer> <duck> yeah, but how do you know that you are right with '0.597s reply' for group 1</p>
-13:35 < deer> <duck> and that it shouldnt be 0.603s</p>
-13:35 < jrandom> (so we'll keep a full profile of the best 1000 peers, and minimal of the next 10,000)</p>
-13:35 < jrandom> ah, ok, good question.</p>
-13:36 < jrandom> thats the Rate component</p>
-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</p>
-13:37 < deer> <duck> I did see it using averages</p>
-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</p>
-13:37 < deer> <duck> so if you throw in 100 shitty nodes, you heavily influence the average</p>
-13:37 < jrandom> agreed - there are two different aspects of that that we can tune</p>
-13:38 < jrandom> first, we can make the threshold use the top 10% to determine the "fast" vs "not fast"</p>
-13:38 < jrandom> (or top 90%, whichever)</p>
-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</p>
-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</p>
-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)</p>
-13:40 < deer> <duck> ok, so what prevents another NGRouting disaster from happening?</p>
-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</p>
-13:40 < jrandom> ngrouting tried to do two different things - find particular data, and find available peers.</p>
-13:40 < jrandom> we only need to find available peers</p>
-13:41 < deer> <duck> good</p>
-13:41 < jrandom> (and place our tunnels there)</p>
-13:41 < deer> * duck removes breakpoint</p>
-13:41 < jrandom> :)</p>
-13:41 < mihi> but we have to find tunnels as well.</p>
-13:41 < jrandom> right mihi - the netDb is an important point</p>
-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.</p>
-13:42 < deer> <Pellinore> But I would happily partner up with someone and contribute if I can.</p>
-13:42 < jrandom> awesome pellinore!</p>
-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 :)</p>
-13:43 < deer> <Pellinore> k</p>
-13:43 < jrandom> (i know, i don't expect you to read the code, just mentioning it)</p>
-13:44 < deer> <Pellinore> I'll read it, but it will be about like my dog reading Kierkegaard.</p>
-13:44 < jrandom> hehe</p>
-13:45 < deer> <Pellinore> But I am learning.</p>
-13:45 < deer> <Pellinore> Anyway, please proceed -- I don't mean to bog things down.</p>
-13:45 < jrandom> (volunteering to help isn't bogging things down ;)</p>
-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</p>
-13:46 < jrandom> we still do (fairly) traditional kademlia search/store with all non-failing peers</p>
-13:46 < jrandom> also, within each peer group, we always choose *randomly*</p>
-13:46 < jrandom> (aka we don't always choose the fastest of the fast group, etc)</p>
-13:47 < jrandom> thats for both security and load balancing reasons</p>
-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)</p>
-13:49 < jrandom> ok, do we have anything else for 3) peer profiling / selection?</p>
-13:49 < deer> <duck> .</p>
-13:50 < deer> <ughabugha> Doesn't look like it.</p>
-13:50 < jrandom> ok, moving on to 4) web architecture</p>
-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</p>
-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</p>
-13:53  * mihi has some code flying around on my hd for that httptunnel code. but it's far from being finished</p>
-13:53 < mihi> for me httptunnel == httpclient + some filters</p>
-13:53 < mihi> of course using my naming and streaming api.</p>
-13:54 < mihi> the code atm only allows different "anonymity profiles".</p>
-13:54 < jrandom> any thoughts on human's style of failing over to outproxies like squid/etc?</p>
-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.</p>
-13:54 < jrandom> ah, interesting</p>
-13:55 < mihi> but these dests are not used yet ;)</p>
-13:55 < jrandom> w3rd.  yeah, there *is* the big caveat that having lots of destinations on one router does increase CPU load nontrivially</p>
-13:55 < jrandom> (since any garlic fail will need to fail once per dest before failing completely)</p>
-13:56 < jrandom> there is some magic left that can be used to minimize that though, i think</p>
-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.</p>
-13:56 < jrandom> ughabugha> all things require anonymity :)</p>
-13:57 < jrandom> (and if they can't tell the difference, well, sheeit...)</p>
-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.</p>
-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.</p>
-13:58 < mihi> on that info page one might add a feature to browse the site throufh e.g. squid.</p>
-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)</p>
-13:58 < jrandom> ah, ok mihi</p>
-13:58 < deer> <aum> morning all</p>
-13:58 < jrandom> mihi> so like a much much more advanced "Unable to reach peer" page?</p>
-13:59 < mihi> more like a "anonymity warning" page like in freenet ;)</p>
-13:59 < jrandom> ughabugha> if we cant handle web browsing, how are we going to handle BT/filesharing?</p>
-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?</p>
-14:00 < jrandom> 'mornin aum, just in time for the dev meeting :)</p>
-14:00 < mihi> jrandom: if someone just wants to browse the web anonymously, he</p>
-14:00 < deer> <ughabugha> jrandom: Hmm... Good point. Are we going to at all? ;)</p>
-14:00 < deer> <aum> jrandom: you're not on iip, you're not on irc.duck.i2p ?!?</p>
-14:00 < jrandom> ughabugha> we must.</p>
-14:01 < mihi> might configure httptunnel to so so (httptunnel will still work as a proxy, so it's quite trivial to add that)</p>
-14:01 < mihi> and most likely someone browsing the web "anonymously" will like some content filters, i guess ;)</p>
-14:01 < jrandom> mihi> i think human already did :)</p>
-14:01 < jrandom> agreed mihih</p>
-14:01 < jrandom> /hih/hi/</p>
-14:02 < mihi> when i say httptunnel, i don't mean httpclient ;)</p>
-14:02 < jrandom> ah ok</p>
-14:02 < deer> <jrandom_> i'm here aum ;)</p>
-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</p>
-14:03 < jrandom> agreed</p>
-14:03 < mihi> human only patched the old version, i patched the new version myself</p>
-14:03 < jrandom> we ran into some bugs this afternoon, not sure if human bounced you logs yet</p>
-14:03 < deer> <wilde> another thing for the list: outproxy was taken, but more like i2p2i</p>
-14:04 < mihi> i did not get logs yet from anyone...</p>
-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?</p>
-14:04 < deer> * aum spent part of yesterday looking at p2p apps with a view to running them on i2p</p>
-14:04 < jrandom> wilde> hmm?</p>
-14:04 < jrandom> wikked aum, anything promising?</p>
-14:04 < deer> * aum is presently inclined to favour 'push'-type filesharing, eg konspire2b</p>
-14:05 < jrandom> i2psnark could be modified to use the new i2ptunnel streaming api fairly easily too</p>
-14:05 < deer> <human> mihi: sending the logs (mihi@i2p.net, right?)</p>
-14:06 < mihi> dunno if mihi made a redirect for me</p>
-14:06 < deer> <mihi> s/mihi/jrandom</p>
-14:06 < jrandom> hmm aum, do you think that freenet/insert model really would work most effectively?</p>
-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</p>
-14:06 < jrandom> mihi> want me to set that to for ward to you?</p>
-14:06 < mihi> jrandom: nothing against it ;)</p>
-14:07 < deer> <ughabugha> aum: 'Push'-type? What's that?</p>
-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'</p>
-14:07 < jrandom> mihi> done.</p>
-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</p>
-14:08 < deer> <aum> konspire2b.sf.net</p>
-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?</p>
-14:09 < jrandom> wouldn't a direct swarming system be much more useful / efficient?</p>
-14:09 < deer> <ughabugha> Heh. That sounds promising for I2P.</p>
-14:09 < deer> <aum> jrandom: any examples of direct swarming?</p>
-14:09 < jrandom> wilde> oh, so like the cgiproxy on duck and janonymous's site?</p>
-14:09 < jrandom> aum> bittorrent</p>
-14:10 < deer> <ughabugha> aum: Did you mean http://konspire.sourceforge.net/?</p>
-14:10 < jrandom> where you get the torrent somewhere, and get content blocks directly from peers who have it</p>
-14:10 < deer> <aum> ughabugha: guess so :)</p>
-14:10 < mihi> argl... $me->brother removed the port forward for i2p...</p>
-14:10 < jrandom> d'oh</p>
-14:10 < deer> <aum> jrandom: is anyone currently trying bt/i2p?</p>
-14:11 < deer> <baffled> aum, have you had a close look at mnet?</p>
-14:11 < jrandom> aum> eco made some headway with i2psnark</p>
-14:11 < deer> <aum> i've had a look, but not a close look</p>
-14:11 < jrandom> (though he's mia at the moment)</p>
-14:12 < jrandom> hmm, mnet with eepsite metatrackers and human's i2p/twisted transport might work</p>
-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</p>
-14:12 < jrandom> duck> how recently were those tests?</p>
-14:12 < deer> <duck> last week</p>
-14:12 < jrandom> though i've got no qualms with potentially exploring other bt implementations</p>
-14:12 < jrandom> ah ok</p>
-14:13 < deer> <duck> about mnet, I _think_ that you'd first to fix mnet itself before you could make that working</p>
-14:13 < deer> <duck> so you might as wel fix freenet and use that</p>
-14:13 < jrandom> heh</p>
-14:13 < deer> <aum> fix freenet, ok! right after we bring in world peace ;p</p>
-14:13 < deer> <duck> but ask in #mnet @ freenode</p>
-14:13 < deer> <Pellinore> mnet=?</p>
-14:13 < deer> <Pellinore> Mute?</p>
-14:14 < jrandom> in that sense, perhaps an azureus mod for i2p might work?</p>
-14:14 < deer> <wilde> no, a market based p2p approach</p>
-14:14 < jrandom> pellinore - mnet.sf.net, a distributed data store without anonymity</p>
-14:14 < deer> <baffled> Actually, I'm using mnet quite reliably on about five machines.</p>
-14:14 < jrandom> right, the mojonation followon</p>
-14:14 < deer> <baffled> I can't use freenet reliably on one machine.</p>
-14:14 < deer> <duck> baffled: 0.6 or 0.7?</p>
-14:14 < deer> <duck> (0.7 is with twisted iirc)</p>
-14:16 < deer> <Pellinore> jrandom -- thanks.</p>
-14:16 < deer> <Pellinore> You can't use Freenet reliably on any machine.</p>
-14:17 < deer> <baffled> 0.6.[23].</p>
-14:17 < deer> <Pellinore> That is, among other reasons, why we are here. :)</p>
-14:17 < deer> <aum> i find that entropy works well... eventually!</p>
-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)</p>
-14:18 < jrandom> for file sharing, we should learn from the filesharing crowd what works best</p>
-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</p>
-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.</p>
-14:18 < jrandom> e.g. DC clones, BT, [or what else do those crazy filesharing people use?]</p>
-14:19 < jrandom> heh aum, damn you ;)</p>
-14:19 < deer> <duck> plus there are the things that Newsbyte did identify about entropy...</p>
-14:19 < deer> <aum> it's weaker anonymity, for example?</p>
-14:19 < deer> <baffled> Right but there are instability issues with 0.7.</p>
-14:19 < deer> <baffled> I think this connection has gotten flakey again.</p>
-14:19 < jrandom> and security issues.  i think we can unfortunately pass on using entropy</p>
-14:21 < jrandom> but, erm, we're on discussion point 4, *web* architecture so for the moment lets jump back to that ;)</p>
-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?</p>
-14:22 < jrandom> NNTP would be really interesting - its reliable as fuck and time tested</p>
-14:22 < deer> <duck> linking the servers?</p>
-14:22  * jrandom would love to have an innd running with i2p ;)</p>
-14:23 < deer> <aum> and since i2p does the anonymity, there's no need for nntp to have it</p>
-14:23 < jrandom> right, the innd feed line could point at a local i2ptunnel proxy</p>
-14:23 < deer> <aum> and people with different servers can config the servers to cache their own choice of groups</p>
-14:23 < mihi> depending on how often they peer it would be possible to censor articles by creating message id collisions</p>
-14:23 < deer> <duck> (ever tried configuring innd?)</p>
-14:24 < jrandom> many times duck, but a loooong time ago</p>
-14:24 < deer> <aum> is innd hard to setup?</p>
-14:24 < deer> <duck> oh well, you are god</p>
-14:24 < jrandom> mihi> agreed - thats not a censorship proof distribution medium</p>
-14:24 < jrandom> aum> its a bitch</p>
-14:25 < jrandom> just like squid - its good at what it does, but we likely need something dirt simple (one click, hopefully) to bundle</p>
-14:25  * jrandom drags us back on topic</p>
-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</p>
-14:26  * mihi guesses most users don't know how to set up a proxy in their brwoser...</p>
-14:26 < deer> <aum> sorry, what's the topic?</p>
-14:26 < jrandom> agenda item 4) web architecture ;)</p>
-14:26 < aum> as in, web servers within i2p?</p>
-14:26 < mihi> aum: yep</p>
-14:26 < jrandom> thats a good point mihi - a web system will want the basics (.bat, .sh scripts) for startup/shutdown</p>
-14:27 < jrandom> hmm, doesn't mozilla include a javascript url you can do to set the proxy?</p>
-14:27 < jrandom> e.g. could we have a config page on httptunnel to click "on"/"off"?</p>
-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</p>
-14:28 < aum> what's the problem with the current eepproxy setup?</p>
-14:29 < jrandom> e.g. filtering, inbound proxies (eeproxies), outbound servers (normal i2ptunnel server), outbound proxies (outproxies ala squid or tor-www)</p>
-14:29 < mihi> aum: it requires quite some skill both to provide and to request eepsites</p>
-14:29 < jrandom> also, the existing outproxy system sucks.</p>
-14:29 < jrandom> its wholely unscalable</p>
-14:29 < jrandom> we need something to allow/force distributing the outbound web request load across multiple outproxies</p>
-14:30 < mihi> how can users get these outproxies. config file (like in hosts.txt?)</p>
-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"</p>
-14:31 < jrandom> thats one option mihhi</p>
-14:31 < mihi> jrandom: hehe</p>
-14:31 < jrandom> s/hh/h/</p>
-14:31 < aum> but doesn't eepproxy make 'direct' http connection to the requested server, ie as 'direct' as i2p connections are?</p>
-14:31 < deer> <wilde> . /castvote DHT ala Freenet</p>
-14:31 < mihi> aum: the problem are "normal" web urls.</p>
-14:31 < jrandom> ./castvote 3 developers x 1 month x 12h / day</p>
-14:32 < deer> * human added httptunnel support to the TunnelManager, btw</p>
-14:32 < deer> <human> s/httptunnel/httpclient/</p>
-14:32 < deer> <aum> what's that?</p>
-14:32 < deer> <aum> oh, http client support?</p>
-14:32 < deer> <human> aum: yes</p>
-14:32 < jrandom> right, we need to find a way to let people browse slashdot.org via i2p</p>
-14:32 < deer> <aum> so tunnelmgr now talks http?</p>
-14:32 < jrandom> nice1 human!</p>
-14:32 < jrandom> aum> remember the squid proxy?</p>
-14:33 < deer> <aum> yep</p>
-14:33 < deer> <wilde> jrandom: so 4 man-months roughly for a DHT?</p>
-14:33 < deer> <human> aum: yup: openhttpclient <port> [<outbound WWW proxy>]</p>
-14:33 < jrandom> wilde> i think thats reasonable, yes.</p>
-14:34 < deer> <aum> human: have you written it up anywhere?</p>
-14:35 < jrandom> aum> all it does is say "if !eepsite { send through $outboundWWWproxy } else {send to eepsite}"</p>
-14:35 < deer> <human> aum: i was going to commit, then i got stuck with a StreamingI2PTunnelServer bug...</p>
-14:36 < jrandom> a good short term solution would be a "outproxies.txt", ala hosts.txt</p>
-14:36 < deer> <aum> human: and what exactly does 'openhttpclient <port> [<outbound WWW proxy>]' do?</p>
-14:36 < jrandom> though we should start thinking about medium and long term solutions</p>
-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</p>
-14:38 < deer> <Pellinore> Now that's interesting.</p>
-14:38 < deer> <aum> human: ahh, nice, so you split off a thread within tunnelmgr?</p>
-14:38 < deer> <human> human: i.e. you can use it to browse both eepsite and the normal web</p>
-14:38 < deer> <human> human: yes</p>
-14:38 < deer> <human> s/human/aum/ :-)</p>
-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</p>
-14:39 < deer> <aum> human: so you talk python *and* java? is that damaging your brain?</p>
-14:39 < deer> <human> aum: i did it to avoid launching yet another JVM for the EepProxy</p>
-14:40 < jrandom> (well, the code is implement in i2ptunnel's httpclient, human just recently exposed it through tunnelmanager as well)</p>
-14:40 < deer> <aum> yes, always good to keep the jvm instances down to a minimum</p>
-14:40 < jrandom> ((and imho httpclient is exactly where it should go ;)</p>
-14:40 < jrandom> (((until mihi's NextGen httpclient [httptunnel] is out)))</p>
-14:41 < deer> <aum> is httpclient in cvs, such that it'll build for me as part of i2p update/build?</p>
-14:41 < jrandom> yes, eepProxy uses httpclient</p>
-14:42 < deer> <aum> *man this is so schizophrenic - i've got 3 xchat sessions open (irc.duck.i2p,iip,freenode)) </p>
-14:42 < jrandom> :)</p>
-14:42 < deer> <aum> wicked latency on irc.duck.i2p</p>
-14:42 < jrandom> ok, so no closure on the web architecture today, obviously, but worthwhile discussion</p>
-14:43 < jrandom> yeah aum, 15s or so for me</p>
-14:43 < jrandom> anything else on the web architecture for now, or should we move on to the 5) ??? open discussion section?</p>
-14:43 < deer> * human is thinking about an I2PSocksTunnel</p>
-14:44 < jrandom> yikes, now that'd be cool</p>
-14:44 < deer> <human> (well, maybe it belongs to 5)</p>
-14:44 < deer> <aum> socks? is there a way to 'shim' non-socks-enabled clients through to a socks interface?</p>
-14:44 < deer> <human> aum: apt-get install tsocks :-)</p>
-14:45 < aum> web discussion - one last thing - what about possibly forking /patching an existing web client</p>
-14:45 < mihi> aum: sockscap for windwos</p>
-14:45 < jrandom> aum> scary.  very powerful, but scary.</p>
-14:45 < jrandom> [i'd hate to have to maintain that]</p>
-14:45 < aum> even for now, a brain-dead browser like dillo</p>
-14:46 < jrandom> [[though it could be made 'uber secure', etc.  but still, very, very scary]]</p>
-14:46 < aum> or better, the browser control in wxwindows, it's multiplatform</p>
-14:46  * jrandom reminices about the orignial flinks, when it had a built in freesite browser</p>
-14:47 < aum> but then again, n00bs will whinge if they can't surf their usual m$-specific-javascript-infested sites</p>
-14:47 < jrandom> right aum, and so will hackers if it doesnt support the latest standards compliant code</p>
-14:47 < aum> hey, we should ask Microsoft for the source to IE6, then patch it ;p</p>
-14:47 < jrandom> building a browser == good way to waste thousands of man-hours</p>
-14:47 < jrandom> heh</p>
-14:47 < deer> * human is quite happy using privoxy</p>
-14:48 < aum> maybe they might toos in ie6 source as part of the European punitive settlement</p>
-14:48 < deer> <human> (http://www.privoxy.org/)</p>
-14:48 < aum> s/toos/toss/</p>
-14:48 < jrandom> human> how would that fly for both sides of the proxy?</p>
-14:48 < jrandom> e.g. we'll want the content filtered locally, not at the outbound endpoint</p>
-14:49 < deer> <human> jrandom: users could be encouraged to install it</p>
-14:49 < jrandom> (but the outbound endpoint will want to filter some content to avoid abuse, etc)</p>
-14:49 < deer> <human> jrandom: or it may be part of the default I2P installation</p>
-14:49 < aum> what if a DWP (distrib web proxy) was using a DHT for its cache?</p>
-14:49 < jrandom> encourage == only geeks.  bundle :)</p>
-14:49 < jrandom> that'd be Good aum</p>
-14:49 < deer> <human> jrandom: eheheh, agreed :-)</p>
-14:49 < deer> <human> jrandom: privoxy also runs on windogs, btw</p>
-14:50 < jrandom> word.  yeah, we need some sort of content filtering - privoxy, muffin, whatever.</p>
-14:50 < deer> <wilde> long meeting...</p>
-14:50  * jrandom takes the hint..</p>
-14:51 < deer> <Pellinore> wilde: Much to be said.</p>
-14:51 < jrandom> anyone else have anything they want to bring up?  we always have the mailing list for further things</p>
-14:51 < deer> <Pellinore> And much to be done of course.</p>
-14:51 < deer> <Pellinore> I have a couple of small questions.</p>
-14:51 < aum> could we fork privoxy and 1) make it work over i2p, 2) make it use DHT for caching?</p>
-14:51 < deer> <Pellinore> But they are as easily taken up privately.</p>
-14:51 < jrandom> pellinore> whats up?</p>
-14:51 < deer> <Pellinore> Nada, sorry I said anything.</p>
-14:51 < jrandom> aum> most likely we wouldnt need to fork</p>
-14:52 < deer> <Pellinore> I'll talk to you about it privately, or duck, at another time.</p>
-14:52 < deer> <Pellinore> Not really dev-specific stuff.</p>
-14:52 < deer> <duck> 10+16+7=33 manhours wasted on this one-hour overtime :)</p>
-14:52 < jrandom> but building a DHT is a lot of effort.  wholely incredibly worthwhile</p>
-14:52 -!- Irssi: #i2p: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal]</p>
-14:52  * aum goes again to visit infoanarchy.org wiki pages on DHTs</p>
-14:52 < jrandom> there are 16 people on iip?</p>
-14:53 < deer> <human> aum: no need to fork, just: web browser <-> privoxy <-> httpclient <-> i2p <-> outbound proxy <-> www.pr0n.com</p>
-14:53 < deer> <wilde> a generic DHT that would work outside I2P too, and that allows other binding than http</p>
-14:53 < jrandom> aum> check out the link duck added to the i2p wiki, listing various ones</p>
-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)</p>
-14:54 < deer> <duck> (http://www.bamboo-dht.org/)</p>
-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</p>
-14:54 < jrandom> hrm duck, what happened to that list of 'em?</p>
-14:54 < deer> <duck> aum: easier to test</p>
-14:55 < deer> <duck> jrandom: some commie did remove it I guess</p>
-14:55 < jrandom> heh</p>
-14:56 < jrandom> google++ : http://www.etse.urv.es/~cpairot/dhts.html</p>
-14:56 < jrandom> (not the same page, but interesting)</p>
-14:56 < jrandom> oh, here's the page - http://himalia.it.jyu.fi/ffdoc/storm/pegboard/available_overlays--hemppah/peg.gen.html</p>
-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</p>
-14:58 < jrandom> (SSK style not being strictly necessary, but damn it would be really useful)</p>
-14:58 < jrandom> but, anyway</p>
-14:58 < jrandom> anyone got anything else they want to bring up?</p>
-14:59 < deer> <duck> tomorrow is St. Patrick's Day</p>
-14:59 < deer> <wilde> topic 5) ?</p>
-14:59 < deer> <duck> so all drink irish beer</p>
-14:59 < jrandom> good point</p>
-14:59 < deer> <Pellinore> TOmorrow is both the anniversary of my current relationship, and of my second marriage.</p>
-14:59  * jrandom takes note to avoid irish pubs tomorrow</p>
-15:00 < jrandom> oh, congrats pellinore :)</p>
-15:00 < jrandom> wilde> we're on 5) ???</p>
-15:01 < jrandom> (and about to be on 6) [baf])</p>
-15:01  * jrandom will be coming to iip momentarily [if i can]</p>
-15:01  * jrandom winds up</p>
-15:01  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/81.rst b/i2p2www/meetings/81.rst
new file mode 100644
index 00000000..ab72bea4
--- /dev/null
+++ b/i2p2www/meetings/81.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 16, 2004 @ 13:00 PST
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/82.log b/i2p2www/meetings/82.log
index 2646ab08..8e863108 100644
--- a/i2p2www/meetings/82.log
+++ b/i2p2www/meetings/82.log
@@ -1,470 +1,464 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 82{% endblock %}
-{% block content %}<h3>Tuesday, Mar 23, 2004 13:00:00 PST</h3>
-<div class="irclog">
-[22:01:22] <jrand0m> agenda:</p>
-[22:01:22] <jrand0m> 0) Hi</p>
-[22:01:22] <jrand0m> 1) Network status</p>
-[22:01:28] <jrand0m> 2) 0.3.1 plan</p>
-[22:01:28] <jrand0m> 3) Web architecture</p>
-[22:01:28] <jrand0m> 4) Administravia</p>
-[22:01:34] <jrand0m> 5) ???</p>
-[22:01:38] <jrand0m> 0) hi</p>
-[22:01:39] <no_dammagE> of yourse</p>
-[22:01:43] <ughabugha> Oh, cool, the meeting. :)</p>
-[22:01:51] <jrand0m> hi, welcome to the weekly dev meeting, number $something</p>
-[22:01:56] <ughabugha> Hi.</p>
-[22:02:02] <jrand0m> weekly status notes up at http://i2p.net/pipermail/i2p/2004-March/000180.html</p>
-[22:02:09] * mihi has joined #i2p</p>
-[22:02:13] <fidd> howdy</p>
-[22:02:32] <jrand0m> we'll see if we can avoid a 2 hour session today ;)</p>
-[22:02:39] <jrand0m> ok, jumping to 1) network status</p>
-[22:02:43] <Masterboy> :P</p>
-[22:02:56] <jrand0m> we got 0.3.0 out on sunday, and its generally functional</p>
-[22:03:12] <Masterboy> yes it is:)</p>
-[22:03:23] <ox> * jrandom waves from i2p#i2p to prove it ;)</p>
-[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</p>
-[22:04:21] * ion has joined #i2p</p>
-[22:04:22] * ughabugha is reading the status notes.</p>
-[22:04:27] * mrflibble has quit IRC (r eboot time)</p>
-[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)</p>
-[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</p>
-[22:05:22] <jrand0m> (basically it visualizes the result of the 0.3 peer profiling and selection process)</p>
-[22:05:50] <ox> <duck> nice!</p>
-[22:06:22] <jrand0m> yeah, its nice to see the visual feedback on the algorithms, rather than manually going through the networkDb</p>
-[22:06:37] <ox> <Masterboy> there's a need of cpu usage decreasing..</p>
-[22:06:38] <fidd> :)</p>
-[22:06:48] * jrand0m gives the eepSiteAppOfTheWeek award to duck for dot.png</p>
-[22:06:54] <ughabugha> Yeah, I wonder what would we be doing without duck?</p>
-[22:07:08] <ox> <duck> maybe we can make an audio version too</p>
-[22:07:17] <fidd> haha</p>
-[22:07:20] <jrand0m> :)</p>
-[22:07:22] <human> heheh</p>
-[22:07:34] <fidd> or a smell-one</p>
-[22:07:47] <ughabugha> Yeah, and stream it over jnon's icecast every hour.</p>
-[22:07:51] <no_dammagE> how do I understand the speed column in #transport?</p>
-[22:08:00] <no_dammagE> I mean peer profiles</p>
-[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.</p>
-[22:08:50] <no_dammagE> ok :)</p>
-[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</p>
-[22:10:07] <jrand0m> the network has also grown to a steady 18-22 routers, which is a good size for the moment</p>
-[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</p>
-[22:10:36] <KyroxX> re</p>
-[22:10:45] <jrand0m> wb KyroxX</p>
-[22:11:03] <jrand0m> ok, that leads us into 2) 0.3.1 plan</p>
-[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)</p>
-[22:11:29] <jrand0m> cool no_dammagE, thats fine</p>
-[22:11:33] * fR has quit IRC (Ping timeout)</p>
-[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</p>
-[22:12:19] <jrand0m> roadmap hasn't yet been updated, but things are pretty much the same</p>
-[22:12:45] * fR has joined #i2p</p>
-[22:13:17] <ughabugha> Are you going to release 0.3.0.1?</p>
-[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</p>
-[22:13:36] * KyroxX has quit IRC (Verlassend)</p>
-[22:13:47] <jrand0m> perhaps, though currently the roadmap lists 0.3.1 as next week</p>
-[22:13:54] <jrand0m> sunday, even.</p>
-[22:14:01] <ox> <baffled> I knew you was in collusion with somebody.</p>
-[22:14:02] <jrand0m> so i'm not sure</p>
-[22:14:03] * Rom|Away|3h has quit IRC (Ping timeout)</p>
-[22:14:04] <Masterboy> how can i limit the cpu usageof my router? why not make : "low" - "normal" - "high" - so you could choose?</p>
-[22:14:10] <jrand0m> heh baff</p>
-[22:14:11] <no_dammagE> why is that critical?:</p>
-[22:14:11] <no_dammagE> 21:55:36.249 CRIT  [I2CP Reader ] et.invisiblenet.i2p.util.Clock: Updating clock</p>
-[22:14:12] <no_dammagE>  offset to 105791ms from 0ms</p>
-[22:14:16] * Romster has joined #i2p</p>
-[22:14:24] * jar has quit IRC (Ping timeout)</p>
-[22:14:38] <jrand0m> Masterboy> the code to work along those lines is planned for the 1.0rc1 release</p>
-[22:14:43] <jrand0m> (router throttling)</p>
-[22:14:48] * KyroxX has joined #i2p</p>
-[22:14:50] <jrand0m> we've got some basics, but its not ready yet.</p>
-[22:15:08] <KyroxX> re</p>
-[22:15:13] <jrand0m> no_dammagE> because it should only occur at most once - if you see it happening a lot, its an issue</p>
-[22:15:14] <Masterboy> oki</p>
-[22:15:21] <jrand0m> (a critical issue)</p>
-[22:15:48] <jrand0m> any other questions / concerns on the 0.3.1 release?</p>
-[22:15:55] <mihi> then it should be debug the first time and then crit...</p>
-[22:16:06] <jrand0m> you're right</p>
-[22:16:09] <KyroxX> whats the topic?</p>
-[22:16:17] <ughabugha> jrand0m: Err.. How can this occur on I2P? Closing Link: [unknown@192.168.0.2] (Ping timeout)</p>
-[22:16:31] <jrand0m> KyroxX> the weekly dev meeting, item 2) 2) 0.3.1 plan</p>
-[22:16:35] <ughabugha> Ah, never mind.</p>
-[22:16:40] <jrand0m> ughabugha> ircd patch</p>
-[22:16:49] <KyroxX> ah</p>
-[22:17:02] <ox> <duck> my ircd is running on nsa.localdomain</p>
-[22:17:06] <jrand0m> hmm</p>
-[22:17:08] <ox> <duck> which has 192.168.0.2 as IP</p>
-[22:17:12] <jrand0m> ah</p>
-[22:17:30] * Romster has quit IRC (Ping timeout)</p>
-[22:17:32] <jrand0m> ok, moving on to 3) Web architecture</p>
-[22:17:49] * ion has quit IRC (Ping timeout)</p>
-[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</p>
-[22:18:02] <mihi> how can i make an account on drupal.i2p.net?</p>
-[22:18:15] * mihi is too stupid for that...</p>
-[22:18:16] <jrand0m> wilde> can you add one for mihi?</p>
-[22:18:31] <jrand0m> (there's no way to register normally)</p>
-[22:18:35] <mihi> jrand0m: you could simply say no, then i know i can stop trying ;)</p>
-[22:18:42] <jrand0m> if wilde isn't around, i'll add one for you momentarily :)</p>
-[22:18:51] * Romster has joined #i2p</p>
-[22:19:04] * Romster is now known as Rom|Away|3h</p>
-[22:19:18] <fidd> i'd like one too if its ok :)</p>
-[22:21:05] <ox> <jmand> /ping jmand</p>
-[22:21:12] <jrand0m> ok, back to the web arch stuff</p>
-[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</p>
-[22:22:34] * ion has joined #i2p</p>
-[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</p>
-[22:23:03] <ughabugha> jrand0m: Are you talking about the separation of Squid and I2P web?</p>
-[22:23:11] <ughabugha> Or something deeper?</p>
-[22:23:24] <duck> the 'HTTPTunnel vs. {privoxy,muffin} + HTTPClient' thread</p>
-[22:23:30] <duck> (http://i2p.dnsalias.net/pipermail/i2p/2004-March/)</p>
-[22:23:48] <jrand0m> the seperation of squid and eepsites, as well as the seperation of browser proxies vs. (essentially) cgis</p>
-[22:23:49] <ughabugha> Right.</p>
-[22:24:00] <jrand0m> and, of course, the filters</p>
-[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</p>
-[22:24:56] * jar has joined #i2p</p>
-[22:25:04] <duck> I tend to agree with human's latest post</p>
-[22:25:13] <jrand0m> plus, with mihi's new streaming I2PTunnel api, its fairly easy to build off</p>
-[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</p>
-[22:26:48] * lucky has joined #i2p</p>
-[22:27:45] * jar has quit IRC (EOF From client)</p>
-[22:27:52] <jrand0m> mihi> any thoughts?</p>
-[22:28:26] <jrand0m> ok or anyone else?  :)</p>
-[22:28:47] <duck> http://i2p.i2p/ looks ugly to me</p>
-[22:28:55] <duck> but even that could be survived</p>
-[22:28:59] <jrand0m> i2p.i2p?</p>
-[22:29:05] <human> ?</p>
-[22:29:27] * ion has quit IRC (Ping timeout)</p>
-[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</p>
-[22:30:01] * fR has quit IRC (EOF From client)</p>
-[22:30:20] * human didn't get the latest proposal :-)</p>
-[22:30:27] <duck> I think I did see i2p.i2p mentioned somewhere as replacement for the current http://i2p/keybla</p>
-[22:30:35] <jrand0m> yours was the latest human</p>
-[22:30:54] <jrand0m> oh, right, yeah on irc last night i think jnano was discussing it</p>
-[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"</p>
-[22:31:03] <mihi> duck: you have good eyes. i did this to prevent netbios lookups in Opera.</p>
-[22:31:21] <duck> ah yeah "code/apps/i2ptunnel/java/src/net/invisiblenet/i2p/httptunnel/handler/RootHandler.java"</p>
-[22:31:21] <jrand0m> ah sorry human, i meant that with regards to what mihi just said :)</p>
-[22:31:23] * lucky has quit IRC (Ping timeout)</p>
-[22:31:49] <duck> it is a shame that some browsers need such workarounds</p>
-[22:31:55] <human> wew</p>
-[22:32:15] <jrand0m> human mentioned something about socks4 not requiring that?</p>
-[22:32:15] * KyroxX is now known as wbk</p>
-[22:32:23] <duck> socks4a</p>
-[22:32:29] <jrand0m> ah ok</p>
-[22:32:39] <duck> (socks4 does DNS)</p>
-[22:32:49] <jrand0m> do all browsers support socks4a?</p>
-[22:32:59] <human> jrand0m: socks4 is Evil(TM), but socks4a and socks5 delegate name resolution to the server</p>
-[22:33:00] <duck> s/socks4 does DNS/with socks4 the client does DNS/</p>
-[22:33:06] <mihi> some browsers don't even support socks proxies...</p>
-[22:33:08] <human> jrand0m: yes, AFAIK</p>
-[22:33:27] <jrand0m> right, plus the kiosk issue mihi, certainly</p>
-[22:33:52] <duck> it could be an alternative</p>
-[22:34:04] <duck> httpclient + socksclient + etc</p>
-[22:34:29] <human> jrand0m, mihi: programs that don's support socks could be tsocks'ed</p>
-[22:34:53] <jrand0m> human> unless its a kiosk, where people can't run apps</p>
-[22:35:00] <jrand0m> (or change settings, etc)</p>
-[22:35:19] <human> jrand0m: yes, of course socks tunnels aren't suited for these tasks</p>
-[22:35:31] <duck> (human: though then they'd still call gethostbyname)</p>
-[22:35:39] <jrand0m> would they duck?</p>
-[22:35:55] <human> duck: no, tsocks even inhibits them and forwards them to the proxy server</p>
-[22:36:16] <human> duck: (dunno what happens in the windows world, though)</p>
-[22:36:30] <jrand0m> they BSOD</p>
-[22:36:32] <jrand0m> er..</p>
-[22:36:57] <duck> (not according to /usr/share/doc/tor-0.0.2_pre27/CLIENTS.gz)</p>
-[22:36:57] <human> heheheh</p>
-[22:37:07] <jrand0m> heh duck</p>
-[22:37:18] <human> socks tunnels, however, will not replace www proxies :-)</p>
-[22:37:24] <duck> (( </tortechnotalk> ))</p>
-[22:38:25] <jrand0m> mihi> whats your take on the highest priority use case for httptunnel?  if there's something we can help with?</p>
-[22:38:31] <mihi> http://home.arcor.de/mschierlm/test/nosocks.png (which browser is that?)</p>
-[22:38:31] <human> it's just an add-on to do some neat stuff with tunnelling, chaining etc.</p>
-[22:38:31] <wbk> I2P is the ircd of iip right?</p>
-[22:38:31] <duck> anyway, all solutions need a clientside filter</p>
-[22:38:47] <human> duck: yes, according to man 8 tsocks :-)</p>
-[22:39:14] <jrand0m> dunno mihi, opera?</p>
-[22:39:19] * fR has joined #i2p</p>
-[22:39:19] <duck> wbk: no private msg</p>
-[22:39:19] <jrand0m> wbk> no</p>
-[22:39:30] <mihi_backup> jrand0m: make it work perfectly with post requests && make it do everything httpclient does</p>
-[22:39:45] <jrand0m> word</p>
-[22:40:08] <ughabugha> mihi: That's Opera.</p>
-[22:40:14] <human> mihi: dunno, but as i wrote above: socks tunnels, however, will not replace www proxies :-)</p>
-[22:40:18] <ughabugha> If you ment that as a question. :)</p>
-[22:41:13] <jrand0m> ok, cool, anyone have anything else to bring up for web stuff, or are we ready for 4) Administravia?</p>
-[22:42:23] <jrand0m> ok, just some notes -</p>
-[22:42:24] * Rom|Away|3h is now known as Rom|Away|4h</p>
-[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 :)</p>
-[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]</p>
-[22:44:26] <duck> I was looking at the license policy...</p>
-[22:44:35] <duck> AFAIK Cryptix == BSD</p>
-[22:44:43] <jrand0m> right</p>
-[22:44:52] <duck> (but with Cryptix team as copyrightor instead of regents of massachusets or something)</p>
-[22:44:52] <jrand0m> but, strictly, its the Cryptix license ;)</p>
-[22:45:05] <duck> what is MIT?</p>
-[22:45:13] <jrand0m> mit is == bsd 2 clause</p>
-[22:45:16] <jrand0m> == x</p>
-[22:45:19] <duck> what code is MIT I mean</p>
-[22:45:25] <jrand0m> nothing</p>
-[22:45:29] <human> == x < 4.4.0</p>
-[22:45:36] <jrand0m> i just list it as "if you want to use MIT, great"</p>
-[22:45:42] <jrand0m> right human :/</p>
-[22:45:49] <duck> the amount of licenses is already quite a few</p>
-[22:45:56] <duck> I was wondering if that could be restricted</p>
-[22:46:07] <duck> for example changing the GPL code into BSD or even pubdomain</p>
-[22:46:31] <duck> was wondering what the author(s) of that part(s) did think about that</p>
-[22:46:32] <ox> <no_dammagE> so, chatroom, ill go sleep now. Good code @ Devteam, good time of day to all others. Till tomorrow.</p>
-[22:46:40] <duck> bye no_dammagE </p>
-[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</p>
-[22:46:51] <jrand0m> later no_dammagE</p>
-[22:46:55] <no_dammagE> cu</p>
-[22:46:58] * no_dammagE has quit IRC</p>
-[22:47:19] * jar_backup has joined #i2p</p>
-[22:47:50] <jrand0m> but, of course, GPL is fine, t'is mihi's right :)</p>
-[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</p>
-[22:48:07] <ughabugha> Well, whatever the license is, it should be GPL-compatible.</p>
-[22:48:36] <ughabugha> (Ie, it shouldn't be more restrictive than GPL)</p>
-[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)</p>
-[22:49:05] <jrand0m> mihi> the streaming and naming lib are funcional without dependency upon i2ptunnel itself, right?</p>
-[22:49:14] <ughabugha> Yeah, reference implementation shouldn't be GPL.</p>
-[22:49:25] <mihi> they should be. if not, it's a bug.</p>
-[22:49:30] <jrand0m> BSD 2 clause on those would be fantastic</p>
-[22:49:40] <human> yup!</p>
-[22:49:45] <mihi> you can have naming lib public domain if you include it into core ;)</p>
-[22:50:02] * ion has joined #i2p</p>
-[22:50:03] <jrand0m> absolutely, I'd love to include them in the core sdk</p>
-[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)</p>
-[22:51:09] <jrand0m> well, the sdk impl itself makes some nontrivial design assumptions - its just a ref impl</p>
-[22:51:22] <jrand0m> i'd love if people could take i2p.jar and write a streaming app</p>
-[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)</p>
-[22:51:28] * Masterboy has quit IRC (Ping timeout)</p>
-[22:51:59] <duck> human: that brings up the "have to hire a lawyer before I can use it"-problem</p>
-[22:52:01] <jrand0m> (perhaps we can split the current i2ptunnel into i2ptunnel and i2pstreaming, if you'd prefer?)</p>
-[22:52:32] <mihi> jrand0m: that would be okay for me. just change the ant task to build 2 jars ;)</p>
-[22:52:35] <human> duck: i suggest to add the exception just to avoid it</p>
-[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</p>
-[22:53:30] <mihi> and better make i2pministreaming instead of i2pstreaming</p>
-[22:53:41] <duck> mihistreaming :)</p>
-[22:53:48] <mihi> (note the n in mi4ni)</p>
-[22:54:02] <mihi> duck: that was exactly what i thought ;)</p>
-[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?</p>
-[22:54:04] <jrand0m> hehe</p>
-[22:54:10] <jrand0m> i2pmihistreaming is good too :)</p>
-[22:55:25] <duck> ok</p>
-[22:55:40] <duck> next week I'll try to convince you all to move totally to publicdomain</p>
-[22:55:45] <duck> but this is enough for now :)</p>
-[22:55:48] <jrand0m> :)</p>
-[22:55:50] <human> hehe</p>
-[22:56:06] <jrand0m> mihi*=5</p>
-[22:56:14] <mihi> jrandom**=5;</p>
-[22:56:21] <duck> wbk did just offer to help with the webdesign</p>
-[22:56:36] <jrand0m> oh awesome duck</p>
-[22:56:45] <jrand0m> well, briefly before we jump to 5)</p>
-[22:56:58] <jrand0m> do any devs have any qualms with the /policy/ in http://drupal.i2p.net/node/view/85?</p>
-[22:57:05] <duck> so I did do a bureaucratic team-table lookup and delegate him to wilde</p>
-[22:57:25] <human> before jumping... what about the GPL + exception suggestion?</p>
-[22:57:29] <jrand0m> aka "implicitly under $primaryLicense" or "explicitly under $alternate"?</p>
-[22:57:47] <jrand0m> duck++ :)</p>
-[22:58:02] <mihi> human: I'm adding it atm</p>
-[22:58:07] * human agrees with jrand0m's policy</p>
-[22:58:25] <duck> what about copyright owner</p>
-[22:58:28] <human> mihi: ok, thanks</p>
-[22:58:30] * duck did see human adding some new files as GPL</p>
-[22:58:36] <duck> and putting mihi's name on that</p>
-[22:58:45] <ughabugha> Err... I don't think drupal likes passwords which are 32 characters long.</p>
-[22:58:51] <human> duck: i just cut'n'pasted existing files</p>
-[22:59:18] <duck> ok, but what if we have 50 ppl working on it and each putting their own name on the copyrights</p>
-[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</p>
-[22:59:22] <human> duck: (well, even if i'm forgetting to put copyrights into files...)</p>
-[22:59:25] <duck> then you cant switch license at a later point</p>
-[22:59:29] <jrand0m> thats fine duck, in my opinion</p>
-[22:59:53] <jrand0m> e.g. thecrypto should be the copyright owner of his encryption and SHA routines</p>
-[23:00:03] <human> (i was still observing jrand0m's policy to stick with module licenses, btw)</p>
-[23:00:05] <jrand0m> though since he's released it under BSD 2 clause, we will use it</p>
-[23:00:38] <jrand0m> oh, maybe i'm missing the point - you want to make sure everyone puts their own name on it?</p>
-[23:00:44] <duck> no</p>
-[23:00:49] * jrand0m assigns copyright to richard nixon</p>
-[23:00:56] <human> heheh</p>
-[23:01:34] <human> btw: in my country, "public domain" is just another kind of copyright</p>
-[23:01:46] <jrand0m> hmm.  i2p doesn't have any legal entity to receive copyright (and *never* will)</p>
-[23:02:02] <human> i.e. you (the author) distribute your works without any restrictions</p>
-[23:02:18] <jrand0m> right, a lot of countries have fucked up IP laws</p>
-[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</p>
-[23:03:13] <jrand0m> that i think is a good idea</p>
-[23:03:47] <human> jrand0m: (it's still happening, of course, but i think it should be a requirement :-)</p>
-[23:03:55] <jrand0m> thats why i included the "jrandom wrote this in $year and releases it into the public domain" ;)</p>
-[23:04:08] <human> jrand0m: yeah :-)</p>
-[23:04:27] <jrand0m> so i'm missing ducks point</p>
-[23:04:37] <fidd> and that thing abouth eating children</p>
-[23:04:37] <duck> I lost it too</p>
-[23:04:43] <jrand0m> :)</p>
-[23:04:44] <human> heheh</p>
-[23:04:47] <duck> lets forget it</p>
-[23:04:58] * lucky has joined #i2p</p>
-[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</p>
-[23:05:22] <jrand0m> (even if they dont copyright it?)</p>
-[23:05:24] <lucky> hi</p>
-[23:05:25] <lucky> :D</p>
-[23:05:39] <jrand0m> s/suggestion/<i>suggestion</i>/</p>
-[23:05:42] <jrand0m> hi lucky</p>
-[23:05:50] <jrand0m> [damn i borked my regexp]</p>
-[23:05:57] <duck> want me to PGP sign a statement?</p>
-[23:06:09] <jrand0m> i'm going to, yes</p>
-[23:06:30] <jrand0m> once the policy is ready and revised, i'll be contacting all prior committers for PGP/GPG auth </p>
-[23:06:33] <human> jrand0m: yes (in my country it's impossible to refuse copyright, it's seen as an inalienable author's right)</p>
-[23:06:52] <duck> yes, your country is fucked</p>
-[23:06:53] <duck> NEXT</p>
-[23:06:56] <duck> (oops)</p>
-[23:06:58] <jrand0m> :)</p>
-[23:07:19] <fidd> human, what country?</p>
-[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</p>
-[23:07:47] <human> fidd: somewhere near Europe :-)</p>
-[23:07:54] <fidd> heh, ok</p>
-[23:07:59] <lucky> human: you can later say you don't want the copyright</p>
-[23:08:03] <lucky> and put it in the public domain.</p>
-[23:08:19] <jrand0m> human> with the "implicit release under $primaryLicense", that should address the issue though, right?</p>
-[23:08:24] <duck> human means that that doesnt mean anything in $fuckedcountry</p>
-[23:08:42] <jrand0m> human> since that implicitly means commit == release as $primaryLicense</p>
-[23:08:50] <human> duck: yup, exactly</p>
-[23:09:07] <jrand0m> (so no comment == implicit license by $author, per `cvs log`)</p>
-[23:09:28] <jrand0m> (ah, legalese in code ;)</p>
-[23:09:36] <human> jrand0m: well, i'm not a lawyer... but i think it should work</p>
-[23:09:43] * kaji has joined #i2p</p>
-[23:09:48] <ox> * wilde agrees with the last proposal</p>
-[23:09:57] <jrand0m> w3rd.</p>
-[23:10:05] <jrand0m> ok, i'll see if i can get the eff to review</p>
-[23:10:19] <jrand0m> moving on to 5) ???</p>
-[23:10:21] <human> jrand0m: maybe it's better to have some sort of agreement when ppl are given CVS access</p>
-[23:10:46] <ox> <wilde> when will we see, net.i2p.legal.LicenseManager?</p>
-[23:10:47] <jrand0m> agreed human> explicit agreement with $policy will be a prerequisit for getting commit privs</p>
-[23:10:50] <jrand0m> heh</p>
-[23:10:52] <human> jrand0m: (for example, GPG signing the your policy, and hosting it on the I2P site?)</p>
-[23:11:00] <human> heheh</p>
-[23:11:04] <jrand0m> reasonable enough human.</p>
-[23:11:13] <mihi> jrand0m prefers PGP8 ;)</p>
-[23:11:23] <jrand0m> damn straight.  pgpdisk++</p>
-[23:12:06] * wilde has joined #i2p</p>
-[23:12:14] <duck> hi wilde</p>
-[23:12:36] <jrand0m> ok, does anyone have anything they want to bring up for 5) ??? </p>
-[23:13:27] <wilde> just an invitation one more time for people to visit drupal and comment, modify, etc</p>
-[23:13:37] <jrand0m> word, yes, thats a good point</p>
-[23:13:41] <duck> http://drupal.i2p.net/</p>
-[23:13:41] <wilde> so we can have good docs for 1.0</p>
-[23:13:41] <mihi> human, jrand0m: is the license in CVS okay now? ;)</p>
-[23:13:55] <jrand0m> on http://drupal.i2p.net/team there are a lot of [vacant] roles.  volunteer!</p>
-[23:14:02] <fidd> i cant get drupal thru squuid :/</p>
-[23:14:17] * mihi volunteers for QS guy cuz of echo server ;)</p>
-[23:14:29] <mihi> s/QS/QA/</p>
-[23:14:33] <jrand0m> woot!</p>
-[23:15:01] <wilde> unit tests for echo server</p>
-[23:15:12] <mihi> wilde rofl no</p>
-[23:15:17] <human> mihi: maybe you should s/XXXX/mihi/ in the GPL exception :-)</p>
-[23:15:20] <ughabugha> jrand0m: Heh, what do you mean by stress testing? :)</p>
-[23:15:34] <mihi> echo server is system test for i2p ;)</p>
-[23:15:38] <mihi> human: oops ;)</p>
-[23:15:56] * Rom|Away|4h has quit IRC (Ping timeout)</p>
-[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</p>
-[23:16:35] <ox> <wilde> thus stress testing poor jrandom...</p>
-[23:16:40] <ughabugha> jrand0m: Oh, okay. :)</p>
-[23:16:44] <duck> wow, mihi is fast</p>
-[23:16:47] <ughabugha> Hehe.</p>
-[23:17:30] * Romster has joined #i2p</p>
-[23:17:40] <mihi> duck: editor still open and the CVS comment was fast to type as well ;)</p>
-[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?</p>
-[23:17:41] * Romster is now known as Rom|Away|4h</p>
-[23:18:02] <jrand0m> (or you can just add that copyright text into the source)</p>
-[23:19:24] <mihi> hmm, what does idented mean? (yes to your second subclause)</p>
-[23:19:42] <jrand0m> means you've proven to trent that you're mihi :)</p>
-[23:19:50] <duck> authenticated</p>
-[23:19:54] <mihi> ok, identified ;)</p>
-[23:20:01] <jrand0m> w3rd</p>
-[23:20:06] <human> let's try identicated</p>
-[23:20:14] <mihi> it looked to me like "indented" and i thought that my white space was incorrect ;)</p>
-[23:20:20] <jrand0m> hehe</p>
-[23:20:43] <ox> * wilde thinks launches word for find yet another synonym</p>
-[23:21:07] <human> authentified?</p>
-[23:21:22] <duck> anyway...</p>
-[23:21:28] <jrand0m> ok, r0x0r, anyone have anything else to bring up?</p>
-[23:21:44] <ox> <wilde> yeah</p>
-[23:21:50] <ox> <wilde> eep naming </p>
-[23:22:00] <jrand0m> heh you don't like my pronounciation?</p>
-[23:22:12] * kaji has quit IRC (Ping timeout)</p>
-[23:22:14] <ox> <wilde> of i2p -> eep</p>
-[23:22:14] * Rom|Away|4h has quit IRC (Ping timeout)</p>
-[23:22:21] <jrand0m> oh</p>
-[23:22:30] <jrand0m> you want to rename the whole project "eep" ?</p>
-[23:22:39] <human> lol</p>
-[23:22:48] <ox> * wilde mutters</p>
-[23:22:48] <mihi> envisible enternet project ;)</p>
-[23:23:08] <lucky> envisible</p>
-[23:23:09] <jrand0m> extrordinarily excellent people</p>
-[23:23:15] <lucky> connotates something for me.</p>
-[23:23:46] <mihi> even easier publishing ;)</p>
-[23:23:51] <jrand0m> ooOOoo</p>
-[23:23:51] <lucky> As in its going to be visable, therefore possible. envision maybe?</p>
-[23:23:53] <ughabugha> Come on, stop picking on wilde. :)</p>
-[23:23:54] <ox> <wilde> seriously, do you like the name then it's fun?</p>
-[23:24:06] <ox> <wilde> fine i mean, getting tired</p>
-[23:24:44] <ox> <wilde> new users will not have it easy</p>
-[23:25:03] <jrand0m> oh, i'm not a marketeer.  we went under "eep" because its all i could think of</p>
-[23:25:23] <human> i think it should be forbidden to explain that eep ~= i2p, or users will *really* screw up</p>
-[23:25:25] * ion has quit IRC (Ping timeout)</p>
-[23:25:26] <jrand0m> what should we call websites that people both host and access through i2p?</p>
-[23:25:38] <jrand0m> hehe</p>
-[23:25:42] <duck> i2psites?</p>
-[23:25:44] <ox> <wilde> i2p site?</p>
-[23:25:57] * human likes eepsites without explanations :-)</p>
-[23:26:09] * kaji has joined #i2p</p>
-[23:26:25] * jrand0m asks the http://drupal.i2p.net/team user advocate for their opinion</p>
-[23:26:35] <duck> we got one?</p>
-[23:26:38] <jrand0m> no</p>
-[23:26:43] <jrand0m> ;)</p>
-[23:26:52] <duck> heh</p>
-[23:26:55] <human> anyway... you can change all the naming, as long as the "Shitlist" keeps its current name</p>
-[23:26:56] <ox> * wilde rushes to the browser</p>
-[23:27:01] <jrand0m> heh</p>
-[23:27:06] <mihi> lol human</p>
-[23:27:07] <jrand0m> oh, shitlist is going to stay, for sure ;)</p>
-[23:27:21] <ox> <wilde> i take the role, it should be i2p sites, i resign</p>
-[23:27:21] <duck> I bet that shitlist is a proper english word</p>
-[23:27:24] <jrand0m> i mean, "blacklist" just isn't as fun</p>
-[23:27:26] <jrand0m> hah wilde</p>
-[23:27:29] <human> jrand0m: cool!</p>
-[23:27:56] <ughabugha> But why not stick to the current names?</p>
-[23:28:05] * human was worried that the shitlist was going to be the first victim when I2P goes corporate</p>
-[23:28:06] <jrand0m> ok, i don't really care either way, i2psite is fine, eepsite is fine</p>
-[23:28:09] <ughabugha> I mean we have enough time to consider it on the mailing list until 1.0.</p>
-[23:28:09] <mihi> jrand0m: and the elephants on the moon have to stay too ;)</p>
-[23:28:22] <kaji> so is kaji.i2p up for anyone. i kinda just started it up without testing anything and left it running</p>
-[23:28:31] <jrand0m> human> i think we don't have to worry about that one ;)</p>
-[23:28:35] <ughabugha> kaji: It worked for me.</p>
-[23:28:48] <jrand0m> we have to keep moving the easter eggs mihi :)</p>
-[23:28:48] <ox> <wilde> i don't really care, eepsite is just as boring as i2psite</p>
-[23:29:05] <jrand0m> we can consider them synonyms</p>
-[23:29:23] <ox> <wilde> that the worst decision ;)</p>
-[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</p>
-[23:29:44] * jrand0m supposes that now that i've taken on the title of PM i've got to make a decision</p>
-[23:29:48] * ion has joined #i2p</p>
-[23:29:55] * jrand0m kicks self</p>
-[23:30:09] <human> heheh</p>
-[23:30:12] * mihi guesses jrand0m needs some support for that</p>
-[23:30:19] * Trent@anon.iip sets mode: +o mihi</p>
-[23:30:27] * mihi sets mode: +o jrand0m</p>
-[23:30:30] <@jrand0m> ooOOoo</p>
-[23:30:32] * mihi sets mode: -o mihi</p>
-[23:30:49] <ox> <wilde> ok no more questions from me</p>
-[23:30:55] * human sacrifices his pet to the PM</p>
-[23:31:38] * mihi still waits for jrand0m kicking himself...</p>
-[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"</p>
-[23:31:59] * @jrand0m Offically Decides "eepsite"</p>
-[23:32:23] * You were kicked by jrand0m (bastard!)</p>
-Session Close: Tue Mar 23 23:32:23 2004</p>
-Session Start: Tue Mar 23 23:32:30 2004</p>
-[23:32:32] <human> lol</p>
-[23:32:37] <duck> lets quickly baff the meeting closed</p>
-[23:32:40] <duck> oh, too late</p>
-[23:32:42] <jrand0m> heh</p>
-[23:32:48] <human> heheh</p>
-[23:32:56] <jrand0m> ok anything else?  we're at the 92 minute mark</p>
-[23:33:05] * jrand0m winds up...</p>
-[23:33:20] * jrand0m *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/82.rst b/i2p2www/meetings/82.rst
new file mode 100644
index 00000000..1aee8e0e
--- /dev/null
+++ b/i2p2www/meetings/82.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, March 23, 2004 @ 13:00 PST
+===========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/9.log b/i2p2www/meetings/9.log
index db4e13ef..16dc75c3 100644
--- a/i2p2www/meetings/9.log
+++ b/i2p2www/meetings/9.log
@@ -1,10 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 9{% endblock %}
-{% block content %}
-<h3>I2P (invisiblenet) Development Meeting 9</h3>
-<div class="irclog">
-Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
-
 --- Log opened Wed Aug 21 00:58:22 2002
 00:58 <@mids> test
 01:00 <@mids> Hi folk(s)
@@ -94,5 +87,3 @@ Courtesy of <a href="http://www.archive.org/">the wayback machine</a>.
 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
-</div>
-{% endblock %}
diff --git a/i2p2www/meetings/9.rst b/i2p2www/meetings/9.rst
new file mode 100644
index 00000000..44130b42
--- /dev/null
+++ b/i2p2www/meetings/9.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, August 21, 2002
+================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log (Courtesy of <a href="http://www.archive.org/">the wayback machine</a>)
+------------
diff --git a/i2p2www/meetings/90.log b/i2p2www/meetings/90.log
index e31c593d..f7cb2e36 100644
--- a/i2p2www/meetings/90.log
+++ b/i2p2www/meetings/90.log
@@ -1,203 +1,197 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 90{% endblock %}
-{% block content %}<h3> Tuesday, May 18, 2004 14:00:00 PDT</h3>
-<div class="irclog">
-14:07 < jrandom> 0) hi</p>
-14:07 < jrandom> 1) testnet status</p>
-14:07 < jrandom> 2) SAM</p>
-14:07 < jrandom> 3) roadmap updates</p>
-14:07 < jrandom> 4) MyI2P</p>
-14:07 < jrandom> 5) ???</p>
-14:07 < jrandom> 0) hi</p>
-14:07  * jrandom waves </p>
-14:08 < Nightblade> hi</p>
-14:08  * jteitel waves back</p>
-14:08 < jar> hi</p>
-14:08 < duck> lo</p>
-14:08 < Masterboy> :P</p>
-14:08 < jrandom> weekly status notes posted up to http://dev.i2p.net/pipermail/i2p/2004-May/000239.html</p>
-14:09 < jrandom> sorry if I'm a bit out of it today, sleep schedule is more out of wack than usual</p>
-14:09 < jrandom> anyway, moving on to 1) testnet status</p>
-14:10 < duck> the diversification would automatically happen with a bigger network wouldnt it?</p>
-14:10 < jrandom> yes, and/or less skewed peer selection thresholds</p>
-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</p>
-14:11 < jrandom> as opposed to the situation we have today where the speeds are heavily skewed</p>
-14:12 < Masterboy> well the network healed that's not so bad</p>
-14:12 < jrandom> yeah, it took longer than it should though, and exposed ways that it can be improved</p>
-14:13 < jteitel> did the network heal?  I still cannot connect to i2p irc reliably</p>
-14:13 < jrandom> the peer profiles didn't decay fast enough, or promote new candidates efficiently</p>
-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</p>
-14:15 < human> ayeee ayeee ayeee!</p>
-14:15 < jrandom> its been a progression jteitel - some of the issues we've been seeing are related to the netDb failures </p>
-14:15 < jrandom> heya human</p>
-14:15 < jteitel> Oh, OK</p>
-14:16 < _cervantes_> could not an troubled router offload tunnels to another peer?</p>
-14:16 < ugha_node> Wow, Lifetime rate: 8.87KBps sent 8.35KBps received.</p>
-14:16 < Nightblade> jteitel: I connected just now after several tries...still waiting for my /join to go through</p>
-14:16  * BrianR looks around.</p>
-14:16 < jrandom> no - a router can simply drop a tunnel though (if it shouldn't have accepted it in the first place)</p>
-14:16 < ugha_node> (And I restarted my router half an hour ago)</p>
-14:16 < BrianR> damn it. I'm late.</p>
-14:17 < BrianR> jrandom: (Thanks for arranging myi2p towards the end of the agenda)</p>
-14:17 < jrandom> ugha> yeah, y'all had to pick up the slack for those three fast ones</p>
-14:17 < jrandom> hehe :)</p>
-14:18 < duck> a nice attack it was</p>
-14:18 < ugha_node> jrandom: Obciously.</p>
-14:18 < _cervantes_> so would it not be better to be more ruthless and reject tunnels at lower threshold</p>
-14:19 < jrandom> yes cervantes - the routers right now never reject a tunnel unless they cant reach the next hop</p>
-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</p>
-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</p>
-14:20 < _cervantes_> or simply allow the user to set a threshold based on the hardware/bandwith he/she knows he has availabled</p>
-14:20 < jrandom> (due to the fast+reliable peers going offline)</p>
-14:20 < _cervantes_> at least at this stage</p>
-14:20 < jrandom> oh thats a good point - allowing people to explicitly set a max # participating tunnels.</p>
-14:21 < jrandom> we'll get that into the next rev.  good call.</p>
-14:21 < ugha_node> This sounds just like fuzzy logic.</p>
-14:21 < jrandom> we've got to deal with overload, and simply queueing up messages in memory certainly doesnt work</p>
-14:21 < duck> (hi fvw)</p>
-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)</p>
-14:22 < _cervantes_> btw I took my server offline....it was getting a shed load of tunnels and I haven't yet compiled jbigi ;-)</p>
-14:22 < jrandom> see http://localhost:7655/routerStats.html#Tunnels</p>
-14:23 < jrandom> ah!  yeah, jbigi is something we want to encourage everyone to use </p>
-14:23 < BrianR> Any thoughts on doing bandwidth budgeting for tunnels? </p>
-14:24 < jrandom> currently slated for 3.0 (with overall bandwidth limiting for the router as a whole @ 0.4.1)</p>
-14:24 < jrandom> but having per-tunnel bandwidth limits earlier wouldnt hurt</p>
-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?</p>
-14:25 < _cervantes_> something I would like to see is per-tunnel depth settings (perhaps this is already possible)</p>
-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</p>
-14:25 < jrandom> fvw> thats a good point, especially since we currently don't devour too much bandwidth</p>
-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</p>
-14:26 < _cervantes_> nope</p>
-14:26 < jrandom> cervantes - i think what you're looking for is a QoS where you can shorten the conn for one particular peer</p>
-14:26 < _cervantes_> for instance...</p>
-14:26 < _cervantes_> yep</p>
-14:27 < jrandom> (which was slated for i2p 4.0, but thats more than a year away == infinity)</p>
-14:27 < _cervantes_> in this case also select the depth per i2p host</p>
-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... </p>
-14:27 < _cervantes_> ah ok</p>
-14:27 < _cervantes_> :)</p>
-14:27 < jrandom> but its a good idea, and technically feasible, but patches accepted :)</p>
-14:28 < _cervantes_> the patch is already in the mail....along with that cheque for 5000 bars of e-gold </p>
-14:28 < _cervantes_> ;-)</p>
-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?</p>
-14:28 < jrandom> heh</p>
-14:30 < jrandom> ok, anyone have anything else for the testnet status?</p>
-14:30 < Masterboy> what about my paradox?</p>
-14:30 < Masterboy> :)</p>
-14:30 < jrandom> my plan is to get a 0.3.1.3 with the updates out by thursday or friday</p>
-14:31 < jrandom> Masterboy: i havent had time to go through your logs, but we'll have it resolved</p>
-14:31 < _cervantes_> friday 2005?</p>
-14:31 < _cervantes_> cool</p>
-14:31 < Masterboy> k</p>
-14:31 < jrandom> ok, moving on to 2) SAM</p>
-14:31 < Masterboy> now we know who is running the out of date router..</p>
-14:32  * jrandom hands the mic to our intrepid SAM.pm dev</p>
-14:33 < jrandom> (thats you BrianR :)</p>
-14:33 < BrianR> Hold a second.. :)</p>
-14:33  * duck cheers</p>
-14:33 < jrandom> in the meantime, dm or firerabbit around?</p>
-14:33 -!- Irssi: #i2p: Total of 26 nicks [0 ops, 0 halfops, 0 voices, 26 normal]</p>
-14:33  * jrandom checks the /names, nope.  oh well</p>
-14:33 < jrandom> (no .net/C# sam lib updates then)</p>
-14:34 < duck> is the .py stuff still current?</p>
-14:34 < duck> or depricated by SAM improvements</p>
-14:34 < jrandom> not sure</p>
-14:34 < BrianR> Ok. I'm back. </p>
-14:34 < Nightblade> My C library appears to be working... I have not written an application to use it yet though</p>
-14:34 < jrandom> awesome nightblade!</p>
-14:35 < Nightblade> Has anyone here done GTK+/C programming under Windows?</p>
-14:35 < human> duck: the client lib needs a small change for versioning support</p>
-14:35 < _cervantes_> "hello world"?</p>
-14:35 < human> duck: the rest should work without problems</p>
-14:35  * jrandom suggests a datagram like tftp as the ideal sam test :)</p>
-14:35 < Nightblade> well, anything really... does GTK work well under windows.....?</p>
-14:35 < jrandom> (or even SAM streaming instead of datagram or raw)</p>
-14:36 < jrandom> cool BrianR - how goes the .pm and the samcat?</p>
-14:36 < BrianR> Net::SAM is in the CVS in mostly non-working form.</p>
-14:36 < BrianR> I hope to have all of the bugs ironed and datagram and raw working before week end.</p>
-14:37 < BrianR> A bit more work will be required to put a nice OO finish on streams.</p>
-14:37 < Nightblade> oh yeah, i didn't bother with datagram or raw... just stream</p>
-14:37 < Nightblade> but that is all i would use anyway</p>
-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)</p>
-14:37 < jrandom> awesome BrianR </p>
-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 </p>
-14:38 < human> fvw: the GTK windows client does exist (The GIMP runs on windows, too)</p>
-14:38 < jrandom> cool nightblade, its best to implement whats needed first</p>
-14:38 < human> fvw: s/client/port/</p>
-14:38 < jrandom> heh 'k BrianR, thanks</p>
-14:38 < fvw> human: I mean gtk windows target for wxWindows (which I was suggesting you use)</p>
-14:38  * fvw waves to BrianR. Bon Appetite.</p>
-14:38 < human> fvw: ah... well, i don't know about vxWidgets (vxWindows' new name :-)</p>
-14:39 < human> fvw: but it was Nightblade speaking about GTK+, not me :-)</p>
-14:40 < fvw> Oops, my eyes are crooked, ignore me.</p>
-14:40 < Nightblade> I'm not as familiar with C++ as I am C</p>
-14:40 < Nightblade> afaik GTK is the only cross-platform C GUI library</p>
-14:40 < Nightblade> not that i am particularly fond of GTK</p>
-14:40 < fvw> doesn't really matter, wxWindows is easily approachable from C.</p>
-14:40 < Nightblade> hmm</p>
-14:40 < Nightblade> well maybe i'll take a look at it too</p>
-14:40 < Nightblade> i know C++ but I haven't written any major programs in it</p>
-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.</p>
-14:42 < Nightblade> i am sure wxwindows has a more mature windows port</p>
-14:42 < Nightblade> than gtk</p>
-14:42 < fvw> quite probably yeah.</p>
-14:43 < Nightblade> (ok continue meeting) heh</p>
-14:43 < jrandom> :)</p>
-14:43 < jrandom> ok, jumping to 3) roadmap updates</p>
-14:44  * jrandom has been negligent updating http://www.i2p.net/roadmap over the last month</p>
-14:44 < jrandom> but now its back up to current</p>
-14:44 < jrandom> unfortunately we're obviously not getting 0.4 in next week</p>
-14:44 < duck> (are 1.1, 2.0, 3.0 also up2date?)</p>
-14:45 < jrandom> yessir</p>
-14:45  * Masterboy read it liked it - no rush we are not on fire..</p>
-14:46 < duck> someone should update wikipedia/infoanarchy too :)</p>
-14:46 < jrandom> oh, i should probably remove the "SAM bridge and client libraries implemented and tested" from 0.4</p>
-14:46 < jrandom> heh yeah, thats why i !thwapped iA a while back when they just copied the wiki page</p>
-14:46 < jrandom> (they should just point to the /roadmap, not duplicate the content)</p>
-14:47 < Masterboy> SAM is finished?</p>
-14:47 < jrandom> its functional yes, though work on additional client libraries are ongoing</p>
-14:47 < jrandom> s/are/is/</p>
-14:48 < jrandom> ok, unless there are any more roadmap questions/concerns, moving on to 4) MyI2P</p>
-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</p>
-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</p>
-14:51 < Masterboy> tried to get in it my friend he said too mutch work too little money;P well he is a capitalist;)</p>
-14:51 < Masterboy> well i offered to code it..</p>
-14:52 < jrandom> coding on it is always wanted :)  </p>
-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</p>
-14:53 < Nightblade> just have to have some trusted i2p isp</p>
-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</p>
-14:54 < _cervantes_> the later being the long term ideal solution</p>
-14:54 < _cervantes_> *latter</p>
-14:54 < duck> (and being another bounty)</p>
-14:55 < _cervantes_> or a webcache proxy service...</p>
-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</p>
-14:55 < jrandom> _cervantes_: thats essentially the distributed backing store - untrusted data caches</p>
-14:57 < deer> * Masterboy wonders where is bogobot</p>
-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</p>
-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</p>
-14:57 < _cervantes_> and signed content</p>
-14:58 < jrandom> right, both ways will need to have signed content</p>
-15:00 < _cervantes_> this is where hypercubus' model has merit...but it's by no means "quick" solution</p>
-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</p>
-15:01 < wilde> first things first, getting a basic MyI2P in first place</p>
-15:02 < jrandom> right, and to get the basic myi2p implemented, we've got to know the deployment architecture</p>
-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</p>
-15:03 < jrandom> and why would someone use myi2p if they merely need lj's threat model?  because its anonymous</p>
-15:04 < jrandom> we could go on for some idealized system, but there is the law of diminishing returns</p>
-15:04 -!- Irssi: #i2p: Total of 24 nicks [0 ops, 0 halfops, 0 voices, 24 normal]</p>
-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</p>
-15:05 -!- duck_ is now known as duck</p>
-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</p>
-15:06 < jrandom> if not, moving on to 5) ???</p>
-15:07 < _cervantes_> hmm you need a large gavel :)</p>
-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!</p>
-15:08 < jrandom> (and sungo.i2p has his webcam up and running :)</p>
-15:08 < _cervantes_> heh...</p>
-15:08 < _cervantes_> i2pr0n</p>
-15:08 < jrandom> anyone else have anything they want to bring up?</p>
-15:10 < jrandom> if not, that'll put us at the 70 minute mark</p>
-15:10 < deer> <Masterboy> no</p>
-15:10  * jrandom winds up</p>
-15:10  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/90.rst b/i2p2www/meetings/90.rst
new file mode 100644
index 00000000..b23ba11a
--- /dev/null
+++ b/i2p2www/meetings/90.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, May 18, 2004 @ 14:00 PDT
+=========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/92.log b/i2p2www/meetings/92.log
index c6011847..a7831ff0 100644
--- a/i2p2www/meetings/92.log
+++ b/i2p2www/meetings/92.log
@@ -1,341 +1,336 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 92{% endblock %}
-{% block content %}<div class="irclog">
-[22:59] <duck> Tue Jun  1 21:00:00 UTC 2004</p>
-[23:00] <duck> hi folks!</p>
-[23:00] <mihi> hi duck</p>
-[23:00] <duck> http://dev.i2p.net/pipermail/i2p/2004-June/000250.html</p>
-[23:00] <duck> my proposal:</p>
-[23:00] * Masterboy has joined #i2p</p>
+[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</p>
-[23:00] <duck> 2) featured content</p>
-[23:00] <duck> 3) testnet status</p>
-[23:00] <duck> 4) bounties</p>
-[23:00] <duck> 5) ???</p>
-[23:00] <Masterboy> hi:)</p>
-[23:00] <duck> .</p>
-[23:01] <duck> since jrandom is off we'll have to do it ourself</p>
-[23:01] <duck> (I know that he is logging and verifying our independency)</p>
-[23:01] <Masterboy> no problem:P</p>
-[23:02] <duck> unless there are problems with the agenda I propose that we stick to it</p>
-[23:02] <duck> though there aint much that I can do if you dont :)</p>
-[23:02] <duck> .</p>
-[23:02] <mihi> ;)</p>
-[23:02] <duck> 1) code progress</p>
-[23:02] <duck> not much code submitted to cvs</p>
-[23:02] <duck> I did win the trophy this week: http://duck.i2p/duck_trophy.jpg</p>
-[23:03] * hypercubus has no cvs account yet</p>
-[23:03] <Masterboy> and who did submit something?</p>
-[23:03] <duck> anybody doing any secret coding?</p>
-[23:03] * Nightblade has joined #I2P</p>
+[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</p>
-[23:04] <hypercubus> i've got maybe 20% of the 0.4 installer hacked out</p>
-[23:04] <duck> hypercubus: if you have stuff then provide diffs and $dev will commit for you</p>
-[23:04] <duck> ofcourse the strict license agreements apply</p>
-[23:05] <duck> hypercubus: cool, any issues / things worth mentioning?</p>
-[23:06] <hypercubus> not yet, but i'll probably need a couple of BSD people to test the preinstaller shell scripts</p>
-[23:06] * duck turns some stones</p>
-[23:06] <Nightblade> is it text-only</p>
-[23:07] <mihi> duck: which one is you on duck_trophy.jpg?</p>
-[23:07] <mihi> ;)</p>
-[23:07] <Nightblade> luckypunk has freebsd, also my isp has freebsd but their config is kind of screwed up</p>
-[23:07] <Nightblade> my web host isp that is, not comcast</p>
-[23:08] <duck> mihi: left one with the glasses. wilde is the right guy handing me the trophy</p>
-[23:08] * wilde waves</p>
-[23:08] <hypercubus> you have a choice... if you have java installed, you can skip the preinstaller altogether... </p>
-  if you don't have java installed you can run the linux binary or win32 binary preinstaller (console mode), or a </p>
-  generic *nix script preinstaller (console mode)</p>
-[23:08] <hypercubus> the main installer gives you the choice of using console mode or spiffy GUI mode</p>
-[23:08] <Masterboy> i will install freebsd soon so in the future i will give a try to the installer too</p>
-[23:09] <hypercubus> ok good... didn't know if anyone else besides jrandom was using it</p>
-[23:09] <Nightblade> freebsd java is invoked as "javavm" rather than "java"</p>
-[23:09] <hypercubus> as built from sun sources?</p>
-[23:09] <mihi> freebsd supports symlinks ;)</p>
-[23:10] <hypercubus> anyhow the binary preinstaller is 100% complete</p>
-[23:10] <hypercubus> compiles with gcj to native</p>
-[23:11] <hypercubus> it just asks you for the install dir, and it grabs a JRE for you</p>
-[23:11] <duck> w00t</p>
-[23:11] <Nightblade> cool</p>
-[23:11] <hypercubus> jrandom's packaging a custom JRE for i2p</p>
+[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> .</p>
-[23:12] <Nightblade> if you install java from the freebsd ports collection you use some wrapper script called </p>
-  javavm</p>
-[23:12] <deer> <r> .</p>
-[23:12] <hypercubus> anyhow this puppy will be almost completely automated</p>
-[23:12] <deer> <r> .</p>
-[23:12] <deer> <r> .</p>
-[23:12] <deer> <r> .</p>
-[23:12] <deer> <duck> r: cut it</p>
-[23:12] <deer> <r> .</p>
-[23:12] <deer> <m> .</p>
-[23:13] <deer> <m> stoopid irc server, does not support pipelining :(</p>
-[23:13] <duck> hypercubus: got any ETA for us?</p>
-[23:14] <deer> <m> oops, the problem is "Nick change too fast" :(</p>
-[23:14] <hypercubus> i still expect to be finished in under a month, before 0.4 is ripe for release</p>
-[23:14] <hypercubus> though at present i'm compiling a new OS for my dev system, so it'll be a couple of days </p>
-  before i get back to the installer ;-)</p>
-[23:14] <hypercubus> no worries though</p>
-[23:15] <duck> ok. so more news next week :)</p>
-[23:15] <duck> any other coding done?</p>
-[23:15] <hypercubus> hopefully... unless the power company screws me again</p>
-[23:16] * duck moves to #2</p>
-[23:16] <duck> * 2) featured content</p>
-[23:16] <duck> lots of streaming audio (ogg/vorbis) done this week</p>
-[23:16] <duck> baffled is running his egoplay stream and I am running a stream too</p>
-[23:16] <Masterboy> and it works quite good</p>
-[23:17] <duck> on our site you can get info how to use it</p>
-[23:17] <hypercubus> got any rough stats for us?</p>
-[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 </p>
-  add</p>
-[23:17] <Masterboy> duck where is the link to baffleds stream on your site?</p>
-[23:17] <Masterboy> :P</p>
-[23:17] <duck> hypercubus: 4kB/s goes pretty well</p>
-[23:18] <duck> and with ogg it aint tooooo bad</p>
-[23:18] <hypercubus> but that still seems to be the avg. speed?</p>
-[23:18] <duck> my observation is that is the max</p>
-[23:18] <duck> but it is all config tweaking</p>
-[23:19] <hypercubus> any idea why that seems to be the max?</p>
-[23:19] <hypercubus> and i'm not just talking streaming here</p>
-[23:19] <hypercubus> but downloads too</p>
-[23:20] <Nightblade> i was downloading some big files yesterday (a couple megabytes) off of duck's hosting </p>
-  service and i was getting about 4kb-5kb as well</p>
-[23:20] <duck> I think that it is the rtt</p>
-[23:20] <Nightblade> those Chips movies</p>
-[23:20] <hypercubus> 4-5 seems an improvement over the ~3 that i've gotten consistently since i started using i2p</p>
+[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..</p>
-[23:20] <duck> with a windowsize of 1 you dont get much faster..</p>
-[23:20] <duck> windowsize >1 bounty: http://www.i2p.net/node/view/224</p>
-[23:21] <duck> mihi: maybe you can comment?</p>
-[23:21] <hypercubus> but it is a remarkably consistent 3 kbps</p>
-[23:21] <mihi> on what? windowsize>1 with ministreaming: you are a wizard if you manage that ;)</p>
-[23:21] <hypercubus> no hiccups on the bandwidth meter... a fairly smooth line</p>
-[23:21] <duck> mihi: on why it is so stable at 4kb/s</p>
-[23:21] <mihi> no idea. i don't hear any sound :(</p>
-[23:22] <duck> mihi: for all i2ptunnel transfers</p>
-[23:22] <Masterboy> mihi you need to config the ogg streaming plugin..</p>
-[23:22] <mihi> Masterboy:?</p>
-[23:23] <mihi> no, there is no limit inside i2ptunnel regarding speed. it must be in the router...</p>
-[23:23] <duck> my thinking: max packet size: 32kB, 5 second rtt: 32kB/5s =~ 6.5kb/s</p>
-[23:24] <hypercubus> sounds plausible</p>
-[23:25] <duck> ok..</p>
-[23:25] <duck> other content:</p>
-[23:25] * hirvox has joined #i2p</p>
+[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</p>
-[23:25] <duck> anonynanny.i2p</p>
-[23:25] <duck> key is commited to cvs and he did put it on ugha's wiki</p>
-[23:25] * mihi is hearing "sitting in the ..." - duck++</p>
-[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 </p>
-  is in the router or the streaming lib</p>
-[23:26] <duck> Naughtious: you there? tell something about your plan :)</p>
-[23:26] <Masterboy> i have read that he provides hosting</p>
-[23:26] <duck> Nightblade: I did try 3 parallel downloads from baffled and I got 3-4kB each</p>
-[23:26] <Nightblade> i c</p>
-[23:27] <mihi> Nightblade: how can you tell that then?</p>
-[23:27] * mihi likes listening in "stop&go" mode ;)</p>
-[23:27] <Nightblade> well if there is some kind of limitation in the router that only lets it handle 4kb at once</p>
-[23:27] <Nightblade> or if it is something else</p>
-[23:28] <hypercubus> can someone explain this anonynanny site? i don't have a running i2p router atm</p>
-[23:28] <mihi> hypercubus: just a wiki or some sort of it</p>
-[23:28] <duck> plone CMS setup, open account creation</p>
-[23:28] <duck> allows file upload and website stuff</p>
-[23:28] <duck> through web interface</p>
-[23:28] <Nightblade> another thing to do would be to test the throughput of the "repliable datagram" which afaik </p>
-  is the same as the streams but without acks</p>
-[23:28] <duck> likely a lot like drupal</p>
-[23:28] <hypercubus> yeah i've run plone before</p>
-[23:29] <duck> Nightblade: I have been thinking about using airhook to manage those</p>
-[23:29] <duck> but so far only some basic thought</p>
-[23:29] <hypercubus> anything goes for the wiki content, or does it center on something in particular?</p>
-[23:29] <Nightblade> i think airhook is GPLed</p>
-[23:29] <duck> the protocol</p>
-[23:29] <duck> not the code</p>
-[23:29] <Nightblade> ah :)</p>
-[23:30] <duck> hypercubus: he wants quality content, and lets you provide that :)</p>
-[23:30] <Masterboy> upload the best pr0n of yourself you have got hyper;P</p>
-[23:30] <duck> ok</p>
-[23:30] * Masterboy will try to do that too</p>
-[23:30] <hypercubus> yeah, anyone running an open wiki is just asking for quality content ;-)</p>
-[23:31] <duck> ok</p>
-[23:31] * duck moves to #3</p>
-[23:31] <duck> * 3) testnet status</p>
-[23:31] <Nightblade> Airhook gracefully handles intermittent, unreliable, or delayed networks  <-- hehe not an </p>
-  optimistic description of I2P!</p>
-[23:31] <duck> how has it been going?</p>
-[23:32] <duck> lets put the datagram over i2p discussion to the end</p>
-[23:32] <tessier> I love to run around to open wiki's and link to this: http://www.fissure.org/humour/pics/squirre</p>
-  l.jpg</p>
-[23:32] <tessier> airhook rocks</p>
-[23:32] <tessier> I've been looking at it for building a p2p network also.</p>
-[23:32] <Nightblade> it seems to be reliable to me (#3)</p>
-[23:32] <Nightblade> best i've seen so far</p>
-[23:33] <duck> yeah</p>
-[23:33] <mihi> works well - at least for stop&go audio streaming</p>
-[23:33] <duck> I see quite impressive uptimes on irc</p>
-[23:33] <hypercubus> agreed... seeing lots more blue guys in my router console</p>
-[23:33] <Nightblade> mihi: are you listening to techno ? :)</p>
-[23:33] <duck> but hard to tell since bogobot doesnt seem to handle connections that go over 00:00</p>
-[23:33] <tessier> audio streaming works great for me but loading websites often takes a number of tries</p>
-[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 </p>
-  for 7 hours and so my router was running for 13hours</p>
-[23:33] <duck> (*hint*)</p>
-[23:34] <hypercubus> duck: er... heheh</p>
-[23:34] <hypercubus> i could fix that i guess</p>
-[23:34] <hypercubus> do you have the logging set for daily?</p>
-[23:34] <duck> hypercubus++</p>
-[23:34] <hypercubus> log rotation that is</p>
-[23:34] <duck> oh yes</p>
-[23:34] <duck> duck--</p>
-[23:34] <hypercubus> that's why</p>
-[23:34] <Nightblade> I was at work all day and turned on my computer and started i2p and was on duck's irc server </p>
-  in just a few minutes</p>
-[23:35] <duck> I have been seeing some weird DNFs</p>
-[23:35] <duck> even when connecting to my own eepsites</p>
-[23:35] <duck> (http://dev.i2p.net/bugzilla/show_bug.cgi?id=74)</p>
-[23:35] <duck> I think that is what causes most problems now</p>
-[23:35] <hypercubus> bogoparser will only analyze uptimes that occur wholly within a single logfile... so if the </p>
-  logfile encompasses only 24 hours, nobody will show up as connected longer than 24 hours</p>
-[23:35] <duck> Masterboy and ughabugha did also have it I think...</p>
-[23:36] <Masterboy> yup</p>
-[23:36] <duck> (fix it and you will win next weeks trophy for sure!)</p>
-[23:37] <deer> <mihi> bogobot is excited? ;)</p>
-[23:37] <Masterboy> i tried my web site and sometimes when i hit refresh it takes the other route? and i have to </p>
-  wait for it to load but i never wait;P i hit it again and it shows instantly</p>
-[23:37] <deer> <mihi> oops, sry. forgot that this is gated...</p>
-[23:38] <duck> Masterboy: do the timeouts take 61 seconds?</p>
-[23:39] <duck> mihi: bogobot set to weekly rotations now</p>
-[23:39] * mihi has quit IRC ("bye, and have a nice meeting")</p>
-[23:40] <Masterboy> sorry i didn't check it on my web site when i can't reatch it instantly i just hit refresh </p>
-  and it loads instantly..</p>
-[23:40] <duck> hm</p>
-[23:40] <duck> well, it needs to be fixed</p>
-[23:41] <duck> .... #4</p>
-[23:41] <Masterboy> i think the route is given not the same eatch time</p>
-[23:41] <duck> * 4) bounties</p>
-[23:41] <duck> Masterboy: local connections should be cutted short</p>
-[23:42] <duck> wilde had some bounty thoughts... you there?</p>
-[23:42] <Masterboy> maybe it is a peer selection bug</p>
-[23:42] <wilde> I'm not sure that was for the agenda really</p>
-[23:42] <duck> oh</p>
-[23:42] <wilde> ok but the thoughts were something like:</p>
-[23:42] <Masterboy> i think then we go public the bounty system will work better</p>
-[23:43] <Nightblade> masterboy: yes there are two tunnels for each connection, or that is how i understand it </p>
-  from reading the router.config</p>
-[23:43] <wilde> we could use this month to do some small advertising of i2p and increase the bounty pool a bit</p>
-[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</p>
-[23:44] <wilde> target against freedom communities, crypto people, etc</p>
-[23:44] <Nightblade> I don't think jrandom wants advertising</p>
-[23:44] <wilde> not public slashdot attention, no</p>
-[23:44] <hypercubus> that's what i've observed as well</p>
-[23:44] <Masterboy> i want to push it again - when we go public the system will work a lot better;P</p>
-[23:45] <wilde> Masterboy: bounties could speed up myi2p development for example</p>
-[23:45] <Masterboy> and as jr said no public till 1.0 and only some attention after 0.4</p>
-[23:45] <Masterboy> *wrote</p>
-[23:45] <wilde> when we have like $500+ for a bounty people could actually survive for some weeks</p>
-[23:46] <hypercubus> the tricky part is, even if we target a small dev community, like *cough* Mute devs, those </p>
-  guys might spread the word about i2p further than we'd like</p>
-[23:46] <Nightblade> someone could make a career out of fixing i2p bugs</p>
-[23:46] <hypercubus> and too soon</p>
-[23:46] <wilde> i2p links are already in many public places</p>
-[23:46] <Masterboy> you google and you can find i2p</p>
+[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 </p>
-  even loaded!)</p>
-[23:47] <wilde> http://en.wikipedia.org/wiki/I2p</p>
-[23:47] <Masterboy> but i agree that no advertising till 0.4 is done</p>
-[23:47] <Masterboy> wha???????</p>
-[23:47] <wilde> http://www.ovmj.org/GNUnet/links.php3?xlang=English</p>
-[23:48] <Masterboy> protol0l does a great job;P</p>
-[23:48] <Masterboy> ;))))))</p>
-[23:48] <hypercubus> nice typo ;-)</p>
-[23:48] <wilde> ok anyway, I agree we should still keep I2P private (jr read this log ;)</p>
-[23:49] <Masterboy> who did that?</p>
-[23:49] <Masterboy> i think the Freenet crew discussion gave more attention..</p>
-[23:50] <Masterboy> and jr discussing with toad give a lot info to the big public..</p>
-[23:50] <Masterboy> so as in ughas wiki - we can all blame jr for that;P</p>
-[23:50] <wilde> ok anyway, we'll see if we can bring in some $ without bringing in /.</p>
-[23:50] <Masterboy> agreed</p>
-[23:50] <hypercubus> the freenet dev list is hardly what i call the "big public" ;-)</p>
-[23:50] <wilde> .</p>
-[23:51] <hypercubus> wilde: you'll have a lot of $ sooner than you think ;-)</p>
-[23:51] <wilde> oh come on, even my mum subscribe to freenet-devl</p>
-[23:51] <duck> my mum reads through gmame</p>
-[23:51] <deer> <clayboy> freenet-devl is being taught in schools here</p>
-[23:52] <wilde> .</p>
-[23:52] <Masterboy> so we will see more bounties after we go 0.4 stable..</p>
-[23:53] <Masterboy> that is after 2 months;P</p>
-[23:53] <wilde> where did that duck go?</p>
-[23:53] <duck> thanks wilde </p>
-[23:53] <hypercubus> though as the only bounty claimant thus far, i have to say that the bounty money had no </p>
-  bearing on my decision to take up the challenge</p>
-[23:54] <wilde> hehe, it would if it been 100x</p>
-[23:54] <duck> wyou are too good for the world</p>
-[23:54] <Nightblade> haha</p>
-[23:54] * duck moves to #5</p>
-[23:54] <hypercubus> wilde, $100 doesn't mean shit to me ;-)</p>
-[23:54] <duck> 100 * 10 = 1000</p>
-[23:55] * duck pops("5 airhook")</p>
-[23:55] <duck> tessier: got any real-world experience with it</p>
-[23:55] <duck> (http://www.airhook.org/)</p>
-[23:55] * Masterboy will try dis out:P</p>
-[23:56] <duck> java implementation (dunno if it even works) http://cvs.ofb.net/airhook-j/</p>
-[23:56] <duck> python implementation (a mess, did work in the past) http://cvs.sourceforge.net/viewcvs.py/khashmir</p>
-  /khashmir/airhook.py</p>
-[23:58] * duck opens the rant-valve</p>
-[23:58] <Nightblade> j one is also gpl</p>
-[23:58] <duck> port it to pubdomain</p>
-[23:58] <hypercubus> amen</p>
-[23:58] <Nightblade> the entire protocol doc is only about 3 pages - it can't be that hard</p>
-[23:59] <Masterboy> nothing is hard</p>
-[23:59] <Masterboy> it's just not easy</p>
-[23:59] <duck> I dont think that it is fully specced though</p>
-[23:59] * hypercubus takes away masterboy's fortune cookies</p>
-[23:59] <duck> you might need to dive into the C code for a reference implementation</p>
-[00:00] <Nightblade> I would do it myself but I am busy with other i2p stuff right now</p>
-[00:00] <Nightblade> (and also my full-time job)</p>
-[00:00] <hypercubus> duck: maybe a bounty for it?</p>
-[00:00] <Nightblade> there already is</p>
-[00:00] <Masterboy> ?</p>
-[00:00] <Masterboy> ahh Pseudonyms</p>
-[00:00] <duck> it could be used at 2 levels</p>
-[00:00] <duck> 1) as a transport besides TCP</p>
-[00:01] <duck> 2) as a protocol to handle datagrams inside i2cp/sam</p>
-[00:01] <hypercubus> that's worth serious consideration then</p>
-[00:01] <hypercubus> </obvious></p>
+[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 </p>
-  stream has a maximum size of 32kb - making me think that the sender's destination is sent with each packet in </p>
-  repliable datagram mode, and only at the beginning for a stream mode -</p>
-[00:02] <Masterboy> well airhook cvs is not very updated..</p>
-[00:03] <Nightblade> making me think that it would be inefficient to make a protocol on top of the repliable </p>
-  datagrams through sam</p>
-[00:03] <duck> airhooks message size is 256 bytes, i2cp's is 32kb, so you need to atleast change a bit</p>
-[00:04] <Nightblade> actually if you wanted to do the protocol in SAM you could just use the anoymous datagram </p>
-  and have the first packet contain the sender's destination.... blah blah blah - i have lots of ideas but not </p>
-  enough time to code them</p>
-[00:06] <duck> then again you have to problems to verify signatures</p>
-[00:06] <duck> so someone could send fake packages to you</p>
-[00:06] <Masterboy> topic:::: SAM</p>
-[00:06] <Masterboy> ;P</p>
-[00:07] <Nightblade> true</p>
-[00:08] <Nightblade> but if you sent back to that destination and there was no acknowledgement you'd know it was </p>
-  a faker</p>
-[00:08] <Nightblade> there woudl have to be a handshake</p>
-[00:08] <duck> but you'll need aapplication level handshakes for that</p>
-[00:08] <Nightblade> no not really</p>
-[00:09] <Nightblade> just put it in a library for accessing SAM</p>
-[00:09] <Nightblade> that is a bad way of doing though</p>
-[00:09] <Nightblade> doing it though</p>
-[00:09] <duck> you could also use seperated tunnels</p>
-[00:09] <Nightblade> it shuold be in the streaming lib</p>
-[00:11] <duck> yup. makes sense</p>
-[00:12] <duck> ok</p>
-[00:12] <duck> I am feeling *baff*-y</p>
-[00:13] <Nightblade> ja</p>
-[00:13] * duck *baffs*</p>
-</div>
-{% endblock %}
\ No newline at end of file
+[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/92.rst b/i2p2www/meetings/92.rst
new file mode 100644
index 00000000..d9142714
--- /dev/null
+++ b/i2p2www/meetings/92.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, June 1, 2004 @ 21:00 UTC
+=========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/93.log b/i2p2www/meetings/93.log
index 215a8f9a..772771dc 100644
--- a/i2p2www/meetings/93.log
+++ b/i2p2www/meetings/93.log
@@ -1,280 +1,275 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 93{% endblock %}
-{% block content %}<div class="irclog">
-21:02:08 <duck> Tue Jun  8 21:02:08 UTC 2004</p>
-21:02:21 <duck> meeting time</p>
-21:02:33 <duck> writeup is at http://dev.i2p.net/pipermail/i2p/2004-June/000268.html</p>
-21:02:39 <duck> but I did make a mistake in the numbering</p>
-21:02:45 <duck> so the first item 5 will be skipped</p>
-21:02:53 <hypercubus> yay!</p>
-21:03:03  * duck puts some ice in his beer</p>
-21:03:14  * mihi 'd rename first #5 to #4 ;)</p>
-21:03:27 <hypercubus> nah, let's just have two item 4's next week ;-)</p>
-21:03:37  * duck renames 'hypercubus' to 'mihi'</p>
-21:03:48 <hypercubus> yay!</p>
-21:03:49 <duck> ok</p>
-21:03:53 <duck> * 1) libsam</p>
-21:04:02 <duck> is there a Nightblade in the channel?</p>
-21:04:39 <duck> (idle     : 0 days 0 hours 0 mins 58 secs)</p>
-21:05:03 <hypercubus> ;-)</p>
-21:05:53  * duck reclaims the microphone</p>
-21:06:15 <duck> Nightblade wrote a SAM lib for C / C++</p>
-21:06:23 <duck> it compiles for me.. but that is all I can say :)</p>
-21:06:37 <mihi> no test cases? ;)</p>
-21:07:06 <duck> if there are any rFfreebsd users Nightblade might be interested in you</p>
-21:07:08 <ugha_node> The strstr calls really annoyed me in the code. ;)</p>
-21:07:27 <ugha_node> duck: What's a rFfreebsd?</p>
-21:07:42 <duck> how I did type freebsd</p>
-21:08:00 <mihi> rm -rF freebsd?</p>
-21:08:29 <ugha_node> Too bad -F doesn't work with rm.</p>
-21:08:30 <duck> ugha_node: its bsd licensed; so fix it</p>
-21:08:41 <fvw> sounds sane to me :). Alas I uninstalled my last freebsd box a while back. I </p>
-                have accounts on other peoples' boxes though, and am willing to run testcases.</p>
-21:08:43 <ugha_node> duck: I might. :)</p>
-21:08:50 <duck> (damn BSD hippies)</p>
-21:09:09 <duck> oh, nice and short frank</p>
-21:09:17 <duck> mo libsam comments?</p>
-21:09:49 <duck> fvw: I guess Nightblade will contact you if he has a need</p>
-21:09:50  * fvw grumbles at perfectly sane unix behaviour for killing his irc client.</p>
-21:10:02 <duck> but since his email was a week old be might have found something</p>
-21:10:17 <mihi> fvw: ?</p>
-21:10:24 <fvw> yeah, if someone wanted to take me up on my offer I sort of missed that. Feel </p>
-                free to send email or something.</p>
-21:10:42  * duck hops to #2</p>
-21:10:46 <hypercubus> uhm, to where? ;-)</p>
-21:10:54 <duck> 2) browse i2p and normal web with one browser</p>
-21:10:57 <fvw> fresh install, haven't yet told my zsh not to hup stuff in the bacgrkground. </p>
-                </offtopic></p>
+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</p>
-21:12:11 <duck> there was some stuff about adding all TLDs to your brower proxy ignore list</p>
-21:12:23 <fvw> does that require discussion? I think it was pretty much handled on the </p>
-                mailinglist.</p>
-21:12:24 <duck> I think it is a dirty hack</p>
-21:12:36 <fvw> yes, that was mentioned. Welcome back.</p>
-21:12:47 <duck> fvw: I didnt read the thread :)</p>
-21:13:12 <duck> okay, if you dont want to discuss it, move to #3</p>
-21:13:19 <duck> * 3) chat channel</p>
-21:13:23 <hypercubus> cervantes' script works perfectly on Konqueror 3.2.2, Firefox 0.8, and </p>
-                       Opera 7.51, all for Gentoo w/KDE 3.2.2</p>
-21:13:39  * mihi places a flag on #4</p>
-21:13:55 <duck> #i2p-chat is an alternative channel here for offtopic chat and light support</p>
-21:14:08 <duck> I dont know who did regg it</p>
-21:14:12 <hypercubus> i did</p>
-21:14:17 <duck> so better be careful :)</p>
-21:14:22 <fvw> ehm, there is no #4, just two #5's :)</p>
-21:14:33 <hypercubus> i'll be lucky if i can remember the password when i need it ;-)</p>
-21:14:33 <mihi> [22:27] -ChanServ-      Channel: #i2p-chat</p>
-21:14:33 <mihi> [22:27] -ChanServ-      Contact: hypercubus <<ONLINE >></p>
+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 >></p>
-21:14:37 <mihi> [22:27] -ChanServ-   Registered: 4 days (0h 2m 41s) ago</p>
-21:15:12 <hypercubus> i gave a few trusted peeps op powers for whenver i'm not around and </p>
-                       there's trouble</p>
-21:15:24 <duck> sounds good</p>
-21:15:39 <duck> it might be a bit overkill</p>
-21:15:51 <hypercubus> you never know on IRC ;-)</p>
-21:15:55 <duck> but after this protogirl did join here I thought it would be good to clean up </p>
-                 this chan</p>
-21:16:03 <hypercubus> heh</p>
-21:16:27 <hypercubus> we'll need it for sure sometime in the next few months anyhow</p>
-21:16:34 <duck> jups</p>
-21:16:48 <duck> and then the freenode ppl will kick us out </p>
-21:16:55 <hypercubus> ;-)</p>
-21:17:13 <duck> they dont like anything that isnt written in their kampf</p>
-21:17:16 <duck> err</p>
-21:17:44  * duck moves to $nextitem and triggers mihi's breakpoint</p>
-21:17:47 <hypercubus> i figured tying the new channel in with support would legitimize it for </p>
-                       freenode</p>
-21:18:47 <duck> hypercubus: you might be surprised</p>
-21:19:04 <hypercubus> *cough* i admittedly didn't read all the policies...</p>
-21:19:24 <duck> it is russian roullete</p>
-21:19:39 <hypercubus> hmm, didn't think it would be quite that dire</p>
-21:19:52  * duck is being negative</p>
-21:19:54 <hypercubus> well i'll look into what we can do</p>
-21:20:09 <fvw> sorry, I must have missed something. Why would freenode kick us off?</p>
-21:20:21  * duck looks at the timeout counter for mihi's breakpoint</p>
-21:20:32 <duck> fvw: they focus on development channels</p>
-21:20:35 <mihi> ?</p>
-21:20:53 <mihi> duck: the breakpoint triggers on /^4).*/</p>
-21:21:01 <duck> mihi: but there is no #4</p>
-21:21:06 <fvw> so? i2p is soo alpha that right now even support is development.</p>
-21:21:11 <fvw> (and no, you may not quote me on that)</p>
-21:21:36 <duck> fvw: you might not be familiar with the types of discussion that did happen </p>
-                 on IIP</p>
-21:21:38 <hypercubus> yeah but we have *2* channels for it</p>
-21:21:45 <duck> and which will likely happen in #i2p channels</p>
-21:22:04 <duck> I am pretty sure that freenode does not appreciate it.</p>
-21:22:10 <Nightblade> i'm here now</p>
-21:22:49 <hypercubus> we'll donate a margarita machine to them or something</p>
-21:22:49 <mihi> duck: what do you refer to? the floods? or #cl? or what?</p>
-21:23:08 <fvw> discussions on IIP or discussions on #iip? I've never seen anything apart from </p>
-                devel and support on #iip. And discussions on IIP would move to I2P, not </p>
-                #i2p@freenode.</p>
-21:23:09 <duck> all kinds of non political correct talk</p>
-21:23:36 <fvw> there's margarita machines? Ooh, me want.</p>
-21:23:54 <duck> oh well</p>
-21:24:38 <hypercubus> shall we revisit 2)?</p>
-21:24:58 <duck> hypercubus: what do you have to add about the browser proxy?</p>
-21:25:18 <hypercubus> oops, number 1... since nightblade just graced us with his presence ;-)</p>
-21:25:33 <duck> Nightblade: we took the freedom to 'discuss' libsam</p>
-21:25:42 <Nightblade> Ok, i'll say a few lines</p>
-21:25:48 <hypercubus> but yeah i had something that wasn't brought up on the list about the </p>
-                       browser thing too now that i think about it</p>
-21:25:56 <duck> Nightblade: fvw told us that he might be able to help with some freebsd </p>
-                 testing</p>
-21:26:20 <fvw> I don't have a freebsd machine anymore but I have accounts on freebsd </p>
-                machines, give me test cases and I'd be happy to run them.</p>
-21:27:02 <Nightblade> I have started working on a C++ dht, which uses Libsam (C).  At this </p>
-                       point I have not gotten especially far although I've been working a lot </p>
-                       on it.  right now nodes in the dht can "ping" each other through a sam </p>
-                       data message</p>
-21:27:09 <Nightblade> in the process i found a couple minor bugs in libsam</p>
-21:27:18 <Nightblade> which i will post a new version of sometime in the future</p>
-21:27:51 <ugha_node> Nightblade: Could you please remove those 'strstr' calls from libsam? :)</p>
-21:27:52 <Nightblade> the test case is: try to compile it and report the errors to me</p>
-21:28:01 <Nightblade> what is wrong with strstr</p>
-21:28:21 <ugha_node> It's not meant to be used instead of strcmp.</p>
-21:28:38 <Nightblade> oh yeah, also I am going to port libsam to windows, but that is not in </p>
-                       any near future</p>
-21:29:07 <Nightblade> is there anything wrong with the way i am using it, besides aesthetics?</p>
-21:29:15 <Nightblade> you can send me changes or tell me what you'd rather do</p>
-21:29:19 <Nightblade> that just seemed the easiest way</p>
-21:29:21 <ugha_node> Nightblade: I didn't notice any.</p>
-21:29:32 <fvw> strcmp is more efficient than strstr ofcourse.</p>
-21:29:36 <ugha_node> But I just skimmed through it.</p>
-21:30:20 <ugha_node> fvw: You can occasionally exploit stuff which uses strstr instead of </p>
-                      strcmp, but that's not the case.</p>
-21:31:22 <Nightblade> yeah now i see some places where i can change it</p>
-21:31:28 <fvw> that too, but I'm assuming you'd have noted that. Well, actually, you'd have </p>
-                to use strncmp to prevent those exploits. But that's besides the point.</p>
-21:31:31 <Nightblade> i don't remember why i did it that way</p>
-21:31:57 <ugha_node> fvw: I agree.</p>
-21:32:27 <Nightblade> oh now i remember why</p>
-21:32:40 <Nightblade> it is a lazy way of not having to figure the length for strncmp</p>
-21:32:49 <duck> heh</p>
-21:32:52 <ugha_node> Nightblade: Heheh.</p>
-21:33:01 <fvw> use min(strlen(foo), sizeof(*foo))</p>
-21:33:04 <hypercubus> shall the spanking commence?</p>
-21:33:15 <fvw> I thought the oral sex came first? *ducks*</p>
-21:33:32 <fvw> right, next point I think. Hypercube had a comment about proxying?</p>
-21:33:38 <hypercubus> heh</p>
-21:33:54 <duck> bring it on!</p>
-21:34:03 <Nightblade> i will make the changes for the next version - change some of them at </p>
-                       least</p>
-21:34:25 <hypercubus> ok, well this had been discussed briefly in channel a few weeks back, </p>
-                       but i think it bears revisiting</p>
-21:34:48 <deer> * Sugadude volunteers to perform the oral sex.</p>
-21:34:59 <hypercubus> rather than adding TLD's to your browser's block list, or using the </p>
-                       proxy script, there's a third way</p>
-21:35:29 <hypercubus> which shouldn't have the same drawbacks as the other two approaches </p>
-                       anonymity-wise</p>
-21:36:17 <fvw> which I'll tell you for the cheap cheap price of $29.99? Spill it already!</p>
-21:36:27 <hypercubus> and that would be to have the eeproxy re-write incoming html pages to </p>
-                       embed the page in a frameset... </p>
-21:36:58 <hypercubus> the main frame would contain the requested HTTP content, the other </p>
-                       frame would serve as a control bar</p>
-21:37:13 <hypercubus> and would allow you to turn on/off proxying at will</p>
-21:37:40 <hypercubus> and will also alert you, perhaps via colored borders or some other kind </p>
-                       of alert, that you're browsing non-anonymously</p>
-21:37:54 <fvw> how are you going to prevent an i2p site (with javascript etc) from turning </p>
-                off anonimity?</p>
-21:37:59  * duck tries to apply jrandom-skill-level-of tolerance</p>
-21:37:59 <hypercubus> or that a link in an eepsite page leads to the RealWeb(tm)</p>
-21:38:04 <duck> cool! make it!</p>
-21:38:16 <fvw> you'll still have to do something fproxy-like, or make something </p>
-                non-browser-controlled for switching.</p>
-21:38:29 <ugha_node> fvw: Right.</p>
-21:39:10 <hypercubus> that's why i'm throwing this out here again, perhaps someone might have</p>
-                        some ideas about how to secure this</p>
-21:39:31 <hypercubus> but imo this is something that will be sorely needed for most i2p end </p>
-                       usrers</p>
-21:39:33 <hypercubus> *users</p>
-21:40:04 <hypercubus> because the TLD/proxy script/dedicated browser approaches are too much </p>
-                       to ask of your general net user</p>
-21:40:29 <fvw> In the long run, I think an fproxy workalike is the best idea. But that's </p>
-                definately not a priority imho, and I don't actually think browsing sites will </p>
-                be the i2p killer app.</p>
-21:40:42 <Sonium> What is the netDb anyway?</p>
-21:40:59 <duck> Sonium: database of known routers</p>
-21:41:10 <hypercubus> fproxy is too cumbersome for most users</p>
-21:41:32 <Sonium> doesn't such a database compromise annonymity?</p>
-21:41:39 <hypercubus> imo it's part of the reason freenet never caught on in the non-dev </p>
-                       community</p>
-21:41:41 <fvw> hypercube: not necessarily. proxy autoconfiguragion ("pac") can make it as </p>
-                simple as filling in a single value in your browser config. I think we </p>
-                shouldn't underestimate the fact that in the foreseeable future, all the i2p </p>
-                users will be at least slightly clueful computer-wise. (all evidence on </p>
-                freenet-support notwithstanding)</p>
-21:42:00 <ugha_node> Sonium: No, 'bad guys' could collect that information manually anyway.</p>
-21:42:21 <Sonium> but if NetDb is down i2p is down, right?</p>
-21:42:29 <fvw> hypercubus: Not really, I think the fact that it hasn't worked at all since </p>
-                early 0.5 is more to blame for that. </offtopic time="once again"></p>
+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)</p>
-21:42:58 <hypercubus> we already have pac, and even though it works spectacularly from a tech </p>
-                       standpoint, realistically it's not going to protect the anonymity of </p>
-                       the avg. jog</p>
-21:43:03 <hypercubus> *avg. joe</p>
-21:43:22 <ugha_node> fvw: Err.. Every router has its own netDb.</p>
-21:43:42 <duck> ok. I am about to pass out. be sure to *baff* the meeting closed after you </p>
-                 are done</p>
-21:43:52 <ugha_node> I2P has no central dependencies anymore.</p>
-21:44:07 <hypercubus> ok, well i just wanted to get this idea formally in the logs ;-)</p>
-21:44:30 <fvw> ugha_node: ok, a published netdb then. I don't actually run a node (yet), I'm </p>
-                not entirely up with the terminology.</p>
-21:44:34 <ugha_node> Hmm. Didn't mihi want to say something?</p>
-21:45:05  * fvw feeds duck coffee-flavoured chocolate to keep him up and running a little bit </p>
-          longer.</p>
-21:45:07 <mihi> no :)</p>
-21:45:21 <mihi> is duck a network device? ;)</p>
-21:45:25 <ugha_node> mihi: Btw, are you going to take the window size increase bounty?</p>
-21:45:28  * fvw feeds duck alcohol-flavoured chocolate to shut him down indefinately.</p>
-21:45:30 <hypercubus> in swedish</p>
-21:45:52 <mihi> ugha_node: what bounty?</p>
-21:46:00 <hypercubus> okay, then on to 5), rant-a-rama? ;-)</p>
-21:46:13 <ugha_node> mihi: http://www.i2p.net/node/view/224</p>
-21:46:27  * duck eats some of fvw's chocolate</p>
-21:47:16 <mihi> ugha_node: definitely no; sorry</p>
-21:47:36 <ugha_node> mihi: Uh, okay. :(</p>
-21:48:33  * mihi tried to hack up the "old" streaming api some time ago, but that one was too </p>
-          buggy...</p>
-21:48:53 <mihi> but it would imho be easier to fix that one instead of fixing mine...</p>
-21:49:21 <ugha_node> Heh.</p>
-21:49:42 <hypercubus> so modest</p>
-21:49:46 <mihi> since it already has some (broken) "reordering" support in it</p>
-21:50:49 <Sonium> is there a way to ask deer how many people are on the i2p-#i2p channel?</p>
-21:51:01 <duck> no</p>
-21:51:08 <hypercubus> nope, but i can add that to bogobot</p>
-21:51:08 <Sonium> :/</p>
-21:51:11 <Nightblade> !list</p>
-21:51:13 <deer> <duck> 10 ppl</p>
-21:51:13 <hypercubus> after i finish the installer ;-)</p>
-21:51:24 <Sonium> !list</p>
-21:51:32 <Sonium> o_O</p>
-21:51:35 <mihi> Sonium ;)</p>
-21:51:38 <ugha_node> This is not an fserv channel!</p>
-21:51:39 <Sonium> that was a trick!</p>
-21:51:40 <ugha_node> :)</p>
-21:51:41 <hypercubus> should be !who</p>
-21:51:44 <deer> <duck> ant duck identiguy Pseudonym ugha2p bogobot hirvox jrandom Sugadude </p>
-                 unknown</p>
-21:51:48 <cervantes> oop missed the meeting</p>
-21:51:57 <ugha_node> !list</p>
-21:52:01 <Nightblade> !who</p>
-21:52:11 <deer> <duck> !who-your-mom</p>
-21:52:17 <mihi> !who !has !the !list ?</p>
-21:52:21 <fvw> !yesletsallspamthechannelwithinoperativecommands</p>
-21:52:33 <Nightblade> !ban fvw!*@*</p>
-21:52:42 <mihi> !ban *!*@*</p>
-21:52:50 <hypercubus> i sense a gavel coming down</p>
-21:52:51 <duck> sounds like a good time to close it down</p>
-21:52:55 <Sonium> btw, you should also implement an !8 command like chanserv has</p>
-21:52:59 <fvw> right, now we have that settled, let's clo.. yes. that.</p>
-21:53:00  * hypercubus is psychic</p>
-21:53:05 <duck> *BAFF*</p>
-21:53:11 <Nightblade> !baff</p>
-21:53:12 <hypercubus> my hair, my hair</p>
-21:53:24  * fvw points at hypercube and laughs. Your hair! Your hair!</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/93.rst b/i2p2www/meetings/93.rst
new file mode 100644
index 00000000..d3cd3f58
--- /dev/null
+++ b/i2p2www/meetings/93.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, June 8, 2004 @ 21:02 UTC
+=========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/95.log b/i2p2www/meetings/95.log
index 3f07bbeb..5ac5f4d2 100644
--- a/i2p2www/meetings/95.log
+++ b/i2p2www/meetings/95.log
@@ -1,287 +1,282 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 95{% endblock %}
-{% block content %}<div class="irclog">
-14:00 < jrandom> 0) hi</p>
-14:00 < jrandom> 1) status update</p>
-14:00 < jrandom> 2) cvs HEAD</p>
-14:00 < jrandom> 3) 0.4</p>
-14:00 < jrandom> 4) 1.0</p>
-14:00 < jrandom> 5) other activities</p>
-14:00 < jrandom> 6) ???</p>
-14:00 < jrandom> 0) hi</p>
-14:00 < dm> 7) Profit!!</p>
-14:00 < mihi> hi</p>
-14:00 < cervantes> hello</p>
-14:00 < dm> hi</p>
-14:00 < fvw> hi dr nick</p>
-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</p>
-14:01 < jrandom> as we've done in the past, that contains the actual content - we get all meta here and discuss stuff</p>
-14:01  * dm is playing at home. WINK WINK WINK.</p>
-14:01 < jrandom> BrianR: this is where the LART comes in handy</p>
-14:02 < jrandom> anyway, jumping into 1) status update</p>
-14:02 < thecrypto> let's see if i can connect to an eepsite</p>
-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</p>
-14:03  * mihi fires up his router</p>
-14:03 < thecrypto> yah!</p>
-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</p>
-14:04 < dm> ok</p>
-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.</p>
-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)</p>
-14:05 < jrandom> ah wikked</p>
-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</p>
-14:06 < dm> Why don't operating system's have per-application bandwidth limiting built-in? Is it a hard task?</p>
-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?</p>
-14:06 < dm> All these projects wasting time implementing their own bandwidth limiting, seems silly.</p>
-14:06 < fvw> dm: Linux does it, as does freebsd no doubt.</p>
-14:07 < dm> Do they?</p>
-14:07 < cervantes> netlimiter on windoze does it</p>
-14:07 < BrianR> dm: It's not a hard task. There's lots of system level bandwidth limiting stuff available, for 'doze, linux, *bsd...</p>
-14:07 < dm> Makes sense to put it in the OS if you ask me.</p>
-14:07 < fvw> dm iptables marking + tc under linux; Using it right now, works like a charm.</p>
-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)</p>
-14:07 < dm> But anyway...</p>
-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</p>
-14:08 < jrandom> exactly</p>
-14:08 < dm> That's a different problem.</p>
-14:08 < jrandom> with bandwidth limiting within i2p, we know when we're saturating our limit and can refuse to participate in tunnels (etc)</p>
-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.</p>
-14:08 < fvw> actually, best would be to have the OS give proper feedback; But that's not relevant for i2p right now.</p>
-14:09 < jrandom> true fvw, once we integrate i2p with tun/tap ;)</p>
-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..</p>
-14:09 < dm> Put a bounty on patching windows to have per-application bandwidth limiting. Thanks.</p>
-14:09 < jrandom> heh</p>
-14:09 < fvw> "my stuff isn't arriving" and "this connection is being throttled now" are two entirely different things.</p>
-14:09 < fvw> they sometimes overlap ofcourse.</p>
-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)</p>
-14:11 < jrandom> ok does anyone else have any network status related things to bring up?</p>
-14:12 < BrianR> Oh.. That IRC connection monitoring thing..</p>
-14:12 < duckie> I appologize for updating to cvs</p>
-14:12 < jrandom> hehe</p>
-14:12 < BrianR> Is there a MRTG graph of that or logs or something somewhere?</p>
-14:12 < jrandom> bogobot right?  duck.i2p/bogo/ iirc?</p>
-14:13 < duckie> something like that</p>
-14:13 < jrandom> (its linked to off duck.i2p, my routers are down atm so i cant check)</p>
-14:13 < duckie> linked to on http://duck.i2p/ uder the stats section</p>
-14:13 < duckie> http://duck.i2p/bogobotlogs/</p>
-14:14 < BrianR> it might be useful to extend that thing to act as a general reachability survey tool..</p>
-14:15 < dm> You guys type reaaaaaaaaaaaaaaaally slowly.</p>
-14:15 < deer> <cervantes> hypercubus has some enhancements on the backburner, but he's pretty busy with installer stuff atm</p>
-14:16 < jrandom> BrianR: bogobot is just for passive irc tracking, but someone could modify i2ptunnel's ping command to support periodic checking?</p>
-14:16 < jrandom> or someone could whip up a perl/SAM script ;)</p>
-14:16 < BrianR> maybe some sort of script that produces a MRTG graph of endpoint reachability....</p>
-14:16 < BrianR> jrandom: speaking of perl/sam, bring that up again when we get to the appropriate number in the agenda</p>
-14:16 < duckie> doesnt the heartbeat thing do that?</p>
-14:17 < BrianR> If it does, I couldn't make it work :(</p>
-14:17 < jrandom> kind of - heartbeat tests heartbeat servers, not generic apps</p>
-14:18 < BrianR> Yes... Like I want to see if I can successfully do a "GET /" on duck.i2p, and how long it took.</p>
-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</p>
-14:18 < Nightblade> pingflood too</p>
-14:18 < dm> Is there a limit on GET strings?</p>
-14:18 < dm> like if you have a really long URL, because of cgi parameters?</p>
-14:19 < cervantes> 2047 characters iirc</p>
-14:19 < jrandom> that wouldnt be too hard to put together</p>
-14:19 < BrianR> dm: Depends on the web server... I think the RFC also specifies a minimum which must be suported.</p>
-14:19 < jrandom> (er, an http tester)</p>
-14:19 < dm> cervantes: thanks</p>
-14:19 < dm> (just realized it might affect something I've been working on)</p>
-14:20 < cervantes> you run into 2 problems, webserver support and client support</p>
-14:20 < BrianR> have we stumbled off topic?</p>
-14:20 < cervantes> both IE and Mozilla are 2047</p>
-14:20 < cervantes> eer yep :)</p>
-14:21 < dm> I got my answer, we can move on :)</p>
-14:21 < jrandom> ok, i think that covers 1), now briefly to 2) cvs HEAD</p>
-14:21 < jrandom> there's a nasty bug in there currently, and i apologize for not fixing it sooner</p>
-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)</p>
-14:22 < jrandom> anyway, 'nuff 'bout that</p>
-14:23 < jrandom> jumping forward to 3) 0.4</p>
-14:23 < jrandom> the email has my viewpoint / rational for the release - anyone have any concerns / questions / ideas / suggestions?</p>
-14:24 < Nightblade> looks good to me</p>
-14:24 < duckie> how does it change the time estimates?</p>
-14:24  * fvw nods. Sane and everything.</p>
-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</p>
-14:25 < jrandom> i dont think it'll change the 1.0 dates, just moving things around before it</p>
-14:26 < jrandom> the sim has shown our main problem with tunnel diversification can be easily remedied by active peer testing</p>
-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</p>
-14:27 < jrandom> (when in fact lots of shit was just plain broken, causing the overhead)</p>
-14:27 < deer> <cervantes> what does active peer testing involve?</p>
-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</p>
-14:29 < jrandom> (and if that intersection is too small, extend it to the 'not failing' set)</p>
-14:29 < jrandom> i dont know how many tunnels or peers to test yet, we'll probably keep that as a tunable parameter</p>
-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</p>
-14:30 < jrandom> (which may be due to them being shitty, or more likely due to them not being tested)</p>
-14:31 < jrandom> ok, anything else on 0.4?  or should we move on to 4) 1.0?</p>
-14:32 < duckie> yes</p>
-14:33 < jrandom> 4) 1.0</p>
-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</p>
-14:34 < jrandom> that said, anyone have any concerns / ideas / suggestions/ questions wrt whats in the mail?</p>
-14:35 < dm> The rate at which the versioning is increasing would indeed indicate that it is an asymptotically approached 1.0</p>
-14:36 < dm> We're gonna need some big jumps!</p>
-14:36 < jrandom> 0.4--> 1.0</p>
-14:36 < dm> Sweeeeeeeet....</p>
-14:36 < jrandom> and we're only a few weeks from 0.4</p>
-14:37 < jrandom> but, of course, we could use some help to get things moving faster :)</p>
-14:37 < dm> Are we happy with stability then?</p>
-14:37 < jrandom> no, stability right now sucks</p>
-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</p>
-14:37 < dm> Okay, haven't been following closely.</p>
-14:38 < cervantes> such as DHT and datagrams etc</p>
-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.</p>
-14:38 < cervantes> right</p>
-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@</p>
-14:39 < cervantes> private messaging is just a small hop from the syndicated address book too</p>
-14:39 < jrandom> right, its all doable</p>
-14:40 < cervantes> live streaming cam girl desktop might take longer...</p>
-14:40 -!- Irssi: #i2p: Total of 21 nicks [0 ops, 0 halfops, 0 voices, 21 normal]</p>
-14:40 < jrandom> heh</p>
-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 -</p>
-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</p>
-14:42 < cervantes> ah I meant to enquire earlier about enhancing the console GUI too</p>
-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)</p>
-14:42 < jrandom> that we'll want for the 0.4 release, and will be jsp/servlet driven</p>
-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</p>
-14:43 < Nightblade> console GUI?  what is that - SVGALIB? :)</p>
-14:43 < jrandom> heh</p>
-14:43 < mihi> Nightblade: TWIN / curses</p>
-14:43 < cervantes> is the data set the same or are there new and improved stats for 0.4</p>
-14:44 < dm> I want a console gui in WIN32/MFC</p>
-14:44 < Nightblade> the http console on 7655 right</p>
-14:44 < cervantes> ie the duration that elephants stay on the moon, and whether they return freuqently</p>
-14:44 < cervantes> yup</p>
-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</p>
-14:45 < jrandom> (e.g. no one cares what the base64 of a routerIdentity's public key is)</p>
-14:45 < cervantes> although I suggest that info should still be available</p>
-14:46 < jrandom> yeah, i think we may keep the existing console as an option - no need to throw it away</p>
-14:46 < jrandom> (but it'd be something like http://localhost:7655/uglyConsole/)</p>
-14:46 < cervantes> ./forlynxusers/</p>
-14:47 < jrandom> the new admin console should work for lynx users too</p>
-14:47 < dm> Does anyone really use lynx?</p>
-14:47 < cervantes> eeew cross browser compatibility</p>
-14:47 < jrandom> i do</p>
-14:47 < jrandom> (at times)</p>
-14:47 < dm> but.... why?</p>
-14:47 < fvw> for things like brief config edits, definately.</p>
-14:47 < cervantes> dm: if you're stuck at a command prompt you don't have much choice</p>
-14:47 < fvw> it's quick and you don't need X</p>
-14:48 < Nightblade> i use it for web browsing on headless servers</p>
-14:48 < deer> <Pseudonym> I use links browser</p>
-14:48 < jrandom> well, yeah, links is preferable to lynx</p>
-14:48 < mihi> anyone using w3m?</p>
-14:48 < dm> I use INTERNET EXPLORER FROM MICROSOFT</p>
-14:48 < dm> It's quite cool.</p>
-14:48 < jrandom> good point - anything else wrt i2p 1.0?</p>
-14:49 < dm> Won the browser war of 1992-1998</p>
-14:49 < jrandom> or moving on to 5) other activites?</p>
-14:49 < dm> 3 medals of honor.</p>
-14:49 < Nightblade> yes</p>
-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</p>
-14:49 < Nightblade> I am going to also upload Nickster's threading library</p>
-14:49 < jrandom> awesome!/doh!</p>
-14:50 < jrandom> nice!</p>
-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</p>
-14:50 < jrandom> once 0.3.1.5 is out, i'll start running the cvs server on i2p as well</p>
-14:50 < jrandom> cool</p>
-14:51 < jrandom> (so nickster will be able to make edits/updates to his code in cvs without exposing his ip)</p>
-14:51 < jrandom> whats new in the next rev of libsam?</p>
-14:51 < Nightblade> some fixes to datagram send/receive which were broken</p>
-14:51 < Nightblade> and some other stuff i don't remember</p>
-14:51 < Nightblade> it iwll be in the changelog</p>
-14:51 < jrandom> cool, sounds good</p>
-14:52 < jrandom> btw, if you want a mailing list for libsam (-announce,-dev,-users,etc) lemmie know</p>
-14:52 < jrandom> (but posting on i2p@i2p is fine too)</p>
-14:52 < Nightblade> overkill</p>
-14:52 < jrandom> hehe</p>
-14:53 < jrandom> yeah prolly</p>
-14:53 < cervantes> he can have a section in i2pforum</p>
-14:53  * cervantes moves smoothly onto his agenda</p>
-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</p>
-14:53 < Nightblade> cervantes: there is already an application development forum or somethihng like that iirc</p>
-14:53 < Nightblade> also Connelly needs an account on i2p.net if someone has gotten him one yet</p>
-14:53 < cervantes> specifically in relation to i2p?</p>
-14:54 < Nightblade> http://www.i2p.net/forum/3</p>
-14:54 < jrandom> oh, i havent added an account for connelly, i'll chat with 'im next time i see him</p>
-14:54 < fvw> dang, got to run. See you all next week, keep up the good work.</p>
-14:54 < jrandom> ugh, yeah, i dont know about the www.i2p.net/forum/s</p>
-14:54 < cervantes> ah...drupal...</p>
-14:55 < jrandom> cool fvw, glad you could make it</p>
-14:56 < cervantes> the i2pforum is pretty much set up</p>
-14:56 < cervantes> it basically just needs content/users to fill it :)</p>
-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</p>
-14:57 < jrandom> cool cervantes - is that as an eepsite, website, or both?</p>
-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</p>
-14:57 < cervantes> it's both</p>
-14:58 < cervantes> currently I have the i2p tunnel offline while my router is so unstable</p>
-14:58 < jrandom> cant say i blame you :)</p>
-14:58 < Nightblade> what is the url</p>
-14:58 < cervantes> but people can start playing on outweb</p>
-14:59 < cervantes> currenlty you'll have to add an entry to /etc/hosts c:/windows/system32/drivers/etc/hosts</p>
-14:59 < cervantes> 212.113.22.104 i2pforum.cervantes.not2p</p>
-14:59 < jrandom> heh</p>
-15:00 < cervantes> I'll configure it with a proper hostname soon</p>
-15:00 < cervantes> or if someone wants to add a subdomain pointer to the php.net domain record...that would be better</p>
-15:00 < jrandom> lemmie know if you want something under the i2p.net domain or if you're going with another domain thats cool</p>
-15:00 < cervantes> blah</p>
-15:00 < cervantes> i2p.net</p>
-15:00 < cervantes> <-- php on the brain</p>
-15:01 < jrandom> do you want that to be e.g. forum.i2p.net?</p>
-15:01 < cervantes> that would be cool ;-)</p>
-15:01 < jrandom> w3rd, i'll update the records tonight</p>
-15:01 < cervantes> I've tweaked standard phpbb2 code so it doesn't require a valid email to become a member</p>
-15:01 < dm> "The site you requested is no longer hosted here"</p>
-15:02 < cervantes> if you forget your pass then you have to contact an admin</p>
-15:02 < cervantes> dm: did you enter that into your hosts file or are you just browsing to the IP</p>
-15:03 < dm>                                   Invalid URI in request GET i2pforum.cervantes.</p>
-15:03 < dm> not2p/<P></p>
+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.</p>
-15:04 < jrandom> i did it through telnet just now.  works fine.</p>
-15:04 < dm> hmm forgot the HTTP 1.1 I think.</p>
-15:04 < jrandom> GET / HTTP/1.1\nHost: i2pforum.cervantes.not2p\n\n</p>
-15:04 < jrandom> anyway</p>
-15:04 < jrandom> BrianR: ping</p>
-15:05 < dm> That worked. Your telnetting skills are sharp, young one.</p>
-15:07 -!- Irssi: #i2p: Total of 19 nicks [0 ops, 0 halfops, 0 voices, 19 normal]</p>
-15:07 < jrandom> ok, anyone else working on i2p related projects they want to discuss?</p>
-15:07 < jrandom> if not, 6) ???</p>
-15:07 < dm> cum!</p>
-15:07  * wern put a hand in the air</p>
-15:07 < jrandom> hi^2, que tal?</p>
-15:08  * jrandom calls on wilde</p>
-15:08 -!- wern is now known as wilde</p>
-15:08 < wilde> I just want to thank our new sponsors, cervantes and hypercubus</p>
-15:08 < wilde> :)</p>
-15:09 < wilde> we got two generous donations to the general fund</p>
-15:09 < cervantes> wilde: did they convert ok?</p>
-15:09 < dm> how much?</p>
-15:09 < wilde> cervantes: will exchange them tomorrow</p>
-15:09 < cervantes> ah</p>
-15:09 < wilde> (hopefully)</p>
-15:10 < cervantes> so there still might be a runner-up prize ;-)</p>
-15:10 < jrandom> awesome, thanks cervantes & hypercubus :)</p>
-15:10 < cervantes> heh...well save praise until the money is in the bank I think ;-)</p>
-15:11 < dm> twas a good meeting. I'm off to bed.</p>
-15:11 < dm> Nite!</p>
-15:11 < jrandom> 'night dm</p>
-15:11 < wilde> yeah, I'll do the full praising next time</p>
-15:11 < jrandom> ok, anything else to add wilde, or someone else?</p>
-15:11 < wilde> yeah</p>
-15:12 < wilde> I'll take the i2p.net site down tomorrow for a while (intentionally this time ;)</p>
-15:12 < wilde> to switch servers</p>
-15:12 < jrandom> heh ok cool</p>
-15:12 < wilde> hold on to your posts, they may disappear</p>
-15:12 < jrandom> will we have the same IP, or should I update the records?</p>
-15:12 < dm> can you make it seamless?</p>
-15:12 < wilde> if you post tomorrow that is</p>
-15:13 < wilde> dm: no way ;)</p>
-15:13 < wilde> not me</p>
-15:13 < dm> okay.</p>
-15:13 < wilde> jrandom: same IP</p>
-15:13 < jrandom> ok cool</p>
-15:13 < jrandom> wilde++</p>
-15:13 < wilde> over and out</p>
-15:14 < jrandom> ok, anyone else have something they'd like to discuss?</p>
-15:14  * cervantes puts on his metal "ming the merciless" skullcap</p>
-15:14 < jrandom> in that case</p>
-15:15  * jrandom winds up</p>
-15:15  * jrandom *baf*s cervantes on the head, closing the meeting</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/95.rst b/i2p2www/meetings/95.rst
new file mode 100644
index 00000000..4286de2a
--- /dev/null
+++ b/i2p2www/meetings/95.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, DATE
+=============================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------
diff --git a/i2p2www/meetings/99.log b/i2p2www/meetings/99.log
index 24d48f39..b2ed0241 100644
--- a/i2p2www/meetings/99.log
+++ b/i2p2www/meetings/99.log
@@ -1,203 +1,197 @@
-{% extends "_layout.html" %}
-{% block title %}I2P Development Meeting 99{% endblock %}
-{% block content %}<h3>I2P dev meeting, July 20 @ 21:00 GMT</h3>
-<div class="irclog">
-14:05 < jrandom> 0) hi</p>
-14:05 < jrandom> 1) 0.3.2.3, 0.3.3, and the roadmap</p>
-14:05 < jrandom> 2) s/reliability/capacity/g</p>
-14:05 < jrandom> 3) website updates</p>
-14:05 < jrandom> 4) attacks and defenses</p>
-14:05 < jrandom> 5) ???</p>
-14:05 < jrandom> 0) hi</p>
-14:05  * jrandom waves </p>
-14:05 < jrandom> weekly status notes up @ http://dev.i2p.net/pipermail/i2p/2004-July/000358.html</p>
-14:06 < jrandom> swingin right into 1) 0.3.2.3, 0.3.3, and the roadmap</p>
-14:07 < jrandom> (while y'all read ahead, i assume ;)</p>
-14:07 < jrandom> the 0.3.2.3 release is out there and seems to be doing well</p>
-14:07 < jrandom> what are the main pain points people are seeing?</p>
-14:08 < deer> <Nightblade> no trouble at all</p>
-14:08 < deer> <duck> 4d uptime with no problems</p>
-14:08 < jrandom> hmm, word</p>
-14:08 < deer> <duck> for some irc doesnt seem too stable</p>
-14:08 < deer> <duck> like kaji getting kicked ever minute</p>
-14:08 < deer> <duck> but thats nothing new</p>
-14:09 < jrandom> yeah that happens to him on the freenode network too, so i'm not sure what to blame there</p>
-14:09 < deer> <duck> yeah</p>
-14:09 < deer> <duck> connelly had some bad downloads afaik</p>
-14:10 < deer> <duck> but you dont hear me complainin'</p>
-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</p>
-14:10 < jrandom> especially while leeching books from alexandria</p>
-14:10 < jrandom> (well, not especially, but thats the only site i leech from)</p>
-14:11 < deer> <duck> :)</p>
-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</p>
-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)</p>
-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</p>
-14:13 < jrandom> afaik hypercubus' installer is pretty much good to go</p>
-14:13 < jrandom> (though i threw some new work on him today ;)</p>
-14:13 < deer> <duck> featurecreep++</p>
-14:14 < jrandom> keeps people on their toes :)</p>
-14:14 < jrandom> (but c'mon, everyone hates downloading all the jars seperately for upgrades)</p>
-14:14 < deer> <duck> yes, that is my biggest problem with upgrading</p>
-14:14 < deer> <duck> (though I use cvs)</p>
-14:14 < deer> <duck> but it would be if I didn't</p>
-14:15 < jrandom> heh</p>
-14:15 < mihi> jrandom: just tar all of them -> 1 download ;)</p>
-14:15 < jrandom> that'd be simple enough, and leave updgrade.sh/upgrade.bat == jar xf upgrade.jar</p>
-14:16 < jrandom> (after a wget-esque call)</p>
-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</p>
-14:17 < jrandom> anyway, yeah, as y'all may have noticed, our schedule isn't quite what it was before </p>
-14:17 < jrandom> the roadmap has been updated and eeeellloooonnnggaattteedd</p>
-14:18 < mihi> jjrraannddoomm::  cchheecckk yyoouurr dduupplleexx sswwiittcchh</p>
-14:18 < deer> <Nightblade> hah</p>
-14:18 < jrandom> heh</p>
-14:18  * mihi made a mistake... who spots it first?</p>
-14:19 < jrandom> (\n\n)</p>
-14:19 < jrandom> but anyway</p>
-14:19 < mihi> okay, another one ;)</p>
-14:19 < duck> (no double spaces)</p>
-14:19 < mihi> duck++</p>
-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</p>
-14:20 < jrandom> (and, of course, as always the roadmap is subject to change if more people get involved :)</p>
-14:21 < modulus> maybe one day I will, after I learn java, but i2p doesn't sound like a project for a novice.</p>
-14:21 < deer> <Sandworm> yeah, it'll take longer :)</p>
-14:21 < deer> * duck expects some more slips along the road</p>
-14:21 < modulus> :-)</p>
-14:22 < deer> * duck can barely call it slips, look at the impressive table on http://www.i2p.net/redesign/announcements</p>
-14:22 < jrandom> slips may happen of course, but i think the milestones left are all pretty doable</p>
-14:22 < jrandom> yeah, thanks for showing that i have no life duck ;)</p>
-14:22 < deer> <duck> this is your life</p>
-14:22 < modulus> so, when's 1.0 out? :-)</p>
-14:22 < deer> <duck> be proud of it</p>
-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</p>
-14:23 < modulus> probably rather boring parts though, no?</p>
-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</p>
-14:24 < duck> (website updates)</p>
-14:24 < modulus> hmm, sounds cool.</p>
-14:24 < jrandom> (aka simple client apps that can be anonymous)</p>
-14:24 < jrandom> and of course web updates ;)</p>
-14:25 < modulus> what's this web updates deal?</p>
-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)</p>
-14:25 < cat-a-puss> Where does myi2p fit into all that?</p>
-14:25 < modulus> ah ah</p>
-14:26 < jrandom> cat-a-puss: http://www.i2p.net/redesign/myi2p :)</p>
-14:26 < modulus> methinks myi2p isn't a priority right now...</p>
-14:26 < jrandom> (i just wrote a brief page about it a few hours back)</p>
-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)</p>
-14:28 < modulus> hmm, i could write a global naming ap :-)</p>
-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</p>
-14:28 < jrandom> (per the roadmap, slated for november)</p>
-14:28 < jrandom> yes, you certainly could</p>
-14:28 < modulus> something simpler than DNS, with authentication and delegation of TLD's</p>
-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</p>
-14:29 < modulus> yep</p>
-14:29 < jrandom> so, get coding :)</p>
-14:29 < modulus> I'll start tomorrow. beat me up if i'm on other things ;-)</p>
-14:29 < jrandom> hehe cool, shall do</p>
-14:29 < jrandom> ok, moving on to 2) s/reliability/capacity/g</p>
-14:29 < duck> small questio on the site:</p>
-14:29 < duck> oh wait</p>
-14:29 < duck> thats 3</p>
-14:29 < duck> sorry</p>
-14:29 < jrandom> sure, sup?</p>
-14:30 < jrandom> ah, 'k</p>
-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</p>
-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))</p>
-14:31 < jrandom> and no more negative values :)</p>
-14:31 < modulus> :)</p>
-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</p>
-14:32 < cat-a-puss> d</p>
-14:32 < cat-a-puss> <modulus></p>
-14:32 < cat-a-puss> oops</p>
-14:33 < duck> suggesting against updating cvs?</p>
-14:33 < cat-a-puss> to do dns look at a cache of http://www.levien.com/thesis/compact.pdf</p>
-14:33 < jrandom> nope, cvs is fairly stable atm</p>
-14:33 < jrandom> (but as always, be prepared to fall back if some nastiness hits)</p>
-14:35 < jrandom> looks cool cat-a-puss, thanks</p>
-14:35 < cat-a-puss> (I have a copy of the origional if anyone wants it)</p>
-14:36 < jrandom> the google cache kind of garbles the images a bit, so if you have the raw pdf that'd be great</p>
-14:36 < jrandom> anyway, we're sliding a bit off topic for the moment (but we can get back to this)</p>
-14:37 < jrandom> that's about it for the reliability/capacity switch, so moving on to 3) website updates</p>
-14:37 < jrandom> duck: you had something you wanted to bring up?</p>
-14:38 < jrandom> while duck prepares his notes, perhaps anyone has any ideas/suggestions/concerns wrt the items posted in the email?</p>
-14:39 < deer> <Nightblade> the website looks  good</p>
-14:39 < jrandom> yeah, i like the new nav and the site layout is quite clean</p>
-14:40 < deer> <Nightblade> easier to find stuff</p>
-14:40 < cervantes> _much_ easier to find stuff</p>
-14:40 < duck> first of all I want to thank our user advocate protocol for becoming useful :)</p>
-14:40 < jrandom> heh</p>
-14:40 < duck> he had some good suggestions and he did just start</p>
-14:40 < cervantes> hip hip horray!</p>
-14:40 < jrandom> (hear hear!)</p>
-14:41 < duck> next I think that there is barely a reason not to put the redesign up for real</p>
-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 </p>
-14:42 < jrandom> i just want it to go live with all links working (and all pages that arent working)</p>
-14:43 < jrandom> there will of course be further updates after it goes life ;)</p>
-14:43 < jrandom> er, live</p>
-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</p>
-14:44 < cervantes> coolio</p>
-14:44 < jrandom> thoughts duck?  can the menu.php thingy handle non-page nav entries?  </p>
-14:44  * cervantes checks his inbox for referal points</p>
-14:45 < jrandom> (or would it be too much effort to mod that in?)</p>
-14:45 < jrandom> hehe cervantes, that should be on the way</p>
-14:45 < cervantes> ;-)</p>
-14:45 < cervantes> ah the old "cheque's in the post" gambit</p>
-14:47 < duck> sorry; doing some other work in the meanwhile.</p>
-14:47 < duck> ok; yes possible to make it nav section title only</p>
-14:47 < jrandom> np, we can move on and come back to it later if you'd prefer</p>
-14:47 < jrandom> ok cool</p>
-14:47 < jrandom> (duck++)</p>
-14:48 < jrandom> ok, any other website related stuff?  </p>
-14:48 < duck> with your suggestion it sounds ready for up.</p>
-14:48 < jrandom> if not, we can move on to 4) attacks and defenses</p>
-14:48 < duck> .</p>
-14:48 < jrandom> word</p>
-14:49 < jrandom> ok, i'm assuming y'all read the mailing list and have seen connelly's posts and the various replies</p>
-14:50 < cervantes> he's been busy :)</p>
-14:50 < cervantes> (almost as much as proto)</p>
-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</p>
-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</p>
-14:50 < Connelly> the encryption pretty much screws over any non-aggressive attacks</p>
-14:51 < jrandom> that is the hope</p>
-14:51 < jrandom> plus with i2p 2.0 and 3.0 capabilities, defenses for attacks by govt scale adversaries will be possible</p>
-14:51 < Connelly> course in practice there will be security holes to patch</p>
-14:52  * jrandom still needs to write up some docs as to how the 3.0 delays will prevent segmentation attacks</p>
-14:52 < jrandom> certainly connelly</p>
-14:54 < jrandom> ok, if there's nothing more along those lines, i think thats all i've got</p>
-14:54 < jrandom> so 5) ???</p>
-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</p>
-14:55 < jrandom> thats posted up @ http://dev.i2p.net/~jrandom/4daybandwidth.png</p>
-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'</p>
-14:56 < duck> (nolink property implemented for the site)</p>
-14:56 < jrandom> (e.g. load distributed over the fast reliable peers, slow peers avoided, etc)</p>
-14:56 < jrandom> w00t</p>
-14:56 < Connelly> a log plot of bandwidth/user vs network size would be nice</p>
-14:57 < Connelly> so you can say 'yeah, it really scales'</p>
-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]</p>
-14:58 < jrandom> but yeah, I agree, we need some docs describing how i2p scales</p>
-14:58 < Connelly> well for kademlia ... is that in your sim?</p>
-14:58 < jrandom> yeah, the sim is actually the full blown router code, all run in a single JVM</p>
-14:58 < jrandom> i'm running it even with the full TCP connections instead of the VM comm system too</p>
-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</p>
-14:59 < jrandom> (so there are no needs for subsequent netDb lookups)</p>
-15:00 < cervantes> vl07 and onb0 are the choked routers?</p>
-15:00 < jrandom> but yeah, we need a simulation to demonstrate how the netDb itself scales</p>
-15:01 < jrandom> cevantes: 0jvf and onb0</p>
-15:01 < cervantes> what accounts for vl07's dive after a days uptime?</p>
-15:02 < cervantes> seems to cross over with 00u0</p>
-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</p>
-15:04 < Connelly> do your designations of 'fast and reliable', 'slow' etc recover from large values?</p>
-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</p>
-15:04 < jrandom> yes, the rankings use the median now, not the mean, plus there is a fiarly fast decay on the data</p>
-15:05 < jrandom> s/fiarly/fairly/</p>
-15:05 < Connelly> so if i make you think my reliability is 1000000000, you can recover when i start dropping messages</p>
-15:06 < jrandom> certainly - if you 'fail' i immediately stop asking you to do things and decrease your ranking</p>
-15:06 < jrandom> the new "capacity" calculation in turn is quite sensitive to those types of changes</p>
-15:06 < jrandom> (speed is kind of hard to fake too, as all speed ranks are actual measured values)</p>
-15:07 < jrandom> ((as was the reliability, and as is the capacity calc))</p>
-15:09 < jrandom> ok, anyone else have anything they want to bring up?</p>
-15:10 < deer> * jrandomi2p suggests the *baf*er</p>
-15:11  * jrandom concurs</p>
-15:11  * jrandom winds up</p>
-15:11  * jrandom *baf*s the meeting closed</p>
-</div>
-{% endblock %}
\ No newline at end of file
+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/99.rst b/i2p2www/meetings/99.rst
new file mode 100644
index 00000000..63bc9cd9
--- /dev/null
+++ b/i2p2www/meetings/99.rst
@@ -0,0 +1,10 @@
+I2P dev meeting, July 20, 2004 @ 21:00 GMT
+==========================================
+
+Quick recap
+-----------
+
+TODO
+
+Full IRC Log
+------------

From 94cb7205c877b49c91ef22b2c9fe1eaa6110d909 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 03:24:12 +0000
Subject: [PATCH 34/75] Template and tweaks -> meetings now display. TODO:
 properly render .rst

---
 i2p2www/meetings/208.rst         | 2 --
 i2p2www/pages/global/lang.html   | 1 +
 i2p2www/pages/meetings/show.html | 8 ++++++++
 3 files changed, 9 insertions(+), 2 deletions(-)
 create mode 100644 i2p2www/pages/meetings/show.html

diff --git a/i2p2www/meetings/208.rst b/i2p2www/meetings/208.rst
index 9543338a..b83fd332 100644
--- a/i2p2www/meetings/208.rst
+++ b/i2p2www/meetings/208.rst
@@ -20,7 +20,6 @@ Quick recap
 *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:*
@@ -33,7 +32,6 @@ Quick recap
   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/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html
index c62ab667..c421597f 100644
--- a/i2p2www/pages/global/lang.html
+++ b/i2p2www/pages/global/lang.html
@@ -1,5 +1,6 @@
 {%- macro change_lang(lang) -%}
 {%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
+{%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }}
 {%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
 {%- else -%}{{ url_for('site_show', lang=lang) }}
 {%- endif -%}
diff --git a/i2p2www/pages/meetings/show.html b/i2p2www/pages/meetings/show.html
new file mode 100644
index 00000000..0dcca0d3
--- /dev/null
+++ b/i2p2www/pages/meetings/show.html
@@ -0,0 +1,8 @@
+{% extends "global/layout.html" %}
+{% block title %}Meeting {{ id }}{% endblock %}
+{% block content %}
+{{ header }}
+<pre>
+{{ log }}
+</pre>
+{% endblock %}

From f8b1cbffbb532e39c4e7c1dd12e5052bac75d3f0 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 03:42:24 +0000
Subject: [PATCH 35/75] Dynamically generate meetings index (as for blog index)

---
 i2p2www/__init__.py               |  26 ++++-
 i2p2www/pages/meetings/index.html | 178 +-----------------------------
 runserver.py                      |   2 +-
 3 files changed, 29 insertions(+), 177 deletions(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index be03a629..6ba06a56 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -129,13 +129,37 @@ def site_show(page='index'):
     return render_template(name, page=page)
 
 
+########################
+# Meeting helper methods
+
+def get_meetings_index():
+    """
+    Returns reverse-sorted list of valid ids
+    """
+    # list of ids
+    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()
+    return meetings
+
+
 ##################
 # Meeting handlers
 
 # Meeting index
 @app.route('/<string:lang>/meetings/')
 def meetings_index():
-    return render_template('meetings/index.html')
+    meetings = get_meetings_index()
+
+    return render_template('meetings/index.html', meetings=meetings)
 
 # Renderer for specific meetings
 @app.route('/<string:lang>/meetings/<int:id>')
diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
index b8effc6b..c7172051 100644
--- a/i2p2www/pages/meetings/index.html
+++ b/i2p2www/pages/meetings/index.html
@@ -7,180 +7,8 @@ If you have something to discuss, please find the developers on IRC in #i2p-dev.
 <a href="statusnotes.html">Status updates</a> from developers are also available.
 </p><div class="underline"></div>
 <ul class="infolist">
-<li><a href="meeting208">Meeting 208</a> - September 8, 2010</li>
-<li><a href="meeting207">Meeting 207</a> - February 10, 2009</li>
-<li><a href="meeting206">Meeting 206</a> - April 10, 2007</li>
-<li><a href="meeting205">Meeting 205</a> - April 3, 2007</li>
-<li><a href="meeting204">Meeting 204</a> - March 27, 2007</li>
-<li><a href="meeting203">Meeting 203</a> - March 20, 2007</li>
-<li><a href="meeting202">Meeting 202</a> - March 13, 2007</li>
-<li><a href="meeting201">Meeting 201</a> - February 20, 2007</li>
-<li><a href="meeting200">Meeting 200</a> - February 13, 2007</li>
-<li><a href="meeting199">Meeting 199</a> - February 6, 2007</li>
-<li><a href="meeting198">Meeting 198</a> - January 30, 2007</li>
-<li><a href="meeting197">Meeting 197</a> - January 16, 2007</li>
-<li><a href="meeting196">Meeting 196</a> - January 9, 2007</li>
-<li><a href="meeting195">Meeting 195</a> - January 2, 2007</li>
-<li><a href="meeting194">Meeting 194</a> - December 26, 2006</li>
-<li><a href="meeting193">Meeting 193</a> - December 12, 2006</li>
-<li><a href="meeting192">Meeting 192</a> - December 05, 2006</li>
-<li><a href="meeting191">Meeting 191</a> - November 28, 2006</li>
-<li><a href="meeting190">Meeting 190</a> - November 21, 2006</li>
-<li><a href="meeting189">Meeting 189</a> - November 14, 2006</li>
-<li><a href="meeting188">Meeting 188</a> - November 7, 2006</li>
-<li><a href="meeting187">Meeting 187</a> - October 31, 2006</li>
-<li><a href="meeting186">Meeting 186</a> - October 24, 2006</li>
-<li><a href="meeting185">Meeting 185</a> - October 17, 2006</li>
-<li><a href="meeting184">Meeting 184</a> - September 12, 2006</li>
-<li><a href="meeting183">Meeting 183</a> - August 1, 2006</li>
-<li><a href="meeting182">Meeting 182</a> - June 13, 2006</li>
-<li><a href="meeting181">Meeting 181</a> - May 30, 2006</li>
-<li><a href="meeting180">Meeting 180</a> - May 16, 2006</li>
-<li><a href="meeting179">Meeting 179</a> - May 9, 2006</li>
-<li><a href="meeting178">Meeting 178</a> - May 2, 2006</li>
-<li><a href="meeting177">Meeting 177</a> - April 25, 2006</li>
-<li><a href="meeting176">Meeting 176</a> - April 18, 2006</li>
-<li><a href="meeting175">Meeting 175</a> - April 4, 2006</li>
-<li><a href="meeting174">Meeting 174</a> - March 28, 2006</li>
-<li><a href="meeting173">Meeting 173</a> - March 21, 2006</li>
-<li><a href="meeting172">Meeting 172</a> - March 14, 2006</li>
-<li><a href="meeting171">Meeting 171</a> - March 7, 2006</li>
-<li><a href="meeting170">Meeting 170</a> - February 28, 2006</li>
-<li><a href="meeting169">Meeting 169</a> - February 21, 2006</li>
-<li><a href="meeting168">Meeting 168</a> - February 14, 2006</li>
-<li><a href="meeting167">Meeting 167</a> - February 7, 2006</li>
-<li><a href="meeting166">Meeting 166</a> - January 31, 2006</li>
-<li><a href="meeting165">Meeting 165</a> - January 24, 2006</li>
-<li><a href="meeting164">Meeting 164</a> - January 17, 2006</li>
-<li><a href="meeting163">Meeting 163</a> - January 10, 2006</li>
-<li><a href="meeting162">Meeting 162</a> - January 4, 2006</li>
-<li><a href="meeting161">Meeting 161</a> - December 20, 2005</li>
-<li><a href="meeting160">Meeting 160</a> - December 13, 2005</li>
-<li><a href="meeting159">Meeting 159</a> - December 6, 2005</li>
-<li><a href="meeting158">Meeting 158</a> - November 29, 2005</li>
-<li><a href="meeting157">Meeting 157</a> - November 22, 2005</li>
-<li><a href="meeting156">Meeting 156</a> - November 15, 2005</li>
-<li><a href="meeting155">Meeting 155</a> - November 8, 2005</li>
-<li><a href="meeting154">Meeting 154</a> - November 1, 2005</li>
-<li><a href="meeting153">Meeting 153</a> - October 25, 2005</li>
-<li><a href="meeting152">Meeting 152</a> - October 18, 2005</li>
-<li><a href="meeting151">Meeting 151</a> - October 11, 2005</li>
-<li><a href="meeting150">Meeting 150</a> - October 4, 2005</li>
-<li><a href="meeting149">Meeting 149</a> - September 27, 2005</li>
-<li><a href="meeting148">Meeting 148</a> - September 20, 2005</li>
-<li><a href="meeting147">Meeting 147</a> - September 13, 2005</li>
-<li><a href="meeting146">Meeting 146</a> - September 6, 2005</li>
-<li><a href="meeting145">Meeting 145</a> - August 30, 2005</li>
-<li><a href="meeting144">Meeting 144</a> - August 23, 2005</li>
-<li><a href="meeting143">Meeting 143</a> - August 16, 2005</li>
-<li><a href="meeting142">Meeting 142</a> - August 9, 2005</li>
-<li><a href="meeting141">Meeting 141</a> - August 2, 2005</li>
-<li><a href="meeting140">Meeting 140</a> - May 3, 2005</li>
-<li><a href="meeting139">Meeting 139</a> - April 26, 2005</li>
-<li><a href="meeting138">Meeting 138</a> - April 19, 2005</li>
-<li><a href="meeting137">Meeting 137</a> - April 12, 2005</li>
-<li><a href="meeting136">Meeting 136</a> - April 5, 2005</li>
-<li><a href="meeting135">Meeting 135</a> - March 28, 2005</li>
-<li><a href="meeting134">Meeting 134</a> - March 22, 2005</li>
-<li><a href="meeting133">Meeting 133</a> - March 15, 2005</li>
-<li><a href="meeting132">Meeting 132</a> - March 8, 2005</li>
-<li><a href="meeting131">Meeting 131</a> - March 1, 2005</li>
-<li><a href="meeting130">Meeting 130</a> - February 22, 2005</li>
-<li><a href="meeting129">Meeting 129</a> - February 15, 2005</li>
-<li><a href="meeting128">Meeting 128</a> - February 8, 2005</li>
-<li><a href="meeting127">Meeting 127</a> - February 1, 2005</li>
-<li><a href="meeting126">Meeting 126</a> - January 25, 2005</li>
-<li><a href="meeting125">Meeting 125</a> - January 18, 2005</li>
-<li><a href="meeting124">Meeting 124</a> - January 11, 2005</li>
-<li><a href="meeting123">Meeting 123</a> - January 4, 2005</li>
-<li><a href="meeting122">Meeting 122</a> - December 28, 2004</li>
-<li><a href="meeting121">Meeting 121</a> - December 21, 2004</li>
-<li><a href="meeting120">Meeting 120</a> - December 14, 2004</li>
-<li><a href="meeting119">Meeting 119</a> - December 7, 2004</li>
-<li><a href="meeting118">Meeting 118</a> - November 30, 2004</li>
-<li><a href="meeting117">Meeting 117</a> - November 23, 2004</li>
-<li><a href="meeting116">Meeting 116</a> - November 16, 2004</li>
-<li><a href="meeting115">Meeting 115</a> - November 9, 2004</li>
-<li><a href="meeting114">Meeting 114</a> - November 2, 2004</li>
-<li><a href="meeting113">Meeting 113</a> - October 26, 2004</li>
-<li><a href="meeting112">Meeting 112</a> - October 19, 2004</li>
-<li><a href="meeting111">Meeting 111</a> - October 12, 2004</li>
-<li><a href="meeting110">Meeting 110</a> - October 5, 2004</li>
-<li><a href="meeting109">Meeting 109</a> - September 28, 2004</li>
-<li><a href="meeting108">Meeting 108</a> - September 21, 2004</li>
-<li><a href="meeting107">Meeting 107</a> - September 14, 2004</li>
-<li><a href="meeting106">Meeting 106</a> - September 7, 2004</li>
-<li><a href="meeting105">Meeting 105</a> - August 31, 2004</li>
-<li><a href="meeting104">Meeting 104</a> - August 24, 2004</li>
-<li><a href="meeting103">Meeting 103</a> - August 17, 2004</li>
-<li><a href="meeting102">Meeting 102</a> - August 10, 2004</li>
-<li><a href="meeting101">Meeting 101</a> - August 3, 2004</li>
-<li><a href="meeting100">Meeting 100</a> - July 27, 2004</li>
-<li><a href="meeting99">Meeting 99</a> - July 20, 2004</li>
-<li><a href="meeting95">Meeting 95</a></li>
-<li><a href="meeting93">Meeting 93</a></li>
-<li><a href="meeting92">Meeting 92</a></li>
-<li><a href="meeting90">Meeting 90</a></li>
-<li><a href="meeting82">Meeting 82</a></li>
-<li><a href="meeting81">Meeting 81</a></li>
-<li><a href="meeting80">Meeting 80</a></li>
-<li><a href="meeting79">Meeting 79</a></li>
-<li><a href="meeting78">Meeting 78</a></li>
-<li><a href="meeting77">Meeting 77</a></li>
-<li><a href="meeting76">Meeting 76</a></li>
-<li><a href="meeting75">Meeting 75</a></li>
-<li><a href="meeting74">Meeting 74</a></li>
-<li><a href="meeting73">Meeting 73</a></li>
-<li><a href="meeting72">Meeting 72</a></li>
-<li><a href="meeting71">Meeting 71</a></li>
-<li><a href="meeting70">Meeting 70</a></li>
-<li><a href="meeting69">Meeting 69</a></li>
-<li><a href="meeting68">Meeting 68</a></li>
-<li><a href="meeting66">Meeting 66</a></li>
-<li><a href="meeting65">Meeting 65</a></li>
-<li><a href="meeting64">Meeting 64</a></li>
-<li><a href="meeting63">Meeting 63</a></li>
-<li><a href="meeting62">Meeting 62</a></li>
-<li><a href="meeting61">Meeting 61</a></li>
-<li><a href="meeting60">Meeting 60</a></li>
-<li><a href="meeting59">Meeting 59</a></li>
-<li><a href="meeting58">Meeting 58</a></li>
-<li><a href="meeting57">Meeting 57</a></li>
-<li><a href="meeting56">Meeting 56</a></li>
-<li><a href="meeting55">Meeting 55</a></li>
-<li><a href="meeting54">Meeting 54</a></li>
-<li><a href="meeting53">Meeting 53</a></li>
-<li><a href="meeting52">Meeting 52</a></li>
-<li><a href="meeting51">Meeting 51</a></li>
-<li><a href="meeting50">Meeting 50</a></li>
-<li><a href="meeting49">Meeting 49</a></li>
-<li><a href="meeting47">Meeting 47</a></li>
-<li><a href="meeting35">Meeting 35</a></li>
-<li><a href="meeting34">Meeting 34</a></li>
-<li><a href="meeting33">Meeting 33</a></li>
-<li><a href="meeting32">Meeting 32</a></li>
-<li><a href="meeting31">Meeting 31</a></li>
-<li><a href="meeting30">Meeting 30</a></li>
-<li><a href="meeting29">Meeting 29</a></li>
-<li><a href="meeting28">Meeting 28</a></li>
-<li><a href="meeting26">Meeting 26</a></li>
-<li><a href="meeting25">Meeting 25</a></li>
-<li><a href="meeting23">Meeting 23</a></li>
-<li><a href="meeting22">Meeting 22</a></li>
-<li><a href="meeting21">Meeting 21</a></li>
-<li><a href="meeting20">Meeting 20</a></li>
-<li><a href="meeting18">Meeting 18</a></li>
-<li><a href="meeting15">Meeting 15</a></li>
-<li><a href="meeting12">Meeting 12</a></li>
-<li><a href="meeting11">Meeting 11</a></li>
-<li><a href="meeting10">Meeting 10</a></li>
-<li><a href="meeting9">Meeting 9</a></li>
-<li><a href="meeting8">Meeting 8</a></li>
-<li><a href="meeting7">Meeting 7</a></li>
-<li><a href="meeting4">Meeting 4</a></li>
-<li><a href="meeting3">Meeting 3</a></li>
-<li><a href="meeting2">Meeting 2</a></li>
-<li><a href="meeting1">Meeting 1</a></li>
-
+{% for meeting in meetings -%}
+  <li><a href="{{ url_for('meetings_show', lang=g.lang, id=meeting) }}">Meeting {{ meeting }}</a></li>
+{%- endfor %}
 </ul>
 {% endblock %}
diff --git a/runserver.py b/runserver.py
index 695772b8..45e60621 100644
--- a/runserver.py
+++ b/runserver.py
@@ -1,2 +1,2 @@
 from i2p2www import app
-app.run(debug=False)
+app.run(debug=True)

From 6109ae787d273d3be8a3568cd319f6f8c235c609 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 03:45:24 +0000
Subject: [PATCH 36/75] Turn off debug mode again

---
 runserver.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/runserver.py b/runserver.py
index 45e60621..695772b8 100644
--- a/runserver.py
+++ b/runserver.py
@@ -1,2 +1,2 @@
 from i2p2www import app
-app.run(debug=True)
+app.run(debug=False)

From 905bfba44d0b4c2f28c4842c9455d15138866783 Mon Sep 17 00:00:00 2001
From: dev <dev@welterde.de>
Date: Thu, 13 Sep 2012 07:56:56 +0000
Subject: [PATCH 37/75] add missing template to make meetings work..

---
 pages/meetings/show.html | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 pages/meetings/show.html

diff --git a/pages/meetings/show.html b/pages/meetings/show.html
new file mode 100644
index 00000000..034e7b69
--- /dev/null
+++ b/pages/meetings/show.html
@@ -0,0 +1,15 @@
+{% extends "global/layout.html" %}
+{% block title %}I2P Development Meeting {{ id }}{% endblock %}
+{% block content %}
+{% autoescape false %}
+{% if header %}
+{{ header | restructuredtext }}
+{% endif %}
+{% endautoescape %}
+<div class="irclog">
+<pre>
+{{ log|escape }}
+{# TODO: pygments #}
+</pre>
+</div>
+{% endblock %}

From 80e097316540b13af550633a7bcb495468cb155a Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 12:38:36 +0000
Subject: [PATCH 38/75] Cleanup after merge

---
 i2p2www/pages/meetings/show.html | 13 ++++++++++---
 show.html.other                  | 15 ---------------
 2 files changed, 10 insertions(+), 18 deletions(-)
 delete mode 100644 show.html.other

diff --git a/i2p2www/pages/meetings/show.html b/i2p2www/pages/meetings/show.html
index 0dcca0d3..034e7b69 100644
--- a/i2p2www/pages/meetings/show.html
+++ b/i2p2www/pages/meetings/show.html
@@ -1,8 +1,15 @@
 {% extends "global/layout.html" %}
-{% block title %}Meeting {{ id }}{% endblock %}
+{% block title %}I2P Development Meeting {{ id }}{% endblock %}
 {% block content %}
-{{ header }}
+{% autoescape false %}
+{% if header %}
+{{ header | restructuredtext }}
+{% endif %}
+{% endautoescape %}
+<div class="irclog">
 <pre>
-{{ log }}
+{{ log|escape }}
+{# TODO: pygments #}
 </pre>
+</div>
 {% endblock %}
diff --git a/show.html.other b/show.html.other
deleted file mode 100644
index 034e7b69..00000000
--- a/show.html.other
+++ /dev/null
@@ -1,15 +0,0 @@
-{% extends "global/layout.html" %}
-{% block title %}I2P Development Meeting {{ id }}{% endblock %}
-{% block content %}
-{% autoescape false %}
-{% if header %}
-{{ header | restructuredtext }}
-{% endif %}
-{% endautoescape %}
-<div class="irclog">
-<pre>
-{{ log|escape }}
-{# TODO: pygments #}
-</pre>
-</div>
-{% endblock %}

From 5419e6c1ca038b0f2f66e62722f89a345446ecd8 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 21:05:56 +0000
Subject: [PATCH 39/75] disapproval of revision
 '378ab6a882c7ce887e80fb4ada4fd04eb2d21c39'

---
 i2p2www/__init__.py               |  26 +----
 i2p2www/pages/meetings/index.html | 178 +++++++++++++++++++++++++++++-
 runserver.py                      |   2 +-
 3 files changed, 177 insertions(+), 29 deletions(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index 6ba06a56..be03a629 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -129,37 +129,13 @@ def site_show(page='index'):
     return render_template(name, page=page)
 
 
-########################
-# Meeting helper methods
-
-def get_meetings_index():
-    """
-    Returns reverse-sorted list of valid ids
-    """
-    # list of ids
-    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()
-    return meetings
-
-
 ##################
 # Meeting handlers
 
 # Meeting index
 @app.route('/<string:lang>/meetings/')
 def meetings_index():
-    meetings = get_meetings_index()
-
-    return render_template('meetings/index.html', meetings=meetings)
+    return render_template('meetings/index.html')
 
 # Renderer for specific meetings
 @app.route('/<string:lang>/meetings/<int:id>')
diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
index c7172051..b8effc6b 100644
--- a/i2p2www/pages/meetings/index.html
+++ b/i2p2www/pages/meetings/index.html
@@ -7,8 +7,180 @@ If you have something to discuss, please find the developers on IRC in #i2p-dev.
 <a href="statusnotes.html">Status updates</a> from developers are also available.
 </p><div class="underline"></div>
 <ul class="infolist">
-{% for meeting in meetings -%}
-  <li><a href="{{ url_for('meetings_show', lang=g.lang, id=meeting) }}">Meeting {{ meeting }}</a></li>
-{%- endfor %}
+<li><a href="meeting208">Meeting 208</a> - September 8, 2010</li>
+<li><a href="meeting207">Meeting 207</a> - February 10, 2009</li>
+<li><a href="meeting206">Meeting 206</a> - April 10, 2007</li>
+<li><a href="meeting205">Meeting 205</a> - April 3, 2007</li>
+<li><a href="meeting204">Meeting 204</a> - March 27, 2007</li>
+<li><a href="meeting203">Meeting 203</a> - March 20, 2007</li>
+<li><a href="meeting202">Meeting 202</a> - March 13, 2007</li>
+<li><a href="meeting201">Meeting 201</a> - February 20, 2007</li>
+<li><a href="meeting200">Meeting 200</a> - February 13, 2007</li>
+<li><a href="meeting199">Meeting 199</a> - February 6, 2007</li>
+<li><a href="meeting198">Meeting 198</a> - January 30, 2007</li>
+<li><a href="meeting197">Meeting 197</a> - January 16, 2007</li>
+<li><a href="meeting196">Meeting 196</a> - January 9, 2007</li>
+<li><a href="meeting195">Meeting 195</a> - January 2, 2007</li>
+<li><a href="meeting194">Meeting 194</a> - December 26, 2006</li>
+<li><a href="meeting193">Meeting 193</a> - December 12, 2006</li>
+<li><a href="meeting192">Meeting 192</a> - December 05, 2006</li>
+<li><a href="meeting191">Meeting 191</a> - November 28, 2006</li>
+<li><a href="meeting190">Meeting 190</a> - November 21, 2006</li>
+<li><a href="meeting189">Meeting 189</a> - November 14, 2006</li>
+<li><a href="meeting188">Meeting 188</a> - November 7, 2006</li>
+<li><a href="meeting187">Meeting 187</a> - October 31, 2006</li>
+<li><a href="meeting186">Meeting 186</a> - October 24, 2006</li>
+<li><a href="meeting185">Meeting 185</a> - October 17, 2006</li>
+<li><a href="meeting184">Meeting 184</a> - September 12, 2006</li>
+<li><a href="meeting183">Meeting 183</a> - August 1, 2006</li>
+<li><a href="meeting182">Meeting 182</a> - June 13, 2006</li>
+<li><a href="meeting181">Meeting 181</a> - May 30, 2006</li>
+<li><a href="meeting180">Meeting 180</a> - May 16, 2006</li>
+<li><a href="meeting179">Meeting 179</a> - May 9, 2006</li>
+<li><a href="meeting178">Meeting 178</a> - May 2, 2006</li>
+<li><a href="meeting177">Meeting 177</a> - April 25, 2006</li>
+<li><a href="meeting176">Meeting 176</a> - April 18, 2006</li>
+<li><a href="meeting175">Meeting 175</a> - April 4, 2006</li>
+<li><a href="meeting174">Meeting 174</a> - March 28, 2006</li>
+<li><a href="meeting173">Meeting 173</a> - March 21, 2006</li>
+<li><a href="meeting172">Meeting 172</a> - March 14, 2006</li>
+<li><a href="meeting171">Meeting 171</a> - March 7, 2006</li>
+<li><a href="meeting170">Meeting 170</a> - February 28, 2006</li>
+<li><a href="meeting169">Meeting 169</a> - February 21, 2006</li>
+<li><a href="meeting168">Meeting 168</a> - February 14, 2006</li>
+<li><a href="meeting167">Meeting 167</a> - February 7, 2006</li>
+<li><a href="meeting166">Meeting 166</a> - January 31, 2006</li>
+<li><a href="meeting165">Meeting 165</a> - January 24, 2006</li>
+<li><a href="meeting164">Meeting 164</a> - January 17, 2006</li>
+<li><a href="meeting163">Meeting 163</a> - January 10, 2006</li>
+<li><a href="meeting162">Meeting 162</a> - January 4, 2006</li>
+<li><a href="meeting161">Meeting 161</a> - December 20, 2005</li>
+<li><a href="meeting160">Meeting 160</a> - December 13, 2005</li>
+<li><a href="meeting159">Meeting 159</a> - December 6, 2005</li>
+<li><a href="meeting158">Meeting 158</a> - November 29, 2005</li>
+<li><a href="meeting157">Meeting 157</a> - November 22, 2005</li>
+<li><a href="meeting156">Meeting 156</a> - November 15, 2005</li>
+<li><a href="meeting155">Meeting 155</a> - November 8, 2005</li>
+<li><a href="meeting154">Meeting 154</a> - November 1, 2005</li>
+<li><a href="meeting153">Meeting 153</a> - October 25, 2005</li>
+<li><a href="meeting152">Meeting 152</a> - October 18, 2005</li>
+<li><a href="meeting151">Meeting 151</a> - October 11, 2005</li>
+<li><a href="meeting150">Meeting 150</a> - October 4, 2005</li>
+<li><a href="meeting149">Meeting 149</a> - September 27, 2005</li>
+<li><a href="meeting148">Meeting 148</a> - September 20, 2005</li>
+<li><a href="meeting147">Meeting 147</a> - September 13, 2005</li>
+<li><a href="meeting146">Meeting 146</a> - September 6, 2005</li>
+<li><a href="meeting145">Meeting 145</a> - August 30, 2005</li>
+<li><a href="meeting144">Meeting 144</a> - August 23, 2005</li>
+<li><a href="meeting143">Meeting 143</a> - August 16, 2005</li>
+<li><a href="meeting142">Meeting 142</a> - August 9, 2005</li>
+<li><a href="meeting141">Meeting 141</a> - August 2, 2005</li>
+<li><a href="meeting140">Meeting 140</a> - May 3, 2005</li>
+<li><a href="meeting139">Meeting 139</a> - April 26, 2005</li>
+<li><a href="meeting138">Meeting 138</a> - April 19, 2005</li>
+<li><a href="meeting137">Meeting 137</a> - April 12, 2005</li>
+<li><a href="meeting136">Meeting 136</a> - April 5, 2005</li>
+<li><a href="meeting135">Meeting 135</a> - March 28, 2005</li>
+<li><a href="meeting134">Meeting 134</a> - March 22, 2005</li>
+<li><a href="meeting133">Meeting 133</a> - March 15, 2005</li>
+<li><a href="meeting132">Meeting 132</a> - March 8, 2005</li>
+<li><a href="meeting131">Meeting 131</a> - March 1, 2005</li>
+<li><a href="meeting130">Meeting 130</a> - February 22, 2005</li>
+<li><a href="meeting129">Meeting 129</a> - February 15, 2005</li>
+<li><a href="meeting128">Meeting 128</a> - February 8, 2005</li>
+<li><a href="meeting127">Meeting 127</a> - February 1, 2005</li>
+<li><a href="meeting126">Meeting 126</a> - January 25, 2005</li>
+<li><a href="meeting125">Meeting 125</a> - January 18, 2005</li>
+<li><a href="meeting124">Meeting 124</a> - January 11, 2005</li>
+<li><a href="meeting123">Meeting 123</a> - January 4, 2005</li>
+<li><a href="meeting122">Meeting 122</a> - December 28, 2004</li>
+<li><a href="meeting121">Meeting 121</a> - December 21, 2004</li>
+<li><a href="meeting120">Meeting 120</a> - December 14, 2004</li>
+<li><a href="meeting119">Meeting 119</a> - December 7, 2004</li>
+<li><a href="meeting118">Meeting 118</a> - November 30, 2004</li>
+<li><a href="meeting117">Meeting 117</a> - November 23, 2004</li>
+<li><a href="meeting116">Meeting 116</a> - November 16, 2004</li>
+<li><a href="meeting115">Meeting 115</a> - November 9, 2004</li>
+<li><a href="meeting114">Meeting 114</a> - November 2, 2004</li>
+<li><a href="meeting113">Meeting 113</a> - October 26, 2004</li>
+<li><a href="meeting112">Meeting 112</a> - October 19, 2004</li>
+<li><a href="meeting111">Meeting 111</a> - October 12, 2004</li>
+<li><a href="meeting110">Meeting 110</a> - October 5, 2004</li>
+<li><a href="meeting109">Meeting 109</a> - September 28, 2004</li>
+<li><a href="meeting108">Meeting 108</a> - September 21, 2004</li>
+<li><a href="meeting107">Meeting 107</a> - September 14, 2004</li>
+<li><a href="meeting106">Meeting 106</a> - September 7, 2004</li>
+<li><a href="meeting105">Meeting 105</a> - August 31, 2004</li>
+<li><a href="meeting104">Meeting 104</a> - August 24, 2004</li>
+<li><a href="meeting103">Meeting 103</a> - August 17, 2004</li>
+<li><a href="meeting102">Meeting 102</a> - August 10, 2004</li>
+<li><a href="meeting101">Meeting 101</a> - August 3, 2004</li>
+<li><a href="meeting100">Meeting 100</a> - July 27, 2004</li>
+<li><a href="meeting99">Meeting 99</a> - July 20, 2004</li>
+<li><a href="meeting95">Meeting 95</a></li>
+<li><a href="meeting93">Meeting 93</a></li>
+<li><a href="meeting92">Meeting 92</a></li>
+<li><a href="meeting90">Meeting 90</a></li>
+<li><a href="meeting82">Meeting 82</a></li>
+<li><a href="meeting81">Meeting 81</a></li>
+<li><a href="meeting80">Meeting 80</a></li>
+<li><a href="meeting79">Meeting 79</a></li>
+<li><a href="meeting78">Meeting 78</a></li>
+<li><a href="meeting77">Meeting 77</a></li>
+<li><a href="meeting76">Meeting 76</a></li>
+<li><a href="meeting75">Meeting 75</a></li>
+<li><a href="meeting74">Meeting 74</a></li>
+<li><a href="meeting73">Meeting 73</a></li>
+<li><a href="meeting72">Meeting 72</a></li>
+<li><a href="meeting71">Meeting 71</a></li>
+<li><a href="meeting70">Meeting 70</a></li>
+<li><a href="meeting69">Meeting 69</a></li>
+<li><a href="meeting68">Meeting 68</a></li>
+<li><a href="meeting66">Meeting 66</a></li>
+<li><a href="meeting65">Meeting 65</a></li>
+<li><a href="meeting64">Meeting 64</a></li>
+<li><a href="meeting63">Meeting 63</a></li>
+<li><a href="meeting62">Meeting 62</a></li>
+<li><a href="meeting61">Meeting 61</a></li>
+<li><a href="meeting60">Meeting 60</a></li>
+<li><a href="meeting59">Meeting 59</a></li>
+<li><a href="meeting58">Meeting 58</a></li>
+<li><a href="meeting57">Meeting 57</a></li>
+<li><a href="meeting56">Meeting 56</a></li>
+<li><a href="meeting55">Meeting 55</a></li>
+<li><a href="meeting54">Meeting 54</a></li>
+<li><a href="meeting53">Meeting 53</a></li>
+<li><a href="meeting52">Meeting 52</a></li>
+<li><a href="meeting51">Meeting 51</a></li>
+<li><a href="meeting50">Meeting 50</a></li>
+<li><a href="meeting49">Meeting 49</a></li>
+<li><a href="meeting47">Meeting 47</a></li>
+<li><a href="meeting35">Meeting 35</a></li>
+<li><a href="meeting34">Meeting 34</a></li>
+<li><a href="meeting33">Meeting 33</a></li>
+<li><a href="meeting32">Meeting 32</a></li>
+<li><a href="meeting31">Meeting 31</a></li>
+<li><a href="meeting30">Meeting 30</a></li>
+<li><a href="meeting29">Meeting 29</a></li>
+<li><a href="meeting28">Meeting 28</a></li>
+<li><a href="meeting26">Meeting 26</a></li>
+<li><a href="meeting25">Meeting 25</a></li>
+<li><a href="meeting23">Meeting 23</a></li>
+<li><a href="meeting22">Meeting 22</a></li>
+<li><a href="meeting21">Meeting 21</a></li>
+<li><a href="meeting20">Meeting 20</a></li>
+<li><a href="meeting18">Meeting 18</a></li>
+<li><a href="meeting15">Meeting 15</a></li>
+<li><a href="meeting12">Meeting 12</a></li>
+<li><a href="meeting11">Meeting 11</a></li>
+<li><a href="meeting10">Meeting 10</a></li>
+<li><a href="meeting9">Meeting 9</a></li>
+<li><a href="meeting8">Meeting 8</a></li>
+<li><a href="meeting7">Meeting 7</a></li>
+<li><a href="meeting4">Meeting 4</a></li>
+<li><a href="meeting3">Meeting 3</a></li>
+<li><a href="meeting2">Meeting 2</a></li>
+<li><a href="meeting1">Meeting 1</a></li>
+
 </ul>
 {% endblock %}
diff --git a/runserver.py b/runserver.py
index 45e60621..695772b8 100644
--- a/runserver.py
+++ b/runserver.py
@@ -1,2 +1,2 @@
 from i2p2www import app
-app.run(debug=True)
+app.run(debug=False)

From eef5f3fc8c36871dee8361209572b12a186baf6a Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 21:26:21 +0000
Subject: [PATCH 40/75] Update hard-coded meeting urls

---
 i2p2www/pages/meetings/index.html | 349 +++++++++++++++---------------
 1 file changed, 175 insertions(+), 174 deletions(-)

diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
index b8effc6b..c475889e 100644
--- a/i2p2www/pages/meetings/index.html
+++ b/i2p2www/pages/meetings/index.html
@@ -7,180 +7,181 @@ If you have something to discuss, please find the developers on IRC in #i2p-dev.
 <a href="statusnotes.html">Status updates</a> from developers are also available.
 </p><div class="underline"></div>
 <ul class="infolist">
-<li><a href="meeting208">Meeting 208</a> - September 8, 2010</li>
-<li><a href="meeting207">Meeting 207</a> - February 10, 2009</li>
-<li><a href="meeting206">Meeting 206</a> - April 10, 2007</li>
-<li><a href="meeting205">Meeting 205</a> - April 3, 2007</li>
-<li><a href="meeting204">Meeting 204</a> - March 27, 2007</li>
-<li><a href="meeting203">Meeting 203</a> - March 20, 2007</li>
-<li><a href="meeting202">Meeting 202</a> - March 13, 2007</li>
-<li><a href="meeting201">Meeting 201</a> - February 20, 2007</li>
-<li><a href="meeting200">Meeting 200</a> - February 13, 2007</li>
-<li><a href="meeting199">Meeting 199</a> - February 6, 2007</li>
-<li><a href="meeting198">Meeting 198</a> - January 30, 2007</li>
-<li><a href="meeting197">Meeting 197</a> - January 16, 2007</li>
-<li><a href="meeting196">Meeting 196</a> - January 9, 2007</li>
-<li><a href="meeting195">Meeting 195</a> - January 2, 2007</li>
-<li><a href="meeting194">Meeting 194</a> - December 26, 2006</li>
-<li><a href="meeting193">Meeting 193</a> - December 12, 2006</li>
-<li><a href="meeting192">Meeting 192</a> - December 05, 2006</li>
-<li><a href="meeting191">Meeting 191</a> - November 28, 2006</li>
-<li><a href="meeting190">Meeting 190</a> - November 21, 2006</li>
-<li><a href="meeting189">Meeting 189</a> - November 14, 2006</li>
-<li><a href="meeting188">Meeting 188</a> - November 7, 2006</li>
-<li><a href="meeting187">Meeting 187</a> - October 31, 2006</li>
-<li><a href="meeting186">Meeting 186</a> - October 24, 2006</li>
-<li><a href="meeting185">Meeting 185</a> - October 17, 2006</li>
-<li><a href="meeting184">Meeting 184</a> - September 12, 2006</li>
-<li><a href="meeting183">Meeting 183</a> - August 1, 2006</li>
-<li><a href="meeting182">Meeting 182</a> - June 13, 2006</li>
-<li><a href="meeting181">Meeting 181</a> - May 30, 2006</li>
-<li><a href="meeting180">Meeting 180</a> - May 16, 2006</li>
-<li><a href="meeting179">Meeting 179</a> - May 9, 2006</li>
-<li><a href="meeting178">Meeting 178</a> - May 2, 2006</li>
-<li><a href="meeting177">Meeting 177</a> - April 25, 2006</li>
-<li><a href="meeting176">Meeting 176</a> - April 18, 2006</li>
-<li><a href="meeting175">Meeting 175</a> - April 4, 2006</li>
-<li><a href="meeting174">Meeting 174</a> - March 28, 2006</li>
-<li><a href="meeting173">Meeting 173</a> - March 21, 2006</li>
-<li><a href="meeting172">Meeting 172</a> - March 14, 2006</li>
-<li><a href="meeting171">Meeting 171</a> - March 7, 2006</li>
-<li><a href="meeting170">Meeting 170</a> - February 28, 2006</li>
-<li><a href="meeting169">Meeting 169</a> - February 21, 2006</li>
-<li><a href="meeting168">Meeting 168</a> - February 14, 2006</li>
-<li><a href="meeting167">Meeting 167</a> - February 7, 2006</li>
-<li><a href="meeting166">Meeting 166</a> - January 31, 2006</li>
-<li><a href="meeting165">Meeting 165</a> - January 24, 2006</li>
-<li><a href="meeting164">Meeting 164</a> - January 17, 2006</li>
-<li><a href="meeting163">Meeting 163</a> - January 10, 2006</li>
-<li><a href="meeting162">Meeting 162</a> - January 4, 2006</li>
-<li><a href="meeting161">Meeting 161</a> - December 20, 2005</li>
-<li><a href="meeting160">Meeting 160</a> - December 13, 2005</li>
-<li><a href="meeting159">Meeting 159</a> - December 6, 2005</li>
-<li><a href="meeting158">Meeting 158</a> - November 29, 2005</li>
-<li><a href="meeting157">Meeting 157</a> - November 22, 2005</li>
-<li><a href="meeting156">Meeting 156</a> - November 15, 2005</li>
-<li><a href="meeting155">Meeting 155</a> - November 8, 2005</li>
-<li><a href="meeting154">Meeting 154</a> - November 1, 2005</li>
-<li><a href="meeting153">Meeting 153</a> - October 25, 2005</li>
-<li><a href="meeting152">Meeting 152</a> - October 18, 2005</li>
-<li><a href="meeting151">Meeting 151</a> - October 11, 2005</li>
-<li><a href="meeting150">Meeting 150</a> - October 4, 2005</li>
-<li><a href="meeting149">Meeting 149</a> - September 27, 2005</li>
-<li><a href="meeting148">Meeting 148</a> - September 20, 2005</li>
-<li><a href="meeting147">Meeting 147</a> - September 13, 2005</li>
-<li><a href="meeting146">Meeting 146</a> - September 6, 2005</li>
-<li><a href="meeting145">Meeting 145</a> - August 30, 2005</li>
-<li><a href="meeting144">Meeting 144</a> - August 23, 2005</li>
-<li><a href="meeting143">Meeting 143</a> - August 16, 2005</li>
-<li><a href="meeting142">Meeting 142</a> - August 9, 2005</li>
-<li><a href="meeting141">Meeting 141</a> - August 2, 2005</li>
-<li><a href="meeting140">Meeting 140</a> - May 3, 2005</li>
-<li><a href="meeting139">Meeting 139</a> - April 26, 2005</li>
-<li><a href="meeting138">Meeting 138</a> - April 19, 2005</li>
-<li><a href="meeting137">Meeting 137</a> - April 12, 2005</li>
-<li><a href="meeting136">Meeting 136</a> - April 5, 2005</li>
-<li><a href="meeting135">Meeting 135</a> - March 28, 2005</li>
-<li><a href="meeting134">Meeting 134</a> - March 22, 2005</li>
-<li><a href="meeting133">Meeting 133</a> - March 15, 2005</li>
-<li><a href="meeting132">Meeting 132</a> - March 8, 2005</li>
-<li><a href="meeting131">Meeting 131</a> - March 1, 2005</li>
-<li><a href="meeting130">Meeting 130</a> - February 22, 2005</li>
-<li><a href="meeting129">Meeting 129</a> - February 15, 2005</li>
-<li><a href="meeting128">Meeting 128</a> - February 8, 2005</li>
-<li><a href="meeting127">Meeting 127</a> - February 1, 2005</li>
-<li><a href="meeting126">Meeting 126</a> - January 25, 2005</li>
-<li><a href="meeting125">Meeting 125</a> - January 18, 2005</li>
-<li><a href="meeting124">Meeting 124</a> - January 11, 2005</li>
-<li><a href="meeting123">Meeting 123</a> - January 4, 2005</li>
-<li><a href="meeting122">Meeting 122</a> - December 28, 2004</li>
-<li><a href="meeting121">Meeting 121</a> - December 21, 2004</li>
-<li><a href="meeting120">Meeting 120</a> - December 14, 2004</li>
-<li><a href="meeting119">Meeting 119</a> - December 7, 2004</li>
-<li><a href="meeting118">Meeting 118</a> - November 30, 2004</li>
-<li><a href="meeting117">Meeting 117</a> - November 23, 2004</li>
-<li><a href="meeting116">Meeting 116</a> - November 16, 2004</li>
-<li><a href="meeting115">Meeting 115</a> - November 9, 2004</li>
-<li><a href="meeting114">Meeting 114</a> - November 2, 2004</li>
-<li><a href="meeting113">Meeting 113</a> - October 26, 2004</li>
-<li><a href="meeting112">Meeting 112</a> - October 19, 2004</li>
-<li><a href="meeting111">Meeting 111</a> - October 12, 2004</li>
-<li><a href="meeting110">Meeting 110</a> - October 5, 2004</li>
-<li><a href="meeting109">Meeting 109</a> - September 28, 2004</li>
-<li><a href="meeting108">Meeting 108</a> - September 21, 2004</li>
-<li><a href="meeting107">Meeting 107</a> - September 14, 2004</li>
-<li><a href="meeting106">Meeting 106</a> - September 7, 2004</li>
-<li><a href="meeting105">Meeting 105</a> - August 31, 2004</li>
-<li><a href="meeting104">Meeting 104</a> - August 24, 2004</li>
-<li><a href="meeting103">Meeting 103</a> - August 17, 2004</li>
-<li><a href="meeting102">Meeting 102</a> - August 10, 2004</li>
-<li><a href="meeting101">Meeting 101</a> - August 3, 2004</li>
-<li><a href="meeting100">Meeting 100</a> - July 27, 2004</li>
-<li><a href="meeting99">Meeting 99</a> - July 20, 2004</li>
-<li><a href="meeting95">Meeting 95</a></li>
-<li><a href="meeting93">Meeting 93</a></li>
-<li><a href="meeting92">Meeting 92</a></li>
-<li><a href="meeting90">Meeting 90</a></li>
-<li><a href="meeting82">Meeting 82</a></li>
-<li><a href="meeting81">Meeting 81</a></li>
-<li><a href="meeting80">Meeting 80</a></li>
-<li><a href="meeting79">Meeting 79</a></li>
-<li><a href="meeting78">Meeting 78</a></li>
-<li><a href="meeting77">Meeting 77</a></li>
-<li><a href="meeting76">Meeting 76</a></li>
-<li><a href="meeting75">Meeting 75</a></li>
-<li><a href="meeting74">Meeting 74</a></li>
-<li><a href="meeting73">Meeting 73</a></li>
-<li><a href="meeting72">Meeting 72</a></li>
-<li><a href="meeting71">Meeting 71</a></li>
-<li><a href="meeting70">Meeting 70</a></li>
-<li><a href="meeting69">Meeting 69</a></li>
-<li><a href="meeting68">Meeting 68</a></li>
-<li><a href="meeting66">Meeting 66</a></li>
-<li><a href="meeting65">Meeting 65</a></li>
-<li><a href="meeting64">Meeting 64</a></li>
-<li><a href="meeting63">Meeting 63</a></li>
-<li><a href="meeting62">Meeting 62</a></li>
-<li><a href="meeting61">Meeting 61</a></li>
-<li><a href="meeting60">Meeting 60</a></li>
-<li><a href="meeting59">Meeting 59</a></li>
-<li><a href="meeting58">Meeting 58</a></li>
-<li><a href="meeting57">Meeting 57</a></li>
-<li><a href="meeting56">Meeting 56</a></li>
-<li><a href="meeting55">Meeting 55</a></li>
-<li><a href="meeting54">Meeting 54</a></li>
-<li><a href="meeting53">Meeting 53</a></li>
-<li><a href="meeting52">Meeting 52</a></li>
-<li><a href="meeting51">Meeting 51</a></li>
-<li><a href="meeting50">Meeting 50</a></li>
-<li><a href="meeting49">Meeting 49</a></li>
-<li><a href="meeting47">Meeting 47</a></li>
-<li><a href="meeting35">Meeting 35</a></li>
-<li><a href="meeting34">Meeting 34</a></li>
-<li><a href="meeting33">Meeting 33</a></li>
-<li><a href="meeting32">Meeting 32</a></li>
-<li><a href="meeting31">Meeting 31</a></li>
-<li><a href="meeting30">Meeting 30</a></li>
-<li><a href="meeting29">Meeting 29</a></li>
-<li><a href="meeting28">Meeting 28</a></li>
-<li><a href="meeting26">Meeting 26</a></li>
-<li><a href="meeting25">Meeting 25</a></li>
-<li><a href="meeting23">Meeting 23</a></li>
-<li><a href="meeting22">Meeting 22</a></li>
-<li><a href="meeting21">Meeting 21</a></li>
-<li><a href="meeting20">Meeting 20</a></li>
-<li><a href="meeting18">Meeting 18</a></li>
-<li><a href="meeting15">Meeting 15</a></li>
-<li><a href="meeting12">Meeting 12</a></li>
-<li><a href="meeting11">Meeting 11</a></li>
-<li><a href="meeting10">Meeting 10</a></li>
-<li><a href="meeting9">Meeting 9</a></li>
-<li><a href="meeting8">Meeting 8</a></li>
-<li><a href="meeting7">Meeting 7</a></li>
-<li><a href="meeting4">Meeting 4</a></li>
-<li><a href="meeting3">Meeting 3</a></li>
-<li><a href="meeting2">Meeting 2</a></li>
-<li><a href="meeting1">Meeting 1</a></li>
+{%- macro meeting_url(m_id) -%}{{ url_for('meetings_show', lang=g.lang, id=m_id) }}{%- endmacro -%}
+<li><a href="{{ meeting_url(208) }}">Meeting 208</a> - September 8, 2010</li>
+<li><a href="{{ meeting_url(207) }}">Meeting 207</a> - February 10, 2009</li>
+<li><a href="{{ meeting_url(206) }}">Meeting 206</a> - April 10, 2007</li>
+<li><a href="{{ meeting_url(205) }}">Meeting 205</a> - April 3, 2007</li>
+<li><a href="{{ meeting_url(204) }}">Meeting 204</a> - March 27, 2007</li>
+<li><a href="{{ meeting_url(203) }}">Meeting 203</a> - March 20, 2007</li>
+<li><a href="{{ meeting_url(202) }}">Meeting 202</a> - March 13, 2007</li>
+<li><a href="{{ meeting_url(201) }}">Meeting 201</a> - February 20, 2007</li>
+<li><a href="{{ meeting_url(200) }}">Meeting 200</a> - February 13, 2007</li>
+<li><a href="{{ meeting_url(199) }}">Meeting 199</a> - February 6, 2007</li>
+<li><a href="{{ meeting_url(198) }}">Meeting 198</a> - January 30, 2007</li>
+<li><a href="{{ meeting_url(197) }}">Meeting 197</a> - January 16, 2007</li>
+<li><a href="{{ meeting_url(196) }}">Meeting 196</a> - January 9, 2007</li>
+<li><a href="{{ meeting_url(195) }}">Meeting 195</a> - January 2, 2007</li>
+<li><a href="{{ meeting_url(194) }}">Meeting 194</a> - December 26, 2006</li>
+<li><a href="{{ meeting_url(193) }}">Meeting 193</a> - December 12, 2006</li>
+<li><a href="{{ meeting_url(192) }}">Meeting 192</a> - December 05, 2006</li>
+<li><a href="{{ meeting_url(191) }}">Meeting 191</a> - November 28, 2006</li>
+<li><a href="{{ meeting_url(190) }}">Meeting 190</a> - November 21, 2006</li>
+<li><a href="{{ meeting_url(189) }}">Meeting 189</a> - November 14, 2006</li>
+<li><a href="{{ meeting_url(188) }}">Meeting 188</a> - November 7, 2006</li>
+<li><a href="{{ meeting_url(187) }}">Meeting 187</a> - October 31, 2006</li>
+<li><a href="{{ meeting_url(186) }}">Meeting 186</a> - October 24, 2006</li>
+<li><a href="{{ meeting_url(185) }}">Meeting 185</a> - October 17, 2006</li>
+<li><a href="{{ meeting_url(184) }}">Meeting 184</a> - September 12, 2006</li>
+<li><a href="{{ meeting_url(183) }}">Meeting 183</a> - August 1, 2006</li>
+<li><a href="{{ meeting_url(182) }}">Meeting 182</a> - June 13, 2006</li>
+<li><a href="{{ meeting_url(181) }}">Meeting 181</a> - May 30, 2006</li>
+<li><a href="{{ meeting_url(180) }}">Meeting 180</a> - May 16, 2006</li>
+<li><a href="{{ meeting_url(179) }}">Meeting 179</a> - May 9, 2006</li>
+<li><a href="{{ meeting_url(178) }}">Meeting 178</a> - May 2, 2006</li>
+<li><a href="{{ meeting_url(177) }}">Meeting 177</a> - April 25, 2006</li>
+<li><a href="{{ meeting_url(176) }}">Meeting 176</a> - April 18, 2006</li>
+<li><a href="{{ meeting_url(175) }}">Meeting 175</a> - April 4, 2006</li>
+<li><a href="{{ meeting_url(174) }}">Meeting 174</a> - March 28, 2006</li>
+<li><a href="{{ meeting_url(173) }}">Meeting 173</a> - March 21, 2006</li>
+<li><a href="{{ meeting_url(172) }}">Meeting 172</a> - March 14, 2006</li>
+<li><a href="{{ meeting_url(171) }}">Meeting 171</a> - March 7, 2006</li>
+<li><a href="{{ meeting_url(170) }}">Meeting 170</a> - February 28, 2006</li>
+<li><a href="{{ meeting_url(169) }}">Meeting 169</a> - February 21, 2006</li>
+<li><a href="{{ meeting_url(168) }}">Meeting 168</a> - February 14, 2006</li>
+<li><a href="{{ meeting_url(167) }}">Meeting 167</a> - February 7, 2006</li>
+<li><a href="{{ meeting_url(166) }}">Meeting 166</a> - January 31, 2006</li>
+<li><a href="{{ meeting_url(165) }}">Meeting 165</a> - January 24, 2006</li>
+<li><a href="{{ meeting_url(164) }}">Meeting 164</a> - January 17, 2006</li>
+<li><a href="{{ meeting_url(163) }}">Meeting 163</a> - January 10, 2006</li>
+<li><a href="{{ meeting_url(162) }}">Meeting 162</a> - January 4, 2006</li>
+<li><a href="{{ meeting_url(161) }}">Meeting 161</a> - December 20, 2005</li>
+<li><a href="{{ meeting_url(160) }}">Meeting 160</a> - December 13, 2005</li>
+<li><a href="{{ meeting_url(159) }}">Meeting 159</a> - December 6, 2005</li>
+<li><a href="{{ meeting_url(158) }}">Meeting 158</a> - November 29, 2005</li>
+<li><a href="{{ meeting_url(157) }}">Meeting 157</a> - November 22, 2005</li>
+<li><a href="{{ meeting_url(156) }}">Meeting 156</a> - November 15, 2005</li>
+<li><a href="{{ meeting_url(155) }}">Meeting 155</a> - November 8, 2005</li>
+<li><a href="{{ meeting_url(154) }}">Meeting 154</a> - November 1, 2005</li>
+<li><a href="{{ meeting_url(153) }}">Meeting 153</a> - October 25, 2005</li>
+<li><a href="{{ meeting_url(152) }}">Meeting 152</a> - October 18, 2005</li>
+<li><a href="{{ meeting_url(151) }}">Meeting 151</a> - October 11, 2005</li>
+<li><a href="{{ meeting_url(150) }}">Meeting 150</a> - October 4, 2005</li>
+<li><a href="{{ meeting_url(149) }}">Meeting 149</a> - September 27, 2005</li>
+<li><a href="{{ meeting_url(148) }}">Meeting 148</a> - September 20, 2005</li>
+<li><a href="{{ meeting_url(147) }}">Meeting 147</a> - September 13, 2005</li>
+<li><a href="{{ meeting_url(146) }}">Meeting 146</a> - September 6, 2005</li>
+<li><a href="{{ meeting_url(145) }}">Meeting 145</a> - August 30, 2005</li>
+<li><a href="{{ meeting_url(144) }}">Meeting 144</a> - August 23, 2005</li>
+<li><a href="{{ meeting_url(143) }}">Meeting 143</a> - August 16, 2005</li>
+<li><a href="{{ meeting_url(142) }}">Meeting 142</a> - August 9, 2005</li>
+<li><a href="{{ meeting_url(141) }}">Meeting 141</a> - August 2, 2005</li>
+<li><a href="{{ meeting_url(140) }}">Meeting 140</a> - May 3, 2005</li>
+<li><a href="{{ meeting_url(139) }}">Meeting 139</a> - April 26, 2005</li>
+<li><a href="{{ meeting_url(138) }}">Meeting 138</a> - April 19, 2005</li>
+<li><a href="{{ meeting_url(137) }}">Meeting 137</a> - April 12, 2005</li>
+<li><a href="{{ meeting_url(136) }}">Meeting 136</a> - April 5, 2005</li>
+<li><a href="{{ meeting_url(135) }}">Meeting 135</a> - March 28, 2005</li>
+<li><a href="{{ meeting_url(134) }}">Meeting 134</a> - March 22, 2005</li>
+<li><a href="{{ meeting_url(133) }}">Meeting 133</a> - March 15, 2005</li>
+<li><a href="{{ meeting_url(132) }}">Meeting 132</a> - March 8, 2005</li>
+<li><a href="{{ meeting_url(131) }}">Meeting 131</a> - March 1, 2005</li>
+<li><a href="{{ meeting_url(130) }}">Meeting 130</a> - February 22, 2005</li>
+<li><a href="{{ meeting_url(129) }}">Meeting 129</a> - February 15, 2005</li>
+<li><a href="{{ meeting_url(128) }}">Meeting 128</a> - February 8, 2005</li>
+<li><a href="{{ meeting_url(127) }}">Meeting 127</a> - February 1, 2005</li>
+<li><a href="{{ meeting_url(126) }}">Meeting 126</a> - January 25, 2005</li>
+<li><a href="{{ meeting_url(125) }}">Meeting 125</a> - January 18, 2005</li>
+<li><a href="{{ meeting_url(124) }}">Meeting 124</a> - January 11, 2005</li>
+<li><a href="{{ meeting_url(123) }}">Meeting 123</a> - January 4, 2005</li>
+<li><a href="{{ meeting_url(122) }}">Meeting 122</a> - December 28, 2004</li>
+<li><a href="{{ meeting_url(121) }}">Meeting 121</a> - December 21, 2004</li>
+<li><a href="{{ meeting_url(120) }}">Meeting 120</a> - December 14, 2004</li>
+<li><a href="{{ meeting_url(119) }}">Meeting 119</a> - December 7, 2004</li>
+<li><a href="{{ meeting_url(118) }}">Meeting 118</a> - November 30, 2004</li>
+<li><a href="{{ meeting_url(117) }}">Meeting 117</a> - November 23, 2004</li>
+<li><a href="{{ meeting_url(116) }}">Meeting 116</a> - November 16, 2004</li>
+<li><a href="{{ meeting_url(115) }}">Meeting 115</a> - November 9, 2004</li>
+<li><a href="{{ meeting_url(114) }}">Meeting 114</a> - November 2, 2004</li>
+<li><a href="{{ meeting_url(113) }}">Meeting 113</a> - October 26, 2004</li>
+<li><a href="{{ meeting_url(112) }}">Meeting 112</a> - October 19, 2004</li>
+<li><a href="{{ meeting_url(111) }}">Meeting 111</a> - October 12, 2004</li>
+<li><a href="{{ meeting_url(110) }}">Meeting 110</a> - October 5, 2004</li>
+<li><a href="{{ meeting_url(109) }}">Meeting 109</a> - September 28, 2004</li>
+<li><a href="{{ meeting_url(108) }}">Meeting 108</a> - September 21, 2004</li>
+<li><a href="{{ meeting_url(107) }}">Meeting 107</a> - September 14, 2004</li>
+<li><a href="{{ meeting_url(106) }}">Meeting 106</a> - September 7, 2004</li>
+<li><a href="{{ meeting_url(105) }}">Meeting 105</a> - August 31, 2004</li>
+<li><a href="{{ meeting_url(104) }}">Meeting 104</a> - August 24, 2004</li>
+<li><a href="{{ meeting_url(103) }}">Meeting 103</a> - August 17, 2004</li>
+<li><a href="{{ meeting_url(102) }}">Meeting 102</a> - August 10, 2004</li>
+<li><a href="{{ meeting_url(101) }}">Meeting 101</a> - August 3, 2004</li>
+<li><a href="{{ meeting_url(100) }}">Meeting 100</a> - July 27, 2004</li>
+<li><a href="{{ meeting_url(99) }}">Meeting 99</a> - July 20, 2004</li>
+<li><a href="{{ meeting_url(95) }}">Meeting 95</a></li>
+<li><a href="{{ meeting_url(93) }}">Meeting 93</a></li>
+<li><a href="{{ meeting_url(92) }}">Meeting 92</a></li>
+<li><a href="{{ meeting_url(90) }}">Meeting 90</a></li>
+<li><a href="{{ meeting_url(82) }}">Meeting 82</a></li>
+<li><a href="{{ meeting_url(81) }}">Meeting 81</a></li>
+<li><a href="{{ meeting_url(80) }}">Meeting 80</a></li>
+<li><a href="{{ meeting_url(79) }}">Meeting 79</a></li>
+<li><a href="{{ meeting_url(78) }}">Meeting 78</a></li>
+<li><a href="{{ meeting_url(77) }}">Meeting 77</a></li>
+<li><a href="{{ meeting_url(76) }}">Meeting 76</a></li>
+<li><a href="{{ meeting_url(75) }}">Meeting 75</a></li>
+<li><a href="{{ meeting_url(74) }}">Meeting 74</a></li>
+<li><a href="{{ meeting_url(73) }}">Meeting 73</a></li>
+<li><a href="{{ meeting_url(72) }}">Meeting 72</a></li>
+<li><a href="{{ meeting_url(71) }}">Meeting 71</a></li>
+<li><a href="{{ meeting_url(70) }}">Meeting 70</a></li>
+<li><a href="{{ meeting_url(69) }}">Meeting 69</a></li>
+<li><a href="{{ meeting_url(68) }}">Meeting 68</a></li>
+<li><a href="{{ meeting_url(66) }}">Meeting 66</a></li>
+<li><a href="{{ meeting_url(65) }}">Meeting 65</a></li>
+<li><a href="{{ meeting_url(64) }}">Meeting 64</a></li>
+<li><a href="{{ meeting_url(63) }}">Meeting 63</a></li>
+<li><a href="{{ meeting_url(62) }}">Meeting 62</a></li>
+<li><a href="{{ meeting_url(61) }}">Meeting 61</a></li>
+<li><a href="{{ meeting_url(60) }}">Meeting 60</a></li>
+<li><a href="{{ meeting_url(59) }}">Meeting 59</a></li>
+<li><a href="{{ meeting_url(58) }}">Meeting 58</a></li>
+<li><a href="{{ meeting_url(57) }}">Meeting 57</a></li>
+<li><a href="{{ meeting_url(56) }}">Meeting 56</a></li>
+<li><a href="{{ meeting_url(55) }}">Meeting 55</a></li>
+<li><a href="{{ meeting_url(54) }}">Meeting 54</a></li>
+<li><a href="{{ meeting_url(53) }}">Meeting 53</a></li>
+<li><a href="{{ meeting_url(52) }}">Meeting 52</a></li>
+<li><a href="{{ meeting_url(51) }}">Meeting 51</a></li>
+<li><a href="{{ meeting_url(50) }}">Meeting 50</a></li>
+<li><a href="{{ meeting_url(49) }}">Meeting 49</a></li>
+<li><a href="{{ meeting_url(47) }}">Meeting 47</a></li>
+<li><a href="{{ meeting_url(35) }}">Meeting 35</a></li>
+<li><a href="{{ meeting_url(34) }}">Meeting 34</a></li>
+<li><a href="{{ meeting_url(33) }}">Meeting 33</a></li>
+<li><a href="{{ meeting_url(32) }}">Meeting 32</a></li>
+<li><a href="{{ meeting_url(31) }}">Meeting 31</a></li>
+<li><a href="{{ meeting_url(30) }}">Meeting 30</a></li>
+<li><a href="{{ meeting_url(29) }}">Meeting 29</a></li>
+<li><a href="{{ meeting_url(28) }}">Meeting 28</a></li>
+<li><a href="{{ meeting_url(26) }}">Meeting 26</a></li>
+<li><a href="{{ meeting_url(25) }}">Meeting 25</a></li>
+<li><a href="{{ meeting_url(23) }}">Meeting 23</a></li>
+<li><a href="{{ meeting_url(22) }}">Meeting 22</a></li>
+<li><a href="{{ meeting_url(21) }}">Meeting 21</a></li>
+<li><a href="{{ meeting_url(20) }}">Meeting 20</a></li>
+<li><a href="{{ meeting_url(18) }}">Meeting 18</a></li>
+<li><a href="{{ meeting_url(15) }}">Meeting 15</a></li>
+<li><a href="{{ meeting_url(12) }}">Meeting 12</a></li>
+<li><a href="{{ meeting_url(11) }}">Meeting 11</a></li>
+<li><a href="{{ meeting_url(10) }}">Meeting 10</a></li>
+<li><a href="{{ meeting_url(9) }}">Meeting 9</a></li>
+<li><a href="{{ meeting_url(8) }}">Meeting 8</a></li>
+<li><a href="{{ meeting_url(7) }}">Meeting 7</a></li>
+<li><a href="{{ meeting_url(4) }}">Meeting 4</a></li>
+<li><a href="{{ meeting_url(3) }}">Meeting 3</a></li>
+<li><a href="{{ meeting_url(2) }}">Meeting 2</a></li>
+<li><a href="{{ meeting_url(1) }}">Meeting 1</a></li>
 
 </ul>
 {% endblock %}

From 2c982e8262b088d3e0c9e05caf09a7f5b2caadad Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 23:42:20 +0000
Subject: [PATCH 41/75] Overhauled the dropdown menus

---
 i2p2www/pages/global/lang.html   |   2 +-
 i2p2www/pages/global/layout.html |   1 -
 i2p2www/pages/global/nav.html    |  70 +++++++-----
 i2p2www/static/styles/duck.css   | 183 +++++++++++++++++++++++++++----
 4 files changed, 201 insertions(+), 55 deletions(-)

diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html
index c421597f..4d145bfb 100644
--- a/i2p2www/pages/global/lang.html
+++ b/i2p2www/pages/global/lang.html
@@ -5,7 +5,7 @@
 {%- else -%}{{ url_for('site_show', lang=lang) }}
 {%- endif -%}
 {%- endmacro -%}
-<ul class="languages nav">
+<ul class="languages">
   <li><a href="{{ change_lang('en') }}"><img src="{{ url_for('static', filename='images/us.png') }}" alt="English" /></a></li>
   <li><a href="{{ change_lang('es') }}"><img src="{{ url_for('static', filename='images/es.png') }}" alt="Castellano" /></a></li>
   <li><a href="{{ change_lang('zh') }}"><img src="{{ url_for('static', filename='images/zh.png') }}" alt="Chinese" /></a></li>
diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html
index 78fd3d7f..d66b24c6 100644
--- a/i2p2www/pages/global/layout.html
+++ b/i2p2www/pages/global/layout.html
@@ -14,7 +14,6 @@
       <div class="title">{{ self.title() }}</div>
     </div>
     <div class="navigation">
-      {% include "global/lang.html" %}
       {% include "global/nav.html" %}
     </div>
     <div id="content">
diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 6744c27d..73fd5e57 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -1,42 +1,54 @@
-<ul class="sections nav">
-  <li><a href="{{ url_for('site_show', lang=g.lang) }}">Home</a></li>
-  <li><a href="{{ url_for('downloads_list', lang=g.lang) }}">Download</a></li>
-  <li><a href="#">Docs</a>
+<div id="cssmenu">
+<ul>
+  <li><a href="{{ url_for('site_show', lang=g.lang) }}"><span>Home</span></a></li>
+  <li><a href="{{ url_for('downloads_list', lang=g.lang) }}"><span>Download</span></a></li>
+  <li class="has-sub"><a href="#"><span>Docs</span></a>
     <ul>
-      <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}"> How does it work?</a></li>
-      <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}"> Tech intro</a></li>
-      <li><a href="howto.html"> Howto docs</a></li>
-      <li><a href="applications.html"> Applications</a></li>
+      <li class="has-sub"><a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}"><span>How does it work?</span></a>
+        <ul>
+          <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}"><span>Gentle intro</span></a></li>
+          <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}"><span>Tech intro</span></a></li>
+        </ul>
+      </li>
+      <li><a href="howto.html"><span>Howto docs</span></a></li>
+      <li><a href="applications.html"><span>Applications</span></a></li>
     </ul>
   </li>
-  <li><a href='#'>Support</a></li>
-  <li><a href="getinvolved.html">Develop</a>
+  <li class="has-sub"><a href="#"><span>Support</span></a>
     <ul>
-      <li><a href="api.html"> API</a></li>
-      <li><a href="licenses.html"> Licenses</a></li>
-      <li><a href="http://trac.i2p2.i2p/"> Trac</a></li>
+      <li><a href="faq.html"><span>FAQ</span></a></li>
+      <li><a href="http://forum.i2p2.de/"><span>Forums</span></a></li>
     </ul>
   </li>
-  <li><a href='#'>Volunteer</a></li>
-  <li><a href="#">News</a>
+  <li class="has-sub"><a href="getinvolved.html"><span>Develop</span></a>
+    <ul>
+      <li><a href="api.html"><span>API</span></a></li>
+      <li><a href="licenses.html"><span>Licenses</span></a></li>
+      <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
+    </ul>
+  </li>
+  <li><a href="#"><span>Volunteer</span></a></li>
+  <li class="has-sub"><a href="#"><span>News</span></a>
     <ul class="leftbutton">
-      <li><a href="{{ url_for('blog_index', lang=g.lang) }}"> Announcements</a></li>
-      <li><a href="{{ url_for('meetings_index', lang=g.lang) }}"> Meetings</a></li>
-      <li><a href="roadmap.html"> Roadmap</a></li>
-      <li><a href="todo.html"> Task list</a></li>
+      <li><a href="{{ url_for('blog_index', lang=g.lang) }}"><span>Announcements</span></a></li>
+      <li><a href="{{ url_for('meetings_index', lang=g.lang) }}"><span>Meetings</span></a></li>
+      <li><a href="roadmap.html"><span>Roadmap</span></a></li>
+      <li><a href="todo.html"><span>Task list</span></a></li>
     </ul>
   </li>
-  <li><a href="#">About</a>
+  <li class="has-sub"><a href="#"><span>About</span></a>
     <ul>
-      <li><a href="faq.html"> FAQ</a></li>
-      <li><a href="http://forum.i2p2.de/"> Forums</a></li>
-      <li><a href="bounties.html"> Bounties</a></li>
-      <li><a href="getinvolved.html"> Get involved</a></li>
-      <li><a href="donate.html"> Donate!</a></li>
-      <li><a href="team.html"> I2P Team</a></li>
-      <li><a href="halloffame.html"> Hall of Fame</a></li>
-      <li><a href="links.html"> Links</a></li>
-      <li><a href="impressum.html"> Impressum</a></li>
+      <li><a href="bounties.html"><span>Bounties</span></a></li>
+      <li><a href="getinvolved.html"><span>Get involved</span></a></li>
+      <li><a href="donate.html"><span>Donate!</span></a></li>
+      <li><a href="team.html"><span>I2P Team</span></a></li>
+      <li><a href="halloffame.html"><span>Hall of Fame</span></a></li>
+      <li><a href="links.html"><span>Links</span></a></li>
+      <li><a href="impressum.html"><span>Impressum</span></a></li>
     </ul>
   </li>
+  <li class="has-sub right"><a href="#"><span>Language</span></a>
+    {% include "global/lang.html" %}
+  </li>
 </ul>
+</div>
diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css
index 55c3d39a..c5ff0a22 100644
--- a/i2p2www/static/styles/duck.css
+++ b/i2p2www/static/styles/duck.css
@@ -20,30 +20,165 @@ div#branding {width:80%; margin:1em auto; position:relative;}
     }
 
 div.navigation {position:relative;}
-    ul.nav li {display:inline-block; *display:inline; *zoom:1;}
-ul.languages {width:130px; position:absolute; right:10%; top:0;}
-ul.sections {margin:1em 10%; padding-right:130px;}
-ul.sections li {
-    font-size:2em; font-family:"URW Gothic L", "Century Gothic", sans-serif;
-    font-weight:bold; margin:0 1.3em 0 0; text-shadow:1px 1px 1px rgba(100,20,20,.2);
-    position:relative;}
-    ul.sections li ul {display:none; padding:1px; z-index:1;}
-    ul.sections li:hover ul, ul.sections li a:hover ul {
-        display:block; position:absolute; margin:0; top:24px; left:-1px; height:auto;
-        width:13.5em; background:black;}
-    ul.sections li:hover ul li a, u.sections li a:hover ul li a {
-        border:0; margin:0; padding:0; height:auto;
-        width:13.5em; background:#d8d8d8;}
-    ul.sections li:hover ul li:hover a, u.sections li a:hover ul li a:hover {
-        background:white;}
-    ul.sections li:hover ul li ul, ul.sections li a:hover ul li a ul {visibility:hidden;}
-    ul.sections li:hover ul li:hover ul, ul.sections li a:hover ul li a:hover ul {
-        visibility:visible; position:absolute; margin-top:-1px; top:0;
-        left:8.08333em; width:14em;}
-    ul.sections li:hover ul li:hover ul li a, ul.sections li a:hover ul li a:hover ul li a {
-        width:14em; background:#d8d8d8;}
-    ul.sections li:hover ul li:hover ul li a:hover, ul.sections li a:hover ul li a:hover ul li a:hover {
-        width:14em; background:white;}
+    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 a {
+  margin: 0;
+  padding: 0;
+  position: relative;
+}
+#cssmenu {
+  height: 49px;
+  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 a {
+  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;
+  display: inline-block;
+  font-family: "URW Gothic L", "Century Gothic", sans-serif;
+  font-size: 11pt;
+  font-weight: bold;
+  text-shadow: 1px 1px 1px rgba(100,20,20,.2);
+  line-height: 49px;
+  padding: 0 20px;
+  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;
+  margin-left: -10px;
+}
+#cssmenu > ul > li:first-child > a {
+  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 > a {
+  border-radius: 0 5px 0 0;
+  -moz-border-radius: 0 5px 0 0;
+  -webkit-border-radius: 0 5px 0 0;
+}
+#cssmenu > ul > li.active > a {
+  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 > a {
+  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 {
+  *margin-bottom: -1px;
+}
+#cssmenu .has-sub ul li a {
+  background: #0fa1e0;
+  border-bottom: 1px dotted #6fc7ec;
+  filter: none;
+  font-size: 9pt;
+  display: block;
+  line-height: 120%;
+  padding: 10px;
+}
+#cssmenu .has-sub ul li:hover a {
+  background: #0c7fb0;
+}
+#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 a {
+  background: #0c7fb0;
+  border-bottom: 1px dotted #6db2d0;
+}
+#cssmenu .has-sub .has-sub ul li a:hover {
+  background: #095c80;
+}
+
+/* End of dropdown menu CSS */
 
 div#content {display:block;}
     /**

From 0a2cb5f89cf4bc494b6ea530c0d4c7d688936727 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 13 Sep 2012 23:56:35 +0000
Subject: [PATCH 42/75] Reorganised menu and footer links

---
 i2p2www/pages/global/footer.html | 33 +++++++-------------------------
 i2p2www/pages/global/nav.html    | 19 +++---------------
 2 files changed, 10 insertions(+), 42 deletions(-)

diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html
index 314bc691..c646dcc9 100644
--- a/i2p2www/pages/global/footer.html
+++ b/i2p2www/pages/global/footer.html
@@ -1,59 +1,40 @@
       <div class='aside first'>
         <h1>News</h1>
         <ul>
-          <li><a href="announcements.html">Announcements</a></li>
-          <li><a href="meetings.html">Meetings</a></li>
-          <li><a href="roadmap.html">Roadmap</a></li>
-          <li><a href="todo.html">Task list</a></li>
+          <li><a href="{{ url_for('blog_index', lang=g.lang) }}">Announcements</a></li>
+          <li><a href="{{ url_for('meetings_index', lang=g.lang) }}">Meetings</a></li>
         </ul>
       </div>
       <div class='aside second'>
         <h1>About I2P</h1>
         <ul>
-          <li><a href="faq.html">FAQ</a></li>
-          <li><a href="http://forum.i2p2.de/">Forums</a></li>
-          <li><a href="bounties.html">Bounties</a></li>
-          <li><a href="getinvolved.html">Get involved</a></li>
-          <li><a href="donate.html">Donate!</a></li>
           <li><a href="team.html">I2P Team</a></li>
           <li><a href="halloffame.html">Hall of Fame</a></li>
         </ul>
       </div>
       <div class='aside third'>
-        <h1>Documentation</h1>
-        <ul>
-          <li><a href="how.html">How does it work?</a></li>
-          <li><a href="techintro.html">Tech intro</a></li>
-          <li><a href="applications.html">App Dev</a></li>
-        </ul>
-      </div>
-      <div class='aside fourth'>
-        <h1>Development</h1>
-        <ul>
-          <li><a href="http://docs.i2p2.de/javadoc/">API</a></li>
-          <li><a href="licenses.html">Licenses</a></li>
-          <li><a href="http://trac.i2p2.de/report/1">Report a Bug</a></li>
-        </ul>
-      </div>
-      <div class='aside fifth'>
         <h1>Mirrors</h1>
         <ul>
           <li><a rel="nofollow" href="http://i2pproject.net/">http://i2pproject.net</a></li>
           <li><a rel="nofollow" href="http://i2p.us/">http://i2p.us</a></li>
           <li><a rel="nofollow" href="http://i2p-projekt.de/">http://i2p-projeckt.de</a></li>
         </ul>
+      </div>
+      <div class='aside fourth'>
         <h1>Secure</h1>
         <ul>
           <li><a rel="nofollow" href="https://www.i2p2.de/">https://www.i2p2.de</a></li>
           <li><a rel="nofollow" href="https://i2p.us/">https://i2p.us</a></li>
         </ul>
       </div>
-      <div class='aside sixth'>
+      <div class='aside fifth'>
         <h1>Misc.</h1>
         <ul>
           <li><a href="http://syndie.i2p2.de/">Syndie</a></li>
           <li><a href="links.html">Links</a></li>
           <li><a href="impressum.html">Impressum</a></li>
         </ul>
+      </div>
+      <div class='aside sixth'>
         <a class='button' href='#donate'>Donate</a>
       </div>
diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 73fd5e57..2b5a0f3c 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -27,24 +27,11 @@
       <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
-  <li><a href="#"><span>Volunteer</span></a></li>
-  <li class="has-sub"><a href="#"><span>News</span></a>
-    <ul class="leftbutton">
-      <li><a href="{{ url_for('blog_index', lang=g.lang) }}"><span>Announcements</span></a></li>
-      <li><a href="{{ url_for('meetings_index', lang=g.lang) }}"><span>Meetings</span></a></li>
-      <li><a href="roadmap.html"><span>Roadmap</span></a></li>
-      <li><a href="todo.html"><span>Task list</span></a></li>
-    </ul>
-  </li>
-  <li class="has-sub"><a href="#"><span>About</span></a>
+  <li class="has-sub"><a href="#"><span>Volunteer</span></a>
     <ul>
       <li><a href="bounties.html"><span>Bounties</span></a></li>
-      <li><a href="getinvolved.html"><span>Get involved</span></a></li>
-      <li><a href="donate.html"><span>Donate!</span></a></li>
-      <li><a href="team.html"><span>I2P Team</span></a></li>
-      <li><a href="halloffame.html"><span>Hall of Fame</span></a></li>
-      <li><a href="links.html"><span>Links</span></a></li>
-      <li><a href="impressum.html"><span>Impressum</span></a></li>
+      <li><a href="roadmap.html"><span>Roadmap</span></a></li>
+      <li><a href="todo.html"><span>Task list</span></a></li>
     </ul>
   </li>
   <li class="has-sub right"><a href="#"><span>Language</span></a>

From b13744ae18ac3b69b496abb8ba4f77497b01be02 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 00:13:38 +0000
Subject: [PATCH 43/75] Bugfix to get blog entries to render

---
 i2p2www/__init__.py            | 2 +-
 i2p2www/pages/global/lang.html | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index be03a629..44071e11 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -280,7 +280,7 @@ def blog_entry(slug):
 
     if parts:
         # now just pass to simple template file and we are done
-        return render_template('blog/entry.html', parts=parts, title=parts['title'], body=parts['fragment'])
+        return render_template('blog/entry.html', parts=parts, title=parts['title'], body=parts['fragment'], slug=slug)
     else:
         abort(404)
 
diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html
index 4d145bfb..4c09d66e 100644
--- a/i2p2www/pages/global/lang.html
+++ b/i2p2www/pages/global/lang.html
@@ -1,5 +1,6 @@
 {%- macro change_lang(lang) -%}
 {%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
+{%- elif request.endpoint == 'blog_entry' -%}{{ url_for('blog_entry', lang=lang, slug=slug) }}
 {%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }}
 {%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
 {%- else -%}{{ url_for('site_show', lang=lang) }}

From 6c1d7c5318f4efaabe27500b3ae74bb55e0b5d53 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 01:10:10 +0000
Subject: [PATCH 44/75] Beginning of migration of status notes

---
 .../blog/2004/07/13/status.html                             | 0
 i2p2www/blog/2004/07/13/status.rst                          | 6 ++++++
 .../blog/2004/07/20/status.html                             | 0
 i2p2www/blog/2004/07/20/status.rst                          | 6 ++++++
 .../blog/2004/07/27/status.html                             | 0
 i2p2www/blog/2004/07/27/status.rst                          | 6 ++++++
 .../blog/2004/08/03/status.html                             | 0
 i2p2www/blog/2004/08/03/status.rst                          | 6 ++++++
 .../blog/2004/08/10/status.html                             | 0
 i2p2www/blog/2004/08/10/status.rst                          | 6 ++++++
 .../blog/2004/08/17/status.html                             | 0
 i2p2www/blog/2004/08/17/status.rst                          | 6 ++++++
 .../blog/2004/08/24/status.html                             | 0
 i2p2www/blog/2004/08/24/status.rst                          | 6 ++++++
 .../blog/2004/08/31/status.html                             | 0
 i2p2www/blog/2004/08/31/status.rst                          | 6 ++++++
 .../blog/2004/09/08/status.html                             | 0
 i2p2www/blog/2004/09/08/status.rst                          | 6 ++++++
 .../blog/2004/09/14/status.html                             | 0
 i2p2www/blog/2004/09/14/status.rst                          | 6 ++++++
 .../blog/2004/09/21/status.html                             | 0
 i2p2www/blog/2004/09/21/status.rst                          | 6 ++++++
 .../blog/2004/09/28/status.html                             | 0
 i2p2www/blog/2004/09/28/status.rst                          | 6 ++++++
 .../blog/2004/10/05/status.html                             | 0
 i2p2www/blog/2004/10/05/status.rst                          | 6 ++++++
 .../blog/2004/10/12/status.html                             | 0
 i2p2www/blog/2004/10/12/status.rst                          | 6 ++++++
 .../blog/2004/10/19/status.html                             | 0
 i2p2www/blog/2004/10/19/status.rst                          | 6 ++++++
 .../blog/2004/10/26/status.html                             | 0
 i2p2www/blog/2004/10/26/status.rst                          | 6 ++++++
 .../blog/2004/11/02/status.html                             | 0
 i2p2www/blog/2004/11/02/status.rst                          | 6 ++++++
 .../blog/2004/11/09/status.html                             | 0
 i2p2www/blog/2004/11/09/status.rst                          | 6 ++++++
 .../blog/2004/11/16/status.html                             | 0
 i2p2www/blog/2004/11/16/status.rst                          | 6 ++++++
 .../blog/2004/11/23/status.html                             | 0
 i2p2www/blog/2004/11/23/status.rst                          | 6 ++++++
 .../blog/2004/11/30/status.html                             | 0
 i2p2www/blog/2004/11/30/status.rst                          | 6 ++++++
 .../blog/2004/12/07/status.html                             | 0
 i2p2www/blog/2004/12/07/status.rst                          | 6 ++++++
 .../blog/2004/12/14/status.html                             | 0
 i2p2www/blog/2004/12/14/status.rst                          | 6 ++++++
 .../blog/2004/12/21/status.html                             | 0
 i2p2www/blog/2004/12/21/status.rst                          | 6 ++++++
 .../blog/2004/12/28/status.html                             | 0
 i2p2www/blog/2004/12/28/status.rst                          | 6 ++++++
 .../blog/2005/01/04/status.html                             | 0
 i2p2www/blog/2005/01/04/status.rst                          | 6 ++++++
 .../blog/2005/01/11/status.html                             | 0
 i2p2www/blog/2005/01/11/status.rst                          | 6 ++++++
 .../blog/2005/01/18/status.html                             | 0
 i2p2www/blog/2005/01/18/status.rst                          | 6 ++++++
 .../blog/2005/01/25/status.html                             | 0
 i2p2www/blog/2005/01/25/status.rst                          | 6 ++++++
 .../blog/2005/02/01/status.html                             | 0
 i2p2www/blog/2005/02/01/status.rst                          | 6 ++++++
 .../blog/2005/02/08/status.html                             | 0
 i2p2www/blog/2005/02/08/status.rst                          | 6 ++++++
 .../blog/2005/02/15/status.html                             | 0
 i2p2www/blog/2005/02/15/status.rst                          | 6 ++++++
 .../blog/2005/02/22/status.html                             | 0
 i2p2www/blog/2005/02/22/status.rst                          | 6 ++++++
 .../blog/2005/03/01/status.html                             | 0
 i2p2www/blog/2005/03/01/status.rst                          | 6 ++++++
 .../blog/2005/03/08/status.html                             | 0
 i2p2www/blog/2005/03/08/status.rst                          | 6 ++++++
 .../blog/2005/03/15/status.html                             | 0
 i2p2www/blog/2005/03/15/status.rst                          | 6 ++++++
 .../blog/2005/03/22/status.html                             | 0
 i2p2www/blog/2005/03/22/status.rst                          | 6 ++++++
 .../blog/2005/03/29/status.html                             | 0
 i2p2www/blog/2005/03/29/status.rst                          | 6 ++++++
 .../blog/2005/04/05/status.html                             | 0
 i2p2www/blog/2005/04/05/status.rst                          | 6 ++++++
 .../blog/2005/04/12/status.html                             | 0
 i2p2www/blog/2005/04/12/status.rst                          | 6 ++++++
 .../blog/2005/04/19/status.html                             | 0
 i2p2www/blog/2005/04/19/status.rst                          | 6 ++++++
 .../blog/2005/04/26/status.html                             | 0
 i2p2www/blog/2005/04/26/status.rst                          | 6 ++++++
 .../blog/2005/05/03/status.html                             | 0
 i2p2www/blog/2005/05/03/status.rst                          | 6 ++++++
 .../blog/2005/06/21/status.html                             | 0
 i2p2www/blog/2005/06/21/status.rst                          | 6 ++++++
 .../blog/2005/06/28/status.html                             | 0
 i2p2www/blog/2005/06/28/status.rst                          | 6 ++++++
 .../blog/2005/07/05/status.html                             | 0
 i2p2www/blog/2005/07/05/status.rst                          | 6 ++++++
 .../blog/2005/07/12/status.html                             | 0
 i2p2www/blog/2005/07/12/status.rst                          | 6 ++++++
 .../blog/2005/07/19/status.html                             | 0
 i2p2www/blog/2005/07/19/status.rst                          | 6 ++++++
 .../blog/2005/07/26/status.html                             | 0
 i2p2www/blog/2005/07/26/status.rst                          | 6 ++++++
 .../blog/2005/08/02/status.html                             | 0
 i2p2www/blog/2005/08/02/status.rst                          | 6 ++++++
 .../blog/2005/08/09/status.html                             | 0
 i2p2www/blog/2005/08/09/status.rst                          | 6 ++++++
 .../blog/2005/08/16/status.html                             | 0
 i2p2www/blog/2005/08/16/status.rst                          | 6 ++++++
 .../blog/2005/08/23/status.html                             | 0
 i2p2www/blog/2005/08/23/status.rst                          | 6 ++++++
 .../blog/2005/08/30/status.html                             | 0
 i2p2www/blog/2005/08/30/status.rst                          | 6 ++++++
 .../blog/2005/09/06/status.html                             | 0
 i2p2www/blog/2005/09/06/status.rst                          | 6 ++++++
 .../blog/2005/09/13/status.html                             | 0
 i2p2www/blog/2005/09/13/status.rst                          | 6 ++++++
 .../blog/2005/09/20/status.html                             | 0
 i2p2www/blog/2005/09/20/status.rst                          | 6 ++++++
 .../blog/2005/10/04/status.html                             | 0
 i2p2www/blog/2005/10/04/status.rst                          | 6 ++++++
 .../blog/2005/10/11/status.html                             | 0
 i2p2www/blog/2005/10/11/status.rst                          | 6 ++++++
 .../blog/2005/10/18/status.html                             | 0
 i2p2www/blog/2005/10/18/status.rst                          | 6 ++++++
 .../blog/2005/10/25/status.html                             | 0
 i2p2www/blog/2005/10/25/status.rst                          | 6 ++++++
 .../blog/2005/11/01/status.html                             | 0
 i2p2www/blog/2005/11/01/status.rst                          | 6 ++++++
 .../blog/2005/11/08/status.html                             | 0
 i2p2www/blog/2005/11/08/status.rst                          | 6 ++++++
 .../blog/2005/11/15/status.html                             | 0
 i2p2www/blog/2005/11/15/status.rst                          | 6 ++++++
 .../blog/2005/11/22/status.html                             | 0
 i2p2www/blog/2005/11/22/status.rst                          | 6 ++++++
 .../blog/2005/11/29/status.html                             | 0
 i2p2www/blog/2005/11/29/status.rst                          | 6 ++++++
 .../blog/2005/12/06/status.html                             | 0
 i2p2www/blog/2005/12/06/status.rst                          | 6 ++++++
 .../blog/2005/12/13/status.html                             | 0
 i2p2www/blog/2005/12/13/status.rst                          | 6 ++++++
 .../blog/2005/12/20/status.html                             | 0
 i2p2www/blog/2005/12/20/status.rst                          | 6 ++++++
 .../blog/2006/01/03/status.html                             | 0
 i2p2www/blog/2006/01/03/status.rst                          | 6 ++++++
 .../blog/2006/01/10/status.html                             | 0
 i2p2www/blog/2006/01/10/status.rst                          | 6 ++++++
 .../blog/2006/01/17/status.html                             | 0
 i2p2www/blog/2006/01/17/status.rst                          | 6 ++++++
 .../blog/2006/01/24/status.html                             | 0
 i2p2www/blog/2006/01/24/status.rst                          | 6 ++++++
 .../blog/2006/01/31/status.html                             | 0
 i2p2www/blog/2006/01/31/status.rst                          | 6 ++++++
 .../blog/2006/02/07/status.html                             | 0
 i2p2www/blog/2006/02/07/status.rst                          | 6 ++++++
 .../blog/2006/02/14/status.html                             | 0
 i2p2www/blog/2006/02/14/status.rst                          | 6 ++++++
 .../blog/2006/02/21/status.html                             | 0
 i2p2www/blog/2006/02/21/status.rst                          | 6 ++++++
 .../blog/2006/02/28/status.html                             | 0
 i2p2www/blog/2006/02/28/status.rst                          | 6 ++++++
 .../blog/2006/03/07/status.html                             | 0
 i2p2www/blog/2006/03/07/status.rst                          | 6 ++++++
 .../blog/2006/03/14/status.html                             | 0
 i2p2www/blog/2006/03/14/status.rst                          | 6 ++++++
 .../blog/2006/03/21/status.html                             | 0
 i2p2www/blog/2006/03/21/status.rst                          | 6 ++++++
 .../blog/2006/03/28/status.html                             | 0
 i2p2www/blog/2006/03/28/status.rst                          | 6 ++++++
 .../blog/2006/04/04/status.html                             | 0
 i2p2www/blog/2006/04/04/status.rst                          | 6 ++++++
 .../blog/2006/04/18/status.html                             | 0
 i2p2www/blog/2006/04/18/status.rst                          | 6 ++++++
 .../blog/2006/04/25/status.html                             | 0
 i2p2www/blog/2006/04/25/status.rst                          | 6 ++++++
 .../blog/2006/05/02/status.html                             | 0
 i2p2www/blog/2006/05/02/status.rst                          | 6 ++++++
 .../blog/2006/05/09/status.html                             | 0
 i2p2www/blog/2006/05/09/status.rst                          | 6 ++++++
 .../blog/2006/05/16/status.html                             | 0
 i2p2www/blog/2006/05/16/status.rst                          | 6 ++++++
 .../blog/2006/05/30/status.html                             | 0
 i2p2www/blog/2006/05/30/status.rst                          | 6 ++++++
 .../blog/2006/06/13/status.html                             | 0
 i2p2www/blog/2006/06/13/status.rst                          | 6 ++++++
 .../blog/2006/08/01/status.html                             | 0
 i2p2www/blog/2006/08/01/status.rst                          | 6 ++++++
 .../blog/2006/09/12/status.html                             | 0
 i2p2www/blog/2006/09/12/status.rst                          | 6 ++++++
 .../blog/2006/10/03/status.html                             | 0
 i2p2www/blog/2006/10/03/status.rst                          | 6 ++++++
 .../blog/2008/02/01/status.html                             | 0
 i2p2www/blog/2008/02/01/status.rst                          | 6 ++++++
 188 files changed, 564 insertions(+)
 rename www.i2p2/pages/status-2004-07-13.html => i2p2www/blog/2004/07/13/status.html (100%)
 create mode 100644 i2p2www/blog/2004/07/13/status.rst
 rename www.i2p2/pages/status-2004-07-20.html => i2p2www/blog/2004/07/20/status.html (100%)
 create mode 100644 i2p2www/blog/2004/07/20/status.rst
 rename www.i2p2/pages/status-2004-07-27.html => i2p2www/blog/2004/07/27/status.html (100%)
 create mode 100644 i2p2www/blog/2004/07/27/status.rst
 rename www.i2p2/pages/status-2004-08-03.html => i2p2www/blog/2004/08/03/status.html (100%)
 create mode 100644 i2p2www/blog/2004/08/03/status.rst
 rename www.i2p2/pages/status-2004-08-10.html => i2p2www/blog/2004/08/10/status.html (100%)
 create mode 100644 i2p2www/blog/2004/08/10/status.rst
 rename www.i2p2/pages/status-2004-08-17.html => i2p2www/blog/2004/08/17/status.html (100%)
 create mode 100644 i2p2www/blog/2004/08/17/status.rst
 rename www.i2p2/pages/status-2004-08-24.html => i2p2www/blog/2004/08/24/status.html (100%)
 create mode 100644 i2p2www/blog/2004/08/24/status.rst
 rename www.i2p2/pages/status-2004-08-31.html => i2p2www/blog/2004/08/31/status.html (100%)
 create mode 100644 i2p2www/blog/2004/08/31/status.rst
 rename www.i2p2/pages/status-2004-09-08.html => i2p2www/blog/2004/09/08/status.html (100%)
 create mode 100644 i2p2www/blog/2004/09/08/status.rst
 rename www.i2p2/pages/status-2004-09-14.html => i2p2www/blog/2004/09/14/status.html (100%)
 create mode 100644 i2p2www/blog/2004/09/14/status.rst
 rename www.i2p2/pages/status-2004-09-21.html => i2p2www/blog/2004/09/21/status.html (100%)
 create mode 100644 i2p2www/blog/2004/09/21/status.rst
 rename www.i2p2/pages/status-2004-09-28.html => i2p2www/blog/2004/09/28/status.html (100%)
 create mode 100644 i2p2www/blog/2004/09/28/status.rst
 rename www.i2p2/pages/status-2004-10-05.html => i2p2www/blog/2004/10/05/status.html (100%)
 create mode 100644 i2p2www/blog/2004/10/05/status.rst
 rename www.i2p2/pages/status-2004-10-12.html => i2p2www/blog/2004/10/12/status.html (100%)
 create mode 100644 i2p2www/blog/2004/10/12/status.rst
 rename www.i2p2/pages/status-2004-10-19.html => i2p2www/blog/2004/10/19/status.html (100%)
 create mode 100644 i2p2www/blog/2004/10/19/status.rst
 rename www.i2p2/pages/status-2004-10-26.html => i2p2www/blog/2004/10/26/status.html (100%)
 create mode 100644 i2p2www/blog/2004/10/26/status.rst
 rename www.i2p2/pages/status-2004-11-02.html => i2p2www/blog/2004/11/02/status.html (100%)
 create mode 100644 i2p2www/blog/2004/11/02/status.rst
 rename www.i2p2/pages/status-2004-11-09.html => i2p2www/blog/2004/11/09/status.html (100%)
 create mode 100644 i2p2www/blog/2004/11/09/status.rst
 rename www.i2p2/pages/status-2004-11-16.html => i2p2www/blog/2004/11/16/status.html (100%)
 create mode 100644 i2p2www/blog/2004/11/16/status.rst
 rename www.i2p2/pages/status-2004-11-23.html => i2p2www/blog/2004/11/23/status.html (100%)
 create mode 100644 i2p2www/blog/2004/11/23/status.rst
 rename www.i2p2/pages/status-2004-11-30.html => i2p2www/blog/2004/11/30/status.html (100%)
 create mode 100644 i2p2www/blog/2004/11/30/status.rst
 rename www.i2p2/pages/status-2004-12-07.html => i2p2www/blog/2004/12/07/status.html (100%)
 create mode 100644 i2p2www/blog/2004/12/07/status.rst
 rename www.i2p2/pages/status-2004-12-14.html => i2p2www/blog/2004/12/14/status.html (100%)
 create mode 100644 i2p2www/blog/2004/12/14/status.rst
 rename www.i2p2/pages/status-2004-12-21.html => i2p2www/blog/2004/12/21/status.html (100%)
 create mode 100644 i2p2www/blog/2004/12/21/status.rst
 rename www.i2p2/pages/status-2004-12-28.html => i2p2www/blog/2004/12/28/status.html (100%)
 create mode 100644 i2p2www/blog/2004/12/28/status.rst
 rename www.i2p2/pages/status-2005-01-04.html => i2p2www/blog/2005/01/04/status.html (100%)
 create mode 100644 i2p2www/blog/2005/01/04/status.rst
 rename www.i2p2/pages/status-2005-01-11.html => i2p2www/blog/2005/01/11/status.html (100%)
 create mode 100644 i2p2www/blog/2005/01/11/status.rst
 rename www.i2p2/pages/status-2005-01-18.html => i2p2www/blog/2005/01/18/status.html (100%)
 create mode 100644 i2p2www/blog/2005/01/18/status.rst
 rename www.i2p2/pages/status-2005-01-25.html => i2p2www/blog/2005/01/25/status.html (100%)
 create mode 100644 i2p2www/blog/2005/01/25/status.rst
 rename www.i2p2/pages/status-2005-02-01.html => i2p2www/blog/2005/02/01/status.html (100%)
 create mode 100644 i2p2www/blog/2005/02/01/status.rst
 rename www.i2p2/pages/status-2005-02-08.html => i2p2www/blog/2005/02/08/status.html (100%)
 create mode 100644 i2p2www/blog/2005/02/08/status.rst
 rename www.i2p2/pages/status-2005-02-15.html => i2p2www/blog/2005/02/15/status.html (100%)
 create mode 100644 i2p2www/blog/2005/02/15/status.rst
 rename www.i2p2/pages/status-2005-02-22.html => i2p2www/blog/2005/02/22/status.html (100%)
 create mode 100644 i2p2www/blog/2005/02/22/status.rst
 rename www.i2p2/pages/status-2005-03-01.html => i2p2www/blog/2005/03/01/status.html (100%)
 create mode 100644 i2p2www/blog/2005/03/01/status.rst
 rename www.i2p2/pages/status-2005-03-08.html => i2p2www/blog/2005/03/08/status.html (100%)
 create mode 100644 i2p2www/blog/2005/03/08/status.rst
 rename www.i2p2/pages/status-2005-03-15.html => i2p2www/blog/2005/03/15/status.html (100%)
 create mode 100644 i2p2www/blog/2005/03/15/status.rst
 rename www.i2p2/pages/status-2005-03-22.html => i2p2www/blog/2005/03/22/status.html (100%)
 create mode 100644 i2p2www/blog/2005/03/22/status.rst
 rename www.i2p2/pages/status-2005-03-29.html => i2p2www/blog/2005/03/29/status.html (100%)
 create mode 100644 i2p2www/blog/2005/03/29/status.rst
 rename www.i2p2/pages/status-2005-04-05.html => i2p2www/blog/2005/04/05/status.html (100%)
 create mode 100644 i2p2www/blog/2005/04/05/status.rst
 rename www.i2p2/pages/status-2005-04-12.html => i2p2www/blog/2005/04/12/status.html (100%)
 create mode 100644 i2p2www/blog/2005/04/12/status.rst
 rename www.i2p2/pages/status-2005-04-19.html => i2p2www/blog/2005/04/19/status.html (100%)
 create mode 100644 i2p2www/blog/2005/04/19/status.rst
 rename www.i2p2/pages/status-2005-04-26.html => i2p2www/blog/2005/04/26/status.html (100%)
 create mode 100644 i2p2www/blog/2005/04/26/status.rst
 rename www.i2p2/pages/status-2005-05-03.html => i2p2www/blog/2005/05/03/status.html (100%)
 create mode 100644 i2p2www/blog/2005/05/03/status.rst
 rename www.i2p2/pages/status-2005-06-21.html => i2p2www/blog/2005/06/21/status.html (100%)
 create mode 100644 i2p2www/blog/2005/06/21/status.rst
 rename www.i2p2/pages/status-2005-06-28.html => i2p2www/blog/2005/06/28/status.html (100%)
 create mode 100644 i2p2www/blog/2005/06/28/status.rst
 rename www.i2p2/pages/status-2005-07-05.html => i2p2www/blog/2005/07/05/status.html (100%)
 create mode 100644 i2p2www/blog/2005/07/05/status.rst
 rename www.i2p2/pages/status-2005-07-12.html => i2p2www/blog/2005/07/12/status.html (100%)
 create mode 100644 i2p2www/blog/2005/07/12/status.rst
 rename www.i2p2/pages/status-2005-07-19.html => i2p2www/blog/2005/07/19/status.html (100%)
 create mode 100644 i2p2www/blog/2005/07/19/status.rst
 rename www.i2p2/pages/status-2005-07-26.html => i2p2www/blog/2005/07/26/status.html (100%)
 create mode 100644 i2p2www/blog/2005/07/26/status.rst
 rename www.i2p2/pages/status-2005-08-02.html => i2p2www/blog/2005/08/02/status.html (100%)
 create mode 100644 i2p2www/blog/2005/08/02/status.rst
 rename www.i2p2/pages/status-2005-08-09.html => i2p2www/blog/2005/08/09/status.html (100%)
 create mode 100644 i2p2www/blog/2005/08/09/status.rst
 rename www.i2p2/pages/status-2005-08-16.html => i2p2www/blog/2005/08/16/status.html (100%)
 create mode 100644 i2p2www/blog/2005/08/16/status.rst
 rename www.i2p2/pages/status-2005-08-23.html => i2p2www/blog/2005/08/23/status.html (100%)
 create mode 100644 i2p2www/blog/2005/08/23/status.rst
 rename www.i2p2/pages/status-2005-08-30.html => i2p2www/blog/2005/08/30/status.html (100%)
 create mode 100644 i2p2www/blog/2005/08/30/status.rst
 rename www.i2p2/pages/status-2005-09-06.html => i2p2www/blog/2005/09/06/status.html (100%)
 create mode 100644 i2p2www/blog/2005/09/06/status.rst
 rename www.i2p2/pages/status-2005-09-13.html => i2p2www/blog/2005/09/13/status.html (100%)
 create mode 100644 i2p2www/blog/2005/09/13/status.rst
 rename www.i2p2/pages/status-2005-09-20.html => i2p2www/blog/2005/09/20/status.html (100%)
 create mode 100644 i2p2www/blog/2005/09/20/status.rst
 rename www.i2p2/pages/status-2005-10-04.html => i2p2www/blog/2005/10/04/status.html (100%)
 create mode 100644 i2p2www/blog/2005/10/04/status.rst
 rename www.i2p2/pages/status-2005-10-11.html => i2p2www/blog/2005/10/11/status.html (100%)
 create mode 100644 i2p2www/blog/2005/10/11/status.rst
 rename www.i2p2/pages/status-2005-10-18.html => i2p2www/blog/2005/10/18/status.html (100%)
 create mode 100644 i2p2www/blog/2005/10/18/status.rst
 rename www.i2p2/pages/status-2005-10-25.html => i2p2www/blog/2005/10/25/status.html (100%)
 create mode 100644 i2p2www/blog/2005/10/25/status.rst
 rename www.i2p2/pages/status-2005-11-01.html => i2p2www/blog/2005/11/01/status.html (100%)
 create mode 100644 i2p2www/blog/2005/11/01/status.rst
 rename www.i2p2/pages/status-2005-11-08.html => i2p2www/blog/2005/11/08/status.html (100%)
 create mode 100644 i2p2www/blog/2005/11/08/status.rst
 rename www.i2p2/pages/status-2005-11-15.html => i2p2www/blog/2005/11/15/status.html (100%)
 create mode 100644 i2p2www/blog/2005/11/15/status.rst
 rename www.i2p2/pages/status-2005-11-22.html => i2p2www/blog/2005/11/22/status.html (100%)
 create mode 100644 i2p2www/blog/2005/11/22/status.rst
 rename www.i2p2/pages/status-2005-11-29.html => i2p2www/blog/2005/11/29/status.html (100%)
 create mode 100644 i2p2www/blog/2005/11/29/status.rst
 rename www.i2p2/pages/status-2005-12-06.html => i2p2www/blog/2005/12/06/status.html (100%)
 create mode 100644 i2p2www/blog/2005/12/06/status.rst
 rename www.i2p2/pages/status-2005-12-13.html => i2p2www/blog/2005/12/13/status.html (100%)
 create mode 100644 i2p2www/blog/2005/12/13/status.rst
 rename www.i2p2/pages/status-2005-12-20.html => i2p2www/blog/2005/12/20/status.html (100%)
 create mode 100644 i2p2www/blog/2005/12/20/status.rst
 rename www.i2p2/pages/status-2006-01-03.html => i2p2www/blog/2006/01/03/status.html (100%)
 create mode 100644 i2p2www/blog/2006/01/03/status.rst
 rename www.i2p2/pages/status-2006-01-10.html => i2p2www/blog/2006/01/10/status.html (100%)
 create mode 100644 i2p2www/blog/2006/01/10/status.rst
 rename www.i2p2/pages/status-2006-01-17.html => i2p2www/blog/2006/01/17/status.html (100%)
 create mode 100644 i2p2www/blog/2006/01/17/status.rst
 rename www.i2p2/pages/status-2006-01-24.html => i2p2www/blog/2006/01/24/status.html (100%)
 create mode 100644 i2p2www/blog/2006/01/24/status.rst
 rename www.i2p2/pages/status-2006-01-31.html => i2p2www/blog/2006/01/31/status.html (100%)
 create mode 100644 i2p2www/blog/2006/01/31/status.rst
 rename www.i2p2/pages/status-2006-02-07.html => i2p2www/blog/2006/02/07/status.html (100%)
 create mode 100644 i2p2www/blog/2006/02/07/status.rst
 rename www.i2p2/pages/status-2006-02-14.html => i2p2www/blog/2006/02/14/status.html (100%)
 create mode 100644 i2p2www/blog/2006/02/14/status.rst
 rename www.i2p2/pages/status-2006-02-21.html => i2p2www/blog/2006/02/21/status.html (100%)
 create mode 100644 i2p2www/blog/2006/02/21/status.rst
 rename www.i2p2/pages/status-2006-02-28.html => i2p2www/blog/2006/02/28/status.html (100%)
 create mode 100644 i2p2www/blog/2006/02/28/status.rst
 rename www.i2p2/pages/status-2006-03-07.html => i2p2www/blog/2006/03/07/status.html (100%)
 create mode 100644 i2p2www/blog/2006/03/07/status.rst
 rename www.i2p2/pages/status-2006-03-14.html => i2p2www/blog/2006/03/14/status.html (100%)
 create mode 100644 i2p2www/blog/2006/03/14/status.rst
 rename www.i2p2/pages/status-2006-03-21.html => i2p2www/blog/2006/03/21/status.html (100%)
 create mode 100644 i2p2www/blog/2006/03/21/status.rst
 rename www.i2p2/pages/status-2006-03-28.html => i2p2www/blog/2006/03/28/status.html (100%)
 create mode 100644 i2p2www/blog/2006/03/28/status.rst
 rename www.i2p2/pages/status-2006-04-04.html => i2p2www/blog/2006/04/04/status.html (100%)
 create mode 100644 i2p2www/blog/2006/04/04/status.rst
 rename www.i2p2/pages/status-2006-04-18.html => i2p2www/blog/2006/04/18/status.html (100%)
 create mode 100644 i2p2www/blog/2006/04/18/status.rst
 rename www.i2p2/pages/status-2006-04-25.html => i2p2www/blog/2006/04/25/status.html (100%)
 create mode 100644 i2p2www/blog/2006/04/25/status.rst
 rename www.i2p2/pages/status-2006-05-02.html => i2p2www/blog/2006/05/02/status.html (100%)
 create mode 100644 i2p2www/blog/2006/05/02/status.rst
 rename www.i2p2/pages/status-2006-05-09.html => i2p2www/blog/2006/05/09/status.html (100%)
 create mode 100644 i2p2www/blog/2006/05/09/status.rst
 rename www.i2p2/pages/status-2006-05-16.html => i2p2www/blog/2006/05/16/status.html (100%)
 create mode 100644 i2p2www/blog/2006/05/16/status.rst
 rename www.i2p2/pages/status-2006-05-30.html => i2p2www/blog/2006/05/30/status.html (100%)
 create mode 100644 i2p2www/blog/2006/05/30/status.rst
 rename www.i2p2/pages/status-2006-06-13.html => i2p2www/blog/2006/06/13/status.html (100%)
 create mode 100644 i2p2www/blog/2006/06/13/status.rst
 rename www.i2p2/pages/status-2006-08-01.html => i2p2www/blog/2006/08/01/status.html (100%)
 create mode 100644 i2p2www/blog/2006/08/01/status.rst
 rename www.i2p2/pages/status-2006-09-12.html => i2p2www/blog/2006/09/12/status.html (100%)
 create mode 100644 i2p2www/blog/2006/09/12/status.rst
 rename www.i2p2/pages/status-2006-10-03.html => i2p2www/blog/2006/10/03/status.html (100%)
 create mode 100644 i2p2www/blog/2006/10/03/status.rst
 rename www.i2p2/pages/statnotes0108.html => i2p2www/blog/2008/02/01/status.html (100%)
 create mode 100644 i2p2www/blog/2008/02/01/status.rst

diff --git a/www.i2p2/pages/status-2004-07-13.html b/i2p2www/blog/2004/07/13/status.html
similarity index 100%
rename from www.i2p2/pages/status-2004-07-13.html
rename to i2p2www/blog/2004/07/13/status.html
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 100%
rename from www.i2p2/pages/status-2004-07-20.html
rename to i2p2www/blog/2004/07/20/status.html
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 100%
rename from www.i2p2/pages/status-2004-07-27.html
rename to i2p2www/blog/2004/07/27/status.html
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 100%
rename from www.i2p2/pages/status-2004-08-03.html
rename to i2p2www/blog/2004/08/03/status.html
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 100%
rename from www.i2p2/pages/status-2004-08-10.html
rename to i2p2www/blog/2004/08/10/status.html
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 100%
rename from www.i2p2/pages/status-2004-08-17.html
rename to i2p2www/blog/2004/08/17/status.html
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 100%
rename from www.i2p2/pages/status-2004-08-24.html
rename to i2p2www/blog/2004/08/24/status.html
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 100%
rename from www.i2p2/pages/status-2004-08-31.html
rename to i2p2www/blog/2004/08/31/status.html
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 100%
rename from www.i2p2/pages/status-2004-09-08.html
rename to i2p2www/blog/2004/09/08/status.html
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 100%
rename from www.i2p2/pages/status-2004-09-14.html
rename to i2p2www/blog/2004/09/14/status.html
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 100%
rename from www.i2p2/pages/status-2004-09-21.html
rename to i2p2www/blog/2004/09/21/status.html
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 100%
rename from www.i2p2/pages/status-2004-09-28.html
rename to i2p2www/blog/2004/09/28/status.html
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 100%
rename from www.i2p2/pages/status-2004-10-05.html
rename to i2p2www/blog/2004/10/05/status.html
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 100%
rename from www.i2p2/pages/status-2004-10-12.html
rename to i2p2www/blog/2004/10/12/status.html
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 100%
rename from www.i2p2/pages/status-2004-10-19.html
rename to i2p2www/blog/2004/10/19/status.html
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 100%
rename from www.i2p2/pages/status-2004-10-26.html
rename to i2p2www/blog/2004/10/26/status.html
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 100%
rename from www.i2p2/pages/status-2004-11-02.html
rename to i2p2www/blog/2004/11/02/status.html
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 100%
rename from www.i2p2/pages/status-2004-11-09.html
rename to i2p2www/blog/2004/11/09/status.html
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 100%
rename from www.i2p2/pages/status-2004-11-16.html
rename to i2p2www/blog/2004/11/16/status.html
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 100%
rename from www.i2p2/pages/status-2004-11-23.html
rename to i2p2www/blog/2004/11/23/status.html
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 100%
rename from www.i2p2/pages/status-2004-11-30.html
rename to i2p2www/blog/2004/11/30/status.html
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 100%
rename from www.i2p2/pages/status-2004-12-07.html
rename to i2p2www/blog/2004/12/07/status.html
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 100%
rename from www.i2p2/pages/status-2004-12-14.html
rename to i2p2www/blog/2004/12/14/status.html
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 100%
rename from www.i2p2/pages/status-2004-12-21.html
rename to i2p2www/blog/2004/12/21/status.html
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 100%
rename from www.i2p2/pages/status-2004-12-28.html
rename to i2p2www/blog/2004/12/28/status.html
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 100%
rename from www.i2p2/pages/status-2005-01-04.html
rename to i2p2www/blog/2005/01/04/status.html
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 100%
rename from www.i2p2/pages/status-2005-01-11.html
rename to i2p2www/blog/2005/01/11/status.html
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 100%
rename from www.i2p2/pages/status-2005-01-18.html
rename to i2p2www/blog/2005/01/18/status.html
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 100%
rename from www.i2p2/pages/status-2005-01-25.html
rename to i2p2www/blog/2005/01/25/status.html
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 100%
rename from www.i2p2/pages/status-2005-02-01.html
rename to i2p2www/blog/2005/02/01/status.html
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 100%
rename from www.i2p2/pages/status-2005-02-08.html
rename to i2p2www/blog/2005/02/08/status.html
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 100%
rename from www.i2p2/pages/status-2005-02-15.html
rename to i2p2www/blog/2005/02/15/status.html
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 100%
rename from www.i2p2/pages/status-2005-02-22.html
rename to i2p2www/blog/2005/02/22/status.html
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 100%
rename from www.i2p2/pages/status-2005-03-01.html
rename to i2p2www/blog/2005/03/01/status.html
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 100%
rename from www.i2p2/pages/status-2005-03-08.html
rename to i2p2www/blog/2005/03/08/status.html
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 100%
rename from www.i2p2/pages/status-2005-03-15.html
rename to i2p2www/blog/2005/03/15/status.html
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 100%
rename from www.i2p2/pages/status-2005-03-22.html
rename to i2p2www/blog/2005/03/22/status.html
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 100%
rename from www.i2p2/pages/status-2005-03-29.html
rename to i2p2www/blog/2005/03/29/status.html
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 100%
rename from www.i2p2/pages/status-2005-04-05.html
rename to i2p2www/blog/2005/04/05/status.html
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 100%
rename from www.i2p2/pages/status-2005-04-12.html
rename to i2p2www/blog/2005/04/12/status.html
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 100%
rename from www.i2p2/pages/status-2005-04-19.html
rename to i2p2www/blog/2005/04/19/status.html
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 100%
rename from www.i2p2/pages/status-2005-04-26.html
rename to i2p2www/blog/2005/04/26/status.html
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 100%
rename from www.i2p2/pages/status-2005-05-03.html
rename to i2p2www/blog/2005/05/03/status.html
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 100%
rename from www.i2p2/pages/status-2005-06-21.html
rename to i2p2www/blog/2005/06/21/status.html
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 100%
rename from www.i2p2/pages/status-2005-06-28.html
rename to i2p2www/blog/2005/06/28/status.html
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 100%
rename from www.i2p2/pages/status-2005-07-05.html
rename to i2p2www/blog/2005/07/05/status.html
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 100%
rename from www.i2p2/pages/status-2005-07-12.html
rename to i2p2www/blog/2005/07/12/status.html
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 100%
rename from www.i2p2/pages/status-2005-07-19.html
rename to i2p2www/blog/2005/07/19/status.html
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 100%
rename from www.i2p2/pages/status-2005-07-26.html
rename to i2p2www/blog/2005/07/26/status.html
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 100%
rename from www.i2p2/pages/status-2005-08-02.html
rename to i2p2www/blog/2005/08/02/status.html
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 100%
rename from www.i2p2/pages/status-2005-08-09.html
rename to i2p2www/blog/2005/08/09/status.html
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 100%
rename from www.i2p2/pages/status-2005-08-16.html
rename to i2p2www/blog/2005/08/16/status.html
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 100%
rename from www.i2p2/pages/status-2005-08-23.html
rename to i2p2www/blog/2005/08/23/status.html
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 100%
rename from www.i2p2/pages/status-2005-08-30.html
rename to i2p2www/blog/2005/08/30/status.html
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 100%
rename from www.i2p2/pages/status-2005-09-06.html
rename to i2p2www/blog/2005/09/06/status.html
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 100%
rename from www.i2p2/pages/status-2005-09-13.html
rename to i2p2www/blog/2005/09/13/status.html
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 100%
rename from www.i2p2/pages/status-2005-09-20.html
rename to i2p2www/blog/2005/09/20/status.html
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 100%
rename from www.i2p2/pages/status-2005-10-04.html
rename to i2p2www/blog/2005/10/04/status.html
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 100%
rename from www.i2p2/pages/status-2005-10-11.html
rename to i2p2www/blog/2005/10/11/status.html
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 100%
rename from www.i2p2/pages/status-2005-10-18.html
rename to i2p2www/blog/2005/10/18/status.html
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 100%
rename from www.i2p2/pages/status-2005-10-25.html
rename to i2p2www/blog/2005/10/25/status.html
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 100%
rename from www.i2p2/pages/status-2005-11-01.html
rename to i2p2www/blog/2005/11/01/status.html
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 100%
rename from www.i2p2/pages/status-2005-11-08.html
rename to i2p2www/blog/2005/11/08/status.html
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 100%
rename from www.i2p2/pages/status-2005-11-15.html
rename to i2p2www/blog/2005/11/15/status.html
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 100%
rename from www.i2p2/pages/status-2005-11-22.html
rename to i2p2www/blog/2005/11/22/status.html
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 100%
rename from www.i2p2/pages/status-2005-11-29.html
rename to i2p2www/blog/2005/11/29/status.html
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 100%
rename from www.i2p2/pages/status-2005-12-06.html
rename to i2p2www/blog/2005/12/06/status.html
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 100%
rename from www.i2p2/pages/status-2005-12-13.html
rename to i2p2www/blog/2005/12/13/status.html
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 100%
rename from www.i2p2/pages/status-2005-12-20.html
rename to i2p2www/blog/2005/12/20/status.html
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 100%
rename from www.i2p2/pages/status-2006-01-03.html
rename to i2p2www/blog/2006/01/03/status.html
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 100%
rename from www.i2p2/pages/status-2006-01-10.html
rename to i2p2www/blog/2006/01/10/status.html
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 100%
rename from www.i2p2/pages/status-2006-01-17.html
rename to i2p2www/blog/2006/01/17/status.html
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 100%
rename from www.i2p2/pages/status-2006-01-24.html
rename to i2p2www/blog/2006/01/24/status.html
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 100%
rename from www.i2p2/pages/status-2006-01-31.html
rename to i2p2www/blog/2006/01/31/status.html
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 100%
rename from www.i2p2/pages/status-2006-02-07.html
rename to i2p2www/blog/2006/02/07/status.html
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 100%
rename from www.i2p2/pages/status-2006-02-14.html
rename to i2p2www/blog/2006/02/14/status.html
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 100%
rename from www.i2p2/pages/status-2006-02-21.html
rename to i2p2www/blog/2006/02/21/status.html
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 100%
rename from www.i2p2/pages/status-2006-02-28.html
rename to i2p2www/blog/2006/02/28/status.html
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 100%
rename from www.i2p2/pages/status-2006-03-07.html
rename to i2p2www/blog/2006/03/07/status.html
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 100%
rename from www.i2p2/pages/status-2006-03-14.html
rename to i2p2www/blog/2006/03/14/status.html
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 100%
rename from www.i2p2/pages/status-2006-03-21.html
rename to i2p2www/blog/2006/03/21/status.html
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 100%
rename from www.i2p2/pages/status-2006-03-28.html
rename to i2p2www/blog/2006/03/28/status.html
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 100%
rename from www.i2p2/pages/status-2006-04-04.html
rename to i2p2www/blog/2006/04/04/status.html
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 100%
rename from www.i2p2/pages/status-2006-04-18.html
rename to i2p2www/blog/2006/04/18/status.html
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 100%
rename from www.i2p2/pages/status-2006-04-25.html
rename to i2p2www/blog/2006/04/25/status.html
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 100%
rename from www.i2p2/pages/status-2006-05-02.html
rename to i2p2www/blog/2006/05/02/status.html
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 100%
rename from www.i2p2/pages/status-2006-05-09.html
rename to i2p2www/blog/2006/05/09/status.html
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 100%
rename from www.i2p2/pages/status-2006-05-16.html
rename to i2p2www/blog/2006/05/16/status.html
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 100%
rename from www.i2p2/pages/status-2006-05-30.html
rename to i2p2www/blog/2006/05/30/status.html
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 100%
rename from www.i2p2/pages/status-2006-06-13.html
rename to i2p2www/blog/2006/06/13/status.html
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 100%
rename from www.i2p2/pages/status-2006-08-01.html
rename to i2p2www/blog/2006/08/01/status.html
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 100%
rename from www.i2p2/pages/status-2006-09-12.html
rename to i2p2www/blog/2006/09/12/status.html
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 100%
rename from www.i2p2/pages/status-2006-10-03.html
rename to i2p2www/blog/2006/10/03/status.html
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/statnotes0108.html b/i2p2www/blog/2008/02/01/status.html
similarity index 100%
rename from www.i2p2/pages/statnotes0108.html
rename to i2p2www/blog/2008/02/01/status.html
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

From 27bee805231f731cd311cc73a9ad5f968ddf36d8 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 01:21:58 +0000
Subject: [PATCH 45/75] Finished migration of status notes

---
 i2p2www/blog/2004/07/13/status.html | 4 ----
 i2p2www/blog/2004/07/20/status.html | 4 ----
 i2p2www/blog/2004/07/27/status.html | 4 ----
 i2p2www/blog/2004/08/03/status.html | 4 ----
 i2p2www/blog/2004/08/10/status.html | 4 ----
 i2p2www/blog/2004/08/17/status.html | 4 ----
 i2p2www/blog/2004/08/24/status.html | 4 ----
 i2p2www/blog/2004/08/31/status.html | 4 ----
 i2p2www/blog/2004/09/08/status.html | 4 ----
 i2p2www/blog/2004/09/14/status.html | 4 ----
 i2p2www/blog/2004/09/21/status.html | 4 ----
 i2p2www/blog/2004/09/28/status.html | 4 ----
 i2p2www/blog/2004/10/05/status.html | 4 ----
 i2p2www/blog/2004/10/12/status.html | 4 ----
 i2p2www/blog/2004/10/19/status.html | 4 ----
 i2p2www/blog/2004/10/26/status.html | 4 ----
 i2p2www/blog/2004/11/02/status.html | 4 ----
 i2p2www/blog/2004/11/09/status.html | 4 ----
 i2p2www/blog/2004/11/16/status.html | 4 ----
 i2p2www/blog/2004/11/23/status.html | 4 ----
 i2p2www/blog/2004/11/30/status.html | 4 ----
 i2p2www/blog/2004/12/07/status.html | 4 ----
 i2p2www/blog/2004/12/14/status.html | 4 ----
 i2p2www/blog/2004/12/21/status.html | 4 ----
 i2p2www/blog/2004/12/28/status.html | 4 ----
 i2p2www/blog/2005/01/04/status.html | 4 ----
 i2p2www/blog/2005/01/11/status.html | 4 ----
 i2p2www/blog/2005/01/18/status.html | 4 ----
 i2p2www/blog/2005/01/25/status.html | 4 ----
 i2p2www/blog/2005/02/01/status.html | 4 ----
 i2p2www/blog/2005/02/08/status.html | 4 ----
 i2p2www/blog/2005/02/15/status.html | 4 ----
 i2p2www/blog/2005/02/22/status.html | 4 ----
 i2p2www/blog/2005/03/01/status.html | 4 ----
 i2p2www/blog/2005/03/08/status.html | 4 ----
 i2p2www/blog/2005/03/15/status.html | 4 ----
 i2p2www/blog/2005/03/22/status.html | 4 ----
 i2p2www/blog/2005/03/29/status.html | 4 ----
 i2p2www/blog/2005/04/05/status.html | 4 ----
 i2p2www/blog/2005/04/12/status.html | 4 ----
 i2p2www/blog/2005/04/19/status.html | 4 ----
 i2p2www/blog/2005/04/26/status.html | 4 ----
 i2p2www/blog/2005/05/03/status.html | 4 ----
 i2p2www/blog/2005/06/21/status.html | 4 ----
 i2p2www/blog/2005/06/28/status.html | 4 ----
 i2p2www/blog/2005/07/05/status.html | 4 ----
 i2p2www/blog/2005/07/12/status.html | 4 ----
 i2p2www/blog/2005/07/19/status.html | 4 ----
 i2p2www/blog/2005/07/26/status.html | 4 ----
 i2p2www/blog/2005/08/02/status.html | 4 ----
 i2p2www/blog/2005/08/09/status.html | 4 ----
 i2p2www/blog/2005/08/16/status.html | 4 ----
 i2p2www/blog/2005/08/23/status.html | 4 ----
 i2p2www/blog/2005/08/30/status.html | 4 ----
 i2p2www/blog/2005/09/06/status.html | 4 ----
 i2p2www/blog/2005/09/13/status.html | 4 ----
 i2p2www/blog/2005/09/20/status.html | 4 ----
 i2p2www/blog/2005/10/04/status.html | 4 ----
 i2p2www/blog/2005/10/11/status.html | 4 ----
 i2p2www/blog/2005/10/18/status.html | 4 ----
 i2p2www/blog/2005/10/25/status.html | 4 ----
 i2p2www/blog/2005/11/01/status.html | 4 ----
 i2p2www/blog/2005/11/08/status.html | 4 ----
 i2p2www/blog/2005/11/15/status.html | 4 ----
 i2p2www/blog/2005/11/22/status.html | 4 ----
 i2p2www/blog/2005/11/29/status.html | 4 ----
 i2p2www/blog/2005/12/06/status.html | 4 ----
 i2p2www/blog/2005/12/13/status.html | 4 ----
 i2p2www/blog/2005/12/20/status.html | 4 ----
 i2p2www/blog/2006/01/03/status.html | 4 ----
 i2p2www/blog/2006/01/10/status.html | 4 ----
 i2p2www/blog/2006/01/17/status.html | 4 ----
 i2p2www/blog/2006/01/24/status.html | 4 ----
 i2p2www/blog/2006/01/31/status.html | 4 ----
 i2p2www/blog/2006/02/07/status.html | 4 ----
 i2p2www/blog/2006/02/14/status.html | 4 ----
 i2p2www/blog/2006/02/21/status.html | 4 ----
 i2p2www/blog/2006/02/28/status.html | 4 ----
 i2p2www/blog/2006/03/07/status.html | 4 ----
 i2p2www/blog/2006/03/14/status.html | 4 ----
 i2p2www/blog/2006/03/21/status.html | 4 ----
 i2p2www/blog/2006/03/28/status.html | 4 ----
 i2p2www/blog/2006/04/04/status.html | 4 ----
 i2p2www/blog/2006/04/18/status.html | 4 ----
 i2p2www/blog/2006/04/25/status.html | 4 ----
 i2p2www/blog/2006/05/02/status.html | 4 ----
 i2p2www/blog/2006/05/09/status.html | 4 ----
 i2p2www/blog/2006/05/16/status.html | 4 ----
 i2p2www/blog/2006/05/30/status.html | 4 ----
 i2p2www/blog/2006/06/13/status.html | 4 ----
 i2p2www/blog/2006/08/01/status.html | 4 ----
 i2p2www/blog/2006/09/12/status.html | 4 ----
 i2p2www/blog/2006/10/03/status.html | 4 ----
 i2p2www/blog/2008/02/01/status.html | 7 +------
 94 files changed, 1 insertion(+), 378 deletions(-)

diff --git a/i2p2www/blog/2004/07/13/status.html b/i2p2www/blog/2004/07/13/status.html
index 4160ef9e..f4e6e42e 100644
--- a/i2p2www/blog/2004/07/13/status.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 %}<h3>I2P Status Notes for 2004-07-13</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ c507IhMQP3WwejdCIyYRx7oX
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/07/20/status.html b/i2p2www/blog/2004/07/20/status.html
index 8124dcfa..2e32c8fb 100644
--- a/i2p2www/blog/2004/07/20/status.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 %}<h3>I2P Status Notes for 2004-07-20</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -148,4 +145,3 @@ sxKqvaHlNppJCq/x/BzEWcxd
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/07/27/status.html b/i2p2www/blog/2004/07/27/status.html
index 7895d539..384c68ce 100644
--- a/i2p2www/blog/2004/07/27/status.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 %}<h3>I2P Status Notes for 2004-07-27</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -99,4 +96,3 @@ Q36Vr3muI4ti770dlw0mUDLu
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/08/03/status.html b/i2p2www/blog/2004/08/03/status.html
index 1d5ffe17..ce5c2385 100644
--- a/i2p2www/blog/2004/08/03/status.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 %}<h3>I2P Status Notes for 2004-08-03</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -143,4 +140,3 @@ iQA/AwUBQQ/U+BpxS9rYd+OGEQI4+ACgglcWt+LSOPGodCCoqSBsVfl0wxYAoNFO
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/08/10/status.html b/i2p2www/blog/2004/08/10/status.html
index 5d26763f..d5f5d58f 100644
--- a/i2p2www/blog/2004/08/10/status.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 %}<h3>I2P Status Notes for 2004-08-10</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -91,4 +88,3 @@ E+89jypnECNyg/uF1RHuy1Fy
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/08/17/status.html b/i2p2www/blog/2004/08/17/status.html
index fe028ea9..7521aa13 100644
--- a/i2p2www/blog/2004/08/17/status.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 %}<h3>I2P Status Notes for 2004-08-17</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ i0kp7DNZkldsLH2uenA0mpeI
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/08/24/status.html b/i2p2www/blog/2004/08/24/status.html
index adc24988..61bc90f5 100644
--- a/i2p2www/blog/2004/08/24/status.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 %}<h3>I2P Status Notes for 2004-08-24</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -216,4 +213,3 @@ JDLmPE9nXRLzrRWdTTRJ1JHH
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/08/31/status.html b/i2p2www/blog/2004/08/31/status.html
index b10050b5..8f54b44d 100644
--- a/i2p2www/blog/2004/08/31/status.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 %}<h3>I2P Status Notes for 2004-08-31</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -162,4 +159,3 @@ gEg6cYDHMxLuGop/ALQwU+bg
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/09/08/status.html b/i2p2www/blog/2004/09/08/status.html
index e91090cb..22bd828f 100644
--- a/i2p2www/blog/2004/09/08/status.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 %}<h3>I2P Status Notes for 2004-09-08</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -130,4 +127,3 @@ qS8j385jn3Xj4wIJCPimEX01
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/09/14/status.html b/i2p2www/blog/2004/09/14/status.html
index 910ca785..ede0b788 100644
--- a/i2p2www/blog/2004/09/14/status.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 %}<h3>I2P Status Notes for 2004-09-14</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -198,4 +195,3 @@ iQA/AwUBQUc1OhpxS9rYd+OGEQLaYQCg0qql8muvuGEh46VICx4t69PuRl8An0Ki
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/09/21/status.html b/i2p2www/blog/2004/09/21/status.html
index 1ecd18ae..03f2df16 100644
--- a/i2p2www/blog/2004/09/21/status.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 %}<h3>I2P Status Notes for 2004-09-21</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ iQA/AwUBQVCVAxpxS9rYd+OGEQIdswCg1gpn/wMwppYT4DnNss+ChBi+U7MAnAuW
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/09/28/status.html b/i2p2www/blog/2004/09/28/status.html
index c75309f7..c106cf84 100644
--- a/i2p2www/blog/2004/09/28/status.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 %}<h3>I2P Status Notes for 2004-09-28</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ iQA/AwUBQVmbSxpxS9rYd+OGEQLRLQCfXYW9hGbiTALFtsv7L803qAJlFocAoPPO
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/10/05/status.html b/i2p2www/blog/2004/10/05/status.html
index 97b0348a..f3d37a44 100644
--- a/i2p2www/blog/2004/10/05/status.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 %}<h3>I2P Status Notes for 2004-10-05</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -168,4 +165,3 @@ vkNuIUa6ZwkKMVJWhoZdWto4
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/10/12/status.html b/i2p2www/blog/2004/10/12/status.html
index 019b2af0..f595c4be 100644
--- a/i2p2www/blog/2004/10/12/status.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 %}<h3>I2P Status Notes for 2004-10-12</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -112,4 +109,3 @@ uGWqH5WOe6ZCObkRlxVsMj+B
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/10/19/status.html b/i2p2www/blog/2004/10/19/status.html
index 40c9f849..538d884b 100644
--- a/i2p2www/blog/2004/10/19/status.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 %}<h3>I2P Status Notes for 2004-10-19</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -96,4 +93,3 @@ azbFco6lKpQW9SM631nLXXZB
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/10/26/status.html b/i2p2www/blog/2004/10/26/status.html
index ebfa0fe6..980186a9 100644
--- a/i2p2www/blog/2004/10/26/status.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 %}<h3>I2P Status Notes for 2004-10-26</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -92,4 +89,3 @@ zFtdHN6Y54VUcfsFl6+5W/3B
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/11/02/status.html b/i2p2www/blog/2004/11/02/status.html
index f2a4fa03..664d200b 100644
--- a/i2p2www/blog/2004/11/02/status.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 %}<h3>I2P Status Notes for 2004-11-02</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ Z1ThyrjEZjAttC/wChPN43aD
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/11/09/status.html b/i2p2www/blog/2004/11/09/status.html
index c27328d8..972ceecc 100644
--- a/i2p2www/blog/2004/11/09/status.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 %}<h3>I2P Status Notes for 2004-11-09</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ iHMiSnKD18OhLH6P91TLfSSv
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/11/16/status.html b/i2p2www/blog/2004/11/16/status.html
index a97459b1..fb99f5ec 100644
--- a/i2p2www/blog/2004/11/16/status.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 %}<h3>I2P Status Notes for 2004-11-16</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -75,4 +72,3 @@ ZEawa8wEMLl1tz/uk4BTENkb
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/11/23/status.html b/i2p2www/blog/2004/11/23/status.html
index 62aff0a8..8f46c762 100644
--- a/i2p2www/blog/2004/11/23/status.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 %}<h3>I2P Status Notes for 2004-11-23</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -117,4 +114,3 @@ pfi+wfwTumipVNuMFPUm39TK
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/11/30/status.html b/i2p2www/blog/2004/11/30/status.html
index 650151b0..61cf05b9 100644
--- a/i2p2www/blog/2004/11/30/status.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 %}<h3>I2P Status Notes for 2004-11-30</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ iD8DBQFBrOBZGnFL2th344YRArtBAJ9YhRvP3MczO96gi4Xwnowie55HlACgzlO3
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/12/07/status.html b/i2p2www/blog/2004/12/07/status.html
index c164b62c..f34dfe38 100644
--- a/i2p2www/blog/2004/12/07/status.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 %}<h3>I2P Status Notes for 2004-12-07</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -59,4 +56,3 @@ i2p mailing list
 i2p-Po2eaMWI3R0@xxxxxxxxxxxxxxxx
 <a  rel="nofollow" href="http://i2p.dnsalias.net/mailman/listinfo/i2p">http://i2p.dnsalias.net/mailman/listinfo/i2p</a>
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/12/14/status.html b/i2p2www/blog/2004/12/14/status.html
index 7420d7ec..1dd3c99b 100644
--- a/i2p2www/blog/2004/12/14/status.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 %}<h3>I2P Status Notes for 2004-12-14</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ vL+gi2piiZq3aup7iyN/wRY=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/12/21/status.html b/i2p2www/blog/2004/12/21/status.html
index 02e3d85d..4e8e679a 100644
--- a/i2p2www/blog/2004/12/21/status.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 %}<h3>I2P Status Notes for 2004-12-21</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -111,4 +108,3 @@ iD8DBQFByItjGnFL2th344YRAmmOAKD+HxEAK+dqseq8ZCO5pjvW4EKImQCgkfwX
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2004/12/28/status.html b/i2p2www/blog/2004/12/28/status.html
index 6138e5f0..0d158b8c 100644
--- a/i2p2www/blog/2004/12/28/status.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 %}<h3>I2P Status Notes for 2004-12-28</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -57,4 +54,3 @@ c9O5fcXfOJ54OuM7vPhHBQU=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/01/04/status.html b/i2p2www/blog/2005/01/04/status.html
index ee953337..ed66a866 100644
--- a/i2p2www/blog/2005/01/04/status.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 %}<h3>I2P Status Notes for 2005-01-04</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -115,4 +112,3 @@ ZQXQmqk6EIx184r2Zi7poZg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/01/11/status.html b/i2p2www/blog/2005/01/11/status.html
index ce7cce0f..86ba3f98 100644
--- a/i2p2www/blog/2005/01/11/status.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 %}<h3>I2P Status Notes for 2005-01-11</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -132,4 +129,3 @@ ItUMfG4sTnmRKk5m2u9Yxjg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/01/18/status.html b/i2p2www/blog/2005/01/18/status.html
index a4d34263..d7ee78b0 100644
--- a/i2p2www/blog/2005/01/18/status.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 %}<h3>I2P Status Notes for 2005-01-18</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -138,4 +135,3 @@ LFh9H55UFtsLPRFk7hxdv1c=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/01/25/status.html b/i2p2www/blog/2005/01/25/status.html
index 49ad20a7..e3b5c2a5 100644
--- a/i2p2www/blog/2005/01/25/status.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 %}<h3>I2P Status Notes for 2005-01-25</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -73,4 +70,3 @@ W/EO4gPSteZWp+rBogWfB3M=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/02/01/status.html b/i2p2www/blog/2005/02/01/status.html
index 9c8aad44..0aac5a94 100644
--- a/i2p2www/blog/2005/02/01/status.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 %}<h3>I2P Status Notes for 2005-02-01</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -74,4 +71,3 @@ kF6G0CoDu08TvpEtuzuzH9o=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/02/08/status.html b/i2p2www/blog/2005/02/08/status.html
index ba74d327..565c07f2 100644
--- a/i2p2www/blog/2005/02/08/status.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 %}<h3>I2P Status Notes for 2005-02-08</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ iD8DBQFCCSaRGnFL2th344YRApVpAKCEypMmgxmJu7ezMwKD5G3ROClh8ACfRqj6
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/02/15/status.html b/i2p2www/blog/2005/02/15/status.html
index 236a2755..cf62c7a2 100644
--- a/i2p2www/blog/2005/02/15/status.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 %}<h3>I2P Status Notes for 2005-02-15</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -90,4 +87,3 @@ Cbz/JT+3L2OfdhKAy8p/isQ=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/02/22/status.html b/i2p2www/blog/2005/02/22/status.html
index 75b0efdf..cb622dbf 100644
--- a/i2p2www/blog/2005/02/22/status.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 %}<h3>I2P Status Notes for 2005-02-22</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -81,4 +78,3 @@ nNdoN5D/aKLL0XdusZcigTA=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/03/01/status.html b/i2p2www/blog/2005/03/01/status.html
index 1c3677c0..563b4631 100644
--- a/i2p2www/blog/2005/03/01/status.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 %}<h3>I2P Status Notes for 2005-03-01</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -94,4 +91,3 @@ iD8DBQFCJNebGnFL2th344YRAobNAJ4lfCULXX7WAGZxOlh/NzTuV1eNwgCg1eV/
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/03/08/status.html b/i2p2www/blog/2005/03/08/status.html
index f4d3edc8..f2e6ec8a 100644
--- a/i2p2www/blog/2005/03/08/status.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 %}<h3>I2P Status Notes for 2005-03-08</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -70,4 +67,3 @@ EHsY9W9LztKK3FZBHPN2FyE=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/03/15/status.html b/i2p2www/blog/2005/03/15/status.html
index 1b596eec..452f2992 100644
--- a/i2p2www/blog/2005/03/15/status.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 %}<h3>I2P Status Notes for 2005-03-15</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ mvxKNX+jQ7jnfBFyJponyCc=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/03/22/status.html b/i2p2www/blog/2005/03/22/status.html
index fa5fcb22..23b47431 100644
--- a/i2p2www/blog/2005/03/22/status.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 %}<h3>I2P Status Notes for 2005-03-22</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -84,4 +81,3 @@ iD8DBQFCQIW+GnFL2th344YRAj03AKCAwDNl6Dr/4Xi6l9x4kOhw8YIkEwCglfFc
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/03/29/status.html b/i2p2www/blog/2005/03/29/status.html
index e64ce8cc..0194b23e 100644
--- a/i2p2www/blog/2005/03/29/status.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 %}<h3>I2P Status Notes for 2005-03-29</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ Kk+3I6WgqDjqaNKSc5xnoQA=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/04/05/status.html b/i2p2www/blog/2005/04/05/status.html
index 0de00d45..bd84ef2c 100644
--- a/i2p2www/blog/2005/04/05/status.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 %}<h3>I2P Status Notes for 2005-04-05</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -57,4 +54,3 @@ Li2s44HU5EehnMoCMxIOZlc=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/04/12/status.html b/i2p2www/blog/2005/04/12/status.html
index ca916400..ec4b2cd1 100644
--- a/i2p2www/blog/2005/04/12/status.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 %}<h3>I2P Status Notes for 2005-04-12</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -127,4 +124,3 @@ ONGe96zS1hmVNeAzqQgjeUo=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/04/19/status.html b/i2p2www/blog/2005/04/19/status.html
index ebe33c85..2b67bff5 100644
--- a/i2p2www/blog/2005/04/19/status.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 %}<h3>I2P Status Notes for 2005-04-19</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -80,4 +77,3 @@ T3H2xh74GXTtBdOloaAHS9o=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/04/26/status.html b/i2p2www/blog/2005/04/26/status.html
index 6ba2b317..0cd1cd91 100644
--- a/i2p2www/blog/2005/04/26/status.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 %}<h3>I2P Status Notes for 2005-04-26</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -61,4 +58,3 @@ VBGnM3PHevpd6dpqHoI/tvg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/05/03/status.html b/i2p2www/blog/2005/05/03/status.html
index 5924348a..6491dae3 100644
--- a/i2p2www/blog/2005/05/03/status.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 %}<h3>I2P Status Notes for 2005-05-03</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ vJ2B+nJiHEMLwobhZIRS2hQ=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/06/21/status.html b/i2p2www/blog/2005/06/21/status.html
index 90dc7a8a..19a2819c 100644
--- a/i2p2www/blog/2005/06/21/status.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 %}<h3>I2P Status Notes for 2005-06-21</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -114,4 +111,3 @@ gaRYTsDAU3zHBCxr4TiSl18=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/06/28/status.html b/i2p2www/blog/2005/06/28/status.html
index bee9abc6..7c9caa53 100644
--- a/i2p2www/blog/2005/06/28/status.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 %}<h3>I2P Status Notes for 2005-06-28</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ mbSQS7iBWcts4GQpGLBmcSg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/07/05/status.html b/i2p2www/blog/2005/07/05/status.html
index 45d1510e..08025bde 100644
--- a/i2p2www/blog/2005/07/05/status.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 %}<h3>I2P Status Notes for 2005-07-05</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ p1RmRcbFNI8vA+qVwFGVFT4=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/07/12/status.html b/i2p2www/blog/2005/07/12/status.html
index 97871c07..b4c8d213 100644
--- a/i2p2www/blog/2005/07/12/status.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 %}<h3>I2P Status Notes for 2005-07-12</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -99,4 +96,3 @@ gB0FYFO3bKRemtBoB1JNyLM=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/07/19/status.html b/i2p2www/blog/2005/07/19/status.html
index 17af1ac9..61de7c2c 100644
--- a/i2p2www/blog/2005/07/19/status.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 %}<h3>I2P Status Notes for 2005-07-19</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -41,4 +38,3 @@ Toa8+cur8F8ErP5Wz57GeCs=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/07/26/status.html b/i2p2www/blog/2005/07/26/status.html
index 61c9daa7..0c60b027 100644
--- a/i2p2www/blog/2005/07/26/status.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 %}<h3>I2P Status Notes for 2005-07-26</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -45,4 +42,3 @@ ifBDYsYs61vpTg447SJ02Xk=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/08/02/status.html b/i2p2www/blog/2005/08/02/status.html
index a793e163..95ddb000 100644
--- a/i2p2www/blog/2005/08/02/status.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 %}<h3>I2P Status Notes for 2005-08-02</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -92,4 +89,3 @@ jRueb/0QtxGouKlYVM6C1Ms=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/08/09/status.html b/i2p2www/blog/2005/08/09/status.html
index b0a32e50..e093881b 100644
--- a/i2p2www/blog/2005/08/09/status.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 %}<h3>I2P Status Notes for 2005-08-09</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ uYh12HSZl+lrsjar+TS36q0=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/08/16/status.html b/i2p2www/blog/2005/08/16/status.html
index 0cf44bae..2739262a 100644
--- a/i2p2www/blog/2005/08/16/status.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 %}<h3>I2P Status Notes for 2005-08-16</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ ZA7O66ghsqwxy4dcVh9e4Hg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/08/23/status.html b/i2p2www/blog/2005/08/23/status.html
index 95e52c19..83c81ade 100644
--- a/i2p2www/blog/2005/08/23/status.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 %}<h3>I2P Status Notes for 2005-08-23</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -106,4 +103,3 @@ eZbXWs+EFfg8QQq3YIv08yw=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/08/30/status.html b/i2p2www/blog/2005/08/30/status.html
index 485d2552..21b2ccc3 100644
--- a/i2p2www/blog/2005/08/30/status.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 %}<h3>I2P Status Notes for 2005-08-30</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -104,4 +101,3 @@ omzf6cHV9GW3oBCkAHg7gns=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/09/06/status.html b/i2p2www/blog/2005/09/06/status.html
index 4d9ac134..d959867d 100644
--- a/i2p2www/blog/2005/09/06/status.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 %}<h3>I2P Status Notes for 2005-09-06</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -84,4 +81,3 @@ nGjbU9ArII04Uj3ZJiAsgC0=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/09/13/status.html b/i2p2www/blog/2005/09/13/status.html
index 548ff175..985988ec 100644
--- a/i2p2www/blog/2005/09/13/status.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 %}<h3>I2P Status Notes for 2005-09-13</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -118,4 +115,3 @@ PVtD2O9r3Xk4yT8r3UWD45E=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/09/20/status.html b/i2p2www/blog/2005/09/20/status.html
index b82e9832..265d699f 100644
--- a/i2p2www/blog/2005/09/20/status.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 %}<h3>I2P Status Notes for 2005-09-20</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -112,4 +109,3 @@ U48LKyf4X8qHAJN4Z5t8eVg=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/10/04/status.html b/i2p2www/blog/2005/10/04/status.html
index 4ef93875..d3f526ff 100644
--- a/i2p2www/blog/2005/10/04/status.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 %}<h3>I2P Status Notes for 2005-10-04</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ iD8DBQFDQtBeWYfZ3rPnHH0RAta/AJ4pXQ8TE1sXwnqtpm/KR8vWv4pKkwCff+fG
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/10/11/status.html b/i2p2www/blog/2005/10/11/status.html
index 528cf833..fa732078 100644
--- a/i2p2www/blog/2005/10/11/status.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 %}<h3>I2P Status Notes for 2005-10-11</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -133,4 +130,3 @@ pGTlS9rp+6WTthBLEZ07b2s=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/10/18/status.html b/i2p2www/blog/2005/10/18/status.html
index 08d90ac7..22294782 100644
--- a/i2p2www/blog/2005/10/18/status.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 %}<h3>I2P Status Notes for 2005-10-18</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -105,4 +102,3 @@ rYTKbx3oDZr3XWp3E9s0ag==
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/10/25/status.html b/i2p2www/blog/2005/10/25/status.html
index 339b1909..475ed252 100644
--- a/i2p2www/blog/2005/10/25/status.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 %}<h3>I2P Status Notes for 2005-10-25</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ iD8DBQFDXpFZWYfZ3rPnHH0RAqKMAJ0TdFB1/n46y3Qn8jHWVl63kwJe4gCfX9Sp
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/11/01/status.html b/i2p2www/blog/2005/11/01/status.html
index 1f81f548..e330e522 100644
--- a/i2p2www/blog/2005/11/01/status.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 %}<h3>I2P Status Notes for 2005-11-01</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -107,4 +104,3 @@ QeaqMIqTB1tvEZI3YEIQX/Y=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/11/08/status.html b/i2p2www/blog/2005/11/08/status.html
index da9362ff..97bf54df 100644
--- a/i2p2www/blog/2005/11/08/status.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 %}<h3>I2P Status Notes for 2005-11-08</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -93,4 +90,3 @@ iD8DBQFDcQFOWYfZ3rPnHH0RAu0yAKCLMH0E31zRlByRJMoZ3MSlY0JmqwCdFIgb
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/11/15/status.html b/i2p2www/blog/2005/11/15/status.html
index a4f4d572..af6e39c7 100644
--- a/i2p2www/blog/2005/11/15/status.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 %}<h3>I2P Status Notes for 2005-11-15</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -98,4 +95,3 @@ wzUvzQmeOtZhXfemCLSsuZE=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/11/22/status.html b/i2p2www/blog/2005/11/22/status.html
index 71a3c45b..43133c27 100644
--- a/i2p2www/blog/2005/11/22/status.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 %}<h3>I2P Status Notes for 2005-11-22</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -69,4 +66,3 @@ bx40VHgj3IV/F0ctUhKD540=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/11/29/status.html b/i2p2www/blog/2005/11/29/status.html
index cfa2bdea..04a26495 100644
--- a/i2p2www/blog/2005/11/29/status.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 %}<h3>I2P Status Notes for 2005-11-29</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -76,4 +73,3 @@ TGFrhg6eQyzhNa6jNV3s3bA=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/12/06/status.html b/i2p2www/blog/2005/12/06/status.html
index 4f381c10..621b9b1b 100644
--- a/i2p2www/blog/2005/12/06/status.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 %}<h3>I2P Status Notes for 2005-12-06</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -101,4 +98,3 @@ I52RW2XsrcEziJHHrihfBms=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/12/13/status.html b/i2p2www/blog/2005/12/13/status.html
index 1d87babf..6f4b1b4a 100644
--- a/i2p2www/blog/2005/12/13/status.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 %}<h3>I2P Status Notes for 2005-12-13</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -75,4 +72,3 @@ RgvenKVDEEUbUMi8ePPOkuk=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2005/12/20/status.html b/i2p2www/blog/2005/12/20/status.html
index 16a90e04..c9e4b06a 100644
--- a/i2p2www/blog/2005/12/20/status.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 %}<h3>I2P Status Notes for 2005-12-20</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -83,4 +80,3 @@ iD8DBQFDqGKDWYfZ3rPnHH0RAiHcAJ9FuF0+Pnq1DKE+phJ7tWHNHHYJAgCcDZks
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/01/03/status.html b/i2p2www/blog/2006/01/03/status.html
index c714597d..8dc0a9eb 100644
--- a/i2p2www/blog/2006/01/03/status.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 %}<h3>I2P Status Notes for 2006-01-03</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -111,4 +108,3 @@ PEKzFOKsWV54No3PoPYsd2c=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/01/10/status.html b/i2p2www/blog/2006/01/10/status.html
index 65a2235c..65dd8f13 100644
--- a/i2p2www/blog/2006/01/10/status.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 %}<h3>I2P Status Notes for 2006-01-10</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -129,4 +126,3 @@ O4wXeggK4HJFFY3qioGTjlU=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/01/17/status.html b/i2p2www/blog/2006/01/17/status.html
index 81e0b524..6d2a886e 100644
--- a/i2p2www/blog/2006/01/17/status.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 %}<h3>I2P Status Notes for 2006-01-17</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -86,4 +83,3 @@ LilfUATcbuSUa0nkgev7ZDc=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/01/24/status.html b/i2p2www/blog/2006/01/24/status.html
index 51c3c966..75f08f3c 100644
--- a/i2p2www/blog/2006/01/24/status.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 %}<h3>I2P Status Notes for 2006-01-24</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -60,4 +57,3 @@ MYP0IunumxNqgO2jfYaVq+M=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/01/31/status.html b/i2p2www/blog/2006/01/31/status.html
index 4972cae3..8d67e036 100644
--- a/i2p2www/blog/2006/01/31/status.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 %}<h3>I2P Status Notes for 2006-01-31</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -64,4 +61,3 @@ trNzQYyZ2jFQ0AKihSFGE+0=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/02/07/status.html b/i2p2www/blog/2006/02/07/status.html
index 5fd3a37f..a653a8c8 100644
--- a/i2p2www/blog/2006/02/07/status.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 %}<h3>I2P Status Notes for 2006-02-07</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -95,4 +92,3 @@ ykoV6oDPbmUhB2CZ05EWnHs=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/02/14/status.html b/i2p2www/blog/2006/02/14/status.html
index c21c9d33..7145113d 100644
--- a/i2p2www/blog/2006/02/14/status.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 %}<h3>I2P Status Notes for 2006-02-14</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -59,4 +56,3 @@ T2YquN2BKbUfLD+ubjeFUic=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/02/21/status.html b/i2p2www/blog/2006/02/21/status.html
index 8a8cbab1..dbafa845 100644
--- a/i2p2www/blog/2006/02/21/status.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 %}<h3>I2P Status Notes for 2006-02-21</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -56,4 +53,3 @@ rB9c/J0H6414HlVQmOPv8Ck=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/02/28/status.html b/i2p2www/blog/2006/02/28/status.html
index 739aafcd..d46e1732 100644
--- a/i2p2www/blog/2006/02/28/status.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 %}<h3>I2P Status Notes for 2006-02-28</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -88,4 +85,3 @@ rALo7pJF3TQlZYXxikyKBaI=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/03/07/status.html b/i2p2www/blog/2006/03/07/status.html
index ea9689a8..c3676872 100644
--- a/i2p2www/blog/2006/03/07/status.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 %}<h3>I2P Status Notes for 2006-03-07</h3>
 <pre>Hey y'all, a brief weekly update this time
 
 * Index
@@ -38,4 +35,3 @@ meeting to say hey!
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/03/14/status.html b/i2p2www/blog/2006/03/14/status.html
index b870b369..aa2ecb05 100644
--- a/i2p2www/blog/2006/03/14/status.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 %}<h3>I2P Status Notes for 2006-03-14</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -45,4 +42,3 @@ DIheXOEdcTPMGnDH4cbK8E0=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/03/21/status.html b/i2p2www/blog/2006/03/21/status.html
index 6504bb50..d51aad97 100644
--- a/i2p2www/blog/2006/03/21/status.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 %}<h3>I2P Status Notes for 2006-03-21</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -71,4 +68,3 @@ TTD/4/BorP0cK1ycO/CBhoU=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/03/28/status.html b/i2p2www/blog/2006/03/28/status.html
index 0a36fd71..5b851484 100644
--- a/i2p2www/blog/2006/03/28/status.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 %}<h3>I2P Status Notes for 2006-03-28</h3>
 <pre>Hi y'all, tuesday rolls around again
 
 * Index
@@ -49,4 +46,3 @@ meeting!
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/04/04/status.html b/i2p2www/blog/2006/04/04/status.html
index 2cca11cd..bccbeb5f 100644
--- a/i2p2www/blog/2006/04/04/status.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 %}<h3>I2P Status Notes for 2006-04-04</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -52,4 +49,3 @@ Gr8i0t2hse2x0/FbsYlNsqw=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/04/18/status.html b/i2p2www/blog/2006/04/18/status.html
index 62400c30..40ec5b34 100644
--- a/i2p2www/blog/2006/04/18/status.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 %}<h3>I2P Status Notes for 2006-04-18</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -78,4 +75,3 @@ nFrLMyhEQRCexJgH5VI2T38=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/04/25/status.html b/i2p2www/blog/2006/04/25/status.html
index a1285445..ccc507ed 100644
--- a/i2p2www/blog/2006/04/25/status.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 %}<h3>I2P Status Notes for 2006-04-25</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -51,4 +48,3 @@ VqtP1RdoT8SGPs/OqC0vdHE=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/05/02/status.html b/i2p2www/blog/2006/05/02/status.html
index a110172c..a22cecd2 100644
--- a/i2p2www/blog/2006/05/02/status.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 %}<h3>I2P Status Notes for 2006-05-02</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -53,4 +50,3 @@ edLqQiDWEyqoe0GsYGIYLCU=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/05/09/status.html b/i2p2www/blog/2006/05/09/status.html
index de512cab..a075bb0e 100644
--- a/i2p2www/blog/2006/05/09/status.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 %}<h3>I2P Status Notes for 2006-05-09</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -69,4 +66,3 @@ VDUPoPbUGi8bVf/h7Ao6jtY=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/05/16/status.html b/i2p2www/blog/2006/05/16/status.html
index f0a32a7d..7b756b51 100644
--- a/i2p2www/blog/2006/05/16/status.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 %}<h3>I2P Status Notes for 2006-05-16</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -27,4 +24,3 @@ r1U4JJaXClSyISpVf1uly2c=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/05/30/status.html b/i2p2www/blog/2006/05/30/status.html
index e828bc70..c3f8deb4 100644
--- a/i2p2www/blog/2006/05/30/status.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 %}<h3>I2P Status Notes for 2006-05-30</h3>
 <pre>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
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/06/13/status.html b/i2p2www/blog/2006/06/13/status.html
index 454c5501..e79001bd 100644
--- a/i2p2www/blog/2006/06/13/status.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 %}<h3>I2P Status Notes for 2006-06-13</h3>
 <pre>Hi gang, 'tis tuesday again,
 
 * Index
@@ -36,4 +33,3 @@ for our meeting to say hey!
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/08/01/status.html b/i2p2www/blog/2006/08/01/status.html
index aa29d512..7e4cf223 100644
--- a/i2p2www/blog/2006/08/01/status.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 %}<h3>I2P Status Notes for 2006-08-01</h3>
 <pre>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!
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/09/12/status.html b/i2p2www/blog/2006/09/12/status.html
index 97545fa9..a30f8d23 100644
--- a/i2p2www/blog/2006/09/12/status.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 %}<h3>I2P Status Notes for 2006-09-12</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -265,4 +262,3 @@ esxfTWz6qhtpyTUqsmoNlB4=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2006/10/03/status.html b/i2p2www/blog/2006/10/03/status.html
index 80241e13..85e5ca30 100644
--- a/i2p2www/blog/2006/10/03/status.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 %}<h3>I2P Status Notes for 2006-10-03</h3>
 <pre>-----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
 
@@ -260,4 +257,3 @@ H/X9NBh7t6KTc9dibqLdgow=
 
 
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/02/01/status.html b/i2p2www/blog/2008/02/01/status.html
index 4c069b79..a7aec701 100644
--- a/i2p2www/blog/2008/02/01/status.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 %}<p>New Information about situation in I2P for start of 2008.</p>
-
 <pre>
 
 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.
 
-</pre>
-{% endblock %}
+</pre>

From 255524a1de2b03fa88420398daba475b65593996 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 01:23:53 +0000
Subject: [PATCH 46/75] Display blog entries latest-first

---
 i2p2www/__init__.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index 44071e11..f85648b8 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -233,6 +233,7 @@ def get_blog_index():
                 continue
             entries.append(safe_join(slugbase, f[:-4]))
     entries.sort()
+    entries.reverse()
     return entries
 
 def get_date_from_slug(slug):

From 8e75eeb712183930fc601ac93fca2328898af581 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 01:42:51 +0000
Subject: [PATCH 47/75] Migrated over the 0.9.1 release announcement

---
 i2p2www/blog/2012/07/30/I2P_0.9.1_released.rst              | 6 ++++++
 .../pages => i2p2www/blog/2012/07/30}/release-0.9.1.html    | 6 ------
 2 files changed, 6 insertions(+), 6 deletions(-)
 create mode 100644 i2p2www/blog/2012/07/30/I2P_0.9.1_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2012/07/30}/release-0.9.1.html (97%)

diff --git a/i2p2www/blog/2012/07/30/I2P_0.9.1_released.rst b/i2p2www/blog/2012/07/30/I2P_0.9.1_released.rst
new file mode 100644
index 00000000..4333a94a
--- /dev/null
+++ b/i2p2www/blog/2012/07/30/I2P_0.9.1_released.rst
@@ -0,0 +1,6 @@
+=============
+0.9.1 Release
+=============
+
+.. raw:: html
+   :file: blog/2012/07/30/release-0.9.1.html
diff --git a/www.i2p2/pages/release-0.9.1.html b/i2p2www/blog/2012/07/30/release-0.9.1.html
similarity index 97%
rename from www.i2p2/pages/release-0.9.1.html
rename to i2p2www/blog/2012/07/30/release-0.9.1.html
index aac6d445..4f8a5270 100644
--- a/www.i2p2/pages/release-0.9.1.html
+++ b/i2p2www/blog/2012/07/30/release-0.9.1.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.9.1 Release{% endblock %}
-{% block content %}
-
 <p>
 0.9.1 includes a large number of bug fixes in i2psnark, some streaming lib improvements,
 home page changes, new themes, and translation updates.
@@ -81,5 +77,3 @@ SHA256 Checksums:
     c039b423983789d914a1d02d3703b3c1aa36c87165e132419ff39b5d184ef480  i2pupdate.sud
 
 </pre>
-
-{% endblock %}

From 2d0a6c3313c870593ff387d7802a3fe17d92b0af Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 02:03:44 +0000
Subject: [PATCH 48/75] Added a macro to simplify inserting site urls

---
 i2p2www/pages/global/layout.html              |  3 +-
 i2p2www/pages/global/macros                   |  5 +++
 i2p2www/pages/global/nav.html                 |  8 ++---
 i2p2www/pages/global/urlify                   |  9 -----
 i2p2www/pages/site/docs/how/cryptography.html | 14 ++++----
 i2p2www/pages/site/docs/how/elgamalaes.html   |  4 +--
 .../pages/site/docs/how/garlicrouting.html    | 16 ++++-----
 i2p2www/pages/site/docs/how/index.html        | 32 ++++++++---------
 i2p2www/pages/site/docs/how/intro.html        | 22 ++++++------
 .../site/docs/how/networkcomparisons.html     |  4 +--
 .../pages/site/docs/how/networkdatabase.html  | 12 +++----
 .../pages/site/docs/how/peerselection.html    |  6 ++--
 i2p2www/pages/site/docs/how/threatmodel.html  | 36 +++++++++----------
 .../pages/site/docs/how/tunnelrouting.html    | 16 ++++-----
 i2p2www/pages/site/docs/techintro.html        |  6 ++--
 15 files changed, 95 insertions(+), 98 deletions(-)
 create mode 100644 i2p2www/pages/global/macros
 delete mode 100644 i2p2www/pages/global/urlify

diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html
index d66b24c6..6fc7fb43 100644
--- a/i2p2www/pages/global/layout.html
+++ b/i2p2www/pages/global/layout.html
@@ -1,3 +1,4 @@
+{%- from "global/macros" import site_url with context -%}
 <!DOCTYPE html>
 <html lang="en">
   <head>
@@ -10,7 +11,7 @@
   <body>
     <div class="hide"><a href="#content" title="Skip navigation" accesskey="2">Skip navigation</a></div>
     <div id="branding">
-      <h1 id="logo"><a href="{{ url_for('site_show', lang=g.lang) }}"><img src="{{ url_for('static', filename='images/logo_medium.png') }}" alt="I2P" /></a></h1>
+      <h1 id="logo"><a href="{{ site_url() }}"><img src="{{ url_for('static', filename='images/logo_medium.png') }}" alt="I2P" /></a></h1>
       <div class="title">{{ self.title() }}</div>
     </div>
     <div class="navigation">
diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros
new file mode 100644
index 00000000..a99b1d17
--- /dev/null
+++ b/i2p2www/pages/global/macros
@@ -0,0 +1,5 @@
+{%- macro site_url(path=None) -%}
+{%- if path -%}{{ url_for('site_show', lang=g.lang, page=path) }}
+{%- else -%}{{ url_for('site_show', lang=g.lang) }}
+{%- endif -%}
+{%- endmacro -%}
diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 2b5a0f3c..08806dcc 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -1,13 +1,13 @@
 <div id="cssmenu">
 <ul>
-  <li><a href="{{ url_for('site_show', lang=g.lang) }}"><span>Home</span></a></li>
+  <li><a href="{{ site_url() }}"><span>Home</span></a></li>
   <li><a href="{{ url_for('downloads_list', lang=g.lang) }}"><span>Download</span></a></li>
   <li class="has-sub"><a href="#"><span>Docs</span></a>
     <ul>
-      <li class="has-sub"><a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}"><span>How does it work?</span></a>
+      <li class="has-sub"><a href="{{ site_url('docs/how') }}"><span>How does it work?</span></a>
         <ul>
-          <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}"><span>Gentle intro</span></a></li>
-          <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}"><span>Tech intro</span></a></li>
+          <li><a href="{{ site_url('docs/how/intro') }}"><span>Gentle intro</span></a></li>
+          <li><a href="{{ site_url('docs/techintro') }}"><span>Tech intro</span></a></li>
         </ul>
       </li>
       <li><a href="howto.html"><span>Howto docs</span></a></li>
diff --git a/i2p2www/pages/global/urlify b/i2p2www/pages/global/urlify
deleted file mode 100644
index e8c9cd78..00000000
--- a/i2p2www/pages/global/urlify
+++ /dev/null
@@ -1,9 +0,0 @@
-{% macro urlify(url, title, suffix) %}
-   {% autoescape false %}
-    {% if static %}
-    <a href="{{url}}.{{suffix}}">{{title}}</a>
-    {% else %}
-    <a href="{{url}}">{{title}}</a>
-    {% endif %}
-   {% endautoescape %}
-{% endmacro %}
\ No newline at end of file
diff --git a/i2p2www/pages/site/docs/how/cryptography.html b/i2p2www/pages/site/docs/how/cryptography.html
index c5ffc62a..3acdc43b 100644
--- a/i2p2www/pages/site/docs/how/cryptography.html
+++ b/i2p2www/pages/site/docs/how/cryptography.html
@@ -12,7 +12,7 @@ one asymmetric algorithm, one signing algorithm, and one hashing algorithm.  How
 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
+technique used in <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
 <p>
 <H2><a name="elgamal">ElGamal encryption</a></H2>
 
@@ -25,7 +25,7 @@ To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Mess
 For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
 using the encryption key in the <a href="common_structures_spec.html#struct_LeaseSet">LeaseSet</a>
 </li><li>
-For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
+For encryption of some <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
 as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
 (destination-to-router or router-to-router).
 </li></ul>
@@ -158,13 +158,13 @@ AES is used for symmetric encryption, in several cases:
 <ul><li>
 For <a href="#transports">transport encryption</a> after DH key exchange
 </li><li>
-For end-to-end (destination-to-destination) encryption as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
+For end-to-end (destination-to-destination) encryption as a part of <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
 </li><li>
-For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
-as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
+For encryption of some <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
+as a part of <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
 (destination-to-router or router-to-router).
 </li><li>
-For encryption of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
+For encryption of <a href="{{ site_url('docs/how/tunnelrouting') }}#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
 </li></ul>
 </p><p>
 We use AES with 256 bit keys and 128 bit blocks in CBC mode.
@@ -376,7 +376,7 @@ 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> does not.
+The primary reason to do the DH negotiation instead of using <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> does not.
 </p>
 <p>
 In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
diff --git a/i2p2www/pages/site/docs/how/elgamalaes.html b/i2p2www/pages/site/docs/how/elgamalaes.html
index 01e45f7c..7fec1547 100644
--- a/i2p2www/pages/site/docs/how/elgamalaes.html
+++ b/i2p2www/pages/site/docs/how/elgamalaes.html
@@ -142,7 +142,7 @@ The 32-byte Pre-IV will be used to generate the IV for the AES block that follow
 the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
 </p><p>
 The 222 byte payload is encrypted
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#elgamal">using ElGamal</a>
+<a href="{{ site_url('docs/how/cryptography') }}#elgamal">using ElGamal</a>
 and the encrypted block is 514 bytes long.
 </p>
 
@@ -212,7 +212,7 @@ Minimum length: 48 bytes
 </PRE>
 
 </p><p>
-The data is then <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">AES Encrypted</a>,
+The data is then <a href="{{ site_url('docs/how/cryptography') }}">AES Encrypted</a>,
 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.
 </p>
diff --git a/i2p2www/pages/site/docs/how/garlicrouting.html b/i2p2www/pages/site/docs/how/garlicrouting.html
index cd311d88..ae724089 100644
--- a/i2p2www/pages/site/docs/how/garlicrouting.html
+++ b/i2p2www/pages/site/docs/how/garlicrouting.html
@@ -42,7 +42,7 @@ 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.
 </p><p>
 This is similar to the way Mixmaster
-(see <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a>) sends messages - taking a message, encrypting it
+(see <a href="{{ site_url('docs/how/networkcomparisons') }}">network comparisons</a>) 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
@@ -84,7 +84,7 @@ and reliable delivery.
 
 <h3>ElGamal/AES Encryption</h3>
 In some cases, "garlic encryption" may simply mean
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
+<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
 (without multiple layers).
 
 
@@ -117,7 +117,7 @@ This is described on the
 Tunnel building details are defined on
 <a href="tunnel-alt-creation.html">this page</a>.
 We use
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
+<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
 </p><p>
 Tunnels are a general-purpose mechanism to transport all
 <a href="i2np.html">I2NP messages</a>, and
@@ -134,7 +134,7 @@ the tunnel encryption is sufficient.
 At the layer above tunnels, I2P delivers end-to-end messages between
 <a href="common_structures_spec#struct_Destination">Destinations</a>.
 Just as within a single tunnel, we use
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
+<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
 Each client message as delivered to the router through the
 <a href="i2cp.html">I2CP interface</a> becomes a single
 <a href="i2np.html#struct_GarlicClove">Garlic Clove</a>
@@ -174,7 +174,7 @@ By periodically bundling a LeaseSet, the router ensures that the far-end will be
 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
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database page</a>.
+<a href="{{ site_url('docs/how/networkdatabase') }}">network database page</a>.
 </li></ol>
 
 </p><p>
@@ -191,7 +191,7 @@ and not part of a general-purpose routing scheme.
 <h3> Storage to the Floodfill Network Database</h3>
 </p>
 As explained on the
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">network database page</a>,
+<a href="{{ site_url('docs/how/networkdatabase') }}#delivery">network database page</a>,
 local
 <a href="common_structures_spec#struct_LeaseSet">LeaseSets</a>
 are sent to floodfill routers in a
@@ -220,14 +220,14 @@ as limiting certain routing paths, restricting the types of I2NP messages that m
 be forwarded along various paths, and enforcing certain message expiration times.
 </p><p>
 As a part of
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES encryption</a>,
+<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES encryption</a>,
 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.
 </p><p>
 Encryption of additional messages to and from the
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
+<a href="{{ site_url('docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
 </p>
 
 
diff --git a/i2p2www/pages/site/docs/how/index.html b/i2p2www/pages/site/docs/how/index.html
index 0d6950df..5f8d149e 100644
--- a/i2p2www/pages/site/docs/how/index.html
+++ b/i2p2www/pages/site/docs/how/index.html
@@ -21,10 +21,10 @@ If you find any inaccuracies in the documents linked below, please
 
 <h3>Overview</h3>
 <ul class="helplist">
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}">Technical Introduction</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}">A Less-Technical Introduction</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">Threat model and analysis</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Comparisons to other anonymous networks</a></li>
+<li><a href="{{ site_url('docs/techintro') }}">Technical Introduction</a></li>
+<li><a href="{{ site_url('docs/how/intro') }}">A Less-Technical Introduction</a></li>
+<li><a href="{{ site_url('docs/how/threatmodel') }}">Threat model and analysis</a></li>
+<li><a href="{{ site_url('docs/how/networkcomparisons') }}">Comparisons to other anonymous networks</a></li>
 <li><a href="protocols.html">Protocol stack chart</a></li>
 <li><a href="papers.html">Papers and Presentations on I2P</a></li>
 <li><a href="{{ url_for('static', filename='pdf/i2p_philosophy.pdf') }}">Invisible Internet Project (I2P) Project Overview</a> August 28, 2003 (pdf)</li>
@@ -101,16 +101,16 @@ Traditionally used only by Java applications and higher-level APIs.
 <h3>End-to-End Encryption</h3>
 How client messages are end-to-end encrypted by the router.
 <ul>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption</li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
+<li><a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption</li>
+<li><a href="{{ site_url('docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
 </ul>
 
 <h3>Network Database</h3>
 Distributed storage and retrieval of information about routers and clients.
 <ul>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">Network database overview, details, and threat analysis</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#SHA256">Cryptographic hashes</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#DSA">Cryptographic signatures</a></li>
+<li><a href="{{ site_url('docs/how/networkdatabase') }}">Network database overview, details, and threat analysis</a></li>
+<li><a href="{{ site_url('docs/how/cryptography') }}#SHA256">Cryptographic hashes</a></li>
+<li><a href="{{ site_url('docs/how/cryptography') }}#DSA">Cryptographic signatures</a></li>
 </ul>
 
 <h3>Router Message Protocol</h3>
@@ -130,12 +130,12 @@ I2P is a message-oriented router. The messages sent between routers are defined
 <h3>Tunnels</h3>
 Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
 <ul>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">Peer profiling and selection</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">Tunnel routing overview</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">Garlic routing and "garlic" terminology</a></li>
+<li><a href="{{ site_url('docs/how/peerselection') }}">Peer profiling and selection</a></li>
+<li><a href="{{ site_url('docs/how/tunnelrouting') }}">Tunnel routing overview</a></li>
+<li><a href="{{ site_url('docs/how/garlicrouting') }}">Garlic routing and "garlic" terminology</a></li>
 <li><a href="tunnel-alt.html">Tunnel building and encryption</a></li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES</a> for build request encryption</li>
-<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
+<li><a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES</a> for build request encryption</li>
+<li><a href="{{ site_url('docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
 <li><a href="tunnel-alt-creation.html">Tunnel building specification</a></li>
 <li><a href="tunnel_message_spec.html">Low-level tunnel message specification</a></li>
 <li><a href="unidirectional-tunnels.html">Unidirectional Tunnels</a></li>
@@ -154,9 +154,9 @@ The protocols for direct (point-to-point) router to router communication.
 </li><li>
 <a href="udp_spec.html">SSU specification</a>
 </li><li>
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
+<a href="{{ site_url('docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
 </li><li>
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#udp">SSU transport encryption</a>
+<a href="{{ site_url('docs/how/cryptography') }}#udp">SSU transport encryption</a>
 </li><li>
 <a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
 </li><li>
diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
index b460686d..83946826 100644
--- a/i2p2www/pages/site/docs/how/intro.html
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -32,7 +32,7 @@ Instead their view will be of one of the I2P enabled applications, or perhaps as
 app to turn on and off various proxies to enable the anonymizing functionality.</p>
 
 <p>An essential part of designing, developing, and testing an anonymizing network is to define the 
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>, since there is no such thing as "true" anonymity, just 
+<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>, 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
@@ -43,20 +43,20 @@ others.</p>
 <h2>Why?</h2>
 <p>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 
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other efforts</a> working on finding ways to provide varying degrees of 
+<a href="{{ site_url('docs/how/networkcomparisons') }}">other efforts</a> 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.</p>
 
 <h2>How?</h2>
 
 <p>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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel routing</a> page). 
+inbound and outbound virtual paths ("tunnels", as outlined on the <a href="{{ site_url('docs/how/tunnelrouting') }}">tunnel routing</a> 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> (using a modification of 
+network.  I2P has its own internal <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a> (using a modification of 
 the Kademlia algorithm) for distributing routing and contact information securely.</p>
 
 <div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="Network topology example" title="Network topology example" /></div>
@@ -73,7 +73,7 @@ network database, which is constantly updated as new leases are authorized and o
   
 <p>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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the 
+messages sent between Alice and Bob are <a href="{{ site_url('docs/how/garlicrouting') }}">garlic</a> 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.</p>
 
@@ -81,12 +81,12 @@ in the network database for the current data.</p>
 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> page.</p>
+needs of the users, as described in the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> page.</p>
 
-<p>The network itself makes use of a significant number of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">cryptographic techniques and algorithms</a> - 
+<p>The network itself makes use of a significant number of <a href="{{ site_url('docs/how/cryptography') }}">cryptographic techniques and algorithms</a> - 
 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
+station authentication, and <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
 
 <p>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 
@@ -100,7 +100,7 @@ A and h are the routers of Alice and Bob, while Alice and Bob in following chart
 
 <div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="End to end layered encryption" title="End to end layered encryption." /></div>
 
-<p>The specific use of these algorithms are outlined <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">elsewhere</a>.</p>
+<p>The specific use of these algorithms are outlined <a href="{{ site_url('docs/how/cryptography') }}">elsewhere</a>.</p>
 
 <p>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 
@@ -111,7 +111,7 @@ flexible and anonymous transports.</p>
 
 <p>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 
-<code>O(log(N))</code> due to the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end 
+<code>O(log(N))</code> due to the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end 
 messages should be <code>O(1)</code> (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.</p>
@@ -144,7 +144,7 @@ There are currently no scheduled development meetings, however
 
 <h2>Additional Information</h2>
 <p>
-See <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">the Index to Technical Documentation</a>
+See <a href="{{ site_url('docs/how') }}">the Index to Technical Documentation</a>
 </p>
 
 {% endblock %}
diff --git a/i2p2www/pages/site/docs/how/networkcomparisons.html b/i2p2www/pages/site/docs/how/networkcomparisons.html
index 2a15493c..f06dfd5b 100644
--- a/i2p2www/pages/site/docs/how/networkcomparisons.html
+++ b/i2p2www/pages/site/docs/how/networkcomparisons.html
@@ -37,8 +37,8 @@ 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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network 
-database</a> and <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a>.</p>
+opposed to I2P's distributed <a href="{{ site_url('docs/how/networkdatabase') }}">network 
+database</a> and <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a>.</p>
 
 <p>The I2P/Tor outproxy functionality does have a few 
 substantial weaknesses against certain attackers - 
diff --git a/i2p2www/pages/site/docs/how/networkdatabase.html b/i2p2www/pages/site/docs/how/networkdatabase.html
index f05d9761..66fee2f4 100644
--- a/i2p2www/pages/site/docs/how/networkdatabase.html
+++ b/i2p2www/pages/site/docs/how/networkdatabase.html
@@ -506,7 +506,7 @@
 
 <h2 id="threat">Threat Analysis</h2>
 <p>
-  Also discussed on <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#floodfill">the threat model page</a>.
+  Also discussed on <a href="{{ site_url('docs/how/threatmodel') }}#floodfill">the threat model page</a>.
 </p>
 <p>
   A hostile user may attempt to harm the network by
@@ -538,7 +538,7 @@
 <h3>Slow or Unresponsive</h3>
 <p>
   Each router maintains an expanded set of statistics in the
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profile</a> for each floodfill router,
+  <a href="{{ site_url('docs/how/peerselection') }}">peer profile</a> for each floodfill router,
   covering various quality metrics for that peer.
   The set includes:
 </p>
@@ -709,7 +709,7 @@ This attack becomes more difficult as the network size grows.
 </p>
 <p>
   This doesn't have much to do with floodfill, but see
-  the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>
+  the <a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>
   for a discussion of the vulnerabilities of peer selection for tunnels.
 </p>
 
@@ -722,8 +722,8 @@ This attack becomes more difficult as the network size grows.
   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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> and
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel building</a> processes; only previously-known peers
+  loosely correlated to the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> and
+  <a href="{{ site_url('docs/how/tunnelrouting') }}">tunnel building</a> processes; only previously-known peers
   are used for tunnels.
   Also, peer selection is unrelated to any notion of DHT key-closeness.
 </p>
@@ -739,7 +739,7 @@ This attack becomes more difficult as the network size grows.
   The floodfill routers are in a position to observe queries and gather information.
   Certainly, at a level of <i>f</i> = 0.2 (20% malicious nodes, as specifed in the paper)
   we expect that many of the Sybil threats we describe
-  (<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#sybil">here</a>,
+  (<a href="{{ site_url('docs/how/threatmodel') }}#sybil">here</a>,
   <a href="#sybil">here</a> and
   <a href="#sybil-partial">here</a>)
   become problematic for several reasons.
diff --git a/i2p2www/pages/site/docs/how/peerselection.html b/i2p2www/pages/site/docs/how/peerselection.html
index 693d5c1b..fba7b842 100644
--- a/i2p2www/pages/site/docs/how/peerselection.html
+++ b/i2p2www/pages/site/docs/how/peerselection.html
@@ -11,14 +11,14 @@ Updated July 2010 for release 0.8
 <p><b>Peer profiling</b> is the process of collecting data based on the <b>observed</b> performance
 of other routers or peers, and classifying those peers into groups.
 Profiling does <b>not</b> use any claimed performance data published by the peer itself
-in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>.
+in the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>.
 
 <p>
 Profiles are used for two purposes:
 <ol>
 <li>Selecting peers to relay our traffic through, which is discussed below
 <li>Choosing peers from the set of floodfill routers to use for network database storage and queries,
-    which is discussed on the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> page
+    which is discussed on the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a> page
 </ol>
 
 
@@ -38,7 +38,7 @@ 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
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#timing">timing attacks</a>
+<a href="{{ site_url('docs/how/threatmodel') }}#timing">timing attacks</a>
 more difficult.
 </p>
 <p>
diff --git a/i2p2www/pages/site/docs/how/threatmodel.html b/i2p2www/pages/site/docs/how/threatmodel.html
index f82c3455..5d265c78 100644
--- a/i2p2www/pages/site/docs/how/threatmodel.html
+++ b/i2p2www/pages/site/docs/how/threatmodel.html
@@ -24,7 +24,7 @@ More review of existing literature (much of it focused on Tor) and original
 work focused on I2P is needed.</p>
 
 <h2>Network Topology Summary</h2>
-<p>I2P builds off the ideas of many <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other</a> 
+<p>I2P builds off the ideas of many <a href="{{ site_url('docs/how/networkcomparisons') }}">other</a> 
 <a href="links">systems</a>, but a few key points should be kept in mind when 
 reviewing related literature:</p><ul>
 <li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
@@ -88,8 +88,8 @@ As we continue to spread the word and grow the network,
 these attacks will become much harder.
 </p><p>
 The
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a> and
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
+<a href="{{ site_url('docs/how/networkcomparisons') }}">network comparisons</a> and
+<a href="{{ site_url('docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
 to review.
 </p>
 
@@ -147,7 +147,7 @@ routers contain limits as to how many tunnels can be routed through a single pee
 As the network grows, these limits are subject to further adjustment.
 Other mechanisms for peer rating, selection and avoidance
 are discussed on the
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>.
+<a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>.
 </p>
 
 
@@ -203,7 +203,7 @@ Partial defenses implemented in I2P:
 <ul><li>
 <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
 </li><li>
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
+<a href="{{ site_url('docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
 </li><li>
 Limits on the number of tunnels routed through a single peer
 </li><li>
@@ -211,7 +211,7 @@ Prevention of peers from the same /16 IP range from being members of a single tu
 </li><li>
 For eepsites or other hosted services, we support
 simultaneous hosting on multiple routers, or
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#intersection">multihoming</a>
+<a href="{{ site_url('docs/how/threatmodel') }}#intersection">multihoming</a>
 </li></ul>
 
 Even in total, these defenses are not a complete solution.
@@ -270,7 +270,7 @@ each with different costs and consequences:</p><ul>
     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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">profiles</a> on the 
+    I2P addresses these issues by maintaining <a href="{{ site_url('docs/how/peerselection') }}">profiles</a> on the 
     peers, attempting to identify underperforming ones and simply ignoring 
     them, or using them rarely.
     We have significantly enhanced the
@@ -305,10 +305,10 @@ each with different costs and consequences:</p><ul>
     A floodfill router may provide bad or no response to lookups, and
     it may also interfere with inter-floodfill communication.
     Some defenses and
-    <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> are implemented,
+    <a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> are implemented,
     however there is much more to do.
     For more information see the
-    <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
+    <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
 </li>
 </ul>
 
@@ -356,7 +356,7 @@ matter, the attacker would need to control a significant portion of the network
 which other tunnels or messages have those delays).
 </p><p>
 Also discussed on the
-    <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
+    <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
 </p>
 
 <h3 id="predecessor">Predecessor attacks</h3>
@@ -371,7 +371,7 @@ target is located.  </p>
 
 <p>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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
+the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
 into tiers.  Second, with <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
 in a tunnel, the fact that a peer shows up more frequently does not mean they're
 the source.  Third, with <a href="tunnel-alt.html#length">permuted tunnel length</a>
@@ -505,7 +505,7 @@ in several IP blocks.
 However, this is not a meaningful defense against a powerful adversary.
 </p><p>
 See the
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>
+  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>
 for more Sybil discussion.
 </p>
 
@@ -521,7 +521,7 @@ 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 <a href="#sybil">Sybil attack</a>.
 This is somewhat mitigated by our
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
+<a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
 of peers.
 However, this is a powerful attack as the number of routers approaches
 <i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
@@ -537,7 +537,7 @@ Further research and defenses may be necessary.
 <p>
 We use strong cryptography with long keys, and
 we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">on the low-level cryptography page</a>. 
+<a href="{{ site_url('docs/how/cryptography') }}">on the low-level cryptography page</a>. 
 Security features
 include the immediate detection of 
 altered messages along the path, the inability to decrypt messages not addressed to you,
@@ -555,7 +555,7 @@ shared secret values while maintaining backward compatibility.
 </p><p>
 Upgrading the various data structures and protocols to support longer keys
 will have to be tackled eventually, and this will be a
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">major undertaking</a>, just as it will be for 
+<a href="{{ site_url('docs/how/cryptography') }}">major undertaking</a>, just as it will be for 
 <a href="https://torproject.org/">others</a>.
 Hopefully, through careful planning, we can minimize the disruption, and
 implement mechanisms to make it easier for future transitions.
@@ -578,9 +578,9 @@ 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
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
+  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
 The specific mechanisms by which routers communicate with floodfills have been
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">carefully designed</a>.
+  <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">carefully designed</a>.
 However, these threats should be studied further.
 The specific potential threats and corresponding defenses are a topic for future research.
 </p>
@@ -592,7 +592,7 @@ The specific potential threats and corresponding defenses are a topic for future
   creating one or more floodfill routers and crafting them to offer
   bad, slow, or no responses.
   Several scenarios are discussed on the
-  <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
+  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
 </p>
 
 
diff --git a/i2p2www/pages/site/docs/how/tunnelrouting.html b/i2p2www/pages/site/docs/how/tunnelrouting.html
index 43ae9767..28782695 100644
--- a/i2p2www/pages/site/docs/how/tunnelrouting.html
+++ b/i2p2www/pages/site/docs/how/tunnelrouting.html
@@ -10,7 +10,7 @@ Updated July 2011 for release 0.8.7
 This page contains an overview of I2P tunnel terminology and operation, with
 links to more technical pages, details, and specifications.
 </p>
-<p>As briefly explained in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">introduction</a>, I2P builds virtual "tunnels" -
+<p>As briefly explained in the <a href="{{ site_url('docs/how') }}">introduction</a>, 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
@@ -35,7 +35,7 @@ F: Inbound Endpoint (Bob)
 <ul>
 	<li class="gap"><b>Tunnel gateway</b> - the first router in a tunnel.  For inbound tunnels,
 		this is the one mentioned in the LeaseSet published in the
-	<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>.  For outbound tunnels, the
+	<a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>.  For outbound tunnels, the
 		gateway is the originating router.  (e.g. both A and D above)</li>
 	<li class="gap"><b>Tunnel endpoint</b> - the last router in a tunnel.  (e.g. both C and F above)</li>
 	<li class="gap"><b>Tunnel participant</b> - all routers in a tunnel except for the gateway or
@@ -157,7 +157,7 @@ but could show similar information (though would be slightly harder to mount)</p
 <h3>1-hop tunnels</h3>
 <p>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 <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>). However,
+adversary (as described on <a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>). 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.</p>
@@ -190,12 +190,12 @@ DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunne
 functional. If it was used for a client's inbound tunnel, a new leaseSet
 is created.
 Tunnel test failures are also reflected in the
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}#capacity">capacity rating in the peer profile</a>.
+<a href="{{ site_url('docs/how/peerselection') }}#capacity">capacity rating in the peer profile</a>.
 </p>
 
 
 <h2>Tunnel creation</h2>
-<p>Tunnel creation is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
+<p>Tunnel creation is handled by <a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing</a>
 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
@@ -207,7 +207,7 @@ Details are in the
 
 
 <h2>Tunnel encryption</h2>
-<p>Multi-layer encryption is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic encryption</a>
+<p>Multi-layer encryption is handled by <a href="{{ site_url('docs/how/garlicrouting') }}">garlic encryption</a>
 of tunnel messages.
 Details are in the
 <a href="tunnel-alt.html">tunnel specification</a>.
@@ -245,9 +245,9 @@ tunnel's lifetime may be implemented (e.g. no more than 300 messages or
 </li><li>
 <a href="tunnel_message_spec.html">tunnel message specification</a>
 </li><li>
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
+<a href="{{ site_url('docs/how/garlicrouting') }}">garlic routing</a>
 </li><li>
-<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
+<a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
 </li><li>
 <a href="i2cp.html#options">I2CP options</a>
 </li>
diff --git a/i2p2www/pages/site/docs/techintro.html b/i2p2www/pages/site/docs/techintro.html
index e05b35c9..b27a092b 100644
--- a/i2p2www/pages/site/docs/techintro.html
+++ b/i2p2www/pages/site/docs/techintro.html
@@ -306,7 +306,7 @@
   <h2 id="op.netdb">Network Database</h2>
   <p>
     As mentioned earlier, I2P's netDb works to share the network's metadata.
-    This is detailed in <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">the networkdatabase</a> page,
+    This is detailed in <a href="{{ site_url('docs/how/networkdatabase') }}">the networkdatabase</a> page,
     but a basic explanation is available below.
   </p>
   <p>
@@ -320,7 +320,7 @@
     If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
     using the <a href="http://en.wikipedia.org/wiki/Kademlia">Kademlia algorithm</a>.
     The 'lookup' queries currently function differently, to avoid an important
-    <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#lookup">security issue</a>.
+    <a href="{{ site_url('docs/how/networkdatabase') }}#lookup">security issue</a>.
     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).
   </p>
@@ -576,7 +576,7 @@ What other tunnel peer selection and ordering strategies should be available?
     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. </p>
-  <p> See also the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Network Comparisons Page</a>. 
+  <p> See also the <a href="{{ site_url('docs/how/networkcomparisons') }}">Network Comparisons Page</a>. 
   </p>
 
   <h2 id="similar.tor">Tor</h2>

From 01ff425135f315196a16b011ab6dd1d669749bc5 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 23:31:26 +0000
Subject: [PATCH 49/75] Migrated over FAQ

---
 i2p2www/pages/global/nav.html                           | 2 +-
 {www.i2p2/pages => i2p2www/pages/site/support}/faq.html | 7 +++----
 2 files changed, 4 insertions(+), 5 deletions(-)
 rename {www.i2p2/pages => i2p2www/pages/site/support}/faq.html (99%)

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 08806dcc..b220edd0 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -16,7 +16,7 @@
   </li>
   <li class="has-sub"><a href="#"><span>Support</span></a>
     <ul>
-      <li><a href="faq.html"><span>FAQ</span></a></li>
+      <li><a href="{{ site_url('support/faq') }}"><span>FAQ</span></a></li>
       <li><a href="http://forum.i2p2.de/"><span>Forums</span></a></li>
     </ul>
   </li>
diff --git a/www.i2p2/pages/faq.html b/i2p2www/pages/site/support/faq.html
similarity index 99%
rename from www.i2p2/pages/faq.html
rename to i2p2www/pages/site/support/faq.html
index f0b3f451..882cd86a 100644
--- a/www.i2p2/pages/faq.html
+++ b/i2p2www/pages/site/support/faq.html
@@ -1,7 +1,6 @@
-{% extends "_layout.html" %}
-{% block title %}FAQ{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}Frequently Asked Questions{% endblock %}
 {% block content %}
-<h1>I2P - FREQUENTLY ASKED QUESTIONS</h1>
 <h3 id="index"> Index </h3>
 <ol>
 <li style="list-style: none; display: inline">
@@ -276,7 +275,7 @@ The best way to stay "better-connected" to the network is to <a href="http://loc
 <span class="permalink">(<a href="#proxy_safe">link</a>)</span></h3>
 <p>
    This is a question that only you can answer because the correct answer depends on your behaviours, your
-   <a href="how_threatmodel.html">threat model</a>, and how much you trust the outproxy operator.
+   <a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>, and how much you trust the outproxy operator.
 </p><p>
    Like Tor, I2P does not magically encrypt the Internet.
    You are vulnerable to snooping by the outproxy operators.

From ca2094c5e014c106f688e6a7bdbc9aca9bfb10bb Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 14 Sep 2012 23:43:17 +0000
Subject: [PATCH 50/75] Migrated getinvolved.html to volunteer/index.html

---
 i2p2www/pages/global/nav.html                                 | 2 +-
 .../pages/site/volunteer/index.html                           | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename www.i2p2/pages/getinvolved.html => i2p2www/pages/site/volunteer/index.html (95%)

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index b220edd0..72547e0f 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -27,7 +27,7 @@
       <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
-  <li class="has-sub"><a href="#"><span>Volunteer</span></a>
+  <li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>Volunteer</span></a>
     <ul>
       <li><a href="bounties.html"><span>Bounties</span></a></li>
       <li><a href="roadmap.html"><span>Roadmap</span></a></li>
diff --git a/www.i2p2/pages/getinvolved.html b/i2p2www/pages/site/volunteer/index.html
similarity index 95%
rename from www.i2p2/pages/getinvolved.html
rename to i2p2www/pages/site/volunteer/index.html
index 68981373..c436f5c2 100644
--- a/www.i2p2/pages/getinvolved.html
+++ b/i2p2www/pages/site/volunteer/index.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Get Involved!{% endblock %}
 {% block content %}
 <h1>We need your help!</h1>
@@ -43,7 +43,7 @@ See the <a href="newtranslators.html">new translator's guide</a> for details.
 </li><li><b>Analysis</b> —
 Study or test the code to look for vulnerabilities.
 Both anonymity vulnerabilities from the various
-<a href="how_threatmodel.html">threat models</a>,
+<a href="{{ site_url('docs/how/threatmodel') }}">threat models</a>,
 and DOS and other weaknesses due to securities holes,
 need researching.
 </li><li><b><a href="donate.html">Donate</a></b>

From 17fa2f7942990ccf28e78258455fad1f42c8aea6 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Sat, 15 Sep 2012 03:18:17 +0000
Subject: [PATCH 51/75] Migrated over bounties

---
 i2p2www/pages/global/nav.html                 |  2 +-
 .../pages/site/volunteer/bounties/arabic.html |  2 +-
 .../site/volunteer/bounties/btcclient.html    |  2 +-
 .../site/volunteer/bounties/datastore.html    |  2 +-
 .../site/volunteer/bounties/debpack.html      |  3 +--
 .../pages/site/volunteer/bounties/i2phex.html |  2 +-
 .../pages/site/volunteer/bounties/index.html  | 24 +++++++++----------
 .../pages/site/volunteer/bounties/ipv6.html   |  2 +-
 .../site/volunteer/bounties/rutrans.html      |  2 +-
 .../pages/site/volunteer/bounties/silc.html   |  2 +-
 .../site/volunteer/bounties/unittests.html    |  4 ++--
 .../site/volunteer/bounties/vuzeplugin.html   |  2 +-
 12 files changed, 24 insertions(+), 25 deletions(-)
 rename www.i2p2/pages/bounty_arabic.html => i2p2www/pages/site/volunteer/bounties/arabic.html (97%)
 rename www.i2p2/pages/bounty_btcclient.html => i2p2www/pages/site/volunteer/bounties/btcclient.html (95%)
 rename www.i2p2/pages/bounty_datastore.html => i2p2www/pages/site/volunteer/bounties/datastore.html (98%)
 rename www.i2p2/pages/bounty_debpack.html => i2p2www/pages/site/volunteer/bounties/debpack.html (92%)
 rename www.i2p2/pages/bounty_i2phex.html => i2p2www/pages/site/volunteer/bounties/i2phex.html (93%)
 rename www.i2p2/pages/bounties.html => i2p2www/pages/site/volunteer/bounties/index.html (78%)
 rename www.i2p2/pages/bounty_ipv6.html => i2p2www/pages/site/volunteer/bounties/ipv6.html (96%)
 rename www.i2p2/pages/bounty_rutrans.html => i2p2www/pages/site/volunteer/bounties/rutrans.html (97%)
 rename www.i2p2/pages/bounty_silc.html => i2p2www/pages/site/volunteer/bounties/silc.html (96%)
 rename www.i2p2/pages/bounty_unittests.html => i2p2www/pages/site/volunteer/bounties/unittests.html (98%)
 rename www.i2p2/pages/bounty_vuzeplugin.html => i2p2www/pages/site/volunteer/bounties/vuzeplugin.html (96%)

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 72547e0f..34734abc 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -29,7 +29,7 @@
   </li>
   <li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>Volunteer</span></a>
     <ul>
-      <li><a href="bounties.html"><span>Bounties</span></a></li>
+      <li><a href="{{ site_url('volunteer/bounties') }}"><span>Bounties</span></a></li>
       <li><a href="roadmap.html"><span>Roadmap</span></a></li>
       <li><a href="todo.html"><span>Task list</span></a></li>
     </ul>
diff --git a/www.i2p2/pages/bounty_arabic.html b/i2p2www/pages/site/volunteer/bounties/arabic.html
similarity index 97%
rename from www.i2p2/pages/bounty_arabic.html
rename to i2p2www/pages/site/volunteer/bounties/arabic.html
index 448f9002..f243aa51 100644
--- a/www.i2p2/pages/bounty_arabic.html
+++ b/i2p2www/pages/site/volunteer/bounties/arabic.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty Arabic translation of webpage and router console{% endblock %}
 {% block content %}<p>To improve I2P usage and attract more people
 into I2P echelon set out this bounty for translation
diff --git a/www.i2p2/pages/bounty_btcclient.html b/i2p2www/pages/site/volunteer/bounties/btcclient.html
similarity index 95%
rename from www.i2p2/pages/bounty_btcclient.html
rename to i2p2www/pages/site/volunteer/bounties/btcclient.html
index 52318a96..465f9ebd 100644
--- a/www.i2p2/pages/bounty_btcclient.html
+++ b/i2p2www/pages/site/volunteer/bounties/btcclient.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty creating a I2P native Bitcoin client {% endblock %}
 {% block content %}<p>For a future of I2P and attract more people
 into I2P this bounty is to create a I2P native Bitcoin client. 
diff --git a/www.i2p2/pages/bounty_datastore.html b/i2p2www/pages/site/volunteer/bounties/datastore.html
similarity index 98%
rename from www.i2p2/pages/bounty_datastore.html
rename to i2p2www/pages/site/volunteer/bounties/datastore.html
index 217461cb..fb7dd654 100644
--- a/www.i2p2/pages/bounty_datastore.html
+++ b/i2p2www/pages/site/volunteer/bounties/datastore.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty datastorage{% endblock %}
 {% block content %}<p>To improve I2P's usage and to be independent of routers 
 online status we want a datastorage as a extension to I2P.
diff --git a/www.i2p2/pages/bounty_debpack.html b/i2p2www/pages/site/volunteer/bounties/debpack.html
similarity index 92%
rename from www.i2p2/pages/bounty_debpack.html
rename to i2p2www/pages/site/volunteer/bounties/debpack.html
index 4d25029b..e096eb4b 100644
--- a/www.i2p2/pages/bounty_debpack.html
+++ b/i2p2www/pages/site/volunteer/bounties/debpack.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty I2P package in Debian and Ubuntu mirrors{% endblock %}
 {% block content %}<p>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 
@@ -19,4 +19,3 @@ for this work (e.g. GSoC students are not permitted to claim it).</p>
 you think these are important? <a href="donate">Make a donation</a>, 
 marking the amount for the I2P Ubuntu/Debian package bounty!</i></p>
 {% endblock %}
-                                             
diff --git a/www.i2p2/pages/bounty_i2phex.html b/i2p2www/pages/site/volunteer/bounties/i2phex.html
similarity index 93%
rename from www.i2p2/pages/bounty_i2phex.html
rename to i2p2www/pages/site/volunteer/bounties/i2phex.html
index 80198738..2b719294 100644
--- a/www.i2p2/pages/bounty_i2phex.html
+++ b/i2p2www/pages/site/volunteer/bounties/i2phex.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty I2PHex code implementation{% endblock %}
 {% block content %}<p>To improve I2P usage and attract more people
 into I2PHex P2P ArneBab setout the bounty for implementing actual
diff --git a/www.i2p2/pages/bounties.html b/i2p2www/pages/site/volunteer/bounties/index.html
similarity index 78%
rename from www.i2p2/pages/bounties.html
rename to i2p2www/pages/site/volunteer/bounties/index.html
index b3f2a605..0b73d9f8 100644
--- a/www.i2p2/pages/bounties.html
+++ b/i2p2www/pages/site/volunteer/bounties/index.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounties{% endblock %}
 {% block content %}
 <!-- file version 2012.04.16.01 -->
@@ -25,49 +25,49 @@ etc), and the like.</p>
 <table border="1">
  <tr><td><p><b>Name</b></p></td><td><p><b>Status</b></p></td><td><p><b>Judge</b></p></td><td><p><b>Dev <sup>*</sup></b></p></td><td><p><b>Bounty</b></p></td></tr>
  <tr>
-  <td><p><b><a href="bounty_datastore">Frost for I2P datastorage</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/datastore') }}">Frost for I2P datastorage</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>echelon</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€50 EUR</p></td>
  </tr>
  <tr>
-  <td><p><b><a href="bounty_datastore">Eepsites served out of I2P datastorage</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/datastore') }}">Eepsites served out of I2P datastorage</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>echelon</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€50 EUR</p></td>
  </tr>
  <tr>
-  <td><p><b><a href="bounty_i2phex">Backporting Phex code onto I2PHex</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/i2phex') }}">Backporting Phex code onto I2PHex</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>Arne Bab</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€100 EUR</p></td>
  </tr> 
  <tr>
-  <td><p><b><a href="bounty_ipv6">make I2P IPv6 native</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/ipv6') }}">make I2P IPv6 native</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>Amiga4000</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€100 EUR</p></td>
  </tr>
  <tr>
-  <td><p><b><a href="bounty_debpack">I2P package in Debian and Ubuntu mirrors</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/debpack') }}">I2P package in Debian and Ubuntu mirrors</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>h2ik</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€93 EUR</p></td>
  </tr>
  <tr>
-  <td><p><b><a href="bounty_btcclient">Bitcoin client for I2P</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/btcclient') }}">Bitcoin client for I2P</a></b></p></td>
   <td><p>Proposal in development</p></td>
   <td><p>psychonaut</p></td>
   <td><p>[vacant]</p></td>
   <td><p>€30 EUR and 114,24BTC</p></td>
  </tr>
  <tr>
-  <td><p><b><a href="bounty_unittests">Unit tests and Multi-router Simulation</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/unittests') }}">Unit tests and Multi-router Simulation</a></b></p></td>
   <td><p>Partly done, partly in work, partly still open</p></td>
   <td><p>anonymous</p></td>
   <td><p>str4d,hottuna</p></td>
@@ -93,22 +93,22 @@ etc), and the like.</p>
 <table border="1">
  <tr><td><p><b>Name</b></p></td><td><p><b>Status</b></p></td><td><p><b>Dev team<sup>*</sup></b></p></td></tr>
  <tr>
-  <td><p><b><a href="bounty_silc">Setting up a SILC server</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/silc') }}">Setting up a SILC server</a></b></p></td>
   <td><p>withdrawn and bounty divided between ReturningNovice and the general fund</p></td>
   <td><p>An Anonymous Secret Society, society@mail.i2p</p></td>
  </tr>
  <tr>
-   <td><p><b><a href="bounty_arabic">arabic translation</a></b></p></td>
+   <td><p><b><a href="{{ site_url('volunteer/bounties/arabic') }}">arabic translation</a></b></p></td>
    <td><p>both parts were taken by hamada for 100 BTC</p></td>
    <td><p>hamada</p></td>
  </tr> 
  <tr>
-  <td><p><b><a href="bounty_datastore">Datastore over I2P</a></b></p></td>
+  <td><p><b><a href="{{ site_url('volunteer/bounties/datastore') }}">Datastore over I2P</a></b></p></td>
   <td><p><a href="http://duck.i2p/tahoe-lafs/">CLAIMED</a> for 700 €</p></td>
   <td><p>duck, smeghead</p></td>
  </tr>
  <tr>
-  <td>  <p><b><a href="bounty_rutrans">translation into Russian</a></b></p></td>
+  <td>  <p><b><a href="{{ site_url('volunteer/bounties/rutrans') }}">translation into Russian</a></b></p></td>
   <td><p>claimed for $230 USD sponsored by russian sponsor</p></td>
   <td><p>4get</p></td>
  </tr>
diff --git a/www.i2p2/pages/bounty_ipv6.html b/i2p2www/pages/site/volunteer/bounties/ipv6.html
similarity index 96%
rename from www.i2p2/pages/bounty_ipv6.html
rename to i2p2www/pages/site/volunteer/bounties/ipv6.html
index 064a7e04..aef61737 100644
--- a/www.i2p2/pages/bounty_ipv6.html
+++ b/i2p2www/pages/site/volunteer/bounties/ipv6.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty I2P IPv6 native{% endblock %}
 {% block content %}<p>For a future of I2P and attract more people
 into I2P I withdrawal the vuze bounty and offer a IPv6 bounty.
diff --git a/www.i2p2/pages/bounty_rutrans.html b/i2p2www/pages/site/volunteer/bounties/rutrans.html
similarity index 97%
rename from www.i2p2/pages/bounty_rutrans.html
rename to i2p2www/pages/site/volunteer/bounties/rutrans.html
index 2be64c47..76851ee6 100644
--- a/www.i2p2/pages/bounty_rutrans.html
+++ b/i2p2www/pages/site/volunteer/bounties/rutrans.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty russian translation of webpage and router console{% endblock %}
 {% block content %}<p>To improve I2P usage and attract more people
 into I2P a anonymous donator set out the bounty for translation
diff --git a/www.i2p2/pages/bounty_silc.html b/i2p2www/pages/site/volunteer/bounties/silc.html
similarity index 96%
rename from www.i2p2/pages/bounty_silc.html
rename to i2p2www/pages/site/volunteer/bounties/silc.html
index 7989923c..4c197740 100644
--- a/www.i2p2/pages/bounty_silc.html
+++ b/i2p2www/pages/site/volunteer/bounties/silc.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty migrate I2P IRC to SILC {% endblock %}
 {% block content %}
 <!-- file version 2012.01.01.01 -->
diff --git a/www.i2p2/pages/bounty_unittests.html b/i2p2www/pages/site/volunteer/bounties/unittests.html
similarity index 98%
rename from www.i2p2/pages/bounty_unittests.html
rename to i2p2www/pages/site/volunteer/bounties/unittests.html
index d9c3a127..a63e74a3 100644
--- a/www.i2p2/pages/bounty_unittests.html
+++ b/i2p2www/pages/site/volunteer/bounties/unittests.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty unittests{% endblock %}
 {% block content %}
 <!-- file version 2012.04.16.01 -->
@@ -96,4 +96,4 @@ called succesfull done and money can be paid.
 <p><i>Note: 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 unit test bounty!</i></p>
-{% endblock %}
\ No newline at end of file
+{% endblock %}
diff --git a/www.i2p2/pages/bounty_vuzeplugin.html b/i2p2www/pages/site/volunteer/bounties/vuzeplugin.html
similarity index 96%
rename from www.i2p2/pages/bounty_vuzeplugin.html
rename to i2p2www/pages/site/volunteer/bounties/vuzeplugin.html
index 33380136..21d3c885 100644
--- a/www.i2p2/pages/bounty_vuzeplugin.html
+++ b/i2p2www/pages/site/volunteer/bounties/vuzeplugin.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Bounty I2P vuze plugin{% endblock %}
 {% block content %}<p>To improve I2P usage and attract more people
 into I2P torrent P2P I setout the bounty for a working I2P vuze

From 5a3090e952681ef51d1ae2635af0ea05c8c3006f Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Sat, 15 Sep 2012 03:36:42 +0000
Subject: [PATCH 52/75] Migrated over API, application dev and license-related
 pages

---
 i2p2www/pages/global/nav.html                              | 7 ++++---
 i2p2www/pages/site/develop/api.html                        | 5 +++++
 .../pages => i2p2www/pages/site/develop}/applications.html | 2 +-
 .../pages/site/develop}/license-agreements.html            | 4 ++--
 .../pages => i2p2www/pages/site/develop}/licenses.html     | 6 +++---
 www.i2p2/pages/api.html                                    | 5 -----
 6 files changed, 15 insertions(+), 14 deletions(-)
 create mode 100644 i2p2www/pages/site/develop/api.html
 rename {www.i2p2/pages => i2p2www/pages/site/develop}/applications.html (99%)
 rename {www.i2p2/pages => i2p2www/pages/site/develop}/license-agreements.html (99%)
 rename {www.i2p2/pages => i2p2www/pages/site/develop}/licenses.html (98%)
 delete mode 100644 www.i2p2/pages/api.html

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 34734abc..f7326cee 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -20,10 +20,11 @@
       <li><a href="http://forum.i2p2.de/"><span>Forums</span></a></li>
     </ul>
   </li>
-  <li class="has-sub"><a href="getinvolved.html"><span>Develop</span></a>
+  <li class="has-sub"><a href="#"><span>Develop</span></a>
     <ul>
-      <li><a href="api.html"><span>API</span></a></li>
-      <li><a href="licenses.html"><span>Licenses</span></a></li>
+      <li><a href="{{ site_url('develop/api') }}"><span>API</span></a></li>
+      <li><a href="{{ site_url('develop/applications') }}"><span>Applications</span></a></li>
+      <li><a href="{{ site_url('develop/licenses') }}"><span>Licenses</span></a></li>
       <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
diff --git a/i2p2www/pages/site/develop/api.html b/i2p2www/pages/site/develop/api.html
new file mode 100644
index 00000000..99f6efa0
--- /dev/null
+++ b/i2p2www/pages/site/develop/api.html
@@ -0,0 +1,5 @@
+{% extends "global/layout.html" %}
+{% block title %}API{% endblock %}
+{% block content %}
+See the <a href="{{ site_url('docs/how') }}">Index to Technical Documentation</a>.
+{% endblock %}
diff --git a/www.i2p2/pages/applications.html b/i2p2www/pages/site/develop/applications.html
similarity index 99%
rename from www.i2p2/pages/applications.html
rename to i2p2www/pages/site/develop/applications.html
index a1dcff58..3a73f819 100644
--- a/www.i2p2/pages/applications.html
+++ b/i2p2www/pages/site/develop/applications.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Application Development{% endblock %}
 {% block content %}
 <h1>Application Development Guide</h1>
diff --git a/www.i2p2/pages/license-agreements.html b/i2p2www/pages/site/develop/license-agreements.html
similarity index 99%
rename from www.i2p2/pages/license-agreements.html
rename to i2p2www/pages/site/develop/license-agreements.html
index 6ed222d8..e15c27b7 100644
--- a/www.i2p2/pages/license-agreements.html
+++ b/i2p2www/pages/site/develop/license-agreements.html
@@ -1,8 +1,8 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}License Agreements{% endblock %}
 {% block content %}
 
-<p>For more information see <a href="licenses.html">licenses.html</a>.
+<p>For more information see <a href="{{ site_url('develop/licenses') }}">licenses.html</a>.
 </p><p>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.
diff --git a/www.i2p2/pages/licenses.html b/i2p2www/pages/site/develop/licenses.html
similarity index 98%
rename from www.i2p2/pages/licenses.html
rename to i2p2www/pages/site/develop/licenses.html
index 327a21c4..fca1bbdf 100644
--- a/www.i2p2/pages/licenses.html
+++ b/i2p2www/pages/site/develop/licenses.html
@@ -1,10 +1,10 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Licenses{% endblock %}
 {% block content %}
 <h1>I2P Software Licenses</h1>
 <p>
 As required by our
-<a href="how_threatmodel.html">threat model</a> (among other reasons), the 
+<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a> (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
@@ -306,6 +306,6 @@ That means that they must send one of the release managers a signed message affi
 <p>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.
-<a href="license-agreements.html">See developers' license agreements</a>.
+<a href="{{ site_url('develop/license-agreements') }}">See developers' license agreements</a>.
 </p>
 {% endblock %}
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 <a href="how.html">Index to Technical Documentation</a>.
-{% endblock %}

From e9aa0ea90f60f43be6e39686b1a5c4e03ab14ef8 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Sat, 15 Sep 2012 03:40:49 +0000
Subject: [PATCH 53/75] Migrated some static urls in application dev page

---
 i2p2www/pages/site/develop/applications.html | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/i2p2www/pages/site/develop/applications.html b/i2p2www/pages/site/develop/applications.html
index 3a73f819..79898a40 100644
--- a/i2p2www/pages/site/develop/applications.html
+++ b/i2p2www/pages/site/develop/applications.html
@@ -50,16 +50,16 @@
     by using (best effort) datagrams without having to worry about MTU detection or 
     fragmentation of messages under 32KB.
 </p>
-   
+
         <div class="box" id="tunnel.serverclient" style="text-align:center">
-        <img src="_static/images/i2ptunnel_serverclient.png" alt="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." title="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." />
+        <img src="{{ url_for('static', filename='images/i2ptunnel_serverclient.png') }}" alt="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." title="Creating a server-client connection using I2PTunnel only requires creating a single tunnel." />
         <br /><br />
         Figure 1: Creating a server-client connection using I2PTunnel only requires creating a single tunnel.
         </div>
    <br/>
-  
+
         <div class="box" id="tunnel.peertopeer" style="text-align:center">
-        <img src="_static/images/i2ptunnel_peertopeer.png" alt="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." title="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." />
+        <img src="{{ url_for('static', filename='images/i2ptunnel_peertopeer.png') }}" alt="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." title="Setting up connections for a peer-to-peer applications requires a very large amount of tunnels." />
         <br /><br />
         Figure 2: Setting up connections for a peer-to-peer applications requires a very large amount of tunnels.
         </div>

From 2ab919e1cf8ede1fdc71f024fdda4b7d742d273f Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Sat, 15 Sep 2012 04:54:16 +0000
Subject: [PATCH 54/75] Added the 'i2pconv' template filter to convert I2P urls
 to clearnet as required

---
 i2p2www/__init__.py | 42 ++++++++++++++++++++++++++++++++----------
 1 file changed, 32 insertions(+), 10 deletions(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index f85648b8..d0655a0c 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -69,15 +69,6 @@ def detect_theme():
         return resp
 
 
-############################
-# Hooks - request processing
-
-@app.template_filter('restructuredtext')
-def restructuredtext(value):
-    parts = publish_parts(source=value, writer_name="html")
-    return parts['html_body']
-
-
 #######################
 # Hooks - after request
 
@@ -88,7 +79,38 @@ def call_after_request_callbacks(response):
     return response
 
 
-###############
+##################
+# Template filters
+
+@app.template_filter('restructuredtext')
+def restructuredtext(value):
+    parts = publish_parts(source=value, writer_name="html")
+    return parts['html_body']
+
+# Convert an I2P url to an equivalent clearnet one
+i2ptoclear = {
+    'www.i2p2.i2p': 'www.i2p2.de',
+    'forum.i2p': 'forum.i2p2.de',
+    'trac.i2p2.i2p': 'trac.i2p2.de',
+    }
+@app.template_filter('i2pconv')
+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 i2ptoclear[value]
+    except KeyError:
+        # The I2P site has no known clearnet address, so use an inproxy
+        return value + '.to'
+
+
+################
 # Error handlers
 
 @app.errorhandler(404)

From c4ce9b811ae2aa46bcd7fd52fb2ec550a0de2aed Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 00:25:00 +0000
Subject: [PATCH 55/75] Moved change_lang macro into the global macro file

---
 i2p2www/pages/global/lang.html   | 8 --------
 i2p2www/pages/global/layout.html | 2 +-
 i2p2www/pages/global/macros      | 8 ++++++++
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html
index 4c09d66e..91356aff 100644
--- a/i2p2www/pages/global/lang.html
+++ b/i2p2www/pages/global/lang.html
@@ -1,11 +1,3 @@
-{%- macro change_lang(lang) -%}
-{%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
-{%- elif request.endpoint == 'blog_entry' -%}{{ url_for('blog_entry', lang=lang, slug=slug) }}
-{%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }}
-{%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
-{%- else -%}{{ url_for('site_show', lang=lang) }}
-{%- endif -%}
-{%- endmacro -%}
 <ul class="languages">
   <li><a href="{{ change_lang('en') }}"><img src="{{ url_for('static', filename='images/us.png') }}" alt="English" /></a></li>
   <li><a href="{{ change_lang('es') }}"><img src="{{ url_for('static', filename='images/es.png') }}" alt="Castellano" /></a></li>
diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html
index 6fc7fb43..5ef6d7aa 100644
--- a/i2p2www/pages/global/layout.html
+++ b/i2p2www/pages/global/layout.html
@@ -1,4 +1,4 @@
-{%- from "global/macros" import site_url with context -%}
+{%- from "global/macros" import site_url, change_lang with context -%}
 <!DOCTYPE html>
 <html lang="en">
   <head>
diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros
index a99b1d17..92fabf41 100644
--- a/i2p2www/pages/global/macros
+++ b/i2p2www/pages/global/macros
@@ -3,3 +3,11 @@
 {%- else -%}{{ url_for('site_show', lang=g.lang) }}
 {%- endif -%}
 {%- endmacro -%}
+{%- macro change_lang(lang) -%}
+{%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }}
+{%- elif request.endpoint == 'blog_entry' -%}{{ url_for('blog_entry', lang=lang, slug=slug) }}
+{%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }}
+{%- elif request.endpoint -%}{{ url_for(request.endpoint, lang=lang) }}
+{%- else -%}{{ url_for('site_show', lang=lang) }}
+{%- endif -%}
+{%- endmacro -%}

From eaed7cecf974748587b2edb2930d918dbe60340c Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 00:26:39 +0000
Subject: [PATCH 56/75] Updated translation link for rutrans bounty page

---
 i2p2www/pages/site/volunteer/bounties/rutrans.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/i2p2www/pages/site/volunteer/bounties/rutrans.html b/i2p2www/pages/site/volunteer/bounties/rutrans.html
index 76851ee6..96b0d546 100644
--- a/i2p2www/pages/site/volunteer/bounties/rutrans.html
+++ b/i2p2www/pages/site/volunteer/bounties/rutrans.html
@@ -30,7 +30,7 @@ to be translated to collect the bounty of $115 USD.
 <p>
 Judge is the russian donor.
 </p>
-<a href="bounty_rutrans_ru">russian</a> short version of this page available.<br>
+<a href="{{ change_lang('ru') }}">russian</a> short version of this page available.<br>
 <br>
 <p>
 Note:

From 5c47ddde0bac2556a3a0f3fab883ed1d23b3daba Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 00:37:00 +0000
Subject: [PATCH 57/75] Migrated over donation and hall of fame pages

---
 i2p2www/pages/global/footer.html                 |  2 +-
 .../pages/site/volunteer}/donate.html            |  4 ++--
 .../pages/site/volunteer}/halloffame.html        | 16 ++++++++--------
 3 files changed, 11 insertions(+), 11 deletions(-)
 rename {www.i2p2/pages => i2p2www/pages/site/volunteer}/donate.html (97%)
 rename {www.i2p2/pages => i2p2www/pages/site/volunteer}/halloffame.html (97%)

diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html
index c646dcc9..602815c2 100644
--- a/i2p2www/pages/global/footer.html
+++ b/i2p2www/pages/global/footer.html
@@ -36,5 +36,5 @@
         </ul>
       </div>
       <div class='aside sixth'>
-        <a class='button' href='#donate'>Donate</a>
+        <a class='button' href="{{ site_url('volunteer/donate') }}">Donate</a>
       </div>
diff --git a/www.i2p2/pages/donate.html b/i2p2www/pages/site/volunteer/donate.html
similarity index 97%
rename from www.i2p2/pages/donate.html
rename to i2p2www/pages/site/volunteer/donate.html
index 5652ee67..34af00ca 100644
--- a/www.i2p2/pages/donate.html
+++ b/i2p2www/pages/site/volunteer/donate.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Donate{% endblock %}
 {% block content %}<p>Thank you for your interest in contributing to I2P!
 The details of how you
@@ -91,5 +91,5 @@ as the envelope can be lost on the way to us. </p>
 <p>If you'd like to donate via  snail mail, send an email to <a href="mailto:echelon@i2pmail.org?subject=information about snailmail donation">echelon@i2pmail.org</a>
  and you'll receive an email with instructions detailing how to proceed.</p>
 
-<p>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 <a href="halloffame.html">hall of fame</a>.</p>
+<p>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 <a href="{{ site_url('volunteer/halloffame') }}">hall of fame</a>.</p>
 {% endblock %}
diff --git a/www.i2p2/pages/halloffame.html b/i2p2www/pages/site/volunteer/halloffame.html
similarity index 97%
rename from www.i2p2/pages/halloffame.html
rename to i2p2www/pages/site/volunteer/halloffame.html
index fd21c8ca..4d02f05a 100644
--- a/www.i2p2/pages/halloffame.html
+++ b/i2p2www/pages/site/volunteer/halloffame.html
@@ -1,16 +1,16 @@
-{% extends "_layout.html" %}
-{% block title %}halloffame{% endblock %}
+{% extends "global/layout.html" %}
+{% block title %}Hall Of Fame{% endblock %}
 {% block content %}
 <!-- file version 2012.08.01.01 -->
 <h1>I2P'<small>s</small> Hall of Fame</h1>   
 <b>Current balance: as of 2012-08-01</b><br />
 <b>General fund: 3471,5 € and 1528,65311242 BTC</b><br />
-<b><a href="bounty_datastore">Datastorage bounty</a>: 115.0 € and 2 BTC</b><br />
-<b><a href="bounty_ipv6">native IPv6 I2P </a>: 100.0 €</b><br />
-<b><a href="bounty_i2phex">I2PHex bounty</a>: 60.0 €</b><br />
-<b><a href="bounty_debpack">I2P in debian mirrors</a>: 93.0 €</b><br />
-<b><a href="bounty_btcclient">Bitcoin client for I2P</a>: 30.0 € and 117.34 BTC</b><br />
-<b><a href="bounty_unittests">Unit Tests for I2P router</a>: 2700 €</b><br />
+<b><a href="{{ site_url('volunteer/bounties/datastore') }}">Datastorage bounty</a>: 115.0 € and 2 BTC</b><br />
+<b><a href="{{ site_url('volunteer/bounties/ipv6') }}">native IPv6 I2P </a>: 100.0 €</b><br />
+<b><a href="{{ site_url('volunteer/bounties/i2phex') }}">I2PHex bounty</a>: 60.0 €</b><br />
+<b><a href="{{ site_url('volunteer/bounties/debpack') }}">I2P in debian mirrors</a>: 93.0 €</b><br />
+<b><a href="{{ site_url('volunteer/bounties/btcclient') }}">Bitcoin client for I2P</a>: 30.0 € and 117.34 BTC</b><br />
+<b><a href="{{ site_url('volunteer/bounties/unittests') }}">Unit Tests for I2P router</a>: 2700 €</b><br />
 <br />
 <b>Current monthly running costs:</b><br />
 <table border="1">

From 62a7de51e7dd1c041b83233b98d3f3f38c6231d9 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 01:04:51 +0000
Subject: [PATCH 58/75] Finished migrating docs/how/intro

---
 i2p2www/pages/site/docs/how/intro.html | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
index 83946826..929a59b8 100644
--- a/i2p2www/pages/site/docs/how/intro.html
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -25,7 +25,7 @@ or even taken over to attempt more malicious attacks.</p>
 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 <a href="i2ptunnel">I2PTunnel</a> application, 
+or a distributed data store.  With the help of the <a href="{{ site_url('docs/applications/i2ptunnel') }}">I2PTunnel</a> 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 
@@ -63,7 +63,7 @@ the Kademlia algorithm) for distributing routing and contact information securel
 
 
 <p>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),
+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
@@ -122,10 +122,10 @@ The size of the network (N) bears no impact.</p>
 <a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="roadmap">roadmap</a>.</p>
+the <a href="{{ site_url('volunteer/roadmap') }}">roadmap</a>.</p>
 
 <h2>Who?</h2>
-<p>We have a small <a href="team">team</a> spread around several continents, working to advance different 
+<p>We have a small <a href="{{ site_url('team') }}">team</a> 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 
@@ -140,7 +140,7 @@ join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.po
 There are currently no scheduled development meetings, however
 <a href="{{ url_for('meetings_index', lang=g.lang) }}">archives are available</a>.</p>
 
-<p>The current source is available in <a href="monotone.html">monotone</a>.</p>
+<p>The current source is available in <a href="{{ site_url('develop/monotone') }}">monotone</a>.</p>
 
 <h2>Additional Information</h2>
 <p>

From 2ee45fcfe6c0354600e294d9e548b0b5dcbae76f Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 01:12:59 +0000
Subject: [PATCH 59/75] Migrated over monotone, roadmap and team pages

---
 .../pages => i2p2www/pages/site/develop}/monotone.html      | 6 +++---
 {www.i2p2/pages => i2p2www/pages/site}/team.html            | 6 +++---
 .../pages => i2p2www/pages/site/volunteer}/roadmap.html     | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)
 rename {www.i2p2/pages => i2p2www/pages/site/develop}/monotone.html (99%)
 rename {www.i2p2/pages => i2p2www/pages/site}/team.html (98%)
 rename {www.i2p2/pages => i2p2www/pages/site/volunteer}/roadmap.html (75%)

diff --git a/www.i2p2/pages/monotone.html b/i2p2www/pages/site/develop/monotone.html
similarity index 99%
rename from www.i2p2/pages/monotone.html
rename to i2p2www/pages/site/develop/monotone.html
index 10797055..3baf9083 100644
--- a/www.i2p2/pages/monotone.html
+++ b/i2p2www/pages/site/develop/monotone.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Monotone{% endblock %}
 {% block content %}
 <h1>Monotone Guide</h1>
@@ -55,7 +55,7 @@
 <p>
   <i>This is a revised version of <a href="transition-guide.txt">Complication's original
   guide</a> detailing the use of Monotone in I2P development.
-  For basic instructions see the <a href="newdevelopers.html">quick-start guide</a>.</i>
+  For basic instructions see the <a href="{{ site_url('develop/newdevelopers') }}">quick-start guide</a>.</i>
 </p>
 
 <p>
@@ -65,7 +65,7 @@
   development work can be shared and merged cooperatively, and work that's
   considered satisfactory is eventually merged into a single trusted repository
   that serves as the project's master. In practice however, since contributors
-  are often given commit privileges (after signing the <a href="licenses.html#commit">developer
+  are often given commit privileges (after signing the <a href="{{ site_url('develop/licenses') }}#commit">developer
   agreement]</a>), it's more common for completed work to be
   pushed directly to the master repository by its original authors.
 </p>
diff --git a/www.i2p2/pages/team.html b/i2p2www/pages/site/team.html
similarity index 98%
rename from www.i2p2/pages/team.html
rename to i2p2www/pages/site/team.html
index 442e8cba..bac6282f 100644
--- a/www.i2p2/pages/team.html
+++ b/i2p2www/pages/site/team.html
@@ -1,11 +1,11 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Team{% endblock %}
 {% block content %}
 <h1>I2P Project Members</h1>
 <p>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.
-<a href="getinvolved.html">Get involved!</a>
+<a href="{{ site_url('volunteer') }}">Get involved!</a>
 </p>
 
 <table border="0">
@@ -36,7 +36,7 @@ network.
 	<td valign="top"><i>manage the project mirrors</i></td>
 </tr>
 <tr>
-        <td valign="top"><b><a href="/monotone.html">Monotone</a> guru</b></td>
+        <td valign="top"><b><a href="{{ site_url('develop/monotone') }}">Monotone</a> guru</b></td>
         <td valign="top">welterde, eche|on</td>
         <td valign="top"><i>manage the public monotone repositories</i></td>
 </tr>
diff --git a/www.i2p2/pages/roadmap.html b/i2p2www/pages/site/volunteer/roadmap.html
similarity index 75%
rename from www.i2p2/pages/roadmap.html
rename to i2p2www/pages/site/volunteer/roadmap.html
index 1b4decfc..e79af448 100644
--- a/www.i2p2/pages/roadmap.html
+++ b/i2p2www/pages/site/volunteer/roadmap.html
@@ -1,11 +1,11 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
 {% block title %}Roadmap{% endblock %}
 {% block content %}
 
 <h2 id="v0.9">0.9</h2>
 <ul>
 <li>Include some seed data in the distribution so a central reseed location isn't required?</li>
-<li>Reachability Mapping / handle peers partially reachable / enhanced <a href="todo.html#fullRestrictedRoutes">restricted routes</a></li>
+<li>Reachability Mapping / handle peers partially reachable / enhanced <a href="{{ site_url('volunteer/todo') }}#fullRestrictedRoutes">restricted routes</a></li>
 <li>Improve help pages and website</li>
 <li>More translations</li>
 <li>SSU disconnect message</li>
@@ -30,5 +30,5 @@
 <li>User defined message delays</li>
 </ul>
 
-<p>Please see the <a href="todo">TODO</a> list for more detailed info about some of these tasks.</p>
+<p>Please see the <a href="{{ site_url('volunteer/todo') }}">TODO</a> list for more detailed info about some of these tasks.</p>
 {% endblock %}

From fcbf62afe6908501e7eff6658f7e18c6c12b4e6c Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 01:19:57 +0000
Subject: [PATCH 60/75] Added translation support using Flask-Babel

---
 i2p2www/__init__.py | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index d0655a0c..a3fd2a51 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -1,5 +1,6 @@
 from jinja2 import Environment, FileSystemLoader, environmentfilter
 from flask import Flask, request, session, g, redirect, url_for, abort, render_template, flash, send_from_directory, safe_join
+from flaskext.babel import Babel
 from docutils.core import publish_parts
 import os.path
 import os
@@ -15,6 +16,20 @@ MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings')
 
 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)
+
+
+#################
+# 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'])
 
 
 ##########################

From f20cf0a1b5c4821f465b0a6a0865ea0a9e5389fa Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 01:55:36 +0000
Subject: [PATCH 61/75] Added translation tags to docs/how/intro

---
 i2p2www/pages/site/docs/how/intro.html | 127 ++++++++++++++-----------
 1 file changed, 70 insertions(+), 57 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
index 929a59b8..f7beb111 100644
--- a/i2p2www/pages/site/docs/how/intro.html
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -1,150 +1,163 @@
 {% extends "global/layout.html" %}
-{% block title %}A Gentle Introduction{% endblock %}
+{% block title %}{% trans %}A Gentle Introduction{% endtrans %}{% endblock %}
 {% block content %}
 
-<h2>A Gentle Introduction to How I2P Works</h2>
+<h2>{% trans %}A Gentle Introduction to How I2P Works{% endtrans %}</h2>
 
-<p>I2P is a project to build, deploy, and maintain a network supporting secure and anonymous 
+<p>{% 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.</p>
+and freely available.{% endtrans %}</p>
 
-<p>Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the 
+<p>{% 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.</p>
+or even taken over to attempt more malicious attacks.{% endtrans %}</p>
 
-<p>The network itself is message oriented - it is essentially a secure and anonymous IP layer, 
+<p>{% trans i2ptunnel=site_url('docs/applications/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 <a href="{{ site_url('docs/applications/i2ptunnel') }}">I2PTunnel</a> application, 
+or a distributed data store.  With the help of the <a href="{{ i2ptunnel }}">I2PTunnel</a> 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.</p>
+app to turn on and off various proxies to enable the anonymizing functionality.{% endtrans %}</p>
 
-<p>An essential part of designing, developing, and testing an anonymizing network is to define the 
-<a href="{{ site_url('docs/how/threatmodel') }}">threat model</a>, since there is no such thing as "true" anonymity, just 
+<p>{% trans threatmodel=site_url('docs/how/threatmodel') %}
+An essential part of designing, developing, and testing an anonymizing network is to define the 
+<a href="{{ threatmodel }}">threat model</a>, 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,
 <i>all on the same network</i>, where each one's messages are essentially indistinguishable from the 
-others.</p>
+others.{% endtrans %}</p>
 
-<h2>Why?</h2>
-<p>There are a multitude of reasons why we need a system to support 
+<h2>{% trans %}Why?{% endtrans %}</h2>
+<p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') %}
+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 
-<a href="{{ site_url('docs/how/networkcomparisons') }}">other efforts</a> working on finding ways to provide varying degrees of 
+<a href="{{ networkcomparisons }}">other efforts</a> 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.</p>
+model.{% endtrans %}</p>
 
-<h2>How?</h2>
+<h2>{% trans %}How?{% endtrans %}</h2>
 
-<p>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 <a href="{{ site_url('docs/how/tunnelrouting') }}">tunnel routing</a> page). 
+<p>{% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') %}
+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 <a href="{{ tunnelrouting }}">tunnel routing</a> 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 <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a> (using a modification of 
-the Kademlia algorithm) for distributing routing and contact information securely.</p>
+network.  I2P has its own internal <a href="{{ netdb }}">network database</a> (using a modification of 
+the Kademlia algorithm) for distributing routing and contact information securely.{% endtrans %}</p>
 
-<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="Network topology example" title="Network topology example" /></div>
+<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="{% trans %}Network topology example{% endtrans %}" title="{% trans %}Network topology example{% endtrans %}" /></div>
 
-
-<p>In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their 
+<p>{% 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.</p>
+network database, which is constantly updated as new leases are authorized and old ones expire.{% endtrans %}</p>
   
-<p>If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his
+<p>{% trans garlicrouting=site_url('docs/how/garlicrouting') %}
+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 <a href="{{ site_url('docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the 
+messages sent between Alice and Bob are <a href="{{ garlicrouting }}">garlic</a> 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.</p>
+in the network database for the current data.{% endtrans %}</p>
 
-<p>To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and 
+<p>{% trans peerselection=site_url('docs/how/peerselection') %}
+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 <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> page.</p>
+needs of the users, as described in the <a href="{{ peerselection }}">peer selection</a> page.{% endtrans %}</p>
 
-<p>The network itself makes use of a significant number of <a href="{{ site_url('docs/how/cryptography') }}">cryptographic techniques and algorithms</a> - 
+<p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') %}
+The network itself makes use of a significant number of <a href="{{ cryptography }}">cryptographic techniques and algorithms</a> - 
 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 <a href="{{ site_url('docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
+station authentication, and <a href="{{ elgamalaes }}">ElGamal / AES+SessionTag</a>.{% endtrans %}</p>
 
-<p>Content sent over I2P is encrypted through three layers garlic encryption (used to verify the delivery of the message to 
+<p>{% 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):</p>
-<p>End-to-end (I2CP) encryption (client application to server application) was disabled in I2P release 0.6; 
+uses AES256 with ephemeral keys).{% endtrans %}</p>
+
+<p>{% 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.</p>
+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 %}</p>
 
-<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="End to end layered encryption" title="End to end layered encryption." /></div>
+<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="{% trans %}End to end layered encryption{% endtrans %}" title="{% trans %}End to end layered encryption{% endtrans %}" /></div>
 
-<p>The specific use of these algorithms are outlined <a href="{{ site_url('docs/how/cryptography') }}">elsewhere</a>.</p>
+<p>{% trans crypto=site_url('docs/how/cryptography') %}
+The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.{% endtrans %}</p>
 
-<p>The two main mechanisms for allowing people who need strong anonymity to use the network are 
+<p>{% 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.</p>
+flexible and anonymous transports.{% endtrans %}</p>
 
-<p>Some questions have been raised with regards to the scalability of I2P, and reasonably so. There 
+<p>{% trans netdb=site_url('docs/how/networkdatabase') %}
+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 
-<code>O(log(N))</code> due to the <a href="{{ site_url('docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end 
+<code>O(log(N))</code> due to the <a href="{{ netdb }}">network database</a>'s algorithm, while end to end 
 messages should be <code>O(1)</code> (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.</p>
+The size of the network (N) bears no impact.{% endtrans %}</p>
 
-<h2>When?</h2>
-<p>I2P initially began in Feb 2003 as a proposed modification to 
+<h2>{% trans %}When?{% endtrans %}</h2>
+<p>{% trans roadmap=site_url('volunteer/roadmap') %}
+I2P initially began in Feb 2003 as a proposed modification to 
 <a href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as 
 <a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="{{ site_url('volunteer/roadmap') }}">roadmap</a>.</p>
+the <a href="{{ roadmap }}">roadmap</a>.{% endtrans %}</p>
 
-<h2>Who?</h2>
-<p>We have a small <a href="{{ site_url('team') }}">team</a> spread around several continents, working to advance different 
+<h2>{% trans %}Who?{% endtrans %}</h2>
+<p>{% trans team=site_url('team') %}
+We have a small <a href="{{ team }}">team</a> 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 <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
-</p>
+{% endtrans %}</p>
 
-<h2>Where?</h2>
-<p>Anyone interested should
+<h2>{% trans %}Where?{% endtrans %}</h2>
+<p>{% trans meetings=url_for('meetings_index', lang=g.lang) %}
+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
-<a href="{{ url_for('meetings_index', lang=g.lang) }}">archives are available</a>.</p>
+<a href="{{ meetings }}">archives are available</a>.{% endtrans %}</p>
 
-<p>The current source is available in <a href="{{ site_url('develop/monotone') }}">monotone</a>.</p>
+<p>{% trans monotone=site_url('develop/monotone') %}
+The current source is available in <a href="{{ monotone }}">monotone</a>.{% endtrans %}</p>
 
-<h2>Additional Information</h2>
-<p>
-See <a href="{{ site_url('docs/how') }}">the Index to Technical Documentation</a>
-</p>
+<h2>{% trans %}Additional Information{% endtrans %}</h2>
+<p>{% trans how_index=site_url('docs/how') %}
+See <a href="{{ how_index}}">the Index to Technical Documentation</a>
+{% endtrans %}</p>
 
 {% endblock %}

From f35c2fae60982ad46e0e77362e488d3fe46ddf88 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 02:24:02 +0000
Subject: [PATCH 62/75] Removed some whitespace from translation tags

---
 i2p2www/pages/site/docs/how/intro.html | 31 +++++++++++++-------------
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
index f7beb111..eec7250f 100644
--- a/i2p2www/pages/site/docs/how/intro.html
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -21,7 +21,7 @@ web (allowing anonymous web browsing). Having the ability to run servers within
 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 %}</p>
 
-<p>{% trans i2ptunnel=site_url('docs/applications/i2ptunnel') %}
+<p>{% trans i2ptunnel=site_url('docs/applications/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
@@ -32,7 +32,7 @@ even streaming audio. Most people will not use I2P directly, or even need to kno
 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 %}</p>
 
-<p>{% trans threatmodel=site_url('docs/how/threatmodel') %}
+<p>{% trans threatmodel=site_url('docs/how/threatmodel') -%}
 An essential part of designing, developing, and testing an anonymizing network is to define the 
 <a href="{{ threatmodel }}">threat model</a>, 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 
@@ -43,7 +43,7 @@ detection by a very powerful adversary, while others will try to evade a weaker
 others.{% endtrans %}</p>
 
 <h2>{% trans %}Why?{% endtrans %}</h2>
-<p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') %}
+<p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') -%}
 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 
 <a href="{{ networkcomparisons }}">other efforts</a> working on finding ways to provide varying degrees of 
@@ -52,7 +52,7 @@ model.{% endtrans %}</p>
 
 <h2>{% trans %}How?{% endtrans %}</h2>
 
-<p>{% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') %}
+<p>{% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') -%}
 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 <a href="{{ tunnelrouting }}">tunnel routing</a> page). 
 Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers 
@@ -74,21 +74,21 @@ talk to each other, Alice sends a message out one of her (pink) outbound tunnels
 (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 %}</p>
   
-<p>{% trans garlicrouting=site_url('docs/how/garlicrouting') %}
+<p>{% trans garlicrouting=site_url('docs/how/garlicrouting') -%}
 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 <a href="{{ garlicrouting }}">garlic</a> 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 %}</p>
 
-<p>{% trans peerselection=site_url('docs/how/peerselection') %}
+<p>{% trans peerselection=site_url('docs/how/peerselection') -%}
 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 <a href="{{ peerselection }}">peer selection</a> page.{% endtrans %}</p>
 
-<p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') %}
+<p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') -%}
 The network itself makes use of a significant number of <a href="{{ cryptography }}">cryptographic techniques and algorithms</a> - 
 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 
@@ -107,7 +107,7 @@ A and h are the routers of Alice and Bob, while Alice and Bob in following chart
 
 <div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="{% trans %}End to end layered encryption{% endtrans %}" title="{% trans %}End to end layered encryption{% endtrans %}" /></div>
 
-<p>{% trans crypto=site_url('docs/how/cryptography') %}
+<p>{% trans crypto=site_url('docs/how/cryptography') -%}
 The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.{% endtrans %}</p>
 
 <p>{% trans %}The two main mechanisms for allowing people who need strong anonymity to use the network are 
@@ -117,7 +117,7 @@ delays and FIFO tunnels are currently in place. Additionally, the 2.0 release wi
 up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more 
 flexible and anonymous transports.{% endtrans %}</p>
 
-<p>{% trans netdb=site_url('docs/how/networkdatabase') %}
+<p>{% trans netdb=site_url('docs/how/networkdatabase') -%}
 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 
 <code>O(log(N))</code> due to the <a href="{{ netdb }}">network database</a>'s algorithm, while end to end 
@@ -126,7 +126,7 @@ 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 %}</p>
 
 <h2>{% trans %}When?{% endtrans %}</h2>
-<p>{% trans roadmap=site_url('volunteer/roadmap') %}
+<p>{% trans roadmap=site_url('volunteer/roadmap') -%}
 I2P initially began in Feb 2003 as a proposed modification to 
 <a href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as 
 <a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, then grew into its own as an 
@@ -135,7 +135,7 @@ I2P is currently under development, following
 the <a href="{{ roadmap }}">roadmap</a>.{% endtrans %}</p>
 
 <h2>{% trans %}Who?{% endtrans %}</h2>
-<p>{% trans team=site_url('team') %}
+<p>{% trans team=site_url('team') -%}
 We have a small <a href="{{ team }}">team</a> 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 
@@ -146,18 +146,17 @@ are being written in Python and other languages. The code works on <a href="http
 {% endtrans %}</p>
 
 <h2>{% trans %}Where?{% endtrans %}</h2>
-<p>{% trans meetings=url_for('meetings_index', lang=g.lang) %}
+<p>{% trans meetings=url_for('meetings_index', lang=g.lang) -%}
 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
 <a href="{{ meetings }}">archives are available</a>.{% endtrans %}</p>
 
-<p>{% trans monotone=site_url('develop/monotone') %}
+<p>{% trans monotone=site_url('develop/monotone') -%}
 The current source is available in <a href="{{ monotone }}">monotone</a>.{% endtrans %}</p>
 
 <h2>{% trans %}Additional Information{% endtrans %}</h2>
-<p>{% trans how_index=site_url('docs/how') %}
-See <a href="{{ how_index}}">the Index to Technical Documentation</a>
-{% endtrans %}</p>
+<p>{% trans how_index=site_url('docs/how') -%}
+See <a href="{{ how_index}}">the Index to Technical Documentation</a>.{% endtrans %}</p>
 
 {% endblock %}

From 82ef323039a97f50b9d12ff3f73e0d59a392ec1b Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 06:34:02 +0000
Subject: [PATCH 63/75] Reformatted docs/how/intro text (more uniform, culled
 extra whitespace)

---
 i2p2www/pages/site/docs/how/intro.html | 251 ++++++++++++++-----------
 1 file changed, 140 insertions(+), 111 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html
index eec7250f..200a2281 100644
--- a/i2p2www/pages/site/docs/how/intro.html
+++ b/i2p2www/pages/site/docs/how/intro.html
@@ -4,159 +4,188 @@
 
 <h2>{% trans %}A Gentle Introduction to How I2P Works{% endtrans %}</h2>
 
-<p>{% 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 %}</p>
+<p>{% 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 %}</p>
 
-<p>{% 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 %}</p>
+<p>{% 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 %}</p>
 
 <p>{% trans i2ptunnel=site_url('docs/applications/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 <a href="{{ i2ptunnel }}">I2PTunnel</a> 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 %}</p>
+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 <a href="{{ i2ptunnel }}">I2PTunnel</a> 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 %}</p>
 
 <p>{% trans threatmodel=site_url('docs/how/threatmodel') -%}
-An essential part of designing, developing, and testing an anonymizing network is to define the 
-<a href="{{ threatmodel }}">threat model</a>, 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,
-<i>all on the same network</i>, where each one's messages are essentially indistinguishable from the 
-others.{% endtrans %}</p>
+An essential part of designing, developing, and testing an anonymizing network is to define the <a
+href="{{ threatmodel }}">threat model</a>, 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, <i>all on the same network</i>, where each one's messages are essentially indistinguishable
+from the others.
+{%- endtrans %}</p>
 
 <h2>{% trans %}Why?{% endtrans %}</h2>
 <p>{% trans networkcomparisons=site_url('docs/how/networkcomparisons') -%}
-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 
-<a href="{{ networkcomparisons }}">other efforts</a> 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 %}</p>
+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 <a href="{{ networkcomparisons }}">other
+efforts</a> 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 %}</p>
 
 <h2>{% trans %}How?{% endtrans %}</h2>
 
 <p>{% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') -%}
-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 <a href="{{ tunnelrouting }}">tunnel routing</a> 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 <a href="{{ netdb }}">network database</a> (using a modification of 
-the Kademlia algorithm) for distributing routing and contact information securely.{% endtrans %}</p>
+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 <a href="{{ tunnelrouting
+}}">tunnel routing</a> 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
+<a href="{{ netdb }}">network database</a> (using a modification of the Kademlia algorithm) for
+distributing routing and contact information securely.
+{%- endtrans %}</p>
 
 <div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="{% trans %}Network topology example{% endtrans %}" title="{% trans %}Network topology example{% endtrans %}" /></div>
 
-<p>{% 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 %}</p>
-  
+<p>{% 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 %}</p>
+
 <p>{% trans garlicrouting=site_url('docs/how/garlicrouting') -%}
-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 <a href="{{ garlicrouting }}">garlic</a> 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 %}</p>
+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 <a href="{{ garlicrouting }}">garlic</a>
+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 %}</p>
 
 <p>{% trans peerselection=site_url('docs/how/peerselection') -%}
-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 <a href="{{ peerselection }}">peer selection</a> page.{% endtrans %}</p>
+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 <a href="{{ peerselection }}">peer selection</a>
+page.
+{%- endtrans %}</p>
 
 <p>{% trans crypto=site_url('docs/how/cryptography'), elgamalaes=site_url('docs/how/elgamalaes') -%}
-The network itself makes use of a significant number of <a href="{{ cryptography }}">cryptographic techniques and algorithms</a> - 
-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 <a href="{{ elgamalaes }}">ElGamal / AES+SessionTag</a>.{% endtrans %}</p>
+The network itself makes use of a significant number of <a href="{{ cryptography }}">cryptographic
+techniques and algorithms</a> - 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 <a href="{{ elgamalaes
+}}">ElGamal / AES+SessionTag</a>.
+{%- endtrans %}</p>
 
-<p>{% 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 %}</p>
+<p>{% 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 %}</p>
 
-<p>{% 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 %}</p>
+<p>{% 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 %}</p>
 
 <div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="{% trans %}End to end layered encryption{% endtrans %}" title="{% trans %}End to end layered encryption{% endtrans %}" /></div>
 
 <p>{% trans crypto=site_url('docs/how/cryptography') -%}
-The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.{% endtrans %}</p>
+The specific use of these algorithms are outlined <a href="{{ cryptography }}">elsewhere</a>.
+{%- endtrans %}</p>
 
-<p>{% 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 %}</p>
+<p>{% 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 %}</p>
 
 <p>{% trans netdb=site_url('docs/how/networkdatabase') -%}
-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 
-<code>O(log(N))</code> due to the <a href="{{ netdb }}">network database</a>'s algorithm, while end to end 
-messages should be <code>O(1)</code> (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 %}</p>
+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
+<code>O(log(N))</code> due to the <a href="{{ netdb }}">network database</a>'s algorithm, while end
+to end messages should be <code>O(1)</code> (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 %}</p>
 
 <h2>{% trans %}When?{% endtrans %}</h2>
 <p>{% trans roadmap=site_url('volunteer/roadmap') -%}
-I2P initially began in Feb 2003 as a proposed modification to 
-<a href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as 
-<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="{{ roadmap }}">roadmap</a>.{% endtrans %}</p>
+I2P initially began in Feb 2003 as a proposed modification to <a
+href="http://freenetproject.org">Freenet</a> to allow it to use alternate transports, such as <a
+href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="{{ roadmap
+}}">roadmap</a>.
+{%- endtrans %}</p>
 
 <h2>{% trans %}Who?{% endtrans %}</h2>
 <p>{% trans team=site_url('team') -%}
-We have a small <a href="{{ team }}">team</a> 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 <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
-{% endtrans %}</p>
+We have a small <a href="{{ team }}">team</a> 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 <a href="http://java.com/en/">Sun Java SE</a> and other Java Virtual Machines.
+{%- endtrans %}</p>
 
 <h2>{% trans %}Where?{% endtrans %}</h2>
 <p>{% trans meetings=url_for('meetings_index', lang=g.lang) -%}
-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
-<a href="{{ meetings }}">archives are available</a>.{% endtrans %}</p>
+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 <a href="{{ meetings }}">archives are available</a>.
+{%- endtrans %}</p>
 
 <p>{% trans monotone=site_url('develop/monotone') -%}
-The current source is available in <a href="{{ monotone }}">monotone</a>.{% endtrans %}</p>
+The current source is available in <a href="{{ monotone }}">monotone</a>.
+{%- endtrans %}</p>
 
 <h2>{% trans %}Additional Information{% endtrans %}</h2>
 <p>{% trans how_index=site_url('docs/how') -%}
-See <a href="{{ how_index}}">the Index to Technical Documentation</a>.{% endtrans %}</p>
+See <a href="{{ how_index}}">the Index to Technical Documentation</a>.
+{%- endtrans %}</p>
 
 {% endblock %}

From e9a5b01ab7f47efce8c9d7568d5f978dc191080a Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 11:03:25 +0000
Subject: [PATCH 64/75] Migrated over es translation of docs/how/intro

---
 i2p2www/babel.cfg                             |   3 +
 .../translations/es/LC_MESSAGES/messages.po   | 596 ++++++++++++++++++
 www.i2p2/pages/how_intro_es.html              | 177 ------
 3 files changed, 599 insertions(+), 177 deletions(-)
 create mode 100644 i2p2www/babel.cfg
 create mode 100644 i2p2www/translations/es/LC_MESSAGES/messages.po
 delete mode 100644 www.i2p2/pages/how_intro_es.html

diff --git a/i2p2www/babel.cfg b/i2p2www/babel.cfg
new file mode 100644
index 00000000..0f7e2157
--- /dev/null
+++ b/i2p2www/babel.cfg
@@ -0,0 +1,3 @@
+[python: **.py]
+[jinja2: **/pages/**.html]
+extensions=jinja2.ext.autoescape,jinja2.ext.with_
diff --git a/i2p2www/translations/es/LC_MESSAGES/messages.po b/i2p2www/translations/es/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..b3805bf5
--- /dev/null
+++ b/i2p2www/translations/es/LC_MESSAGES/messages.po
@@ -0,0 +1,596 @@
+# Spanish translations for I2P website.
+# Copyright (C) 2011 I2P
+# This file is distributed under the same license as the I2P website project.
+# m1xxy <m1xxy@mail.i2p>, 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-04-18 19:54+0000\n"
+"Last-Translator: Ulises\n"
+"Language-Team: es <LL@li.org>\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"
+"Language: es\n"
+
+#: pages/site/docs/how/intro.html:2
+msgid "A Gentle Introduction"
+msgstr "Una Introducción Sencilla"
+
+#: 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"
+
+#: 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."
+
+#: 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."
+
+#: 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 <a href=\"%(i2ptunnel)s\">I2PTunnel</a> 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 <a href=\"%(i2ptunnel)s\">\n"
+"I2PTunnel</a>, 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."
+
+#: 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 <a\n"
+"href=\"%(threatmodel)s\">threat model</a>, 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, <i>all on the same network</i>, 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 <a\n"
+"href=\"%(threatmodel)s\">modelo de amenaza</a>, 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, <i>todo en la "
+"misma red</i>, donde\n"
+"los mensajes de cada uno son ensencialmente indistinguibles de los del resto."
+
+#: pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr "¿Por qué?"
+
+#: 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 <a href="
+"\"%(networkcomparisons)s\">other\n"
+"efforts</a> 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 ""
+"Puede haber multitud de razones por las que necesitemos un sistema que "
+"soporte comunicación\n"
+"anónima, y cada cual tendrá su razonamiento personal. Hay muchos <a href="
+"\"%(networkcomparisons)s\">\n"
+"otros proyectos</a> trabajando en encontrar formas de suministrar a la gente "
+"diferentes grados\n"
+"de anonimato a través de Internet, pero no podríamos encontrar ninguno que "
+"se ajuste a nuestras\n"
+"necesidades o al modelo de amenaza."
+
+#: pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr "¿Cómo?"
+
+#: 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 <a href="
+"\"%(tunnelrouting)s\">tunnel routing</a> 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"
+"<a href=\"%(netdb)s\">network database</a> (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 <a href=\"%(tunnelrouting)s\">tunnel routing</a>). 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 <a href=\"%(netdb)s"
+"\">base de datos de\n"
+"red</a> (utilizando una modificación del algoritmo Kadeemlia) para "
+"distribuir información de\n"
+"rutas y contactos de forma segura."
+
+#: pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr ""
+
+#: 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."
+
+#: 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 <a href="
+"\"%(garlicrouting)s\">garlic</a>\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 <a href=\"%(garlicrouting)s\">garlic</a>, "
+"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."
+
+#: 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 <a href="
+"\"%(peerselection)s\">peer selection</a>\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 <a href=\"%(peerselection)s\">selección de pares</a>."
+
+#: pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of <a href="
+"\"%(cryptography)s\">cryptographic\n"
+"techniques and algorithms</a> - 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 <a href="
+"\"%(elgamalaes)s\">ElGamal / AES+SessionTag</a>."
+msgstr ""
+"La red hace uso de un significante número de <a href=\"%(cryptography)s"
+"\">técnicas criptográficas\n"
+"y algoritmos</a> - 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 <a href=\"%(elgamalaes)s\">\n"
+"ElGamal / AES+SessionTag</a>."
+
+#: 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)."
+
+#: 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."
+
+#: pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr ""
+
+#: pages/site/docs/how/intro.html:131
+#, python-format
+msgid ""
+"The specific use of these algorithms are outlined <a href=\"%(cryptography)s"
+"\">elsewhere</a>."
+msgstr ""
+"El uso específico de estos algoritmos está descrito en <a href="
+"\"%(cryptography)s\">otra parte</a>."
+
+#: 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."
+
+#: 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"
+"<code>O(log(N))</code> due to the <a href=\"%(netdb)s\">network database</"
+"a>'s algorithm, while end\n"
+"to end messages should be <code>O(1)</code> (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"
+"<code>O(log(N))</code> debido al algoritmo de <a href=\"%(netdb)s\">base de "
+"datos de\n"
+"red</a>, mientras que los mensajes punto a punto serían <code>O(1)</code> "
+"(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."
+
+#: pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr "¿Cuándo?"
+
+#: pages/site/docs/how/intro.html:154
+#, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to <a\n"
+"href=\"http://freenetproject.org\">Freenet</a> to allow it to use alternate "
+"transports, such as <a\n"
+"href=\"http://java.sun.com/products/jms/index.jsp\">JMS</a>, 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 <a "
+"href=\"%(roadmap)s\">roadmap</a>."
+msgstr ""
+"I2P comenzó inicialmente en 2003 como una propuesta de modificar\n"
+"<a href=\"http://freenetproject.org\">Freenet</a> para permitir el uso de "
+"transportes alternativos,\n"
+"como puede ser <a href=\"http://java.sun.com/products/jms/index.jsp\">JMS</"
+"a>, 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 <a href=\"%(roadmap)s"
+"\">hoja de ruta</a>."
+
+#: pages/site/docs/how/intro.html:163
+msgid "Who?"
+msgstr "¿Quiénes?"
+
+#: pages/site/docs/how/intro.html:164
+#, python-format
+msgid ""
+"We have a small <a href=\"%(team)s\">team</a> 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 <a href=\"http://java.com/en/\">Sun Java SE</a> and other Java Virtual "
+"Machines."
+msgstr ""
+"Tenemos un pequeño <a href=\"%(team)s\">equipo</a> 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 <a href=\"http://java.com/en/"
+"\">Sun Java SE</a>\n"
+"y otras máquinas virtuales Java."
+
+#: pages/site/docs/how/intro.html:175
+msgid "Where?"
+msgstr "¿Dónde?"
+
+#: 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 <a href=\"%(meetings)s\">archives "
+"are available</a>."
+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 <a href="
+"\"%(meetings)s\">archivos\n"
+"disponibles</a>."
+
+#: pages/site/docs/how/intro.html:182
+#, python-format
+msgid ""
+"The current source is available in <a href=\"%(monotone)s\">monotone</a>."
+msgstr ""
+"El código actual está disponible en <a href=\"%(monotone)s\">monotone</a>."
+
+#: pages/site/docs/how/intro.html:186
+msgid "Additional Information"
+msgstr "Información adicional"
+
+#: pages/site/docs/how/intro.html:187
+#, python-format
+msgid "See <a href=\"%(how_index)s\">the Index to Technical Documentation</a>."
+msgstr ""
+"Ver <a href=\"%(how_index)s\">el Indice de la Documentación Técnica</a>."
+
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 %}
-
-<h2>Una breve presentación de cómo funciona I2P</h2>
-
-<p>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.
-</p>
-
-<p>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.</p>
-
-<p>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 <a href="i2ptunnel">I2PTunnel</a>,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.</p>
-
-<p>Una parte esencial de diseñar, desarrollar y probar una red anónima es definir el 
-<a href="how_threatmodel">modelo de amenaza</a>, 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,
-<i>todo en la misma red</i>, donde los
-mensajes de cada uno son ensencialmente indistinguibles de los del resto.</p>
-
-<h2>¿Por qué?</h2>
-<p> 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 
-<a href="how_networkcomparisons">otros proyectos</a> 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.</p>
-
-<h2>¿Cómo?</h2>
-
-<p>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 <a href="how_tunnelrouting">tunnel routing</a>). 
-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 <a href="how_networkdatabase">base de datos de red</a> (utilizando una modificación del algoritmo Kademlia) para distribuir
-información de rutas y contactos de forma segura.</p>
-
-<div class="box" style="text-align:center;"><img src="_static/images/net.png" alt="Network topology example" title="Network topology example" /></div>
-
-
-<p>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.</p>
-  
-<p>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 <a href="how_garlicrouting">garlic</a>, 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.</p>
-
-<p>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  <a href="how_peerselection">selección de pares</a></p>
-
-<p>La red hace uso de un significante número de <a href="how_cryptography">técnicas criptográficas y algoritmos</a> - 
-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 <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
-
-<p>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).</p>
-
-<p>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.</p>
-
-<div class="box" style="text-align:center;"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div>
-
-<p>El uso específico de estos algoritmos está descrito en <a href="how_cryptography">otra parte</a>.</p>
-
-<p>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.</p>
-
-<p>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
-<code>O(log(N))</code> debido al algoritmo de <a href="how_networkdatabase">base de datos de red</a>, mientras que los mensajes punto a punto serían <code>O(1)</code> (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.</p>
-
-<h2>¿Cuándo?</h2>
-<p>I2P comenzó inicialmente en 2003 como una propuesta de modificar
-<a href="http://freenetproject.org">Freenet</a> para permitir el uso de transportes alternativos, como puede ser 
-<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="roadmap">hoja de ruta</a>.</p>
-
-<h2>¿Quiénes?</h2>
-<p>Tenemos un pequeño <a href="team">equipo</a> 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 <a href="http://java.com/en/">Sun Java SE</a> y otras máquinas virtuales Java.
-</p>
-
-<h2>¿Dónde?</h2>
-<p>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
-<a href="meetings">archivos disponibles</a>.</p>
-
-<p>El código actual está disponible en <a href="monotone.html">monotone</a>.</p>
-
-<h2>Información adicional</h2>
-<p>
-Ver <a href="how.html">el Índice de la Documentación Técnica</a>
-</p>
-
-{% endblock %}

From c2a739e9fd73386c4762446c73d28ac6963e359f Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 13:29:31 +0000
Subject: [PATCH 65/75] Added /favicon.ico path for legacy browsers

---
 i2p2www/__init__.py | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index a3fd2a51..e3a55619 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -364,7 +364,10 @@ def legacy_show(f):
     else:
         return redirect(url_for('site_show', lang=lang, page=f))
 
-
+@app.route('/favicon.ico')
+def favicon():
+    return send_from_directory(os.path.join(app.root_path, 'static'),
+                               'favicon.ico', mimetype='image/vnd.microsoft.icon')
 
 if __name__ == '__main__':
     app.run(debug=True)

From 6eda93580eb35c6862ae1ad5654a4586e5253a00 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 14:34:13 +0000
Subject: [PATCH 66/75] Migrated over de and fr translations of docs/how/intro

---
 .../translations/de/LC_MESSAGES/messages.po   | 597 ++++++++++++++++++
 .../translations/fr/LC_MESSAGES/messages.po   | 573 +++++++++++++++++
 www.i2p2/pages/how_intro_de.html              | 163 -----
 www.i2p2/pages/how_intro_fr.html              | 160 -----
 4 files changed, 1170 insertions(+), 323 deletions(-)
 create mode 100644 i2p2www/translations/de/LC_MESSAGES/messages.po
 create mode 100644 i2p2www/translations/fr/LC_MESSAGES/messages.po
 delete mode 100644 www.i2p2/pages/how_intro_de.html
 delete mode 100644 www.i2p2/pages/how_intro_fr.html

diff --git a/i2p2www/translations/de/LC_MESSAGES/messages.po b/i2p2www/translations/de/LC_MESSAGES/messages.po
new file mode 100644
index 00000000..70cf4553
--- /dev/null
+++ b/i2p2www/translations/de/LC_MESSAGES/messages.po
@@ -0,0 +1,597 @@
+# German translations for I2P website.
+# Copyright (C) 2008 I2P
+# This file is distributed under the same license as the I2P website
+# project.
+# amiga4000 <amiga4000@mail.i2p>, 2008.
+#
+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: 2010-10-11 18:18+0000\n"
+"Last-Translator: echelon <echelon@mail.i2p>\n"
+"Language-Team: de <LL@li.org>\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 ""
+
+#: pages/site/docs/how/intro.html:5
+msgid "A Gentle Introduction to How I2P Works"
+msgstr "Einführung in die Arbeitsweise von 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 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."
+
+#: 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."
+
+#: 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 <a href=\"%(i2ptunnel)s\">I2PTunnel</a> 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"
+"<a href=\"http://bitconjurer.org/BitTorrent/\">BitTorrent</a> Klient "
+"(\"I2Psnark\") oder ein verteilter\n"
+"Datencontainer. Mit der Hilfe von mihis <a href=\"%(i2ptunnel)s\">I2PTunnel</"
+"a>\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."
+
+#: 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 <a\n"
+"href=\"%(threatmodel)s\">threat model</a>, 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, <i>all on the same network</i>, 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 <a href=\"%(threatmodel)s\">Angriffsszenarios</a>, 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"
+"<i>alles in dem selben Netzwerk</i>, in dem eine Nachricht nicht von einer "
+"anderen unterschieden werden\n"
+"kann."
+
+#: pages/site/docs/how/intro.html:51
+msgid "Why?"
+msgstr "Warum?"
+
+#: 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 <a href="
+"\"%(networkcomparisons)s\">other\n"
+"efforts</a> 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 <a href=\"%(networkcomparisons)s\">andere Bestrebungen</a>, "
+"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."
+
+#: pages/site/docs/how/intro.html:59
+msgid "How?"
+msgstr "Wie?"
+
+#: 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 <a href="
+"\"%(tunnelrouting)s\">tunnel routing</a> 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"
+"<a href=\"%(netdb)s\">network database</a> (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"
+"<a href=\"%(tunnelrouting)s\">Tunnel Routing</a>  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 <a href=\"%(netdb)s\">Netzwerk Datenbank</a> (\"Floodfill"
+"\")\n"
+"zum skalierbaren sicherem Verteilen von Routing und Kontaktinformationen."
+
+#: pages/site/docs/how/intro.html:74
+msgid "Network topology example"
+msgstr ""
+
+#: 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."
+
+#: 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 <a href="
+"\"%(garlicrouting)s\">garlic</a>\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"
+"\"<a href=\"%(garlicrouting)s\">Garlics</a>\" 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."
+
+#: 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 <a href="
+"\"%(peerselection)s\">peer selection</a>\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"
+"\"<a href=\"%(peerselection)s\">Knoten Auswahl</a>\" Seite beschrieben ist."
+
+#: pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of <a href="
+"\"%(cryptography)s\">cryptographic\n"
+"techniques and algorithms</a> - 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 <a href="
+"\"%(elgamalaes)s\">ElGamal / AES+SessionTag</a>."
+msgstr ""
+"Das Netzwerk selber nutzt eine signifikante Anzahl von <a href="
+"\"%(cryptography)s\">Kryptographischen\n"
+"Techniken und Algorhytmen</a> - 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 <a "
+"href=\"%(elgamalaes)s\">\n"
+"ElGamal / AES+SessionTag</a>."
+
+#: 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)."
+
+#: 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."
+
+#: pages/site/docs/how/intro.html:129
+msgid "End to end layered encryption"
+msgstr ""
+
+#: pages/site/docs/how/intro.html:131
+#, python-format
+msgid ""
+"The specific use of these algorithms are outlined <a href=\"%(cryptography)s"
+"\">elsewhere</a>."
+msgstr ""
+"Die genaue Anwendung dieser Algorhytmen sind <a href=\"%(cryptography)s"
+"\">woanders</a> beschrieben."
+
+#: 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."
+
+#: 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"
+"<code>O(log(N))</code> due to the <a href=\"%(netdb)s\">network database</"
+"a>'s algorithm, while end\n"
+"to end messages should be <code>O(1)</code> (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 <a href=\"%(netdb)s\">network database</"
+"a>'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."
+
+#: pages/site/docs/how/intro.html:153
+msgid "When?"
+msgstr "Wann?"
+
+#: pages/site/docs/how/intro.html:154
+#, fuzzy, python-format
+msgid ""
+"I2P initially began in Feb 2003 as a proposed modification to <a\n"
+"href=\"http://freenetproject.org\">Freenet</a> to allow it to use alternate "
+"transports, such as <a\n"
+"href=\"http://java.sun.com/products/jms/index.jsp\">JMS</a>, 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 <a "
+"href=\"%(roadmap)s\">roadmap</a>."
+msgstr ""
+"I2P startete im Februar 2003 als eine vorgeschlagene Modifizierung zu <a "
+"href=\"http://freenetproject.org\">\n"
+"Freenet</a>, damit dieses alternative Transports, wie z.B. <a href=\"http://"
+"java.sun.com/products/jms/index.jsp\">\n"
+"JMS</a>, 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 <a href=\"%(roadmap)s\">Roadmap</a>."
+
+#: pages/site/docs/how/intro.html:163
+msgid "Who?"
+msgstr "Wer?"
+
+#: pages/site/docs/how/intro.html:164
+#, fuzzy, python-format
+msgid ""
+"We have a small <a href=\"%(team)s\">team</a> 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 <a href=\"http://java.com/en/\">Sun Java SE</a> and other Java Virtual "
+"Machines."
+msgstr ""
+"Wir sind ein kleines <a href=\"%(team)s\">Team</a> 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 <a href=\"http://gcc.gnu.org/java/\">GCJ</a> lauffähig zu bekommen."
+
+#: pages/site/docs/how/intro.html:175
+msgid "Where?"
+msgstr "Wo?"
+
+#: 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 <a href=\"%(meetings)s\">archives "
+"are available</a>."
+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 <a href="
+"\"%(meetings)s\">Archiv</a>\n"
+"von abgehaltenen Entwickler Treffen."
+
+#: pages/site/docs/how/intro.html:182
+#, python-format
+msgid ""
+"The current source is available in <a href=\"%(monotone)s\">monotone</a>."
+msgstr ""
+"Der aktuelle Quelltext ist in <a href=\"%(monotone)s\">Monotone</a> "
+"verfügbar."
+
+#: pages/site/docs/how/intro.html:186
+msgid "Additional Information"
+msgstr ""
+
+#: pages/site/docs/how/intro.html:187
+#, python-format
+msgid "See <a href=\"%(how_index)s\">the Index to Technical Documentation</a>."
+msgstr ""
+
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 <magma@mail.i2p>, 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 <magma@mail.i2p>\n"
+"Language-Team: fr <LL@li.org>\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 <a href=\"%(i2ptunnel)s\">I2PTunnel</a> 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"
+"<a href=\"%(i2ptunnel)s\">I2PTunnel</a>, 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 <a\n"
+"href=\"%(threatmodel)s\">threat model</a>, 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, <i>all on the same network</i>, 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"
+"<a href=\"%(threatmodel)s\">modèle de sécurité</a>, 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"
+"<i>tout ceci sur le même réseau</i> 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 <a href="
+"\"%(networkcomparisons)s\">other\n"
+"efforts</a> 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 <a href="
+"\"%(networkcomparisons)s\">autres efforts</a>\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 <a href="
+"\"%(tunnelrouting)s\">tunnel routing</a> 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"
+"<a href=\"%(netdb)s\">network database</a> (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"
+"<a href=\"%(tunnelrouting)s\">routage en tunnel</a>).) 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"
+"<a href=\"%(netdb)s\">base de donnée réseau</a> 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 <a href="
+"\"%(garlicrouting)s\">garlic</a>\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 <a href=\"%(garlicrouting)s\">garlic\"</a>,\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 <a href="
+"\"%(peerselection)s\">peer selection</a>\n"
+"page."
+msgstr ""
+"Pour gérer une grande gamme d'attaques, I2P est entièrement <b>décentralisé</"
+"b> 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 <a href=\"%(peerselection)s"
+"\">sélection de pairs</a>."
+
+#: pages/site/docs/how/intro.html:105
+#, python-format
+msgid ""
+"The network itself makes use of a significant number of <a href="
+"\"%(cryptography)s\">cryptographic\n"
+"techniques and algorithms</a> - 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 <a href="
+"\"%(elgamalaes)s\">ElGamal / AES+SessionTag</a>."
+msgstr ""
+"Le réseau fait usage d'un nombre significatif de <a href=\"%(cryptography)s"
+"\">techniques et algorithmes\n"
+"cryptographiques</a>: 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"
+"<a href=\"%(elgamalaes)s\">ElGamal / AES+SessionTag</a>."
+
+#: 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 <b>sont</b> 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 <a href=\"%(cryptography)s"
+"\">elsewhere</a>."
+msgstr ""
+"Les utilisations spécifiques de ces algorithmes sont précisées <a href="
+"\"%(cryptography)s\">ailleurs</a>."
+
+#: 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"
+"<code>O(log(N))</code> due to the <a href=\"%(netdb)s\">network database</"
+"a>'s algorithm, while end\n"
+"to end messages should be <code>O(1)</code> (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 ?|  <b>\n"
+"<code>O(log(N))</code></b> grâce ?|  l'algorithme de la <a href=\"%(netdb)s"
+"\">base de données</a>,\n"
+"alors que les messages seraient plutôt liés ?| <b><code>O(1)</code></b> (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 <a\n"
+"href=\"http://freenetproject.org\">Freenet</a> to allow it to use alternate "
+"transports, such as <a\n"
+"href=\"http://java.sun.com/products/jms/index.jsp\">JMS</a>, 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 <a "
+"href=\"%(roadmap)s\">roadmap</a>."
+msgstr ""
+"I2P a commencé en février 2003 en tant que proposition de modification de\n"
+"<a href=\"http://freenetproject.org\">Freenet</a> pour lui permettre "
+"d'utiliser d'autres modes de transferts,\n"
+"comme <a href=\"http://java.sun.com/products/jms/index.jsp\">JMS</a>, 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 <a href=\"%(roadmap)s\">\n"
+"feuille de route</a>."
+
+#: 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 <a href=\"%(team)s\">team</a> 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 <a href=\"http://java.com/en/\">Sun Java SE</a> and other Java Virtual "
+"Machines."
+msgstr ""
+"Nous sommes une petite <a href=\"%(team)s\">équipe</a> 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 <a href="
+"\"http://java.com/en/\">Oracle/Sun Java SE</a> 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 <a href=\"%(meetings)s\">archives "
+"are available</a>."
+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"
+"<a href=\"%(meetings)s\">les archives sont disponibles</a>."
+
+#: pages/site/docs/how/intro.html:182
+#, python-format
+msgid ""
+"The current source is available in <a href=\"%(monotone)s\">monotone</a>."
+msgstr ""
+"Le code source est disponible dans <a href=\"%(monotone)s\">monotone</a>."
+
+#: 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 <a href=\"%(how_index)s\">the Index to Technical Documentation</a>."
+msgstr ""
+"Voir la <a href=\"%(how_index)s\">table des matières de la documentation "
+"technique</a>."
+
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 %}
-<p>Die Webseite wird gerade überholt und dieses Dokument kann alte Informationen enthalten</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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 
-<a href="http://bitconjurer.org/BitTorrent/">BitTorrent</a> Klient ("I2Psnark") oder ein verteilter 
-Datencontainer. Mit der Hilfe von mihis <a href="i2ptunnel">I2PTunnel</a>
-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.</p>
-
-<p>Ein wichtiger Teil des Planens, Entwickelns und Testens eines anonymen Netzwerkes ist das 
-Definieren des <a href="how_threatmodel">Angriffsszenarios</a>, 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 -
-<i>alles in dem selben Netzwerk</i>, in dem eine Nachricht nicht von einer anderen unterschieden werden
-kann.</p>
-
-<h2>Warum?</h2>
-<p>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 <a href="how_networkcomparisons">andere Bestrebungen</a>, 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.</p>
-
-<h2>Wie?</h2>
-
-<p>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 
-<a href="how_tunnelrouting">Tunnel Routing</a>  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 <a href="how_networkdatabase">Netzwerk Datenbank</a> ("Floodfill") zum skalierbaren sicherem Verteilen von Routing
-und Kontaktinformationen.</p>
-
-<div class="box" style="text-align:center;"><img src="_static/images/net.png" alt="Network topology example" title="Network topology example" /></div>
-
-<p>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.</p>
-  
-<p>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
-"<a href="how_garlicrouting">Garlics</a>" 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.</p>
-
-<p>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 "
-<a href="how_peerselection">Knoten Auswahl</a>" Seite beschrieben ist.</p>
-
-<p>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 <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
-
-<p>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).</p>
-<p>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.</p>
-
-<div class="box" style="text-align:center;"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div>
-
-<p>Die genaue Anwendung dieser Algorhytmen sind <a href="how_cryptography">woanders</a> beschrieben.</p>
-
-<p>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.</p>
-
-<p>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.</p>
-
-<h2>Wann?</h2>
-<p>I2P startete im Februar 2003 als eine vorgeschlagene Modifizierung zu <a href="http://freenetproject.org">Freenet</a>, damit dieses
-alternative Transports, wie z.B. <a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="roadmap">Roadmap</a>.</p>
-
-<p>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.</p>
-
-<h2>Wer?</h2>
-<p>Wir sind ein kleines <a href="team">Team</a> 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 <a href="http://gcc.gnu.org/java/">GCJ</a> lauffähig zu bekommen.</p>
-
-<h2>Wo?</h2>
-<p>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 <a href="meetings">Archiv</a> von abgehaltenen Entwickler Treffen.</p>
-
-<p>Der aktuelle Quelltext ist in <a href="monotone.html">Monotone</a> verfügbar.</p>
-
-{% 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. <a href="how_intro.html">Version anglaise actuelle</a>
-<h2>Une présentation allégée du fonctionnement d'I2P</h2>
-<p>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.</p>
-
-<p>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.</p>
-
-<p>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 <a href="i2ptunnel">I2PTunnel</a>, 
-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.</p>
-
-<p>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
-<a href="how_threatmodel">modèle de sécurité</a>, 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,
-<i>tout ceci sur le même réseau</i> dans lequel les messages des uns sont fondamentalement indistinguables de ceux des 
-autres.</p>
-
-<h2>Pourquoi?</h2>
-<p>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  
-<a href="how_networkcomparisons">autres efforts</a> 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é.</p>
-
-<h2>Comment?</h2>
-
-<p>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 <a href="how_tunnelrouting">routage en tunnel</a>). 
-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 <a href="how_networkdatabase">base de donnée réseau</a> interne 
-(avec une modification de l'algorithme Kademlia) pour une distribution sécurisée 
-des informations de routage et de contacts.</p>
-
-<div class="box" style="text-align:center;">
-<img src="_static/images/net_fr.png" alt="Exemple de topologie du réseau"
-title="Exemple de topologie du réseau"/></div>
-
-
-<p>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.</p>
-  
-<p>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 <a href="how_garlicrouting">garlic"</a>, 
-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.</p>
-
-<p>Pour gérer une grande gamme d'attaques, I2P est entièrement <b>décentralisé</b> 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 <a href="how_peerselection">sélection de pairs</a>.</p>
-
-<p>Le réseau fait usage d'un nombre significatif de 
-<a href="how_cryptography">techniques et algorithmes cryptographiques</a>: 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 <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
-
-<p>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):</p>
-<p>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 <b>sont</b> les applications 
-qui tournent sur I2P.</p>
-
-<div class="box" style="text-align:center;"><img src="_static/images/endToEndEncryption_fr.png" 
-alt="Cryptage en couches de bout en bout" title="Cryptage en couches de bout en bout" /></div>
-
-<p>Les utilisations spécifiques de ces algorithmes sont précisées <a href="how_cryptography">ailleurs</a>.</p>
-
-<p>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.</p>
-
-<p>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 à <b><code>O(log(N))</code></b> 
-grâce à l'algorithme de la <a href="how_networkdatabase">base de données</a>, alors que les messages seraient plutôt 
-liés à <b><code>O(1)</code></b> (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.</p>
-
-<h2>Quand?</h2>
-<p>I2P a commencé en février 2003 en tant que proposition de modification de 
-<a href="http://freenetproject.org">Freenet</a> pour lui permettre d'utiliser d'autres modes de transferts, comme 
-<a href="http://java.sun.com/products/jms/index.jsp">JMS</a>, 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 <a href="roadmap_fr">feuille de route</a>.</p>
-
-<h2>Qui?</h2>
-<p>Nous sommes une petite <a href="team_fr">équipe</a> 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 <a href="http://java.com/en/">Oracle/Sun Java SE</a> et 
-d'autres Machines Virtuelles Java.
-</p>
-
-<h2>Où?</h2>
-<p>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 
-<a href="meetings_fr">les archives sont disponibles</a>.</p>
-
-<p>Le code source est disponible dans <a href="monotone.html">monotone</a>.</p>
-
-<h2>Plus d'infos</h2>
-<p>
-Voir la <a href="how_fr.html">table des matières de la documentation technique</a>.
-</p>
-
-{% endblock %}

From 0eab5f512a912dc56f37f11b365ed5251ec0bc60 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 21:31:08 +0000
Subject: [PATCH 67/75] Prevent lang flag being appended to static urls

---
 i2p2www/__init__.py | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index e3a55619..e5c29ebc 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -55,6 +55,10 @@ def pull_lang(endpoint, values):
 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'):

From 715dc78038d251067337102ea516dbad6e9c8b28 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Mon, 17 Sep 2012 22:55:32 +0000
Subject: [PATCH 68/75] Added translation tags to index page and global
 includes

---
 i2p2www/pages/global/error_404.html | 16 +++---------
 i2p2www/pages/global/error_500.html |  4 +++
 i2p2www/pages/global/footer.html    | 24 ++++++++---------
 i2p2www/pages/global/layout.html    |  2 +-
 i2p2www/pages/global/nav.html       | 40 ++++++++++++++---------------
 i2p2www/pages/site/index.html       | 28 ++++++++++----------
 6 files changed, 55 insertions(+), 59 deletions(-)

diff --git a/i2p2www/pages/global/error_404.html b/i2p2www/pages/global/error_404.html
index d8563c03..5111f007 100644
--- a/i2p2www/pages/global/error_404.html
+++ b/i2p2www/pages/global/error_404.html
@@ -1,21 +1,13 @@
 {% extends "global/layout.html" %}
 {% block title -%}
-{% if g.lang == 'de' %}
-Nicht gefunden
-{% elif g.lang == 'zh' %}
-未找到
-{% else %}
+{% trans -%}
 Not found
-{% endif %}
+{%- endtrans %}
 {%- endblock %}
 
 {% block content %}
-{% if g.lang == 'de' %}
-Yep... die Information nach der du suchst, nennt sich anders, existiert nicht oder wurde entfernt.
-{% elif g.lang == 'zh' %}
-您搜索的页面或资源的名称不正确或不存在或已被删除。
-{% else %}
+{% trans -%}
 Yep... the resource, you were searching for, is named differently, doesn't exist or was removed.
-{% endif %}
+{%- endtrans %}
 
 {% endblock %}
diff --git a/i2p2www/pages/global/error_500.html b/i2p2www/pages/global/error_500.html
index 5f19d7ad..c6cc1159 100644
--- a/i2p2www/pages/global/error_500.html
+++ b/i2p2www/pages/global/error_500.html
@@ -1,8 +1,12 @@
 {% extends "global/layout.html" %}
 {% block title -%}
+{% trans -%}
 Server error
+{%- endtrans %}
 {%- endblock %}
 
 {% block content %}
+{% trans -%}
 Umm... the server encountered some sort of error.
+{%- endtrans %}
 {% endblock %}
diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html
index 602815c2..f131c9c9 100644
--- a/i2p2www/pages/global/footer.html
+++ b/i2p2www/pages/global/footer.html
@@ -1,19 +1,19 @@
       <div class='aside first'>
-        <h1>News</h1>
+        <h1>{{ _('News') }}</h1>
         <ul>
-          <li><a href="{{ url_for('blog_index', lang=g.lang) }}">Announcements</a></li>
-          <li><a href="{{ url_for('meetings_index', lang=g.lang) }}">Meetings</a></li>
+          <li><a href="{{ url_for('blog_index', lang=g.lang) }}">{{ _('Blog') }}</a></li>
+          <li><a href="{{ url_for('meetings_index', lang=g.lang) }}">{{ _('Meetings') }}</a></li>
         </ul>
       </div>
       <div class='aside second'>
-        <h1>About I2P</h1>
+        <h1>{{ _('About I2P') }}</h1>
         <ul>
-          <li><a href="team.html">I2P Team</a></li>
-          <li><a href="halloffame.html">Hall of Fame</a></li>
+          <li><a href="team.html">{{ _('I2P Team') }}</a></li>
+          <li><a href="halloffame.html">{{ _('Hall of Fame') }}</a></li>
         </ul>
       </div>
       <div class='aside third'>
-        <h1>Mirrors</h1>
+        <h1>{{ _('Mirrors') }}</h1>
         <ul>
           <li><a rel="nofollow" href="http://i2pproject.net/">http://i2pproject.net</a></li>
           <li><a rel="nofollow" href="http://i2p.us/">http://i2p.us</a></li>
@@ -21,20 +21,20 @@
         </ul>
       </div>
       <div class='aside fourth'>
-        <h1>Secure</h1>
+        <h1>{{ _('Secure') }}</h1>
         <ul>
           <li><a rel="nofollow" href="https://www.i2p2.de/">https://www.i2p2.de</a></li>
           <li><a rel="nofollow" href="https://i2p.us/">https://i2p.us</a></li>
         </ul>
       </div>
       <div class='aside fifth'>
-        <h1>Misc.</h1>
+        <h1>{{ _('Misc.') }}</h1>
         <ul>
           <li><a href="http://syndie.i2p2.de/">Syndie</a></li>
-          <li><a href="links.html">Links</a></li>
-          <li><a href="impressum.html">Impressum</a></li>
+          <li><a href="links.html">{{ _('Links') }}</a></li>
+          <li><a href="impressum.html">{{ _('Impressum') }}</a></li>
         </ul>
       </div>
       <div class='aside sixth'>
-        <a class='button' href="{{ site_url('volunteer/donate') }}">Donate</a>
+        <a class='button' href="{{ site_url('volunteer/donate') }}">{{ _('Donate') }}</a>
       </div>
diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html
index 5ef6d7aa..6978c796 100644
--- a/i2p2www/pages/global/layout.html
+++ b/i2p2www/pages/global/layout.html
@@ -9,7 +9,7 @@
     <meta name="robots" content="NOODP" />
   </head>
   <body>
-    <div class="hide"><a href="#content" title="Skip navigation" accesskey="2">Skip navigation</a></div>
+    <div class="hide"><a href="#content" title="Skip navigation" accesskey="2">{{ _('Skip navigation') }}</a></div>
     <div id="branding">
       <h1 id="logo"><a href="{{ site_url() }}"><img src="{{ url_for('static', filename='images/logo_medium.png') }}" alt="I2P" /></a></h1>
       <div class="title">{{ self.title() }}</div>
diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index f7326cee..70851350 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -1,41 +1,41 @@
 <div id="cssmenu">
 <ul>
-  <li><a href="{{ site_url() }}"><span>Home</span></a></li>
-  <li><a href="{{ url_for('downloads_list', lang=g.lang) }}"><span>Download</span></a></li>
-  <li class="has-sub"><a href="#"><span>Docs</span></a>
+  <li><a href="{{ site_url() }}"><span>{{ _('Home') }}</span></a></li>
+  <li><a href="{{ url_for('downloads_list', lang=g.lang) }}"><span>{{ _('Download') }}</span></a></li>
+  <li class="has-sub"><a href="#"><span>{{ _('Docs') }}</span></a>
     <ul>
-      <li class="has-sub"><a href="{{ site_url('docs/how') }}"><span>How does it work?</span></a>
+      <li class="has-sub"><a href="{{ site_url('docs/how') }}"><span>{{ _('How does it work?') }}</span></a>
         <ul>
-          <li><a href="{{ site_url('docs/how/intro') }}"><span>Gentle intro</span></a></li>
-          <li><a href="{{ site_url('docs/techintro') }}"><span>Tech intro</span></a></li>
+          <li><a href="{{ site_url('docs/how/intro') }}"><span>{{ _('Gentle intro') }}</span></a></li>
+          <li><a href="{{ site_url('docs/techintro') }}"><span>{{ _('Tech intro') }}</span></a></li>
         </ul>
       </li>
-      <li><a href="howto.html"><span>Howto docs</span></a></li>
-      <li><a href="applications.html"><span>Applications</span></a></li>
+      <li><a href="howto.html"><span>{{ _('Howto docs') }}</span></a></li>
+      <li><a href="applications.html"><span>{{ _('Applications') }}</span></a></li>
     </ul>
   </li>
-  <li class="has-sub"><a href="#"><span>Support</span></a>
+  <li class="has-sub"><a href="#"><span>{{ _('Support') }}</span></a>
     <ul>
-      <li><a href="{{ site_url('support/faq') }}"><span>FAQ</span></a></li>
-      <li><a href="http://forum.i2p2.de/"><span>Forums</span></a></li>
+      <li><a href="{{ site_url('support/faq') }}"><span>{{ _('FAQ') }}</span></a></li>
+      <li><a href="http://forum.i2p2.de/"><span>{{ _('Forums') }}</span></a></li>
     </ul>
   </li>
-  <li class="has-sub"><a href="#"><span>Develop</span></a>
+  <li class="has-sub"><a href="#"><span>{{ _('Develop') }}</span></a>
     <ul>
-      <li><a href="{{ site_url('develop/api') }}"><span>API</span></a></li>
-      <li><a href="{{ site_url('develop/applications') }}"><span>Applications</span></a></li>
-      <li><a href="{{ site_url('develop/licenses') }}"><span>Licenses</span></a></li>
+      <li><a href="{{ site_url('develop/api') }}"><span>{{ _('API') }}</span></a></li>
+      <li><a href="{{ site_url('develop/applications') }}"><span>{{ _('Applications') }}</span></a></li>
+      <li><a href="{{ site_url('develop/licenses') }}"><span>{{ _('Licenses') }}</span></a></li>
       <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
-  <li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>Volunteer</span></a>
+  <li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>{{ _('Volunteer') }}</span></a>
     <ul>
-      <li><a href="{{ site_url('volunteer/bounties') }}"><span>Bounties</span></a></li>
-      <li><a href="roadmap.html"><span>Roadmap</span></a></li>
-      <li><a href="todo.html"><span>Task list</span></a></li>
+      <li><a href="{{ site_url('volunteer/bounties') }}"><span>{{ _('Bounties') }}</span></a></li>
+      <li><a href="roadmap.html"><span>{{ _('Roadmap') }}</span></a></li>
+      <li><a href="todo.html"><span>{{ _('Task list') }}</span></a></li>
     </ul>
   </li>
-  <li class="has-sub right"><a href="#"><span>Language</span></a>
+  <li class="has-sub right"><a href="#"><span>{{ _('Language') }}</span></a>
     {% include "global/lang.html" %}
   </li>
 </ul>
diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html
index e27fbcb6..dd36699b 100644
--- a/i2p2www/pages/site/index.html
+++ b/i2p2www/pages/site/index.html
@@ -1,26 +1,26 @@
 {% extends "global/layout.html" %}
-{% block title %}The Invisible Internet Project{% endblock %}
+{% block title %}{% trans %}The Invisible Internet Project{% endtrans %}{% endblock %}
 {% block content_outer %}
 <div class="main">
-  <h1>What does I2P do for you?</h1>
-  <p>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 on I2P.</p>
-  <a class="get-i2p" href="{{ url_for('downloads_list', lang=g.lang) }}">Get I2P 0.9.1</a>
+  <h1>{% trans %}What does I2P do for you?{% endtrans %}</h1>
+  <p>{% 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 on I2P.{% endtrans %}</p>
+  <a class="get-i2p" href="{{ url_for('downloads_list', lang=g.lang) }}">{% trans version='0.9.1' %}Get I2P {{ version }}{% endtrans %}</a>
 </div>
 <div class="aside-wrap">
   <div class="aside">
-    <h1>Who Uses I2P?</h1>
-    <p>I2P is used by many people who care about their privacy, as well as those in high-risk situations such as:</p>
+    <h1>{% trans %}Who Uses I2P?{% endtrans %}</h1>
+    <p>{% trans %}I2P is used by many people who care about their privacy, as well as those in high-risk situations such as:{% endtrans %}</p>
     <ul>
-      <li><a href='#'>Activists</a></li>
-      <li><a href='#'>Oppressed People</a></li>
-      <li><a href='#'>Journalists</a></li>
-      <li><a href='#'>Whistleblowers</a></li>
-      <li><a href='#'>The Privacy-Conscious</a></li>
-      <li><a href='#'>Ur Mom</a></li>
+      <li><a href='#'>{{ _('Activists') }}</a></li>
+      <li><a href='#'>{{ _('Oppressed People') }}</a></li>
+      <li><a href='#'>{{ _('Journalists') }}</a></li>
+      <li><a href='#'>{{ _('Whistleblowers') }}</a></li>
+      <li><a href='#'>{{ _('The Privacy-Conscious') }}</a></li>
+      <li><a href='#'>{{ _('Ur Mom') }}</a></li>
     </ul>
   </div>
   <div class="aside">
-    <h1>Supported Software</h1>
+    <h1>{{ _('Supported Software') }}</h1>
     <ul>
       <li>
       <a href="supported_applications_email.html">Email</a> Integrated web mail interface, plugin for serverless email.
@@ -49,7 +49,7 @@
     </ul>
   </div>
   <div class="aside">
-    <h1>News & Updates</h1>
+    <h1>{% trans %}News & Updates{% endtrans %}</h1>
       <ul>
         <li>2012-07-30 - <a href="release-0.9.1.html">I2P 0.9.1 Released</a></li>
         <li>2012-05-02 - <a href="release-0.9.html">I2P 0.9 Released</a></li>

From a49c9a0eb47ece7119fc9cfa7aed556ed2b00f3a Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Wed, 19 Sep 2012 11:16:10 +0000
Subject: [PATCH 69/75] Moved the Trac menu link from Develop to Support

---
 i2p2www/pages/global/nav.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html
index 70851350..efbbcc92 100644
--- a/i2p2www/pages/global/nav.html
+++ b/i2p2www/pages/global/nav.html
@@ -18,6 +18,7 @@
     <ul>
       <li><a href="{{ site_url('support/faq') }}"><span>{{ _('FAQ') }}</span></a></li>
       <li><a href="http://forum.i2p2.de/"><span>{{ _('Forums') }}</span></a></li>
+      <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
   <li class="has-sub"><a href="#"><span>{{ _('Develop') }}</span></a>
@@ -25,7 +26,6 @@
       <li><a href="{{ site_url('develop/api') }}"><span>{{ _('API') }}</span></a></li>
       <li><a href="{{ site_url('develop/applications') }}"><span>{{ _('Applications') }}</span></a></li>
       <li><a href="{{ site_url('develop/licenses') }}"><span>{{ _('Licenses') }}</span></a></li>
-      <li><a href="http://trac.i2p2.i2p/"><span>Trac</span></a></li>
     </ul>
   </li>
   <li class="has-sub"><a href="{{ site_url('volunteer') }}"><span>{{ _('Volunteer') }}</span></a>

From 5d5419b0c4e9e376a8be3f62520e34259d469616 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Wed, 19 Sep 2012 12:02:03 +0000
Subject: [PATCH 70/75] Moved latest news list from index.html to a separate
 file (since it will be updated more often)

---
 i2p2www/pages/blog/latest.html | 12 ++++++++++++
 i2p2www/pages/site/index.html  | 13 +------------
 2 files changed, 13 insertions(+), 12 deletions(-)
 create mode 100644 i2p2www/pages/blog/latest.html

diff --git a/i2p2www/pages/blog/latest.html b/i2p2www/pages/blog/latest.html
new file mode 100644
index 00000000..5d617502
--- /dev/null
+++ b/i2p2www/pages/blog/latest.html
@@ -0,0 +1,12 @@
+      <ul>
+        <li>2012-07-30 - <a href="release-0.9.1.html">I2P 0.9.1 Released</a></li>
+        <li>2012-05-02 - <a href="release-0.9.html">I2P 0.9 Released</a></li>
+        <li>2012-02-27 - <a href="release-0.8.13.html">I2P 0.8.13 Released</a></li>
+        <li>2012-01-06 - <a href="release-0.8.12.html">I2P 0.8.12 Released</a></li>
+        <li>2011-03-02 - <a href="release-0.8.4.html">I2P 0.8.4 Released</a></li>
+        <li>2011-03-01 - <a href='#'>Coding Moratorium & New Site </a></li>
+        <li>2011-01-24 - <a href="release-0.8.3.html">I2P 0.8.3 Released</a></li>
+        <li>2011-01-01 - <a href='#'>I2P at HOPE, Pegasus Project</a></li>
+        <li>2010-12-22 - <a href="release-0.8.2.html">I2P 0.8.2 Released</a></li>
+        <li>2010-11-15 - <a href="release-0.8.1.html">I2P 0.8.1 Released</a></li>
+      </ul>
diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html
index dd36699b..db8606e5 100644
--- a/i2p2www/pages/site/index.html
+++ b/i2p2www/pages/site/index.html
@@ -50,18 +50,7 @@
   </div>
   <div class="aside">
     <h1>{% trans %}News & Updates{% endtrans %}</h1>
-      <ul>
-        <li>2012-07-30 - <a href="release-0.9.1.html">I2P 0.9.1 Released</a></li>
-        <li>2012-05-02 - <a href="release-0.9.html">I2P 0.9 Released</a></li>
-        <li>2012-02-27 - <a href="release-0.8.13.html">I2P 0.8.13 Released</a></li>
-        <li>2012-01-06 - <a href="release-0.8.12.html">I2P 0.8.12 Released</a></li>
-        <li>2011-03-02 - <a href="release-0.8.4.html">I2P 0.8.4 Released</a></li>
-        <li>2011-03-01 - <a href='#'>Coding Moratorium & New Site </a></li>
-        <li>2011-01-24 - <a href="release-0.8.3.html">I2P 0.8.3 Released</a></li>
-        <li>2011-01-01 - <a href='#'>I2P at HOPE, Pegasus Project</a></li>
-        <li>2010-12-22 - <a href="release-0.8.2.html">I2P 0.8.2 Released</a></li>
-        <li>2010-11-15 - <a href="release-0.8.1.html">I2P 0.8.1 Released</a></li>
-      </ul>
+      {% include "blog/latest.html" %}
   </div>
 </div>
 {% endblock %}

From 416cf769709b4706366e25fefd5b345468656dfc Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Wed, 19 Sep 2012 14:06:13 +0000
Subject: [PATCH 71/75] Migrated announcements to blog

---
 i2p2www/blog/2007/10/07/I2P_0.6.1.30_released.rst        | 6 ++++++
 .../blog/2007/10/07}/release-0.6.1.30.html               | 4 ----
 i2p2www/blog/2008/02/10/I2P_0.6.1.31_released.rst        | 6 ++++++
 .../blog/2008/02/10}/release-0.6.1.31.html               | 4 ----
 i2p2www/blog/2008/03/09/I2P_0.6.1.32_released.rst        | 6 ++++++
 .../blog/2008/03/09}/release-0.6.1.32.html               | 4 ----
 i2p2www/blog/2008/04/26/I2P_0.6.1.33_released.rst        | 6 ++++++
 .../blog/2008/04/26}/release-0.6.1.33.html               | 4 ----
 i2p2www/blog/2008/06/07/I2P_0.6.2_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2008/06/07}/release-0.6.2.html | 4 ----
 i2p2www/blog/2008/08/26/I2P_0.6.3_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2008/08/26}/release-0.6.3.html | 4 ----
 i2p2www/blog/2008/10/06/I2P_0.6.4_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2008/10/06}/release-0.6.4.html | 4 ----
 i2p2www/blog/2008/12/01/I2P_0.6.5_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2008/12/01}/release-0.6.5.html | 4 ----
 i2p2www/blog/2009/01/25/I2P_0.7_released.rst             | 6 ++++++
 .../pages => i2p2www/blog/2009/01/25}/release-0.7.html   | 4 ----
 i2p2www/blog/2009/03/29/I2P_0.7.1_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/03/29}/release-0.7.1.html | 4 ----
 i2p2www/blog/2009/04/19/I2P_0.7.2_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/04/19}/release-0.7.2.html | 4 ----
 i2p2www/blog/2009/05/18/I2P_0.7.3_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/05/18}/release-0.7.3.html | 4 ----
 i2p2www/blog/2009/06/13/I2P_0.7.4_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/06/13}/release-0.7.4.html | 4 ----
 i2p2www/blog/2009/06/29/I2P_0.7.5_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/06/29}/release-0.7.5.html | 4 ----
 i2p2www/blog/2009/07/31/I2P_0.7.6_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/07/31}/release-0.7.6.html | 4 ----
 i2p2www/blog/2009/10/12/I2P_0.7.7_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/10/12}/release-0.7.7.html | 4 ----
 i2p2www/blog/2009/12/08/I2P_0.7.8_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2009/12/08}/release-0.7.8.html | 4 ----
 i2p2www/blog/2010/01/12/I2P_0.7.9_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2010/01/12}/release-0.7.9.html | 4 ----
 i2p2www/blog/2010/01/22/I2P_0.7.10_released.rst          | 6 ++++++
 .../blog/2010/01/22}/release-0.7.10.html                 | 4 ----
 i2p2www/blog/2010/02/15/I2P_0.7.11_released.rst          | 6 ++++++
 .../blog/2010/02/15}/release-0.7.11.html                 | 4 ----
 i2p2www/blog/2010/03/15/I2P_0.7.12_released.rst          | 6 ++++++
 .../blog/2010/03/15}/release-0.7.12.html                 | 4 ----
 i2p2www/blog/2010/04/27/I2P_0.7.13_released.rst          | 6 ++++++
 .../blog/2010/04/27}/release-0.7.13.html                 | 4 ----
 i2p2www/blog/2010/06/07/I2P_0.7.14_released.rst          | 6 ++++++
 .../blog/2010/06/07}/release-0.7.14.html                 | 4 ----
 i2p2www/blog/2010/07/12/I2P_0.8_released.rst             | 6 ++++++
 .../pages => i2p2www/blog/2010/07/12}/release-0.8.html   | 4 ----
 i2p2www/blog/2010/11/15/I2P_0.8.1_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2010/11/15}/release-0.8.1.html | 4 ----
 i2p2www/blog/2010/12/22/I2P_0.8.2_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2010/12/22}/release-0.8.2.html | 4 ----
 i2p2www/blog/2011/01/24/I2P_0.8.3_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/01/24}/release-0.8.3.html | 4 ----
 i2p2www/blog/2011/03/02/I2P_0.8.4_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/03/02}/release-0.8.4.html | 4 ----
 i2p2www/blog/2011/04/18/I2P_0.8.5_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/04/18}/release-0.8.5.html | 5 -----
 i2p2www/blog/2011/05/16/I2P_0.8.6_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/05/16}/release-0.8.6.html | 5 -----
 i2p2www/blog/2011/06/06/Ipredator_Summer_of_Code.rst     | 6 ++++++
 .../blog/2011/06/06}/summerofcode-2011.html              | 6 ------
 i2p2www/blog/2011/06/27/I2P_0.8.7_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/06/27}/release-0.8.7.html | 6 ------
 i2p2www/blog/2011/08/23/I2P_0.8.8_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/08/23}/release-0.8.8.html | 6 ------
 .../03/Ipredator_Summer_of_Code_-_itoopie_released.rst   | 6 ++++++
 .../blog/2011/09/03}/summerofcode-2011-end.html          | 9 ---------
 i2p2www/blog/2011/10/11/I2P_0.8.9_released.rst           | 6 ++++++
 .../pages => i2p2www/blog/2011/10/11}/release-0.8.9.html | 6 ------
 i2p2www/blog/2011/10/20/I2P_0.8.10_released.rst          | 6 ++++++
 .../blog/2011/10/20}/release-0.8.10.html                 | 6 ------
 i2p2www/blog/2011/11/08/I2P_0.8.11_released.rst          | 6 ++++++
 .../blog/2011/11/08}/release-0.8.11.html                 | 6 ------
 i2p2www/blog/2012/01/06/I2P_0.8.12_released.rst          | 6 ++++++
 .../blog/2012/01/06}/release-0.8.12.html                 | 6 ------
 i2p2www/blog/2012/02/27/I2P_0.8.13_released.rst          | 6 ++++++
 .../blog/2012/02/27}/release-0.8.13.html                 | 6 ------
 i2p2www/blog/2012/05/02/I2P_0.9_released.rst             | 6 ++++++
 .../pages => i2p2www/blog/2012/05/02}/release-0.9.html   | 6 ------
 80 files changed, 240 insertions(+), 185 deletions(-)
 create mode 100644 i2p2www/blog/2007/10/07/I2P_0.6.1.30_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2007/10/07}/release-0.6.1.30.html (87%)
 create mode 100644 i2p2www/blog/2008/02/10/I2P_0.6.1.31_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/02/10}/release-0.6.1.31.html (92%)
 create mode 100644 i2p2www/blog/2008/03/09/I2P_0.6.1.32_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/03/09}/release-0.6.1.32.html (94%)
 create mode 100644 i2p2www/blog/2008/04/26/I2P_0.6.1.33_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/04/26}/release-0.6.1.33.html (92%)
 create mode 100644 i2p2www/blog/2008/06/07/I2P_0.6.2_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/06/07}/release-0.6.2.html (93%)
 create mode 100644 i2p2www/blog/2008/08/26/I2P_0.6.3_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/08/26}/release-0.6.3.html (93%)
 create mode 100644 i2p2www/blog/2008/10/06/I2P_0.6.4_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/10/06}/release-0.6.4.html (93%)
 create mode 100644 i2p2www/blog/2008/12/01/I2P_0.6.5_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2008/12/01}/release-0.6.5.html (94%)
 create mode 100644 i2p2www/blog/2009/01/25/I2P_0.7_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/01/25}/release-0.7.html (95%)
 create mode 100644 i2p2www/blog/2009/03/29/I2P_0.7.1_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/03/29}/release-0.7.1.html (93%)
 create mode 100644 i2p2www/blog/2009/04/19/I2P_0.7.2_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/04/19}/release-0.7.2.html (93%)
 create mode 100644 i2p2www/blog/2009/05/18/I2P_0.7.3_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/05/18}/release-0.7.3.html (93%)
 create mode 100644 i2p2www/blog/2009/06/13/I2P_0.7.4_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/06/13}/release-0.7.4.html (93%)
 create mode 100644 i2p2www/blog/2009/06/29/I2P_0.7.5_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/06/29}/release-0.7.5.html (95%)
 create mode 100644 i2p2www/blog/2009/07/31/I2P_0.7.6_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/07/31}/release-0.7.6.html (97%)
 create mode 100644 i2p2www/blog/2009/10/12/I2P_0.7.7_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/10/12}/release-0.7.7.html (95%)
 create mode 100644 i2p2www/blog/2009/12/08/I2P_0.7.8_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2009/12/08}/release-0.7.8.html (97%)
 create mode 100644 i2p2www/blog/2010/01/12/I2P_0.7.9_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/01/12}/release-0.7.9.html (96%)
 create mode 100644 i2p2www/blog/2010/01/22/I2P_0.7.10_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/01/22}/release-0.7.10.html (91%)
 create mode 100644 i2p2www/blog/2010/02/15/I2P_0.7.11_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/02/15}/release-0.7.11.html (95%)
 create mode 100644 i2p2www/blog/2010/03/15/I2P_0.7.12_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/03/15}/release-0.7.12.html (97%)
 create mode 100644 i2p2www/blog/2010/04/27/I2P_0.7.13_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/04/27}/release-0.7.13.html (96%)
 create mode 100644 i2p2www/blog/2010/06/07/I2P_0.7.14_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/06/07}/release-0.7.14.html (94%)
 create mode 100644 i2p2www/blog/2010/07/12/I2P_0.8_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/07/12}/release-0.8.html (97%)
 create mode 100644 i2p2www/blog/2010/11/15/I2P_0.8.1_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/11/15}/release-0.8.1.html (95%)
 create mode 100644 i2p2www/blog/2010/12/22/I2P_0.8.2_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2010/12/22}/release-0.8.2.html (96%)
 create mode 100644 i2p2www/blog/2011/01/24/I2P_0.8.3_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/01/24}/release-0.8.3.html (95%)
 create mode 100644 i2p2www/blog/2011/03/02/I2P_0.8.4_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/03/02}/release-0.8.4.html (94%)
 create mode 100644 i2p2www/blog/2011/04/18/I2P_0.8.5_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/04/18}/release-0.8.5.html (94%)
 create mode 100644 i2p2www/blog/2011/05/16/I2P_0.8.6_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/05/16}/release-0.8.6.html (93%)
 create mode 100644 i2p2www/blog/2011/06/06/Ipredator_Summer_of_Code.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/06/06}/summerofcode-2011.html (87%)
 create mode 100644 i2p2www/blog/2011/06/27/I2P_0.8.7_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/06/27}/release-0.8.7.html (98%)
 create mode 100644 i2p2www/blog/2011/08/23/I2P_0.8.8_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/08/23}/release-0.8.8.html (97%)
 create mode 100644 i2p2www/blog/2011/09/03/Ipredator_Summer_of_Code_-_itoopie_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/09/03}/summerofcode-2011-end.html (89%)
 create mode 100644 i2p2www/blog/2011/10/11/I2P_0.8.9_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/10/11}/release-0.8.9.html (97%)
 create mode 100644 i2p2www/blog/2011/10/20/I2P_0.8.10_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/10/20}/release-0.8.10.html (92%)
 create mode 100644 i2p2www/blog/2011/11/08/I2P_0.8.11_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2011/11/08}/release-0.8.11.html (95%)
 create mode 100644 i2p2www/blog/2012/01/06/I2P_0.8.12_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2012/01/06}/release-0.8.12.html (97%)
 create mode 100644 i2p2www/blog/2012/02/27/I2P_0.8.13_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2012/02/27}/release-0.8.13.html (97%)
 create mode 100644 i2p2www/blog/2012/05/02/I2P_0.9_released.rst
 rename {www.i2p2/pages => i2p2www/blog/2012/05/02}/release-0.9.html (97%)

diff --git a/i2p2www/blog/2007/10/07/I2P_0.6.1.30_released.rst b/i2p2www/blog/2007/10/07/I2P_0.6.1.30_released.rst
new file mode 100644
index 00000000..6539ec97
--- /dev/null
+++ b/i2p2www/blog/2007/10/07/I2P_0.6.1.30_released.rst
@@ -0,0 +1,6 @@
+=============
+0.6.1.30 Release
+=============
+
+.. raw:: html
+   :file: blog/2008/02/02/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -28,4 +25,3 @@ C5c5uUMKct7SwyqWArEyx2I=
 =WZ3+
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/02/10/I2P_0.6.1.31_released.rst b/i2p2www/blog/2008/02/10/I2P_0.6.1.31_released.rst
new file mode 100644
index 00000000..7ae2421a
--- /dev/null
+++ b/i2p2www/blog/2008/02/10/I2P_0.6.1.31_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -43,4 +40,3 @@ DgDzhyGCLCMWps4ibp7w4ZM=
 =T9GN
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/03/09/I2P_0.6.1.32_released.rst b/i2p2www/blog/2008/03/09/I2P_0.6.1.32_released.rst
new file mode 100644
index 00000000..47183700
--- /dev/null
+++ b/i2p2www/blog/2008/03/09/I2P_0.6.1.32_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -55,4 +52,3 @@ E+npcvwX3Y4q5oAD4t9RUBI=
 =EaFf
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/04/26/I2P_0.6.1.33_released.rst b/i2p2www/blog/2008/04/26/I2P_0.6.1.33_released.rst
new file mode 100644
index 00000000..056bba6e
--- /dev/null
+++ b/i2p2www/blog/2008/04/26/I2P_0.6.1.33_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -41,4 +38,3 @@ iD8DBQFIE5cv+h38a3n8zjMRAiNhAJ4o+6vL/Yd7TlUoU1pevLGXGCsa4gCgiEDK
 =Yac6
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/06/07/I2P_0.6.2_released.rst b/i2p2www/blog/2008/06/07/I2P_0.6.2_released.rst
new file mode 100644
index 00000000..4eb68369
--- /dev/null
+++ b/i2p2www/blog/2008/06/07/I2P_0.6.2_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ AqL1Wz/jN7hRUPXLRhPJTGw=
 =u9me
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/08/26/I2P_0.6.3_released.rst b/i2p2www/blog/2008/08/26/I2P_0.6.3_released.rst
new file mode 100644
index 00000000..026c449e
--- /dev/null
+++ b/i2p2www/blog/2008/08/26/I2P_0.6.3_released.rst
@@ -0,0 +1,6 @@
+=============
+0.6.3 Release
+=============
+
+.. raw:: html
+   :file: blog/2008/08/24/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -45,4 +42,3 @@ iD8DBQFIsTvl+h38a3n8zjMRAi2GAJ9HAwg9JBWIjkHcvR8SHw95FcYnngCfQL+w
 =5P8t
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/10/06/I2P_0.6.4_released.rst b/i2p2www/blog/2008/10/06/I2P_0.6.4_released.rst
new file mode 100644
index 00000000..9bc8f5a3
--- /dev/null
+++ b/i2p2www/blog/2008/10/06/I2P_0.6.4_released.rst
@@ -0,0 +1,6 @@
+=============
+0.6.4 Release
+=============
+
+.. raw:: html
+   :file: blog/2008/10/07/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -46,4 +43,3 @@ ceYAn0BoC7N/Er34EG361tdrG8qT9WpQ
 =hG2h
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2008/12/01/I2P_0.6.5_released.rst b/i2p2www/blog/2008/12/01/I2P_0.6.5_released.rst
new file mode 100644
index 00000000..98f996b0
--- /dev/null
+++ b/i2p2www/blog/2008/12/01/I2P_0.6.5_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -57,4 +54,3 @@ clQAnRbuoYUa8qPiea7fCxOsGKsJMMCL
 =STLb
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/01/25/I2P_0.7_released.rst b/i2p2www/blog/2009/01/25/I2P_0.7_released.rst
new file mode 100644
index 00000000..441a3c14
--- /dev/null
+++ b/i2p2www/blog/2009/01/25/I2P_0.7_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -56,4 +53,3 @@ UkgAn1HqnG8FOuN84l3gShE3PVfDAVNS
 =TxoZ
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/03/29/I2P_0.7.1_released.rst b/i2p2www/blog/2009/03/29/I2P_0.7.1_released.rst
new file mode 100644
index 00000000..d8c8fb70
--- /dev/null
+++ b/i2p2www/blog/2009/03/29/I2P_0.7.1_released.rst
@@ -0,0 +1,6 @@
+=============
+0.7.1 Release
+=============
+
+.. raw:: html
+   :file: blog/2009/03/30/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ iEYEARECAAYFAknP3UQACgkQ+h38a3n8zjNTwwCcCBDoS6Lqz7rpuNFx4ilSO6fb
 =BBsy
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/04/19/I2P_0.7.2_released.rst b/i2p2www/blog/2009/04/19/I2P_0.7.2_released.rst
new file mode 100644
index 00000000..c4219fad
--- /dev/null
+++ b/i2p2www/blog/2009/04/19/I2P_0.7.2_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -47,4 +44,3 @@ HZMAn15tFbcHh2xE+HyZOT1EOctYZHK/
 =RpcD
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/05/18/I2P_0.7.3_released.rst b/i2p2www/blog/2009/05/18/I2P_0.7.3_released.rst
new file mode 100644
index 00000000..c129b9c6
--- /dev/null
+++ b/i2p2www/blog/2009/05/18/I2P_0.7.3_released.rst
@@ -0,0 +1,6 @@
+=============
+0.7.3 Release
+=============
+
+.. raw:: html
+   :file: blog/2009/05/16/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -44,4 +41,3 @@ Cy0An372IlJMf/E+dHE9ssiH4DoTi57q
 =7SfN
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/06/13/I2P_0.7.4_released.rst b/i2p2www/blog/2009/06/13/I2P_0.7.4_released.rst
new file mode 100644
index 00000000..a361c87d
--- /dev/null
+++ b/i2p2www/blog/2009/06/13/I2P_0.7.4_released.rst
@@ -0,0 +1,6 @@
+=============
+0.7.4 Release
+=============
+
+.. raw:: html
+   :file: blog/2009/06/12/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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -44,4 +41,3 @@ gc8An3/HFievfAvorlpm2GzzZE57KVIy
 =xe6x
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/06/29/I2P_0.7.5_released.rst b/i2p2www/blog/2009/06/29/I2P_0.7.5_released.rst
new file mode 100644
index 00000000..ee552e52
--- /dev/null
+++ b/i2p2www/blog/2009/06/29/I2P_0.7.5_released.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 %}
 <pre>
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA1
@@ -66,4 +63,3 @@ gk8AoIU30WJSxJmFo5FTDYRDc605HBgw
 =5I+4
 -----END PGP SIGNATURE-----
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/07/31/I2P_0.7.6_released.rst b/i2p2www/blog/2009/07/31/I2P_0.7.6_released.rst
new file mode 100644
index 00000000..9d28affd
--- /dev/null
+++ b/i2p2www/blog/2009/07/31/I2P_0.7.6_released.rst
@@ -0,0 +1,6 @@
+=============
+0.7.6 Release
+=============
+
+.. raw:: html
+   :file: blog/2009/07/30/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 %}
 <p>
 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
 </pre>
-{% endblock %}
diff --git a/i2p2www/blog/2009/10/12/I2P_0.7.7_released.rst b/i2p2www/blog/2009/10/12/I2P_0.7.7_released.rst
new file mode 100644
index 00000000..37db0f7d
--- /dev/null
+++ b/i2p2www/blog/2009/10/12/I2P_0.7.7_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2009/12/08/I2P_0.7.8_released.rst b/i2p2www/blog/2009/12/08/I2P_0.7.8_released.rst
new file mode 100644
index 00000000..4930c1a6
--- /dev/null
+++ b/i2p2www/blog/2009/12/08/I2P_0.7.8_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/01/12/I2P_0.7.9_released.rst b/i2p2www/blog/2010/01/12/I2P_0.7.9_released.rst
new file mode 100644
index 00000000..19d8385a
--- /dev/null
+++ b/i2p2www/blog/2010/01/12/I2P_0.7.9_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/01/22/I2P_0.7.10_released.rst b/i2p2www/blog/2010/01/22/I2P_0.7.10_released.rst
new file mode 100644
index 00000000..61802ba2
--- /dev/null
+++ b/i2p2www/blog/2010/01/22/I2P_0.7.10_released.rst
@@ -0,0 +1,6 @@
+=============
+0.7.10 Release
+=============
+
+.. raw:: html
+   :file: blog/2010/01/21/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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/02/15/I2P_0.7.11_released.rst b/i2p2www/blog/2010/02/15/I2P_0.7.11_released.rst
new file mode 100644
index 00000000..9684e327
--- /dev/null
+++ b/i2p2www/blog/2010/02/15/I2P_0.7.11_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/03/15/I2P_0.7.12_released.rst b/i2p2www/blog/2010/03/15/I2P_0.7.12_released.rst
new file mode 100644
index 00000000..fb2a6056
--- /dev/null
+++ b/i2p2www/blog/2010/03/15/I2P_0.7.12_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/04/27/I2P_0.7.13_released.rst b/i2p2www/blog/2010/04/27/I2P_0.7.13_released.rst
new file mode 100644
index 00000000..e143821d
--- /dev/null
+++ b/i2p2www/blog/2010/04/27/I2P_0.7.13_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/06/07/I2P_0.7.14_released.rst b/i2p2www/blog/2010/06/07/I2P_0.7.14_released.rst
new file mode 100644
index 00000000..fb2ae624
--- /dev/null
+++ b/i2p2www/blog/2010/06/07/I2P_0.7.14_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/07/12/I2P_0.8_released.rst b/i2p2www/blog/2010/07/12/I2P_0.8_released.rst
new file mode 100644
index 00000000..24dc0f6b
--- /dev/null
+++ b/i2p2www/blog/2010/07/12/I2P_0.8_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/11/15/I2P_0.8.1_released.rst b/i2p2www/blog/2010/11/15/I2P_0.8.1_released.rst
new file mode 100644
index 00000000..5024592c
--- /dev/null
+++ b/i2p2www/blog/2010/11/15/I2P_0.8.1_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2010/12/22/I2P_0.8.2_released.rst b/i2p2www/blog/2010/12/22/I2P_0.8.2_released.rst
new file mode 100644
index 00000000..9803fb98
--- /dev/null
+++ b/i2p2www/blog/2010/12/22/I2P_0.8.2_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2011/01/24/I2P_0.8.3_released.rst b/i2p2www/blog/2011/01/24/I2P_0.8.3_released.rst
new file mode 100644
index 00000000..3278d520
--- /dev/null
+++ b/i2p2www/blog/2011/01/24/I2P_0.8.3_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2011/03/02/I2P_0.8.4_released.rst b/i2p2www/blog/2011/03/02/I2P_0.8.4_released.rst
new file mode 100644
index 00000000..7e597c86
--- /dev/null
+++ b/i2p2www/blog/2011/03/02/I2P_0.8.4_released.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 %}
 <p>
 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
 </pre>
 </p>
-{% endblock %}
diff --git a/i2p2www/blog/2011/04/18/I2P_0.8.5_released.rst b/i2p2www/blog/2011/04/18/I2P_0.8.5_released.rst
new file mode 100644
index 00000000..f70e5314
--- /dev/null
+++ b/i2p2www/blog/2011/04/18/I2P_0.8.5_released.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 %}
 <p>
 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
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/05/16/I2P_0.8.6_released.rst b/i2p2www/blog/2011/05/16/I2P_0.8.6_released.rst
new file mode 100644
index 00000000..30f3696c
--- /dev/null
+++ b/i2p2www/blog/2011/05/16/I2P_0.8.6_released.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 %}
 <p>
 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:
 
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/06/06/Ipredator_Summer_of_Code.rst b/i2p2www/blog/2011/06/06/Ipredator_Summer_of_Code.rst
new file mode 100644
index 00000000..54f9edfb
--- /dev/null
+++ b/i2p2www/blog/2011/06/06/Ipredator_Summer_of_Code.rst
@@ -0,0 +1,6 @@
+========================
+ViaEuropa Summer of Code
+========================
+
+.. raw:: html
+   :file: blog/2011/06/06/release-summerofcode-2011.html
diff --git a/www.i2p2/pages/summerofcode-2011.html b/i2p2www/blog/2011/06/06/summerofcode-2011.html
similarity index 87%
rename from www.i2p2/pages/summerofcode-2011.html
rename to i2p2www/blog/2011/06/06/summerofcode-2011.html
index 9f39a577..64d6cfa2 100644
--- a/www.i2p2/pages/summerofcode-2011.html
+++ b/i2p2www/blog/2011/06/06/summerofcode-2011.html
@@ -1,8 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}ViaEuropa Summer of Code{% endblock %}
-{% block content %}
-
-
 <p>Ipredator Summer of Code</p>
 
 <p>
@@ -16,4 +11,3 @@ Current information can be found on <a href="http://zzz.i2p.to/topics/888">zzz's
 
 <p>Cheers
 <br>// hottuna (or Robert)</p>
-{% endblock %}
diff --git a/i2p2www/blog/2011/06/27/I2P_0.8.7_released.rst b/i2p2www/blog/2011/06/27/I2P_0.8.7_released.rst
new file mode 100644
index 00000000..2a22c0d6
--- /dev/null
+++ b/i2p2www/blog/2011/06/27/I2P_0.8.7_released.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 %}
-
 <p>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.</p>
@@ -101,5 +97,3 @@ SHA256 Checksums:
      cad2233ec477fb4455ce90283a5d4a18dda17d312a818d6ae1276358cb2f55a5  i2pupdate.sud
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/08/23/I2P_0.8.8_released.rst b/i2p2www/blog/2011/08/23/I2P_0.8.8_released.rst
new file mode 100644
index 00000000..7eb72a6f
--- /dev/null
+++ b/i2p2www/blog/2011/08/23/I2P_0.8.8_released.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 %}
-
 <p>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:
 
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/09/03/Ipredator_Summer_of_Code_-_itoopie_released.rst b/i2p2www/blog/2011/09/03/Ipredator_Summer_of_Code_-_itoopie_released.rst
new file mode 100644
index 00000000..6feb49b3
--- /dev/null
+++ b/i2p2www/blog/2011/09/03/Ipredator_Summer_of_Code_-_itoopie_released.rst
@@ -0,0 +1,6 @@
+========================
+Ipredator Summer of Code
+========================
+
+.. raw:: html
+   :file: blog/2011/09/03/release-summerofcode-2011-end.html
diff --git a/www.i2p2/pages/summerofcode-2011-end.html b/i2p2www/blog/2011/09/03/summerofcode-2011-end.html
similarity index 89%
rename from www.i2p2/pages/summerofcode-2011-end.html
rename to i2p2www/blog/2011/09/03/summerofcode-2011-end.html
index 0dc9696c..2cf80704 100644
--- a/www.i2p2/pages/summerofcode-2011-end.html
+++ b/i2p2www/blog/2011/09/03/summerofcode-2011-end.html
@@ -1,8 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}Ipredator Summer of Code{% endblock %}
-{% block content %}
-
-
 <p>itoopie and I2PControl are launching!</p>
 
 <p>I'm happy to announce that itoopie and I2PControl are available publicly.</p>
@@ -18,7 +13,3 @@ This project has been funded by the VPN services <a href="http://relakks.com">Re
 
 <p>Thank you Jan-Erik and Peter,
 <br>// hottuna</p>
-{% endblock %}
-
-
-
diff --git a/i2p2www/blog/2011/10/11/I2P_0.8.9_released.rst b/i2p2www/blog/2011/10/11/I2P_0.8.9_released.rst
new file mode 100644
index 00000000..5d9aba89
--- /dev/null
+++ b/i2p2www/blog/2011/10/11/I2P_0.8.9_released.rst
@@ -0,0 +1,6 @@
+=============
+0.8.9 Release
+=============
+
+.. raw:: html
+   :file: blog/2011/10/11/release-0.8.9.html
diff --git a/www.i2p2/pages/release-0.8.9.html b/i2p2www/blog/2011/10/11/release-0.8.9.html
similarity index 97%
rename from www.i2p2/pages/release-0.8.9.html
rename to i2p2www/blog/2011/10/11/release-0.8.9.html
index be14fac5..6dd08056 100644
--- a/www.i2p2/pages/release-0.8.9.html
+++ b/i2p2www/blog/2011/10/11/release-0.8.9.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.9 Release{% endblock %}
-{% block content %}
-
 <p>
 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
@@ -84,5 +80,3 @@ SHA256 Checksums:
 
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/10/20/I2P_0.8.10_released.rst b/i2p2www/blog/2011/10/20/I2P_0.8.10_released.rst
new file mode 100644
index 00000000..df618c90
--- /dev/null
+++ b/i2p2www/blog/2011/10/20/I2P_0.8.10_released.rst
@@ -0,0 +1,6 @@
+=============
+0.8.10 Release
+=============
+
+.. raw:: html
+   :file: blog/2011/10/20/release-0.8.10.html
diff --git a/www.i2p2/pages/release-0.8.10.html b/i2p2www/blog/2011/10/20/release-0.8.10.html
similarity index 92%
rename from www.i2p2/pages/release-0.8.10.html
rename to i2p2www/blog/2011/10/20/release-0.8.10.html
index 82373a0e..454e5fe1 100644
--- a/www.i2p2/pages/release-0.8.10.html
+++ b/i2p2www/blog/2011/10/20/release-0.8.10.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.10 Release{% endblock %}
-{% block content %}
-
 <p>
 
 Release 0.8.10 includes two changes intended to reduce the number of router-to-router connections,
@@ -44,5 +40,3 @@ SHA256 Checksums:
 
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2011/11/08/I2P_0.8.11_released.rst b/i2p2www/blog/2011/11/08/I2P_0.8.11_released.rst
new file mode 100644
index 00000000..fb3bb2b8
--- /dev/null
+++ b/i2p2www/blog/2011/11/08/I2P_0.8.11_released.rst
@@ -0,0 +1,6 @@
+=============
+0.8.11 Release
+=============
+
+.. raw:: html
+   :file: blog/2011/11/07/release-0.8.11.html
diff --git a/www.i2p2/pages/release-0.8.11.html b/i2p2www/blog/2011/11/08/release-0.8.11.html
similarity index 95%
rename from www.i2p2/pages/release-0.8.11.html
rename to i2p2www/blog/2011/11/08/release-0.8.11.html
index 7aa5a25c..1033f1b8 100644
--- a/www.i2p2/pages/release-0.8.11.html
+++ b/i2p2www/blog/2011/11/08/release-0.8.11.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.11 Release{% endblock %}
-{% block content %}
-
 <p>
 As you all have noticed, the unprecedented network growth starting October 5th
 has dramatically increased network congestion, especially on evenings (UTC)
@@ -61,5 +57,3 @@ SHA256 Checksums:
 
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2012/01/06/I2P_0.8.12_released.rst b/i2p2www/blog/2012/01/06/I2P_0.8.12_released.rst
new file mode 100644
index 00000000..949b5f31
--- /dev/null
+++ b/i2p2www/blog/2012/01/06/I2P_0.8.12_released.rst
@@ -0,0 +1,6 @@
+=============
+0.8.12 Release
+=============
+
+.. raw:: html
+   :file: blog/2012/01/06/release-0.8.12.html
diff --git a/www.i2p2/pages/release-0.8.12.html b/i2p2www/blog/2012/01/06/release-0.8.12.html
similarity index 97%
rename from www.i2p2/pages/release-0.8.12.html
rename to i2p2www/blog/2012/01/06/release-0.8.12.html
index f97f2cbe..df8a19d4 100644
--- a/www.i2p2/pages/release-0.8.12.html
+++ b/i2p2www/blog/2012/01/06/release-0.8.12.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.12 Release{% endblock %}
-{% block content %}
-
 <p>
 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
@@ -93,5 +89,3 @@ SHA256 Checksums:
     491722ef1a641512fc3bbaf825d5d1671b701e32b1298572f2820ab7fbf9851d  i2pupdate.sud
 
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2012/02/27/I2P_0.8.13_released.rst b/i2p2www/blog/2012/02/27/I2P_0.8.13_released.rst
new file mode 100644
index 00000000..e09af2f4
--- /dev/null
+++ b/i2p2www/blog/2012/02/27/I2P_0.8.13_released.rst
@@ -0,0 +1,6 @@
+=============
+0.8.13 Release
+=============
+
+.. raw:: html
+   :file: blog/2012/02/27/release-0.8.13.html
diff --git a/www.i2p2/pages/release-0.8.13.html b/i2p2www/blog/2012/02/27/release-0.8.13.html
similarity index 97%
rename from www.i2p2/pages/release-0.8.13.html
rename to i2p2www/blog/2012/02/27/release-0.8.13.html
index 2c6f4ad6..812565ef 100644
--- a/www.i2p2/pages/release-0.8.13.html
+++ b/i2p2www/blog/2012/02/27/release-0.8.13.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.8.13 Release{% endblock %}
-{% block content %}
-
 <p>
 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,
@@ -79,5 +75,3 @@ SHA256 Checksums:
     81fa5256250fde2790153b83d2b01b6bc3b5ee7ea1b4d12232ce46f06ae736ef  i2pupdate.su2
     2eb25974ebfeeeec59d8138e42d5663d97cc24b94f2c6cf77cfe6dc991acf0bb  i2pupdate.sud
 </pre>
-
-{% endblock %}
diff --git a/i2p2www/blog/2012/05/02/I2P_0.9_released.rst b/i2p2www/blog/2012/05/02/I2P_0.9_released.rst
new file mode 100644
index 00000000..6f5d9c09
--- /dev/null
+++ b/i2p2www/blog/2012/05/02/I2P_0.9_released.rst
@@ -0,0 +1,6 @@
+=============
+0.9 Release
+=============
+
+.. raw:: html
+   :file: blog/2012/05/03/release-0.9.html
diff --git a/www.i2p2/pages/release-0.9.html b/i2p2www/blog/2012/05/02/release-0.9.html
similarity index 97%
rename from www.i2p2/pages/release-0.9.html
rename to i2p2www/blog/2012/05/02/release-0.9.html
index 20f3aeb3..54c5b5bf 100644
--- a/www.i2p2/pages/release-0.9.html
+++ b/i2p2www/blog/2012/05/02/release-0.9.html
@@ -1,7 +1,3 @@
-{% extends "_layout.html" %}
-{% block title %}0.9 Release{% endblock %}
-{% block content %}
-
 <p>
 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
@@ -109,5 +105,3 @@ SHA256 Checksums:
 
 
 </pre>
-
-{% endblock %}

From 63133d532b33de6b31307e94f00049627ebff4c3 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Wed, 19 Sep 2012 14:11:41 +0000
Subject: [PATCH 72/75] Convert underscores to spaces when using blog entry
 slugs as link text

---
 i2p2www/__init__.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py
index e5c29ebc..b810ca9d 100644
--- a/i2p2www/__init__.py
+++ b/i2p2www/__init__.py
@@ -310,7 +310,8 @@ def blog_index(page=0):
     entries= []
     for slug in slugs:
         date = get_date_from_slug(slug)
-        title = slug.rsplit('/', 1)[1]
+        titlepart = slug.rsplit('/', 1)[1]
+        title = ' '.join(titlepart.split('_'))
         entries.append((slug, date, title))
 
     return render_template('blog/index.html', entries=entries)

From 68dce484667cd6e6cc5982910c682884de852f2b Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Wed, 19 Sep 2012 14:16:26 +0000
Subject: [PATCH 73/75] Updated link to status notes on meetings index ->
 points to blog now

---
 i2p2www/pages/meetings/index.html | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html
index c475889e..c8e90820 100644
--- a/i2p2www/pages/meetings/index.html
+++ b/i2p2www/pages/meetings/index.html
@@ -4,7 +4,7 @@
 <h1>Logs of past I2P meetings</h1>
 <p>Regularly scheduled meetings are not being held at this time.
 If you have something to discuss, please find the developers on IRC in #i2p-dev.
-<a href="statusnotes.html">Status updates</a> from developers are also available.
+<a href="{{ url_for('blog_index', lang=g.lang) }}">Status updates</a> from developers are also available.
 </p><div class="underline"></div>
 <ul class="infolist">
 {%- macro meeting_url(m_id) -%}{{ url_for('meetings_show', lang=g.lang, id=m_id) }}{%- endmacro -%}

From ac73c8ee217774e49242301cc95c29622c4c0ece Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 20 Sep 2012 00:52:27 +0000
Subject: [PATCH 74/75] Moved old translations into a separate directory

---
 www.i2p2/pages/{ => translations}/_layout_ar.html                | 0
 www.i2p2/pages/{ => translations}/_layout_cs.html                | 0
 www.i2p2/pages/{ => translations}/_layout_de.html                | 0
 www.i2p2/pages/{ => translations}/_layout_es.html                | 0
 www.i2p2/pages/{ => translations}/_layout_fr.html                | 0
 www.i2p2/pages/{ => translations}/_layout_it.html                | 0
 www.i2p2/pages/{ => translations}/_layout_nl.html                | 0
 www.i2p2/pages/{ => translations}/_layout_ru.html                | 0
 www.i2p2/pages/{ => translations}/_layout_zh.html                | 0
 www.i2p2/pages/{ => translations}/announcements_ar.html          | 0
 www.i2p2/pages/{ => translations}/announcements_de.html          | 0
 www.i2p2/pages/{ => translations}/announcements_fr.html          | 0
 www.i2p2/pages/{ => translations}/announcements_it.html          | 0
 www.i2p2/pages/{ => translations}/api_de.html                    | 0
 www.i2p2/pages/{ => translations}/api_it.html                    | 0
 www.i2p2/pages/{ => translations}/bittorrent_fr.html             | 0
 www.i2p2/pages/{ => translations}/bounties_ar.html               | 0
 www.i2p2/pages/{ => translations}/bounties_de.html               | 0
 www.i2p2/pages/{ => translations}/bounties_it.html               | 0
 www.i2p2/pages/{ => translations}/bounties_ru.html               | 0
 www.i2p2/pages/{ => translations}/bounty_arabic_de.html          | 0
 www.i2p2/pages/{ => translations}/bounty_datastore_de.html       | 0
 www.i2p2/pages/{ => translations}/bounty_datastore_ru.html       | 0
 www.i2p2/pages/{ => translations}/bounty_debpack_de.html         | 0
 www.i2p2/pages/{ => translations}/bounty_i2phex_de.html          | 0
 www.i2p2/pages/{ => translations}/bounty_i2phex_ru.html          | 0
 www.i2p2/pages/{ => translations}/bounty_ipv6_de.html            | 0
 www.i2p2/pages/{ => translations}/bounty_ipv6_ru.html            | 0
 www.i2p2/pages/{ => translations}/bounty_rutrans_de.html         | 0
 www.i2p2/pages/{ => translations}/bounty_rutrans_ru.html         | 0
 www.i2p2/pages/{ => translations}/bounty_unittests_de.html       | 0
 www.i2p2/pages/{ => translations}/bounty_vuzeplugin_de.html      | 0
 www.i2p2/pages/{ => translations}/bounty_vuzeplugin_ru.html      | 0
 www.i2p2/pages/{ => translations}/clt_de.html                    | 0
 www.i2p2/pages/{ => translations}/cvs_de.html                    | 0
 www.i2p2/pages/{ => translations}/datagrams_de.html              | 0
 www.i2p2/pages/{ => translations}/debian_fr.html                 | 0
 www.i2p2/pages/{ => translations}/donate_ar.html                 | 0
 www.i2p2/pages/{ => translations}/donate_de.html                 | 0
 www.i2p2/pages/{ => translations}/donate_fr.html                 | 0
 www.i2p2/pages/{ => translations}/donate_ru.html                 | 0
 www.i2p2/pages/{ => translations}/download_ar.html               | 0
 www.i2p2/pages/{ => translations}/download_cs.html               | 0
 www.i2p2/pages/{ => translations}/download_de.html               | 0
 www.i2p2/pages/{ => translations}/download_es.html               | 0
 www.i2p2/pages/{ => translations}/download_fr.html               | 0
 www.i2p2/pages/{ => translations}/download_ru.html               | 0
 www.i2p2/pages/{ => translations}/download_zh.html               | 0
 www.i2p2/pages/{ => translations}/faq_ar.html                    | 0
 www.i2p2/pages/{ => translations}/faq_de.html                    | 0
 www.i2p2/pages/{ => translations}/faq_fr.html                    | 0
 www.i2p2/pages/{ => translations}/faq_zh.html                    | 0
 www.i2p2/pages/{ => translations}/getinvolved_ar.html            | 0
 www.i2p2/pages/{ => translations}/getinvolved_de.html            | 0
 www.i2p2/pages/{ => translations}/getinvolved_fr.html            | 0
 www.i2p2/pages/{ => translations}/getinvolved_ru.html            | 0
 www.i2p2/pages/{ => translations}/halloffame_de.html             | 0
 www.i2p2/pages/{ => translations}/how_cryptography_de.html       | 0
 www.i2p2/pages/{ => translations}/how_de.html                    | 0
 www.i2p2/pages/{ => translations}/how_elgamalaes_de.html         | 0
 www.i2p2/pages/{ => translations}/how_fr.html                    | 0
 www.i2p2/pages/{ => translations}/how_garlicrouting_de.html      | 0
 www.i2p2/pages/{ => translations}/how_networkcomparisons_fr.html | 0
 www.i2p2/pages/{ => translations}/how_peerselection_de.html      | 0
 www.i2p2/pages/{ => translations}/how_threatmodel_fr.html        | 0
 www.i2p2/pages/{ => translations}/htproxyports_fr.html           | 0
 www.i2p2/pages/{ => translations}/i2np_de.html                   | 0
 www.i2p2/pages/{ => translations}/impressum_de.html              | 0
 www.i2p2/pages/{ => translations}/index_ar.html                  | 0
 www.i2p2/pages/{ => translations}/index_cs.html                  | 0
 www.i2p2/pages/{ => translations}/index_de.html                  | 0
 www.i2p2/pages/{ => translations}/index_es.html                  | 0
 www.i2p2/pages/{ => translations}/index_fr.html                  | 0
 www.i2p2/pages/{ => translations}/index_it.html                  | 0
 www.i2p2/pages/{ => translations}/index_nl.html                  | 0
 www.i2p2/pages/{ => translations}/index_ru.html                  | 0
 www.i2p2/pages/{ => translations}/index_zh.html                  | 0
 www.i2p2/pages/{ => translations}/installation_de.html           | 0
 www.i2p2/pages/{ => translations}/installation_zh.html           | 0
 www.i2p2/pages/{ => translations}/intro_ar.html                  | 0
 www.i2p2/pages/{ => translations}/intro_fr.html                  | 0
 www.i2p2/pages/{ => translations}/intro_ru.html                  | 0
 www.i2p2/pages/{ => translations}/invisiblenet_de.html           | 0
 www.i2p2/pages/{ => translations}/jbigi_de.html                  | 0
 www.i2p2/pages/{ => translations}/jrandom-awol_de.html           | 0
 www.i2p2/pages/{ => translations}/license-agreements_de.html     | 0
 www.i2p2/pages/{ => translations}/licenses_de.html               | 0
 www.i2p2/pages/{ => translations}/links_de.html                  | 0
 www.i2p2/pages/{ => translations}/links_fr.html                  | 0
 www.i2p2/pages/{ => translations}/links_zh.html                  | 0
 www.i2p2/pages/{ => translations}/meetings_de.html               | 0
 www.i2p2/pages/{ => translations}/meetings_fr.html               | 0
 www.i2p2/pages/{ => translations}/naming_fr.html                 | 0
 www.i2p2/pages/{ => translations}/newdevelopers_de.html          | 0
 www.i2p2/pages/{ => translations}/newdevelopers_fr.html          | 0
 www.i2p2/pages/{ => translations}/newdevelopers_it.html          | 0
 www.i2p2/pages/{ => translations}/newtranslators_fr.html         | 0
 www.i2p2/pages/{ => translations}/papers_fr.html                 | 0
 www.i2p2/pages/{ => translations}/plugin_spec_de.html            | 0
 www.i2p2/pages/{ => translations}/plugin_spec_fr.html            | 0
 www.i2p2/pages/{ => translations}/plugins_de.html                | 0
 www.i2p2/pages/{ => translations}/plugins_fr.html                | 0
 www.i2p2/pages/{ => translations}/protocols_de.html              | 0
 www.i2p2/pages/{ => translations}/protocols_fr.html              | 0
 www.i2p2/pages/{ => translations}/release-0.7.8_zh.html          | 0
 www.i2p2/pages/{ => translations}/release-0.8.4_fr.html          | 0
 www.i2p2/pages/{ => translations}/release-0.8.5_fr.html          | 0
 www.i2p2/pages/{ => translations}/release-0.8.6_fr.html          | 0
 www.i2p2/pages/{ => translations}/release-0.8.7_fr.html          | 0
 www.i2p2/pages/{ => translations}/roadmap_de.html                | 0
 www.i2p2/pages/{ => translations}/roadmap_fr.html                | 0
 www.i2p2/pages/{ => translations}/summerofcode-2011_fr.html      | 0
 www.i2p2/pages/{ => translations}/team_de.html                   | 0
 www.i2p2/pages/{ => translations}/team_fr.html                   | 0
 www.i2p2/pages/{ => translations}/techintro_fr.html              | 0
 www.i2p2/pages/{ => translations}/todo_de.html                   | 0
 www.i2p2/pages/{ => translations}/todo_fr.html                   | 0
 www.i2p2/pages/{ => translations}/updates_de.html                | 0
 118 files changed, 0 insertions(+), 0 deletions(-)
 rename www.i2p2/pages/{ => translations}/_layout_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_cs.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_de.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_es.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_it.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_nl.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/_layout_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/announcements_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/announcements_de.html (100%)
 rename www.i2p2/pages/{ => translations}/announcements_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/announcements_it.html (100%)
 rename www.i2p2/pages/{ => translations}/api_de.html (100%)
 rename www.i2p2/pages/{ => translations}/api_it.html (100%)
 rename www.i2p2/pages/{ => translations}/bittorrent_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/bounties_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/bounties_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounties_it.html (100%)
 rename www.i2p2/pages/{ => translations}/bounties_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_arabic_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_datastore_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_datastore_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_debpack_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_i2phex_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_i2phex_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_ipv6_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_ipv6_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_rutrans_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_rutrans_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_unittests_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_vuzeplugin_de.html (100%)
 rename www.i2p2/pages/{ => translations}/bounty_vuzeplugin_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/clt_de.html (100%)
 rename www.i2p2/pages/{ => translations}/cvs_de.html (100%)
 rename www.i2p2/pages/{ => translations}/datagrams_de.html (100%)
 rename www.i2p2/pages/{ => translations}/debian_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/donate_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/donate_de.html (100%)
 rename www.i2p2/pages/{ => translations}/donate_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/donate_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/download_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/download_cs.html (100%)
 rename www.i2p2/pages/{ => translations}/download_de.html (100%)
 rename www.i2p2/pages/{ => translations}/download_es.html (100%)
 rename www.i2p2/pages/{ => translations}/download_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/download_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/download_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/faq_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/faq_de.html (100%)
 rename www.i2p2/pages/{ => translations}/faq_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/faq_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/getinvolved_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/getinvolved_de.html (100%)
 rename www.i2p2/pages/{ => translations}/getinvolved_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/getinvolved_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/halloffame_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_cryptography_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_elgamalaes_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/how_garlicrouting_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_networkcomparisons_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/how_peerselection_de.html (100%)
 rename www.i2p2/pages/{ => translations}/how_threatmodel_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/htproxyports_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/i2np_de.html (100%)
 rename www.i2p2/pages/{ => translations}/impressum_de.html (100%)
 rename www.i2p2/pages/{ => translations}/index_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/index_cs.html (100%)
 rename www.i2p2/pages/{ => translations}/index_de.html (100%)
 rename www.i2p2/pages/{ => translations}/index_es.html (100%)
 rename www.i2p2/pages/{ => translations}/index_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/index_it.html (100%)
 rename www.i2p2/pages/{ => translations}/index_nl.html (100%)
 rename www.i2p2/pages/{ => translations}/index_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/index_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/installation_de.html (100%)
 rename www.i2p2/pages/{ => translations}/installation_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/intro_ar.html (100%)
 rename www.i2p2/pages/{ => translations}/intro_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/intro_ru.html (100%)
 rename www.i2p2/pages/{ => translations}/invisiblenet_de.html (100%)
 rename www.i2p2/pages/{ => translations}/jbigi_de.html (100%)
 rename www.i2p2/pages/{ => translations}/jrandom-awol_de.html (100%)
 rename www.i2p2/pages/{ => translations}/license-agreements_de.html (100%)
 rename www.i2p2/pages/{ => translations}/licenses_de.html (100%)
 rename www.i2p2/pages/{ => translations}/links_de.html (100%)
 rename www.i2p2/pages/{ => translations}/links_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/links_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/meetings_de.html (100%)
 rename www.i2p2/pages/{ => translations}/meetings_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/naming_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/newdevelopers_de.html (100%)
 rename www.i2p2/pages/{ => translations}/newdevelopers_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/newdevelopers_it.html (100%)
 rename www.i2p2/pages/{ => translations}/newtranslators_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/papers_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/plugin_spec_de.html (100%)
 rename www.i2p2/pages/{ => translations}/plugin_spec_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/plugins_de.html (100%)
 rename www.i2p2/pages/{ => translations}/plugins_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/protocols_de.html (100%)
 rename www.i2p2/pages/{ => translations}/protocols_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/release-0.7.8_zh.html (100%)
 rename www.i2p2/pages/{ => translations}/release-0.8.4_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/release-0.8.5_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/release-0.8.6_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/release-0.8.7_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/roadmap_de.html (100%)
 rename www.i2p2/pages/{ => translations}/roadmap_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/summerofcode-2011_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/team_de.html (100%)
 rename www.i2p2/pages/{ => translations}/team_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/techintro_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/todo_de.html (100%)
 rename www.i2p2/pages/{ => translations}/todo_fr.html (100%)
 rename www.i2p2/pages/{ => translations}/updates_de.html (100%)

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_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_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_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_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_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_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_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_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_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_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/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

From 00ef914a5aa9cc94c6171a09e450df2f182c785b Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 20 Sep 2012 00:56:40 +0000
Subject: [PATCH 75/75] Migrated over impressum.html

---
 i2p2www/pages/global/footer.html                      | 2 +-
 {www.i2p2/pages => i2p2www/pages/site}/impressum.html | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename {www.i2p2/pages => i2p2www/pages/site}/impressum.html (76%)

diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html
index f131c9c9..3b3ff3b5 100644
--- a/i2p2www/pages/global/footer.html
+++ b/i2p2www/pages/global/footer.html
@@ -32,7 +32,7 @@
         <ul>
           <li><a href="http://syndie.i2p2.de/">Syndie</a></li>
           <li><a href="links.html">{{ _('Links') }}</a></li>
-          <li><a href="impressum.html">{{ _('Impressum') }}</a></li>
+          <li><a href="{{ site_url('impressum') }}">{{ _('Impressum') }}</a></li>
         </ul>
       </div>
       <div class='aside sixth'>
diff --git a/www.i2p2/pages/impressum.html b/i2p2www/pages/site/impressum.html
similarity index 76%
rename from www.i2p2/pages/impressum.html
rename to i2p2www/pages/site/impressum.html
index cdfdcc28..8afeb302 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 %}
   <p>[German laws...]</p>
   <p>Tassilo Schweyer<br />
     Weitfelderweg 8b<br />
     89275 Elchingen</p>
-{% endblock %}
\ No newline at end of file
+{% endblock %}