From ed19b23c9242378de1cc9e279029da5b9c073945 Mon Sep 17 00:00:00 2001 From: duck Date: Sat, 31 Jul 2010 15:24:13 +0000 Subject: [PATCH 001/498] 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 }}

- -
- {% 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 002/498] 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 003/498] 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 004/498] 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 005/498] 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 - - + + -

{{ title }}

+

{{ self.title() }}

{% 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 006/498] 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 %} - + diff --git a/www.i2p2/pages/bounty_syndie2012.html b/i2p2www/pages/site/volunteer/bounties/syndie2012.html similarity index 96% rename from www.i2p2/pages/bounty_syndie2012.html rename to i2p2www/pages/site/volunteer/bounties/syndie2012.html index c9e0e807..5c3f0980 100644 --- a/www.i2p2/pages/bounty_syndie2012.html +++ b/i2p2www/pages/site/volunteer/bounties/syndie2012.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Syndie development{% endblock %} {% block content %} diff --git a/www.i2p2/pages/bounty_syndie2012_de.html b/www.i2p2/pages/translations/bounty_syndie2012_de.html similarity index 100% rename from www.i2p2/pages/bounty_syndie2012_de.html rename to www.i2p2/pages/translations/bounty_syndie2012_de.html From 8b608ea750cefc13672bf5c4ec7e41518769a86c Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 05:18:40 +0000 Subject: [PATCH 157/498] Prepare meetings_index() for pagination --- i2p2www/__init__.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 82dac44f..517844f6 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -265,7 +265,8 @@ def render_meeting_rst(id): # Meeting index @app.route('//meetings/') -def meetings_index(): +@app.route('//meetings/page/') +def meetings_index(page=0): meetings = get_meetings() return render_template('meetings/index.html', meetings=meetings) From 3f19792df777cce555236a299b0796d68e163e0a Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 05:27:03 +0000 Subject: [PATCH 158/498] Use Werkzeug route level defaults to ensure unique urls --- i2p2www/__init__.py | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 517844f6..74f924fb 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -165,9 +165,9 @@ def main_index(): return redirect(url_for('site_show', lang='en')) # Site pages -@app.route('//site/') +@app.route('//site/', defaults={'page': 'index'}) @app.route('//site/') -def site_show(page='index'): +def site_show(page): if page.endswith('.html'): return redirect(url_for('site_show', page=page[:-5])) name = 'site/%s.html' % page @@ -264,9 +264,9 @@ def render_meeting_rst(id): # Meeting handlers # Meeting index -@app.route('//meetings/') +@app.route('//meetings/', defaults={'page': 1}) @app.route('//meetings/page/') -def meetings_index(page=0): +def meetings_index(page): meetings = get_meetings() return render_template('meetings/index.html', meetings=meetings) @@ -384,9 +384,9 @@ def downloads_select(file): obj.append(a) return render_template('downloads/select.html', mirrors=obj, file=file) -@app.route('/download//any/') +@app.route('/download//any/', defaults={'mirror': None}) @app.route('/download///') -def downloads_redirect(protocol, file, mirror=None): +def downloads_redirect(protocol, file, mirror): mirrors=read_mirrors() if not protocol in mirrors: abort(404) @@ -473,9 +473,9 @@ def render_blog_entry(slug): ############### # Blog handlers -@app.route('//blog/') +@app.route('//blog/', defaults={'page': 1}) @app.route('//blog/page/') -def blog_index(page=0): +def blog_index(page): entries = get_blog_entries() return render_template('blog/index.html', entries=entries) From fe76f20f0c4cdd880ca82aa868bb76d43500c237 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 06:26:21 +0000 Subject: [PATCH 159/498] Implemented pagination for meetings and blog entries --- i2p2www/__init__.py | 41 +++++++++++++++++++++++++------ i2p2www/helpers.py | 32 ++++++++++++++++++++++++ i2p2www/pages/blog/index.html | 2 ++ i2p2www/pages/global/macros | 26 ++++++++++++++++++++ i2p2www/pages/meetings/index.html | 2 ++ 5 files changed, 96 insertions(+), 7 deletions(-) create mode 100644 i2p2www/helpers.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 74f924fb..c8d98b11 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -14,6 +14,7 @@ try: except ImportError: import simplejson as json +from helpers import Pagination TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages') STATIC_DIR = os.path.join(os.path.dirname(__file__), 'static') @@ -21,6 +22,9 @@ 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') +BLOG_ENTRIES_PER_PAGE = 20 +MEETINGS_PER_PAGE = 20 + MIRRORS_FILE = os.path.join(TEMPLATE_DIR, 'downloads/mirrors') app = application = Flask('i2p2www', template_folder=TEMPLATE_DIR, static_url_path='/_static', static_folder=STATIC_DIR) @@ -141,7 +145,15 @@ def utility_processor(): except KeyError: # The I2P site has no known clearnet address, so use an inproxy return value + '.to' - return dict(i2pconv=convert_url_to_clearnet) + + # Convert a paginated URL to that of another page + def url_for_other_page(page): + args = request.view_args.copy() + args['page'] = page + return url_for(request.endpoint, **args) + + return dict(i2pconv=convert_url_to_clearnet, + url_for_other_page=url_for_other_page) ################ @@ -156,6 +168,15 @@ def server_error(error): return render_template('global/error_500.html'), 500 +######################## +# General helper methods + +def get_for_page(items, page, per_page): + from_item = (page-1)*per_page + to_item = page*per_page + return items[from_item:to_item] + + ####################### # General page handlers @@ -267,9 +288,12 @@ def render_meeting_rst(id): @app.route('//meetings/', defaults={'page': 1}) @app.route('//meetings/page/') def meetings_index(page): - meetings = get_meetings() - - return render_template('meetings/index.html', meetings=meetings) + all_meetings = get_meetings() + meetings = get_for_page(all_meetings, page, MEETINGS_PER_PAGE) + if not meetings and page != 1: + abort(404) + pagination = Pagination(page, MEETINGS_PER_PAGE, len(all_meetings)) + return render_template('meetings/index.html', pagination=pagination, meetings=meetings) # Renderer for specific meetings @app.route('//meetings/') @@ -476,9 +500,12 @@ def render_blog_entry(slug): @app.route('//blog/', defaults={'page': 1}) @app.route('//blog/page/') def blog_index(page): - entries = get_blog_entries() - - return render_template('blog/index.html', entries=entries) + all_entries = get_blog_entries() + entries = get_for_page(all_entries, page, BLOG_ENTRIES_PER_PAGE) + if not entries and page != 1: + abort(404) + pagination = Pagination(page, BLOG_ENTRIES_PER_PAGE, len(all_entries)) + return render_template('blog/index.html', pagination=pagination, entries=entries) @app.route('//blog/entry/') def blog_entry(slug): diff --git a/i2p2www/helpers.py b/i2p2www/helpers.py new file mode 100644 index 00000000..bbd8a656 --- /dev/null +++ b/i2p2www/helpers.py @@ -0,0 +1,32 @@ +from math import ceil + +class Pagination(object): + def __init__(self, page, per_page, total_count): + self.page = page + self.per_page = per_page + self.total_count = total_count + + @property + def pages(self): + return int(ceil(self.total_count / float(self.per_page))) + + @property + def has_prev(self): + return self.page > 1 + + @property + def has_next(self): + return self.page < self.pages + + def iter_pages(self, left_edge=2, left_current=2, + right_current=5, right_edge=2): + last = 0 + for num in xrange(1, self.pages + 1): + if num <= left_edge or \ + (num > self.page - left_current - 1 and \ + num < self.page + right_current) or \ + num > self.pages - right_edge: + if last + 1 != num: + yield None + yield num + last = num diff --git a/i2p2www/pages/blog/index.html b/i2p2www/pages/blog/index.html index 2b8d7d05..06e99752 100644 --- a/i2p2www/pages/blog/index.html +++ b/i2p2www/pages/blog/index.html @@ -10,4 +10,6 @@
  • {{ entry[1] }} - {{ entry[2] }}
  • {%- endfor %} +{%- from "global/macros" import render_pagination with context -%} +{{ render_pagination(pagination) | safe }} {% endblock %} diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index 8fd460a6..a1470155 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -3,6 +3,7 @@ {%- 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) }} @@ -12,8 +13,33 @@ {%- else -%}{{ url_for('site_show', lang=lang) }} {%- endif -%} {%- endmacro -%} + {%- macro ver(string=None) -%} {%- if string -%}{{ string % '0.9.3' }} {%- else -%}{{ '0.9.3' }} {%- endif -%} {%- endmacro -%} + +{%- macro render_pagination(pagination) %} + +{%- endmacro -%} diff --git a/i2p2www/pages/meetings/index.html b/i2p2www/pages/meetings/index.html index 0046b71b..8ca96792 100644 --- a/i2p2www/pages/meetings/index.html +++ b/i2p2www/pages/meetings/index.html @@ -15,4 +15,6 @@
  • Meeting {{ meeting['id'] }}{% if meeting['date'] %} - {{ meeting['date'].strftime("%B %d, %Y") }}{% endif %}
  • {%- endfor %} +{%- from "global/macros" import render_pagination with context -%} +{{ render_pagination(pagination) | safe }} {% endblock %} From 3284f92ae34866087f4579b93f9c1965ad2656db Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 07:56:28 +0000 Subject: [PATCH 160/498] New heading for middle column of front page --- i2p2www/pages/site/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html index 7f51efdc..0888c0ee 100644 --- a/i2p2www/pages/site/index.html +++ b/i2p2www/pages/site/index.html @@ -19,7 +19,7 @@
    -

    {{ _('Supported Software') }}

    +

    {{ _('What can you do with I2P?') }}

    • Email Integrated web mail interface, plugin for serverless email. From d129c789671cadee7776ea2f8176683097db5af0 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 08:00:02 +0000 Subject: [PATCH 161/498] "anonymously on I2P." -> "anonymously inside I2P." --- i2p2www/pages/site/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html index 0888c0ee..3c1fd9f5 100644 --- a/i2p2www/pages/site/index.html +++ b/i2p2www/pages/site/index.html @@ -3,7 +3,7 @@ {% block content_outer %}

      {% trans %}What does I2P do for you?{% endtrans %}

      -

      {% 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 %}

      +

      {% trans %}The I2P network provides strong privacy protections for communication over the Internet. Many activities that would risk your privacy on the public Internet can be conducted anonymously inside I2P.{% endtrans %}

      {% trans version=ver() %}Get I2P {{ version }}{% endtrans %}
      From 2bc59701cb33d333e6b248eecb494e890787481f Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 21:39:59 +0000 Subject: [PATCH 162/498] Added missing lu flag --- i2p2www/static/images/lu.png | Bin 0 -> 481 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 i2p2www/static/images/lu.png diff --git a/i2p2www/static/images/lu.png b/i2p2www/static/images/lu.png new file mode 100644 index 0000000000000000000000000000000000000000..4cabba98ae70837922beadc41453b5f848f03854 GIT binary patch literal 481 zcmV<70UrK|P)?-#?r-wgj45C|ZESQtLMVW?~Zs{a4) zALIXj41fOq2a1uNeOQW%&E= z|DQh$fB%40fEE4z10q3;-;ClCKpOx8h=su~@}N>;ErcnO|V^hXG82+5i4Q+5aFU0|N&GK!5=N X;lz1sunOP500000NkvXXu0mjf*7env literal 0 HcmV?d00001 From cd5adeb8593cb1929cac1634d1b709d80d122b32 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 21:47:01 +0000 Subject: [PATCH 163/498] Reorganized flags and removed duplicates --- i2p2www/pages/downloads/select.html | 2 +- i2p2www/pages/global/lang.html | 24 +++++++++++------------ i2p2www/static/images/cz.png | Bin 476 -> 0 bytes i2p2www/static/images/{ => flags}/ar.png | Bin i2p2www/static/images/{ => flags}/cs.png | Bin i2p2www/static/images/{ => flags}/de.png | Bin i2p2www/static/images/{ => flags}/el.png | Bin i2p2www/static/images/{ => flags}/es.png | Bin i2p2www/static/images/{ => flags}/eu.png | Bin i2p2www/static/images/{ => flags}/fr.png | Bin i2p2www/static/images/{ => flags}/it.png | Bin i2p2www/static/images/{ => flags}/lu.png | Bin i2p2www/static/images/{ => flags}/nl.png | Bin i2p2www/static/images/{ => flags}/ru.png | Bin i2p2www/static/images/{ => flags}/sv.png | Bin i2p2www/static/images/{ => flags}/us.png | Bin i2p2www/static/images/{ => flags}/zh.png | Bin i2p2www/static/images/lang_ar.png | Bin 228 -> 0 bytes 18 files changed, 13 insertions(+), 13 deletions(-) delete mode 100644 i2p2www/static/images/cz.png rename i2p2www/static/images/{ => flags}/ar.png (100%) rename i2p2www/static/images/{ => flags}/cs.png (100%) rename i2p2www/static/images/{ => flags}/de.png (100%) rename i2p2www/static/images/{ => flags}/el.png (100%) rename i2p2www/static/images/{ => flags}/es.png (100%) rename i2p2www/static/images/{ => flags}/eu.png (100%) rename i2p2www/static/images/{ => flags}/fr.png (100%) rename i2p2www/static/images/{ => flags}/it.png (100%) rename i2p2www/static/images/{ => flags}/lu.png (100%) rename i2p2www/static/images/{ => flags}/nl.png (100%) rename i2p2www/static/images/{ => flags}/ru.png (100%) rename i2p2www/static/images/{ => flags}/sv.png (100%) rename i2p2www/static/images/{ => flags}/us.png (100%) rename i2p2www/static/images/{ => flags}/zh.png (100%) delete mode 100644 i2p2www/static/images/lang_ar.png diff --git a/i2p2www/pages/downloads/select.html b/i2p2www/pages/downloads/select.html index 3eaf46a9..2745a2b2 100644 --- a/i2p2www/pages/downloads/select.html +++ b/i2p2www/pages/downloads/select.html @@ -9,7 +9,7 @@
      diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html index 1a930207..8e3d6572 100644 --- a/i2p2www/pages/global/lang.html +++ b/i2p2www/pages/global/lang.html @@ -1,14 +1,14 @@
        -
      • English
      • -
      • Castellano
      • -
      • Chinese
      • -
      • Deutsch
      • -
      • Français
      • -
      • Italiano
      • -
      • Nederlands
      • -
      • Russian
      • -
      • Svenska
      • -
      • Czech
      • -
      • Arabic
      • -
      • Greek
      • +
      • English
      • +
      • Castellano
      • +
      • Chinese
      • +
      • Deutsch
      • +
      • Français
      • +
      • Italiano
      • +
      • Nederlands
      • +
      • Russian
      • +
      • Svenska
      • +
      • Czech
      • +
      • Arabic
      • +
      • Greek
      diff --git a/i2p2www/static/images/cz.png b/i2p2www/static/images/cz.png deleted file mode 100644 index c8403dd21fd15f46d501a766a7a97733462f3b22..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 476 zcmV<20VDp2P)? 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{sJ00004#3RcVi4%-E25xf8IheWCU;o|NGe2%p zDuXgJv$GiU{zvZ7l1EK%#kfcxXgQOZl8~Tb`)j7-pVRT5cz&Edav Date: Fri, 14 Dec 2012 21:51:45 +0000 Subject: [PATCH 164/498] Fixed custom theme loader --- i2p2www/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index c8d98b11..e512eb75 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -89,7 +89,7 @@ def detect_theme(): 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)): + if not os.path.isfile(safe_join(safe_join(STATIC_DIR, 'styles'), '%s.css' % theme)): theme = 'duck' g.theme = theme @after_this_request From 96df3373452da1e5716e4401be2bd0eee44f60cb Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 22:00:12 +0000 Subject: [PATCH 165/498] Tweak to (unused in default theme) mainmenu.css to detect the menu --- i2p2www/static/styles/mainmenu.css | 64 +++++++++++++++--------------- 1 file changed, 32 insertions(+), 32 deletions(-) diff --git a/i2p2www/static/styles/mainmenu.css b/i2p2www/static/styles/mainmenu.css index 9d410985..ea350e57 100644 --- a/i2p2www/static/styles/mainmenu.css +++ b/i2p2www/static/styles/mainmenu.css @@ -16,7 +16,7 @@ /*========================= TOP OF THE MENU CASCADE =========================*/ -.menu { +#cssmenu { position:relative; /* establish a menu-relative positioning context */ float:left; /* play nicely with others */ margin:0; @@ -25,17 +25,17 @@ height:24px; /* the menu's overall height */ } -.menu img { +#cssmenu img { vertical-align: top; /* prevent images from being pushed down by text */ } -.menu ul { +#cssmenu ul { margin:0; list-style-type:none; /* we don't want to view the list as a list */ line-height:1.5em; /* globally set the menu's item spacing. note */ } /* this must be 1.0 or 1.5 or 2.0 for Mozilla */ -.menu li { +#cssmenu li { float:left; /* this creates the side-by-side array of top-level buttons */ position:relative; /* create local positioning contexts for each button */ margin:0; @@ -62,13 +62,13 @@ /*======================== TOP LEVEL MENU DEFINITIONS ========================*/ -.menu ul li ul { +#cssmenu 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 */ +#cssmenu ul li a, +#cssmenu ul li a:visited { /* unselected top-level menu items */ display:block; float:left; text-decoration:none; @@ -77,8 +77,8 @@ /*======================== 2ND LEVEL MENU DEFINITIONS ========================*/ -.menu ul li:hover ul, -.menu ul li a:hover ul { /* 2nd level drop-down box */ +#cssmenu ul li:hover ul, +#cssmenu ul li a:hover ul { /* 2nd level drop-down box */ display:block; position:absolute; margin:0; @@ -90,29 +90,29 @@ 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 */ +#cssmenu ul li:hover ul.leftbutton, +#cssmenu 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 */ +#cssmenu ul li:hover ul.skinny, +#cssmenu ul li a:hover ul.skinny { /* 2nd level skinny drop-down box */ width:8.08333em; /* with a 12px default font, this is 97px width (97/12) */ } -.menu ul.rightmenu li:hover ul, -.menu ul.rightmenu li a:hover ul { /* 2nd level neighborhood drop-down box */ +#cssmenu ul.rightmenu li:hover ul, +#cssmenu ul.rightmenu li a:hover ul { /* 2nd level neighborhood drop-down box */ left:auto; right:0; /* nudge the right menu right to line up under the border */ width:400px; /* with a 12px default font, this is 228px width (228/12) */ } -* html .menu ul.rightmenu li a:hover ul { /* IE5/6 needs a tweak here */ +* html #cssmenu 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 */ +#cssmenu ul li:hover ul li a, +#cssmenu ul li a:hover ul li a { /* 2nd level unselected items */ border:0; margin:0; padding:0; @@ -122,28 +122,28 @@ width:13.5em; } -.menu ul li:hover ul li:hover a, -.menu ul li a:hover ul li a:hover { /* 2nd level selected item */ +#cssmenu ul li:hover ul li:hover a, +#cssmenu ul li a:hover ul li a:hover { /* 2nd level selected item */ color:black; background:white; } -.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 */ +#cssmenu ul li:hover ul.skinny li a, +#cssmenu ul li a:hover ul.skinny li a, +#cssmenu ul li:hover ul.skinny li a:hover, +#cssmenu ul li a:hover ul.skinny li a:hover { /* 2nd level un+selected items */ width:8.08333em; } /*======================== 3RD LEVEL MENU DEFINITIONS ========================*/ -.menu ul li:hover ul li ul, -.menu ul li a:hover ul li a ul { /* hide inactive 3rd-level menus */ +#cssmenu ul li:hover ul li ul, +#cssmenu 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 */ +#cssmenu ul li:hover ul li:hover ul, +#cssmenu ul li a:hover ul li a:hover ul { /* 3rd level drop-down box */ visibility:visible; position:absolute; margin-top:-1px; /* bring the top edge of the 3rd level menu up one */ @@ -152,14 +152,14 @@ 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 */ +#cssmenu ul li:hover ul li:hover ul li a, +#cssmenu ul li a:hover ul li a:hover ul li a { /* 3rd level unselected items */ width:14em; background:#d8d8d8; } -.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 */ +#cssmenu ul li:hover ul li:hover ul li a:hover, +#cssmenu ul li a:hover ul li a:hover ul li a:hover { /* level3 selected items */ width:14em; background:white; } From 963cc90c6a75b9fb7185f75d58029d2567639b87 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 01:35:48 +0000 Subject: [PATCH 166/498] ".main" -> "#content", ".menu" -> "#cssmenu" in dark.css --- i2p2www/static/styles/dark.css | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/i2p2www/static/styles/dark.css b/i2p2www/static/styles/dark.css index 0b86749a..9466250d 100644 --- a/i2p2www/static/styles/dark.css +++ b/i2p2www/static/styles/dark.css @@ -38,7 +38,7 @@ div.logo { font-color: #fff; } -div.menu { +div#cssmenu { /* width: 8em; */ /* height: 5em; */ /* position: fixed; */ @@ -63,7 +63,7 @@ div.menu { } /* -div.menu a:link { +div#cssmenu a:link { border:1px solid #000022; border-left: 3px solid #000022; margin: 10px 0; @@ -76,13 +76,13 @@ background-color: #9999ff; */ /* -div.menu a:link{color:#99f;margin: 15px 0;padding: 0px 5px 0px 10px; border-left: 5px solid #99f;line-height: 240%; text-decoration: none;} +div#cssmenu a:link{color:#99f;margin: 15px 0;padding: 0px 5px 0px 10px; border-left: 5px solid #99f;line-height: 240%; text-decoration: none;} */ -div.menu a:link{color:#99f;} -div.menu a:visited{color:#60f} -div.menu a:hover{color:#ff6600;} -/* div.menu a:hover{color:#ff6600;border-left: 5px solid #fff;}*/ -div.menu a:active{color:#900} +div#cssmenu a:link{color:#99f;} +div#cssmenu a:visited{color:#60f} +div#cssmenu a:hover{color:#ff6600;} +/* div#cssmenu a:hover{color:#ff6600;border-left: 5px solid #fff;}*/ +div#cssmenu a:active{color:#900} div.warning { margin: 0em 1em 1em 12em; @@ -93,7 +93,7 @@ div.warning { color: inherit; } -div.main { +div#content { margin: 0px 0px 0px 0px; padding: 25px 40px 20px 190px; background-color: #001; @@ -103,7 +103,7 @@ div.main { border-bottom: 1px solid #99f; } -div.main h1 { +div#content h1 { text-align: left; color: #99f; padding-left: 10px; @@ -437,4 +437,4 @@ td.announce { .targetlist { list-style-image: url(/_static/images/target.png); -} \ No newline at end of file +} From f76b8998668413e84f7285af2ea756d7698532ce Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 01:37:16 +0000 Subject: [PATCH 167/498] ".main" -> "#content", ".menu" -> "#cssmenu" in light.css --- i2p2www/static/styles/light.css | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/i2p2www/static/styles/light.css b/i2p2www/static/styles/light.css index d339a9c7..0c3bfec6 100644 --- a/i2p2www/static/styles/light.css +++ b/i2p2www/static/styles/light.css @@ -38,7 +38,7 @@ div.logo { font-color: #fff; } -div.menu { +div#cssmenu { /* width: 8em; */ /* height: 5em; */ /* position: fixed; */ @@ -63,7 +63,7 @@ div.menu { } /* -div.menu a:link { +div#cssmenu a:link { border:1px solid #000022; border-left: 3px solid #000022; margin: 10px 0; @@ -83,7 +83,7 @@ div.warning { color: inherit; } -div.main { +div#content { margin: 0px 0px 0px 0px; padding: 25px 40px 20px 190px; background-color: #eeeeff; @@ -93,7 +93,7 @@ div.main { border-bottom: 1px solid #000; } -div.main h1 { +div#content h1 { text-align: left; color: #000022; padding-left: 10px; From c42a4604f394962bd145c853cb4c0a04032edc85 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 01:38:09 +0000 Subject: [PATCH 168/498] ".main" -> "#content", ".menu" -> "#cssmenu" in light_ar.css --- i2p2www/static/styles/light_ar.css | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/i2p2www/static/styles/light_ar.css b/i2p2www/static/styles/light_ar.css index 88cedcec..6298e8e3 100644 --- a/i2p2www/static/styles/light_ar.css +++ b/i2p2www/static/styles/light_ar.css @@ -38,7 +38,7 @@ div.logo { font-color: #fff; } -div.menu { +div#cssmenu { /* width: 8em; */ /* height: 5em; */ /* position: fixed; */ @@ -63,7 +63,7 @@ div.menu { } /* -div.menu a:link { +div#cssmenu a:link { border:1px solid #000022; border-left: 3px solid #000022; margin: 10px 0; @@ -83,7 +83,7 @@ div.warning { color: inherit; } -div.main { +div#content { margin: 0px 0px 0px 0px; padding: 30px 200px 20px 19px; background-color: #eeeeff; @@ -93,7 +93,7 @@ div.main { border-bottom: 1px solid #000; } -div.main h1 { +div#content h1 { text-align: right; color: #000022; padding-left: 10px; From cfbc0cdd48aae022ad85c33f29118b676899e106 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 01:38:43 +0000 Subject: [PATCH 169/498] ".main" -> "#content", ".menu" -> "#cssmenu" in light_zh.css --- i2p2www/static/styles/light_zh.css | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/i2p2www/static/styles/light_zh.css b/i2p2www/static/styles/light_zh.css index 337ae867..cc8bc814 100644 --- a/i2p2www/static/styles/light_zh.css +++ b/i2p2www/static/styles/light_zh.css @@ -38,7 +38,7 @@ div.logo { font-color: #fff; } -div.menu { +div#cssmenu { width: 8em; /* height: 5em; */ /* position: fixed; */ @@ -64,7 +64,7 @@ div.menu { } /* -div.menu a:link { +div#cssmenu a:link { border:1px solid #000022; border-left: 3px solid #000022; margin: 10px 0; @@ -84,7 +84,7 @@ div.warning { color: inherit; } -div.main { +div#content { margin: 0px 0px 0px 0px; padding: 25px 40px 20px 190px; background-color: #eeeeff; @@ -95,7 +95,7 @@ div.main { line-height: 21px; } -div.main h1 { +div#content h1 { text-align: left; color: #000022; padding-left: 10px; From 05dfa49133f243f586ca53ac104f6cbf93b8b59c Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 01:55:37 +0000 Subject: [PATCH 170/498] Apply the h1 theming to div.title in old themes (like on current site) --- i2p2www/static/styles/dark.css | 2 +- i2p2www/static/styles/light.css | 2 +- i2p2www/static/styles/light_ar.css | 2 +- i2p2www/static/styles/light_zh.css | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/i2p2www/static/styles/dark.css b/i2p2www/static/styles/dark.css index 9466250d..3e429ea5 100644 --- a/i2p2www/static/styles/dark.css +++ b/i2p2www/static/styles/dark.css @@ -172,7 +172,7 @@ ul { text-indent: -4em; } -h1 { +h1, div.title { color: #9999ff; text-shadow: 0px 0px 2px rgba(255, 255, 255, 0.9); text-align: right; diff --git a/i2p2www/static/styles/light.css b/i2p2www/static/styles/light.css index 0c3bfec6..bce6d6eb 100644 --- a/i2p2www/static/styles/light.css +++ b/i2p2www/static/styles/light.css @@ -160,7 +160,7 @@ ul { text-indent: -4em; } -h1 { +h1, div.title { color: #9999ff; /* text-shadow: 0px 0px 2px rgba(255, 255, 255, 0.9); */ text-align: right; diff --git a/i2p2www/static/styles/light_ar.css b/i2p2www/static/styles/light_ar.css index 6298e8e3..00c5d3ea 100644 --- a/i2p2www/static/styles/light_ar.css +++ b/i2p2www/static/styles/light_ar.css @@ -160,7 +160,7 @@ ul { text-indent: -4em; } -h1 { +h1, div.title { color: #9999ff; /* text-shadow: 0px 0px 2px rgba(255, 255, 255, 0.9); */ text-align: right; diff --git a/i2p2www/static/styles/light_zh.css b/i2p2www/static/styles/light_zh.css index cc8bc814..e75fe817 100644 --- a/i2p2www/static/styles/light_zh.css +++ b/i2p2www/static/styles/light_zh.css @@ -163,7 +163,7 @@ ul { text-indent: -4em; } -h1 { +h1, div.title { color: #9999ff; font-family:"SimHei","黑体"; text-shadow: 1px 1px 2px rgba(255, 255, 255, 0.9); From 046acf4b36f522751ba8d07d10990f84fe071f74 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 11:14:41 +0000 Subject: [PATCH 171/498] Text change suggestions from zab --- i2p2www/pages/global/nav.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index b231cabc..da203c9f 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -95,10 +95,10 @@
    • {{ _('Plugins') }}
    -
  • {{ _('Support') }} +
  • {{ _('Help') }}
    • {{ _('FAQ') }}
    • -
    • {{ _('Web browser configuration') }}
    • +
    • {{ _('How to browse I2P') }}
    • {{ _('Glossary') }}
    • {{ _('Performance') }}
    • {{ _('Forums') }}
    • From df7a02df2b5c4352e6822d128d0fb84f0791b1f7 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 11:27:07 +0000 Subject: [PATCH 172/498] Added support/performance page based on eche|on's i2pspeed.txt document --- .../pages/site/support/performance/index.html | 105 ++++++++++++++++++ 1 file changed, 105 insertions(+) create mode 100644 i2p2www/pages/site/support/performance/index.html diff --git a/i2p2www/pages/site/support/performance/index.html b/i2p2www/pages/site/support/performance/index.html new file mode 100644 index 00000000..30b139f6 --- /dev/null +++ b/i2p2www/pages/site/support/performance/index.html @@ -0,0 +1,105 @@ +{% extends "global/layout.html" %} +{% block title %}Performance{% endblock %} +{% block content %} + +

      How does I2P work, why is it slow, and why does it not use my full bandwidth?

      + +

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

      + +

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

      + +

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

      + +

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

      + +

      +Each data package is sent through 6 other I2P nodes until it reaches the server: +

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

      +and on way back 6 different I2P nodes: +

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

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

      + +

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

      + +

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

      + +

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

      + +

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

      + +

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

      + +

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

      + +

      Performance Improvements

      + +

      For possible future performance improvements see +Future Performance Improvements.

      + +

      For past performance improvements see the +Performance History.

      + +{% endblock %} From 0c837b7a05e3bfd2d35663b5eafca6f68811a171 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 11:28:34 +0000 Subject: [PATCH 173/498] forum.i2p2.i2p is currently not clearnet-hosted --- i2p2www/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index e512eb75..279d3e72 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -128,7 +128,7 @@ def utility_processor(): # Convert an I2P url to an equivalent clearnet one i2ptoclear = { 'www.i2p2.i2p': 'www.i2p2.de', - 'forum.i2p': 'forum.i2p2.de', + #'forum.i2p': 'forum.i2p2.de', 'trac.i2p2.i2p': 'trac.i2p2.de', } def convert_url_to_clearnet(value): From cf40d5ded73e812946e76d3263b6a484fd51c472 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 11:29:19 +0000 Subject: [PATCH 174/498] Moved bug tracker link into Volunteer -> Develop --- 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 da203c9f..45016de5 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -102,7 +102,6 @@
    • {{ _('Glossary') }}
    • {{ _('Performance') }}
    • {{ _('Forums') }}
    • -
    • {{ _('Bug tracker') }}
  • {{ _('Volunteer') }} @@ -115,6 +114,7 @@
  • {{ _('Release signing keys') }}
  • {{ _('Signed keys') }}
  • {{ _('Developers keys') }}
  • +
  • {{ _('Bug tracker') }}
  • {{ _('Guides') }} From 65c2e96f9a5b08facef4fbe953eb30725e61a4b7 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 11:42:41 +0000 Subject: [PATCH 175/498] Moved Docs menu into About menu --- i2p2www/pages/global/nav.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 45016de5..c4912aac 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -12,13 +12,7 @@
  • {{ _('About') }} -
  • -
  • {{ _('Docs') }} +
  • {{ _('Documentation') }} +
  • +
  • {{ _('Team') }}
  • +
  • {{ _('Hall of Fame') }}
  • +
  • {{ _('Papers and presentations') }}
  • +
  • {{ _('Contact us') }}
  • +
  • {{ _('Help') }}
      From 6ee28ea4292b29a88f5ea8c3e74e3965c55a471b Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 12:09:29 +0000 Subject: [PATCH 176/498] Added feed icon for blog to front page --- i2p2www/pages/site/index.html | 1 + i2p2www/static/images/feed-icon-28x28.png | Bin 0 -> 1737 bytes i2p2www/static/styles/duck.css | 10 ++++++++++ 3 files changed, 11 insertions(+) create mode 100644 i2p2www/static/images/feed-icon-28x28.png diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html index 3c1fd9f5..daa5dfed 100644 --- a/i2p2www/pages/site/index.html +++ b/i2p2www/pages/site/index.html @@ -48,6 +48,7 @@
  • + I2P Blog ATOM Feed

    {% trans %}News & Updates{% endtrans %}

    {% include "blog/latest.html" %}
    diff --git a/i2p2www/static/images/feed-icon-28x28.png b/i2p2www/static/images/feed-icon-28x28.png new file mode 100644 index 0000000000000000000000000000000000000000..d64c669c7589d3a886682dbd1f3c83b716a420f5 GIT binary patch literal 1737 zcmV;)1~&PLP)sAF&N>2z!Fdr4Imm26om*2a>%jE0(;Kv%yf78|JB{oGfPNxX8x(_?yCCg`;V_$ zXsz+vi(@PROR2wt+9on+`tt9tz79KlSO2H>IyGO>#kRR$cU=`Hmyc#J&lVDyanqor z1tA1LcZEeQ^@U{`(^^*e%-kna7Wft+z>JVkoMv=$6&UWDkQ$<2lKHssGAf!lTvqVr4)B+FQFUkn06c#WX1OxA_5 z;;t4x27iQdkQg)F7+O{!f8h`chd+YqxfC)gbK_tz9fLAfFeIEn@r7e^t8mW`EtHtl zf~sX-Ks>w(zD$JfL<}?-ObbNSqyoSo8EhI@Me*$0_W}BkY=u=l5_at*Bqz>Bs-YQ{ zos4mvG?H^x!JY63{2$(dmAw(OgDBN4r@D?n>1$kSvMo%1n@ne~L*#Ej+@`@-enjuF z&(K|SKhjN0k!f56nXE1WtNKQG3pT>t|2pJAM+hc@!uQ#Vl>I(@D{D3pxKswlb>~tD zb^TOW4Rc`CjDzjiNDWa)=dPf5=zVl-eHJ}`?5*&!96k~1@ekpr?gI+6@IV)I-%YZ1 z=-v+aWGLp%CKUe#s$sz;wpp^;mX)Y(TnOzI;dNa_{>&cebNk>B1K00F_Tam4Z(qQO zd23_Pq2no`*2DW|3GJHdIgFd8T4NJhnrn;yjGBaL&ff6-AOJ$zP&E^gesm2|&uoXB zvj$EwiHzuj`}0P$f4kO{ObL|Si{@9rxo7|l7_S!?%oAqFYC^>-3Q9eduY7-u)FfIoCHc?ZV)@-|{<8PO#m0!q@K`h=j&~-o;Qk3aNwz=j=|n zt*@f@(}n2RJRjZ1wpX$pMoIGICP*h?K<~6}fS2ozSx$Zo7}Z$8j=^Jwto#h>^+V-5 z;CNj~*)B4qf2rJg3h)YcC8lmRCX=+ze4R)W{Rjv-OrYtP6i`tkW#ZBZo zAquzQ)1pNRc%A~zt)gVgBrSNqe~I>8uMwtO7Oxi|M?C$Fs^Ts74UpfJM^h3sV?wMW0WJehh2{~g4ogxB$XB+z3 zj>dqsQ-JDmG0PG|RvIr$F{C4kCg$jP$}HFbr*4{YjY!qNUc40!F-=kycOU+QnB?Mx z8|Kk4n-6^So&Tjm@IeU{f$7jOq0(5vX+iOD$&HEn>6Ln&9A*v|n??7|MdU7@C{vjR z$f_|A5hO^O4ut*#ZxgtJGkT`cL-*i%v!F$w>{{>2ab(X< zB7{67ze4nP(?WE=r;}pbYUptK=i7b_Vo0DObgB4h*)ZMw#4Moef;n1P)m$$SapFyk zgn28|VG$Q8#!==OS!68?6Qk&A<31f;^D`aBP}NOF+u83;43FmqXr@XA^@G5zL#R|Z z-6OEbB$o=0VUJMXVpoM`Q5^X>w^j&dHb$?C`9O1za}2k1oIVYauA>==_^=F>L6=L^ zy)3G=Vq5~I&uoz(IUI+sizYAj3Qn3MPY>NxTc2EAJ9P$ Date: Sat, 15 Dec 2012 12:49:03 +0000 Subject: [PATCH 177/498] Updated internal links in downloads/* --- i2p2www/pages/downloads/debian.html | 6 +++--- i2p2www/pages/downloads/list.html | 12 ++++++------ 2 files changed, 9 insertions(+), 9 deletions(-) diff --git a/i2p2www/pages/downloads/debian.html b/i2p2www/pages/downloads/debian.html index e4c3d56c..2ab9f960 100644 --- a/i2p2www/pages/downloads/debian.html +++ b/i2p2www/pages/downloads/debian.html @@ -15,7 +15,7 @@ have been tested and should work on x86
  • gNewSense 2.3
  • Nexenta 3.0.1
  • -The I2P packages may work on systems not listed above. Please report any issues with these packages on Trac at http://trac.i2p2.de. +The I2P packages may work on systems not listed above. Please report any issues with these packages on Trac at http://{{ i2pconv('trac.i2p2.i2p') }}.
    • Option 1: Recent versions of Ubuntu and its derivatives (Try this if you're not using Debian)
    • Option 2: Debian (including systems based on Debian and older versions of Ubuntu)
    • @@ -55,7 +55,7 @@ user to root with "su" or by prefixing each command with "sudo").
    • Add the GPG key that signs the repository with the following command:
          apt-key adv --keyserver keyserver.ubuntu.com --recv-keys EB2CC88B
      You'll have output like the following if the command was successful:
      -    
    • +    
    • For Debian Oldstable (Lenny) and Stable (Squeeze): Add the following entries to /etc/apt/sources.list.d/i2p.list
          deb http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main
          deb-src http://ppa.launchpad.net/i2p-maintainers/i2p/ubuntu natty main

      @@ -109,5 +109,5 @@ you may portforward.com to be helpful. as the default settings of 96 KB/s down / 40 KB/s up are fairly conservative.

      -If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto.

      +If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto.

      {% endblock %} diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index d5fb82d3..b873d5b2 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -44,7 +44,7 @@ or type java -version at your command prompt. (SHA256 39a7d6859bf4bd9ac56fd83a5e32d47d1b24ba06f912a027804492ca941936dd sig)
      - Alternately, you can fetch the source from monotone. + Alternately, you can fetch the source from monotone.
      Run (tar xjvf i2psource_{{ ver() }}.tar.bz2 ; cd i2p-{{ ver() }} ; ant pkg) then either run the GUI installer or headless install as above
    • @@ -71,7 +71,7 @@ start the router with "sh runplain.sh" instead.

      When installing for the first time, please remember to adjust your NAT/firewall if you can, bearing in mind the Internet-facing ports I2P uses, -described here among other ports. +described here among other ports. If you have successfully opened your port to inbound TCP, also enable inbound TCP on the configuration page.

      @@ -82,7 +82,7 @@ as the default settings of 96 KBps down / 40 KBps up are fairly slow.

      -If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto. +If you want to reach eepsites via your browser, have a look on the browser proxy setup page for an easy howto.

      Updates from earlier releases:

      @@ -99,7 +99,7 @@ may get a "downloaded version is not greater than current version" error, and should use the manual update method below.

      If you are running 0.7.4 or earlier, please see -the 0.7.5 release notes +the 0.7.5 release notes for important information about how to configure your router to automatically receive the release.

      @@ -132,12 +132,12 @@ receive the release. The file is signed by zzz, -whose key is here. +whose key is here.

      Previous Releases

      Previous releases are available on Google Code and Launchpad -and within the I2P network on echelon.i2p. +and within the I2P network on {{ i2pconv('echelon.i2p') }}. {% endblock %} From 885d8fc2a45c1193b846088fd436ff5002903eac Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 12:54:30 +0000 Subject: [PATCH 178/498] Added mail.i2p to i2pconv list so emails can be rewritten --- i2p2www/pages/site/about/halloffame.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/about/halloffame.html b/i2p2www/pages/site/about/halloffame.html index 45c34140..31dba8c3 100644 --- a/i2p2www/pages/site/about/halloffame.html +++ b/i2p2www/pages/site/about/halloffame.html @@ -26,7 +26,7 @@
    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 007/498] 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 008/498] 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 009/498] 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 010/498] 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 011/498] 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 012/498] 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 @@

    {{ self.title() }}

    s to make them readable --- i2p2www/static/styles/duck.css | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index becc05ea..ac71926a 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -237,6 +237,7 @@ div#content .main { div#content .inner h3 {font-size:1.4em;} div#content .inner ul {margin:1.5em; 1em;} div#content .inner p {margin:1em 0;} + div#content .inner td {padding:2px 5px;} 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;} From 791cffb2e974b787ae38dd33f3ff3a5e4edcc13d Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 14 Dec 2012 04:33:13 +0000 Subject: [PATCH 156/498] Migrated the bounty_syndie2012* pages --- i2p2www/pages/site/volunteer/bounties/index.html | 2 +- .../pages/site/volunteer/bounties/syndie2012.html | 2 +- www.i2p2/pages/{ => translations}/bounty_syndie2012_de.html | 0 3 files changed, 2 insertions(+), 2 deletions(-) rename www.i2p2/pages/bounty_syndie2012.html => i2p2www/pages/site/volunteer/bounties/syndie2012.html (96%) rename www.i2p2/pages/{ => translations}/bounty_syndie2012_de.html (100%) diff --git a/i2p2www/pages/site/volunteer/bounties/index.html b/i2p2www/pages/site/volunteer/bounties/index.html index b80f7523..0c480cb1 100644 --- a/i2p2www/pages/site/volunteer/bounties/index.html +++ b/i2p2www/pages/site/volunteer/bounties/index.html @@ -74,7 +74,7 @@ etc), and the like.

    3000 €, of which 300 € already paid for done jobs

    Syndie

    Syndie

    Proposal in development

    I2P team

    [vacant]

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

    -If you have made a donation, please send an email to echelon +If you have made a donation, please send an email to echelon with your name or nick (and optionally homepage) so we can list you here.

    From 7775b8ed48f4d764ae44ee49ab88d5966e6cfac1 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 13:01:09 +0000 Subject: [PATCH 179/498] Missed __init__.py in last commit --- i2p2www/__init__.py | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 279d3e72..5341abdf 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -130,6 +130,7 @@ def utility_processor(): 'www.i2p2.i2p': 'www.i2p2.de', #'forum.i2p': 'forum.i2p2.de', 'trac.i2p2.i2p': 'trac.i2p2.de', + 'mail.i2p': 'i2pmail.org', } def convert_url_to_clearnet(value): if not value.endswith('.i2p'): From 471178471a274913c177b6f445ef4cb66c05b73c Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 13:01:44 +0000 Subject: [PATCH 180/498] Updated links in about/* --- i2p2www/pages/site/about/papers.html | 4 ++-- i2p2www/pages/site/about/team.html | 24 ++++++++++++------------ 2 files changed, 14 insertions(+), 14 deletions(-) diff --git a/i2p2www/pages/site/about/papers.html b/i2p2www/pages/site/about/papers.html index a4881172..9a0fe279 100644 --- a/i2p2www/pages/site/about/papers.html +++ b/i2p2www/pages/site/about/papers.html @@ -15,11 +15,11 @@ Newest links are at the bottom of each section.
    • -Invisible Internet Project (I2P) Project Overview, jrandom, August 28, 2003. +Invisible Internet Project (I2P) Project Overview, jrandom, August 28, 2003.
    • -Peer Profiling and Selection in the I2P Anonymous Network - +Peer Profiling and Selection in the I2P Anonymous Network - zzz and Lars Schimmer, presented at PET-CON 2009.1, diff --git a/i2p2www/pages/site/about/team.html b/i2p2www/pages/site/about/team.html index 5bd06e7d..db394d57 100644 --- a/i2p2www/pages/site/about/team.html +++ b/i2p2www/pages/site/about/team.html @@ -26,7 +26,7 @@ network. press contact, manages public relations and affairs - Forum admin + Forum admin cervantes manage the public user forum @@ -81,12 +81,12 @@ network. manage the public project website content design - Webserver admin + Webserver admin welterde manage the public project webservers - Website admin + Website admin [vacant] manage the public project website content @@ -108,47 +108,47 @@ network. lead dev for the SDK and router - I2P mail lead + I2P mail lead postman organize and develop the i2p mail system - I2Host lead + I2Host lead sponge I2Host addressbook application - BOB lead + BOB lead sponge Basic Open Bridge - I2P-Bote lead + I2P-Bote lead HungryHobo I2PBote plugin - Robert lead + Robert lead sponge Robert BitTorrent client - I2Phex lead + I2Phex lead [vacant] I2Phex Gnutella client - I2PSnark lead + I2PSnark lead zzz Maintains the integrated Bittorrent client - iMule lead + iMule lead [vacant] eMule client over I2P - Syndie lead + Syndie lead [vacant] Syndie development From a9b34ce7ad2aaa242e4fea8ab5eda3da5b4f3e83 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 13:12:54 +0000 Subject: [PATCH 181/498] Updated links in support/* --- i2p2www/pages/site/support/faq.html | 27 +++++++++---------- .../site/support/performance/future.html | 2 +- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/i2p2www/pages/site/support/faq.html b/i2p2www/pages/site/support/faq.html index e7705af6..82941ca6 100644 --- a/i2p2www/pages/site/support/faq.html +++ b/i2p2www/pages/site/support/faq.html @@ -49,7 +49,7 @@

      What systems will I2P run on? (link)

      -

      While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A chart comparing the performance of the various JREs can be found at http://trac.i2p2.de/wiki/java, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK.

      +

      While I2P has been reported to run PCs as meagre as a low-end Pentium II with 64 MB of RAM, you'll have a much better experience on a Pentium III (or better) with 128MB of RAM (or more). A chart comparing the performance of the various JREs can be found at http://{{ i2pconv('trac.i2p2.i2p') }}/wiki/java, but in short: it's at all possible, use Sun/Oracle Java or OpenJDK.

      I2P has been tested on Windows, Linux, FreeBSD (see the note below), OSX, and OpenSolaris. There is work underway to bring I2P to the Android platform.

      @@ -58,8 +58,8 @@ Here are some places, pick one or more.

      @@ -97,7 +97,7 @@ We do not know if or when jrandom will return. The *.i2p.net domains were left in a non-functioning state after a power outage at the hosting company.

      See this page for jrandom's parting message and additional information - on the migration of *.i2p.net to this website.

      + on the migration of *.i2p.net to this website.

      I2P remains in active development.

      My router is using too much CPU?!? @@ -198,13 +198,13 @@ All routers adjust dynamically to changing network conditions and demands. If you are running release 0.6.1.31 or later, you probably don't need to do this. If you are running release 0.6.1.26 or earlier, either follow the manual reseed instructions below - or install the latest release. + or install the latest release. Possible alternate method - add wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/ to wrapper.config, shutdown the router completely, then start again, then click "reseed". Let us know if this works.

      -

      ...but you *really* should upgrade to the latest version.

      +

      ...but you *really* should upgrade to the latest version.

      My router has very few active peers, is this OK? (link)

      @@ -261,7 +261,7 @@ The best way to stay "better-connected" to the network is to h2ik's for the address. + See this forum post of h2ik's for the address. Make sure Shared Client, Delay Connect, AutoStart are checked. Other options should be left at the defaults. Click Save. In tunnel manger, click the Start button next to your new tunnel.
    • In firefox, click through Tools>Options>Advanced>Network>Setting. @@ -284,7 +284,7 @@ The best way to stay "better-connected" to the network is to zzz.i2p. + There is additional discussion about this on zzz.i2p.

      How do I access IRC, BitTorrent, or other services on the regular Internet? @@ -301,7 +301,7 @@ The best way to stay "better-connected" to the network is to perv.i2p tracks active eepsites. + perv.i2p tracks active eepsites.

      How do I set up my own eepsite? @@ -332,15 +332,14 @@ keeps you well-integrated in the network and helps your own transfer speeds.

      I2P is a work in progress. Lots of improvements and fixes are being implemented, and generally speaking, running the latest release will help your performance. -If you haven't, install the latest release. +If you haven't, install the latest release.

      Bittorrent / I2PSnark / Azureus I2P Plugin Questions? (link)

      See the -I2P Bittorrent FAQ -(outside I2P) +I2P Bittorrent FAQ

      How do I connect to IRC within I2P? (link)

      @@ -426,7 +425,7 @@ router advanced configuration option i2cp.tcp.bindAllInterfaces=true an extremely dangerous.

      If you would like more information on the socks proxy application anyway, - there are some helpful hints on the socks page. + there are some helpful hints on the socks page.

      What ports does I2P use? @@ -639,7 +638,7 @@ click Shutdown, wait 11 minutes, then start I2P.

      (link)

      Great! Find us on IRC irc.freenode.net #i2p or post to - the forum (within I2P) and we'll post it here (with + the forum (within I2P) and we'll post it here (with the answer, hopefully).

      {% endblock %} diff --git a/i2p2www/pages/site/support/performance/future.html b/i2p2www/pages/site/support/performance/future.html index a07d3571..95bdafbe 100644 --- a/i2p2www/pages/site/support/performance/future.html +++ b/i2p2www/pages/site/support/performance/future.html @@ -115,6 +115,6 @@ bandwidth, latency, and CPU usage.

    Additional ideas for improving the streaming library are described on the -streaming library page. +streaming library page.

    {% endblock %} From f7c84f3473d0c21eebda9daa9d2ad572b8ba4059 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 15 Dec 2012 21:57:32 +0000 Subject: [PATCH 182/498] Removed duplicate links from footer, and added theme changing links --- i2p2www/__init__.py | 9 ++++++++- i2p2www/pages/global/footer.html | 24 +++++++++++------------- 2 files changed, 19 insertions(+), 14 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 5341abdf..ff1b73ae 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -153,8 +153,15 @@ def utility_processor(): args['page'] = page return url_for(request.endpoint, **args) + # Change the theme of the current page + def change_theme(theme): + args = request.view_args.copy() + args['theme'] = theme + return url_for(request.endpoint, **args) + return dict(i2pconv=convert_url_to_clearnet, - url_for_other_page=url_for_other_page) + url_for_other_page=url_for_other_page, + change_theme=change_theme) ################ diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html index dda9b768..9edbab19 100644 --- a/i2p2www/pages/global/footer.html +++ b/i2p2www/pages/global/footer.html @@ -1,18 +1,14 @@
    -

    {{ _('About I2P') }}

    - -
    -

    {{ _('Mirrors') }}

    -
    +

    {{ _('Secure') }}

    -
    +

    {{ _('Misc.') }}

    -
    +

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

    +
    + From 1f65a8110eda38e28bf1f538f8bc666d38ec457e Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 19:55:08 +0000 Subject: [PATCH 183/498] Migrated over 0.9.4 release page --- i2p2www/blog/2012/12/17/I2P_0.9.4_released.rst | 6 ++++++ .../pages => i2p2www/blog/2012/12/17}/release-0.9.4.html | 6 ------ 2 files changed, 6 insertions(+), 6 deletions(-) create mode 100644 i2p2www/blog/2012/12/17/I2P_0.9.4_released.rst rename {www.i2p2/pages => i2p2www/blog/2012/12/17}/release-0.9.4.html (96%) diff --git a/i2p2www/blog/2012/12/17/I2P_0.9.4_released.rst b/i2p2www/blog/2012/12/17/I2P_0.9.4_released.rst new file mode 100644 index 00000000..c7ae40cf --- /dev/null +++ b/i2p2www/blog/2012/12/17/I2P_0.9.4_released.rst @@ -0,0 +1,6 @@ +============= +0.9.4 Release +============= + +.. raw:: html + :file: blog/2012/12/17/release-0.9.4.html diff --git a/www.i2p2/pages/release-0.9.4.html b/i2p2www/blog/2012/12/17/release-0.9.4.html similarity index 96% rename from www.i2p2/pages/release-0.9.4.html rename to i2p2www/blog/2012/12/17/release-0.9.4.html index 7945a92a..3ce2459c 100644 --- a/www.i2p2/pages/release-0.9.4.html +++ b/i2p2www/blog/2012/12/17/release-0.9.4.html @@ -1,7 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}0.9.4 Release{% endblock %} -{% block content %} -

    0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability @@ -67,5 +63,3 @@ SHA256 Checksums:

    - -{% endblock %} From b8a1626b163a3830d8de3aa411a6eb3cdb1e6733 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 20:33:43 +0000 Subject: [PATCH 184/498] Fix after merge --- i2p2www/pages/downloads/list.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/downloads/list.html b/i2p2www/pages/downloads/list.html index fa7f7261..8dfaac62 100644 --- a/i2p2www/pages/downloads/list.html +++ b/i2p2www/pages/downloads/list.html @@ -119,7 +119,7 @@ receive the release.

    Updates from earlier releases (manual method):

      -
    1. Download i2pupdate_0.9.4.zip +
    2. Download i2pupdate_{{ ver() }}.zip (SHA256 0f369d9b85793f157ec67c4d59723a2ad0c1de2a0902d35e11c26a2c74add824 sig) to your I2P From 0a5b848f953405b206ffe9f9e99ee7b1ccfa4a67 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 20:35:52 +0000 Subject: [PATCH 185/498] 0.9.4 --- i2p2www/pages/global/macros | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index a1470155..52783c00 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -15,8 +15,8 @@ {%- endmacro -%} {%- macro ver(string=None) -%} -{%- if string -%}{{ string % '0.9.3' }} -{%- else -%}{{ '0.9.3' }} +{%- if string -%}{{ string % '0.9.4' }} +{%- else -%}{{ '0.9.4' }} {%- endif -%} {%- endmacro -%} From 6772b465636513d9bad31217a7cb9c566ea25cb1 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 21:21:47 +0000 Subject: [PATCH 186/498] Migrated over meetings 211 and 212 --- .../meetings/211.log | 35 ------------------- i2p2www/meetings/211.rst | 19 ++++++++++ .../meetings/212.log | 33 ----------------- i2p2www/meetings/212.rst | 17 +++++++++ 4 files changed, 36 insertions(+), 68 deletions(-) rename www.i2p2/pages/meeting211.html => i2p2www/meetings/211.log (96%) create mode 100644 i2p2www/meetings/211.rst rename www.i2p2/pages/meeting212.html => i2p2www/meetings/212.log (89%) create mode 100644 i2p2www/meetings/212.rst diff --git a/www.i2p2/pages/meeting211.html b/i2p2www/meetings/211.log similarity index 96% rename from www.i2p2/pages/meeting211.html rename to i2p2www/meetings/211.log index 62d4f38e..0845fd1e 100644 --- a/www.i2p2/pages/meeting211.html +++ b/i2p2www/meetings/211.log @@ -1,33 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 211{% endblock %} -{% block content %}

      I2P dev meeting, December 4, 2012 @ 20:00 UTC

      -
      -

      Quick recap

      -
        -
      • Present: - - dg, - hottuna, - KillYourTV, - lillith, - Meeh, - psi, - str4d, - weltende, - zzz -
      • -
      • - Next Meeting -

        - The next meeting is scheduled for Tuesday, December 11 @ 20:00 UTC (8:00PM) -

        -
      • -
      -
      -
      -

      Full IRC Log

      -
      -{% filter escape %}
       20:18:53  * KillYourTV has noticed that we're 17 minutes into the meeting...and we're off to a quiet start...
       20:19:31   i was wondering that, did i also get the wrong time or something?
       20:20:23  * dg is waiting for self to be free
      @@ -261,8 +231,3 @@
       22:28:10  * psi lag
       22:28:55   Meeh, to be decided, maybe before since this one wasn't a great success
       22:29:25   true true, next week then
      -{% endfilter %}
      -{# TODO: pygments #}
      -
      -
      -{% endblock %} diff --git a/i2p2www/meetings/211.rst b/i2p2www/meetings/211.rst new file mode 100644 index 00000000..c0746a65 --- /dev/null +++ b/i2p2www/meetings/211.rst @@ -0,0 +1,19 @@ +I2P dev meeting, December 4, 2012 @ 20:00 UTC +============================================== + +Quick recap +----------- + +* **Present:** + dg, + hottuna, + KillYourTV, + lillith, + Meeh, + psi, + str4d, + weltende, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, December 11 @ 20:00 UTC (8:00PM) diff --git a/www.i2p2/pages/meeting212.html b/i2p2www/meetings/212.log similarity index 89% rename from www.i2p2/pages/meeting212.html rename to i2p2www/meetings/212.log index e82fa34a..23a705cc 100644 --- a/www.i2p2/pages/meeting212.html +++ b/i2p2www/meetings/212.log @@ -1,31 +1,3 @@ -{% extends "_layout.html" %} -{% block title %}I2P Development Meeting 212{% endblock %} -{% block content %}

      I2P dev meeting, December 11, 2012 @ 20:00 UTC

      -
      -

      Quick recap

      -
        -
      • Present: - - lillith, - Meeh, - postman, - psi, - str4d, - topiltzin, - zzz -
      • -
      • - Next Meeting -

        - The next meeting is scheduled for Tuesday, December 18 @ 20:00 UTC (8:00PM) -

        -
      • -
      -
      -
      -

      Full IRC Log

      -
      -{% filter escape %}
       20:20:09    Not sure where dg is, so I propose that we get the meeting started anyway, continuing on with the agenda from last week (or restarting it if necessary).
       20:20:09   (http://zzz.i2p/posts/5779)
       20:20:18   Title: zzz.i2p: IRC Meetings (at zzz.i2p)
      @@ -99,8 +71,3 @@
       22:07:     i'l leave this to dg , presumably it will be 8.00 UTC next tuesday (18th)
       22:08:     topiltzin, i'l take a look
       22:09:     I'd say this meeting is now officially over then :)
      -{% endfilter %}
      -{# TODO: pygments #}
      -
      -
      -{% endblock %} diff --git a/i2p2www/meetings/212.rst b/i2p2www/meetings/212.rst new file mode 100644 index 00000000..8502917d --- /dev/null +++ b/i2p2www/meetings/212.rst @@ -0,0 +1,17 @@ +I2P dev meeting, December 11, 2012 @ 20:00 UTC +=============================================== + +Quick recap +----------- + +* **Present:** + lillith, + Meeh, + postman, + psi, + str4d, + topiltzin, + zzz + +* **Next Meeting** + The next meeting is scheduled for Tuesday, December 18 @ 20:00 UTC (8:00PM) From a665d6153fc45494ef7ca0da39884886c98fe61b Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 21:31:55 +0000 Subject: [PATCH 187/498] 500 error page should have minimal reliance on the backend (so it doesn't error itself) --- i2p2www/pages/global/error_500.html | 33 ++++++++++++++++++----------- 1 file changed, 21 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/global/error_500.html b/i2p2www/pages/global/error_500.html index c6cc1159..e96680d0 100644 --- a/i2p2www/pages/global/error_500.html +++ b/i2p2www/pages/global/error_500.html @@ -1,12 +1,21 @@ -{% extends "global/layout.html" %} -{% block title -%} -{% trans -%} -Server error -{%- endtrans %} -{%- endblock %} - -{% block content %} -{% trans -%} -Umm... the server encountered some sort of error. -{%- endtrans %} -{% endblock %} + + + + + {% trans %}Server error{% endtrans %} - I2P + + + + + +
      +

      I2P

      +
      {% trans %}500 Server error{% endtrans %}
      +
      +
      +
      + {% trans %}Umm... the server encountered some sort of error.{% endtrans %} +
      +
      + + From 68ce69fdd1b0c4570a78fb7937c3e4dd54056b60 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 21:36:43 +0000 Subject: [PATCH 188/498] Add title to blog ATOM feed link on front page --- i2p2www/pages/site/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html index daa5dfed..1b6820f1 100644 --- a/i2p2www/pages/site/index.html +++ b/i2p2www/pages/site/index.html @@ -48,7 +48,7 @@
    - I2P Blog ATOM Feed + I2P Blog ATOM Feed

    {% trans %}News & Updates{% endtrans %}

    {% include "blog/latest.html" %}
    From 262040fd301db4b1af50af3bc135a28e5e29dd2e Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 21:59:41 +0000 Subject: [PATCH 189/498] Tweaked mirror code so mirror urls can contain the current I2P version, added Launchpad as HTTPS mirror NOTE: this enables mirrors that require a version string to download the current version of files. Older file versions will *not* be downloadable (that would require parsing the requested filename to try and find a version). Hey, it's better than no support at all =) --- i2p2www/__init__.py | 16 +++++++++++++--- i2p2www/pages/downloads/mirrors | 7 ++++--- 2 files changed, 17 insertions(+), 6 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index ff1b73ae..e1a572c5 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -16,6 +16,8 @@ except ImportError: from helpers import Pagination +CURRENT_I2P_VERSION = '0.9.4' + TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages') STATIC_DIR = os.path.join(os.path.dirname(__file__), 'static') @@ -406,13 +408,17 @@ def downloads_select(file): if (file == 'debian'): return render_template('downloads/debian.html') mirrors=read_mirrors() + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } obj=[] for protocol in mirrors.keys(): a={} a['name']=protocol a['mirrors']=mirrors[protocol] for mirror in a['mirrors']: - mirror['url']=mirror['url'] % file + mirror['url']=mirror['url'] % data obj.append(a) return render_template('downloads/select.html', mirrors=obj, file=file) @@ -423,9 +429,13 @@ def downloads_redirect(protocol, file, mirror): if not protocol in mirrors: abort(404) mirrors=mirrors[protocol] + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } if mirror: - return redirect(mirrors[mirror]['url'] % file) - return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % file) + return redirect(mirrors[mirror]['url'] % data) + return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) ##################### diff --git a/i2p2www/pages/downloads/mirrors b/i2p2www/pages/downloads/mirrors index 82ab9b31..b3368578 100644 --- a/i2p2www/pages/downloads/mirrors +++ b/i2p2www/pages/downloads/mirrors @@ -1,3 +1,4 @@ -{"url": "http://i2p.googlecode.com/files/%s", "org": "Google Code", "org_url": "http://code.google.com", "protocol": "http", "country": "us"} -{"url": "http://golden.mtveurope.org/~yang/i2p_mirror/%s", "org": "VServer.si", "org_url": "http://www.vserver.si", "protocol": "http", "country": "lu"} -{"url": "http://a.mirror.geti2p.net/releases/current/%s", "org": "welterde", "protocol": "http", "country": "de"} +{"url": "http://i2p.googlecode.com/files/%(file)s", "org": "Google Code", "org_url": "http://code.google.com", "protocol": "http", "country": "us"} +{"url": "http://golden.mtveurope.org/~yang/i2p_mirror/%(file)s", "org": "VServer.si", "org_url": "http://www.vserver.si", "protocol": "http", "country": "lu"} +{"url": "http://a.mirror.geti2p.net/releases/current/%(file)s", "org": "welterde", "protocol": "http", "country": "de"} +{"url": "https://launchpad.net/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "protocol": "https", "country": "us"} From 9acb01be7a7dc3ded60bd32c982786301cf1e6a1 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 17 Dec 2012 22:19:39 +0000 Subject: [PATCH 190/498] Added Google Code as an HTTPS mirror, sorted mirrors file by org --- i2p2www/pages/downloads/mirrors | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/downloads/mirrors b/i2p2www/pages/downloads/mirrors index b3368578..4913ac68 100644 --- a/i2p2www/pages/downloads/mirrors +++ b/i2p2www/pages/downloads/mirrors @@ -1,4 +1,5 @@ {"url": "http://i2p.googlecode.com/files/%(file)s", "org": "Google Code", "org_url": "http://code.google.com", "protocol": "http", "country": "us"} +{"url": "https://i2p.googlecode.com/files/%(file)s", "org": "Google Code", "org_url": "https://code.google.com", "protocol": "https", "country": "us"} +{"url": "https://launchpad.net/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "protocol": "https", "country": "us"} {"url": "http://golden.mtveurope.org/~yang/i2p_mirror/%(file)s", "org": "VServer.si", "org_url": "http://www.vserver.si", "protocol": "http", "country": "lu"} {"url": "http://a.mirror.geti2p.net/releases/current/%(file)s", "org": "welterde", "protocol": "http", "country": "de"} -{"url": "https://launchpad.net/i2p/trunk/%(version)s/+download/%(file)s", "org": "Launchpad", "org_url": "https://launchpad.net", "protocol": "https", "country": "us"} From 18e26d6cc3dd3494eaa8aafbe671a895b653d6ec Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 18 Dec 2012 00:42:19 +0000 Subject: [PATCH 191/498] Replace half of .inner padding with margin -> adds side border to all pages --- i2p2www/static/styles/duck.css | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 64a0992a..66fcc14f 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -237,7 +237,7 @@ div#content .main { * 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; + width:auto; margin: 0 5%; padding: 4em 5%; position:relative; background: rgba(171, 204, 113, 0.6); border-top:2px solid #abcc71; color:black; font-size:1.2em; line-height:1.4em; } From 32db04d701b77c2485abfa762cec66c5cab20777 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 18 Dec 2012 00:44:54 +0000 Subject: [PATCH 192/498] Rounded bottom corners of .lastupdated box --- i2p2www/static/styles/duck.css | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 66fcc14f..8d36404a 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -225,6 +225,7 @@ div#content .main { div#content .lastupdated { background-color: #ffffdd; + border-radius: 0 0 5px 5px; padding: 2px 4px; position: absolute; right: 10%; From 914492e6259b0d37278dcc865da7c30b245bc61d Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 01:47:48 +0000 Subject: [PATCH 193/498] Moved the last few unsorted pages into misc/ (and ports into docs/) --- {www.i2p2/pages => i2p2www/pages/site/docs}/ports.html | 8 ++++---- .../pages/site/misc}/i2ptunnel_services.html | 2 +- {www.i2p2/pages => i2p2www/pages/site/misc}/jbigi.html | 9 ++++----- .../pages => i2p2www/pages/site/misc}/manualwrapper.html | 4 ++-- {www.i2p2/pages => i2p2www/pages/site/misc}/minwww.html | 4 ++-- .../pages => i2p2www/pages/site/misc}/ratestats.html | 2 +- 6 files changed, 14 insertions(+), 15 deletions(-) rename {www.i2p2/pages => i2p2www/pages/site/docs}/ports.html (92%) rename {www.i2p2/pages => i2p2www/pages/site/misc}/i2ptunnel_services.html (99%) rename {www.i2p2/pages => i2p2www/pages/site/misc}/jbigi.html (96%) rename {www.i2p2/pages => i2p2www/pages/site/misc}/manualwrapper.html (95%) rename {www.i2p2/pages => i2p2www/pages/site/misc}/minwww.html (99%) rename {www.i2p2/pages => i2p2www/pages/site/misc}/ratestats.html (99%) diff --git a/www.i2p2/pages/ports.html b/i2p2www/pages/site/docs/ports.html similarity index 92% rename from www.i2p2/pages/ports.html rename to i2p2www/pages/site/docs/ports.html index 557746d0..22dcfd89 100644 --- a/www.i2p2/pages/ports.html +++ b/i2p2www/pages/site/docs/ports.html @@ -1,5 +1,7 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Ports Used by I2P{% endblock %} +{% block lastupdated %}May 2012{% endblock %} +{% block accuratefor %}0.9{% endblock %} {% block content %}

    @@ -7,10 +9,8 @@ These are the ports used or reserved by I2P, including those for known plugins, common alternates, and some typical related applications.

    -Updated May 2012, current for router version 0.9. -

    Note that many of these are not enabled by default. -There is more information in the FAQ. +There is more information in the FAQ. See also the documentation for individual plugins. Plugin authors please add any ports you use here. For new plugins, we recommend using the next available port diff --git a/www.i2p2/pages/i2ptunnel_services.html b/i2p2www/pages/site/misc/i2ptunnel_services.html similarity index 99% rename from www.i2p2/pages/i2ptunnel_services.html rename to i2p2www/pages/site/misc/i2ptunnel_services.html index 507cdf2b..a9e9433a 100644 --- a/www.i2p2/pages/i2ptunnel_services.html +++ b/i2p2www/pages/site/misc/i2ptunnel_services.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}i2ptunnel services{% endblock %} {% block content %}Below is quick copy of aum's eepsite deployment guide.
    diff --git a/www.i2p2/pages/jbigi.html b/i2p2www/pages/site/misc/jbigi.html similarity index 96% rename from www.i2p2/pages/jbigi.html rename to i2p2www/pages/site/misc/jbigi.html index 47747a4d..5a123c5b 100644 --- a/www.i2p2/pages/jbigi.html +++ b/i2p2www/pages/site/misc/jbigi.html @@ -1,9 +1,8 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}jbigi{% endblock %} +{% block lastupdated %}August 2011{% endblock %} +{% block accuratefor %}0.8.7{% endblock %} {% block content %} - -Updated August 2011, current as of router version 0.8.7 -

    Overview

    Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a little manual work and a piece of chewing gum we have made several @@ -77,7 +76,7 @@ If your encrypt time is less than 50ms for a relatively new processor, or less t for an older processor, and the native BigInteger library was loaded, you are probably fine.

  • Get the latest released source code of I2P from -the download page, or get the cutting-edge source +the download page, or get the cutting-edge source out of the monotone database mtn.i2p2.de
  • Inside the source tree change directory to: core/c/jbigi
  • Read the README file. diff --git a/www.i2p2/pages/manualwrapper.html b/i2p2www/pages/site/misc/manualwrapper.html similarity index 95% rename from www.i2p2/pages/manualwrapper.html rename to i2p2www/pages/site/misc/manualwrapper.html index b2c71411..3aba9b90 100644 --- a/www.i2p2/pages/manualwrapper.html +++ b/i2p2www/pages/site/misc/manualwrapper.html @@ -1,9 +1,9 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Manually Installing the Java Wrapper{% endblock %} {% block content %}

    Manually Installing the Java Wrapper

    -

    The installation package for the I2P router comes +

    The installation package for the I2P router comes with a Java wrapper for the most common architectures. If your system is not supported by our installer—or if you want to update the wrapper to a newer version—the following steps describe installing the wrapper manually. diff --git a/www.i2p2/pages/minwww.html b/i2p2www/pages/site/misc/minwww.html similarity index 99% rename from www.i2p2/pages/minwww.html rename to i2p2www/pages/site/misc/minwww.html index 2fc32768..a4307741 100644 --- a/www.i2p2/pages/minwww.html +++ b/i2p2www/pages/site/misc/minwww.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}minwww{% endblock %} {% block content %}

    Here's an outline and rationale for a minimal WWW proxy app for use over I2P.

    @@ -100,4 +100,4 @@ size, but that's going to be going away since it involves either excessive memor overhead on intermediary routers, or additional implementation details to handle. I2PTunnel is currently limited to 128KB and hasn't been a burden, so perhaps it could be increased to 256KB when the I2CP spec is updated)

    -{% endblock %} \ No newline at end of file +{% endblock %} diff --git a/www.i2p2/pages/ratestats.html b/i2p2www/pages/site/misc/ratestats.html similarity index 99% rename from www.i2p2/pages/ratestats.html rename to i2p2www/pages/site/misc/ratestats.html index e51b0c01..83cd79b7 100644 --- a/www.i2p2/pages/ratestats.html +++ b/i2p2www/pages/site/misc/ratestats.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}RateStat list{% endblock %} {% block content %}

    RateStat list

    From db3a7de35d46f126aa8a6fbd64020890a4080933 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 01:58:58 +0000 Subject: [PATCH 194/498] Moved the old (but not replaced) pages into misc/ --- .../old => i2p2www/pages/site/misc}/clt.html | 2 +- .../old => i2p2www/pages/site/misc}/cvs.html | 4 ++-- .../pages/site/misc}/i2ptunnel_migration.html | 4 ++-- i2p2www/pages/site/misc/invisiblenet.html | 23 +++++++++++++++++++ .../pages/site/misc}/jrandom-awol.html | 2 +- .../pages/site/misc}/myi2p.html | 8 +++---- .../pages/site/misc}/transition-guide.html | 6 ++--- .../pages/site/misc}/transition-guide.txt | 0 .../pages/site/misc}/upgrade-0.6.1.30.html | 6 ++--- www.i2p2/pages/old/invisiblenet.html | 23 ------------------- 10 files changed, 39 insertions(+), 39 deletions(-) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/clt.html (96%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/cvs.html (88%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/i2ptunnel_migration.html (97%) create mode 100644 i2p2www/pages/site/misc/invisiblenet.html rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/jrandom-awol.html (98%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/myi2p.html (86%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/transition-guide.html (80%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/transition-guide.txt (100%) rename {www.i2p2/pages/old => i2p2www/pages/site/misc}/upgrade-0.6.1.30.html (93%) delete mode 100644 www.i2p2/pages/old/invisiblenet.html diff --git a/www.i2p2/pages/old/clt.html b/i2p2www/pages/site/misc/clt.html similarity index 96% rename from www.i2p2/pages/old/clt.html rename to i2p2www/pages/site/misc/clt.html index 0532fdee..9a529f74 100644 --- a/www.i2p2/pages/old/clt.html +++ b/i2p2www/pages/site/misc/clt.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}I2P at CLT and PetCon 2009.1{% endblock %} {% block content %}

    Members of I2P will held a talk at CLT and PetCon 2009.1

    Two members of the I2P team will be at two forthcoming Linux day and security convention. diff --git a/www.i2p2/pages/old/cvs.html b/i2p2www/pages/site/misc/cvs.html similarity index 88% rename from www.i2p2/pages/old/cvs.html rename to i2p2www/pages/site/misc/cvs.html index 26f93a9f..52365d9d 100644 --- a/www.i2p2/pages/old/cvs.html +++ b/i2p2www/pages/site/misc/cvs.html @@ -1,6 +1,6 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}CVS{% endblock %} -{% block content %}

    The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository. +{% block content %}

    The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository. For those who aren't very familiar with CVS, there is a fantastic book on the subject (developers only need to deal with the first chapter - "An Overview of diff --git a/www.i2p2/pages/old/i2ptunnel_migration.html b/i2p2www/pages/site/misc/i2ptunnel_migration.html similarity index 97% rename from www.i2p2/pages/old/i2ptunnel_migration.html rename to i2p2www/pages/site/misc/i2ptunnel_migration.html index 888ce4ab..0c5fa751 100644 --- a/www.i2p2/pages/old/i2ptunnel_migration.html +++ b/i2p2www/pages/site/misc/i2ptunnel_migration.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}i2ptunnel migration{% endblock %} {% block content %}

    I2PTunnel migration:

    @@ -41,4 +41,4 @@ existing tunnels and rebuild new ones)

    into the network before you are able to use the /i2ptunnel/ web interface. It will say "Please be patient" if you try to beforehand, which means that it is still trying to build the -necessary I2PTunnel sessions it has been configured to create.

    {% endblock %} \ No newline at end of file +necessary I2PTunnel sessions it has been configured to create.

    {% endblock %} diff --git a/i2p2www/pages/site/misc/invisiblenet.html b/i2p2www/pages/site/misc/invisiblenet.html new file mode 100644 index 00000000..5c2c7a10 --- /dev/null +++ b/i2p2www/pages/site/misc/invisiblenet.html @@ -0,0 +1,23 @@ +{% extends "global/layout.html" %} +{% block title %}Old Documents{% endblock %} +{% block content %} + +Following is a list of documents originally on www.invisiblenet.net/i2p/ and +rescued via the +Wayback Machine. +They are quite dated and may or may not be accurate. +However, the I2CP and I2NP documents in particular have some good information. + + +

    Index of /i2p

    +
    Name                    Last modified       Size
    +
    +I2CP_spec.pdf 03-Sep-2003 12:49 119k +I2NP_spec.pdf 03-Sep-2003 12:49 356k +datastructures.pdf 03-Sep-2003 12:49 149k +i2p_philosophy.pdf 03-Sep-2003 12:52 126k +polling_http_transpo..> 03-Sep-2003 12:49 189k +
    + + +{% endblock %} diff --git a/www.i2p2/pages/old/jrandom-awol.html b/i2p2www/pages/site/misc/jrandom-awol.html similarity index 98% rename from www.i2p2/pages/old/jrandom-awol.html rename to i2p2www/pages/site/misc/jrandom-awol.html index 5ca4aff9..a5ea40c6 100644 --- a/www.i2p2/pages/old/jrandom-awol.html +++ b/i2p2www/pages/site/misc/jrandom-awol.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Jrandom's Announcement{% endblock %} {% block content %} The following message was received in mid-November 2007. We have no further information diff --git a/www.i2p2/pages/old/myi2p.html b/i2p2www/pages/site/misc/myi2p.html similarity index 86% rename from www.i2p2/pages/old/myi2p.html rename to i2p2www/pages/site/misc/myi2p.html index 4daf83c2..e78b1b93 100644 --- a/www.i2p2/pages/old/myi2p.html +++ b/i2p2www/pages/site/misc/myi2p.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}MYI2P{% endblock %} {% block content %}

    There has been discussion about a distributed blogging application for a few months now called "MyI2P". While the original discussions were lost, we were @@ -8,7 +8,7 @@ that ensued.

    The application itself is not yet implemented, and the ideas behind it have been made less ambitious over time, but they are still valid and the current -plan is to have the core MyI2P functionality available +plan is to have the core MyI2P functionality available along side the I2P 1.0 release. That will include a distributed address book to enable secure, distributed, and human readable naming by sacrificing the need for global uniqueness - basically everyone has their own local address book @@ -19,7 +19,7 @@ system using a reduced and secured subset of bbcode to essentially provide an anonymous LiveJournal with a 'friends list' and transparent access control (authenticated by the I2P -datagrams with rules defined based on the address book).

    +datagrams with rules defined based on the address book).

    Additional functionality, such as integration with a DHT backing store or swarming file transfers for 'attachments' can be added later. Email may or may @@ -27,4 +27,4 @@ not get in the first pass either, though its implementation is essentially just a blog entry with private access, so perhaps some UI designer can come up with something. Exporting the data to RSS or access through ATOM will be an option down the road as well.

    -{% endblock %} \ No newline at end of file +{% endblock %} diff --git a/www.i2p2/pages/old/transition-guide.html b/i2p2www/pages/site/misc/transition-guide.html similarity index 80% rename from www.i2p2/pages/old/transition-guide.html rename to i2p2www/pages/site/misc/transition-guide.html index 0f10d1c8..4480f02d 100644 --- a/www.i2p2/pages/old/transition-guide.html +++ b/i2p2www/pages/site/misc/transition-guide.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}Monotone{% endblock %} {% block content %}

    The I2P sourcecode is kept in several distributed monotone repositories. See the @@ -8,7 +8,7 @@ See this forum post on i2p monotone for more information on how to get started and check out the source anonymously. There is also a quick-start guide on the -new developer's page. +new developer's page.

    @@ -21,7 +21,7 @@ The i2p source code branch is "i2p.i2p". The following is a detailed guide by Complication.

    -  {% include "transition-guide.txt" %}
    +  {% include "site/misc/transition-guide.txt" %}
     
    {% endblock %} diff --git a/www.i2p2/pages/old/transition-guide.txt b/i2p2www/pages/site/misc/transition-guide.txt similarity index 100% rename from www.i2p2/pages/old/transition-guide.txt rename to i2p2www/pages/site/misc/transition-guide.txt diff --git a/www.i2p2/pages/old/upgrade-0.6.1.30.html b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html similarity index 93% rename from www.i2p2/pages/old/upgrade-0.6.1.30.html rename to i2p2www/pages/site/misc/upgrade-0.6.1.30.html index 5adc7362..0d5b3e2c 100644 --- a/www.i2p2/pages/old/upgrade-0.6.1.30.html +++ b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html @@ -1,4 +1,4 @@ -{% extends "_layout.html" %} +{% extends "global/layout.html" %} {% block title %}How to Upgrade from 0.6.1.30 and Earlier{% endblock %} {% block content %}

    @@ -6,7 +6,7 @@ 2008-02-05: Upgrading from 0.6.1.30 and Earlier Releases

    Since i2p's lead developer -has gone AWOL, +has gone AWOL, we do not have his update signing key or access to www.i2p[.net] or dev.i2p[.net]. Complication and zzz have generated new signing keys, and they and Amiga are providing @@ -18,7 +18,7 @@ the latest release. We recommend the automated process as it will verify the key of the signed update file. If you do not make these changes, you may manually download the i2pupdate.zip file from -the download page. +the download page.

    1. On configupdate.jsp: diff --git a/www.i2p2/pages/old/invisiblenet.html b/www.i2p2/pages/old/invisiblenet.html deleted file mode 100644 index de48244f..00000000 --- a/www.i2p2/pages/old/invisiblenet.html +++ /dev/null @@ -1,23 +0,0 @@ -{% extends "_layout.html" %} -{% block title %}Old Documents{% endblock %} -{% block content %} - -Following is a list of documents originally on www.invisiblenet.net/i2p/ and -rescued via the -Wayback Machine. -They are quite dated and may or may not be accurate. -However, the I2CP and I2NP documents in particular have some good information. - - -

      Index of /i2p

      -
      Name                    Last modified       Size
      -
      -I2CP_spec.pdf 03-Sep-2003 12:49 119k -I2NP_spec.pdf 03-Sep-2003 12:49 356k -datastructures.pdf 03-Sep-2003 12:49 149k -i2p_philosophy.pdf 03-Sep-2003 12:52 126k -polling_http_transpo..> 03-Sep-2003 12:49 189k -
      - - -{% endblock %} From e6287d4edb5cff748b44cc323a821a5b9b7e4602 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 02:07:10 +0000 Subject: [PATCH 195/498] Fixed a url-building error on support/faq --- i2p2www/pages/site/support/faq.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/site/support/faq.html b/i2p2www/pages/site/support/faq.html index 82941ca6..b455f71c 100644 --- a/i2p2www/pages/site/support/faq.html +++ b/i2p2www/pages/site/support/faq.html @@ -198,13 +198,13 @@ All routers adjust dynamically to changing network conditions and demands. If you are running release 0.6.1.31 or later, you probably don't need to do this. If you are running release 0.6.1.26 or earlier, either follow the manual reseed instructions below - or install the latest release. + or install the latest release. Possible alternate method - add wrapper.java.additional.5=-Di2p.reseedURL=http://netdb.i2p2.de/ to wrapper.config, shutdown the router completely, then start again, then click "reseed". Let us know if this works.

      -

      ...but you *really* should upgrade to the latest version.

      +

      ...but you *really* should upgrade to the latest version.

      My router has very few active peers, is this OK? (link)

      From 766c8059f4cdddf0776f7d0f9d1f71a09abdd91d Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 02:53:11 +0000 Subject: [PATCH 196/498] Keep the current website's title for the front page (to help keep its existing page rank for "anonymous network") --- i2p2www/pages/global/layout.html | 2 +- i2p2www/pages/site/index.html | 1 + 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index 9c8a7b44..1d71c19f 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -3,7 +3,7 @@ - {% block title %}{% endblock %} - I2P + {% block title_outer %}{% block title %}{% endblock %} - I2P{% endblock %} diff --git a/i2p2www/pages/site/index.html b/i2p2www/pages/site/index.html index 1b6820f1..605a0291 100644 --- a/i2p2www/pages/site/index.html +++ b/i2p2www/pages/site/index.html @@ -1,4 +1,5 @@ {% extends "global/layout.html" %} +{% block title_outer %}{% trans %}I2P Anonymous Network{% endtrans %}{% endblock %} {% block title %}{% trans %}The Invisible Internet Project{% endtrans %}{% endblock %} {% block content_outer %}
      From fe4852a9eb11ba625d78d8771d6d81d4728a8f8a Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 04:08:41 +0000 Subject: [PATCH 197/498] Display current language flag next to the Language menu (for easier identification) --- i2p2www/pages/global/lang.html | 2 +- i2p2www/pages/global/nav.html | 2 +- i2p2www/static/images/flags/{us.png => en.png} | Bin 3 files changed, 2 insertions(+), 2 deletions(-) rename i2p2www/static/images/flags/{us.png => en.png} (100%) diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html index 8e3d6572..a7f9a9d3 100644 --- a/i2p2www/pages/global/lang.html +++ b/i2p2www/pages/global/lang.html @@ -1,5 +1,5 @@
        -
      • English
      • +
      • English
      • Castellano
      • Chinese
      • Deutsch
      • diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index c4912aac..31b58380 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -130,7 +130,7 @@
      • {{ _('Task list') }}
    2. -
    3. {{ _('Language') }} +
    4. {{ _('Language') }} {% include "global/lang.html" %}
    5. diff --git a/i2p2www/static/images/flags/us.png b/i2p2www/static/images/flags/en.png similarity index 100% rename from i2p2www/static/images/flags/us.png rename to i2p2www/static/images/flags/en.png From 8b5633c8810d4ae5abef9fab84c8b5c2906cd04b Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 04:29:43 +0000 Subject: [PATCH 198/498] Added rel="alternate" hreflang="XX" to language changer links AFAICT these attributes are meant to be on tags, but it shouldn't hurt having them here instead (though if it doesn't help and tags need to be added, then this commit should probably be reverted). --- i2p2www/pages/global/lang.html | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html index a7f9a9d3..dab824fe 100644 --- a/i2p2www/pages/global/lang.html +++ b/i2p2www/pages/global/lang.html @@ -1,14 +1,14 @@
        -
      • English
      • -
      • Castellano
      • -
      • Chinese
      • -
      • Deutsch
      • -
      • Français
      • -
      • Italiano
      • -
      • Nederlands
      • -
      • Russian
      • -
      • Svenska
      • -
      • Czech
      • -
      • Arabic
      • -
      • Greek
      • +
      • English
      • +
      • Castellano
      • +
      • Chinese
      • +
      • Deutsch
      • +
      • Français
      • +
      • Italiano
      • +
      • Nederlands
      • +
      • Russian
      • +
      • Svenska
      • +
      • Czech
      • +
      • Arabic
      • +
      • Greek
      From c9a4c5e77cb765e4f89491f5add4f40514d8a1c4 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 04:51:36 +0000 Subject: [PATCH 199/498] Add canonical link to of each page --- i2p2www/__init__.py | 10 +++++++++- i2p2www/pages/global/layout.html | 1 + 2 files changed, 10 insertions(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index e1a572c5..328917f5 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -18,6 +18,8 @@ from helpers import Pagination CURRENT_I2P_VERSION = '0.9.4' +CANONICAL_DOMAIN = 'www.i2p2.de' + TEMPLATE_DIR = os.path.join(os.path.dirname(__file__), 'pages') STATIC_DIR = os.path.join(os.path.dirname(__file__), 'static') @@ -127,6 +129,11 @@ def restructuredtext(value): @app.context_processor def utility_processor(): + # Provide the canonical link to the current page + def get_canonical_link(): + protocol = request.url.split('//')[0] + return protocol + '//' + CANONICAL_DOMAIN + request.path + # Convert an I2P url to an equivalent clearnet one i2ptoclear = { 'www.i2p2.i2p': 'www.i2p2.de', @@ -163,7 +170,8 @@ def utility_processor(): return dict(i2pconv=convert_url_to_clearnet, url_for_other_page=url_for_other_page, - change_theme=change_theme) + change_theme=change_theme, + canonical=get_canonical_link) ################ diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index 1d71c19f..494d2566 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -4,6 +4,7 @@ {% block title_outer %}{% block title %}{% endblock %} - I2P{% endblock %} + From 254fab592cf8ce9bdd22f84557340f4db1d6511c Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 04:58:44 +0000 Subject: [PATCH 200/498] Removed "site/" from the main site URLs It seems that Werkzeug doesn't get confused between /en/blog/ and /en/ --- i2p2www/__init__.py | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 328917f5..4342c142 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -204,8 +204,8 @@ def main_index(): return redirect(url_for('site_show', lang='en')) # Site pages -@app.route('//site/', defaults={'page': 'index'}) -@app.route('//site/') +@app.route('//', defaults={'page': 'index'}) +@app.route('//') def site_show(page): if page.endswith('.html'): return redirect(url_for('site_show', page=page[:-5])) From 8f9e8fb178ded11160000c8f89f2a804114399ba Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 05:28:01 +0000 Subject: [PATCH 201/498] Added LazyView from http://flask.pocoo.org/docs/patterns/lazyloading/ to helpers --- i2p2www/helpers.py | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/i2p2www/helpers.py b/i2p2www/helpers.py index bbd8a656..aabf4a5e 100644 --- a/i2p2www/helpers.py +++ b/i2p2www/helpers.py @@ -1,4 +1,17 @@ from math import ceil +from werkzeug import import_string, cached_property + +class LazyView(object): + def __init__(self, import_name): + self.__module__, self.__name__ = import_name.rsplit('.', 1) + self.import_name = import_name + + @cached_property + def view(self): + return import_string(self.import_name) + + def __call__(self, *args, **kwargs): + return self.view(*args, **kwargs) class Pagination(object): def __init__(self, page, per_page, total_count): From 785f627d7a0384648e87244b5eddf3d1111283b0 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 06:53:59 +0000 Subject: [PATCH 202/498] Reorganized site and blog views and helpers to use LazyView This increases the speed of the site by not requiring the site and blog code to be imported on every request - just those that are relevant. It also splits the code into modules which are easier to work with. --- i2p2www/__init__.py | 181 ++++----------------------------------- i2p2www/blog/__init__.py | 0 i2p2www/blog/helpers.py | 82 ++++++++++++++++++ i2p2www/blog/views.py | 44 ++++++++++ i2p2www/helpers.py | 12 +++ 5 files changed, 157 insertions(+), 162 deletions(-) create mode 100644 i2p2www/blog/__init__.py create mode 100644 i2p2www/blog/helpers.py create mode 100644 i2p2www/blog/views.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 4342c142..8ebd1baa 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -14,7 +14,7 @@ try: except ImportError: import simplejson as json -from helpers import Pagination +from helpers import LazyView, Pagination CURRENT_I2P_VERSION = '0.9.4' @@ -36,6 +36,24 @@ app.debug = bool(os.environ.get('APP_DEBUG', 'False')) babel = Babel(app) +###### +# URLs + +def url(url_rule, import_name, **options): + view = LazyView('i2p2www.' + import_name) + app.add_url_rule(url_rule, view_func=view, **options) + +url('/', 'views.main_index') +url('//', 'views.site_show', defaults={'page': 'index'}) +url('//', 'views.site_show') + +url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) +url('//blog/page/', 'blog.views.blog_index') +url('//blog/entry/', 'blog.views.blog_entry') +url('//feed/blog/rss', 'blog.views.blog_rss') +url('//feed/blog/atom', 'blog.views.blog_atom') + + ################# # Babel selectors @@ -186,50 +204,6 @@ def server_error(error): return render_template('global/error_500.html'), 500 -######################## -# General helper methods - -def get_for_page(items, page, per_page): - from_item = (page-1)*per_page - to_item = page*per_page - return items[from_item:to_item] - - -####################### -# General page handlers - -# Index - redirects to en homepage -@app.route('/') -def main_index(): - return redirect(url_for('site_show', lang='en')) - -# Site pages -@app.route('//', defaults={'page': 'index'}) -@app.route('//') -def site_show(page): - if page.endswith('.html'): - return redirect(url_for('site_show', page=page[:-5])) - name = 'site/%s.html' % page - page_file = safe_join(TEMPLATE_DIR, name) - - if not os.path.exists(page_file): - # Could be a directory, so try index.html - name = 'site/%s/index.html' % page - page_file = safe_join(TEMPLATE_DIR, name) - if not os.path.exists(page_file): - # bah! those damn users all the time! - abort(404) - - options = { - 'page': page, - } - if (page == 'index'): - options['blog_entries'] = get_blog_entries(8) - - # hah! - return render_template(name, **options) - - ######################## # Meeting helper methods @@ -446,123 +420,6 @@ def downloads_redirect(protocol, file, mirror): return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) -##################### -# Blog helper methods - -def get_blog_feed_items(num=0): - entries = get_blog_entries(num) - items = [] - for entry in entries: - parts = render_blog_entry(entry[0]) - if parts: - a = {} - a['title'] = parts['title'] - a['content'] = parts['fragment'] - a['url'] = url_for('blog_entry', lang=g.lang, slug=entry[0]) - a['updated'] = datetime.datetime.strptime(entry[1], '%Y-%m-%d') - items.append(a) - return items - -def get_blog_entries(num=0): - """ - Returns the latest #num valid entries sorted by date, or all slugs if num=0. - """ - slugs = get_blog_slugs(num) - entries= [] - for slug in slugs: - date = get_date_from_slug(slug) - titlepart = slug.rsplit('/', 1)[1] - title = ' '.join(titlepart.split('_')) - entries.append((slug, date, title)) - return entries - -def get_blog_slugs(num=0): - """ - Returns the latest #num valid slugs sorted by date, or all slugs if num=0. - """ - # list of slugs - slugs=[] - # walk over all directories/files - for v in os.walk(BLOG_DIR): - # iterate over all files - slugbase = os.path.relpath(v[0], BLOG_DIR) - for f in v[2]: - # ignore all non-.rst files - if not f.endswith('.rst'): - continue - slugs.append(safe_join(slugbase, f[:-4])) - slugs.sort() - slugs.reverse() - if (num > 0): - return slugs[:num] - return slugs - -def get_date_from_slug(slug): - parts = slug.split('/') - return "%s-%s-%s" % (parts[0], parts[1], parts[2]) - -def render_blog_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") - - -############### -# Blog handlers - -@app.route('//blog/', defaults={'page': 1}) -@app.route('//blog/page/') -def blog_index(page): - all_entries = get_blog_entries() - entries = get_for_page(all_entries, page, BLOG_ENTRIES_PER_PAGE) - if not entries and page != 1: - abort(404) - pagination = Pagination(page, BLOG_ENTRIES_PER_PAGE, len(all_entries)) - return render_template('blog/index.html', pagination=pagination, entries=entries) - -@app.route('//blog/entry/') -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'], slug=slug) - else: - abort(404) - -@app.route('//feed/blog/rss') -def blog_rss(): - # TODO: implement - pass - -@app.route('//feed/blog/atom') -def blog_atom(): - # TODO: Only output beginning of each blog entry - feed = AtomFeed('I2P Blog', feed_url=request.url, url=request.url_root) - items = get_blog_feed_items(10) - for item in items: - feed.add(item['title'], - item['content'], - content_type='html', - url=item['url'], - updated=item['updated']) - return feed.get_response() - - ############ # Root files diff --git a/i2p2www/blog/__init__.py b/i2p2www/blog/__init__.py new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/blog/helpers.py b/i2p2www/blog/helpers.py new file mode 100644 index 00000000..15a19a90 --- /dev/null +++ b/i2p2www/blog/helpers.py @@ -0,0 +1,82 @@ +import codecs +import datetime +from docutils.core import publish_parts +from flask import abort, g, safe_join, url_for +import os +import os.path + +from i2p2www import BLOG_DIR + + +##################### +# Blog helper methods + +def get_blog_feed_items(num=0): + entries = get_blog_entries(num) + items = [] + for entry in entries: + parts = render_blog_entry(entry[0]) + if parts: + a = {} + a['title'] = parts['title'] + a['content'] = parts['fragment'] + a['url'] = url_for('blog_entry', lang=g.lang, slug=entry[0]) + a['updated'] = datetime.datetime.strptime(entry[1], '%Y-%m-%d') + items.append(a) + return items + +def get_blog_entries(num=0): + """ + Returns the latest #num valid entries sorted by date, or all slugs if num=0. + """ + slugs = get_blog_slugs(num) + entries= [] + for slug in slugs: + date = get_date_from_slug(slug) + titlepart = slug.rsplit('/', 1)[1] + title = ' '.join(titlepart.split('_')) + entries.append((slug, date, title)) + return entries + +def get_blog_slugs(num=0): + """ + Returns the latest #num valid slugs sorted by date, or all slugs if num=0. + """ + # list of slugs + slugs=[] + # walk over all directories/files + for v in os.walk(BLOG_DIR): + # iterate over all files + slugbase = os.path.relpath(v[0], BLOG_DIR) + for f in v[2]: + # ignore all non-.rst files + if not f.endswith('.rst'): + continue + slugs.append(safe_join(slugbase, f[:-4])) + slugs.sort() + slugs.reverse() + if (num > 0): + return slugs[:num] + return slugs + +def get_date_from_slug(slug): + parts = slug.split('/') + return "%s-%s-%s" % (parts[0], parts[1], parts[2]) + +def render_blog_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") diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py new file mode 100644 index 00000000..a61d6c36 --- /dev/null +++ b/i2p2www/blog/views.py @@ -0,0 +1,44 @@ +from flask import request, abort, render_template +from werkzeug.contrib.atom import AtomFeed + +from i2p2www import BLOG_ENTRIES_PER_PAGE +from i2p2www.blog.helpers import get_blog_entries, get_blog_feed_items, render_blog_entry +from i2p2www.helpers import Pagination, get_for_page + + +############ +# Blog views + +def blog_index(page): + all_entries = get_blog_entries() + entries = get_for_page(all_entries, page, BLOG_ENTRIES_PER_PAGE) + if not entries and page != 1: + abort(404) + pagination = Pagination(page, BLOG_ENTRIES_PER_PAGE, len(all_entries)) + return render_template('blog/index.html', pagination=pagination, entries=entries) + +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'], slug=slug) + else: + abort(404) + +def blog_rss(): + # TODO: implement + pass + +def blog_atom(): + # TODO: Only output beginning of each blog entry + feed = AtomFeed('I2P Blog', feed_url=request.url, url=request.url_root) + items = get_blog_feed_items(10) + for item in items: + feed.add(item['title'], + item['content'], + content_type='html', + url=item['url'], + updated=item['updated']) + return feed.get_response() diff --git a/i2p2www/helpers.py b/i2p2www/helpers.py index aabf4a5e..04bd49ee 100644 --- a/i2p2www/helpers.py +++ b/i2p2www/helpers.py @@ -1,6 +1,18 @@ from math import ceil from werkzeug import import_string, cached_property +######################## +# General helper methods + +def get_for_page(items, page, per_page): + from_item = (page-1)*per_page + to_item = page*per_page + return items[from_item:to_item] + + +######################## +# General helper classes + class LazyView(object): def __init__(self, import_name): self.__module__, self.__name__ = import_name.rsplit('.', 1) From 3ff5e146dcf5526801091aa8e12a188afdf057ac Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 06:58:07 +0000 Subject: [PATCH 203/498] Moved meetings/* to meetings/logs/ (ready for splitting out meetings code) --- i2p2www/__init__.py | 2 +- i2p2www/meetings/{ => logs}/1.log | 0 i2p2www/meetings/{ => logs}/1.rst | 0 i2p2www/meetings/{ => logs}/10.log | 0 i2p2www/meetings/{ => logs}/10.rst | 0 i2p2www/meetings/{ => logs}/100.log | 0 i2p2www/meetings/{ => logs}/100.rst | 0 i2p2www/meetings/{ => logs}/101.log | 0 i2p2www/meetings/{ => logs}/101.rst | 0 i2p2www/meetings/{ => logs}/102.log | 0 i2p2www/meetings/{ => logs}/102.rst | 0 i2p2www/meetings/{ => logs}/103.log | 0 i2p2www/meetings/{ => logs}/103.rst | 0 i2p2www/meetings/{ => logs}/104.log | 0 i2p2www/meetings/{ => logs}/104.rst | 0 i2p2www/meetings/{ => logs}/105.log | 0 i2p2www/meetings/{ => logs}/105.rst | 0 i2p2www/meetings/{ => logs}/106.log | 0 i2p2www/meetings/{ => logs}/106.rst | 0 i2p2www/meetings/{ => logs}/107.log | 0 i2p2www/meetings/{ => logs}/107.rst | 0 i2p2www/meetings/{ => logs}/108.log | 0 i2p2www/meetings/{ => logs}/108.rst | 0 i2p2www/meetings/{ => logs}/109.log | 0 i2p2www/meetings/{ => logs}/109.rst | 0 i2p2www/meetings/{ => logs}/11.log | 0 i2p2www/meetings/{ => logs}/11.rst | 0 i2p2www/meetings/{ => logs}/110.log | 0 i2p2www/meetings/{ => logs}/110.rst | 0 i2p2www/meetings/{ => logs}/111.log | 0 i2p2www/meetings/{ => logs}/111.rst | 0 i2p2www/meetings/{ => logs}/112.log | 0 i2p2www/meetings/{ => logs}/112.rst | 0 i2p2www/meetings/{ => logs}/113.log | 0 i2p2www/meetings/{ => logs}/113.rst | 0 i2p2www/meetings/{ => logs}/114.log | 0 i2p2www/meetings/{ => logs}/114.rst | 0 i2p2www/meetings/{ => logs}/115.log | 0 i2p2www/meetings/{ => logs}/115.rst | 0 i2p2www/meetings/{ => logs}/116.log | 0 i2p2www/meetings/{ => logs}/116.rst | 0 i2p2www/meetings/{ => logs}/117.log | 0 i2p2www/meetings/{ => logs}/117.rst | 0 i2p2www/meetings/{ => logs}/118.log | 0 i2p2www/meetings/{ => logs}/118.rst | 0 i2p2www/meetings/{ => logs}/119.log | 0 i2p2www/meetings/{ => logs}/119.rst | 0 i2p2www/meetings/{ => logs}/12.log | 0 i2p2www/meetings/{ => logs}/12.rst | 0 i2p2www/meetings/{ => logs}/120.log | 0 i2p2www/meetings/{ => logs}/120.rst | 0 i2p2www/meetings/{ => logs}/121.log | 0 i2p2www/meetings/{ => logs}/121.rst | 0 i2p2www/meetings/{ => logs}/122.log | 0 i2p2www/meetings/{ => logs}/122.rst | 0 i2p2www/meetings/{ => logs}/123.log | 0 i2p2www/meetings/{ => logs}/123.rst | 0 i2p2www/meetings/{ => logs}/124.log | 0 i2p2www/meetings/{ => logs}/124.rst | 0 i2p2www/meetings/{ => logs}/125.log | 0 i2p2www/meetings/{ => logs}/125.rst | 0 i2p2www/meetings/{ => logs}/126.log | 0 i2p2www/meetings/{ => logs}/126.rst | 0 i2p2www/meetings/{ => logs}/127.log | 0 i2p2www/meetings/{ => logs}/127.rst | 0 i2p2www/meetings/{ => logs}/128.log | 0 i2p2www/meetings/{ => logs}/128.rst | 0 i2p2www/meetings/{ => logs}/129.log | 0 i2p2www/meetings/{ => logs}/129.rst | 0 i2p2www/meetings/{ => logs}/130.log | 0 i2p2www/meetings/{ => logs}/130.rst | 0 i2p2www/meetings/{ => logs}/131.log | 0 i2p2www/meetings/{ => logs}/131.rst | 0 i2p2www/meetings/{ => logs}/132.log | 0 i2p2www/meetings/{ => logs}/132.rst | 0 i2p2www/meetings/{ => logs}/133.log | 0 i2p2www/meetings/{ => logs}/133.rst | 0 i2p2www/meetings/{ => logs}/134.log | 0 i2p2www/meetings/{ => logs}/134.rst | 0 i2p2www/meetings/{ => logs}/135.log | 0 i2p2www/meetings/{ => logs}/135.rst | 0 i2p2www/meetings/{ => logs}/136.log | 0 i2p2www/meetings/{ => logs}/136.rst | 0 i2p2www/meetings/{ => logs}/137.log | 0 i2p2www/meetings/{ => logs}/137.rst | 0 i2p2www/meetings/{ => logs}/138.log | 0 i2p2www/meetings/{ => logs}/138.rst | 0 i2p2www/meetings/{ => logs}/139.log | 0 i2p2www/meetings/{ => logs}/139.rst | 0 i2p2www/meetings/{ => logs}/140.log | 0 i2p2www/meetings/{ => logs}/140.rst | 0 i2p2www/meetings/{ => logs}/141.log | 0 i2p2www/meetings/{ => logs}/141.rst | 0 i2p2www/meetings/{ => logs}/142.log | 0 i2p2www/meetings/{ => logs}/142.rst | 0 i2p2www/meetings/{ => logs}/143.log | 0 i2p2www/meetings/{ => logs}/143.rst | 0 i2p2www/meetings/{ => logs}/144.log | 0 i2p2www/meetings/{ => logs}/144.rst | 0 i2p2www/meetings/{ => logs}/145.log | 0 i2p2www/meetings/{ => logs}/145.rst | 0 i2p2www/meetings/{ => logs}/146.log | 0 i2p2www/meetings/{ => logs}/146.rst | 0 i2p2www/meetings/{ => logs}/147.log | 0 i2p2www/meetings/{ => logs}/147.rst | 0 i2p2www/meetings/{ => logs}/148.log | 0 i2p2www/meetings/{ => logs}/148.rst | 0 i2p2www/meetings/{ => logs}/149.log | 0 i2p2www/meetings/{ => logs}/149.rst | 0 i2p2www/meetings/{ => logs}/15.log | 0 i2p2www/meetings/{ => logs}/15.rst | 0 i2p2www/meetings/{ => logs}/150.log | 0 i2p2www/meetings/{ => logs}/150.rst | 0 i2p2www/meetings/{ => logs}/151.log | 0 i2p2www/meetings/{ => logs}/151.rst | 0 i2p2www/meetings/{ => logs}/152.log | 0 i2p2www/meetings/{ => logs}/152.rst | 0 i2p2www/meetings/{ => logs}/153.log | 0 i2p2www/meetings/{ => logs}/153.rst | 0 i2p2www/meetings/{ => logs}/154.log | 0 i2p2www/meetings/{ => logs}/154.rst | 0 i2p2www/meetings/{ => logs}/155.log | 0 i2p2www/meetings/{ => logs}/155.rst | 0 i2p2www/meetings/{ => logs}/156.log | 0 i2p2www/meetings/{ => logs}/156.rst | 0 i2p2www/meetings/{ => logs}/157.log | 0 i2p2www/meetings/{ => logs}/157.rst | 0 i2p2www/meetings/{ => logs}/158.log | 0 i2p2www/meetings/{ => logs}/158.rst | 0 i2p2www/meetings/{ => logs}/159.log | 0 i2p2www/meetings/{ => logs}/159.rst | 0 i2p2www/meetings/{ => logs}/160.log | 0 i2p2www/meetings/{ => logs}/160.rst | 0 i2p2www/meetings/{ => logs}/161.log | 0 i2p2www/meetings/{ => logs}/161.rst | 0 i2p2www/meetings/{ => logs}/162.log | 0 i2p2www/meetings/{ => logs}/162.rst | 0 i2p2www/meetings/{ => logs}/163.log | 0 i2p2www/meetings/{ => logs}/163.rst | 0 i2p2www/meetings/{ => logs}/164.log | 0 i2p2www/meetings/{ => logs}/164.rst | 0 i2p2www/meetings/{ => logs}/165.log | 0 i2p2www/meetings/{ => logs}/165.rst | 0 i2p2www/meetings/{ => logs}/166.log | 0 i2p2www/meetings/{ => logs}/166.rst | 0 i2p2www/meetings/{ => logs}/167.log | 0 i2p2www/meetings/{ => logs}/167.rst | 0 i2p2www/meetings/{ => logs}/168.log | 0 i2p2www/meetings/{ => logs}/168.rst | 0 i2p2www/meetings/{ => logs}/170.log | 0 i2p2www/meetings/{ => logs}/170.rst | 0 i2p2www/meetings/{ => logs}/171.log | 0 i2p2www/meetings/{ => logs}/171.rst | 0 i2p2www/meetings/{ => logs}/172.log | 0 i2p2www/meetings/{ => logs}/172.rst | 0 i2p2www/meetings/{ => logs}/173.log | 0 i2p2www/meetings/{ => logs}/173.rst | 0 i2p2www/meetings/{ => logs}/174.log | 0 i2p2www/meetings/{ => logs}/174.rst | 0 i2p2www/meetings/{ => logs}/175.log | 0 i2p2www/meetings/{ => logs}/175.rst | 0 i2p2www/meetings/{ => logs}/176.log | 0 i2p2www/meetings/{ => logs}/176.rst | 0 i2p2www/meetings/{ => logs}/177.log | 0 i2p2www/meetings/{ => logs}/177.rst | 0 i2p2www/meetings/{ => logs}/178.log | 0 i2p2www/meetings/{ => logs}/178.rst | 0 i2p2www/meetings/{ => logs}/179.log | 0 i2p2www/meetings/{ => logs}/179.rst | 0 i2p2www/meetings/{ => logs}/18.log | 0 i2p2www/meetings/{ => logs}/18.rst | 0 i2p2www/meetings/{ => logs}/180.log | 0 i2p2www/meetings/{ => logs}/180.rst | 0 i2p2www/meetings/{ => logs}/181.log | 0 i2p2www/meetings/{ => logs}/181.rst | 0 i2p2www/meetings/{ => logs}/182.log | 0 i2p2www/meetings/{ => logs}/182.rst | 0 i2p2www/meetings/{ => logs}/183.log | 0 i2p2www/meetings/{ => logs}/183.rst | 0 i2p2www/meetings/{ => logs}/184.log | 0 i2p2www/meetings/{ => logs}/184.rst | 0 i2p2www/meetings/{ => logs}/185.log | 0 i2p2www/meetings/{ => logs}/185.rst | 0 i2p2www/meetings/{ => logs}/186.log | 0 i2p2www/meetings/{ => logs}/186.rst | 0 i2p2www/meetings/{ => logs}/187.log | 0 i2p2www/meetings/{ => logs}/187.rst | 0 i2p2www/meetings/{ => logs}/188.log | 0 i2p2www/meetings/{ => logs}/188.rst | 0 i2p2www/meetings/{ => logs}/189.log | 0 i2p2www/meetings/{ => logs}/189.rst | 0 i2p2www/meetings/{ => logs}/190.log | 0 i2p2www/meetings/{ => logs}/190.rst | 0 i2p2www/meetings/{ => logs}/191.log | 0 i2p2www/meetings/{ => logs}/191.rst | 0 i2p2www/meetings/{ => logs}/192.log | 0 i2p2www/meetings/{ => logs}/192.rst | 0 i2p2www/meetings/{ => logs}/193.log | 0 i2p2www/meetings/{ => logs}/193.rst | 0 i2p2www/meetings/{ => logs}/194.log | 0 i2p2www/meetings/{ => logs}/194.rst | 0 i2p2www/meetings/{ => logs}/195.log | 0 i2p2www/meetings/{ => logs}/195.rst | 0 i2p2www/meetings/{ => logs}/196.log | 0 i2p2www/meetings/{ => logs}/196.rst | 0 i2p2www/meetings/{ => logs}/197.log | 0 i2p2www/meetings/{ => logs}/197.rst | 0 i2p2www/meetings/{ => logs}/198.log | 0 i2p2www/meetings/{ => logs}/198.rst | 0 i2p2www/meetings/{ => logs}/199.log | 0 i2p2www/meetings/{ => logs}/199.rst | 0 i2p2www/meetings/{ => logs}/2.log | 0 i2p2www/meetings/{ => logs}/2.rst | 0 i2p2www/meetings/{ => logs}/20.log | 0 i2p2www/meetings/{ => logs}/20.rst | 0 i2p2www/meetings/{ => logs}/200.log | 0 i2p2www/meetings/{ => logs}/200.rst | 0 i2p2www/meetings/{ => logs}/201.log | 0 i2p2www/meetings/{ => logs}/201.rst | 0 i2p2www/meetings/{ => logs}/202.log | 0 i2p2www/meetings/{ => logs}/202.rst | 0 i2p2www/meetings/{ => logs}/203.log | 0 i2p2www/meetings/{ => logs}/203.rst | 0 i2p2www/meetings/{ => logs}/204.log | 0 i2p2www/meetings/{ => logs}/204.rst | 0 i2p2www/meetings/{ => logs}/205.log | 0 i2p2www/meetings/{ => logs}/205.rst | 0 i2p2www/meetings/{ => logs}/206.log | 0 i2p2www/meetings/{ => logs}/206.rst | 0 i2p2www/meetings/{ => logs}/207.log | 0 i2p2www/meetings/{ => logs}/207.rst | 0 i2p2www/meetings/{ => logs}/208.log | 0 i2p2www/meetings/{ => logs}/208.rst | 0 i2p2www/meetings/{ => logs}/209.log | 0 i2p2www/meetings/{ => logs}/209.rst | 0 i2p2www/meetings/{ => logs}/21.log | 0 i2p2www/meetings/{ => logs}/21.rst | 0 i2p2www/meetings/{ => logs}/210.log | 0 i2p2www/meetings/{ => logs}/210.rst | 0 i2p2www/meetings/{ => logs}/211.log | 0 i2p2www/meetings/{ => logs}/211.rst | 0 i2p2www/meetings/{ => logs}/212.log | 0 i2p2www/meetings/{ => logs}/212.rst | 0 i2p2www/meetings/{ => logs}/22.log | 0 i2p2www/meetings/{ => logs}/22.rst | 0 i2p2www/meetings/{ => logs}/23.log | 0 i2p2www/meetings/{ => logs}/23.rst | 0 i2p2www/meetings/{ => logs}/25.log | 0 i2p2www/meetings/{ => logs}/25.rst | 0 i2p2www/meetings/{ => logs}/26.log | 0 i2p2www/meetings/{ => logs}/26.rst | 0 i2p2www/meetings/{ => logs}/28.log | 0 i2p2www/meetings/{ => logs}/28.rst | 0 i2p2www/meetings/{ => logs}/29.log | 0 i2p2www/meetings/{ => logs}/29.rst | 0 i2p2www/meetings/{ => logs}/3.log | 0 i2p2www/meetings/{ => logs}/3.rst | 0 i2p2www/meetings/{ => logs}/30.log | 0 i2p2www/meetings/{ => logs}/30.rst | 0 i2p2www/meetings/{ => logs}/31.log | 0 i2p2www/meetings/{ => logs}/31.rst | 0 i2p2www/meetings/{ => logs}/32.log | 0 i2p2www/meetings/{ => logs}/32.rst | 0 i2p2www/meetings/{ => logs}/33.log | 0 i2p2www/meetings/{ => logs}/33.rst | 0 i2p2www/meetings/{ => logs}/34.log | 0 i2p2www/meetings/{ => logs}/34.rst | 0 i2p2www/meetings/{ => logs}/35.log | 0 i2p2www/meetings/{ => logs}/35.rst | 0 i2p2www/meetings/{ => logs}/4.log | 0 i2p2www/meetings/{ => logs}/4.rst | 0 i2p2www/meetings/{ => logs}/47.log | 0 i2p2www/meetings/{ => logs}/47.rst | 0 i2p2www/meetings/{ => logs}/49.log | 0 i2p2www/meetings/{ => logs}/49.rst | 0 i2p2www/meetings/{ => logs}/50.log | 0 i2p2www/meetings/{ => logs}/50.rst | 0 i2p2www/meetings/{ => logs}/51.log | 0 i2p2www/meetings/{ => logs}/51.rst | 0 i2p2www/meetings/{ => logs}/52.log | 0 i2p2www/meetings/{ => logs}/52.rst | 0 i2p2www/meetings/{ => logs}/53.log | 0 i2p2www/meetings/{ => logs}/53.rst | 0 i2p2www/meetings/{ => logs}/54.log | 0 i2p2www/meetings/{ => logs}/54.rst | 0 i2p2www/meetings/{ => logs}/55.log | 0 i2p2www/meetings/{ => logs}/55.rst | 0 i2p2www/meetings/{ => logs}/56.log | 0 i2p2www/meetings/{ => logs}/56.rst | 0 i2p2www/meetings/{ => logs}/57.log | 0 i2p2www/meetings/{ => logs}/57.rst | 0 i2p2www/meetings/{ => logs}/58.log | 0 i2p2www/meetings/{ => logs}/58.rst | 0 i2p2www/meetings/{ => logs}/59.log | 0 i2p2www/meetings/{ => logs}/59.rst | 0 i2p2www/meetings/{ => logs}/60.log | 0 i2p2www/meetings/{ => logs}/60.rst | 0 i2p2www/meetings/{ => logs}/61.log | 0 i2p2www/meetings/{ => logs}/61.rst | 0 i2p2www/meetings/{ => logs}/62.log | 0 i2p2www/meetings/{ => logs}/62.rst | 0 i2p2www/meetings/{ => logs}/63.log | 0 i2p2www/meetings/{ => logs}/63.rst | 0 i2p2www/meetings/{ => logs}/64.log | 0 i2p2www/meetings/{ => logs}/64.rst | 0 i2p2www/meetings/{ => logs}/65.log | 0 i2p2www/meetings/{ => logs}/65.rst | 0 i2p2www/meetings/{ => logs}/66.log | 0 i2p2www/meetings/{ => logs}/66.rst | 0 i2p2www/meetings/{ => logs}/68.log | 0 i2p2www/meetings/{ => logs}/68.rst | 0 i2p2www/meetings/{ => logs}/69.log | 0 i2p2www/meetings/{ => logs}/69.rst | 0 i2p2www/meetings/{ => logs}/7.log | 0 i2p2www/meetings/{ => logs}/7.rst | 0 i2p2www/meetings/{ => logs}/70.log | 0 i2p2www/meetings/{ => logs}/70.rst | 0 i2p2www/meetings/{ => logs}/71.log | 0 i2p2www/meetings/{ => logs}/71.rst | 0 i2p2www/meetings/{ => logs}/72.log | 0 i2p2www/meetings/{ => logs}/72.rst | 0 i2p2www/meetings/{ => logs}/73.log | 0 i2p2www/meetings/{ => logs}/73.rst | 0 i2p2www/meetings/{ => logs}/74.log | 0 i2p2www/meetings/{ => logs}/74.rst | 0 i2p2www/meetings/{ => logs}/75.log | 0 i2p2www/meetings/{ => logs}/75.rst | 0 i2p2www/meetings/{ => logs}/76.log | 0 i2p2www/meetings/{ => logs}/76.rst | 0 i2p2www/meetings/{ => logs}/77.log | 0 i2p2www/meetings/{ => logs}/77.rst | 0 i2p2www/meetings/{ => logs}/78.log | 0 i2p2www/meetings/{ => logs}/78.rst | 0 i2p2www/meetings/{ => logs}/79.log | 0 i2p2www/meetings/{ => logs}/79.rst | 0 i2p2www/meetings/{ => logs}/8.log | 0 i2p2www/meetings/{ => logs}/8.rst | 0 i2p2www/meetings/{ => logs}/80.log | 0 i2p2www/meetings/{ => logs}/80.rst | 0 i2p2www/meetings/{ => logs}/81.log | 0 i2p2www/meetings/{ => logs}/81.rst | 0 i2p2www/meetings/{ => logs}/82.log | 0 i2p2www/meetings/{ => logs}/82.rst | 0 i2p2www/meetings/{ => logs}/9.log | 0 i2p2www/meetings/{ => logs}/9.rst | 0 i2p2www/meetings/{ => logs}/90.log | 0 i2p2www/meetings/{ => logs}/90.rst | 0 i2p2www/meetings/{ => logs}/92.log | 0 i2p2www/meetings/{ => logs}/92.rst | 0 i2p2www/meetings/{ => logs}/93.log | 0 i2p2www/meetings/{ => logs}/93.rst | 0 i2p2www/meetings/{ => logs}/95.log | 0 i2p2www/meetings/{ => logs}/95.rst | 0 i2p2www/meetings/{ => logs}/99.log | 0 i2p2www/meetings/{ => logs}/99.rst | 0 355 files changed, 1 insertion(+), 1 deletion(-) rename i2p2www/meetings/{ => logs}/1.log (100%) rename i2p2www/meetings/{ => logs}/1.rst (100%) rename i2p2www/meetings/{ => logs}/10.log (100%) rename i2p2www/meetings/{ => logs}/10.rst (100%) rename i2p2www/meetings/{ => logs}/100.log (100%) rename i2p2www/meetings/{ => logs}/100.rst (100%) rename i2p2www/meetings/{ => logs}/101.log (100%) rename i2p2www/meetings/{ => logs}/101.rst (100%) rename i2p2www/meetings/{ => logs}/102.log (100%) rename i2p2www/meetings/{ => logs}/102.rst (100%) rename i2p2www/meetings/{ => logs}/103.log (100%) rename i2p2www/meetings/{ => logs}/103.rst (100%) rename i2p2www/meetings/{ => logs}/104.log (100%) rename i2p2www/meetings/{ => logs}/104.rst (100%) rename i2p2www/meetings/{ => logs}/105.log (100%) rename i2p2www/meetings/{ => logs}/105.rst (100%) rename i2p2www/meetings/{ => logs}/106.log (100%) rename i2p2www/meetings/{ => logs}/106.rst (100%) rename i2p2www/meetings/{ => logs}/107.log (100%) rename i2p2www/meetings/{ => logs}/107.rst (100%) rename i2p2www/meetings/{ => logs}/108.log (100%) rename i2p2www/meetings/{ => logs}/108.rst (100%) rename i2p2www/meetings/{ => logs}/109.log (100%) rename i2p2www/meetings/{ => logs}/109.rst (100%) rename i2p2www/meetings/{ => logs}/11.log (100%) rename i2p2www/meetings/{ => logs}/11.rst (100%) rename i2p2www/meetings/{ => logs}/110.log (100%) rename i2p2www/meetings/{ => logs}/110.rst (100%) rename i2p2www/meetings/{ => logs}/111.log (100%) rename i2p2www/meetings/{ => logs}/111.rst (100%) rename i2p2www/meetings/{ => logs}/112.log (100%) rename i2p2www/meetings/{ => logs}/112.rst (100%) rename i2p2www/meetings/{ => logs}/113.log (100%) rename i2p2www/meetings/{ => logs}/113.rst (100%) rename i2p2www/meetings/{ => logs}/114.log (100%) rename i2p2www/meetings/{ => logs}/114.rst (100%) rename i2p2www/meetings/{ => logs}/115.log (100%) rename i2p2www/meetings/{ => logs}/115.rst (100%) rename i2p2www/meetings/{ => logs}/116.log (100%) rename i2p2www/meetings/{ => logs}/116.rst (100%) rename i2p2www/meetings/{ => logs}/117.log (100%) rename i2p2www/meetings/{ => logs}/117.rst (100%) rename i2p2www/meetings/{ => logs}/118.log (100%) rename i2p2www/meetings/{ => logs}/118.rst (100%) rename i2p2www/meetings/{ => logs}/119.log (100%) rename i2p2www/meetings/{ => logs}/119.rst (100%) rename i2p2www/meetings/{ => logs}/12.log (100%) rename i2p2www/meetings/{ => logs}/12.rst (100%) rename i2p2www/meetings/{ => logs}/120.log (100%) rename i2p2www/meetings/{ => logs}/120.rst (100%) rename i2p2www/meetings/{ => logs}/121.log (100%) rename i2p2www/meetings/{ => logs}/121.rst (100%) rename i2p2www/meetings/{ => logs}/122.log (100%) rename i2p2www/meetings/{ => logs}/122.rst (100%) rename i2p2www/meetings/{ => logs}/123.log (100%) rename i2p2www/meetings/{ => logs}/123.rst (100%) rename i2p2www/meetings/{ => logs}/124.log (100%) rename i2p2www/meetings/{ => logs}/124.rst (100%) rename i2p2www/meetings/{ => logs}/125.log (100%) rename i2p2www/meetings/{ => logs}/125.rst (100%) rename i2p2www/meetings/{ => logs}/126.log (100%) rename i2p2www/meetings/{ => logs}/126.rst (100%) rename i2p2www/meetings/{ => logs}/127.log (100%) rename i2p2www/meetings/{ => logs}/127.rst (100%) rename i2p2www/meetings/{ => logs}/128.log (100%) rename i2p2www/meetings/{ => logs}/128.rst (100%) rename i2p2www/meetings/{ => logs}/129.log (100%) rename i2p2www/meetings/{ => logs}/129.rst (100%) rename i2p2www/meetings/{ => logs}/130.log (100%) rename i2p2www/meetings/{ => logs}/130.rst (100%) rename i2p2www/meetings/{ => logs}/131.log (100%) rename i2p2www/meetings/{ => logs}/131.rst (100%) rename i2p2www/meetings/{ => logs}/132.log (100%) rename i2p2www/meetings/{ => logs}/132.rst (100%) rename i2p2www/meetings/{ => logs}/133.log (100%) rename i2p2www/meetings/{ => logs}/133.rst (100%) rename i2p2www/meetings/{ => logs}/134.log (100%) rename i2p2www/meetings/{ => logs}/134.rst (100%) rename i2p2www/meetings/{ => logs}/135.log (100%) rename i2p2www/meetings/{ => logs}/135.rst (100%) rename i2p2www/meetings/{ => logs}/136.log (100%) rename i2p2www/meetings/{ => logs}/136.rst (100%) rename i2p2www/meetings/{ => logs}/137.log (100%) rename i2p2www/meetings/{ => logs}/137.rst (100%) rename i2p2www/meetings/{ => logs}/138.log (100%) rename i2p2www/meetings/{ => logs}/138.rst (100%) rename i2p2www/meetings/{ => logs}/139.log (100%) rename i2p2www/meetings/{ => logs}/139.rst (100%) rename i2p2www/meetings/{ => logs}/140.log (100%) rename i2p2www/meetings/{ => logs}/140.rst (100%) rename i2p2www/meetings/{ => logs}/141.log (100%) rename i2p2www/meetings/{ => logs}/141.rst (100%) rename i2p2www/meetings/{ => logs}/142.log (100%) rename i2p2www/meetings/{ => logs}/142.rst (100%) rename i2p2www/meetings/{ => logs}/143.log (100%) rename i2p2www/meetings/{ => logs}/143.rst (100%) rename i2p2www/meetings/{ => logs}/144.log (100%) rename i2p2www/meetings/{ => logs}/144.rst (100%) rename i2p2www/meetings/{ => logs}/145.log (100%) rename i2p2www/meetings/{ => logs}/145.rst (100%) rename i2p2www/meetings/{ => logs}/146.log (100%) rename i2p2www/meetings/{ => logs}/146.rst (100%) rename i2p2www/meetings/{ => logs}/147.log (100%) rename i2p2www/meetings/{ => logs}/147.rst (100%) rename i2p2www/meetings/{ => logs}/148.log (100%) rename i2p2www/meetings/{ => logs}/148.rst (100%) rename i2p2www/meetings/{ => logs}/149.log (100%) rename i2p2www/meetings/{ => logs}/149.rst (100%) rename i2p2www/meetings/{ => logs}/15.log (100%) rename i2p2www/meetings/{ => logs}/15.rst (100%) rename i2p2www/meetings/{ => logs}/150.log (100%) rename i2p2www/meetings/{ => logs}/150.rst (100%) rename i2p2www/meetings/{ => logs}/151.log (100%) rename i2p2www/meetings/{ => logs}/151.rst (100%) rename i2p2www/meetings/{ => logs}/152.log (100%) rename i2p2www/meetings/{ => logs}/152.rst (100%) rename i2p2www/meetings/{ => logs}/153.log (100%) rename i2p2www/meetings/{ => logs}/153.rst (100%) rename i2p2www/meetings/{ => logs}/154.log (100%) rename i2p2www/meetings/{ => logs}/154.rst (100%) rename i2p2www/meetings/{ => logs}/155.log (100%) rename i2p2www/meetings/{ => logs}/155.rst (100%) rename i2p2www/meetings/{ => logs}/156.log (100%) rename i2p2www/meetings/{ => logs}/156.rst (100%) rename i2p2www/meetings/{ => logs}/157.log (100%) rename i2p2www/meetings/{ => logs}/157.rst (100%) rename i2p2www/meetings/{ => logs}/158.log (100%) rename i2p2www/meetings/{ => logs}/158.rst (100%) rename i2p2www/meetings/{ => logs}/159.log (100%) rename i2p2www/meetings/{ => logs}/159.rst (100%) rename i2p2www/meetings/{ => logs}/160.log (100%) rename i2p2www/meetings/{ => logs}/160.rst (100%) rename i2p2www/meetings/{ => logs}/161.log (100%) rename i2p2www/meetings/{ => logs}/161.rst (100%) rename i2p2www/meetings/{ => logs}/162.log (100%) rename i2p2www/meetings/{ => logs}/162.rst (100%) rename i2p2www/meetings/{ => logs}/163.log (100%) rename i2p2www/meetings/{ => logs}/163.rst (100%) rename i2p2www/meetings/{ => logs}/164.log (100%) rename i2p2www/meetings/{ => logs}/164.rst (100%) rename i2p2www/meetings/{ => logs}/165.log (100%) rename i2p2www/meetings/{ => logs}/165.rst (100%) rename i2p2www/meetings/{ => logs}/166.log (100%) rename i2p2www/meetings/{ => logs}/166.rst (100%) rename i2p2www/meetings/{ => logs}/167.log (100%) rename i2p2www/meetings/{ => logs}/167.rst (100%) rename i2p2www/meetings/{ => logs}/168.log (100%) rename i2p2www/meetings/{ => logs}/168.rst (100%) rename i2p2www/meetings/{ => logs}/170.log (100%) rename i2p2www/meetings/{ => logs}/170.rst (100%) rename i2p2www/meetings/{ => logs}/171.log (100%) rename i2p2www/meetings/{ => logs}/171.rst (100%) rename i2p2www/meetings/{ => logs}/172.log (100%) rename i2p2www/meetings/{ => logs}/172.rst (100%) rename i2p2www/meetings/{ => logs}/173.log (100%) rename i2p2www/meetings/{ => logs}/173.rst (100%) rename i2p2www/meetings/{ => logs}/174.log (100%) rename i2p2www/meetings/{ => logs}/174.rst (100%) rename i2p2www/meetings/{ => logs}/175.log (100%) rename i2p2www/meetings/{ => logs}/175.rst (100%) rename i2p2www/meetings/{ => logs}/176.log (100%) rename i2p2www/meetings/{ => logs}/176.rst (100%) rename i2p2www/meetings/{ => logs}/177.log (100%) rename i2p2www/meetings/{ => logs}/177.rst (100%) rename i2p2www/meetings/{ => logs}/178.log (100%) rename i2p2www/meetings/{ => logs}/178.rst (100%) rename i2p2www/meetings/{ => logs}/179.log (100%) rename i2p2www/meetings/{ => logs}/179.rst (100%) rename i2p2www/meetings/{ => logs}/18.log (100%) rename i2p2www/meetings/{ => logs}/18.rst (100%) rename i2p2www/meetings/{ => logs}/180.log (100%) rename i2p2www/meetings/{ => logs}/180.rst (100%) rename i2p2www/meetings/{ => logs}/181.log (100%) rename i2p2www/meetings/{ => logs}/181.rst (100%) rename i2p2www/meetings/{ => logs}/182.log (100%) rename i2p2www/meetings/{ => logs}/182.rst (100%) rename i2p2www/meetings/{ => logs}/183.log (100%) rename i2p2www/meetings/{ => logs}/183.rst (100%) rename i2p2www/meetings/{ => logs}/184.log (100%) rename i2p2www/meetings/{ => logs}/184.rst (100%) rename i2p2www/meetings/{ => logs}/185.log (100%) rename i2p2www/meetings/{ => logs}/185.rst (100%) rename i2p2www/meetings/{ => logs}/186.log (100%) rename i2p2www/meetings/{ => logs}/186.rst (100%) rename i2p2www/meetings/{ => logs}/187.log (100%) rename i2p2www/meetings/{ => logs}/187.rst (100%) rename i2p2www/meetings/{ => logs}/188.log (100%) rename i2p2www/meetings/{ => logs}/188.rst (100%) rename i2p2www/meetings/{ => logs}/189.log (100%) rename i2p2www/meetings/{ => logs}/189.rst (100%) rename i2p2www/meetings/{ => logs}/190.log (100%) rename i2p2www/meetings/{ => logs}/190.rst (100%) rename i2p2www/meetings/{ => logs}/191.log (100%) rename i2p2www/meetings/{ => logs}/191.rst (100%) rename i2p2www/meetings/{ => logs}/192.log (100%) rename i2p2www/meetings/{ => logs}/192.rst (100%) rename i2p2www/meetings/{ => logs}/193.log (100%) rename i2p2www/meetings/{ => logs}/193.rst (100%) rename i2p2www/meetings/{ => logs}/194.log (100%) rename i2p2www/meetings/{ => logs}/194.rst (100%) rename i2p2www/meetings/{ => logs}/195.log (100%) rename i2p2www/meetings/{ => logs}/195.rst (100%) rename i2p2www/meetings/{ => logs}/196.log (100%) rename i2p2www/meetings/{ => logs}/196.rst (100%) rename i2p2www/meetings/{ => logs}/197.log (100%) rename i2p2www/meetings/{ => logs}/197.rst (100%) rename i2p2www/meetings/{ => logs}/198.log (100%) rename i2p2www/meetings/{ => logs}/198.rst (100%) rename i2p2www/meetings/{ => logs}/199.log (100%) rename i2p2www/meetings/{ => logs}/199.rst (100%) rename i2p2www/meetings/{ => logs}/2.log (100%) rename i2p2www/meetings/{ => logs}/2.rst (100%) rename i2p2www/meetings/{ => logs}/20.log (100%) rename i2p2www/meetings/{ => logs}/20.rst (100%) rename i2p2www/meetings/{ => logs}/200.log (100%) rename i2p2www/meetings/{ => logs}/200.rst (100%) rename i2p2www/meetings/{ => logs}/201.log (100%) rename i2p2www/meetings/{ => logs}/201.rst (100%) rename i2p2www/meetings/{ => logs}/202.log (100%) rename i2p2www/meetings/{ => logs}/202.rst (100%) rename i2p2www/meetings/{ => logs}/203.log (100%) rename i2p2www/meetings/{ => logs}/203.rst (100%) rename i2p2www/meetings/{ => logs}/204.log (100%) rename i2p2www/meetings/{ => logs}/204.rst (100%) rename i2p2www/meetings/{ => logs}/205.log (100%) rename i2p2www/meetings/{ => logs}/205.rst (100%) rename i2p2www/meetings/{ => logs}/206.log (100%) rename i2p2www/meetings/{ => logs}/206.rst (100%) rename i2p2www/meetings/{ => logs}/207.log (100%) rename i2p2www/meetings/{ => logs}/207.rst (100%) rename i2p2www/meetings/{ => logs}/208.log (100%) rename i2p2www/meetings/{ => logs}/208.rst (100%) rename i2p2www/meetings/{ => logs}/209.log (100%) rename i2p2www/meetings/{ => logs}/209.rst (100%) rename i2p2www/meetings/{ => logs}/21.log (100%) rename i2p2www/meetings/{ => logs}/21.rst (100%) rename i2p2www/meetings/{ => logs}/210.log (100%) rename i2p2www/meetings/{ => logs}/210.rst (100%) rename i2p2www/meetings/{ => logs}/211.log (100%) rename i2p2www/meetings/{ => logs}/211.rst (100%) rename i2p2www/meetings/{ => logs}/212.log (100%) rename i2p2www/meetings/{ => logs}/212.rst (100%) rename i2p2www/meetings/{ => logs}/22.log (100%) rename i2p2www/meetings/{ => logs}/22.rst (100%) rename i2p2www/meetings/{ => logs}/23.log (100%) rename i2p2www/meetings/{ => logs}/23.rst (100%) rename i2p2www/meetings/{ => logs}/25.log (100%) rename i2p2www/meetings/{ => logs}/25.rst (100%) rename i2p2www/meetings/{ => logs}/26.log (100%) rename i2p2www/meetings/{ => logs}/26.rst (100%) rename i2p2www/meetings/{ => logs}/28.log (100%) rename i2p2www/meetings/{ => logs}/28.rst (100%) rename i2p2www/meetings/{ => logs}/29.log (100%) rename i2p2www/meetings/{ => logs}/29.rst (100%) rename i2p2www/meetings/{ => logs}/3.log (100%) rename i2p2www/meetings/{ => logs}/3.rst (100%) rename i2p2www/meetings/{ => logs}/30.log (100%) rename i2p2www/meetings/{ => logs}/30.rst (100%) rename i2p2www/meetings/{ => logs}/31.log (100%) rename i2p2www/meetings/{ => logs}/31.rst (100%) rename i2p2www/meetings/{ => logs}/32.log (100%) rename i2p2www/meetings/{ => logs}/32.rst (100%) rename i2p2www/meetings/{ => logs}/33.log (100%) rename i2p2www/meetings/{ => logs}/33.rst (100%) rename i2p2www/meetings/{ => logs}/34.log (100%) rename i2p2www/meetings/{ => logs}/34.rst (100%) rename i2p2www/meetings/{ => logs}/35.log (100%) rename i2p2www/meetings/{ => logs}/35.rst (100%) rename i2p2www/meetings/{ => logs}/4.log (100%) rename i2p2www/meetings/{ => logs}/4.rst (100%) rename i2p2www/meetings/{ => logs}/47.log (100%) rename i2p2www/meetings/{ => logs}/47.rst (100%) rename i2p2www/meetings/{ => logs}/49.log (100%) rename i2p2www/meetings/{ => logs}/49.rst (100%) rename i2p2www/meetings/{ => logs}/50.log (100%) rename i2p2www/meetings/{ => logs}/50.rst (100%) rename i2p2www/meetings/{ => logs}/51.log (100%) rename i2p2www/meetings/{ => logs}/51.rst (100%) rename i2p2www/meetings/{ => logs}/52.log (100%) rename i2p2www/meetings/{ => logs}/52.rst (100%) rename i2p2www/meetings/{ => logs}/53.log (100%) rename i2p2www/meetings/{ => logs}/53.rst (100%) rename i2p2www/meetings/{ => logs}/54.log (100%) rename i2p2www/meetings/{ => logs}/54.rst (100%) rename i2p2www/meetings/{ => logs}/55.log (100%) rename i2p2www/meetings/{ => logs}/55.rst (100%) rename i2p2www/meetings/{ => logs}/56.log (100%) rename i2p2www/meetings/{ => logs}/56.rst (100%) rename i2p2www/meetings/{ => logs}/57.log (100%) rename i2p2www/meetings/{ => logs}/57.rst (100%) rename i2p2www/meetings/{ => logs}/58.log (100%) rename i2p2www/meetings/{ => logs}/58.rst (100%) rename i2p2www/meetings/{ => logs}/59.log (100%) rename i2p2www/meetings/{ => logs}/59.rst (100%) rename i2p2www/meetings/{ => logs}/60.log (100%) rename i2p2www/meetings/{ => logs}/60.rst (100%) rename i2p2www/meetings/{ => logs}/61.log (100%) rename i2p2www/meetings/{ => logs}/61.rst (100%) rename i2p2www/meetings/{ => logs}/62.log (100%) rename i2p2www/meetings/{ => logs}/62.rst (100%) rename i2p2www/meetings/{ => logs}/63.log (100%) rename i2p2www/meetings/{ => logs}/63.rst (100%) rename i2p2www/meetings/{ => logs}/64.log (100%) rename i2p2www/meetings/{ => logs}/64.rst (100%) rename i2p2www/meetings/{ => logs}/65.log (100%) rename i2p2www/meetings/{ => logs}/65.rst (100%) rename i2p2www/meetings/{ => logs}/66.log (100%) rename i2p2www/meetings/{ => logs}/66.rst (100%) rename i2p2www/meetings/{ => logs}/68.log (100%) rename i2p2www/meetings/{ => logs}/68.rst (100%) rename i2p2www/meetings/{ => logs}/69.log (100%) rename i2p2www/meetings/{ => logs}/69.rst (100%) rename i2p2www/meetings/{ => logs}/7.log (100%) rename i2p2www/meetings/{ => logs}/7.rst (100%) rename i2p2www/meetings/{ => logs}/70.log (100%) rename i2p2www/meetings/{ => logs}/70.rst (100%) rename i2p2www/meetings/{ => logs}/71.log (100%) rename i2p2www/meetings/{ => logs}/71.rst (100%) rename i2p2www/meetings/{ => logs}/72.log (100%) rename i2p2www/meetings/{ => logs}/72.rst (100%) rename i2p2www/meetings/{ => logs}/73.log (100%) rename i2p2www/meetings/{ => logs}/73.rst (100%) rename i2p2www/meetings/{ => logs}/74.log (100%) rename i2p2www/meetings/{ => logs}/74.rst (100%) rename i2p2www/meetings/{ => logs}/75.log (100%) rename i2p2www/meetings/{ => logs}/75.rst (100%) rename i2p2www/meetings/{ => logs}/76.log (100%) rename i2p2www/meetings/{ => logs}/76.rst (100%) rename i2p2www/meetings/{ => logs}/77.log (100%) rename i2p2www/meetings/{ => logs}/77.rst (100%) rename i2p2www/meetings/{ => logs}/78.log (100%) rename i2p2www/meetings/{ => logs}/78.rst (100%) rename i2p2www/meetings/{ => logs}/79.log (100%) rename i2p2www/meetings/{ => logs}/79.rst (100%) rename i2p2www/meetings/{ => logs}/8.log (100%) rename i2p2www/meetings/{ => logs}/8.rst (100%) rename i2p2www/meetings/{ => logs}/80.log (100%) rename i2p2www/meetings/{ => logs}/80.rst (100%) rename i2p2www/meetings/{ => logs}/81.log (100%) rename i2p2www/meetings/{ => logs}/81.rst (100%) rename i2p2www/meetings/{ => logs}/82.log (100%) rename i2p2www/meetings/{ => logs}/82.rst (100%) rename i2p2www/meetings/{ => logs}/9.log (100%) rename i2p2www/meetings/{ => logs}/9.rst (100%) rename i2p2www/meetings/{ => logs}/90.log (100%) rename i2p2www/meetings/{ => logs}/90.rst (100%) rename i2p2www/meetings/{ => logs}/92.log (100%) rename i2p2www/meetings/{ => logs}/92.rst (100%) rename i2p2www/meetings/{ => logs}/93.log (100%) rename i2p2www/meetings/{ => logs}/93.rst (100%) rename i2p2www/meetings/{ => logs}/95.log (100%) rename i2p2www/meetings/{ => logs}/95.rst (100%) rename i2p2www/meetings/{ => logs}/99.log (100%) rename i2p2www/meetings/{ => logs}/99.rst (100%) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 8ebd1baa..18c4bac0 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -24,7 +24,7 @@ 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') +MEETINGS_DIR = os.path.join(os.path.dirname(__file__), 'meetings/logs') BLOG_ENTRIES_PER_PAGE = 20 MEETINGS_PER_PAGE = 20 diff --git a/i2p2www/meetings/1.log b/i2p2www/meetings/logs/1.log similarity index 100% rename from i2p2www/meetings/1.log rename to i2p2www/meetings/logs/1.log diff --git a/i2p2www/meetings/1.rst b/i2p2www/meetings/logs/1.rst similarity index 100% rename from i2p2www/meetings/1.rst rename to i2p2www/meetings/logs/1.rst diff --git a/i2p2www/meetings/10.log b/i2p2www/meetings/logs/10.log similarity index 100% rename from i2p2www/meetings/10.log rename to i2p2www/meetings/logs/10.log diff --git a/i2p2www/meetings/10.rst b/i2p2www/meetings/logs/10.rst similarity index 100% rename from i2p2www/meetings/10.rst rename to i2p2www/meetings/logs/10.rst diff --git a/i2p2www/meetings/100.log b/i2p2www/meetings/logs/100.log similarity index 100% rename from i2p2www/meetings/100.log rename to i2p2www/meetings/logs/100.log diff --git a/i2p2www/meetings/100.rst b/i2p2www/meetings/logs/100.rst similarity index 100% rename from i2p2www/meetings/100.rst rename to i2p2www/meetings/logs/100.rst diff --git a/i2p2www/meetings/101.log b/i2p2www/meetings/logs/101.log similarity index 100% rename from i2p2www/meetings/101.log rename to i2p2www/meetings/logs/101.log diff --git a/i2p2www/meetings/101.rst b/i2p2www/meetings/logs/101.rst similarity index 100% rename from i2p2www/meetings/101.rst rename to i2p2www/meetings/logs/101.rst diff --git a/i2p2www/meetings/102.log b/i2p2www/meetings/logs/102.log similarity index 100% rename from i2p2www/meetings/102.log rename to i2p2www/meetings/logs/102.log diff --git a/i2p2www/meetings/102.rst b/i2p2www/meetings/logs/102.rst similarity index 100% rename from i2p2www/meetings/102.rst rename to i2p2www/meetings/logs/102.rst diff --git a/i2p2www/meetings/103.log b/i2p2www/meetings/logs/103.log similarity index 100% rename from i2p2www/meetings/103.log rename to i2p2www/meetings/logs/103.log diff --git a/i2p2www/meetings/103.rst b/i2p2www/meetings/logs/103.rst similarity index 100% rename from i2p2www/meetings/103.rst rename to i2p2www/meetings/logs/103.rst diff --git a/i2p2www/meetings/104.log b/i2p2www/meetings/logs/104.log similarity index 100% rename from i2p2www/meetings/104.log rename to i2p2www/meetings/logs/104.log diff --git a/i2p2www/meetings/104.rst b/i2p2www/meetings/logs/104.rst similarity index 100% rename from i2p2www/meetings/104.rst rename to i2p2www/meetings/logs/104.rst diff --git a/i2p2www/meetings/105.log b/i2p2www/meetings/logs/105.log similarity index 100% rename from i2p2www/meetings/105.log rename to i2p2www/meetings/logs/105.log diff --git a/i2p2www/meetings/105.rst b/i2p2www/meetings/logs/105.rst similarity index 100% rename from i2p2www/meetings/105.rst rename to i2p2www/meetings/logs/105.rst diff --git a/i2p2www/meetings/106.log b/i2p2www/meetings/logs/106.log similarity index 100% rename from i2p2www/meetings/106.log rename to i2p2www/meetings/logs/106.log diff --git a/i2p2www/meetings/106.rst b/i2p2www/meetings/logs/106.rst similarity index 100% rename from i2p2www/meetings/106.rst rename to i2p2www/meetings/logs/106.rst diff --git a/i2p2www/meetings/107.log b/i2p2www/meetings/logs/107.log similarity index 100% rename from i2p2www/meetings/107.log rename to i2p2www/meetings/logs/107.log diff --git a/i2p2www/meetings/107.rst b/i2p2www/meetings/logs/107.rst similarity index 100% rename from i2p2www/meetings/107.rst rename to i2p2www/meetings/logs/107.rst diff --git a/i2p2www/meetings/108.log b/i2p2www/meetings/logs/108.log similarity index 100% rename from i2p2www/meetings/108.log rename to i2p2www/meetings/logs/108.log diff --git a/i2p2www/meetings/108.rst b/i2p2www/meetings/logs/108.rst similarity index 100% rename from i2p2www/meetings/108.rst rename to i2p2www/meetings/logs/108.rst diff --git a/i2p2www/meetings/109.log b/i2p2www/meetings/logs/109.log similarity index 100% rename from i2p2www/meetings/109.log rename to i2p2www/meetings/logs/109.log diff --git a/i2p2www/meetings/109.rst b/i2p2www/meetings/logs/109.rst similarity index 100% rename from i2p2www/meetings/109.rst rename to i2p2www/meetings/logs/109.rst diff --git a/i2p2www/meetings/11.log b/i2p2www/meetings/logs/11.log similarity index 100% rename from i2p2www/meetings/11.log rename to i2p2www/meetings/logs/11.log diff --git a/i2p2www/meetings/11.rst b/i2p2www/meetings/logs/11.rst similarity index 100% rename from i2p2www/meetings/11.rst rename to i2p2www/meetings/logs/11.rst diff --git a/i2p2www/meetings/110.log b/i2p2www/meetings/logs/110.log similarity index 100% rename from i2p2www/meetings/110.log rename to i2p2www/meetings/logs/110.log diff --git a/i2p2www/meetings/110.rst b/i2p2www/meetings/logs/110.rst similarity index 100% rename from i2p2www/meetings/110.rst rename to i2p2www/meetings/logs/110.rst diff --git a/i2p2www/meetings/111.log b/i2p2www/meetings/logs/111.log similarity index 100% rename from i2p2www/meetings/111.log rename to i2p2www/meetings/logs/111.log diff --git a/i2p2www/meetings/111.rst b/i2p2www/meetings/logs/111.rst similarity index 100% rename from i2p2www/meetings/111.rst rename to i2p2www/meetings/logs/111.rst diff --git a/i2p2www/meetings/112.log b/i2p2www/meetings/logs/112.log similarity index 100% rename from i2p2www/meetings/112.log rename to i2p2www/meetings/logs/112.log diff --git a/i2p2www/meetings/112.rst b/i2p2www/meetings/logs/112.rst similarity index 100% rename from i2p2www/meetings/112.rst rename to i2p2www/meetings/logs/112.rst diff --git a/i2p2www/meetings/113.log b/i2p2www/meetings/logs/113.log similarity index 100% rename from i2p2www/meetings/113.log rename to i2p2www/meetings/logs/113.log diff --git a/i2p2www/meetings/113.rst b/i2p2www/meetings/logs/113.rst similarity index 100% rename from i2p2www/meetings/113.rst rename to i2p2www/meetings/logs/113.rst diff --git a/i2p2www/meetings/114.log b/i2p2www/meetings/logs/114.log similarity index 100% rename from i2p2www/meetings/114.log rename to i2p2www/meetings/logs/114.log diff --git a/i2p2www/meetings/114.rst b/i2p2www/meetings/logs/114.rst similarity index 100% rename from i2p2www/meetings/114.rst rename to i2p2www/meetings/logs/114.rst diff --git a/i2p2www/meetings/115.log b/i2p2www/meetings/logs/115.log similarity index 100% rename from i2p2www/meetings/115.log rename to i2p2www/meetings/logs/115.log diff --git a/i2p2www/meetings/115.rst b/i2p2www/meetings/logs/115.rst similarity index 100% rename from i2p2www/meetings/115.rst rename to i2p2www/meetings/logs/115.rst diff --git a/i2p2www/meetings/116.log b/i2p2www/meetings/logs/116.log similarity index 100% rename from i2p2www/meetings/116.log rename to i2p2www/meetings/logs/116.log diff --git a/i2p2www/meetings/116.rst b/i2p2www/meetings/logs/116.rst similarity index 100% rename from i2p2www/meetings/116.rst rename to i2p2www/meetings/logs/116.rst diff --git a/i2p2www/meetings/117.log b/i2p2www/meetings/logs/117.log similarity index 100% rename from i2p2www/meetings/117.log rename to i2p2www/meetings/logs/117.log diff --git a/i2p2www/meetings/117.rst b/i2p2www/meetings/logs/117.rst similarity index 100% rename from i2p2www/meetings/117.rst rename to i2p2www/meetings/logs/117.rst diff --git a/i2p2www/meetings/118.log b/i2p2www/meetings/logs/118.log similarity index 100% rename from i2p2www/meetings/118.log rename to i2p2www/meetings/logs/118.log diff --git a/i2p2www/meetings/118.rst b/i2p2www/meetings/logs/118.rst similarity index 100% rename from i2p2www/meetings/118.rst rename to i2p2www/meetings/logs/118.rst diff --git a/i2p2www/meetings/119.log b/i2p2www/meetings/logs/119.log similarity index 100% rename from i2p2www/meetings/119.log rename to i2p2www/meetings/logs/119.log diff --git a/i2p2www/meetings/119.rst b/i2p2www/meetings/logs/119.rst similarity index 100% rename from i2p2www/meetings/119.rst rename to i2p2www/meetings/logs/119.rst diff --git a/i2p2www/meetings/12.log b/i2p2www/meetings/logs/12.log similarity index 100% rename from i2p2www/meetings/12.log rename to i2p2www/meetings/logs/12.log diff --git a/i2p2www/meetings/12.rst b/i2p2www/meetings/logs/12.rst similarity index 100% rename from i2p2www/meetings/12.rst rename to i2p2www/meetings/logs/12.rst diff --git a/i2p2www/meetings/120.log b/i2p2www/meetings/logs/120.log similarity index 100% rename from i2p2www/meetings/120.log rename to i2p2www/meetings/logs/120.log diff --git a/i2p2www/meetings/120.rst b/i2p2www/meetings/logs/120.rst similarity index 100% rename from i2p2www/meetings/120.rst rename to i2p2www/meetings/logs/120.rst diff --git a/i2p2www/meetings/121.log b/i2p2www/meetings/logs/121.log similarity index 100% rename from i2p2www/meetings/121.log rename to i2p2www/meetings/logs/121.log diff --git a/i2p2www/meetings/121.rst b/i2p2www/meetings/logs/121.rst similarity index 100% rename from i2p2www/meetings/121.rst rename to i2p2www/meetings/logs/121.rst diff --git a/i2p2www/meetings/122.log b/i2p2www/meetings/logs/122.log similarity index 100% rename from i2p2www/meetings/122.log rename to i2p2www/meetings/logs/122.log diff --git a/i2p2www/meetings/122.rst b/i2p2www/meetings/logs/122.rst similarity index 100% rename from i2p2www/meetings/122.rst rename to i2p2www/meetings/logs/122.rst diff --git a/i2p2www/meetings/123.log b/i2p2www/meetings/logs/123.log similarity index 100% rename from i2p2www/meetings/123.log rename to i2p2www/meetings/logs/123.log diff --git a/i2p2www/meetings/123.rst b/i2p2www/meetings/logs/123.rst similarity index 100% rename from i2p2www/meetings/123.rst rename to i2p2www/meetings/logs/123.rst diff --git a/i2p2www/meetings/124.log b/i2p2www/meetings/logs/124.log similarity index 100% rename from i2p2www/meetings/124.log rename to i2p2www/meetings/logs/124.log diff --git a/i2p2www/meetings/124.rst b/i2p2www/meetings/logs/124.rst similarity index 100% rename from i2p2www/meetings/124.rst rename to i2p2www/meetings/logs/124.rst diff --git a/i2p2www/meetings/125.log b/i2p2www/meetings/logs/125.log similarity index 100% rename from i2p2www/meetings/125.log rename to i2p2www/meetings/logs/125.log diff --git a/i2p2www/meetings/125.rst b/i2p2www/meetings/logs/125.rst similarity index 100% rename from i2p2www/meetings/125.rst rename to i2p2www/meetings/logs/125.rst diff --git a/i2p2www/meetings/126.log b/i2p2www/meetings/logs/126.log similarity index 100% rename from i2p2www/meetings/126.log rename to i2p2www/meetings/logs/126.log diff --git a/i2p2www/meetings/126.rst b/i2p2www/meetings/logs/126.rst similarity index 100% rename from i2p2www/meetings/126.rst rename to i2p2www/meetings/logs/126.rst diff --git a/i2p2www/meetings/127.log b/i2p2www/meetings/logs/127.log similarity index 100% rename from i2p2www/meetings/127.log rename to i2p2www/meetings/logs/127.log diff --git a/i2p2www/meetings/127.rst b/i2p2www/meetings/logs/127.rst similarity index 100% rename from i2p2www/meetings/127.rst rename to i2p2www/meetings/logs/127.rst diff --git a/i2p2www/meetings/128.log b/i2p2www/meetings/logs/128.log similarity index 100% rename from i2p2www/meetings/128.log rename to i2p2www/meetings/logs/128.log diff --git a/i2p2www/meetings/128.rst b/i2p2www/meetings/logs/128.rst similarity index 100% rename from i2p2www/meetings/128.rst rename to i2p2www/meetings/logs/128.rst diff --git a/i2p2www/meetings/129.log b/i2p2www/meetings/logs/129.log similarity index 100% rename from i2p2www/meetings/129.log rename to i2p2www/meetings/logs/129.log diff --git a/i2p2www/meetings/129.rst b/i2p2www/meetings/logs/129.rst similarity index 100% rename from i2p2www/meetings/129.rst rename to i2p2www/meetings/logs/129.rst diff --git a/i2p2www/meetings/130.log b/i2p2www/meetings/logs/130.log similarity index 100% rename from i2p2www/meetings/130.log rename to i2p2www/meetings/logs/130.log diff --git a/i2p2www/meetings/130.rst b/i2p2www/meetings/logs/130.rst similarity index 100% rename from i2p2www/meetings/130.rst rename to i2p2www/meetings/logs/130.rst diff --git a/i2p2www/meetings/131.log b/i2p2www/meetings/logs/131.log similarity index 100% rename from i2p2www/meetings/131.log rename to i2p2www/meetings/logs/131.log diff --git a/i2p2www/meetings/131.rst b/i2p2www/meetings/logs/131.rst similarity index 100% rename from i2p2www/meetings/131.rst rename to i2p2www/meetings/logs/131.rst diff --git a/i2p2www/meetings/132.log b/i2p2www/meetings/logs/132.log similarity index 100% rename from i2p2www/meetings/132.log rename to i2p2www/meetings/logs/132.log diff --git a/i2p2www/meetings/132.rst b/i2p2www/meetings/logs/132.rst similarity index 100% rename from i2p2www/meetings/132.rst rename to i2p2www/meetings/logs/132.rst diff --git a/i2p2www/meetings/133.log b/i2p2www/meetings/logs/133.log similarity index 100% rename from i2p2www/meetings/133.log rename to i2p2www/meetings/logs/133.log diff --git a/i2p2www/meetings/133.rst b/i2p2www/meetings/logs/133.rst similarity index 100% rename from i2p2www/meetings/133.rst rename to i2p2www/meetings/logs/133.rst diff --git a/i2p2www/meetings/134.log b/i2p2www/meetings/logs/134.log similarity index 100% rename from i2p2www/meetings/134.log rename to i2p2www/meetings/logs/134.log diff --git a/i2p2www/meetings/134.rst b/i2p2www/meetings/logs/134.rst similarity index 100% rename from i2p2www/meetings/134.rst rename to i2p2www/meetings/logs/134.rst diff --git a/i2p2www/meetings/135.log b/i2p2www/meetings/logs/135.log similarity index 100% rename from i2p2www/meetings/135.log rename to i2p2www/meetings/logs/135.log diff --git a/i2p2www/meetings/135.rst b/i2p2www/meetings/logs/135.rst similarity index 100% rename from i2p2www/meetings/135.rst rename to i2p2www/meetings/logs/135.rst diff --git a/i2p2www/meetings/136.log b/i2p2www/meetings/logs/136.log similarity index 100% rename from i2p2www/meetings/136.log rename to i2p2www/meetings/logs/136.log diff --git a/i2p2www/meetings/136.rst b/i2p2www/meetings/logs/136.rst similarity index 100% rename from i2p2www/meetings/136.rst rename to i2p2www/meetings/logs/136.rst diff --git a/i2p2www/meetings/137.log b/i2p2www/meetings/logs/137.log similarity index 100% rename from i2p2www/meetings/137.log rename to i2p2www/meetings/logs/137.log diff --git a/i2p2www/meetings/137.rst b/i2p2www/meetings/logs/137.rst similarity index 100% rename from i2p2www/meetings/137.rst rename to i2p2www/meetings/logs/137.rst diff --git a/i2p2www/meetings/138.log b/i2p2www/meetings/logs/138.log similarity index 100% rename from i2p2www/meetings/138.log rename to i2p2www/meetings/logs/138.log diff --git a/i2p2www/meetings/138.rst b/i2p2www/meetings/logs/138.rst similarity index 100% rename from i2p2www/meetings/138.rst rename to i2p2www/meetings/logs/138.rst diff --git a/i2p2www/meetings/139.log b/i2p2www/meetings/logs/139.log similarity index 100% rename from i2p2www/meetings/139.log rename to i2p2www/meetings/logs/139.log diff --git a/i2p2www/meetings/139.rst b/i2p2www/meetings/logs/139.rst similarity index 100% rename from i2p2www/meetings/139.rst rename to i2p2www/meetings/logs/139.rst diff --git a/i2p2www/meetings/140.log b/i2p2www/meetings/logs/140.log similarity index 100% rename from i2p2www/meetings/140.log rename to i2p2www/meetings/logs/140.log diff --git a/i2p2www/meetings/140.rst b/i2p2www/meetings/logs/140.rst similarity index 100% rename from i2p2www/meetings/140.rst rename to i2p2www/meetings/logs/140.rst diff --git a/i2p2www/meetings/141.log b/i2p2www/meetings/logs/141.log similarity index 100% rename from i2p2www/meetings/141.log rename to i2p2www/meetings/logs/141.log diff --git a/i2p2www/meetings/141.rst b/i2p2www/meetings/logs/141.rst similarity index 100% rename from i2p2www/meetings/141.rst rename to i2p2www/meetings/logs/141.rst diff --git a/i2p2www/meetings/142.log b/i2p2www/meetings/logs/142.log similarity index 100% rename from i2p2www/meetings/142.log rename to i2p2www/meetings/logs/142.log diff --git a/i2p2www/meetings/142.rst b/i2p2www/meetings/logs/142.rst similarity index 100% rename from i2p2www/meetings/142.rst rename to i2p2www/meetings/logs/142.rst diff --git a/i2p2www/meetings/143.log b/i2p2www/meetings/logs/143.log similarity index 100% rename from i2p2www/meetings/143.log rename to i2p2www/meetings/logs/143.log diff --git a/i2p2www/meetings/143.rst b/i2p2www/meetings/logs/143.rst similarity index 100% rename from i2p2www/meetings/143.rst rename to i2p2www/meetings/logs/143.rst diff --git a/i2p2www/meetings/144.log b/i2p2www/meetings/logs/144.log similarity index 100% rename from i2p2www/meetings/144.log rename to i2p2www/meetings/logs/144.log diff --git a/i2p2www/meetings/144.rst b/i2p2www/meetings/logs/144.rst similarity index 100% rename from i2p2www/meetings/144.rst rename to i2p2www/meetings/logs/144.rst diff --git a/i2p2www/meetings/145.log b/i2p2www/meetings/logs/145.log similarity index 100% rename from i2p2www/meetings/145.log rename to i2p2www/meetings/logs/145.log diff --git a/i2p2www/meetings/145.rst b/i2p2www/meetings/logs/145.rst similarity index 100% rename from i2p2www/meetings/145.rst rename to i2p2www/meetings/logs/145.rst diff --git a/i2p2www/meetings/146.log b/i2p2www/meetings/logs/146.log similarity index 100% rename from i2p2www/meetings/146.log rename to i2p2www/meetings/logs/146.log diff --git a/i2p2www/meetings/146.rst b/i2p2www/meetings/logs/146.rst similarity index 100% rename from i2p2www/meetings/146.rst rename to i2p2www/meetings/logs/146.rst diff --git a/i2p2www/meetings/147.log b/i2p2www/meetings/logs/147.log similarity index 100% rename from i2p2www/meetings/147.log rename to i2p2www/meetings/logs/147.log diff --git a/i2p2www/meetings/147.rst b/i2p2www/meetings/logs/147.rst similarity index 100% rename from i2p2www/meetings/147.rst rename to i2p2www/meetings/logs/147.rst diff --git a/i2p2www/meetings/148.log b/i2p2www/meetings/logs/148.log similarity index 100% rename from i2p2www/meetings/148.log rename to i2p2www/meetings/logs/148.log diff --git a/i2p2www/meetings/148.rst b/i2p2www/meetings/logs/148.rst similarity index 100% rename from i2p2www/meetings/148.rst rename to i2p2www/meetings/logs/148.rst diff --git a/i2p2www/meetings/149.log b/i2p2www/meetings/logs/149.log similarity index 100% rename from i2p2www/meetings/149.log rename to i2p2www/meetings/logs/149.log diff --git a/i2p2www/meetings/149.rst b/i2p2www/meetings/logs/149.rst similarity index 100% rename from i2p2www/meetings/149.rst rename to i2p2www/meetings/logs/149.rst diff --git a/i2p2www/meetings/15.log b/i2p2www/meetings/logs/15.log similarity index 100% rename from i2p2www/meetings/15.log rename to i2p2www/meetings/logs/15.log diff --git a/i2p2www/meetings/15.rst b/i2p2www/meetings/logs/15.rst similarity index 100% rename from i2p2www/meetings/15.rst rename to i2p2www/meetings/logs/15.rst diff --git a/i2p2www/meetings/150.log b/i2p2www/meetings/logs/150.log similarity index 100% rename from i2p2www/meetings/150.log rename to i2p2www/meetings/logs/150.log diff --git a/i2p2www/meetings/150.rst b/i2p2www/meetings/logs/150.rst similarity index 100% rename from i2p2www/meetings/150.rst rename to i2p2www/meetings/logs/150.rst diff --git a/i2p2www/meetings/151.log b/i2p2www/meetings/logs/151.log similarity index 100% rename from i2p2www/meetings/151.log rename to i2p2www/meetings/logs/151.log diff --git a/i2p2www/meetings/151.rst b/i2p2www/meetings/logs/151.rst similarity index 100% rename from i2p2www/meetings/151.rst rename to i2p2www/meetings/logs/151.rst diff --git a/i2p2www/meetings/152.log b/i2p2www/meetings/logs/152.log similarity index 100% rename from i2p2www/meetings/152.log rename to i2p2www/meetings/logs/152.log diff --git a/i2p2www/meetings/152.rst b/i2p2www/meetings/logs/152.rst similarity index 100% rename from i2p2www/meetings/152.rst rename to i2p2www/meetings/logs/152.rst diff --git a/i2p2www/meetings/153.log b/i2p2www/meetings/logs/153.log similarity index 100% rename from i2p2www/meetings/153.log rename to i2p2www/meetings/logs/153.log diff --git a/i2p2www/meetings/153.rst b/i2p2www/meetings/logs/153.rst similarity index 100% rename from i2p2www/meetings/153.rst rename to i2p2www/meetings/logs/153.rst diff --git a/i2p2www/meetings/154.log b/i2p2www/meetings/logs/154.log similarity index 100% rename from i2p2www/meetings/154.log rename to i2p2www/meetings/logs/154.log diff --git a/i2p2www/meetings/154.rst b/i2p2www/meetings/logs/154.rst similarity index 100% rename from i2p2www/meetings/154.rst rename to i2p2www/meetings/logs/154.rst diff --git a/i2p2www/meetings/155.log b/i2p2www/meetings/logs/155.log similarity index 100% rename from i2p2www/meetings/155.log rename to i2p2www/meetings/logs/155.log diff --git a/i2p2www/meetings/155.rst b/i2p2www/meetings/logs/155.rst similarity index 100% rename from i2p2www/meetings/155.rst rename to i2p2www/meetings/logs/155.rst diff --git a/i2p2www/meetings/156.log b/i2p2www/meetings/logs/156.log similarity index 100% rename from i2p2www/meetings/156.log rename to i2p2www/meetings/logs/156.log diff --git a/i2p2www/meetings/156.rst b/i2p2www/meetings/logs/156.rst similarity index 100% rename from i2p2www/meetings/156.rst rename to i2p2www/meetings/logs/156.rst diff --git a/i2p2www/meetings/157.log b/i2p2www/meetings/logs/157.log similarity index 100% rename from i2p2www/meetings/157.log rename to i2p2www/meetings/logs/157.log diff --git a/i2p2www/meetings/157.rst b/i2p2www/meetings/logs/157.rst similarity index 100% rename from i2p2www/meetings/157.rst rename to i2p2www/meetings/logs/157.rst diff --git a/i2p2www/meetings/158.log b/i2p2www/meetings/logs/158.log similarity index 100% rename from i2p2www/meetings/158.log rename to i2p2www/meetings/logs/158.log diff --git a/i2p2www/meetings/158.rst b/i2p2www/meetings/logs/158.rst similarity index 100% rename from i2p2www/meetings/158.rst rename to i2p2www/meetings/logs/158.rst diff --git a/i2p2www/meetings/159.log b/i2p2www/meetings/logs/159.log similarity index 100% rename from i2p2www/meetings/159.log rename to i2p2www/meetings/logs/159.log diff --git a/i2p2www/meetings/159.rst b/i2p2www/meetings/logs/159.rst similarity index 100% rename from i2p2www/meetings/159.rst rename to i2p2www/meetings/logs/159.rst diff --git a/i2p2www/meetings/160.log b/i2p2www/meetings/logs/160.log similarity index 100% rename from i2p2www/meetings/160.log rename to i2p2www/meetings/logs/160.log diff --git a/i2p2www/meetings/160.rst b/i2p2www/meetings/logs/160.rst similarity index 100% rename from i2p2www/meetings/160.rst rename to i2p2www/meetings/logs/160.rst diff --git a/i2p2www/meetings/161.log b/i2p2www/meetings/logs/161.log similarity index 100% rename from i2p2www/meetings/161.log rename to i2p2www/meetings/logs/161.log diff --git a/i2p2www/meetings/161.rst b/i2p2www/meetings/logs/161.rst similarity index 100% rename from i2p2www/meetings/161.rst rename to i2p2www/meetings/logs/161.rst diff --git a/i2p2www/meetings/162.log b/i2p2www/meetings/logs/162.log similarity index 100% rename from i2p2www/meetings/162.log rename to i2p2www/meetings/logs/162.log diff --git a/i2p2www/meetings/162.rst b/i2p2www/meetings/logs/162.rst similarity index 100% rename from i2p2www/meetings/162.rst rename to i2p2www/meetings/logs/162.rst diff --git a/i2p2www/meetings/163.log b/i2p2www/meetings/logs/163.log similarity index 100% rename from i2p2www/meetings/163.log rename to i2p2www/meetings/logs/163.log diff --git a/i2p2www/meetings/163.rst b/i2p2www/meetings/logs/163.rst similarity index 100% rename from i2p2www/meetings/163.rst rename to i2p2www/meetings/logs/163.rst diff --git a/i2p2www/meetings/164.log b/i2p2www/meetings/logs/164.log similarity index 100% rename from i2p2www/meetings/164.log rename to i2p2www/meetings/logs/164.log diff --git a/i2p2www/meetings/164.rst b/i2p2www/meetings/logs/164.rst similarity index 100% rename from i2p2www/meetings/164.rst rename to i2p2www/meetings/logs/164.rst diff --git a/i2p2www/meetings/165.log b/i2p2www/meetings/logs/165.log similarity index 100% rename from i2p2www/meetings/165.log rename to i2p2www/meetings/logs/165.log diff --git a/i2p2www/meetings/165.rst b/i2p2www/meetings/logs/165.rst similarity index 100% rename from i2p2www/meetings/165.rst rename to i2p2www/meetings/logs/165.rst diff --git a/i2p2www/meetings/166.log b/i2p2www/meetings/logs/166.log similarity index 100% rename from i2p2www/meetings/166.log rename to i2p2www/meetings/logs/166.log diff --git a/i2p2www/meetings/166.rst b/i2p2www/meetings/logs/166.rst similarity index 100% rename from i2p2www/meetings/166.rst rename to i2p2www/meetings/logs/166.rst diff --git a/i2p2www/meetings/167.log b/i2p2www/meetings/logs/167.log similarity index 100% rename from i2p2www/meetings/167.log rename to i2p2www/meetings/logs/167.log diff --git a/i2p2www/meetings/167.rst b/i2p2www/meetings/logs/167.rst similarity index 100% rename from i2p2www/meetings/167.rst rename to i2p2www/meetings/logs/167.rst diff --git a/i2p2www/meetings/168.log b/i2p2www/meetings/logs/168.log similarity index 100% rename from i2p2www/meetings/168.log rename to i2p2www/meetings/logs/168.log diff --git a/i2p2www/meetings/168.rst b/i2p2www/meetings/logs/168.rst similarity index 100% rename from i2p2www/meetings/168.rst rename to i2p2www/meetings/logs/168.rst diff --git a/i2p2www/meetings/170.log b/i2p2www/meetings/logs/170.log similarity index 100% rename from i2p2www/meetings/170.log rename to i2p2www/meetings/logs/170.log diff --git a/i2p2www/meetings/170.rst b/i2p2www/meetings/logs/170.rst similarity index 100% rename from i2p2www/meetings/170.rst rename to i2p2www/meetings/logs/170.rst diff --git a/i2p2www/meetings/171.log b/i2p2www/meetings/logs/171.log similarity index 100% rename from i2p2www/meetings/171.log rename to i2p2www/meetings/logs/171.log diff --git a/i2p2www/meetings/171.rst b/i2p2www/meetings/logs/171.rst similarity index 100% rename from i2p2www/meetings/171.rst rename to i2p2www/meetings/logs/171.rst diff --git a/i2p2www/meetings/172.log b/i2p2www/meetings/logs/172.log similarity index 100% rename from i2p2www/meetings/172.log rename to i2p2www/meetings/logs/172.log diff --git a/i2p2www/meetings/172.rst b/i2p2www/meetings/logs/172.rst similarity index 100% rename from i2p2www/meetings/172.rst rename to i2p2www/meetings/logs/172.rst diff --git a/i2p2www/meetings/173.log b/i2p2www/meetings/logs/173.log similarity index 100% rename from i2p2www/meetings/173.log rename to i2p2www/meetings/logs/173.log diff --git a/i2p2www/meetings/173.rst b/i2p2www/meetings/logs/173.rst similarity index 100% rename from i2p2www/meetings/173.rst rename to i2p2www/meetings/logs/173.rst diff --git a/i2p2www/meetings/174.log b/i2p2www/meetings/logs/174.log similarity index 100% rename from i2p2www/meetings/174.log rename to i2p2www/meetings/logs/174.log diff --git a/i2p2www/meetings/174.rst b/i2p2www/meetings/logs/174.rst similarity index 100% rename from i2p2www/meetings/174.rst rename to i2p2www/meetings/logs/174.rst diff --git a/i2p2www/meetings/175.log b/i2p2www/meetings/logs/175.log similarity index 100% rename from i2p2www/meetings/175.log rename to i2p2www/meetings/logs/175.log diff --git a/i2p2www/meetings/175.rst b/i2p2www/meetings/logs/175.rst similarity index 100% rename from i2p2www/meetings/175.rst rename to i2p2www/meetings/logs/175.rst diff --git a/i2p2www/meetings/176.log b/i2p2www/meetings/logs/176.log similarity index 100% rename from i2p2www/meetings/176.log rename to i2p2www/meetings/logs/176.log diff --git a/i2p2www/meetings/176.rst b/i2p2www/meetings/logs/176.rst similarity index 100% rename from i2p2www/meetings/176.rst rename to i2p2www/meetings/logs/176.rst diff --git a/i2p2www/meetings/177.log b/i2p2www/meetings/logs/177.log similarity index 100% rename from i2p2www/meetings/177.log rename to i2p2www/meetings/logs/177.log diff --git a/i2p2www/meetings/177.rst b/i2p2www/meetings/logs/177.rst similarity index 100% rename from i2p2www/meetings/177.rst rename to i2p2www/meetings/logs/177.rst diff --git a/i2p2www/meetings/178.log b/i2p2www/meetings/logs/178.log similarity index 100% rename from i2p2www/meetings/178.log rename to i2p2www/meetings/logs/178.log diff --git a/i2p2www/meetings/178.rst b/i2p2www/meetings/logs/178.rst similarity index 100% rename from i2p2www/meetings/178.rst rename to i2p2www/meetings/logs/178.rst diff --git a/i2p2www/meetings/179.log b/i2p2www/meetings/logs/179.log similarity index 100% rename from i2p2www/meetings/179.log rename to i2p2www/meetings/logs/179.log diff --git a/i2p2www/meetings/179.rst b/i2p2www/meetings/logs/179.rst similarity index 100% rename from i2p2www/meetings/179.rst rename to i2p2www/meetings/logs/179.rst diff --git a/i2p2www/meetings/18.log b/i2p2www/meetings/logs/18.log similarity index 100% rename from i2p2www/meetings/18.log rename to i2p2www/meetings/logs/18.log diff --git a/i2p2www/meetings/18.rst b/i2p2www/meetings/logs/18.rst similarity index 100% rename from i2p2www/meetings/18.rst rename to i2p2www/meetings/logs/18.rst diff --git a/i2p2www/meetings/180.log b/i2p2www/meetings/logs/180.log similarity index 100% rename from i2p2www/meetings/180.log rename to i2p2www/meetings/logs/180.log diff --git a/i2p2www/meetings/180.rst b/i2p2www/meetings/logs/180.rst similarity index 100% rename from i2p2www/meetings/180.rst rename to i2p2www/meetings/logs/180.rst diff --git a/i2p2www/meetings/181.log b/i2p2www/meetings/logs/181.log similarity index 100% rename from i2p2www/meetings/181.log rename to i2p2www/meetings/logs/181.log diff --git a/i2p2www/meetings/181.rst b/i2p2www/meetings/logs/181.rst similarity index 100% rename from i2p2www/meetings/181.rst rename to i2p2www/meetings/logs/181.rst diff --git a/i2p2www/meetings/182.log b/i2p2www/meetings/logs/182.log similarity index 100% rename from i2p2www/meetings/182.log rename to i2p2www/meetings/logs/182.log diff --git a/i2p2www/meetings/182.rst b/i2p2www/meetings/logs/182.rst similarity index 100% rename from i2p2www/meetings/182.rst rename to i2p2www/meetings/logs/182.rst diff --git a/i2p2www/meetings/183.log b/i2p2www/meetings/logs/183.log similarity index 100% rename from i2p2www/meetings/183.log rename to i2p2www/meetings/logs/183.log diff --git a/i2p2www/meetings/183.rst b/i2p2www/meetings/logs/183.rst similarity index 100% rename from i2p2www/meetings/183.rst rename to i2p2www/meetings/logs/183.rst diff --git a/i2p2www/meetings/184.log b/i2p2www/meetings/logs/184.log similarity index 100% rename from i2p2www/meetings/184.log rename to i2p2www/meetings/logs/184.log diff --git a/i2p2www/meetings/184.rst b/i2p2www/meetings/logs/184.rst similarity index 100% rename from i2p2www/meetings/184.rst rename to i2p2www/meetings/logs/184.rst diff --git a/i2p2www/meetings/185.log b/i2p2www/meetings/logs/185.log similarity index 100% rename from i2p2www/meetings/185.log rename to i2p2www/meetings/logs/185.log diff --git a/i2p2www/meetings/185.rst b/i2p2www/meetings/logs/185.rst similarity index 100% rename from i2p2www/meetings/185.rst rename to i2p2www/meetings/logs/185.rst diff --git a/i2p2www/meetings/186.log b/i2p2www/meetings/logs/186.log similarity index 100% rename from i2p2www/meetings/186.log rename to i2p2www/meetings/logs/186.log diff --git a/i2p2www/meetings/186.rst b/i2p2www/meetings/logs/186.rst similarity index 100% rename from i2p2www/meetings/186.rst rename to i2p2www/meetings/logs/186.rst diff --git a/i2p2www/meetings/187.log b/i2p2www/meetings/logs/187.log similarity index 100% rename from i2p2www/meetings/187.log rename to i2p2www/meetings/logs/187.log diff --git a/i2p2www/meetings/187.rst b/i2p2www/meetings/logs/187.rst similarity index 100% rename from i2p2www/meetings/187.rst rename to i2p2www/meetings/logs/187.rst diff --git a/i2p2www/meetings/188.log b/i2p2www/meetings/logs/188.log similarity index 100% rename from i2p2www/meetings/188.log rename to i2p2www/meetings/logs/188.log diff --git a/i2p2www/meetings/188.rst b/i2p2www/meetings/logs/188.rst similarity index 100% rename from i2p2www/meetings/188.rst rename to i2p2www/meetings/logs/188.rst diff --git a/i2p2www/meetings/189.log b/i2p2www/meetings/logs/189.log similarity index 100% rename from i2p2www/meetings/189.log rename to i2p2www/meetings/logs/189.log diff --git a/i2p2www/meetings/189.rst b/i2p2www/meetings/logs/189.rst similarity index 100% rename from i2p2www/meetings/189.rst rename to i2p2www/meetings/logs/189.rst diff --git a/i2p2www/meetings/190.log b/i2p2www/meetings/logs/190.log similarity index 100% rename from i2p2www/meetings/190.log rename to i2p2www/meetings/logs/190.log diff --git a/i2p2www/meetings/190.rst b/i2p2www/meetings/logs/190.rst similarity index 100% rename from i2p2www/meetings/190.rst rename to i2p2www/meetings/logs/190.rst diff --git a/i2p2www/meetings/191.log b/i2p2www/meetings/logs/191.log similarity index 100% rename from i2p2www/meetings/191.log rename to i2p2www/meetings/logs/191.log diff --git a/i2p2www/meetings/191.rst b/i2p2www/meetings/logs/191.rst similarity index 100% rename from i2p2www/meetings/191.rst rename to i2p2www/meetings/logs/191.rst diff --git a/i2p2www/meetings/192.log b/i2p2www/meetings/logs/192.log similarity index 100% rename from i2p2www/meetings/192.log rename to i2p2www/meetings/logs/192.log diff --git a/i2p2www/meetings/192.rst b/i2p2www/meetings/logs/192.rst similarity index 100% rename from i2p2www/meetings/192.rst rename to i2p2www/meetings/logs/192.rst diff --git a/i2p2www/meetings/193.log b/i2p2www/meetings/logs/193.log similarity index 100% rename from i2p2www/meetings/193.log rename to i2p2www/meetings/logs/193.log diff --git a/i2p2www/meetings/193.rst b/i2p2www/meetings/logs/193.rst similarity index 100% rename from i2p2www/meetings/193.rst rename to i2p2www/meetings/logs/193.rst diff --git a/i2p2www/meetings/194.log b/i2p2www/meetings/logs/194.log similarity index 100% rename from i2p2www/meetings/194.log rename to i2p2www/meetings/logs/194.log diff --git a/i2p2www/meetings/194.rst b/i2p2www/meetings/logs/194.rst similarity index 100% rename from i2p2www/meetings/194.rst rename to i2p2www/meetings/logs/194.rst diff --git a/i2p2www/meetings/195.log b/i2p2www/meetings/logs/195.log similarity index 100% rename from i2p2www/meetings/195.log rename to i2p2www/meetings/logs/195.log diff --git a/i2p2www/meetings/195.rst b/i2p2www/meetings/logs/195.rst similarity index 100% rename from i2p2www/meetings/195.rst rename to i2p2www/meetings/logs/195.rst diff --git a/i2p2www/meetings/196.log b/i2p2www/meetings/logs/196.log similarity index 100% rename from i2p2www/meetings/196.log rename to i2p2www/meetings/logs/196.log diff --git a/i2p2www/meetings/196.rst b/i2p2www/meetings/logs/196.rst similarity index 100% rename from i2p2www/meetings/196.rst rename to i2p2www/meetings/logs/196.rst diff --git a/i2p2www/meetings/197.log b/i2p2www/meetings/logs/197.log similarity index 100% rename from i2p2www/meetings/197.log rename to i2p2www/meetings/logs/197.log diff --git a/i2p2www/meetings/197.rst b/i2p2www/meetings/logs/197.rst similarity index 100% rename from i2p2www/meetings/197.rst rename to i2p2www/meetings/logs/197.rst diff --git a/i2p2www/meetings/198.log b/i2p2www/meetings/logs/198.log similarity index 100% rename from i2p2www/meetings/198.log rename to i2p2www/meetings/logs/198.log diff --git a/i2p2www/meetings/198.rst b/i2p2www/meetings/logs/198.rst similarity index 100% rename from i2p2www/meetings/198.rst rename to i2p2www/meetings/logs/198.rst diff --git a/i2p2www/meetings/199.log b/i2p2www/meetings/logs/199.log similarity index 100% rename from i2p2www/meetings/199.log rename to i2p2www/meetings/logs/199.log diff --git a/i2p2www/meetings/199.rst b/i2p2www/meetings/logs/199.rst similarity index 100% rename from i2p2www/meetings/199.rst rename to i2p2www/meetings/logs/199.rst diff --git a/i2p2www/meetings/2.log b/i2p2www/meetings/logs/2.log similarity index 100% rename from i2p2www/meetings/2.log rename to i2p2www/meetings/logs/2.log diff --git a/i2p2www/meetings/2.rst b/i2p2www/meetings/logs/2.rst similarity index 100% rename from i2p2www/meetings/2.rst rename to i2p2www/meetings/logs/2.rst diff --git a/i2p2www/meetings/20.log b/i2p2www/meetings/logs/20.log similarity index 100% rename from i2p2www/meetings/20.log rename to i2p2www/meetings/logs/20.log diff --git a/i2p2www/meetings/20.rst b/i2p2www/meetings/logs/20.rst similarity index 100% rename from i2p2www/meetings/20.rst rename to i2p2www/meetings/logs/20.rst diff --git a/i2p2www/meetings/200.log b/i2p2www/meetings/logs/200.log similarity index 100% rename from i2p2www/meetings/200.log rename to i2p2www/meetings/logs/200.log diff --git a/i2p2www/meetings/200.rst b/i2p2www/meetings/logs/200.rst similarity index 100% rename from i2p2www/meetings/200.rst rename to i2p2www/meetings/logs/200.rst diff --git a/i2p2www/meetings/201.log b/i2p2www/meetings/logs/201.log similarity index 100% rename from i2p2www/meetings/201.log rename to i2p2www/meetings/logs/201.log diff --git a/i2p2www/meetings/201.rst b/i2p2www/meetings/logs/201.rst similarity index 100% rename from i2p2www/meetings/201.rst rename to i2p2www/meetings/logs/201.rst diff --git a/i2p2www/meetings/202.log b/i2p2www/meetings/logs/202.log similarity index 100% rename from i2p2www/meetings/202.log rename to i2p2www/meetings/logs/202.log diff --git a/i2p2www/meetings/202.rst b/i2p2www/meetings/logs/202.rst similarity index 100% rename from i2p2www/meetings/202.rst rename to i2p2www/meetings/logs/202.rst diff --git a/i2p2www/meetings/203.log b/i2p2www/meetings/logs/203.log similarity index 100% rename from i2p2www/meetings/203.log rename to i2p2www/meetings/logs/203.log diff --git a/i2p2www/meetings/203.rst b/i2p2www/meetings/logs/203.rst similarity index 100% rename from i2p2www/meetings/203.rst rename to i2p2www/meetings/logs/203.rst diff --git a/i2p2www/meetings/204.log b/i2p2www/meetings/logs/204.log similarity index 100% rename from i2p2www/meetings/204.log rename to i2p2www/meetings/logs/204.log diff --git a/i2p2www/meetings/204.rst b/i2p2www/meetings/logs/204.rst similarity index 100% rename from i2p2www/meetings/204.rst rename to i2p2www/meetings/logs/204.rst diff --git a/i2p2www/meetings/205.log b/i2p2www/meetings/logs/205.log similarity index 100% rename from i2p2www/meetings/205.log rename to i2p2www/meetings/logs/205.log diff --git a/i2p2www/meetings/205.rst b/i2p2www/meetings/logs/205.rst similarity index 100% rename from i2p2www/meetings/205.rst rename to i2p2www/meetings/logs/205.rst diff --git a/i2p2www/meetings/206.log b/i2p2www/meetings/logs/206.log similarity index 100% rename from i2p2www/meetings/206.log rename to i2p2www/meetings/logs/206.log diff --git a/i2p2www/meetings/206.rst b/i2p2www/meetings/logs/206.rst similarity index 100% rename from i2p2www/meetings/206.rst rename to i2p2www/meetings/logs/206.rst diff --git a/i2p2www/meetings/207.log b/i2p2www/meetings/logs/207.log similarity index 100% rename from i2p2www/meetings/207.log rename to i2p2www/meetings/logs/207.log diff --git a/i2p2www/meetings/207.rst b/i2p2www/meetings/logs/207.rst similarity index 100% rename from i2p2www/meetings/207.rst rename to i2p2www/meetings/logs/207.rst diff --git a/i2p2www/meetings/208.log b/i2p2www/meetings/logs/208.log similarity index 100% rename from i2p2www/meetings/208.log rename to i2p2www/meetings/logs/208.log diff --git a/i2p2www/meetings/208.rst b/i2p2www/meetings/logs/208.rst similarity index 100% rename from i2p2www/meetings/208.rst rename to i2p2www/meetings/logs/208.rst diff --git a/i2p2www/meetings/209.log b/i2p2www/meetings/logs/209.log similarity index 100% rename from i2p2www/meetings/209.log rename to i2p2www/meetings/logs/209.log diff --git a/i2p2www/meetings/209.rst b/i2p2www/meetings/logs/209.rst similarity index 100% rename from i2p2www/meetings/209.rst rename to i2p2www/meetings/logs/209.rst diff --git a/i2p2www/meetings/21.log b/i2p2www/meetings/logs/21.log similarity index 100% rename from i2p2www/meetings/21.log rename to i2p2www/meetings/logs/21.log diff --git a/i2p2www/meetings/21.rst b/i2p2www/meetings/logs/21.rst similarity index 100% rename from i2p2www/meetings/21.rst rename to i2p2www/meetings/logs/21.rst diff --git a/i2p2www/meetings/210.log b/i2p2www/meetings/logs/210.log similarity index 100% rename from i2p2www/meetings/210.log rename to i2p2www/meetings/logs/210.log diff --git a/i2p2www/meetings/210.rst b/i2p2www/meetings/logs/210.rst similarity index 100% rename from i2p2www/meetings/210.rst rename to i2p2www/meetings/logs/210.rst diff --git a/i2p2www/meetings/211.log b/i2p2www/meetings/logs/211.log similarity index 100% rename from i2p2www/meetings/211.log rename to i2p2www/meetings/logs/211.log diff --git a/i2p2www/meetings/211.rst b/i2p2www/meetings/logs/211.rst similarity index 100% rename from i2p2www/meetings/211.rst rename to i2p2www/meetings/logs/211.rst diff --git a/i2p2www/meetings/212.log b/i2p2www/meetings/logs/212.log similarity index 100% rename from i2p2www/meetings/212.log rename to i2p2www/meetings/logs/212.log diff --git a/i2p2www/meetings/212.rst b/i2p2www/meetings/logs/212.rst similarity index 100% rename from i2p2www/meetings/212.rst rename to i2p2www/meetings/logs/212.rst diff --git a/i2p2www/meetings/22.log b/i2p2www/meetings/logs/22.log similarity index 100% rename from i2p2www/meetings/22.log rename to i2p2www/meetings/logs/22.log diff --git a/i2p2www/meetings/22.rst b/i2p2www/meetings/logs/22.rst similarity index 100% rename from i2p2www/meetings/22.rst rename to i2p2www/meetings/logs/22.rst diff --git a/i2p2www/meetings/23.log b/i2p2www/meetings/logs/23.log similarity index 100% rename from i2p2www/meetings/23.log rename to i2p2www/meetings/logs/23.log diff --git a/i2p2www/meetings/23.rst b/i2p2www/meetings/logs/23.rst similarity index 100% rename from i2p2www/meetings/23.rst rename to i2p2www/meetings/logs/23.rst diff --git a/i2p2www/meetings/25.log b/i2p2www/meetings/logs/25.log similarity index 100% rename from i2p2www/meetings/25.log rename to i2p2www/meetings/logs/25.log diff --git a/i2p2www/meetings/25.rst b/i2p2www/meetings/logs/25.rst similarity index 100% rename from i2p2www/meetings/25.rst rename to i2p2www/meetings/logs/25.rst diff --git a/i2p2www/meetings/26.log b/i2p2www/meetings/logs/26.log similarity index 100% rename from i2p2www/meetings/26.log rename to i2p2www/meetings/logs/26.log diff --git a/i2p2www/meetings/26.rst b/i2p2www/meetings/logs/26.rst similarity index 100% rename from i2p2www/meetings/26.rst rename to i2p2www/meetings/logs/26.rst diff --git a/i2p2www/meetings/28.log b/i2p2www/meetings/logs/28.log similarity index 100% rename from i2p2www/meetings/28.log rename to i2p2www/meetings/logs/28.log diff --git a/i2p2www/meetings/28.rst b/i2p2www/meetings/logs/28.rst similarity index 100% rename from i2p2www/meetings/28.rst rename to i2p2www/meetings/logs/28.rst diff --git a/i2p2www/meetings/29.log b/i2p2www/meetings/logs/29.log similarity index 100% rename from i2p2www/meetings/29.log rename to i2p2www/meetings/logs/29.log diff --git a/i2p2www/meetings/29.rst b/i2p2www/meetings/logs/29.rst similarity index 100% rename from i2p2www/meetings/29.rst rename to i2p2www/meetings/logs/29.rst diff --git a/i2p2www/meetings/3.log b/i2p2www/meetings/logs/3.log similarity index 100% rename from i2p2www/meetings/3.log rename to i2p2www/meetings/logs/3.log diff --git a/i2p2www/meetings/3.rst b/i2p2www/meetings/logs/3.rst similarity index 100% rename from i2p2www/meetings/3.rst rename to i2p2www/meetings/logs/3.rst diff --git a/i2p2www/meetings/30.log b/i2p2www/meetings/logs/30.log similarity index 100% rename from i2p2www/meetings/30.log rename to i2p2www/meetings/logs/30.log diff --git a/i2p2www/meetings/30.rst b/i2p2www/meetings/logs/30.rst similarity index 100% rename from i2p2www/meetings/30.rst rename to i2p2www/meetings/logs/30.rst diff --git a/i2p2www/meetings/31.log b/i2p2www/meetings/logs/31.log similarity index 100% rename from i2p2www/meetings/31.log rename to i2p2www/meetings/logs/31.log diff --git a/i2p2www/meetings/31.rst b/i2p2www/meetings/logs/31.rst similarity index 100% rename from i2p2www/meetings/31.rst rename to i2p2www/meetings/logs/31.rst diff --git a/i2p2www/meetings/32.log b/i2p2www/meetings/logs/32.log similarity index 100% rename from i2p2www/meetings/32.log rename to i2p2www/meetings/logs/32.log diff --git a/i2p2www/meetings/32.rst b/i2p2www/meetings/logs/32.rst similarity index 100% rename from i2p2www/meetings/32.rst rename to i2p2www/meetings/logs/32.rst diff --git a/i2p2www/meetings/33.log b/i2p2www/meetings/logs/33.log similarity index 100% rename from i2p2www/meetings/33.log rename to i2p2www/meetings/logs/33.log diff --git a/i2p2www/meetings/33.rst b/i2p2www/meetings/logs/33.rst similarity index 100% rename from i2p2www/meetings/33.rst rename to i2p2www/meetings/logs/33.rst diff --git a/i2p2www/meetings/34.log b/i2p2www/meetings/logs/34.log similarity index 100% rename from i2p2www/meetings/34.log rename to i2p2www/meetings/logs/34.log diff --git a/i2p2www/meetings/34.rst b/i2p2www/meetings/logs/34.rst similarity index 100% rename from i2p2www/meetings/34.rst rename to i2p2www/meetings/logs/34.rst diff --git a/i2p2www/meetings/35.log b/i2p2www/meetings/logs/35.log similarity index 100% rename from i2p2www/meetings/35.log rename to i2p2www/meetings/logs/35.log diff --git a/i2p2www/meetings/35.rst b/i2p2www/meetings/logs/35.rst similarity index 100% rename from i2p2www/meetings/35.rst rename to i2p2www/meetings/logs/35.rst diff --git a/i2p2www/meetings/4.log b/i2p2www/meetings/logs/4.log similarity index 100% rename from i2p2www/meetings/4.log rename to i2p2www/meetings/logs/4.log diff --git a/i2p2www/meetings/4.rst b/i2p2www/meetings/logs/4.rst similarity index 100% rename from i2p2www/meetings/4.rst rename to i2p2www/meetings/logs/4.rst diff --git a/i2p2www/meetings/47.log b/i2p2www/meetings/logs/47.log similarity index 100% rename from i2p2www/meetings/47.log rename to i2p2www/meetings/logs/47.log diff --git a/i2p2www/meetings/47.rst b/i2p2www/meetings/logs/47.rst similarity index 100% rename from i2p2www/meetings/47.rst rename to i2p2www/meetings/logs/47.rst diff --git a/i2p2www/meetings/49.log b/i2p2www/meetings/logs/49.log similarity index 100% rename from i2p2www/meetings/49.log rename to i2p2www/meetings/logs/49.log diff --git a/i2p2www/meetings/49.rst b/i2p2www/meetings/logs/49.rst similarity index 100% rename from i2p2www/meetings/49.rst rename to i2p2www/meetings/logs/49.rst diff --git a/i2p2www/meetings/50.log b/i2p2www/meetings/logs/50.log similarity index 100% rename from i2p2www/meetings/50.log rename to i2p2www/meetings/logs/50.log diff --git a/i2p2www/meetings/50.rst b/i2p2www/meetings/logs/50.rst similarity index 100% rename from i2p2www/meetings/50.rst rename to i2p2www/meetings/logs/50.rst diff --git a/i2p2www/meetings/51.log b/i2p2www/meetings/logs/51.log similarity index 100% rename from i2p2www/meetings/51.log rename to i2p2www/meetings/logs/51.log diff --git a/i2p2www/meetings/51.rst b/i2p2www/meetings/logs/51.rst similarity index 100% rename from i2p2www/meetings/51.rst rename to i2p2www/meetings/logs/51.rst diff --git a/i2p2www/meetings/52.log b/i2p2www/meetings/logs/52.log similarity index 100% rename from i2p2www/meetings/52.log rename to i2p2www/meetings/logs/52.log diff --git a/i2p2www/meetings/52.rst b/i2p2www/meetings/logs/52.rst similarity index 100% rename from i2p2www/meetings/52.rst rename to i2p2www/meetings/logs/52.rst diff --git a/i2p2www/meetings/53.log b/i2p2www/meetings/logs/53.log similarity index 100% rename from i2p2www/meetings/53.log rename to i2p2www/meetings/logs/53.log diff --git a/i2p2www/meetings/53.rst b/i2p2www/meetings/logs/53.rst similarity index 100% rename from i2p2www/meetings/53.rst rename to i2p2www/meetings/logs/53.rst diff --git a/i2p2www/meetings/54.log b/i2p2www/meetings/logs/54.log similarity index 100% rename from i2p2www/meetings/54.log rename to i2p2www/meetings/logs/54.log diff --git a/i2p2www/meetings/54.rst b/i2p2www/meetings/logs/54.rst similarity index 100% rename from i2p2www/meetings/54.rst rename to i2p2www/meetings/logs/54.rst diff --git a/i2p2www/meetings/55.log b/i2p2www/meetings/logs/55.log similarity index 100% rename from i2p2www/meetings/55.log rename to i2p2www/meetings/logs/55.log diff --git a/i2p2www/meetings/55.rst b/i2p2www/meetings/logs/55.rst similarity index 100% rename from i2p2www/meetings/55.rst rename to i2p2www/meetings/logs/55.rst diff --git a/i2p2www/meetings/56.log b/i2p2www/meetings/logs/56.log similarity index 100% rename from i2p2www/meetings/56.log rename to i2p2www/meetings/logs/56.log diff --git a/i2p2www/meetings/56.rst b/i2p2www/meetings/logs/56.rst similarity index 100% rename from i2p2www/meetings/56.rst rename to i2p2www/meetings/logs/56.rst diff --git a/i2p2www/meetings/57.log b/i2p2www/meetings/logs/57.log similarity index 100% rename from i2p2www/meetings/57.log rename to i2p2www/meetings/logs/57.log diff --git a/i2p2www/meetings/57.rst b/i2p2www/meetings/logs/57.rst similarity index 100% rename from i2p2www/meetings/57.rst rename to i2p2www/meetings/logs/57.rst diff --git a/i2p2www/meetings/58.log b/i2p2www/meetings/logs/58.log similarity index 100% rename from i2p2www/meetings/58.log rename to i2p2www/meetings/logs/58.log diff --git a/i2p2www/meetings/58.rst b/i2p2www/meetings/logs/58.rst similarity index 100% rename from i2p2www/meetings/58.rst rename to i2p2www/meetings/logs/58.rst diff --git a/i2p2www/meetings/59.log b/i2p2www/meetings/logs/59.log similarity index 100% rename from i2p2www/meetings/59.log rename to i2p2www/meetings/logs/59.log diff --git a/i2p2www/meetings/59.rst b/i2p2www/meetings/logs/59.rst similarity index 100% rename from i2p2www/meetings/59.rst rename to i2p2www/meetings/logs/59.rst diff --git a/i2p2www/meetings/60.log b/i2p2www/meetings/logs/60.log similarity index 100% rename from i2p2www/meetings/60.log rename to i2p2www/meetings/logs/60.log diff --git a/i2p2www/meetings/60.rst b/i2p2www/meetings/logs/60.rst similarity index 100% rename from i2p2www/meetings/60.rst rename to i2p2www/meetings/logs/60.rst diff --git a/i2p2www/meetings/61.log b/i2p2www/meetings/logs/61.log similarity index 100% rename from i2p2www/meetings/61.log rename to i2p2www/meetings/logs/61.log diff --git a/i2p2www/meetings/61.rst b/i2p2www/meetings/logs/61.rst similarity index 100% rename from i2p2www/meetings/61.rst rename to i2p2www/meetings/logs/61.rst diff --git a/i2p2www/meetings/62.log b/i2p2www/meetings/logs/62.log similarity index 100% rename from i2p2www/meetings/62.log rename to i2p2www/meetings/logs/62.log diff --git a/i2p2www/meetings/62.rst b/i2p2www/meetings/logs/62.rst similarity index 100% rename from i2p2www/meetings/62.rst rename to i2p2www/meetings/logs/62.rst diff --git a/i2p2www/meetings/63.log b/i2p2www/meetings/logs/63.log similarity index 100% rename from i2p2www/meetings/63.log rename to i2p2www/meetings/logs/63.log diff --git a/i2p2www/meetings/63.rst b/i2p2www/meetings/logs/63.rst similarity index 100% rename from i2p2www/meetings/63.rst rename to i2p2www/meetings/logs/63.rst diff --git a/i2p2www/meetings/64.log b/i2p2www/meetings/logs/64.log similarity index 100% rename from i2p2www/meetings/64.log rename to i2p2www/meetings/logs/64.log diff --git a/i2p2www/meetings/64.rst b/i2p2www/meetings/logs/64.rst similarity index 100% rename from i2p2www/meetings/64.rst rename to i2p2www/meetings/logs/64.rst diff --git a/i2p2www/meetings/65.log b/i2p2www/meetings/logs/65.log similarity index 100% rename from i2p2www/meetings/65.log rename to i2p2www/meetings/logs/65.log diff --git a/i2p2www/meetings/65.rst b/i2p2www/meetings/logs/65.rst similarity index 100% rename from i2p2www/meetings/65.rst rename to i2p2www/meetings/logs/65.rst diff --git a/i2p2www/meetings/66.log b/i2p2www/meetings/logs/66.log similarity index 100% rename from i2p2www/meetings/66.log rename to i2p2www/meetings/logs/66.log diff --git a/i2p2www/meetings/66.rst b/i2p2www/meetings/logs/66.rst similarity index 100% rename from i2p2www/meetings/66.rst rename to i2p2www/meetings/logs/66.rst diff --git a/i2p2www/meetings/68.log b/i2p2www/meetings/logs/68.log similarity index 100% rename from i2p2www/meetings/68.log rename to i2p2www/meetings/logs/68.log diff --git a/i2p2www/meetings/68.rst b/i2p2www/meetings/logs/68.rst similarity index 100% rename from i2p2www/meetings/68.rst rename to i2p2www/meetings/logs/68.rst diff --git a/i2p2www/meetings/69.log b/i2p2www/meetings/logs/69.log similarity index 100% rename from i2p2www/meetings/69.log rename to i2p2www/meetings/logs/69.log diff --git a/i2p2www/meetings/69.rst b/i2p2www/meetings/logs/69.rst similarity index 100% rename from i2p2www/meetings/69.rst rename to i2p2www/meetings/logs/69.rst diff --git a/i2p2www/meetings/7.log b/i2p2www/meetings/logs/7.log similarity index 100% rename from i2p2www/meetings/7.log rename to i2p2www/meetings/logs/7.log diff --git a/i2p2www/meetings/7.rst b/i2p2www/meetings/logs/7.rst similarity index 100% rename from i2p2www/meetings/7.rst rename to i2p2www/meetings/logs/7.rst diff --git a/i2p2www/meetings/70.log b/i2p2www/meetings/logs/70.log similarity index 100% rename from i2p2www/meetings/70.log rename to i2p2www/meetings/logs/70.log diff --git a/i2p2www/meetings/70.rst b/i2p2www/meetings/logs/70.rst similarity index 100% rename from i2p2www/meetings/70.rst rename to i2p2www/meetings/logs/70.rst diff --git a/i2p2www/meetings/71.log b/i2p2www/meetings/logs/71.log similarity index 100% rename from i2p2www/meetings/71.log rename to i2p2www/meetings/logs/71.log diff --git a/i2p2www/meetings/71.rst b/i2p2www/meetings/logs/71.rst similarity index 100% rename from i2p2www/meetings/71.rst rename to i2p2www/meetings/logs/71.rst diff --git a/i2p2www/meetings/72.log b/i2p2www/meetings/logs/72.log similarity index 100% rename from i2p2www/meetings/72.log rename to i2p2www/meetings/logs/72.log diff --git a/i2p2www/meetings/72.rst b/i2p2www/meetings/logs/72.rst similarity index 100% rename from i2p2www/meetings/72.rst rename to i2p2www/meetings/logs/72.rst diff --git a/i2p2www/meetings/73.log b/i2p2www/meetings/logs/73.log similarity index 100% rename from i2p2www/meetings/73.log rename to i2p2www/meetings/logs/73.log diff --git a/i2p2www/meetings/73.rst b/i2p2www/meetings/logs/73.rst similarity index 100% rename from i2p2www/meetings/73.rst rename to i2p2www/meetings/logs/73.rst diff --git a/i2p2www/meetings/74.log b/i2p2www/meetings/logs/74.log similarity index 100% rename from i2p2www/meetings/74.log rename to i2p2www/meetings/logs/74.log diff --git a/i2p2www/meetings/74.rst b/i2p2www/meetings/logs/74.rst similarity index 100% rename from i2p2www/meetings/74.rst rename to i2p2www/meetings/logs/74.rst diff --git a/i2p2www/meetings/75.log b/i2p2www/meetings/logs/75.log similarity index 100% rename from i2p2www/meetings/75.log rename to i2p2www/meetings/logs/75.log diff --git a/i2p2www/meetings/75.rst b/i2p2www/meetings/logs/75.rst similarity index 100% rename from i2p2www/meetings/75.rst rename to i2p2www/meetings/logs/75.rst diff --git a/i2p2www/meetings/76.log b/i2p2www/meetings/logs/76.log similarity index 100% rename from i2p2www/meetings/76.log rename to i2p2www/meetings/logs/76.log diff --git a/i2p2www/meetings/76.rst b/i2p2www/meetings/logs/76.rst similarity index 100% rename from i2p2www/meetings/76.rst rename to i2p2www/meetings/logs/76.rst diff --git a/i2p2www/meetings/77.log b/i2p2www/meetings/logs/77.log similarity index 100% rename from i2p2www/meetings/77.log rename to i2p2www/meetings/logs/77.log diff --git a/i2p2www/meetings/77.rst b/i2p2www/meetings/logs/77.rst similarity index 100% rename from i2p2www/meetings/77.rst rename to i2p2www/meetings/logs/77.rst diff --git a/i2p2www/meetings/78.log b/i2p2www/meetings/logs/78.log similarity index 100% rename from i2p2www/meetings/78.log rename to i2p2www/meetings/logs/78.log diff --git a/i2p2www/meetings/78.rst b/i2p2www/meetings/logs/78.rst similarity index 100% rename from i2p2www/meetings/78.rst rename to i2p2www/meetings/logs/78.rst diff --git a/i2p2www/meetings/79.log b/i2p2www/meetings/logs/79.log similarity index 100% rename from i2p2www/meetings/79.log rename to i2p2www/meetings/logs/79.log diff --git a/i2p2www/meetings/79.rst b/i2p2www/meetings/logs/79.rst similarity index 100% rename from i2p2www/meetings/79.rst rename to i2p2www/meetings/logs/79.rst diff --git a/i2p2www/meetings/8.log b/i2p2www/meetings/logs/8.log similarity index 100% rename from i2p2www/meetings/8.log rename to i2p2www/meetings/logs/8.log diff --git a/i2p2www/meetings/8.rst b/i2p2www/meetings/logs/8.rst similarity index 100% rename from i2p2www/meetings/8.rst rename to i2p2www/meetings/logs/8.rst diff --git a/i2p2www/meetings/80.log b/i2p2www/meetings/logs/80.log similarity index 100% rename from i2p2www/meetings/80.log rename to i2p2www/meetings/logs/80.log diff --git a/i2p2www/meetings/80.rst b/i2p2www/meetings/logs/80.rst similarity index 100% rename from i2p2www/meetings/80.rst rename to i2p2www/meetings/logs/80.rst diff --git a/i2p2www/meetings/81.log b/i2p2www/meetings/logs/81.log similarity index 100% rename from i2p2www/meetings/81.log rename to i2p2www/meetings/logs/81.log diff --git a/i2p2www/meetings/81.rst b/i2p2www/meetings/logs/81.rst similarity index 100% rename from i2p2www/meetings/81.rst rename to i2p2www/meetings/logs/81.rst diff --git a/i2p2www/meetings/82.log b/i2p2www/meetings/logs/82.log similarity index 100% rename from i2p2www/meetings/82.log rename to i2p2www/meetings/logs/82.log diff --git a/i2p2www/meetings/82.rst b/i2p2www/meetings/logs/82.rst similarity index 100% rename from i2p2www/meetings/82.rst rename to i2p2www/meetings/logs/82.rst diff --git a/i2p2www/meetings/9.log b/i2p2www/meetings/logs/9.log similarity index 100% rename from i2p2www/meetings/9.log rename to i2p2www/meetings/logs/9.log diff --git a/i2p2www/meetings/9.rst b/i2p2www/meetings/logs/9.rst similarity index 100% rename from i2p2www/meetings/9.rst rename to i2p2www/meetings/logs/9.rst diff --git a/i2p2www/meetings/90.log b/i2p2www/meetings/logs/90.log similarity index 100% rename from i2p2www/meetings/90.log rename to i2p2www/meetings/logs/90.log diff --git a/i2p2www/meetings/90.rst b/i2p2www/meetings/logs/90.rst similarity index 100% rename from i2p2www/meetings/90.rst rename to i2p2www/meetings/logs/90.rst diff --git a/i2p2www/meetings/92.log b/i2p2www/meetings/logs/92.log similarity index 100% rename from i2p2www/meetings/92.log rename to i2p2www/meetings/logs/92.log diff --git a/i2p2www/meetings/92.rst b/i2p2www/meetings/logs/92.rst similarity index 100% rename from i2p2www/meetings/92.rst rename to i2p2www/meetings/logs/92.rst diff --git a/i2p2www/meetings/93.log b/i2p2www/meetings/logs/93.log similarity index 100% rename from i2p2www/meetings/93.log rename to i2p2www/meetings/logs/93.log diff --git a/i2p2www/meetings/93.rst b/i2p2www/meetings/logs/93.rst similarity index 100% rename from i2p2www/meetings/93.rst rename to i2p2www/meetings/logs/93.rst diff --git a/i2p2www/meetings/95.log b/i2p2www/meetings/logs/95.log similarity index 100% rename from i2p2www/meetings/95.log rename to i2p2www/meetings/logs/95.log diff --git a/i2p2www/meetings/95.rst b/i2p2www/meetings/logs/95.rst similarity index 100% rename from i2p2www/meetings/95.rst rename to i2p2www/meetings/logs/95.rst diff --git a/i2p2www/meetings/99.log b/i2p2www/meetings/logs/99.log similarity index 100% rename from i2p2www/meetings/99.log rename to i2p2www/meetings/logs/99.log diff --git a/i2p2www/meetings/99.rst b/i2p2www/meetings/logs/99.rst similarity index 100% rename from i2p2www/meetings/99.rst rename to i2p2www/meetings/logs/99.rst From 5a088b76c7af40926220a1822a6cca5ebd09979a Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 07:59:22 +0000 Subject: [PATCH 204/498] Split off meetings code --- i2p2www/__init__.py | 161 ++--------------------------------- i2p2www/blog/views.py | 2 +- i2p2www/meetings/__init__.py | 0 i2p2www/meetings/helpers.py | 77 +++++++++++++++++ i2p2www/meetings/views.py | 84 ++++++++++++++++++ 5 files changed, 169 insertions(+), 155 deletions(-) create mode 100644 i2p2www/meetings/__init__.py create mode 100644 i2p2www/meetings/helpers.py create mode 100644 i2p2www/meetings/views.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 18c4bac0..fecf8534 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -1,13 +1,10 @@ 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 werkzeug.contrib.atom import AtomFeed from docutils.core import publish_parts -import datetime import os.path import os import fileinput -import codecs from random import randint try: import json @@ -53,6 +50,13 @@ url('//blog/entry/', 'blog.views.blog_entry') url('//feed/blog/rss', 'blog.views.blog_rss') url('//feed/blog/atom', 'blog.views.blog_atom') +url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) +url('//meetings/page/', 'meetings.views.meetings_index') +url('//meetings/', 'meetings.views.meetings_show') +url('//meetings/.log', 'meetings.views.meetings_show_log') +url('//meetings/.rst', 'meetings.views.meetings_show_rst') +url('//feed/meetings/atom', 'meetings.views.meetings_atom') + ################# # Babel selectors @@ -204,157 +208,6 @@ def server_error(error): return render_template('global/error_500.html'), 500 -######################## -# Meeting helper methods - -def get_meetings_feed_items(num=0): - meetings = get_meetings(num) - items = [] - for meeting in meetings: - a = {} - a['title'] = meeting['parts']['title'] - a['content'] = meeting['parts']['fragment'] - a['url'] = url_for('meetings_show', lang=g.lang, id=meeting['id']) - a['updated'] = (meeting['date'] if meeting['date'] else datetime.datetime(0)) - items.append(a) - return items - -def get_meetings(num=0): - meetings_ids = get_meetings_ids(num) - meetings = [] - for id in meetings_ids: - parts = render_meeting_rst(id) - if parts: - try: - date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y @ %H:%M %Z') - except ValueError: - try: - date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y') - except ValueError: - date = None - a = {} - a['id'] = id - a['date'] = date - a['parts'] = parts - meetings.append(a) - return meetings - -def get_meetings_ids(num=0): - """ - Returns the latest #num valid meetings, or all meetings if num=0. - """ - # list of meetings - meetings=[] - # walk over all directories/files - for v in os.walk(MEETINGS_DIR): - # iterate over all files - for f in v[2]: - # ignore all non-.rst files - if not f.endswith('.rst'): - continue - meetings.append(int(f[:-4])) - meetings.sort() - meetings.reverse() - if (num > 0): - return meetings[:num] - return meetings - -def render_meeting_rst(id): - # check if that file actually exists - name = str(id) + '.rst' - path = safe_join(MEETINGS_DIR, name) - if not os.path.exists(path): - abort(404) - - # read file - with codecs.open(path, encoding='utf-8') as fd: - content = fd.read() - - return publish_parts(source=content, source_path=MEETINGS_DIR, writer_name="html") - - -################## -# Meeting handlers - -# Meeting index -@app.route('//meetings/', defaults={'page': 1}) -@app.route('//meetings/page/') -def meetings_index(page): - all_meetings = get_meetings() - meetings = get_for_page(all_meetings, page, MEETINGS_PER_PAGE) - if not meetings and page != 1: - abort(404) - pagination = Pagination(page, MEETINGS_PER_PAGE, len(all_meetings)) - return render_template('meetings/index.html', pagination=pagination, meetings=meetings) - -# Renderer for specific meetings -@app.route('//meetings/') -def meetings_show(id, log=False, rst=False): - """ - Render the meeting X. - Either display the raw IRC .log or render as html and include .rst as header if it exists - """ - # generate file name for the raw meeting file(and header) - lname = str(id) + '.log' - hname = str(id) + '.rst' - lfile = safe_join(MEETINGS_DIR, lname) - hfile = safe_join(MEETINGS_DIR, hname) - - # check if meeting file exists and throw error if it does not.. - if not os.path.exists(lfile): - abort(404) - - # if the user just wanted the .log - if log: - # hmm... maybe replace with something non-render_template like? - # return render_template('meetings/show_raw.html', log=log) - return send_from_directory(MEETINGS_DIR, lname, mimetype='text/plain') - - log='' - header=None - - # try to load header if that makes sense - if os.path.exists(hfile): - # if the user just wanted the .rst... - if rst: - return send_from_directory(MEETINGS_DIR, hname, mimetype='text/plain') - - # open the file as utf-8 file - with codecs.open(hfile, encoding='utf-8') as fd: - header = fd.read() - elif rst: - abort(404) - - # load log - with codecs.open(lfile, encoding='utf-8') as fd: - log = fd.read() - - return render_template('meetings/show.html', log=log, header=header, id=id) - -# Just return the raw .log for the meeting -@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) - -@app.route('//feed/meetings/atom') -def meetings_atom(): - feed = AtomFeed('I2P Meetings', feed_url=request.url, url=request.url_root) - items = get_meetings_feed_items(10) - for item in items: - feed.add(item['title'], - item['content'], - title_type='html', - content_type='html', - url=item['url'], - updated=item['updated']) - return feed.get_response() - - ################### # Download handlers diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index a61d6c36..4e893464 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -1,4 +1,4 @@ -from flask import request, abort, render_template +from flask import abort, render_template, request from werkzeug.contrib.atom import AtomFeed from i2p2www import BLOG_ENTRIES_PER_PAGE diff --git a/i2p2www/meetings/__init__.py b/i2p2www/meetings/__init__.py new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/meetings/helpers.py b/i2p2www/meetings/helpers.py new file mode 100644 index 00000000..204aff0a --- /dev/null +++ b/i2p2www/meetings/helpers.py @@ -0,0 +1,77 @@ +import codecs +import datetime +from docutils.core import publish_parts +from flask import abort, g, safe_join, url_for +import os +import os.path + +from i2p2www import MEETINGS_DIR + + +######################## +# Meeting helper methods + +def get_meetings_feed_items(num=0): + meetings = get_meetings(num) + items = [] + for meeting in meetings: + a = {} + a['title'] = meeting['parts']['title'] + a['content'] = meeting['parts']['fragment'] + a['url'] = url_for('meetings_show', lang=g.lang, id=meeting['id']) + a['updated'] = (meeting['date'] if meeting['date'] else datetime.datetime(0)) + items.append(a) + return items + +def get_meetings(num=0): + meetings_ids = get_meetings_ids(num) + meetings = [] + for id in meetings_ids: + parts = render_meeting_rst(id) + if parts: + try: + date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y @ %H:%M %Z') + except ValueError: + try: + date = datetime.datetime.strptime(parts['title'], 'I2P dev meeting, %B %d, %Y') + except ValueError: + date = None + a = {} + a['id'] = id + a['date'] = date + a['parts'] = parts + meetings.append(a) + return meetings + +def get_meetings_ids(num=0): + """ + Returns the latest #num valid meetings, or all meetings if num=0. + """ + # list of meetings + meetings=[] + # walk over all directories/files + for v in os.walk(MEETINGS_DIR): + # iterate over all files + for f in v[2]: + # ignore all non-.rst files + if not f.endswith('.rst'): + continue + meetings.append(int(f[:-4])) + meetings.sort() + meetings.reverse() + if (num > 0): + return meetings[:num] + return meetings + +def render_meeting_rst(id): + # check if that file actually exists + name = str(id) + '.rst' + path = safe_join(MEETINGS_DIR, name) + if not os.path.exists(path): + abort(404) + + # read file + with codecs.open(path, encoding='utf-8') as fd: + content = fd.read() + + return publish_parts(source=content, source_path=MEETINGS_DIR, writer_name="html") diff --git a/i2p2www/meetings/views.py b/i2p2www/meetings/views.py new file mode 100644 index 00000000..8c40bce8 --- /dev/null +++ b/i2p2www/meetings/views.py @@ -0,0 +1,84 @@ +import codecs +from flask import abort, render_template, request, safe_join +import os.path +from werkzeug.contrib.atom import AtomFeed + +from i2p2www import MEETINGS_DIR, MEETINGS_PER_PAGE +from i2p2www.helpers import Pagination, get_for_page +from i2p2www.meetings.helpers import get_meetings, get_meetings_feed_items + + +################## +# Meeting handlers + +# Meeting index +def meetings_index(page): + all_meetings = get_meetings() + meetings = get_for_page(all_meetings, page, MEETINGS_PER_PAGE) + if not meetings and page != 1: + abort(404) + pagination = Pagination(page, MEETINGS_PER_PAGE, len(all_meetings)) + return render_template('meetings/index.html', pagination=pagination, meetings=meetings) + +# Renderer for specific meetings +def meetings_show(id, log=False, rst=False): + """ + Render the meeting X. + Either display the raw IRC .log or render as html and include .rst as header if it exists + """ + # generate file name for the raw meeting file(and header) + lname = str(id) + '.log' + hname = str(id) + '.rst' + lfile = safe_join(MEETINGS_DIR, lname) + hfile = safe_join(MEETINGS_DIR, hname) + + # check if meeting file exists and throw error if it does not.. + if not os.path.exists(lfile): + abort(404) + + # if the user just wanted the .log + if log: + # hmm... maybe replace with something non-render_template like? + # return render_template('meetings/show_raw.html', log=log) + return send_from_directory(MEETINGS_DIR, lname, mimetype='text/plain') + + log='' + header=None + + # try to load header if that makes sense + if os.path.exists(hfile): + # if the user just wanted the .rst... + if rst: + return send_from_directory(MEETINGS_DIR, hname, mimetype='text/plain') + + # open the file as utf-8 file + with codecs.open(hfile, encoding='utf-8') as fd: + header = fd.read() + elif rst: + abort(404) + + # load log + with codecs.open(lfile, encoding='utf-8') as fd: + log = fd.read() + + return render_template('meetings/show.html', log=log, header=header, id=id) + +# Just return the raw .log for the meeting +def meetings_show_log(id): + return meetings_show(id, log=True) + +# Just return the raw .rst for the meeting +def meetings_show_rst(id): + return meetings_show(id, rst=True) + +def meetings_atom(): + feed = AtomFeed('I2P Meetings', feed_url=request.url, url=request.url_root) + items = get_meetings_feed_items(10) + for item in items: + feed.add(item['title'], + item['content'], + title_type='html', + content_type='html', + url=item['url'], + updated=item['updated']) + return feed.get_response() From 7dbf4a35bde25aaba1693be95ad06cef92b4d78f Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 10:30:49 +0000 Subject: [PATCH 205/498] Split off legacy support code --- i2p2www/__init__.py | 40 +++++++++------------------------------- i2p2www/legacy.py | 24 ++++++++++++++++++++++++ 2 files changed, 33 insertions(+), 31 deletions(-) create mode 100644 i2p2www/legacy.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index fecf8534..c7920f78 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -57,6 +57,15 @@ url('//meetings/.log', 'meetings.views.meetings_show_log') url('//meetings/.rst', 'meetings.views.meetings_show_rst') url('//feed/meetings/atom', 'meetings.views.meetings_atom') +url('/meeting', 'legacy.legacy_meeting') +url('/meeting.html', 'legacy.legacy_meeting') +url('/status---', 'legacy.legacy_status') +url('/status---.html', 'legacy.legacy_status') +url('/_', 'legacy.legacy_show') +url('/_.html', 'legacy.legacy_show') +url('/', 'legacy.legacy_show') +url('/.html', 'legacy.legacy_show') + ################# # Babel selectors @@ -284,37 +293,6 @@ def hosts(): def robots(): return send_from_directory(STATIC_DIR, 'robots.txt', mimetype='text/plain') - -############## -# Legacy paths - -@app.route('/meeting') -@app.route('/meeting.html') -def legacy_meeting(id): - return redirect(url_for('meetings_show', id=id, lang='en')) - -@app.route('/status---') -@app.route('/status---.html') -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): - 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)) - @app.route('/favicon.ico') def favicon(): return send_from_directory(os.path.join(app.root_path, 'static'), diff --git a/i2p2www/legacy.py b/i2p2www/legacy.py new file mode 100644 index 00000000..0b6f2f0b --- /dev/null +++ b/i2p2www/legacy.py @@ -0,0 +1,24 @@ +from flask import g, redirect, url_for + + +############## +# Legacy paths + +LEGACY_MAP={ + 'download': 'downloads_list' +} + +def legacy_show(f): + 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)) + +def legacy_meeting(id): + return redirect(url_for('meetings_show', id=id, lang='en')) + +def legacy_status(year, month, day): + return redirect(url_for('blog_entry', lang='en', slug=('%s/%s/%s/status' % (year, month, day)))) From 85c2ca464c147d84c41deff194e05d6b42bc08c4 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 10:55:11 +0000 Subject: [PATCH 206/498] Added a few legacy pages (and distinguished them from pages that are now functions) --- i2p2www/legacy.py | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/i2p2www/legacy.py b/i2p2www/legacy.py index 0b6f2f0b..2068ae73 100644 --- a/i2p2www/legacy.py +++ b/i2p2www/legacy.py @@ -4,16 +4,24 @@ from flask import g, redirect, url_for ############## # Legacy paths -LEGACY_MAP={ +LEGACY_FUNCTIONS_MAP={ 'download': 'downloads_list' } +LEGACY_PAGES_MAP={ + 'bounties': 'volunteer/bounties', + 'getinvolved': 'volunteer', + 'faq': 'support/faq', +} + def legacy_show(f): 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)) + if f in LEGACY_FUNCTIONS_MAP: + return redirect(url_for(LEGACY_FUNCTIONS_MAP[f], lang=lang)) + elif f in LEGACY_PAGES_MAP: + return redirect(url_for('site_show', lang=lang, page=LEGACY_PAGES_MAP[f])) else: return redirect(url_for('site_show', lang=lang, page=f)) From 3da28685892ae18a353d859946cb8c54447e16d8 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 11:29:33 +0000 Subject: [PATCH 207/498] Added LangConverter so that /en/ can be distinguished from legacy urls like /faq This is required because "site/" was removed from the urls, but a little backend trickery is usually necessary to get the urls looking right ^_^ --- i2p2www/__init__.py | 52 ++++++++++++++++++++++++++++++--------------- 1 file changed, 35 insertions(+), 17 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index c7920f78..43c5ae28 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -1,6 +1,7 @@ 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 werkzeug.routing import BaseConverter from docutils.core import publish_parts import os.path import os @@ -33,6 +34,23 @@ app.debug = bool(os.environ.get('APP_DEBUG', 'False')) babel = Babel(app) +####################### +# Custom URL converters + +class LangConverter(BaseConverter): + def __init__(self, url_map): + super(LangConverter, self).__init__(url_map) + self.regex = '(?:[a-z]{2})' + + def to_python(self, value): + return value + + def to_url(self, value): + return value + +app.url_map.converters['lang'] = LangConverter + + ###### # URLs @@ -41,28 +59,28 @@ def url(url_rule, import_name, **options): app.add_url_rule(url_rule, view_func=view, **options) url('/', 'views.main_index') -url('//', 'views.site_show', defaults={'page': 'index'}) -url('//', 'views.site_show') +url('//', 'views.site_show', defaults={'page': 'index'}) +url('//', 'views.site_show') -url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) -url('//blog/page/', 'blog.views.blog_index') -url('//blog/entry/', 'blog.views.blog_entry') -url('//feed/blog/rss', 'blog.views.blog_rss') -url('//feed/blog/atom', 'blog.views.blog_atom') +url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) +url('//blog/page/', 'blog.views.blog_index') +url('//blog/entry/', 'blog.views.blog_entry') +url('//feed/blog/rss', 'blog.views.blog_rss') +url('//feed/blog/atom', 'blog.views.blog_atom') -url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) -url('//meetings/page/', 'meetings.views.meetings_index') -url('//meetings/', 'meetings.views.meetings_show') -url('//meetings/.log', 'meetings.views.meetings_show_log') -url('//meetings/.rst', 'meetings.views.meetings_show_rst') -url('//feed/meetings/atom', 'meetings.views.meetings_atom') +url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) +url('//meetings/page/', 'meetings.views.meetings_index') +url('//meetings/', 'meetings.views.meetings_show') +url('//meetings/.log', 'meetings.views.meetings_show_log') +url('//meetings/.rst', 'meetings.views.meetings_show_rst') +url('//feed/meetings/atom', 'meetings.views.meetings_atom') url('/meeting', 'legacy.legacy_meeting') url('/meeting.html', 'legacy.legacy_meeting') url('/status---', 'legacy.legacy_status') url('/status---.html', 'legacy.legacy_status') -url('/_', 'legacy.legacy_show') -url('/_.html', 'legacy.legacy_show') +url('/_', 'legacy.legacy_show') +url('/_.html', 'legacy.legacy_show') url('/', 'legacy.legacy_show') url('/.html', 'legacy.legacy_show') @@ -241,13 +259,13 @@ def read_mirrors(): return ret # List of downloads -@app.route('//download') +@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/') +@app.route('//download/') def downloads_select(file): if (file == 'debian'): return render_template('downloads/debian.html') From 487e9ae9350779f155ef17e1bc714fa2e78d13aa Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 11:37:11 +0000 Subject: [PATCH 208/498] Added / to the end of the base legacy url route This is required because Flask is forcing (via 301) / to be appended to the url which previously resulted in no rule matching legacy pages. We could disable strict_slashes to fix this, but it might cause issues elsewhere. --- i2p2www/__init__.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 43c5ae28..a6371c57 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -81,7 +81,7 @@ url('/status---', 'legacy.legacy_status') url('/status---.html', 'legacy.legacy_status') url('/_', 'legacy.legacy_show') url('/_.html', 'legacy.legacy_show') -url('/', 'legacy.legacy_show') +url('//', 'legacy.legacy_show') url('/.html', 'legacy.legacy_show') From 66dca619d702e2f0cd3a1ffa2669f91d93c1c1b8 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 11:43:40 +0000 Subject: [PATCH 209/498] Moved site_url macro into context processor so could use hasattr(g, 'lang') to fix a bug --- i2p2www/__init__.py | 11 +++++++++++ i2p2www/pages/global/layout.html | 2 +- i2p2www/pages/global/macros | 6 ------ 3 files changed, 12 insertions(+), 7 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index a6371c57..35165ac8 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -178,6 +178,16 @@ def restructuredtext(value): @app.context_processor def utility_processor(): + # Shorthand for getting a site url + def get_site_url(path=None): + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + if path: + return url_for('site_show', lang=lang, page=path) + else: + return url_for('site_show', lang=lang) + # Provide the canonical link to the current page def get_canonical_link(): protocol = request.url.split('//')[0] @@ -220,6 +230,7 @@ def utility_processor(): return dict(i2pconv=convert_url_to_clearnet, url_for_other_page=url_for_other_page, change_theme=change_theme, + site_url=get_site_url, canonical=get_canonical_link) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index 494d2566..b6d01ae6 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -1,4 +1,4 @@ -{%- from "global/macros" import site_url, change_lang, ver with context -%} +{%- from "global/macros" import change_lang, ver with context -%} diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index 52783c00..074b2b7b 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -1,9 +1,3 @@ -{%- 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 -%} - {%- 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) }} From 91a70314e352e53aef35ea63993aec2525f7cc69 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 11:55:05 +0000 Subject: [PATCH 210/498] Added regionalization support to LangConverter --- i2p2www/__init__.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 35165ac8..34a805d7 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -40,12 +40,18 @@ babel = Babel(app) class LangConverter(BaseConverter): def __init__(self, url_map): super(LangConverter, self).__init__(url_map) - self.regex = '(?:[a-z]{2})' + self.regex = '(?:[a-z]{2})(-[a-z]{2})?' def to_python(self, value): + parts = value.split('-') + if len(parts) == 2: + return parts[0] + '_' + parts[1].upper() return value def to_url(self, value): + parts = value.split('_') + if len(parts) == 2: + return parts[0] + '-' + parts[1].lower() return value app.url_map.converters['lang'] = LangConverter From 2ce24d59d3a494f67665a2c591546cb1b2579e14 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:00:12 +0000 Subject: [PATCH 211/498] Removed unused imports --- i2p2www/__init__.py | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 34a805d7..beccae24 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -1,11 +1,9 @@ -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 flask import Flask, request, g, redirect, url_for, abort, render_template, send_from_directory, safe_join from flaskext.babel import Babel from werkzeug.routing import BaseConverter from docutils.core import publish_parts import os.path import os -import fileinput from random import randint try: import json From bc57b82753645d33da67fff94636a7314af1da19 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:13:51 +0000 Subject: [PATCH 212/498] Added shorthand functions to make language handling more stable --- i2p2www/__init__.py | 18 ++++++++++++++++++ i2p2www/pages/global/nav.html | 15 ++++++++------- 2 files changed, 26 insertions(+), 7 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index beccae24..ba4d228b 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -192,6 +192,22 @@ def utility_processor(): else: return url_for('site_show', lang=lang) + # Shorthand for getting a language-specific url + def get_url_with_lang(endpoint, **args): + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + return url_for(endpoint, lang=lang, **args) + + # Get a specific language flag, or the flag for the current language + def get_flag(lang=None): + if not lang: + if hasattr(g, 'lang') and g.lang: + lang = g.lang + else: + lang = 'en' + return url_for('static', filename='images/flags/'+lang+'.png') + # Provide the canonical link to the current page def get_canonical_link(): protocol = request.url.split('//')[0] @@ -235,6 +251,8 @@ def utility_processor(): url_for_other_page=url_for_other_page, change_theme=change_theme, site_url=get_site_url, + get_url=get_url_with_lang, + get_flag=get_flag, canonical=get_canonical_link) diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 31b58380..eea2bed0 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -2,11 +2,11 @@
    6. {{ _('Team') }}
    7. +
    8. {{ _('Blog') }}
    9. {{ _('Hall of Fame') }}
    10. {{ _('Papers and presentations') }}
    11. {{ _('Contact us') }}
    12. @@ -125,12 +126,12 @@
    13. {{ _('Bounties') }}
    14. -
    15. {{ _('Meetings') }}
    16. +
    17. {{ _('Meetings') }}
    18. {{ _('Roadmap') }}
    19. {{ _('Task list') }}
    20. -
    21. {{ _('Language') }} +
    22. {{ _('Language') }} {% include "global/lang.html" %}
    23. From 30876c09f31760f1b2953fce843eeb15a4e3ef23 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:18:14 +0000 Subject: [PATCH 213/498] Use the new get_flag() template function in the Language menu --- i2p2www/pages/global/lang.html | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/i2p2www/pages/global/lang.html b/i2p2www/pages/global/lang.html index dab824fe..5aded9cc 100644 --- a/i2p2www/pages/global/lang.html +++ b/i2p2www/pages/global/lang.html @@ -1,14 +1,14 @@
        -
      • English
      • -
      • Castellano
      • -
      • Chinese
      • -
      • Deutsch
      • -
      • Français
      • -
      • Italiano
      • -
      • Nederlands
      • -
      • Russian
      • -
      • Svenska
      • -
      • Czech
      • -
      • Arabic
      • -
      • Greek
      • +
      • English
      • +
      • Castellano
      • +
      • Chinese
      • +
      • Deutsch
      • +
      • Français
      • +
      • Italiano
      • +
      • Nederlands
      • +
      • Russian
      • +
      • Svenska
      • +
      • Czech
      • +
      • Arabic
      • +
      • Greek
      From c7b8d77da0c1a9a863b0ccda96386acff68e1a78 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:25:19 +0000 Subject: [PATCH 214/498] Made change_theme() more stable (so 404 pages render properly) --- i2p2www/__init__.py | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index ba4d228b..bda0cc09 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -243,9 +243,14 @@ def utility_processor(): # Change the theme of the current page def change_theme(theme): - args = request.view_args.copy() + args = {} + if request.view_args: + args = request.view_args.copy() args['theme'] = theme - return url_for(request.endpoint, **args) + if request.endpoint: + return url_for(request.endpoint, **args) + # Probably a 404 error page + return url_for('main_index', **args) return dict(i2pconv=convert_url_to_clearnet, url_for_other_page=url_for_other_page, From 7701835ece85b05d828503883707b65a102060d1 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:39:53 +0000 Subject: [PATCH 215/498] Moved root file views into i2p2www.views, and committed this file (which was missed earlier) --- i2p2www/__init__.py | 21 ++++--------------- i2p2www/views.py | 50 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 54 insertions(+), 17 deletions(-) create mode 100644 i2p2www/views.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index bda0cc09..20477fb6 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -88,6 +88,10 @@ url('/_.html', 'legacy.legacy_show') url('//', 'legacy.legacy_show') url('/.html', 'legacy.legacy_show') +url('/hosts.txt', 'views.hosts') +url('/robots.txt', 'views.robots') +url('/favicon.ico', 'views.favicon') + ################# # Babel selectors @@ -337,22 +341,5 @@ def downloads_redirect(protocol, file, mirror): return redirect(mirrors[mirror]['url'] % data) return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) - -############ -# Root files - -@app.route('/hosts.txt') -def hosts(): - return send_from_directory(STATIC_DIR, 'hosts.txt', mimetype='text/plain') - -@app.route('/robots.txt') -def robots(): - return send_from_directory(STATIC_DIR, 'robots.txt', mimetype='text/plain') - -@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) diff --git a/i2p2www/views.py b/i2p2www/views.py new file mode 100644 index 00000000..dc94ae5d --- /dev/null +++ b/i2p2www/views.py @@ -0,0 +1,50 @@ +from flask import abort, redirect, render_template, safe_join, send_from_directory, url_for +import os.path + +from i2p2www import STATIC_DIR, TEMPLATE_DIR +from i2p2www.blog.helpers import get_blog_entries + + +####################### +# General page handlers + +# Index - redirects to en homepage +def main_index(): + return redirect(url_for('site_show', lang='en')) + +# Site pages +def site_show(page): + if page.endswith('.html'): + return redirect(url_for('site_show', page=page[:-5])) + name = 'site/%s.html' % page + page_file = safe_join(TEMPLATE_DIR, name) + + if not os.path.exists(page_file): + # Could be a directory, so try index.html + name = 'site/%s/index.html' % page + page_file = safe_join(TEMPLATE_DIR, name) + if not os.path.exists(page_file): + # bah! those damn users all the time! + abort(404) + + options = { + 'page': page, + } + if (page == 'index'): + options['blog_entries'] = get_blog_entries(8) + + # hah! + return render_template(name, **options) + + +############ +# Root files + +def hosts(): + return send_from_directory(STATIC_DIR, 'hosts.txt', mimetype='text/plain') + +def robots(): + return send_from_directory(STATIC_DIR, 'robots.txt', mimetype='text/plain') + +def favicon(): + return send_from_directory(STATIC_DIR, 'favicon.ico', mimetype='image/vnd.microsoft.icon') From 53d9e4030303617a24ff812e79f2b5d7d3b9d0f7 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 12:52:05 +0000 Subject: [PATCH 216/498] Split off downloads code --- i2p2www/__init__.py | 75 +++----------------------------------------- i2p2www/downloads.py | 69 ++++++++++++++++++++++++++++++++++++++++ 2 files changed, 74 insertions(+), 70 deletions(-) create mode 100644 i2p2www/downloads.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 20477fb6..72775575 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -4,11 +4,6 @@ from werkzeug.routing import BaseConverter from docutils.core import publish_parts import os.path import os -from random import randint -try: - import json -except ImportError: - import simplejson as json from helpers import LazyView, Pagination @@ -79,6 +74,11 @@ url('//meetings/.log', 'meetings.views.meetings_show_log') url('//meetings/.rst', 'meetings.views.meetings_show_rst') url('//feed/meetings/atom', 'meetings.views.meetings_atom') +url('//download', 'downloads.downloads_list') +url('//download/', 'downloads.downloads_select') +url('/download//any/', 'downloads.downloads_redirect', defaults={'mirror': None}) +url('/download///', 'downloads.downloads_redirect') + url('/meeting', 'legacy.legacy_meeting') url('/meeting.html', 'legacy.legacy_meeting') url('/status---', 'legacy.legacy_status') @@ -276,70 +276,5 @@ def page_not_found(error): def server_error(error): return render_template('global/error_500.html'), 500 - -################### -# Download handlers - -# Read in mirrors from file -def read_mirrors(): - file = open(MIRRORS_FILE, 'r') - dat = file.read() - file.close() - lines=dat.split('\n') - ret={} - for line in lines: - try: - obj=json.loads(line) - except ValueError: - continue - if 'protocol' not in obj: - continue - protocol=obj['protocol'] - if protocol not in ret: - ret[protocol]=[] - ret[protocol].append(obj) - return ret - -# List of downloads -@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): - if (file == 'debian'): - return render_template('downloads/debian.html') - mirrors=read_mirrors() - data = { - 'version': CURRENT_I2P_VERSION, - 'file': file, - } - obj=[] - for protocol in mirrors.keys(): - a={} - a['name']=protocol - a['mirrors']=mirrors[protocol] - for mirror in a['mirrors']: - mirror['url']=mirror['url'] % data - obj.append(a) - return render_template('downloads/select.html', mirrors=obj, file=file) - -@app.route('/download//any/', defaults={'mirror': None}) -@app.route('/download///') -def downloads_redirect(protocol, file, mirror): - mirrors=read_mirrors() - if not protocol in mirrors: - abort(404) - mirrors=mirrors[protocol] - data = { - 'version': CURRENT_I2P_VERSION, - 'file': file, - } - if mirror: - return redirect(mirrors[mirror]['url'] % data) - return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) - if __name__ == '__main__': app.run(debug=True) diff --git a/i2p2www/downloads.py b/i2p2www/downloads.py new file mode 100644 index 00000000..a9b32592 --- /dev/null +++ b/i2p2www/downloads.py @@ -0,0 +1,69 @@ +from flask import redirect, render_template +try: + import json +except ImportError: + import simplejson as json +from random import randint + +from i2p2www import CURRENT_I2P_VERSION, MIRRORS_FILE + + +################### +# Download handlers + +# Read in mirrors from file +def read_mirrors(): + file = open(MIRRORS_FILE, 'r') + dat = file.read() + file.close() + lines=dat.split('\n') + ret={} + for line in lines: + try: + obj=json.loads(line) + except ValueError: + continue + if 'protocol' not in obj: + continue + protocol=obj['protocol'] + if protocol not in ret: + ret[protocol]=[] + ret[protocol].append(obj) + return ret + +# List of downloads +def downloads_list(): + # TODO: read mirror list or list of available files + return render_template('downloads/list.html') + +# Specific file downloader +def downloads_select(file): + if (file == 'debian'): + return render_template('downloads/debian.html') + mirrors=read_mirrors() + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } + obj=[] + for protocol in mirrors.keys(): + a={} + a['name']=protocol + a['mirrors']=mirrors[protocol] + for mirror in a['mirrors']: + mirror['url']=mirror['url'] % data + obj.append(a) + return render_template('downloads/select.html', mirrors=obj, file=file) + +def downloads_redirect(protocol, file, mirror): + mirrors=read_mirrors() + if not protocol in mirrors: + abort(404) + mirrors=mirrors[protocol] + data = { + 'version': CURRENT_I2P_VERSION, + 'file': file, + } + if mirror: + return redirect(mirrors[mirror]['url'] % data) + return redirect(mirrors[randint(0, len(mirrors) - 1)]['url'] % data) From 9def101b3229fc11d2030ddb8ad432b0a11f7137 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 13:02:16 +0000 Subject: [PATCH 217/498] Split of template functions into a separate file --- i2p2www/__init__.py | 88 ++--------------------------------------- i2p2www/templatevars.py | 88 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+), 84 deletions(-) create mode 100644 i2p2www/templatevars.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 72775575..1f2d07f3 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -181,90 +181,6 @@ def restructuredtext(value): return parts['html_body'] -#################### -# Context processors - -@app.context_processor -def utility_processor(): - # Shorthand for getting a site url - def get_site_url(path=None): - lang = 'en' - if hasattr(g, 'lang') and g.lang: - lang = g.lang - if path: - return url_for('site_show', lang=lang, page=path) - else: - return url_for('site_show', lang=lang) - - # Shorthand for getting a language-specific url - def get_url_with_lang(endpoint, **args): - lang = 'en' - if hasattr(g, 'lang') and g.lang: - lang = g.lang - return url_for(endpoint, lang=lang, **args) - - # Get a specific language flag, or the flag for the current language - def get_flag(lang=None): - if not lang: - if hasattr(g, 'lang') and g.lang: - lang = g.lang - else: - lang = 'en' - return url_for('static', filename='images/flags/'+lang+'.png') - - # Provide the canonical link to the current page - def get_canonical_link(): - protocol = request.url.split('//')[0] - return protocol + '//' + CANONICAL_DOMAIN + request.path - - # Convert an I2P url to an equivalent clearnet one - i2ptoclear = { - 'www.i2p2.i2p': 'www.i2p2.de', - #'forum.i2p': 'forum.i2p2.de', - 'trac.i2p2.i2p': 'trac.i2p2.de', - 'mail.i2p': 'i2pmail.org', - } - 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' - - # Convert a paginated URL to that of another page - def url_for_other_page(page): - args = request.view_args.copy() - args['page'] = page - return url_for(request.endpoint, **args) - - # Change the theme of the current page - def change_theme(theme): - args = {} - if request.view_args: - args = request.view_args.copy() - args['theme'] = theme - if request.endpoint: - return url_for(request.endpoint, **args) - # Probably a 404 error page - return url_for('main_index', **args) - - return dict(i2pconv=convert_url_to_clearnet, - url_for_other_page=url_for_other_page, - change_theme=change_theme, - site_url=get_site_url, - get_url=get_url_with_lang, - get_flag=get_flag, - canonical=get_canonical_link) - - ################ # Error handlers @@ -276,5 +192,9 @@ def page_not_found(error): def server_error(error): return render_template('global/error_500.html'), 500 + +# Import these to ensure they get loaded +import templatevars + if __name__ == '__main__': app.run(debug=True) diff --git a/i2p2www/templatevars.py b/i2p2www/templatevars.py new file mode 100644 index 00000000..3790f505 --- /dev/null +++ b/i2p2www/templatevars.py @@ -0,0 +1,88 @@ +from flask import g, request, url_for + +from i2p2www import CANONICAL_DOMAIN, app + +I2P_TO_CLEAR = { + 'www.i2p2.i2p': 'www.i2p2.de', + #'forum.i2p': 'forum.i2p2.de', + 'trac.i2p2.i2p': 'trac.i2p2.de', + 'mail.i2p': 'i2pmail.org', + } + + +#################### +# Template functions + +@app.context_processor +def utility_processor(): + # Shorthand for getting a site url + def get_site_url(path=None): + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + if path: + return url_for('site_show', lang=lang, page=path) + else: + return url_for('site_show', lang=lang) + + # Shorthand for getting a language-specific url + def get_url_with_lang(endpoint, **args): + lang = 'en' + if hasattr(g, 'lang') and g.lang: + lang = g.lang + return url_for(endpoint, lang=lang, **args) + + # Get a specific language flag, or the flag for the current language + def get_flag(lang=None): + if not lang: + if hasattr(g, 'lang') and g.lang: + lang = g.lang + else: + lang = 'en' + return url_for('static', filename='images/flags/'+lang+'.png') + + # Provide the canonical link to the current page + def get_canonical_link(): + protocol = request.url.split('//')[0] + return protocol + '//' + CANONICAL_DOMAIN + request.path + + # Convert an I2P url to an equivalent clearnet one + def convert_url_to_clearnet(value): + if not value.endswith('.i2p'): + # The url being passed in isn't an I2P url, so just return it + return value + if request.headers.get('X-I2P-Desthash') and not request.headers.get('X-Forwarded-Server'): + # The request is from within I2P, so use I2P url + return value + # The request is either directly from clearnet or through an inproxy + try: + # Return the known clearnet url corresponding to the I2P url + return I2P_TO_CLEAR[value] + except KeyError: + # The I2P site has no known clearnet address, so use an inproxy + return value + '.to' + + # Convert a paginated URL to that of another page + def url_for_other_page(page): + args = request.view_args.copy() + args['page'] = page + return url_for(request.endpoint, **args) + + # Change the theme of the current page + def change_theme(theme): + args = {} + if request.view_args: + args = request.view_args.copy() + args['theme'] = theme + if request.endpoint: + return url_for(request.endpoint, **args) + # Probably a 404 error page + return url_for('main_index', **args) + + return dict(i2pconv=convert_url_to_clearnet, + url_for_other_page=url_for_other_page, + change_theme=change_theme, + site_url=get_site_url, + get_url=get_url_with_lang, + get_flag=get_flag, + canonical=get_canonical_link) From 0312088547528afb113811d8e8acd3f77e1f722b Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 20:53:18 +0000 Subject: [PATCH 218/498] Removed rel="nofollow" from the footer links to the t-shirt sites (they aren't mirrors) --- i2p2www/pages/global/footer.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html index 9edbab19..ec7df978 100644 --- a/i2p2www/pages/global/footer.html +++ b/i2p2www/pages/global/footer.html @@ -33,8 +33,8 @@
      From d633b4a704844b30570176206532be7787a2c37d Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 21:30:06 +0000 Subject: [PATCH 219/498] Split off urls --- i2p2www/__init__.py | 70 +-------------------------------------------- i2p2www/urls.py | 70 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 71 insertions(+), 69 deletions(-) create mode 100644 i2p2www/urls.py diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 1f2d07f3..1bb725c2 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -1,12 +1,9 @@ from flask import Flask, request, g, redirect, url_for, abort, render_template, send_from_directory, safe_join from flaskext.babel import Babel -from werkzeug.routing import BaseConverter from docutils.core import publish_parts import os.path import os -from helpers import LazyView, Pagination - CURRENT_I2P_VERSION = '0.9.4' CANONICAL_DOMAIN = 'www.i2p2.de' @@ -27,72 +24,6 @@ app.debug = bool(os.environ.get('APP_DEBUG', 'False')) babel = Babel(app) -####################### -# Custom URL converters - -class LangConverter(BaseConverter): - def __init__(self, url_map): - super(LangConverter, self).__init__(url_map) - self.regex = '(?:[a-z]{2})(-[a-z]{2})?' - - def to_python(self, value): - parts = value.split('-') - if len(parts) == 2: - return parts[0] + '_' + parts[1].upper() - return value - - def to_url(self, value): - parts = value.split('_') - if len(parts) == 2: - return parts[0] + '-' + parts[1].lower() - return value - -app.url_map.converters['lang'] = LangConverter - - -###### -# URLs - -def url(url_rule, import_name, **options): - view = LazyView('i2p2www.' + import_name) - app.add_url_rule(url_rule, view_func=view, **options) - -url('/', 'views.main_index') -url('//', 'views.site_show', defaults={'page': 'index'}) -url('//', 'views.site_show') - -url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) -url('//blog/page/', 'blog.views.blog_index') -url('//blog/entry/', 'blog.views.blog_entry') -url('//feed/blog/rss', 'blog.views.blog_rss') -url('//feed/blog/atom', 'blog.views.blog_atom') - -url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) -url('//meetings/page/', 'meetings.views.meetings_index') -url('//meetings/', 'meetings.views.meetings_show') -url('//meetings/.log', 'meetings.views.meetings_show_log') -url('//meetings/.rst', 'meetings.views.meetings_show_rst') -url('//feed/meetings/atom', 'meetings.views.meetings_atom') - -url('//download', 'downloads.downloads_list') -url('//download/', 'downloads.downloads_select') -url('/download//any/', 'downloads.downloads_redirect', defaults={'mirror': None}) -url('/download///', 'downloads.downloads_redirect') - -url('/meeting', 'legacy.legacy_meeting') -url('/meeting.html', 'legacy.legacy_meeting') -url('/status---', 'legacy.legacy_status') -url('/status---.html', 'legacy.legacy_status') -url('/_', 'legacy.legacy_show') -url('/_.html', 'legacy.legacy_show') -url('//', 'legacy.legacy_show') -url('/.html', 'legacy.legacy_show') - -url('/hosts.txt', 'views.hosts') -url('/robots.txt', 'views.robots') -url('/favicon.ico', 'views.favicon') - - ################# # Babel selectors @@ -195,6 +126,7 @@ def server_error(error): # Import these to ensure they get loaded import templatevars +import urls if __name__ == '__main__': app.run(debug=True) diff --git a/i2p2www/urls.py b/i2p2www/urls.py new file mode 100644 index 00000000..84ed409d --- /dev/null +++ b/i2p2www/urls.py @@ -0,0 +1,70 @@ +from werkzeug.routing import BaseConverter + +from i2p2www import app +from i2p2www.helpers import LazyView + + +####################### +# Custom URL converters + +class LangConverter(BaseConverter): + def __init__(self, url_map): + super(LangConverter, self).__init__(url_map) + self.regex = '(?:[a-z]{2})(-[a-z]{2})?' + + def to_python(self, value): + parts = value.split('-') + if len(parts) == 2: + return parts[0] + '_' + parts[1].upper() + return value + + def to_url(self, value): + parts = value.split('_') + if len(parts) == 2: + return parts[0] + '-' + parts[1].lower() + return value + +app.url_map.converters['lang'] = LangConverter + + +###### +# URLs + +def url(url_rule, import_name, **options): + view = LazyView('i2p2www.' + import_name) + app.add_url_rule(url_rule, view_func=view, **options) + +url('/', 'views.main_index') +url('//', 'views.site_show', defaults={'page': 'index'}) +url('//', 'views.site_show') + +url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) +url('//blog/page/', 'blog.views.blog_index') +url('//blog/entry/', 'blog.views.blog_entry') +url('//feed/blog/rss', 'blog.views.blog_rss') +url('//feed/blog/atom', 'blog.views.blog_atom') + +url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) +url('//meetings/page/', 'meetings.views.meetings_index') +url('//meetings/', 'meetings.views.meetings_show') +url('//meetings/.log', 'meetings.views.meetings_show_log') +url('//meetings/.rst', 'meetings.views.meetings_show_rst') +url('//feed/meetings/atom', 'meetings.views.meetings_atom') + +url('//download', 'downloads.downloads_list') +url('//download/', 'downloads.downloads_select') +url('/download//any/', 'downloads.downloads_redirect', defaults={'mirror': None}) +url('/download///', 'downloads.downloads_redirect') + +url('/meeting', 'legacy.legacy_meeting') +url('/meeting.html', 'legacy.legacy_meeting') +url('/status---', 'legacy.legacy_status') +url('/status---.html', 'legacy.legacy_status') +url('/_', 'legacy.legacy_show') +url('/_.html', 'legacy.legacy_show') +url('//', 'legacy.legacy_show') +url('/.html', 'legacy.legacy_show') + +url('/hosts.txt', 'views.hosts') +url('/robots.txt', 'views.robots') +url('/favicon.ico', 'views.favicon') From d7bce012883eb6dc7626a7a6e97bf101eefddda8 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 19 Dec 2012 21:32:10 +0000 Subject: [PATCH 220/498] Removed unnecessary block at end of __init__.py --- i2p2www/__init__.py | 3 --- 1 file changed, 3 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 1bb725c2..a9c4093a 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -127,6 +127,3 @@ def server_error(error): # Import these to ensure they get loaded import templatevars import urls - -if __name__ == '__main__': - app.run(debug=True) From f1a1d63e2aaddc6137b13453f20187242cea197c Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 01:41:26 +0000 Subject: [PATCH 221/498] Changes to the menubar CSS to bring it as close to duck's original theme as possible --- i2p2www/static/styles/duck.css | 59 ++++++++++++++++++++++------------ 1 file changed, 38 insertions(+), 21 deletions(-) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 8d36404a..0905664d 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -12,7 +12,7 @@ a {color:#d00e0e; text-decoration:none;} div.hide {display:none;} -div#branding {width:80%; margin:1em auto; position:relative;} +div#branding {width:80%; /*margin:1em auto;*/ margin: 1em auto 0; position:relative;} div#branding #logo img:hover { filter:alpha(opacity=60); -moz-opacity: 0.6; @@ -39,16 +39,17 @@ menu ul, position: relative; } #cssmenu { - height: 49px; - background: #141414; + /*height: 49px;*/ + height: 40px; + /*background: #141414; background: -moz-linear-gradient(top, #32323a 0%, #141414 100%); background: -webkit-gradient(linear, left top, left bottom, color-stop(0%, #32323a), color-stop(100%, #141414)); background: -webkit-linear-gradient(top, #32323a 0%, #141414 100%); background: -o-linear-gradient(top, #32323a 0%, #141414 100%); background: -ms-linear-gradient(top, #32323a 0%, #141414 100%); - background: linear-gradient(to bottom, #32323a 0%, #141414 100%); + 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; + /*border-bottom: 2px solid #0fa1e0;*/ } #cssmenu:after, #cssmenu ul:after { @@ -57,22 +58,26 @@ menu ul, clear: both; } #cssmenu a { - background: #141414; + /*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%); + background: linear-gradient(to bottom, #32323a 0%, #141414 100%);*/ filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#32323a', EndColorStr='#141414', GradientType=0); - color: #ffffff; + /*color: #ffffff;*/ + color: #d00e0e; display: inline-block; font-family: "URW Gothic L", "Century Gothic", sans-serif; - font-size: 11pt; + /*font-size: 11pt;*/ + font-size: 2em; font-weight: bold; text-shadow: 1px 1px 1px rgba(100,20,20,.2); - line-height: 49px; - padding: 0 20px; + /*line-height: 49px;*/ + line-height: 40px; + /*padding: 0 20px;*/ + padding: 0 10px; text-decoration: none; } #cssmenu ul { @@ -99,10 +104,11 @@ menu ul, bottom: 0; border-left: 10px solid transparent; border-right: 10px solid transparent; - border-bottom: 10px solid #0fa1e0; + /*border-bottom: 10px solid #0fa1e0;*/ + border-bottom: 10px solid #abcc71; margin-left: -10px; } -#cssmenu > ul > li:first-child > a { +/*#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; @@ -111,6 +117,11 @@ menu ul, border-radius: 0 5px 0 0; -moz-border-radius: 0 5px 0 0; -webkit-border-radius: 0 5px 0 0; +}*/ +#cssmenu > ul > li > a { + border-radius: 5px 5px 0 0; + -moz-border-radius: 5px 5px 0 0; + -webkit-border-radius: 5px 5px 0 0; } #cssmenu > ul > li.active > a { box-shadow: inset 0 0 3px #000000; @@ -126,13 +137,13 @@ menu ul, filter: progid:DXImageTransform.Microsoft.Gradient(StartColorStr='#26262c', EndColorStr='#070707', GradientType=0); } #cssmenu > ul > li:hover > a { - background: #070707; + /*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%); + 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; @@ -155,8 +166,10 @@ menu ul, *margin-bottom: -1px; } #cssmenu .has-sub ul li a { - background: #0fa1e0; - border-bottom: 1px dotted #6fc7ec; + /*background: #0fa1e0;*/ + /*border-bottom: 1px dotted #6fc7ec;*/ + background: #abcc71; + border-bottom: 1px dotted #ffffcc; filter: none; font-size: 9pt; display: block; @@ -164,7 +177,8 @@ menu ul, padding: 10px; } #cssmenu .has-sub ul li:hover a { - background: #0c7fb0; + /*background: #0c7fb0;*/ + background: #8bac51; } #cssmenu .has-sub .has-sub:hover > ul { display: block; @@ -176,11 +190,14 @@ menu ul, top: 0; } #cssmenu .has-sub .has-sub ul li a { - background: #0c7fb0; - border-bottom: 1px dotted #6db2d0; + /*background: #0c7fb0; + border-bottom: 1px dotted #6db2d0;*/ + background: #8bac51; + border-bottom: 1px dotted #ffffcc; } #cssmenu .has-sub .has-sub ul li a:hover { - background: #095c80; + /*background: #095c80;*/ + background: #6bac31; } /* End of dropdown menu CSS */ From d99220f113bd50869cfbc2df4d1a21054f4998c2 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 01:42:23 +0000 Subject: [PATCH 222/498] Added side borders to .inner and rounded the top corners --- i2p2www/static/styles/duck.css | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 0905664d..5ebe585e 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -257,6 +257,7 @@ div#content .main { div#content .inner { width:auto; margin: 0 5%; padding: 4em 5%; position:relative; background: rgba(171, 204, 113, 0.6); border-top:2px solid #abcc71; + border-left: 2px solid #abcc71; border-right: 2px solid #abcc71; border-radius: 5px 5px 0 0; color:black; font-size:1.2em; line-height:1.4em; } div#content .inner h1, div#content .inner h2, div#content .inner h3 {color:white; text-shadow:1px 1px 1px rgba(0,0,0,.3); margin:1em 0 .5em; border-bottom:1px solid white; padding-bottom:.2em;} From cc292624d22586d8ac46f1a3cb397e28fe7121b7 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 02:07:24 +0000 Subject: [PATCH 223/498] Tweak the color of the second- and third-level menus --- i2p2www/static/styles/duck.css | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 5ebe585e..1230a230 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -178,7 +178,7 @@ menu ul, } #cssmenu .has-sub ul li:hover a { /*background: #0c7fb0;*/ - background: #8bac51; + background: #8bbc51; } #cssmenu .has-sub .has-sub:hover > ul { display: block; @@ -192,7 +192,7 @@ menu ul, #cssmenu .has-sub .has-sub ul li a { /*background: #0c7fb0; border-bottom: 1px dotted #6db2d0;*/ - background: #8bac51; + background: #8bbc51; border-bottom: 1px dotted #ffffcc; } #cssmenu .has-sub .has-sub ul li a:hover { From e6e11fa905287867b6a4d87c8d80368ee91bbc89 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 02:08:53 +0000 Subject: [PATCH 224/498] Migrated docs index over to lastupdated and accuratefor tags --- i2p2www/pages/site/docs/index.html | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index 5784fa5e..22274c62 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -1,11 +1,12 @@ {% extends "global/layout.html" %} {% block title %}Index to Technical Documentation{% endblock %} +{% block lastupdated %}May 2012{% endblock %} +{% block accuratefor %}0.9{% endblock %} {% block content %}

      How does I2P work?

      Following is an index to the technical documentation for I2P. -This page was last updated in May 2012 and is accurate for router version 0.9.

      This index is ordered from the highest to lowest layers. The higher layers are for "clients" or applications; From 9527fcd19c74c8807e965c20a02080ae2a51e42e Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 04:41:03 +0000 Subject: [PATCH 225/498] Attempt to prevent title text overlapping with the header image (though second line sits behind the menu...) --- i2p2www/static/styles/duck.css | 1 + 1 file changed, 1 insertion(+) diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck.css index 1230a230..c80d0dc0 100644 --- a/i2p2www/static/styles/duck.css +++ b/i2p2www/static/styles/duck.css @@ -22,6 +22,7 @@ div#branding {width:80%; /*margin:1em auto;*/ margin: 1em auto 0; position:relat font-family:"URW Gothic L", "Century Gothic", sans-serif; text-transform:uppercase; font-size:3.5em; font-weight:bold; text-shadow:1px 1px 1px rgba(0,0,0,.2); color:#333333; position:absolute; top:0; right:0; line-height:41px; vertical-align:middle; + max-width: 70%; text-align: right; } div.navigation {position:relative;} From 3c3b4ed706f571e7d24fb916edd9f49e229b7952 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 20 Dec 2012 04:46:37 +0000 Subject: [PATCH 226/498] Moved ver() into templatevars so only need to change I2P version in one place --- i2p2www/pages/global/layout.html | 2 +- i2p2www/pages/global/macros | 6 ------ i2p2www/templatevars.py | 8 +++++++- 3 files changed, 8 insertions(+), 8 deletions(-) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index b6d01ae6..3d375aa3 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -1,4 +1,4 @@ -{%- from "global/macros" import change_lang, ver with context -%} +{%- from "global/macros" import change_lang with context -%} diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index 074b2b7b..1d709ff0 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -8,12 +8,6 @@ {%- endif -%} {%- endmacro -%} -{%- macro ver(string=None) -%} -{%- if string -%}{{ string % '0.9.4' }} -{%- else -%}{{ '0.9.4' }} -{%- endif -%} -{%- endmacro -%} - {%- macro render_pagination(pagination) %}

      diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index d61e9ff4..bfc61826 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -9,7 +9,7 @@ {%- endif %} {% if g.exttheme %}{% else -%} - + {%- endif %} diff --git a/i2p2www/static/styles/danimoth.css b/i2p2www/static/styles/danimoth/style.css similarity index 100% rename from i2p2www/static/styles/danimoth.css rename to i2p2www/static/styles/danimoth/style.css diff --git a/i2p2www/static/styles/dark.css b/i2p2www/static/styles/dark/style.css similarity index 100% rename from i2p2www/static/styles/dark.css rename to i2p2www/static/styles/dark/style.css diff --git a/i2p2www/static/styles/reset.css b/i2p2www/static/styles/duck/reset.css similarity index 100% rename from i2p2www/static/styles/reset.css rename to i2p2www/static/styles/duck/reset.css diff --git a/i2p2www/static/styles/duck.css b/i2p2www/static/styles/duck/style.css similarity index 100% rename from i2p2www/static/styles/duck.css rename to i2p2www/static/styles/duck/style.css diff --git a/i2p2www/static/styles/light.css b/i2p2www/static/styles/light/style.css similarity index 100% rename from i2p2www/static/styles/light.css rename to i2p2www/static/styles/light/style.css From a6f0d35f48a56162641e835e3469ae015eb963c4 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 11:09:50 +0000 Subject: [PATCH 344/498] Fixed image paths in CSS after move --- i2p2www/static/styles/danimoth/style.css | 2 +- i2p2www/static/styles/duck/style.css | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/i2p2www/static/styles/danimoth/style.css b/i2p2www/static/styles/danimoth/style.css index 8a013ea2..338d416a 100644 --- a/i2p2www/static/styles/danimoth/style.css +++ b/i2p2www/static/styles/danimoth/style.css @@ -45,7 +45,7 @@ nav.navigation { } div#content .feed-icon { - background-image: url('../images/feed-icon-28x28.png'); + background-image: url('../../images/feed-icon-28x28.png'); display: block; float: right; height: 28px; diff --git a/i2p2www/static/styles/duck/style.css b/i2p2www/static/styles/duck/style.css index 89837f00..a59e5d1e 100644 --- a/i2p2www/static/styles/duck/style.css +++ b/i2p2www/static/styles/duck/style.css @@ -221,7 +221,7 @@ 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; + 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; @@ -245,7 +245,7 @@ div#content .main { div#content .aside ul li {list-style-type:none; margin:1em 0; line-height:1.3em;} div#content .feed-icon { - background-image: url('../images/feed-icon-28x28.png'); + background-image: url('../../images/feed-icon-28x28.png'); display: block; float: right; height: 28px; From 3db722f00ce01c9b2f7ac678a30a9ecbdc063d47 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 11:22:19 +0000 Subject: [PATCH 345/498] Added tags to to support mobile CSS --- i2p2www/pages/global/layout.html | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index bfc61826..fa98e609 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -9,7 +9,12 @@ {%- endif %} {% if g.exttheme %}{% else -%} - + + + + {%- endif %} From 0e81362953ed2cbeb3d0189e86224e6afdd78706 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 12:29:25 +0000 Subject: [PATCH 346/498] Added basic mobile.css for duck's theme --- i2p2www/static/styles/duck/mobile.css | 31 +++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 i2p2www/static/styles/duck/mobile.css diff --git a/i2p2www/static/styles/duck/mobile.css b/i2p2www/static/styles/duck/mobile.css new file mode 100644 index 00000000..c28671f2 --- /dev/null +++ b/i2p2www/static/styles/duck/mobile.css @@ -0,0 +1,31 @@ +#topbar .title h1 { + display: none; +} + +div#content .main { + padding: 4em 10%; +} + +.main .get-i2p { + margin-bottom: -1.5em; + margin-top: .5em; + position: relative; + right: 0; +} + +div#content .aside { + margin-left: 0%; + width: 100%; +} + +.sig { + display: none; +} + +#global-footer .aside { + width: 49%; +} + +#global-footer .aside.third, #global-footer .aside.fifth { + margin-left: 0; +} From 5cfd605f090ee0a637dff251851599edc5ec98ac Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 14:34:27 +0000 Subject: [PATCH 347/498] Use progressive enhancement instead of graceful degradation for mobile support MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The default.css for duck's theme is the same content as the original theme, with some attributes removed or tweaked slightly. The original theme CSS overrides almost all of this file leaving the desktop style unchanged. Once the mobile CSS is more complete and the common CSS is identified, it can be removed from the desktop CSS. The mobile dropdown menu was obtained from http://astuteo.com/mobilemenu and as per the license on the page: "... it’s entirely free for you to download and use, modify for your own applications, or otherwise make millions off of." --- i2p2www/pages/global/layout.html | 10 +- i2p2www/static/styles/duck/default.css | 271 ++++++++++++++++++ .../styles/duck/{style.css => desktop.css} | 2 - i2p2www/static/styles/duck/mobile.css | 110 ++++++- 4 files changed, 383 insertions(+), 10 deletions(-) create mode 100644 i2p2www/static/styles/duck/default.css rename i2p2www/static/styles/duck/{style.css => desktop.css} (99%) diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index fa98e609..8917da0f 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -8,13 +8,17 @@ {%- endif %} - {% if g.exttheme %}{% else -%} - - + {% if g.exttheme %}{% else -%} + + + + {%- endif %} diff --git a/i2p2www/static/styles/duck/default.css b/i2p2www/static/styles/duck/default.css new file mode 100644 index 00000000..31bf033e --- /dev/null +++ b/i2p2www/static/styles/duck/default.css @@ -0,0 +1,271 @@ +@import url('reset.css'); + +body { + font-family: Droid Sans, Helvetica, sans-serif; + font-size: 10px; + background-color: #ffffdd; + min-height:800px; + width:100%; + background:-moz-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc; + background:-webkit-radial-gradient(50% 30% , circle , #fffff9, #ffffcc) no-repeat scroll 0 0 #ffffcc; +} + +a { + color:#d00e0e; + text-decoration:none; +} + +a:hover { + color:#f00e0e; +} + +div.hide { + display:none; +} + +div#topbar { + width:80%; + /*margin:1em auto;*/ + margin: 1em auto; + position:relative; +} + +div#topbar #logo img:hover { + filter:alpha(opacity=60); + -moz-opacity: 0.6; + opacity: 0.6; +} + +div#content { + display:block; +} + +/** + * The .main class is for content wrapper on the home page (with the big banner) + */ +div#content .main { + background:url('../../images/dots.png') 0 10% no-repeat rgba(171, 204, 113, 0.6); + background-size:100% auto; + width:auto; + padding:4em 10% 4em 10%; + position:relative; + margin:0 auto; + text-shadow:1px 1px 1px rgba(255,255,255,.5); + font-size:1.6em; + line-height:1.5em; + border:2px solid #abcc71; + border-left:none; + border-right:none; + box-shadow:0px 2px 8px rgba(0,0,0,.2) +} + +div#content .main h1 { + font-family:"URW Gothic L", "Century Gothic", sans-serif; + font-size:2.5em; + text-shadow:1px 1px 2px rgba(0,0,0,.3); + color:white; + margin-bottom:.5em; +} + +.main .get-i2p { + display:block; + top:50%; + height:1em; + padding:.5em; + line-height:1em; + font-size:2em; + color:white; + font-family:Arial, Helvetica, sans-serif; + font-weight:bold; + text-transform:uppercase; + text-decoration:none; + text-align:center; + background:green; + border-radius:.3em; + text-shadow:1px 1px 1px rgba(0,0,0,.2); + box-shadow:2px 2px 4px rgba(0, 0, 0, 0.3), 1em 3em 2em 0.5em rgba(255, 255, 255, 0.3) inset, inset -.2em -.5em 1em -0em rgba(0,0,0,.3) +} + +div#content .aside-wrap { + width:80%; + margin:2em auto; +} + +div#content .aside { + position:relative; + display:inline-block; + vertical-align:top; + font-size:1.2em +} + +div#content .aside a { + font-weight:bold; +} + +div#content .aside h1 { + padding:1em 0; + border-bottom:1px solid rgba(171, 204, 113, 0.6); + font-size:1.4em; + color:#222200; + text-shadow:1px 1px 1px rgba(0,0,0,.3) +} + +div#content .aside p { + margin:1em 0; +} + +div#content .aside ul { + margin:1em 0; +} + +div#content .aside ul li { + list-style-type:none; + margin:1em 0; + line-height:1.3em; +} + +div#content .feed-icon { + background-image: url('../../images/feed-icon-28x28.png'); + display: block; + float: right; + height: 28px; + margin: 1em; + text-indent: -9999px; + width: 28px; +} + +div#content .lastupdated { + background-color: #ffffdd; + border-radius: 0 0 5px 5px; + padding: 2px 4px; + position: absolute; + right: 10%; + text-align: right; + top: 0; + width: 200px; +} + +/** + * The .inner class is for the content wrapper on inner pages (as opposed to the home page) + */ +div#content .inner { + width:auto; + margin: 0 5%; + padding: 4em 5%; + position:relative; + background: rgba(171, 204, 113, 0.6); + border-top:2px solid #abcc71; + border-left: 2px solid #abcc71; + border-right: 2px solid #abcc71; + border-radius: 5px 5px 0 0; + color:black; + font-size:1.2em; + line-height:1.4em; +} + +div#content .inner h1, div#content .inner h2, div#content .inner h3 { + color:white; + text-shadow:1px 1px 1px rgba(0,0,0,.3); + margin:1em 0 .5em; + border-bottom:1px solid white; + padding-bottom:.2em; +} + +div#content .inner h1 { + font-size:2.2em; + margin:0em 0 1em; + width:auto; +} + +div#content .inner h2 { + font-size:1.6em; +} + +div#content .inner h3 { + font-size:1.4em; +} + +div#content .inner ol { + margin:1.5em; +} + +div#content .inner ul { + margin:1.5em; 1em; +} + +div#content .inner p { + margin:1em 0; +} + +div#content .inner td { + padding:2px 5px; +} + +.package { + border: 2px solid #d00e0e; + border-radius: 5px; + margin: 10px; + padding: 10px; +} + +.file { + border: 1px dashed #d00e0e; + margin: 5px; + padding: 5px; +} + +#global-footer { + width:auto; + border-top:3px + solid #883333; + background:#552222; + box-shadow:0px -4px 8px rgba(0,0,0,.3); + padding:1em 10%; + background:-moz-linear-gradient(#883333, #772222); +} + +#global-footer .aside { + display:inline-block; + vertical-align:top; +} + +#global-footer .aside h1 { + color:#ffdd88; + font-size:1.2em; + text-shadow:-1px -1px 1px rgba(0,0,0,.2); + border-bottom:1px solid #ccaa66; + margin:1em 0; + line-height:1.3em; +} + +#global-footer .aside ul { + margin:0; + padding:0; +} + +#global-footer .aside ul li { + list-style-type:none; + line-height:1.5em; +} + +#global-footer .aside ul li a { + color:#ccaa66; + font-weight:bold; +} + +#global-footer .aside ul li a:hover { + text-decoration:underline; +} + +#global-footer a.button { + padding:.5em 2em; + background-color:#cc2222; + border:1px solid #bb2222; + border-radius:3px; + display:inline-block; + color:white; + margin:1em auto; + text-align:center; + width:auto; + font-weight:bold; +} diff --git a/i2p2www/static/styles/duck/style.css b/i2p2www/static/styles/duck/desktop.css similarity index 99% rename from i2p2www/static/styles/duck/style.css rename to i2p2www/static/styles/duck/desktop.css index a59e5d1e..20c1dcdf 100644 --- a/i2p2www/static/styles/duck/style.css +++ b/i2p2www/static/styles/duck/desktop.css @@ -1,5 +1,3 @@ -@import url('reset.css'); - body { font-family:Droid Sans, Helvetica, sans-serif; font-size:10px; background-color:#ffffdd; diff --git a/i2p2www/static/styles/duck/mobile.css b/i2p2www/static/styles/duck/mobile.css index c28671f2..38d24f66 100644 --- a/i2p2www/static/styles/duck/mobile.css +++ b/i2p2www/static/styles/duck/mobile.css @@ -1,7 +1,109 @@ -#topbar .title h1 { +#topbar .title { display: none; } +/* Dropdown menu CSS */ + +#cssmenu > ul { + width: 100%; + float: none; + background-color: #abcc71; /* change the menu color */ + background-image: -webkit-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2)); + background-image: -moz-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2)); + background-image: -ms-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2)); + background-image: -o-linear-gradient(top, rgba(0,0,0,0), rgba(0,0,0,.2)); + display: block; + /*height: 0;*/ + height: auto; + margin: 0; + padding: 0; + overflow: hidden; + box-shadow: 0 1px 2px rgba(0,0,0,.6); + /*position: absolute;*/ + top: 0px; + left: 0px; + z-index: 998; + clear: both; +} + +#cssmenu > ul li { + /*display: none;*/ + display: block; + width: 100%; + font-family: Arial; +} + +#cssmenu > ul li div.menuitem { + display: block; + width: 90%; + padding: 10px 5%; + font-size: 14px; + font-weight: bold; + text-shadow: -1px -1px 0 rgba(0,0,0,.15); + color: white; + text-decoration: none; + border-bottom: 1px solid rgba(0,0,0,.2); + border-top: 1px solid rgba(255,255,255,.1); +} + +#cssmenu > ul li div.menuitem:hover { + background-color: rgba(0,0,0,.5); + border-top-color: transparent; +} + +#cssmenu > ul > li:first-child { + border-top: 1px solid rgba(0,0,0,.2); +} + +/* Toggle the navigation bar open */ + +#cssmenu > ul.open { + height: auto; + /*padding-top: 50px;*/ +} + +#cssmenu > ul.open li { + display: block; +} + +/* Submenus – .has-sub class indicates dropdowns */ + +#cssmenu > ul > li:hover > div.menuitem { + background: rgba(0,0,0,.5); + border-bottom-color: transparent; +} + +#cssmenu > ul li.has-sub > div.menuitem:after { + content: "▼"; + color: rgba(255,255,255,.5); + float: right; +} + +#cssmenu > ul li.has-sub > div.menuitem:hover { + background: rgba(0,0,0,.75); +} + +#cssmenu > ul li ul { + display: none; + background: rgba(0,0,0,.5); + border-top: 0 none; + padding: 0; +} + +#cssmenu > ul li ul div.menuitem { + border: 0 none; + font-size: 12px; + padding: 10px 5%; + font-weight: normal; +} + +#cssmenu > ul li:hover > ul { + display: block; + border-top: 0 none; +} + +/* End of dropdown menu CSS */ + div#content .main { padding: 4em 10%; } @@ -9,12 +111,9 @@ div#content .main { .main .get-i2p { margin-bottom: -1.5em; margin-top: .5em; - position: relative; - right: 0; } div#content .aside { - margin-left: 0%; width: 100%; } @@ -23,9 +122,10 @@ div#content .aside { } #global-footer .aside { + margin-left: 1%; width: 49%; } -#global-footer .aside.third, #global-footer .aside.fifth { +#global-footer .aside.first, #global-footer .aside.third, #global-footer .aside.fifth { margin-left: 0; } From f063149ab364f106ca1c23e66c2f57bbfc181377 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 14:38:50 +0000 Subject: [PATCH 348/498] Migrated other themes: style.css -> desktop.css --- i2p2www/__init__.py | 2 +- i2p2www/static/styles/danimoth/{style.css => desktop.css} | 0 i2p2www/static/styles/dark/{style.css => desktop.css} | 0 i2p2www/static/styles/light/{style.css => desktop.css} | 0 4 files changed, 1 insertion(+), 1 deletion(-) rename i2p2www/static/styles/danimoth/{style.css => desktop.css} (100%) rename i2p2www/static/styles/dark/{style.css => desktop.css} (100%) rename i2p2www/static/styles/light/{style.css => desktop.css} (100%) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index 41e9a230..ac3a4739 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -113,7 +113,7 @@ def detect_theme(): if theme[:7] == 'http://': g.exttheme = theme theme = 'duck' - if not os.path.isfile(safe_join(safe_join(STATIC_DIR, 'styles'), '%s/style.css' % theme)): + if not os.path.isfile(safe_join(safe_join(STATIC_DIR, 'styles'), '%s/desktop.css' % theme)): theme = 'duck' g.theme = theme @after_this_request diff --git a/i2p2www/static/styles/danimoth/style.css b/i2p2www/static/styles/danimoth/desktop.css similarity index 100% rename from i2p2www/static/styles/danimoth/style.css rename to i2p2www/static/styles/danimoth/desktop.css diff --git a/i2p2www/static/styles/dark/style.css b/i2p2www/static/styles/dark/desktop.css similarity index 100% rename from i2p2www/static/styles/dark/style.css rename to i2p2www/static/styles/dark/desktop.css diff --git a/i2p2www/static/styles/light/style.css b/i2p2www/static/styles/light/desktop.css similarity index 100% rename from i2p2www/static/styles/light/style.css rename to i2p2www/static/styles/light/desktop.css From a5a5e20f3b9c1a199a2d1fdabb93f93129905ba2 Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 22:32:15 +0000 Subject: [PATCH 349/498] Use right arrow instead of thick border for submenu indication --- i2p2www/static/styles/duck/desktop.css | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/i2p2www/static/styles/duck/desktop.css b/i2p2www/static/styles/duck/desktop.css index 20c1dcdf..7859031f 100644 --- a/i2p2www/static/styles/duck/desktop.css +++ b/i2p2www/static/styles/duck/desktop.css @@ -170,8 +170,10 @@ menu ul, border-left: 1px solid #ffffcc; /*margin-bottom: -1px;*/ } -#cssmenu .has-sub ul li.has-sub { - border-right: 5px solid #4B9C31 +#cssmenu .has-sub ul li.has-sub > div.menuitem:after { + content: "►"; + color: rgba(255,255,255,.5); + float: right; } #cssmenu .has-sub ul li div.menuitem { /*background: #0fa1e0;*/ @@ -196,7 +198,6 @@ menu ul, position: absolute; left: 100%; top: 0; - margin-left: 5px; } #cssmenu .has-sub .has-sub ul li:first-child { border-left: none; From 8eea7b22a3f1bde8495a26f3cd2287cd05ebdbae Mon Sep 17 00:00:00 2001 From: str4d Date: Mon, 21 Jan 2013 22:38:31 +0000 Subject: [PATCH 350/498] Added space between mobile dropdown menu and content --- i2p2www/static/styles/duck/mobile.css | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/i2p2www/static/styles/duck/mobile.css b/i2p2www/static/styles/duck/mobile.css index 38d24f66..86f1b200 100644 --- a/i2p2www/static/styles/duck/mobile.css +++ b/i2p2www/static/styles/duck/mobile.css @@ -117,6 +117,10 @@ div#content .aside { width: 100%; } +div#content .inner { + margin-top: 1em; +} + .sig { display: none; } From 827c6dc734d5fa8c6f4169c81d68bbb3d6e40072 Mon Sep 17 00:00:00 2001 From: dev Date: Tue, 22 Jan 2013 22:24:21 +0000 Subject: [PATCH 351/498] Tagged get-involved/guides/monotone.html for translation. --- .../site/get-involved/guides/monotone.html | 228 +++++++++++++----- 1 file changed, 161 insertions(+), 67 deletions(-) diff --git a/i2p2www/pages/site/get-involved/guides/monotone.html b/i2p2www/pages/site/get-involved/guides/monotone.html index 12f092db..b92451c0 100644 --- a/i2p2www/pages/site/get-involved/guides/monotone.html +++ b/i2p2www/pages/site/get-involved/guides/monotone.html @@ -1,145 +1,174 @@ {% extends "global/layout.html" %} {% block title %}Monotone{% endblock %} {% block content %} -

      Monotone Guide

      +

      {% trans %}Monotone Guide{% endtrans %}

      + {% trans -%} This is a revised version of Complication's original guide detailing the use of Monotone in I2P development. For basic instructions see the quick-start guide. + {%- endtrans %}

      + {% trans -%} I2P has a distributed development model. The source code is replicated across independently administered Monotone ("MTN") repositories. Developers with commit rights are able to push their changes to the repository (a license agreement needs to be signed before commit rights are granted). + {%- endtrans %}

      + {% trans -%} Some of Monotone's noteworthy qualities are: distributed version control, cryptographic authentication, access control, its small size, having few dependencies, storage of projects in a compressed SQLite database file, and having the ability to resume interrupted synchronization attempts. + {%- endtrans %}

      -

      Operating a Monotone Client

      +

      {% trans %}Operating a Monotone Client{% endtrans %}

      -

      Generating Monotone keys

      +

      {% trans %}Generating Monotone keys{% endtrans %}

      + {% trans -%} A transport key grants you the ability to push your changes to a Monotone repository server. In order to commit code into Monotone (in essence signing your code), a commit key is also needed. None of the public Monotone servers on I2P currently require a key in order to read (or pull) the source code. + {%- endtrans %}

      + {% trans -%} Without a transport key, one cannot:

      • pull code from a server which doesn't allow global read access
      • push code to any server
      • run a Monotone server
      + {%- endtrans %}

      + {% trans -%} Without a commit key, one cannot:

      • commit any code
      + {%- endtrans %}

      + {% trans -%} If you only intend to retrieve code from MTN, feel free to skip to the next section. If you want to generate keys, read the following. + {%- endtrans %}

      + {% trans -%} By convention keys are named like an e-mail addresses, but a corresponding e-mail address does not need to exist. For example, your keys might be named:

      • yourname@mail.i2p
      • yourname-transport@mail.i2p
      + {%- endtrans %}

      + {% trans -%} Monotone stores keys under $HOME/.monotone/keys in text files which are named identically to the keys. For example:

      • /home/complication/.monotone/keys/complication@mail.i2p
      + {%- endtrans %}

      + {% trans -%} To generate transport and commit keys, enter the following commands at a prompt:

      • $ mtn genkey yourname-transport@someplace
      • $ mtn genkey yourname@someplace
      + {%- endtrans %}

      + {% trans -%} Monotone will prompt you for a password to protect your keys. You are very strongly encouraged to set a password for the commit key. Many users will leave an empty password for the transport key, especially those running a Monotone server. + {%- endtrans %}

      -

      Trust, and initializing your repository

      +

      {% trans %}Trust, and initializing your repository{% endtrans %}

      + {% trans -%} Monotone's security model helps to ensure that nobody can easily impersonate a developer without it being noticed. Since developers can make mistakes and become compromised,only manual review can ensure quality of code. Monotone's trust model will ensure that you read the right diffs. It does not replace reading diffs. + {%- endtrans %}

      + {% trans -%} A Monotone repository is a single file (a compressed SQLite database) which contains all of the project's source code and history. + {%- endtrans %}

      + {% trans -%} After importing the developers' keys into Monotone and setting up trust evaluation hooks, Monotone will prevent untrusted code from being checked out into your workspace. There are commands available to clean untrusted code from your workspace but in practice they've not been needed due to the push access policies in place. + {%- endtrans %}

      + {% trans -%} A repository can hold many branches. For example, our repository holds the following main branches:

        @@ -147,126 +176,160 @@
      • i2p.www — The I2P project website
      • i2p.syndie — Syndie, a distributed forums tool
      + {%- endtrans %}

      -By convention, the I2P Monotone repository is named i2p.mtn. Before pulling + {% trans -%} + By convention, the I2P Monotone repository is named i2p.mtn. Before pulling source code from servers, a database for your repository will need to be initialized. To initialize your local repository, change into the directory that you want the i2p.mtn file and branch directories to be stored and issue the following command: + {%- endtrans %}

      • $ mtn --db="i2p.mtn" db init

      -

      Obtaining and deploying developers' keys

      +

      {% trans %}Obtaining and deploying developers' keys{% endtrans %}

      + {% trans -%} Keys which developers use to commit code are essential for trust evaluation in Monotone. The other developers' transport keys are only required for Monotone server operators. + {% endtrans %}

      -Developers' commit keys are provided GPG-signed on another page. + {% trans -%} + Developers' commit keys are provided GPG-signed on another page. + {%- endtrans %}

      -To import developers' keys after verifying their authenticity, copy all of the keys into a new -file. Create this file (e.g. keys.txt) in the same directory where i2p.mtn is located. Import the keys with the command: -

        -
      • $ mtn --db="i2p.mtn" read < keys.txt
      • -
      + {% trans -%} + To import developers' keys after verifying their authenticity, copy all of the keys into a new + file. Create this file (e.g. keys.txt) in the same directory where i2p.mtn is located. Import the keys with the command: + {%- endtrans %} +
        +
      • $ mtn --db="i2p.mtn" read < keys.txt
      • +

      + {% trans -%} Note: Never add keys to $HOME/.monotone/keys manually. + {%- endtrans %}

      -

      Setting up trust evaluation hooks

      +

      {% trans %}Setting up trust evaluation hooks{% endtrans %}

      + {% trans -%} The default Monotone trust policy is way too lax for our requirements: every comitter is trusted by default. That is not acceptable for I2P development. + {%- endtrans %}

      -Change into the directory $HOME/.monotone and open the file -monotonerc with a text editor. Copy and paste the following two functions into this file: + {% trans -%} + Change into the directory $HOME/.monotone and open the file + monotonerc with a text editor. Copy and paste the following two functions into this file: + {%- endtrans %}

      {% include "include/monotonerc.html" %}

      + {% trans -%} The first function determines an intersection between two sets, in our case a revision's signers and trusted signers. + {%- endtrans %}

      + {% trans -%} The second function determines trust in a given revision, by calling the first function with "signers" and "trusted" as arguments. If the intersection is null, the revision is not trusted. If the intersection is not empty, the revision is trusted. Otherwise, the revision is not trusted. + {%- endtrans %}

      -More information about Trust Evauluation Hooks can be found in the official Monotone documentation. + {% trans -%} + More information about Trust Evauluation Hooks can be found in the official Monotone documentation. + {%- endtrans %}

      -

      Pulling the i2p.i2p, i2p.www and i2p.syndie branches

      +

      {% trans %}Pulling the i2p.i2p, i2p.www and i2p.syndie branches{% endtrans %}

      -Enter the directory where you initialized i2p.mtn. Depending on whether you + {% trans -%} + Enter the directory where you initialized i2p.mtn. Depending on whether you want only I2P sources, or also sources for the I2P website and Syndie, you can perform the pull operation in different ways. + {%- trans %}

      + {% trans -%} If you only want I2P sources: + {%- endtrans %}

      • $ mtn --db="i2p.mtn" -k "" pull 127.0.0.1:8998 i2p.i2p

      + {% trans -%} If you want all branches: + {%- endtrans %}

      • $ mtn --db="i2p.mtn" -k "" pull 127.0.0.1:8998 "i2p.*"
      + {% trans -%} If the transfer aborts before completing sucessfully, simply repeating the pull command will resume the transfer. + {%- endtrans %}

      + {% trans -%} Pulling in the above examples is done anonymously by specifying an empty transport key. If everyone pulls anonymously it will be harder for an attacker who gains control of the server to selectively provide some people with tampered data. + {%- endtrans %}

      -

      Verifying that trust evaluation works

      +

      {% trans %}Verifying that trust evaluation works{% endtrans %}

      -To verify that trust evaluation works: -

    -

    - {% trans -%} - This is a revised version of Complication's original +

    + {% trans transitionguide=site_url('misc/transition-guide'), newdevs=site_url('get-involved/guides/new-developers') -%} + This is a revised version of Complication's original guide detailing the use of Monotone in I2P development. - For basic instructions see the quick-start guide. + For basic instructions see the quick-start guide. {%- endtrans %} -

    +

    - {% trans -%} + {% trans licenses=site_url('get-involved/develop/licenses') -%} I2P has a distributed development model. The source code is replicated across independently administered Monotone ("MTN") repositories. Developers with commit rights are able to push their changes to the repository - (a license agreement needs to be signed + (a license agreement needs to be signed before commit rights are granted). {%- endtrans %}

    @@ -102,31 +102,31 @@ {% trans -%} By convention keys are named like an e-mail addresses, but a corresponding e-mail address does not need to exist. For example, your keys might be named: + {%- endtrans %}
    • yourname@mail.i2p
    • yourname-transport@mail.i2p
    - {%- endtrans %}

    {% trans -%} Monotone stores keys under $HOME/.monotone/keys in text files which are named identically to the keys. For example: + {%- endtrans %}

    • /home/complication/.monotone/keys/complication@mail.i2p
    - {%- endtrans %}

    {% trans -%} To generate transport and commit keys, enter the following commands at a prompt: + {%- endtrans %}

    • $ mtn genkey yourname-transport@someplace
    • $ mtn genkey yourname@someplace
    - {%- endtrans %}

    @@ -171,12 +171,12 @@ {% trans -%} A repository can hold many branches. For example, our repository holds the following main branches: -

      -
    • i2p.i2p — The I2P router and associated programs
    • -
    • i2p.www — The I2P project website
    • -
    • i2p.syndie — Syndie, a distributed forums tool
    • -
    {%- endtrans %} +
      +
    • i2p.i2p — {% trans %}The I2P router and associated programs{% endtrans %}
    • +
    • i2p.www — {% trans %}The I2P project website{% endtrans %}
    • +
    • i2p.syndie — {% trans %}Syndie, a distributed forums tool{% endtrans %}
    • +

    @@ -203,14 +203,14 @@

    - {% trans -%} - Developers' commit keys are provided GPG-signed on another page. + {% trans signedkeys=site_url('get-involved/develop/signed-keys') -%} + Developers' commit keys are provided GPG-signed on another page. {%- endtrans %}

    - {% trans -%} - To import developers' keys after verifying their authenticity, copy all of the keys into a new + {% trans devkeys=site_url('get-involved/develop/developers-keys') -%} + To import developers' keys after verifying their authenticity, copy all of the keys into a new file. Create this file (e.g. keys.txt) in the same directory where i2p.mtn is located. Import the keys with the command: {%- endtrans %}

      @@ -310,24 +310,29 @@

      {% trans -%} To verify that trust evaluation works: -

      Monotone

        -
      • +
      • {% trans -%} Have a basic understanding of distributed source control systems, even if you haven't used monotone before. Ask for help if you need it. Once pushed, checkins are forever, there is no undo. Please be careful. If you have not used monotone before, start with baby steps. Check in some small changes and see how it goes. -
      • +{%- endtrans %}
      • +
      • {% trans -%} Test your changes before checking them in. If you prefer the checkin-before-test development model, use your own development branch (e.g. i2p.i2p.yourname.test) @@ -44,87 +47,102 @@ and propagate back to i2p.i2p once it is working well. Do not break the build. Do not cause regressions. In case you do (it happens), please do not vanish for a long period after you push your change. -
      • +{%- endtrans %}
      • +
      • {% trans -%} If your change is non-trivial, or you want people to test it and need good test reports to know whether your change was tested or not, add a checkin comment to history.txt and increment the build revision in RouterVersion.java. -
      • +{%- endtrans %}
      • +
      • {% trans -%} Ensure that you have the latest monotonerc file in _MTN. Do not check in on top of untrusted revisions. -
      • +{%- endtrans %}
      • +
      • {% trans -%} Ensure that you pull the latest revision before you check in. If you inadvertently diverge, merge and push as soon as possible. Don't routinely make others merge for you. Yes, we know that monotone says you should push and then merge, but in our experience, in-workspace merge works just as well as in-database merge, without creating a merge revision. -
      • +{%- endtrans %}
      • +
      • {% trans -%} Do not check in major changes into the main i2p.i2p branch late in the release cycle. If a project will take you more than a couple days, create your own branch in monotone and do the development there so you do not block releases. -
      +{%- endtrans %} +
    -

    Coding Style

    +

    {{ _('Coding Style') }}

      -
    • +
    • {% trans -%} Coding style throughout most of the code is 4-spaces for indentation. Do not use tabs. Do not reformat code. If your IDE or editor wants to reformat everything, get control of it. Yes, we know 4 spaces is a pain, but perhaps you can configure your editor appropriately. In some places, the coding style is different. Use common sense. Emulate the style in the file you are modifying. -
    • +{%- endtrans %}
    • +
    • {% trans -%} New classes and methods require at least brief javadocs. Add @since release-number. -
    • +{%- endtrans %}
    • +
    • {% trans -%} Classes in core/ (i2p.jar) and portions of i2ptunnel are part of our official API. There are several out-of-tree plugins and other applications that rely on this API. Be careful not to make any changes that break compatibility. Don't add methods to the API unless they are of general utility. Javadocs for API methods should be clear and complete. If you add or change the API, also update the documentation on the website (i2p.www branch). -
    • +{%- endtrans %}
    • +
    • {% trans -%} Tag strings for translation where appropriate. Don't change existing tagged strings unless really necessary, as it will break existing translations. Do not add or change tagged strings after the "tag freeze" in the release cycle so that translators have a chance to update before the release. -
    • +{%- endtrans %}
    • +
    • {% trans -%} Use generics and concurrent classes where possible. I2P is a highly multi-threaded application. -
    • +{%- endtrans %}
    • +
    • {% trans -%} We require Java 6 to build but only Java 5 to run I2P. Do not use Java 6 classes or methods without handling the class not found exceptions and providing alternate Java 5 code. See classes in net.i2p.util for examples. -
    • +{%- endtrans %}
    • +
    • {% trans -%} Explicitly convert between primitive types and classes; don't rely on autoboxing/unboxing. -
    +{%- endtrans %}
  • + -

    Licenses

    +

    {{ _('Licenses') }}

      -
    • +
    • {% trans -%} Only check in code that you wrote yourself. Before checking in any code or library jars from other sources, justify why it is necessary, verify the license is compatible, and obtain approval from the lead developer. -
    • +{%- endtrans %}
    • +
    • {% trans -%} For any images checked in from external sources, it is your responsibility to first verify the license is compatible. Include the license and source information in the checkin comment. -
    +{%- endtrans %} + -

    Bugs

    +

    {{ _('Bugs') }}

      -
    • +
    • {% trans trac=i2pconv('trac.i2p2.i2p') -%} Managing Trac tickets is everybody's job, please help. -Monitor trac.i2p2.i2p for tickets you have been assigned or can help with. -Asssign, categorize, comment on, fix, or close tickets if you can. -
    • +Monitor {{ trac }} for tickets you have been assigned or can help with. +Assign, categorize, comment on, fix, or close tickets if you can. +{%- endtrans %}
    • +
    • {% trans -%} Close a ticket when you think you've fixed it. We don't have a test department to verify and close tickets. If you arent sure you fixed it, close it and add a note saying "I think I fixed it, please test and reopen if it's still broken". Add a comment with the dev build number or revision and set the milestone to the next release. -
    • +{%- endtrans %}
    {% endblock %} diff --git a/i2p2www/pages/site/get-involved/guides/ides.html b/i2p2www/pages/site/get-involved/guides/ides.html index f73c46e6..bb116c0f 100644 --- a/i2p2www/pages/site/get-involved/guides/ides.html +++ b/i2p2www/pages/site/get-involved/guides/ides.html @@ -1,51 +1,51 @@ {% extends "global/layout.html" %} -{% block title %}Using an IDE with I2P{% endblock %} +{% block title %}{{ _('Using an IDE with I2P') }}{% endblock %} {% block content %} -

    +

    {% trans -%} The main I2P development branch (i2p.i2p) has been set up to enable developers to easily set up two of the commonly-used IDEs for Java development: Eclipse and NetBeans. -

    +{%- endtrans %}

    Eclipse

    -

    +

    {% trans -%} The main I2P development branches (i2p.i2p and branches from it) contain .project and .classpath Eclipse files, to enable the branch to be easily set up in Eclipse. -

    +{%- endtrans %}

      -
    1. +
    2. {% trans -%} Check out the I2P branch into some directory (e.g. $HOME/dev/i2p.i2p). -
    3. +{%- endtrans %} -
    4. +
    5. {% trans -%} Open Eclipse and create a new Workspace, based in the directory that the I2P branch was checked out to. -
    6. +{%- endtrans %} -
    7. +
    8. {% trans -%} Select "File - Import..." and then under "General" select "Existing Projects into Workspace". -
    9. +{%- endtrans %} -
    10. +
    11. {% trans -%} For "Select root directory:" choose the directory that the I2P branch was checked out to. -
    12. +{%- endtrans %} -
    13. +
    14. {% trans -%} If necessary, click "Refresh" to refresh the list of projects. -
    15. +{%- endtrans %} -
    16. +
    17. {% trans -%} Select every project in the list, and click "Finish". -
    18. +{%- endtrans %} -
    19. +
    20. {% trans -%} Done! Your workspace should now contain all projects within the I2P branch, and their build dependencies should be correctly set up. -
    21. +{%- endtrans %}

    NetBeans

    -

    +

    {% trans -%} The main I2P development branches (i2p.i2p and branches from it) contain NetBeans project files. -

    +{%- endtrans %}

    {% endblock %} From 8feb48485dc7ff9e8959f40aaf79df82d1223dee Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 26 Jan 2013 02:15:45 +0000 Subject: [PATCH 354/498] Added translation tags to get-involved/guides/new-developers --- .../get-involved/guides/new-developers.html | 264 +++++++++--------- 1 file changed, 134 insertions(+), 130 deletions(-) diff --git a/i2p2www/pages/site/get-involved/guides/new-developers.html b/i2p2www/pages/site/get-involved/guides/new-developers.html index b4615daa..a2d0178a 100644 --- a/i2p2www/pages/site/get-involved/guides/new-developers.html +++ b/i2p2www/pages/site/get-involved/guides/new-developers.html @@ -1,186 +1,190 @@ {% extends "global/layout.html" %} -{% block title %}New Developer's Guide{% endblock %} +{% block title %}{% trans %}New Developer's Guide{% endtrans %}{% endblock %} {% block content %} -

    - So you want to start work on I2P? Great! - Here's a quick guide to getting started - on contributing to the website or the software, doing development or creating translations. -

    -

    - Not quite ready for coding? - Try getting involved first. -

    +

    {% trans %} +So you want to start work on I2P? Great! +Here's a quick guide to getting started +on contributing to the website or the software, doing development or creating translations. +{%- endtrans %}

    +

    {% trans volunteer=site_url('get-involved') %} +Not quite ready for coding? +Try getting involved first. +{%- endtrans %}

    -

    Basic 'study'

    +

    {% trans %}Basic study{% endtrans %}

    -

    - Basic development on the I2P router or the embedded applications uses Java as the main development language. - If you don't have experience with Java, you can always have a look at Thinking in Java. -

    -

    - Study the how intro, - the other "how" documents, - the tech intro, - and associated documents. - These will give you a good overview of how I2P is structured and what different things it does. -

    +

    {% trans -%} +Basic development on the I2P router or the embedded applications uses Java as the main development language. +If you don't have experience with Java, you can always have a look at Thinking in Java. +{%- endtrans %}

    +

    {% trans intro=site_url('docs/how/intro'), docs=site_url('docs'), techintro=site_url('docs/how/tech-intro') -%} +Study the how intro, +the other "how" documents, +the tech intro, +and associated documents. +These will give you a good overview of how I2P is structured and what different things it does. +{%- endtrans %}

    -

    Getting the I2P code

    +

    {% trans %}Getting the I2P code{% endtrans %}

    -

    - For development on the i2p router or the embedded applications, - get the monotone source repository installed - short instructions: -

    +

    {% trans -%} +For development on the i2p router or the embedded applications, +get the monotone source repository installed - short instructions: +{%- endtrans %}

      +
    • {% trans -%} +Install monotone. +Monotone is a version control system. +We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea). + {%- endtrans %}
    • +
    • {% trans -%} +Skim over the monotone tutorial, to make sure you understand the concepts. + {%- endtrans %}
    • - Install monotone. - Monotone is a version control system. - We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea). -
    • -
    • Skim over the monotone tutorial, to make sure you understand the concepts.
    • -
    • -

      +

      {% trans -%} If you want to remain anonymous, you need to do an additional step, to set up a connection to a monotone server over I2P: -

      -

      - Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p. -

      + {%- endtrans %}

      +

      {% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%} + Enable the i2ptunnel client tunnel on port 8998 pointing to mtn.i2p2.i2p. + {%- endtrans %}

    • -
    • - Pick a directory where you want to put all your I2P files, and create a monotone database: mtn -d i2p.mtn db init +
    • {% trans -%} + Pick a directory where you want to put all your I2P files, and create a monotone database:{% endtrans %} mtn -d i2p.mtn db init
    • -
    • Define the trust list by creating ~/.monotone/monotonerc (or _MTN/monotonerc in the i2p.i2p workspace) with the following contents: +
    • {% trans -%} +Define the trust list by creating ~/.monotone/monotonerc (or _MTN/monotonerc in the i2p.i2p workspace) with the following contents: +{%- endtrans %} {% include "include/monotonerc.html" %}
    • -
    • Copy and paste the developer's commit keys into a new file (e.g. keys.txt) in the same directory +
    • {% trans devkeys=site_url('get-involved/develop/developers-keys') -%} +Copy and paste the developer's commit keys into a new file (e.g. keys.txt) in the same directory that i2p.mtn is in. Import the keys into your database with
            mtn -d i2p.mtn read < keys.txt
      -
    • - Pull the I2P sources to your machine. This may take a long time, especially if you are doing this over I2P! + {%- endtrans %}
    • +
    • {% trans %}Pull the I2P sources to your machine. This may take a long time, especially if you are doing this over I2P!{% endtrans %}
        -
      • Anonymously: mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p -k""
      • +
      • {% trans %}Anonymously:{% endtrans %} mtn -d i2p.mtn pull 127.0.0.1:8998 i2p.i2p -k""
      • - Non-anonymously: mtn -d i2p.mtn pull mtn.i2p2.de i2p.i2p -k"" + {% trans %}Non-anonymously:{% endtrans %} mtn -d i2p.mtn pull mtn.i2p2.de i2p.i2p -k""

        -

        +

        {% trans -%} Alternatively, instead of 'mtn.i2p2.de', you can also download from mtn.i2p-projekt.de. -

        + {%- endtrans %}

    • - All the sources are now present on your machine, in the database file. To make them available in a directory, you need to check them out: mtn -d i2p.mtn co --branch=i2p.i2p -

      -

      - The above command creates a directory i2p.i2p, which contains all of the I2P sources. + {% trans %}All the sources are now present on your machine, in the database file. To make them available in a directory, you need to check them out:{% endtrans %} mtn -d i2p.mtn co --branch=i2p.i2p

      +

      {% trans %}The above command creates a directory i2p.i2p, which contains all of the I2P sources.{% endtrans %}

    -

    Remarks

    -

    - To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'. -

    -

    - The initial pull may take several hours using the tunnel. - If it fails after a partial pull, simply rerun it, it will start where it left off. - If you are in a hurry, use the non-anonymous access. -

    -

    - A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn. -

    -

    - A long explanation about using monotone is available on the monotone page. -

    +

    {% trans %}Remarks{% endtrans %}

    +

    {% trans %} +To download the website files instead of the I2P source files, use 'i2p.www' instead of 'i2p.i2p'. +{%- endtrans %}

    +

    {% trans -%} +The initial pull may take several hours using the tunnel. +If it fails after a partial pull, simply rerun it, it will start where it left off. +If you are in a hurry, use the non-anonymous access. +{%- endtrans %}

    +

    {% trans viewmtn='http://stats.i2p/cgi-bin/viewmtn/' -%} +A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn. +{%- endtrans %}

    +

    {% trans monotone=site_url('get-involved/guides/monotone') -%} +A long explanation about using monotone is available on the monotone page. +{%- endtrans %}

    -

    Building I2P

    +

    {% trans %}Building I2P{% endtrans %}

    -

    - To compile the code, you need the Sun Java Development Kit 6 or higher, or equivalent JDK - (Sun JDK 6 strongly recommended) and - Apache ant - version 1.7.0 or higher. - If you go are working on the main I2P code, you can go into the i2p.i2p directory and run 'ant' to see the build options. -

    +

    {% trans sunjdk6='http://java.sun.com/javase/downloads/index.jsp' -%} +To compile the code, you need the Sun Java Development Kit 6 or higher, or equivalent JDK +(Sun JDK 6 strongly recommended) and +Apache ant +version 1.7.0 or higher. +If you go are working on the main I2P code, you can go into the i2p.i2p directory and run 'ant' to see the build options. +{%- endtrans %}

    -

    - To build or work on console translations, you need - the xgettext, msgfmt, and msgmerge tools from the - GNU gettext package. -

    +

    {% trans -%} +To build or work on console translations, you need +the xgettext, msgfmt, and msgmerge tools from the +GNU gettext package. +{%- endtrans %}

    -

    - For development on new applications, - see the application development guide. -

    +

    {% trans apps=site_url('get-involved/develop/applications') -%} +For development on new applications, +see the application development guide. +{%- endtrans %}

    -

    Development ideas

    -

    - See zzz's TODO lists, - this website's TODO list or - Trac - for ideas. -

    +

    {% trans %}Development ideas{% endtrans %}

    +

    {% trans zzz=i2pconv('zzz.i2p'), todo=site_url('get-involved/todo'), trac=i2pconv('trac.i2p2.i2p') -%} +See zzz's TODO lists, +this website's TODO list or +Trac +for ideas. +{%- endtrans %}

    -

    Making the results available

    +

    {% trans %}Making the results available{% endtrans %}

    -

    - See the bottom of licenses.html for - commit privilege requirements. You need these to put code into i2p.i2p (not required for the website!). -

    +

    {% trans licenses=site_url('get-involved/develop/licenses') -%} +See the bottom of the licenses page for +commit privilege requirements. You need these to put code into i2p.i2p (not required for the website!). +{%- endtrans %}

    -

    - Short version of how to generate and use keys if you plan to commit: +

    {% trans %}Short version of how to generate and use keys if you plan to commit:{% endtrans %}

      -
    • mtn genkey yourname-transport@mail.i2p (use an empty passphrase) -
    • mtn genkey yourname@mail.i2p (enter a passphrase) -
    • mtn pubkey yourname-transport@mail.i2p (send this to a mtn repo operator to get push privileges) -
    • mtn pubkey yourname@mail.i2p (send this to a release manager to get commit privileges - not required for website) -
    • mtn ci -k yourname@mail.i2p (check in with this key) -
    • mtn sync -k yourname-transport@mail.i2p (push with this key) +
    • mtn genkey yourname-transport@mail.i2p ({% trans %}use an empty passphrase{% endtrans %}) +
    • mtn genkey yourname@mail.i2p ({% trans %}enter a passphrase{% endtrans %}) +
    • mtn pubkey yourname-transport@mail.i2p ({% trans email='mtn@welterde.de' %}send this to a mtn repo operator to get push privileges{% endtrans %}) +
    • mtn pubkey yourname@mail.i2p ({% trans email='zzz@'+i2pconv('mail.i2p') %}send this to a release manager to get commit privileges - not required for website{% endtrans %}) +
    • mtn ci -k yourname@mail.i2p ({% trans %}check in with this key{% endtrans %}) +
    • mtn sync -k yourname-transport@mail.i2p ({% trans %}push with this key{% endtrans %})
    - Long version: see the monotone page. +{% trans monotone=site_url('get-involved/guides/monotone') -%} +Long version: see the monotone page. +{%- endtrans %}

    -

    Get to know us!

    -

    - The developers hang around on IRC. They can be reached on the Freenode network, OFTC, and on the I2P internal networks. The usual place to look is #i2p-dev. Join the channel and say hi! - We also have additional guidelines for regular developers. -

    +

    {% trans %}Get to know us!{% endtrans %}

    +

    {% trans guidelines=site_url('get-involved/guides/dev-guidelines') -%} +The developers hang around on IRC. They can be reached on the Freenode network, OFTC, and on the I2P internal networks. The usual place to look is #i2p-dev. Join the channel and say hi! +We also have additional guidelines for regular developers. +{%- endtrans %}

    -

    Translations

    -

    - Website and router console translators: See the New Translators Page - for next steps. -

    +

    {% trans %}Translations{% endtrans %}

    +

    {% trans newtrans=site_url('get-involved/guides/new-translators') -%} +Website and router console translators: See the New Translator's Guide +for next steps. +{%- endtrans %}

    -

    Tools

    -

    +

    {% trans %}Tools{% endtrans %}

    +

    {% trans -%} I2P is open source software that is mostly developed using open sourced toolkits. The I2P project recently acquired a license for the YourKit Java Profiler. Open source projects are eligible to receive a free license provided that YourKit is referenced on the project web site. Please get in touch if you are interested in profiling the I2P codebase. -

    +{%- endtrans %}

    -

    +

    {% trans java='http://www.yourkit.com/java/profiler/index.jsp', dotnet='http://www.yourkit.com/.net/profiler/index.jsp' -%} YourKit is kindly supporting open source projects with its full-featured Java Profiler. YourKit, LLC is the creator of innovative and intelligent tools for profiling Java and .NET applications. Take a look at YourKit's leading software products: -YourKit Java Profiler and -YourKit .NET Profiler. -

    +YourKit Java Profiler and +YourKit .NET Profiler. +{%- endtrans %}

    {% endblock %} From 3429dfcd8cf028df8706354abc4b9a452bfae30a Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 26 Jan 2013 02:16:34 +0000 Subject: [PATCH 355/498] Fixed tag bug in monotone guide --- i2p2www/pages/site/get-involved/guides/monotone.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/get-involved/guides/monotone.html b/i2p2www/pages/site/get-involved/guides/monotone.html index 485c9f59..e7c783a3 100644 --- a/i2p2www/pages/site/get-involved/guides/monotone.html +++ b/i2p2www/pages/site/get-involved/guides/monotone.html @@ -272,7 +272,7 @@ Enter the directory where you initialized i2p.mtn. Depending on whether you want only I2P sources, or also sources for the I2P website and Syndie, you can perform the pull operation in different ways. - {%- trans %} + {%- endtrans %}

    From 5c2efa5a75378aed2e3262faa6b5eb6291af577f Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 27 Jan 2013 22:57:57 +0000 Subject: [PATCH 356/498] Added translation tags to get-involved/guides/new-translators --- .../get-involved/guides/new-translators.html | 271 ++++++++++-------- 1 file changed, 159 insertions(+), 112 deletions(-) diff --git a/i2p2www/pages/site/get-involved/guides/new-translators.html b/i2p2www/pages/site/get-involved/guides/new-translators.html index 6fa94c57..82754f24 100644 --- a/i2p2www/pages/site/get-involved/guides/new-translators.html +++ b/i2p2www/pages/site/get-involved/guides/new-translators.html @@ -1,81 +1,112 @@ {% extends "global/layout.html" %} -{% block title %}New Translator's Guide{% endblock %} +{% block title %}{% trans %}New Translator's Guide{% endtrans %}{% endblock %} {% block content %} -Here's a very quick guide to getting started. +{% trans %}Here's a very quick guide to getting started.{% endtrans %} -

    How to Translate the Website

    +

    {% trans %}How to Translate the Website{% endtrans %}

    + +

    {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%} +Translation of the website is done with .po files. The easiest way by far to +translate the website is to sign up for an account at +Transifex and request to join a translation team. +Alternatively it can be done "the old way" as outlined below. +{%- endtrans %}

    1. -Preparation +{% trans %}Preparation{% endtrans %}
        -
      1. - Come to #i2p-dev on irc and talk to people. - Claim the language - - To make sure other coworkers don't bump onto the files you are working on, - please update the translation status on this wiki page.
      2. -
      3. - Follow the new developer's guide, - Including the installation of monotone, - checking out i2p.www branch, and generate your own monotone keys. - It is not required that you sign a dev agreement.
      4. +
      5. {% trans url='http://ugha.i2p/i2pTranslation' -%} +Come to #i2p-dev on irc and talk to people. +Claim the language - +To make sure other coworkers don't bump onto the files you are working on, +please update the translation status on this wiki page. +{%- endtrans %}
      6. +
      7. {% trans newdevs=site_url('get-involved/guides/new-developers') -%} +Follow the new developer's guide, +Including the installation of monotone, +checking out i2p.www branch, and generate your own monotone keys. +It is not required that you sign a dev agreement. +{%- endtrans %}
      -
    2. -Create files: - If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language. - Then 'mtn add' the file. - Also add a _layout_xx.html for your language xx. - Add a flag image file for the menu (copy from the router).
    3. +
    4. {% trans -%} +Create files: +If the file for your language does not exist yet: +{%- endtrans %} +
        +
      1. {% trans -%} +Run "./extract-messages.sh" to generate a messages.pot in the base directory. +Edit the header of this file, then run "./init-new-po.sh locale" to generate the file +i2p2www/translations/locale/LC_MESSAGES/messages.po. "mtn add" this file. +{%- endtrans %}
      2. +
      3. {% trans -%} +Edit i2p2www/pages/global/lang.html and add a line for your language (copy an existing line). +{%- endtrans %}
      4. +
      5. {% trans -%} +Add a flag image file to i2p2www/static/images/flags/ for the menu (copy from the router). +{%- endtrans %}
      6. +
      +
    5. -
    6. -Edit files: - Edit _layout_xx.html, _menu.html, and other files with any text editor. - Be sure not to use an editor in HTML mode that reformats everything.
    7. +
    8. {% trans -%} +Edit files: +Edit i2p2www/translations/locale/LC_MESSAGES/messages.po. +To work with .po files efficiently, you may wish to use POEdit +{%- endtrans %}
    9. -
    10. -Check in: - mtn pull, mtn update. Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..." - This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p". - This synchronizes your local repo with the repo on the target machine.
    11. - -
    12. -Repeat. Check in often. Don't wait until it is perfect.
    13. +
    14. {% trans -%} +Check in: +"mtn pull", "mtn update". Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..." +This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p". +This synchronizes your local repo with the repo on the target machine. +{%- endtrans %}
    15. +
    16. {% trans -%} +Repeat. Check in often. Don't wait until it is perfect. +{%- endtrans %}
    -

    How to Translate the Router Console

    +

    {% trans %}How to Translate the Router Console{% endtrans %}

    -

    The easiest way by far to translate the router console is to sign up for an account at -Transifex and request to join a translation team. -Alternatively it can be done "the old way" as outlined below.

    +

    {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%} +The easiest way by far to translate the router console is to sign up for an account at +Transifex and request to join a translation team. +Alternatively it can be done "the old way" as outlined below. +{%- endtrans %}

    1. -Preparation +{% trans %}Preparation{% endtrans %}
        -
      1. - Come to #i2p-dev on irc and talk to people. - Claim the language - - To make sure other coworkers don't bump onto the files you are working on, - please update the translation status on this wiki page.
      2. -
      3. - Follow the new developer's guide, - Including the installation of monotone and the gettext tools, - checking out i2p.i2p branch, and generate your own monotone keys.
      4. -
      5. - Generate your own gpg key and sign the dev agreement.
      6. -
    2. +
    3. {% trans url='http://ugha.i2p/i2pTranslation' -%} +Come to #i2p-dev on irc and talk to people. +Claim the language - +To make sure other coworkers don't bump onto the files you are working on, +please update the translation status on this wiki page. +{%- endtrans %}
    4. +
    5. {% trans newdevs=site_url('get-involved/guides/new-developers') -%} +Follow the new developer's guide, +including the installation of monotone and the gettext tools, +checking out i2p.i2p branch, and generate your own monotone keys. +{%- endtrans %}
    6. +
    7. {% trans -%} +Generate your own gpg key and sign the dev agreement. +{%- endtrans %}
    8. +
    + -
  • +
  • {% trans -%} Before starting a console translation, better help translate some i2p webpages first. -At least an i2p homepage in your language would be great. This will also help you learn monotone.
  • +At least an i2p homepage in your language would be great. +{%- endtrans %} -
  • -What to translate: - There are about 15 files in the i2p.i2p branch that needs translation: +
  • {% trans -%} +What to translate: +There are about 15 files in the i2p.i2p branch that needs translation: +{%- endtrans %}
    • @@ -98,81 +129,97 @@ What to translate: apps/susidns/locale/messages_xx.po
    - Where xx is your language code like fr/de/ch/zh/... +{% trans -%} +Where xx is your language code like fr/de/ch/zh/... +There may be or may not be files with your lang code. If not, you can create your own. by copying and renaming other language files you know with your own lang code. +{%- endtrans %}
  • - There may be or may not be files with your lang code. If not, you can create your own. by copying and renaming other language files you know with your own lang code. - +
  • {% trans -%} +Create files: +If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language. +Then "mtn add" the file. +After creating a .po file, edit the headers. Then run "ant distclean poupdate". +{%- endtrans %}
  • -
  • -Create files: - If the file for your language does not exist yet, copy another language file to a new file foo_xx.bar for your language. - Then 'mtn add' the file. - After creating a .po file, edit the headers. Then run 'ant distclean poupdate'. -
  • -
  • -Start to work: - Edit the HTML files with any text editor. - Be sure not to use an editor in HTML mode that reformats everything. - To work with .po files efficiently, you may wish to use POEdit -
  • -
  • -Check in: - mtn pull, mtn update. Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..." - This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p". - This synchronizes your local repo with the repo on the target machine. -
  • -
  • +
  • {% trans -%} +Start to work: +Edit the HTML files with any text editor. +Be sure not to use an editor in HTML mode that reformats everything. +To work with .po files efficiently, you may wish to use POEdit +{%- endtrans %}
  • + +
  • {% trans -%} +Check in: +"mtn pull", "mtn update". Then check in by "mtn ci -k yourname@mail.i2p file1 file2 ..." +This collects the diff info of your changed file into your local repo. Then "mtn sync mtn.i2p2.de -k yourname-transport@mail.i2p i2p.i2p". +This synchronizes your local repo with the repo on the target machine. +{%- endtrans %}
  • + +
  • {% trans -%} Repeat. Check in often. Don't wait until it is perfect. - -
  • +{%- endtrans %} -

    As you can see, it's not that difficult. -If you have questions about the meaning of the terms in the console, ask in #i2p-dev on IRC. -

    +

    {% trans -%} +As you can see, it's not that difficult. +If you have questions about the meaning of the terms in the console, ask in #i2p-dev on IRC. +{%- endtrans %}

    -

    FAQ

    +

    {% trans %}FAQ{% endtrans %}

    -Q: Why do I have to install monotone, Java, jsp, learn about .po files and html, etc.? Why can't I just do a translation and email it to you? +

    {% trans -%} +Q: Why do I have to install monotone, Java, jsp, learn about .po files and html, etc.? Why can't I just do a translation and email it to you? +{%- endtrans %}

    -Answer: Several reasons: +

    {% trans %}A: Several reasons:{% endtrans %}

      -
    • You might be interested in translating via Transifex. Request to join a translation team here
    • -
    • - We don't have anybody who has time to accept manual contributions and submit them to our source control system on your behalf. Even if we did, it doesn't scale.
    • +
    • {% trans transifex='https://www.transifex.com/projects/p/I2P/' -%} +You might be interested in translating via Transifex. Request to join a translation team here. +{%- endtrans %}
    • -
    • - Maybe you are thinking translation is a one-step process. It isn't. You can't do it all at once. You will make mistakes. You need to test it and tweak it to make it look right before you submit it. Developers will update or add to the English text, thus requiring a translation update. -
    • -
    • - Having translators use a source control system directly provides authentication and accountablility - we know who is doing what, and we can track changes, and revert them if necessary. +
    • {% trans -%} +We don't have anybody who has time to accept manual contributions and submit them to our source control system on your behalf. Even if we did, it doesn't scale. +{%- endtrans %}
    • - -
    • - .po files are not difficult. If you don't want to work directly with them, we recommend 'poedit'. -
    • -
    • - HTML files are not difficult. Just ignore the html stuff and translate the text. -
    • -
    • - Installing and using monotone is not that difficult. Several of the translators and other contributors to I2P are non-programmers, and they use monotone regularly. Monotone is simply a source control system, it is not about "coding". -
    • -
    • - Our items to translate are not "documents". They are html files and po files, with a specific format and character encoding (UTF-8) that must be maintained, and not corrupted by email programs or other methods of transfer. -
    • -
    • - We looked at 'pootle' as a front-end for translators. It didn't work well, needed an administrator, and a pootle-based process would suffer from a number of the above flaws.
    • +
    • {% trans -%} +Maybe you are thinking translation is a one-step process. It isn't. You can't do it all at once. You will make mistakes. You need to test it and tweak it to make it look right before you submit it. Developers will update or add to the English text, thus requiring a translation update. +{%- endtrans %}
    • + +
    • {% trans -%} +Having translators use a source control system directly provides authentication and accountablility - we know who is doing what, and we can track changes, and revert them if necessary. +{%- endtrans %}
    • + +
    • {% trans -%} +.po files are not difficult. If you don't want to work directly with them, we recommend 'poedit'. +{%- endtrans %}
    • + +
    • {% trans -%} +HTML files are not difficult. Just ignore the html stuff and translate the text. +{%- endtrans %}
    • + +
    • {% trans -%} +Installing and using monotone is not that difficult. Several of the translators and other contributors to I2P are non-programmers, and they use monotone regularly. Monotone is simply a source control system, it is not about "coding". +{%- endtrans %}
    • + +
    • {% trans -%} +Our items to translate are not "documents". They are html files and po files, with a specific format and character encoding (UTF-8) that must be maintained, and not corrupted by email programs or other methods of transfer. +{%- endtrans %}
    • + +
    • {% trans -%} +We looked at 'pootle' as a front-end for translators. It didn't work well, needed an administrator, and a pootle-based process would suffer from a number of the above flaws. +{%- endtrans %}
    +

    {% trans -%} In summary: - Yes, we know it is somewhat of a hurdle to get started. It's really the only possible way we can do it. Give it a try, it really isn't that hard. +{%- endtrans %} -

    More Information

    -The #i2p-dev channel on IRC, or the translation forum on zzz.i2p. - - +

    {% trans %}More Information{% endtrans %}

    +

    {% trans zzz=i2pconv('zzz.i2p') -%} +The #i2p-dev channel on IRC, or the translation forum on {{ zzz }}. +{%- endtrans %}

    {% endblock %} From f9d7a43bc7867d01179592a5475b97197b19bee5 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 29 Jan 2013 01:30:18 +0000 Subject: [PATCH 357/498] Tweaked "How to connect to IRC" entry of faq --- i2p2www/pages/site/faq.html | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/i2p2www/pages/site/faq.html b/i2p2www/pages/site/faq.html index 0cc3e2f0..f0e8ac46 100644 --- a/i2p2www/pages/site/faq.html +++ b/i2p2www/pages/site/faq.html @@ -423,10 +423,12 @@ See the

    {% trans %}How do I connect to IRC within I2P?{% endtrans %} ({{ _('link') }})

    {% trans %} -On the -I2PTunnel configuration page, -start the ircProxy. -Then tell your IRC client to connect to localhost port 6668. +A tunnel to the main IRC server within I2P, Irc2P, is created when I2P is installed (see +the I2PTunnel configuration page), +and is automatically started when the I2P router starts. To connect to it, tell your IRC +client to connect to localhost 6668. XChat-like client users can create a +new network with the server localhost/6668 (remember to tick "Bypass +proxy server" if you have a proxy server configured). {%- endtrans %}

    {% trans %}How can I access the web console from my other machines or password protect it?{% endtrans %} From 611a8f05dc378218128ef9197484184bed411fe5 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 30 Jan 2013 03:47:49 +0000 Subject: [PATCH 358/498] Added translation tags to docs/*.html --- i2p2www/pages/site/docs/index.html | 237 +++++++++--------- i2p2www/pages/site/docs/naming.html | 359 ++++++++++++++++++--------- i2p2www/pages/site/docs/plugins.html | 229 +++++++++++------ i2p2www/pages/site/docs/ports.html | 15 +- 4 files changed, 534 insertions(+), 306 deletions(-) diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index d6d38f20..5f8a2341 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -1,52 +1,56 @@ {% extends "global/layout.html" %} -{% block title %}Index to Technical Documentation{% endblock %} -{% block lastupdated %}May 2012{% endblock %} +{% block title %}{% trans %}Index to Technical Documentation{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}May 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9{% endblock %} {% block content %} -

    How does I2P work?

    +

    {% trans %}How does I2P work{% endtrans %}

    -

    +

    {% trans -%} Following is an index to the technical documentation for I2P. -

    +{%- endtrans %}

    + +

    {% trans -%} This index is ordered from the highest to lowest layers. The higher layers are for "clients" or applications; the lower layers are inside the router itself. The interface between applications and the router is the I2CP (I2P Control Protocol) API. -

    +{%- endtrans %}

    + +

    {% trans trac=i2pconv('trac.i2p2.i2p') -%} The I2P Project is committed to maintaining accurate, current documentation. If you find any inaccuracies in the documents linked below, please -enter a ticket identifying the problem. -

    +enter a ticket identifying the problem. +{%- endtrans %}

    -

    Index to Technical Documentation

    +

    {% trans %}Index to Technical Documentation{% endtrans %}

    -

    Overview

    +

    {% trans %}Overview{% endtrans %}

    -

    Application-Layer Topics

    +

    {% trans %}Application-Layer Topics{% endtrans %}

    -

    Application Layer API and Protocols

    -High-level, easy-to-use APIs for applications written in any language to send and receive data. +

    {% trans %}Application Layer API and Protocols{% endtrans %}

    +{% trans %}High-level, easy-to-use APIs for applications written in any language to send and receive data.{% endtrans %} -

    End-to-End Transport API and Protocols

    -The end-to-end protocols used by clients for reliable and unreliable communication. +

    {% trans %}End-to-End Transport API and Protocols{% endtrans %}

    +{% trans %}The end-to-end protocols used by clients for reliable and unreliable communication.{% endtrans %} -

    Client-to-Router Interface API and Protocol

    +

    {% trans %}Client-to-Router Interface API and Protocol{% endtrans %}

    +{% trans -%} The lowest-level API used for clients (applications) to send and receive traffic to a router. Traditionally used only by Java applications and higher-level APIs. +{%- endtrans %} -

    End-to-End Encryption

    -How client messages are end-to-end encrypted by the router. +

    {% trans %}End-to-End Encryption{% endtrans %}

    +{% trans %}How client messages are end-to-end encrypted by the router.{% endtrans %} -

    Network Database

    -Distributed storage and retrieval of information about routers and clients. +

    {% trans %}Network Database{% endtrans %}

    +{% trans %}Distributed storage and retrieval of information about routers and clients.{% endtrans %} -

    Router Message Protocol

    -I2P is a message-oriented router. The messages sent between routers are defined by the I2NP protocol. +

    {% trans %}Router Message Protocol{% endtrans %}

    +{% trans %}I2P is a message-oriented router. The messages sent between routers are defined by the I2NP protocol.{% endtrans %} -

    Tunnels

    -Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels. +

    {% trans %}Tunnels{% endtrans %}

    +{% trans %}Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.{% endtrans %} -

    Transport Layer

    -The protocols for direct (point-to-point) router to router communication. +

    {% trans %}Transport Layer{% endtrans %}

    +{% trans %}The protocols for direct (point-to-point) router to router communication.{% endtrans %} -

    Other Router Topics

    +

    {% trans %}Other Router Topics{% endtrans %}

    -

    Developer's Guides and Resources

    +

    {% trans %}Developer's Guides and Resources{% endtrans %}

    diff --git a/i2p2www/pages/site/docs/naming.html b/i2p2www/pages/site/docs/naming.html index 371c8784..c8341834 100644 --- a/i2p2www/pages/site/docs/naming.html +++ b/i2p2www/pages/site/docs/naming.html @@ -1,19 +1,19 @@ {% extends "global/layout.html" %} -{% block title %}Naming and Addressbook{% endblock %} -{% block lastupdated %}March 2012{% endblock %} +{% block title %}{% trans %}Naming and Addressbook{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.8.13{% endblock %} {% block content %} -

    Naming in I2P

    -

    Overview

    +

    {% trans %}Naming in I2P{% endtrans %}

    +

    {% trans %}Overview{% endtrans %}

    -

    +

    {% trans -%} I2P ships with a generic naming library and a base implementation designed to work off a local name to destination mapping, as well as an add-on application called the addressbook. I2P also supports Base32 hostnames similar to Tor's .onion addresses. -

    +{%- endtrans %}

    -

    +

    {% trans -%} The addressbook is a web-of-trust driven secure, distributed, and human readable naming system, sacrificing only the call for all human readable names to be globally unique by mandating only @@ -25,116 +25,150 @@ by adding in the entries provided through a third party, or (if some people orga a series of published addressbooks using a first come first serve registration system) people can choose to treat these addressbooks as name servers, emulating traditional DNS. -

    +{%- endtrans %}

    -

    +

    {% trans namingdiscussion=site_url('docs/discussions/naming') -%} NOTE: For the reasoning behind the I2P naming system, common arguments against it -and possible alternatives see the naming discussion +and possible alternatives see the naming discussion page. -

    +{%- endtrans %}

    -

    Naming System Components

    -

    +

    {% trans %}Naming System Components{% endtrans %}

    + +

    {% trans -%} There is no central naming authority in I2P. All hostnames are local. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} The naming system is quite simple and most of it is implemented in applications external to the router, but bundled with the I2P distribution. The components are: -

    +{%- endtrans %}

    +
      -
    1. The client application which does local lookups in hosts.txt +
    2. {% trans -%} +The client application which does local lookups in hosts.txt and also takes care of the Base32 hostnames. -
    3. The HTTP proxy which asks the router for lookups and points -the user to remote jump services to assist with failed lookups -
    4. HTTP host-add forms which allow users to add hosts to their local hosts.txt -
    5. HTTP jump services which provide their own lookups and redirection -
    6. The addressbook application which merges external -host lists, retrieved via HTTP, with the local list -
    7. The SusiDNS application which is a simple web front-end +{%- endtrans %}
    8. +
    9. {% trans -%} +The HTTP proxy which asks the router for lookups and points +the user to remote jump services to assist with failed lookups. +{%- endtrans %}
    10. +
    11. {% trans -%} +HTTP host-add forms which allow users to add hosts to their local hosts.txt +{%- endtrans %}
    12. +
    13. {% trans -%} +HTTP jump services which provide their own lookups and redirection. +{%- endtrans %}
    14. +
    15. {% trans -%} +The addressbook application which merges external +host lists, retrieved via HTTP, with the local list. +{%- endtrans %}
    16. +
    17. {% trans -%} +The SusiDNS application which is a simple web front-end for addressbook configuration and viewing of the local host lists. +{%- endtrans %}
    -

    Naming Files and Lookups

    -

    + +

    {% trans %}Naming Files and Lookups{% endtrans %}

    + +

    {% trans namingdiscussion=site_url('docs/discussions/naming'), todo=site_url('get-involved/todo') -%} All destinations in I2P are 516-byte (or longer) keys. (To be more precise, it is a 256-byte public key plus a 128-byte signing key plus a null certificate, which in Base64 representation is 516 bytes. -Certificates are not used now, +Certificates are not used now, if they are, the keys will be longer. -One possible use of certificates is for proof of work.) -

    +One possible use of certificates is for proof of work.) +{%- endtrans %}

    + +

    {% trans -%} If an application (i2ptunnel or the HTTP proxy) wishes to access a destination by name, the router does a very simple local lookup to resolve that name. The client application (technically, the client side of I2CP in the I2P API) does a linear search through three local files, in order, to look up host names and convert them to a 516-byte destination key: +{%- endtrans %}

    +
    1. privatehosts.txt
    2. userhosts.txt
    3. hosts.txt
    -

    The lookup is case-insensitive. + +

    {% trans -%} +The lookup is case-insensitive. The first match is used, and conflicts are not detected. There is no enforcement of naming rules in lookups. -

    +{%- endtrans %}

    + +

    {% trans namingdiscussion=site_url('docs/discussions/naming') -%} Lookups are cached for a few minutes. There is an experimental facility for real-time lookups (a la DNS) over the network within the router, although it is not enabled by default -(see "EepGet" under Alternatives on the discussion page). -

    +(see "EepGet" under Alternatives on the discussion page). +{%- endtrans %}

    -

    HTTP Proxy

    -

    The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'. +

    {% trans %}HTTP Proxy{% endtrans %}

    + +

    {% trans -%} +The HTTP proxy does a lookup via the router for all hostnames ending in '.i2p'. Otherwise, it forwards the request to a configured HTTP outproxy. Thus, in practice, all HTTP (eepsite) hostnames must end in the pseudo-Top Level Domain '.i2p'. -

    +{%- endtrans %}

    -

    +

    {% trans -%} If the router fails to resolve the hostname, the HTTP proxy returns an error page to the user with links to several "jump" services. See below for details. -

    +{%- endtrans %}

    -

    Addressbook

    -

    Incoming Subscriptions and Merging

    -

    +

    {% trans %}Addressbook{% endtrans %}

    +

    {% trans %}Incoming Subscriptions and Merging{% endtrans %}

    + +

    {% trans -%} The addressbook application periodically retrieves other users' hosts.txt files and merges them with the local hosts.txt, after several checks. Naming conflicts are resolved on a first-come first-served basis. -

    +{%- endtrans %}

    + +

    {% trans -%} Subscribing to another user's hosts.txt file involves giving them a certain amount of trust. You do not want them, for example, 'hijacking' a new site by quickly entering in their own key for a new site before passing the new host/key entry to you. -

    +{%- endtrans %}

    + +

    {% trans -%} For this reason, the only subscription configured by default is http://www.i2p2.i2p/hosts.txt, which contains a copy of the hosts.txt included in the I2P release. Users must configure additional subscriptions in their local addressbook application (via subscriptions.txt or SusiDNS). -

    +{%- endtrans %}

    + +

    {% trans -%} Some other public addressbook subscription links: -

    +{%- endtrans %}

    -

    +

    {% trans -%} The operators of these services may have various policies for listing hosts. Presence on this list does not imply endorsement. -

    +{%- endtrans %}

    -

    Naming Rules

    -

    +

    {% trans %}Naming Rules{% endtrans %}

    +

    {% trans -%} While there are hopefully not any technical limitations within I2P on host names, the addressbook enforces several restrictions on host names imported from subscriptions. @@ -143,30 +177,80 @@ and for security. The rules are essentially the same as those in RFC2396 Section 3.2.2. Any hostnames violating these rules may not be propagated to other routers. -

    -Naming rules:

    +{%- endtrans %}

    + +

    {% trans -%} +Naming rules: +{%- endtrans %}

      -
    • Names are converted to lower case on import. -
    • Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt +
    • {% trans -%} +Names are converted to lower case on import. +{%- endtrans %}
    • + +
    • {% trans -%} +Names are checked for conflict with existing names in the existing userhosts.txt and hosts.txt (but not privatehosts.txt) after conversion to lower case. -
    • Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case. -
    • Must not start with '.' or '-'. -
    • Must end with '.i2p'. -
    • 67 characters maximum, including the '.i2p'. -
    • Must not contain '..'. -
    • Must not contain '.-' or '-.' (as of 0.6.1.33). -
    • Must not contain '--' except in 'xn--' for IDN. -
    • Base32 hostnames (*.b32.i2p) are not allowed. -
    • Certain hostnames reserved for project use are not allowed - (proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, and others) -
    • Keys are checked for base64 validity. -
    • Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt). -
    • Minimum key length 516 bytes. -
    • Maximum key length 616 bytes (to account for certs up to 100 bytes). +{%- endtrans %}
    • + +
    • {% trans -%} +Must contain only [a-z] [0-9] '.' and '-' after conversion to lower case. +{%- endtrans %}
    • + +
    • {% trans -%} +Must not start with '.' or '-'. +{%- endtrans %}
    • + +
    • {% trans -%} +Must end with '.i2p'. +{%- endtrans %}
    • + +
    • {% trans -%} +67 characters maximum, including the '.i2p'. +{%- endtrans %}
    • + +
    • {% trans -%} +Must not contain '..'. +{%- endtrans %}
    • + +
    • {% trans -%} +Must not contain '.-' or '-.' (as of 0.6.1.33). +{%- endtrans %}
    • + +
    • {% trans -%} +Must not contain '--' except in 'xn--' for IDN. +{%- endtrans %}
    • + +
    • {% trans -%} +Base32 hostnames (*.b32.i2p) are not allowed. +{%- endtrans %}
    • + +
    • {% trans -%} +Certain hostnames reserved for project use are not allowed +(proxy.i2p, router.i2p, console.i2p, *.proxy.i2p, *.router.i2p, *.console.i2p, and others) +{%- endtrans %}
    • + +
    • {% trans -%} +Keys are checked for base64 validity. +{%- endtrans %}
    • + +
    • {% trans -%} +Keys are checked for conflict with existing keys in hosts.txt (but not privatehosts.txt). +{%- endtrans %}
    • + +
    • {% trans -%} +Minimum key length 516 bytes. +{%- endtrans %}
    • + +
    • {% trans -%} +Maximum key length 616 bytes (to account for certs up to 100 bytes). +{%- endtrans %}
    -

    + +

    {% trans -%} Any name received via subscription that passes all the checks is added to the local hosts.txt. -

    +{%- endtrans %}

    + +

    {% trans -%} Note that the '.' symbols in a host name are of no significance, and do not denote any actual naming or trust hierarchy. If the name 'host.i2p' already exists, there is nothing @@ -175,70 +259,110 @@ and this name can be imported by others' addressbook. Methods to deny subdomains to non-domain 'owners' (certificates?), and the desirability and feasibility of these methods, are topics for future discussion. -

    +{%- endtrans %}

    + +

    {% trans -%} International Domain Names (IDN) also work in i2p (using punycode 'xn--' form). To see IDN .i2p domain names rendered correctly in Firefox's location bar, add 'network.IDN.whitelist.i2p (boolean) = true' in about:config. -

    +{%- endtrans %}

    + +

    {% trans -%} As the addressbook application does not use privatehosts.txt at all, in practice this file is the only place where it is appropriate to place private aliases or "pet names" for sites already in hosts.txt. -

    +{%- endtrans %}

    -

    Outgoing Subscriptions

    -

    +

    {% trans %}Outgoing Subscriptions{% endtrans %}

    +

    {% trans -%} Addressbook will publish the merged hosts.txt to a location (traditionally hosts.txt in the local eepsite's home directory) to be accessed by others for their subscriptions. This step is optional and is disabled by default. -

    +{%- endtrans %}

    Hosting and HTTP Transport Issues

    -

    +

    {% trans -%} The addressbook application, together with eepget, saves the Etag and/or Last-Modified information returned by the web server of the subscription. This greatly reduces the bandwidth required, as the web server will return a '304 Not Modified' on the next fetch if nothing has changed. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} However the entire hosts.txt is downloaded if it has changed. See below for discussion on this issue. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} Hosts serving a static hosts.txt or an equivalent CGI application are strongly encouraged to deliver a Content-Length header, and either an Etag or Last-Modified header. Also ensure that the server delivers a '304 Not Modified' when appropriate. This will dramatically reduce the network bandwidth, and reduce chances of corruption. -

    +{%- endtrans %}

    -

    Host Add Services

    -

    +

    {% trans %}Host Add Services{% endtrans %}

    +

    {% trans -%} A host add service is a simple CGI application that takes a hostname and a Base64 key as parameters and adds that to its local hosts.txt. If other routers subscribe to that hosts.txt, the new hostname/key will be propagated through the network. -

    +{%- endtrans %}

    + +

    {% trans -%} It is recommended that host add services impose, at a minimum, the restrictions imposed by the addressbook application listed above. Host add services may impose additional restrictions on hostnames and keys, for example: -

    +{%- endtrans %}

      -
    • A limit on number of 'subdomains'. -
    • Authorization for 'subdomains' through various methods. -
    • Hashcash or signed certificates. -
    • Editorial review of host names and/or content. -
    • Categorization of hosts by content. -
    • Reservation or rejection of certain host names. -
    • Restrictions on the number of names registered in a given time period. -
    • Delays between registration and publication. -
    • Requirement that the host be up for verification. -
    • Expiration and/or revocation. -
    • IDN spoof rejection. +
    • {% trans -%} +A limit on number of 'subdomains'. +{%- endtrans %}
    • + +
    • {% trans -%} +Authorization for 'subdomains' through various methods. +{%- endtrans %}
    • + +
    • {% trans -%} +Hashcash or signed certificates. +{%- endtrans %}
    • + +
    • {% trans -%} +Editorial review of host names and/or content. +{%- endtrans %}
    • + +
    • {% trans -%} +Categorization of hosts by content. +{%- endtrans %}
    • + +
    • {% trans -%} +Reservation or rejection of certain host names. +{%- endtrans %}
    • + +
    • {% trans -%} +Restrictions on the number of names registered in a given time period. +{%- endtrans %}
    • + +
    • {% trans -%} +Delays between registration and publication. +{%- endtrans %}
    • + +
    • {% trans -%} +Requirement that the host be up for verification. +{%- endtrans %}
    • + +
    • {% trans -%} +Expiration and/or revocation. +{%- endtrans %}
    • + +
    • {% trans -%} +IDN spoof rejection. +{%- endtrans %}
    -

    Jump Services

    -

    +

    {% trans %}Jump Services{% endtrans %}

    +

    {% trans -%} A jump service is a simple CGI application that takes a hostname as a parameter and returns a 301 redirect to the proper URL with a ?i2paddresshelper=key string appended. @@ -246,34 +370,41 @@ The HTTP proxy will interpret the appended string and use that key as the actual destination. In addition, the proxy will cache that key so the address helper is not necessary until restart. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} Note that, like with subscriptions, using a jump service implies a certain amount of trust, as a jump service could maliciously redirect a user to an incorrect destination. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} To provide the best service, a jump service should be subscribed to several hosts.txt providers so that its local host list is current. -

    +{%- endtrans %}

    SusiDNS

    -

    +

    {% trans -%} SusiDNS is simply a web interface front-end to configuring addressbook subscriptions and accessing the four addressbook files. All the real work is done by the 'addressbook' application. -

    +{%- endtrans %}

    + +

    {% trans -%} Currently, there is little enforcement of addressbook naming rules within SusiDNS, so a user may enter hostnames locally that would be rejected by the addressbook subscription rules. -

    +{%- endtrans %}

    -

    Base32 Names

    -

    I2P supports Base32 hostnames similar to Tor's .onion addresses. +

    {% trans %}Base32 Names{% endtrans %}

    +

    {% trans -%} +I2P supports Base32 hostnames similar to Tor's .onion addresses. Base32 addresses are much shorter and easier to handle than the full 516-character Base64 Destinations or addresshelpers. Example: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p -

    +{%- endtrans %}

    + +

    {% trans -%} In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash. I2P uses 52 characters (256 bits) to represent the full SHA-256 hash. The form is {52 chars}.b32.i2p. @@ -283,10 +414,12 @@ Base32 lookups will only be successful when the Destination is up and publishing a LeaseSet. Because resolution may require a network database lookup, it may take significantly longer than a local address book lookup. -

    +{%- endtrans %}

    + +

    {% trans -%} Base32 addresses can be used in most places where hostnames or full destinations are used, however there are some exceptions where they may fail if the name does not immediately resolve. I2PTunnel will fail, for example, if the name does not resolve to a destination. -

    +{%- endtrans %}

    {% endblock %} diff --git a/i2p2www/pages/site/docs/plugins.html b/i2p2www/pages/site/docs/plugins.html index 9fbc4d2f..0f913c1f 100644 --- a/i2p2www/pages/site/docs/plugins.html +++ b/i2p2www/pages/site/docs/plugins.html @@ -1,108 +1,193 @@ {% extends "global/layout.html" %} -{% block title %}Plugins{% endblock %} -{% block lastupdated %}June 2012{% endblock %} +{% block title %}{% trans %}Plugins{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}June 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9{% endblock %} {% block content %} -

    I2P Plugins

    +

    {% trans %}I2P Plugins{% endtrans %}

    -

    General Information

    -

    +

    {% trans %}General Information{% endtrans %}

    +

    {% trans -%} I2P includes a plugin architecture to support easy development and installation of additional software. -

    +{%- endtrans %}

    -

    +

    {% trans -%} There are now plugins available that support distributed email, blogs, IRC clients, distributed file storage, wikis, and more. -

    +{%- endtrans %}

    -

    +

    {% trans -%} Benefits to i2p users and app developers: -

    +{%- endtrans %}

      -
    • Easy distribution of applications
    • -
    • Allows innovation and use of additional libraries without worrying about -increasing the size of i2pupdate.sud
    • -
    • Support large or special-purpose applications that would never be bundled -with the I2P installation
    • -
    • Cryptographically signed and verified applications
    • -
    • Automatic updates of applications, just like for the router
    • -
    • Separate initial install and update packages, if desired, for smaller update downloads
    • -
    • One-click installation of applications. No more asking users to modify -wrapper.config or clients.config
    • -
    • Isolate applications from the base $I2P installation
    • -
    • Automatic compatibility checking for I2P version, Java version, Jetty -version, and previous installed application version
    • -
    • Automatic link addition in console
    • -
    • Automatic startup of application, including modifying classpath, without requiring a restart
    • -
    • Automatic integration and startup of webapps into console Jetty instance
    • -
    • Facilitate creation of 'app stores' like the one at plugins.i2p
    • -
    • One-click uninstall
    • -
    • Language and theme packs for the console
    • -
    • Bring detailed application information to the router console
    • -
    • Non-java applications also supported
    • +
    • {% trans -%} +Easy distribution of applications +{%- endtrans %}
    • + +
    • {% trans -%} +Allows innovation and use of additional libraries without worrying about +increasing the size of i2pupdate.sud +{%- endtrans %}
    • + +
    • {% trans -%} +Support large or special-purpose applications that would never be bundled +with the I2P installation +{%- endtrans %}
    • + +
    • {% trans -%} +Cryptographically signed and verified applications +{%- endtrans %}
    • + +
    • {% trans -%} +Automatic updates of applications, just like for the router +{%- endtrans %}
    • + +
    • {% trans -%} +Separate initial install and update packages, if desired, for smaller update downloads +{%- endtrans %}
    • + +
    • {% trans -%} +One-click installation of applications. No more asking users to modify +wrapper.config or clients.config +{%- endtrans %}
    • + +
    • {% trans -%} +Isolate applications from the base $I2P installation +{%- endtrans %}
    • + +
    • {% trans -%} +Automatic compatibility checking for I2P version, Java version, Jetty +version, and previous installed application version +{%- endtrans %}
    • + +
    • {% trans -%} +Automatic link addition in console +{%- endtrans %}
    • + +
    • {% trans -%} +Automatic startup of application, including modifying classpath, without requiring a restart +{%- endtrans %}
    • + +
    • {% trans -%} +Automatic integration and startup of webapps into console Jetty instance +{%- endtrans %}
    • + +
    • {% trans pluginsite=i2pconv('plugins.i2p') -%} +Facilitate creation of 'app stores' like the one at +{{ pluginsite }} +{%- endtrans %}
    • + +
    • {% trans -%} +One-click uninstall +{%- endtrans %}
    • + +
    • {% trans -%} +Language and theme packs for the console +{%- endtrans %}
    • + +
    • {% trans -%} +Bring detailed application information to the router console +{%- endtrans %}
    • + +
    • {% trans -%} +Non-java applications also supported +{%- endtrans %}
    -

    Required I2P version

    -

    0.7.12 or newer.

    +

    {% trans %}Required I2P version{% endtrans %}

    +

    {% trans %}0.7.12 or newer.{% endtrans %}

    -

    Installation

    -

    To install and start a plugin, copy the .xpi2p install link to -the form at the bottom of configclients.jsp in - your router console and click the "install plugin" button. After a +

    {% trans %}Installation{% endtrans %}

    +

    {% trans -%} +To install and start a plugin, copy the .xpi2p install link to +the form at the bottom of +configclients.jsp in +your router console and click the "install plugin" button. After a plugin is installed and started, a link to the plugin will usually appear at -the top of your summary bar.

    +the top of your summary bar. +{%- endtrans %}

    -

    To update a plugin to the latest version, just click the update button on +

    {% trans -%} +To update a plugin to the latest version, just click the update button on configclients.jsp. There is also a button to check if the plugin has a more recent version, as well as a button to check for updates for all plugins. Plugins will be checked for updates automatically when updating to a new I2P release (not including dev -builds).

    +builds). +{%- endtrans %}

    -

    Development

    -

    See the latest plugin specification and the plugin forum on zzz.i2p.

    See -also the sources for plugins developed by various people. Some plugins, such -as snowman, were developed -specifically as examples.

    +

    {% trans %}Development{% endtrans %}

    +

    {% trans pluginspec=site_url('docs/spec/plugin'), zzz=i2pconv('zzz.i2p') -%} +See the latest plugin specification and the +plugin forum on {{ zzz }}. +{%- endtrans %}

    -

    Developers wanted! Plugins are a great way to learn more about I2P -or easily add some feature.

    +

    {% trans pluginsite=i2pconv('plugins.i2p') -%} +See also the sources for plugins developed by various people. Some plugins, such +as snowman, were developed +specifically as examples. +{%- endtrans %}

    -

    Getting Started

    -

    To create a plugin from an existing binary package you will need to get -makeplugin.sh from the - i2p.scripts branch in monotone.

    +

    {% trans -%} +Developers wanted! Plugins are a great way to learn more about I2P +or easily add some feature. +{%- endtrans %}

    + +

    {% trans %}Getting Started{% endtrans %}

    +

    {% trans url='http://'+i2pconv('trac.i2p2.i2p')+'/browser/plugin/makeplugin.sh?rev=776519571fda0689ef09c42f66e7398f30432e87' -%} +To create a plugin from an existing binary package you will need to get +makeplugin.sh from the i2p.scripts branch in monotone. +{%- endtrans %}

    -

    Known Issues

    -

    Note that the router's plugin architecture does NOT currently -provide any additional security isolation or sandboxing of plugins.

    +

    {% trans %}Known Issues{% endtrans %}

    +

    {% trans -%} +Note that the router's plugin architecture does NOT currently +provide any additional security isolation or sandboxing of plugins. +{%- endtrans %}

      -
    • Updates of a plugin with included jars (not wars) won't be recognized if +
    • {% trans -%} +Updates of a plugin with included jars (not wars) won't be recognized if the plugin was already run, as it requires class loader trickery to flush the -class cache; a full router restart is required.
    • -
    • The stop button may be displayed even if there is nothing to stop.
    • -
    • Plugins running in a separate JVM create a logs/ directory in -$CWD.
    • -
    • No initial keys are present, except for those of jrandom and zzz (using the +class cache; a full router restart is required. +{%- endtrans %}
    • + +
    • {% trans -%} +The stop button may be displayed even if there is nothing to stop. +{%- endtrans %}
    • + +
    • {% trans -%} +Plugins running in a separate JVM create a logs/ directory in +$CWD. +{%- endtrans %}
    • + +
    • {% trans -%} +No initial keys are present, except for those of jrandom and zzz (using the same keys as for router update), so the first key seen for a signer is -automatically accepted—there is no signing key authority.
    • -
    • When deleting a plugin, the directory is not always deleted, especially on -Windows.
    • -
    • Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result -in a "plugin is corrupt" message if pack200 compression of the plugin file is -used.
    • -
    • Theme and translation plugins are untested.
    • -
    • Disabling autostart doesn't always work.
    • +automatically accepted—there is no signing key authority. +{%- endtrans %} + +
    • {% trans -%} +When deleting a plugin, the directory is not always deleted, especially on +Windows. +{%- endtrans %}
    • + +
    • {% trans -%} +Installing a plugin requiring Java 1.6 on a Java 1.5 machine will result in a +"plugin is corrupt" message if pack200 compression of the plugin file is used. +{%- endtrans %}
    • + +
    • {% trans -%} +Theme and translation plugins are untested. +{%- endtrans %}
    • + +
    • {% trans -%} +Disabling autostart doesn't always work. +{%- endtrans %}
    diff --git a/i2p2www/pages/site/docs/ports.html b/i2p2www/pages/site/docs/ports.html index 22dcfd89..19f0d864 100644 --- a/i2p2www/pages/site/docs/ports.html +++ b/i2p2www/pages/site/docs/ports.html @@ -1,20 +1,23 @@ {% extends "global/layout.html" %} -{% block title %}Ports Used by I2P{% endblock %} -{% block lastupdated %}May 2012{% endblock %} +{% block title %}{% trans %}Ports Used by I2P{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}May 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9{% endblock %} {% block content %} -

    +

    {% trans -%} These are the ports used or reserved by I2P, including those for known plugins, common alternates, and some typical related applications. -

    +{%- endtrans %}

    + +

    {% trans faq=site_url('faq') -%} Note that many of these are not enabled by default. -There is more information in the FAQ. +There is more information in the FAQ. See also the documentation for individual plugins. Plugin authors please add any ports you use here. For new plugins, we recommend using the next available port in the 766x range. +{%- endtrans %}

    @@ -45,7 +48,7 @@ in the 766x range. - + From 32c8fc9268cb8db71fdf8c507b9847c16d6772f7 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 30 Jan 2013 20:23:24 +0000 Subject: [PATCH 359/498] Added translation tags to docs/api/* except SAM pages --- i2p2www/pages/site/docs/api/bob.html | 144 ++++- i2p2www/pages/site/docs/api/i2pcontrol.html | 261 +++++---- i2p2www/pages/site/docs/api/i2ptunnel.html | 123 +++-- .../pages/site/docs/api/ministreaming.html | 43 +- i2p2www/pages/site/docs/api/socks.html | 71 +-- i2p2www/pages/site/docs/api/streaming.html | 508 ++++++++++-------- 6 files changed, 680 insertions(+), 470 deletions(-) diff --git a/i2p2www/pages/site/docs/api/bob.html b/i2p2www/pages/site/docs/api/bob.html index ef058796..f0cbf0bd 100644 --- a/i2p2www/pages/site/docs/api/bob.html +++ b/i2p2www/pages/site/docs/api/bob.html @@ -1,48 +1,77 @@ {% extends "global/layout.html" %} {% block title %}BOB{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block content %} -
    -Technical differences from SAM (for the better?)
    +

    {% trans %}BOB - Basic Open Bridge{% endtrans %}

    +

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

    +

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

    -SAM One connection that does everything, and you need to parse every packet. +

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

    +

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

    +

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

    +

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

    -KEYS = keypair public+private, these are BASE64 -KEY = public key, also BASE64 +

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

    +

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

    +

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

    +

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

    +

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

    -ERROR as is implied returns the message "ERROR "+DESCRIPTION+"\n", where the DESCRIPTION is what went wrong. -OK returns "OK", and if data is to be returned, it is on the same line. OK means the command is finished. -DATA lines contain information that you requested. There may be multiple DATA lines per request. - -NOTE: The help command is the ONLY command that has an exception to +

    {% trans -%} +NOTE: The help command is the ONLY command that has an exception to the rules... it can actually return nothing! This is intentional, since help is a HUMAN and not an APPLICATION command. +{%- endtrans %}

    -PLEASE NOTE: +

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

    +

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

    -Here are the commands we have as of this writing (Aug 2010). +

    {% trans -%} +Here are the commands we have as of this writing: +{%- endtrans %}

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

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

    +

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

    +

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

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

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

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

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

    +

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

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

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

    -NOTE: The "quit" command in the command channel does NOT disconnect the tunnels like SAM. +

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

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

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

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

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

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

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

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

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

    +

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

    +

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

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

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

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

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

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

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

    + +

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

    + +

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

    + +

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

    +{%- endtrans %}

    {% endblock %} diff --git a/i2p2www/pages/site/docs/api/i2pcontrol.html b/i2p2www/pages/site/docs/api/i2pcontrol.html index 4053babc..c5052edf 100644 --- a/i2p2www/pages/site/docs/api/i2pcontrol.html +++ b/i2p2www/pages/site/docs/api/i2pcontrol.html @@ -1,86 +1,87 @@ {% extends "global/layout.html" %} {% block title %}I2PControl API{% endblock %} {% block content %} -

    I2PControl - Remote Control Service

    -

    I2P enables a JSONRPC2 interface via the plugin I2PControl. +

    {% trans %}I2PControl - Remote Control Service{% endtrans %}

    +

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

    -

    I2PControl is by default listening on localhost:7650

    +{%- endtrans %}

    -

    API, version 1.

    -

    +

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

    + +

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

    +

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

    -

    JSON-RPC 2 format

    +

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

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

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

          Implemented methods

          -
            Authenticate – Creates and returns an authentication token used for further communication. -
              Request -
            • API – [long] The version of the I2PControl API used by the client.
            • -
            • Password – [String] The password used for authenticating against the remote server.
            • +

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

              +
                Authenticate – {% trans %}Creates and returns an authentication token used for further communication.{% endtrans %} +
                  {{ _('Request:') }} +
                • API – [long] {% trans %}The version of the I2PControl API used by the client.{% endtrans %}
                • +
                • Password – [String] {% trans %}The password used for authenticating against the remote server.{% endtrans %}
                -
                  Response -
                • API – [long] The primare I2PControl API version implemented by the server.
                • -
                • Token – [String] The token used for further communication.
                • +
                    {{ _('Response:') }} +
                  • API – [long] {% trans %}The primary I2PControl API version implemented by the server.{% endtrans %}
                  • +
                  • Token – [String] {% trans %}The token used for further communication.{% endtrans %}
                -
                  Echo – Echoes the value of the echo key, used for debugging and testing. -
                    Request -
                  • Echo – [String] Value will be returned in response.
                  • -
                  • Token – [String]Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                  • +
                      Echo – {% trans %}Echoes the value of the echo key, used for debugging and testing.{% endtrans %} +
                        {{ _('Request:') }} +
                      • Echo – [String] {% trans %}Value will be returned in response.{% endtrans %}
                      • +
                      • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
                      -
                        Response -
                      • Result – [String] Value of the key 'echo' in the request.
                      • +
                          {{ _('Response:') }} +
                        • Result – [String] {% trans %}Value of the key 'echo' in the request.{% endtrans %}
                      -
                        GetRate – Fetches rateStat from router statManager. Creates stat if not already created. -
                          Request -
                        • Stat – [String] Determines which rateStat to fetch, see ratestats.
                        • -
                        • Period – [long] Determines which period a stat is fetched for. Measured in ms.
                        • -
                        • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                        • +
                            GetRate – {% trans %}Fetches rateStat from router statManager. Creates stat if not already created.{% endtrans %} +
                              {{ _('Request:') }} +
                            • Stat – [String] {% trans %}Determines which rateStat to fetch, see ratestats.{% endtrans %}
                            • +
                            • Period – [long] {% trans %}Determines which period a stat is fetched for. Measured in ms.{% endtrans %}
                            • +
                            • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
                            -
                              Response -
                            • Result – [double] Returns the average value for the reuested rateStat and period.
                            • +
                                {{ _('Response:') }} +
                              • Result – [double] {% trans %}Returns the average value for the reuested rateStat and period.{% endtrans %}
                            -
                              I2PControl – Manages I2PControl. Ports, passwords and the like. -
                                Request -
                              • *i2pcontrol.address – [String] Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are implemented in I2PControl currently).
                              • -
                              • *i2pcontrol.password – [String] Sets a new password for I2PControl, all Authentication tokens will be revoked.
                              • -
                              • *i2pcontrol.port – [String] Switches which port I2PControl will listen for connections on.
                              • -
                              • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                              • +
                                  I2PControl – {% trans %}Manages I2PControl. Ports, passwords and the like.{% endtrans %} +
                                    {{ _('Request:') }} +
                                  • *i2pcontrol.address – [String] {% trans %}Sets a new listen address for I2PControl (only 127.0.0.1 and 0.0.0.0 are implemented in I2PControl currently).{% endtrans %}
                                  • +
                                  • *i2pcontrol.password – [String] {% trans %}Sets a new password for I2PControl, all Authentication tokens will be revoked.{% endtrans %}
                                  • +
                                  • *i2pcontrol.port – [String] {% trans %}Switches which port I2PControl will listen for connections on.{% endtrans %}
                                  • +
                                  • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
                                  -
                                    Response -
                                  • **i2pcontrol.address – [null] Returned if address was changed
                                  • -
                                  • **i2pcontrol.password – [null] Returned if setting was changed
                                  • -
                                  • **i2pcontrol.port – [null] Returned if setting was changed
                                  • -
                                  • SettingsSaved – [Boolean] Returns true if any changes were made.
                                  • -
                                  • RestartNeeded – [Boolean] Returns true if any changes requiring a restart to take effect were made.
                                  • +
                                      {{ _('Response:') }} +
                                    • **i2pcontrol.address – [null] {% trans %}Returned if address was changed{% endtrans %}
                                    • +
                                    • **i2pcontrol.password – [null] {% trans %}Returned if setting was changed{% endtrans %}
                                    • +
                                    • **i2pcontrol.port – [null] {% trans %}Returned if setting was changed{% endtrans %}
                                    • +
                                    • SettingsSaved – [Boolean] {% trans %}Returns true if any changes were made.{% endtrans %}
                                    • +
                                    • RestartNeeded – [Boolean] {% trans %}Returns true if any changes requiring a restart to take effect were made.{% endtrans %}
                                  -
                                    RouterInfo – Fetches basic information about hte I2P router. Uptime, version etc. -
                                      Request +
                                        RouterInfo – {% trans %}Fetches basic information about the I2P router. Uptime, version etc.{% endtrans %} +
                                          {{ _('Request:') }}
                                        • *i2p.router.status – [n/a]
                                        • *i2p.router.uptime – [n/a]
                                        • *i2p.router.version – [n/a]
                                        • @@ -95,17 +96,17 @@ Response:
                                        • *i2p.router.netdb.highcapacitypeers – [n/a]
                                        • *i2p.router.netdb.isreseeding – [n/a]
                                        • *i2p.router.netdb.knownpeers – [n/a]
                                        • -
                                        • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                                        • +
                                        • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
                                        -
                                          Response -
                                        • **i2p.router.status – [String] What the status of the router is.
                                        • -
                                        • **i2p.router.uptime – [long] What the uptime of the router is in ms.
                                        • -
                                        • **i2p.router.version – [String] What version of I2P the router is running.
                                        • -
                                        • **i2p.router.net.bw.inbound.1s – [double] The 1 second average inbound bandwidth in Bps.
                                        • -
                                        • **i2p.router.net.bw.inbound.15s – [double] The 15 second average inbound bandwidth in Bps.
                                        • -
                                        • **i2p.router.net.bw.outbound.1s – [double] The 1 second average outbound bandwidth in Bps.
                                        • -
                                        • **i2p.router.net.bw.outbound.15s – [double] The 15 second average outbound bandwidth in Bps.
                                        • -
                                        • **i2p.router.net.status – [long] What the current network status is. According to the below enum: +
                                            {{ _('Response:') }} +
                                          • **i2p.router.status – [String] {% trans %}What the status of the router is.{% endtrans %}
                                          • +
                                          • **i2p.router.uptime – [long] {% trans %}What the uptime of the router is in ms.{% endtrans %}
                                          • +
                                          • **i2p.router.version – [String] {% trans %}What version of I2P the router is running.{% endtrans %}
                                          • +
                                          • **i2p.router.net.bw.inbound.1s – [double] {% trans %}The 1 second average inbound bandwidth in Bps.{% endtrans %}
                                          • +
                                          • **i2p.router.net.bw.inbound.15s – [double] {% trans %}The 15 second average inbound bandwidth in Bps.{% endtrans %}
                                          • +
                                          • **i2p.router.net.bw.outbound.1s – [double] {% trans %}The 1 second average outbound bandwidth in Bps.{% endtrans %}
                                          • +
                                          • **i2p.router.net.bw.outbound.15s – [double] {% trans %}The 15 second average outbound bandwidth in Bps.{% endtrans %}
                                          • +
                                          • **i2p.router.net.status – [long] {% trans %}What the current network status is. According to the below enum:{% endtrans %}
                                            • 0 – OK
                                            • 1 – TESTING
                                            • @@ -124,83 +125,81 @@ Response:
                                            • 14 – ERROR_UDP_DISABLED_AND_TCP_UNSET
                                          • -
                                          • **i2p.router.net.tunnels.participating – [long] How many tunnels on the I2P net are we participating in.
                                          • -
                                          • **i2p.router.netdb.activepeers – [long] How many peers have we communicated with recently.
                                          • -
                                          • **i2p.router.netdb.fastpeers &ndasg; [long] How many peers are considered 'fast'.
                                          • -
                                          • **i2p.router.netdb.highcapacitypeers – [long] How many peers are considered 'high capacity'.
                                          • -
                                          • **i2p.router.netdb.isreseeding – [boolean] Is the router reseeding hosts to its NetDB?
                                          • -
                                          • **i2p.router.netdb.knownpeers – [long] How many peers are known to us (listed in our NetDB).
                                          • +
                                          • **i2p.router.net.tunnels.participating – [long] {% trans %}How many tunnels on the I2P net are we participating in.{% endtrans %}
                                          • +
                                          • **i2p.router.netdb.activepeers – [long] {% trans %}How many peers have we communicated with recently.{% endtrans %}
                                          • +
                                          • **i2p.router.netdb.fastpeers &ndasg; [long] {% trans %}How many peers are considered 'fast'.{% endtrans %}
                                          • +
                                          • **i2p.router.netdb.highcapacitypeers – [long] {% trans %}How many peers are considered 'high capacity'.{% endtrans %}
                                          • +
                                          • **i2p.router.netdb.isreseeding – [boolean] {% trans %}Is the router reseeding hosts to its NetDB?{% endtrans %}
                                          • +
                                          • **i2p.router.netdb.knownpeers – [long] {% trans %}How many peers are known to us (listed in our NetDB).{% endtrans %}
                                        -
                                          RouterManager – Manages I2P router restart/shutdown. -
                                            Request -
                                          • *Reseed – [n/a] Initiates a router reseed, fetching peers into our NetDB from a remote host.
                                          • -
                                          • *Restart – [n/a] Restarts the router.
                                          • -
                                          • *RestartGraceful – [n/a] Restarts the router gracefully (waits for participating tunnels to expire).
                                          • -
                                          • *Shutdown – [n/a] Shuts down the router.
                                          • -
                                          • *ShutdownGraceful – [n/a] Shuts down the router gracefully (waits for participating tunnels to expire).
                                          • -
                                          • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.
                                          • +
                                              RouterManager – {% trans %}Manages I2P router restart/shutdown.{% endtrans %} +
                                                {{ _('Request:') }} +
                                              • *Reseed – [n/a] {% trans %}Initiates a router reseed, fetching peers into our NetDB from a remote host.{% endtrans %}
                                              • +
                                              • *Restart – [n/a] {% trans %}Restarts the router.{% endtrans %}
                                              • +
                                              • *RestartGraceful – [n/a] {% trans %}Restarts the router gracefully (waits for participating tunnels to expire).{% endtrans %}
                                              • +
                                              • *Shutdown – [n/a] {% trans %}Shuts down the router.{% endtrans %}
                                              • +
                                              • *ShutdownGraceful – [n/a] {% trans %}Shuts down the router gracefully (waits for participating tunnels to expire).{% endtrans %}
                                              • +
                                              • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
                                              -
                                                Response -
                                              • **Reseed – [null] If requested, verifies that a reseed has been initiated.
                                              • -
                                              • **Restart – [null] If requested, verifies that a restart has been initiated.
                                              • -
                                              • **RestartGraceful – [null] If requested, verifies that a graceful restart has been initiated.
                                              • -
                                              • **Shutdown – [null] If requested, verifies that a shutdown has been initiated
                                              • -
                                              • **ShutdownGraceful – [null] If requested, verifies that a graceful shutdown has been initiated
                                              • +
                                                  {{ _('Response:') }} +
                                                • **Reseed – [null] {% trans %}If requested, verifies that a reseed has been initiated.{% endtrans %}
                                                • +
                                                • **Restart – [null] {% trans %}If requested, verifies that a restart has been initiated.{% endtrans %}
                                                • +
                                                • **RestartGraceful – [null] {% trans %}If requested, verifies that a graceful restart has been initiated.{% endtrans %}
                                                • +
                                                • **Shutdown – [null] {% trans %}If requested, verifies that a shutdown has been initiated{% endtrans %}
                                                • +
                                                • **ShutdownGraceful – [null] {% trans %}If requested, verifies that a graceful shutdown has been initiated{% endtrans %}
                                              -
                                                NetworkSetting – Fetches or sets various network related settings. Ports, addresses etc. -
                                                  Request -
                                                • *i2p.router.net.ntcp.port – [String] What port is used for the TCP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ntcp.hostname – [String] What hostname is used for the TCP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ntcp.autoip – [String] Use automatically detected ip for TCP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ssu.port – [String] What port is used for the UDP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ssu.hostname – [String] What hostname is used for the UDP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ssu.autoip – [String] Which methods should be used for detecting the ip address of the UDP transport. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.ssu.detectedip – [null] What ip has been detected by the UDP transport.
                                                • -
                                                • *i2p.router.net.upnp – [String] Is UPNP enabled. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.bw.share – [String] How many percent of bandwidth is usable for participating tunnels. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.bw.in – [String] How many KB/s of inbound bandwidth is allowed. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.bw.out – [String] How many KB/s of outbound bandwidth is allowed. If null is submitted, current setting will be returned.
                                                • -
                                                • *i2p.router.net.laptopmode – [String] Is laptop mode enabled (change router identity and UDP port when IP changes ). If null is submitted, current setting will be returned.
                                                • -
                                                • Token – [String] Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method. If null is submitted, current setting will be returned.
                                                • +
                                                    NetworkSetting – {% trans %}Fetches or sets various network related settings. Ports, addresses etc.{% endtrans %} +
                                                      {{ _('Request:') }} +
                                                    • *i2p.router.net.ntcp.port – [String] {% trans %}What port is used for the TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ntcp.hostname – [String] {% trans %}What hostname is used for the TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ntcp.autoip – [String] {% trans %}Use automatically detected ip for TCP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ssu.port – [String] {% trans %}What port is used for the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ssu.hostname – [String] {% trans %}What hostname is used for the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ssu.autoip – [String] {% trans %}Which methods should be used for detecting the ip address of the UDP transport. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.ssu.detectedip – [null] {% trans %}What ip has been detected by the UDP transport.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.upnp – [String] {% trans %}Is UPnP enabled. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.bw.share – [String] {% trans %}How many percent of bandwidth is usable for participating tunnels. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.bw.in – [String] {% trans %}How many KB/s of inbound bandwidth is allowed. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.bw.out – [String] {% trans %}How many KB/s of outbound bandwidth is allowed. If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • *i2p.router.net.laptopmode – [String] {% trans %}Is laptop mode enabled (change router identity and UDP port when IP changes ). If null is submitted, current setting will be returned.{% endtrans %}
                                                    • +
                                                    • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method. If null is submitted, current setting will be returned.{% endtrans %}
                                                    -
                                                      Response -
                                                    • **i2p.router.net.ntcp.port – [String] If requested, returns the port used for the TCP transport.
                                                    • -
                                                    • **i2p.router.net.ntcp.hostname – [String] If requested, returns the hostname used for the TCP transport.
                                                    • -
                                                    • **i2p.router.net.ntcp.autoip – [String] If requested, returns the method used for automatically detecting ip for the TCP transport.
                                                    • -
                                                    • **i2p.router.net.ssu.port – [String] If requested, returns the port used for the UDP transport.
                                                    • -
                                                    • **i2p.router.net.ssu.hostname – [String] If requested, returns the hostname used for the UDP transport.
                                                    • -
                                                    • **i2p.router.net.ssu.autoip – [String] If requested, returns methods used for detecting the ip address of the UDP transport.
                                                    • -
                                                    • **i2p.router.net.ssu.detectedip – [String] If requested, returns what ip has been detected by the UDP transport.
                                                    • -
                                                    • **i2p.router.net.upnp – [String] If requested, returns the UPNP setting.
                                                    • -
                                                    • **i2p.router.net.bw.share – [String] If requested, returns how many percent of bandwidth is usable for participating tunnels.
                                                    • -
                                                    • **i2p.router.net.bw.in – [String] If requested, returns how many KB/s of inbound bandwidth is allowed.
                                                    • -
                                                    • **i2p.router.net.bw.out – [String] If requested, returns how many KB/s of outbound bandwidth is allowed.
                                                    • -
                                                    • **i2p.router.net.laptopmode – [String] If requested, returns the laptop mode.
                                                    • -
                                                    • SettingsSaved – [boolean] Have the provided settings been saved.
                                                    • -
                                                    • RestartNeeded – [boolean] Is a restart needed for the new settings to be used.
                                                    • +
                                                        {{ _('Response:') }} +
                                                      • **i2p.router.net.ntcp.port – [String] {% trans %}If requested, returns the port used for the TCP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ntcp.hostname – [String] {% trans %}If requested, returns the hostname used for the TCP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ntcp.autoip – [String] {% trans %}If requested, returns the method used for automatically detecting ip for the TCP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ssu.port – [String] {% trans %}If requested, returns the port used for the UDP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ssu.hostname – [String] {% trans %}If requested, returns the hostname used for the UDP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ssu.autoip – [String] {% trans %}If requested, returns methods used for detecting the ip address of the UDP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.ssu.detectedip – [String] {% trans %}If requested, returns what ip has been detected by the UDP transport.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.upnp – [String] {% trans %}If requested, returns the UPNP setting.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.bw.share – [String] {% trans %}If requested, returns how many percent of bandwidth is usable for participating tunnels.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.bw.in – [String] {% trans %}If requested, returns how many KB/s of inbound bandwidth is allowed.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.bw.out – [String] {% trans %}If requested, returns how many KB/s of outbound bandwidth is allowed.{% endtrans %}
                                                      • +
                                                      • **i2p.router.net.laptopmode – [String] {% trans %}If requested, returns the laptop mode.{% endtrans %}
                                                      • +
                                                      • SettingsSaved – [boolean] {% trans %}Have the provided settings been saved.{% endtrans %}
                                                      • +
                                                      • RestartNeeded – [boolean] {% trans %}Is a restart needed for the new settings to be used.{% endtrans %}
                                                    -

                                                    * denotes an optional value.

                                                    -

                                                    ** denotes a possibly occuring return value

                                                    +

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

                                                    +

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

                                                    -

                                                    Error codes

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

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

                                                      +
                                                        {% trans %}Standard JSON-RPC2 error codes.{% endtrans %} +
                                                      • -32700 – {% trans %}JSON parse error.{% endtrans %}
                                                      • +
                                                      • -32600 – {% trans %}Invalid request.{% endtrans %}
                                                      • +
                                                      • -32601 – {% trans %}Method not found.{% endtrans %}
                                                      • +
                                                      • -32603 – {% trans %}Internal error.{% endtrans %}
                                                      -
                                                        I2PControl specific error codes. -
                                                      • -32001 – Invalid password provided.
                                                      • -
                                                      • -32002 – No authentication token presented.
                                                      • -
                                                      • -32003 – Authentication token doesn't exist.
                                                      • -
                                                      • -32004 – The provided authentication token was expired and will be removed.
                                                      • -
                                                      • -32005 – The version of the I2PControl API used wasn't specified, but is required to be specified.
                                                      • -
                                                      • -32006 – The version of the I2PControl API specified is not supported by I2PControl.
                                                      • +
                                                          {% trans %}I2PControl specific error codes.{% endtrans %} +
                                                        • -32001 – {% trans %}Invalid password provided.{% endtrans %}
                                                        • +
                                                        • -32002 – {% trans %}No authentication token presented.{% endtrans %}
                                                        • +
                                                        • -32003 – {% trans %}Authentication token doesn't exist.{% endtrans %}
                                                        • +
                                                        • -32004 – {% trans %}The provided authentication token was expired and will be removed.{% endtrans %}
                                                        • +
                                                        • -32005 – {% trans %}The version of the I2PControl API used wasn't specified, but is required to be specified.{% endtrans %}
                                                        • +
                                                        • -32006 – {% trans %}The version of the I2PControl API specified is not supported by I2PControl.{% endtrans %}
                                                        - - {% endblock %} diff --git a/i2p2www/pages/site/docs/api/i2ptunnel.html b/i2p2www/pages/site/docs/api/i2ptunnel.html index ebb16074..608ab170 100644 --- a/i2p2www/pages/site/docs/api/i2ptunnel.html +++ b/i2p2www/pages/site/docs/api/i2ptunnel.html @@ -1,92 +1,100 @@ {% extends "global/layout.html" %} {% block title %}i2ptunnel{% endblock %} -{% block content %}Description of i2ptunnel and tunneling modes +{% block content %} +

                                                        I2PTunnel

                                                        -

                                                        Overview

                                                        -

                                                        +

                                                        {% trans %}Overview{% endtrans %}

                                                        +

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

                                                        +{%- endtrans %}

                                                        -
                                                        -

                                                        Default Services

                                                        -

                                                        Server tunnels

                                                        +

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

                                                        +

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

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

                                                        Client tunnels

                                                        +

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

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

                                                        Client Modes

                                                        -

                                                        Standard

                                                        +

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

                                                        +

                                                        {% trans %}Standard{% endtrans %}

                                                        +

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

                                                        -

                                                        HTTP

                                                        -

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

                                                        +

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

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

                                                        +

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

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

                                                        +

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

                                                        +{%- endtrans %}

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

                                                        IRC

                                                        +

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

                                                        • MODE
                                                        • JOIN
                                                        • @@ -101,41 +109,58 @@ list of destinations. Only a whitelisted subset of IRC commands are allowed due

                                                        SOCKS 4/4a/5

                                                        +

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

                                                        SOCKS IRC

                                                        +

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

                                                        CONNECT

                                                        +

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

                                                        Streamr

                                                        +

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

                                                        +
                                                        -

                                                        Server Modes

                                                        -

                                                        Standard

                                                        +

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

                                                        +

                                                        {% trans %}Standard{% endtrans %}

                                                        +

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

                                                        HTTP

                                                        +

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

                                                        HTTP Bidirectional

                                                        +

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

                                                        IRC

                                                        +

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

                                                        Streamr

                                                        +

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

                                                        {% endblock %} diff --git a/i2p2www/pages/site/docs/api/ministreaming.html b/i2p2www/pages/site/docs/api/ministreaming.html index d3f78c5d..82b91d80 100644 --- a/i2p2www/pages/site/docs/api/ministreaming.html +++ b/i2p2www/pages/site/docs/api/ministreaming.html @@ -1,47 +1,56 @@ {% extends "global/layout.html" %} -{% block title %}Ministreaming Library{% endblock %} +{% block title %}{% trans %}Ministreaming Library{% endtrans %}{% endblock %} {% block content %} -

                                                        Note

                                                        +

                                                        {% trans %}Note{% endtrans %}

                                                        + +

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

                                                        -

                                                        Ministreaming Library

                                                        +

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

                                                        -

                                                        The ministreaming library is a layer on top of the core -I2CP that allows reliable, in order, and authenticated streams +

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

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

                                                        -

                                                        The ministreaming library was written by mihi as a part of his -I2PTunnel application and then factored out and released +

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

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

                                                        -

                                                        Even with those issues, the ministreaming library performs quite well in many -situations, and its API +

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

                                                        {% endblock %} +SAM's streaming support. +{%- endtrans %}

                                                        +{% endblock %} diff --git a/i2p2www/pages/site/docs/api/socks.html b/i2p2www/pages/site/docs/api/socks.html index 926189a1..b31a1552 100644 --- a/i2p2www/pages/site/docs/api/socks.html +++ b/i2p2www/pages/site/docs/api/socks.html @@ -1,34 +1,39 @@ {% extends "global/layout.html" %} {% block title %}SOCKS{% endblock %} {% block content %} -

                                                        SOCKS and SOCKS proxies

                                                        -

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

                                                        -

                                                        -As it says on the -FAQ: -

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

                                                        +

                                                        {% trans %}SOCKS and SOCKS proxies{% endtrans %}

                                                        +

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

                                                        + +

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

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

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

                                                        +{%- endtrans %}

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

                                                        {% trans -%} Hoping that we can simply strap an arbitrary client on top of I2P without auditing both its behavior and its exposed protocols for security and anonymity is naive. Pretty much *every* application @@ -38,33 +43,33 @@ reality. End users are better served with systems designed for anonymity and security. Modifying existing systems to work in anonymous environments is no small feat, orders of magnitude more work that simply using the existing I2P APIs. -

                                                        +{%- endtrans %}

                                                        -

                                                        +

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

                                                        +{%- endtrans %}

                                                        -

                                                        See Also

                                                        +

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

                                                        -

                                                        If You Do Get Something Working

                                                        +

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

                                                        +

                                                        {% trans -%} Please let us know. And please provide substantial warnings about the risks of socks proxies. +{%- endtrans %} {% endblock %} diff --git a/i2p2www/pages/site/docs/api/streaming.html b/i2p2www/pages/site/docs/api/streaming.html index ef416d55..13616fa8 100644 --- a/i2p2www/pages/site/docs/api/streaming.html +++ b/i2p2www/pages/site/docs/api/streaming.html @@ -1,30 +1,32 @@ {% extends "global/layout.html" %} -{% block title %}Streaming Library{% endblock %} -{% block lastupdated %}November 2012{% endblock %} +{% block title %}{% trans %}Streaming Library{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9.3{% endblock %} {% block content %} -

                                                        Overview

                                                        +

                                                        {% trans %}Overview{% endtrans %}

                                                        -

                                                        +

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

                                                        +datagram library. +{%- endtrans %}

                                                        -

                                                        The streaming library is a layer on top of the core -I2CP API that allows reliable, in-order, and authenticated streams +

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

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

                                                        -

                                                        +

                                                        {% trans -%} In consideration of the relatively high cost of messages, the streaming library's protocol for scheduling and delivering those messages has been optimized to allow individual messages passed to contain as much information as is available. @@ -34,184 +36,256 @@ the small HTTP request payload, and the reply bundles the SYN, FIN, ACK, and the HTTP response payload. While an additional ACK must be transmitted to tell the HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can often deliver the full response to the browser -immediately. -

                                                        +immediately. +{%- endtrans %}

                                                        -

                                                        +

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

                                                        +{%- endtrans %}

                                                        -

                                                        +

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

                                                        +{%- endtrans %}

                                                        +

                                                        {% trans %}API{% endtrans %}

                                                        - -

                                                        API

                                                        - -

                                                        +

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

                                                        +The lower-level I2CP API is completely hidden, except that +applications may pass I2CP parameters through the +streaming library, to be interpreted by I2CP. +{%- endtrans %}

                                                        -

                                                        +

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

                                                        -

                                                        -Here are the -full streaming library Javadocs. -

                                                        +I2PSocketManagerFactory to create an +I2PSocketManager. The application then asks the +socket manager for an I2PSession, which will cause +a connection to the router via I2CP. The application +can then setup connections with an I2PSocket or +receive connections with an I2PServerSocket. +{%- endtrans %}

                                                        -

                                                        +

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

                                                        + +

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

                                                        +{%- endtrans %}

                                                        -

                                                        Options and Defaults

                                                        -

                                                        +

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

                                                        +

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

                                                        -

                                                        -Note that higher-layer APIs, such as -SAM, -BOB, and -I2PTunnel, +{%- endtrans %}

                                                        + +

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

                                                        +{%- endtrans %}

                                                        + +

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

                                                        +{%- endtrans %}

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

    Protocol Specification

    -

    Packet Format

    -

    +

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

    +

    {% trans %}Packet Format{% endtrans %}

    +

    {% trans -%} The format of a single packet in the streaming protocol is: +{%- endtrans %}

     
     +----+----+----+----+----+----+----+----+
    @@ -232,7 +306,7 @@ The format of a single packet in the streaming protocol is:
     
    -
    FieldLengthContents +
    {{ _('Field') }}{{ _('Length') }}{{ _('Contents') }}
    sendStreamId 4 byte IntegerRandom number selected by the connection recipient and constant for the life of the connection. 0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received, @@ -280,11 +354,14 @@ As specified by the flags. See below.
    payload remaining packet size
    -

    Flags and Option Data Fields

    -

    The flags field above specifies some metadata about the packet, and in +

    {% trans %}Flags and Option Data Fields{% endtrans %}

    +

    {% trans -%} +The flags field above specifies some metadata about the packet, and in turn may require certain additional data to be included. The flags are as follows. Any data structures specified must be added to the options area -in the given order.

    +in the given order. +{%- endtrans %}

    +

    Bit order: 15....0 (15 is MSB)

    @@ -329,30 +406,32 @@ Currently unused, the ackThrough field is always valid. 11-15unused -

    Implementation Details

    +

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

    -

    Setup

    -

    +

    {% trans %}Setup{% endtrans %}

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    MTU Selection and Negotiation

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Data Integrity

    +

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

    +

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

    -

    Packet Encapsulation

    +

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

    +

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

    -

    Windowing

    -

    +

    {% trans %}Windowing{% endtrans %}

    +

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

    +{%- endtrans %}

    -

    Close

    -

    +

    {% trans %}Close{% endtrans %}

    +

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

    +{%- endtrans %}

    -

    Control Block Sharing

    -

    +

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

    +

    {% trans -%} The streaming lib supports "TCP" Control Block sharing. This shares two important streaming lib parameters (window size and round trip time) @@ -407,10 +489,12 @@ There is a separate share per ConnectionManager (i.e. per local Destination) so that there is no information leakage to other Destinations on the same router. The share data for a given peer expires after a few minutes. -

    +{%- endtrans %}

    -

    Other Parameters

    +

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

    +

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

    • MIN_RESEND_DELAY = 2*1000 (minimum RTO)
    • MAX_RESEND_DELAY = 45*1000 (maximum RTO) @@ -425,8 +509,8 @@ The following parameters are hardcoded, but may be of interest for analysis:

    -

    History

    -

    +

    {% trans %}History{% endtrans %}

    +

    {% trans -%} The streaming library has grown organically for I2P - first mihi implemented the "mini streaming library" as part of I2PTunnel, which was limited to a window size of 1 message (requiring an ACK before sending the next one), and then it was @@ -437,26 +521,25 @@ streams may adjust the maximum packet size and other options. The default message size is selected to fit precisely in two 1K I2NP tunnel messages, and is a reasonable tradeoff between the bandwidth costs of retransmitting lost messages, and the latency and overhead of multiple messages. -

    +{%- endtrans %}

    - - - -

    Future Work

    +

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

    +

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

      -
    • +
    • {% trans -%} Additional tuning of the streaming lib parameters may be necessary. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans ntcpdisc=site_url('docs/discussions/ntcp') -%} Another area for research is the interaction of the streaming lib with the NTCP and SSU transport layers. -See the NTCP discussion page for details. -
    • -
    • +See the NTCP discussion page for details. +{%- endtrans %}
    • +
    • {% trans -%} The interaction of the routing algorithms with the streaming lib strongly affects performance. In particular, random distribution of messages to multiple tunnels in a pool leads to a high degree of out-of-order delivery which results in smaller window @@ -465,38 +548,35 @@ messages for a single from/to destination pair through a consistent set of tunnels, until tunnel expiration or delivery failure. The router's failure and tunnel selection algorithms should be reviewed for possible improvements. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} The data in the first SYN packet may exceed the receiver's MTU. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} The DELAY_REQUESTED field could be used more. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} Don't send the MTU in a retransmission. -
    • -
    • - Data is sent along unless the outbound window is full. - (i.e. no-Nagle or TCP_NODELAY) - Probably should have a configuration option for this. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} +Data is sent along unless the outbound window is full. +(i.e. no-Nagle or TCP_NODELAY) +Probably should have a configuration option for this. +{%- endtrans %}
    • +
    • {% trans -%} zzz has added debug code to the streaming library to log packets in a wireshark-compatible (pcap) format; Use this to further analyze performance. The format may require enhancement to map more streaming lib parameters to TCP fields. -
    • -
    • +{%- endtrans %}
    • +
    • {% trans -%} There are proposals to replace the streaming lib with standard TCP (or perhaps a null layer together with raw sockets). This would unfortunately be incompatible with the streaming lib but it would be good to compare the performance of the two. -
    • +{%- endtrans %}
    - - - {% endblock %} From 4a801a9fcd4a68492e6fcfdbb3f13537875e0bd9 Mon Sep 17 00:00:00 2001 From: kytv Date: Wed, 30 Jan 2013 21:46:43 +0000 Subject: [PATCH 360/498] typo fix --- i2p2www/pages/downloads/debian.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/downloads/debian.html b/i2p2www/pages/downloads/debian.html index a13dc546..8b3d8557 100644 --- a/i2p2www/pages/downloads/debian.html +++ b/i2p2www/pages/downloads/debian.html @@ -188,7 +188,7 @@ i2p
    " as root or using sudo. This is the recommended means of operation. When installing for the first time, please remember to adjust your NAT/firewall if you can. The ports to forward can be found on the network configuration page in the router console. If guidance with respect to forwarding ports is needed, -you may portforward.com to be helpful. +you may find portforward.com to be helpful. {%- endtrans %}

    {% trans -%} From 8c043011656e25135a15f0d416a8a70959005276 Mon Sep 17 00:00:00 2001 From: kytv Date: Wed, 30 Jan 2013 21:57:14 +0000 Subject: [PATCH 361/498] minor shell script tweaks - add shebang line and make bourne compatible - report bugs to trac --- compile-messages.sh | 3 ++- extract-messages.sh | 9 +++++++-- init-new-po.sh | 3 ++- update-existing-po.sh | 3 ++- 4 files changed, 13 insertions(+), 5 deletions(-) diff --git a/compile-messages.sh b/compile-messages.sh index 68f3d282..819e4e81 100755 --- a/compile-messages.sh +++ b/compile-messages.sh @@ -1,3 +1,4 @@ -source ./translation.vars +#!/bin/sh +. ./translation.vars TZ=UTC env/bin/pybabel compile -d $TRANSDIR diff --git a/extract-messages.sh b/extract-messages.sh index c87dc1d2..1593068d 100755 --- a/extract-messages.sh +++ b/extract-messages.sh @@ -1,3 +1,8 @@ -source ./translation.vars +#!/bin/sh +. ./translation.vars -TZ=UTC env/bin/pybabel extract --project=$PROJECT --version=$VERSION -F $BABELCFG -o $POTFILE $PROJDIR +TZ=UTC env/bin/pybabel extract --msgid-bugs-address="http://trac.i2p2.de" \ + --project=$PROJECT \ + --version=$VERSION \ + -F $BABELCFG \ + -o $POTFILE $PROJDIR diff --git a/init-new-po.sh b/init-new-po.sh index c232ba83..4d9ea0f7 100755 --- a/init-new-po.sh +++ b/init-new-po.sh @@ -1,4 +1,5 @@ -source ./translation.vars +#!/bin/sh +. ./translation.vars if [ $# -ge 1 ] then diff --git a/update-existing-po.sh b/update-existing-po.sh index 8d6b600c..6d4d1717 100755 --- a/update-existing-po.sh +++ b/update-existing-po.sh @@ -1,3 +1,4 @@ -source ./translation.vars +#!/bin/sh +. ./translation.vars TZ=UTC env/bin/pybabel update -i $POTFILE -d $TRANSDIR From 27824b70e66ed17abab3fae88e3c6aa25c7c4589 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 30 Jan 2013 23:19:19 +0000 Subject: [PATCH 362/498] Added translation tags to docs/applications/* --- .../site/docs/applications/bittorrent.html | 235 ++++--- .../site/docs/applications/supported.html | 658 ++++++++++-------- 2 files changed, 501 insertions(+), 392 deletions(-) diff --git a/i2p2www/pages/site/docs/applications/bittorrent.html b/i2p2www/pages/site/docs/applications/bittorrent.html index 013dbefa..79320856 100644 --- a/i2p2www/pages/site/docs/applications/bittorrent.html +++ b/i2p2www/pages/site/docs/applications/bittorrent.html @@ -1,183 +1,203 @@ {% extends "global/layout.html" %} -{% block title %}Bittorrent over I2P{% endblock %} -{% block lastupdated %}September 2012{% endblock %} +{% block title %}{% trans %}Bittorrent over I2P{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}September 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9.2{% endblock %} {% block content %} -

    There are several bittorrent clients and trackers on I2P. +

    {% trans -%} +There are several bittorrent clients and trackers on I2P. As I2P addressing uses a Destination instead of an IP and port, minor changes are required to tracker and client software for operation on I2P. These changes are specified below. Note carefully the guidelines for compatibility with older I2P clients and trackers. -

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Announces

    -

    +

    {% trans %}Announces{% endtrans %}

    +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Non-Compact Tracker Responses

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Compact Tracker Responses

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Destination Enforcement

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Announce Host Names

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Client Connections

    -

    +

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

    +

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

    -

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

    -

    +{%- endtrans %}

    + +

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

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Cross-Network Prevention

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    PEX

    -

    +

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

    +{%- endtrans %}

    DHT

    -

    +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Additional Information

    +

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

    diff --git a/i2p2www/pages/site/docs/applications/supported.html b/i2p2www/pages/site/docs/applications/supported.html index 6deda707..52f0ce66 100644 --- a/i2p2www/pages/site/docs/applications/supported.html +++ b/i2p2www/pages/site/docs/applications/supported.html @@ -1,36 +1,34 @@ {% extends "global/layout.html" %} -{% block title %}Supported Applications{% endblock %} +{% block title %}{% trans %}Supported Applications{% endtrans %}{% endblock %} {% block content %} -

    Supported Applications

    +

    {% trans %}Supported Applications{% endtrans %}

    -

    This is intended to be a comprehensive listing of applications used with +

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

    +Trac, and be sure to select the +“www” component in the submission form. +{%- endtrans %}

    -

    Supported applications are tagged with one or more of the following:

    +

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

    -
    bundled
    +
    {{ _('bundled') }}
    -

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

    +

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

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

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

    +

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

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

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

    +

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

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

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

    +

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

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

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

    +

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

    -

    Warning: Using an application, plugin, or service with I2P +

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

    +carelessness on their part or your own. +{%- endtrans %}

    -

    If you have doubts about the suitability of an application, +

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

    +community. +{%- endtrans %}

    -

    Take responsibility for your own anonymity and safety — always +

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

    +shortcuts. +{%- endtrans %}

    -

    Blogging, Forums, and Wikis

    +

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

    • -

      El - Dorado — Lightweight forum software. - [standalone/mod]

      +

      El Dorado — + {% trans %}Lightweight forum software.{% endtrans %} + [{{ _('standalone/mod') }}]

    • -

      Pebble - — Another lightweight blogging platform. - [plugin, standalone/mod]

      +

      Pebble — + {% trans %}Another lightweight blogging platform.{% endtrans %} + [{{ _('plugin') }}, {{ _('standalone/mod') }}]

    • -

      phpBB — Most - popular open source forum software. - [standalone/mod]

      +

      phpBB — + {% trans %}Most popular open source forum software.{% endtrans %} + [{{ _('standalone/mod') }}]

    • Syndie — - Distributed forums software, originally developed by jrandom. - [plugin, standalone, unmaintained]

      + {% trans %}Distributed forums software, originally developed by jrandom.{% endtrans %} + [{{ _('plugin') }}, {{ _('standalone') }}, {{ _('unmaintained') }}]

    • JAMWiki — - A Java-based MediaWiki clone. No external database needed. - Plugin available here. - [standalone, plugin]

      +{% trans plugins=i2pconv('plugins.i2p') -%} +A Java-based MediaWiki clone. No external database needed. +Plugin available here. +{%- endtrans %} + [{{ _('standalone') }}, {{ _('plugin') }}]

    -

    Decentralized File -Storage

    +

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

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

    Development Tools

    +

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

    -

    Version control

    +

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

    • -

      Git — Most popular - distributed version control system. [standalone]

      +

      Git — + {% trans %}Most popular distributed version control system.{% endtrans %} + [{{ _('standalone') }}]

    • -

      Monotone — Another - distributed version control system. Currently used in I2P development. - [standalone]

      +

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

    -

    Domain Naming

    +

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

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

    Email

    - -
      -
    • -

      I2P-Bote — - Serverless peer-to-peer email application using a distributed hash table - (DHT) for secure mail storage. [plugin]

      -
    • - -
    • -

      Postman's anonymous email - service — Provides email service within the I2P network via - @mail.i2p addresses, and email gateway service between the I2P network - and the public Internet via @i2pmail.org addresses. One of the oldest - continuous services on I2P. [service]

      -
    • - -
    • -

      susimail - — Simple web browser-based email interface. Configured to use Postman's - email service by default. [bundled]

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

    File Sharing

    - -

    BitTorrent clients

    +

    {% trans %}Email{% endtrans %}

    • -

      I2PSnark — I2P's - integrated BitTorrent client. [bundled]

      +

      I2P-Bote — +{% trans -%} +Serverless peer-to-peer email application using a distributed hash table +(DHT) for secure mail storage. +{%- endtrans %} + [{{ _('plugin') }}]

    • -

      I2PSnarkXL - — Modified version of I2PSnark. [standalone]

      +

      Postman's anonymous email service — +{% trans -%} +Provides email service within the I2P network via @mail.i2p addresses, +and email gateway service between the I2P network and the public Internet +via @i2pmail.org addresses. One of the oldest continuous services on I2P. +{%- endtrans %} + [{{ _('service') }}]

    • -

      Robert — a - fork of rufus that uses the Basic Open Bridge (BOB) and has many - improvements, including using the latest wxwidgets and python. It also - supports use of seedless if installed for trackerless torrents and - magnet-link like fetching of torrents within i2p. - [standalone]

      +

      susimail — +{% trans -%} +Simple web browser-based email interface. Configured to use Postman's +email service by default. +{%- endtrans %} + [{{ _('bundled') }}]

      +
    • +
    + +

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

    + +

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

    + +
      +
    • +

      I2PSnark — + {% trans %}I2P's integrated BitTorrent client.{% endtrans %} + [{{ _('bundled') }}]

    • -

      Transmission — - Clean, full-featured cross-platform BitTorrent client with official - ports for several GUI toolkits. [standalone/mod]

      +

      I2PSnarkXL — + {% trans %}Modified version of I2PSnark.{% endtrans %} + [{{ _('standalone') }}]

      +
    • + +
    • +

      Robert — +{% trans %} +A fork of rufus that uses the Basic Open Bridge (BOB) and has many +improvements, including using the latest wxwidgets and python. It also +supports use of seedless if installed for trackerless torrents and +magnet-link like fetching of torrents within I2P. +{% endtrans %} + [{{ _('standalone') }}]

      +
    • + +
    • +

      Transmission — +{% trans -%} +Clean, full-featured cross-platform BitTorrent client with official +ports for several GUI toolkits. +{%- endtrans %} + [{{ _('standalone/mod') }}]

    • Azureus/Vuze — - Had a built-in I2P transport for a while. - [standalone, unmaintained]

      + {% trans %}Has a plugin providing I2P support.{% endtrans %} + [{{ _('standalone') }}, {{ _('unmaintained') }}]

    -

    BitTorrent trackers -and indexers

    +

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

    -

    For a detailed feature comparison of I2P-enabled trackers/indexers, see -here.

    +

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

    • -

      Bytemonsoon — The - code that powered one of the first major tracker/indexer sites on the - Internet. Patched for I2P. [standalone/mod]

      +

      Bytemonsoon — +{% trans -%} +The code that powered one of the first major tracker/indexer sites on the +Internet. Patched for I2P. +{%- endtrans %} + [{{ _('standalone/mod') }}]

    • -

      opentracker - — Lightweight tracker/indexer. I2P mod available in the i2p.opentracker - branch of the I2P Monotone repository. - [standalone/mod]

      +

      opentracker — +{% trans newdevs=site_url('get-involved/guides/new-developers') -%} +Lightweight tracker/indexer. I2P mod available in the i2p.opentracker +branch of the I2P Monotone repository. +{%- endtrans %} + [{{ _('standalone/mod') }}]

    • -

      zzzot — - zzz's Java-based open tracker. More info - here. - [plugin]

      +

      zzzot — +{% trans zzz=i2pconv('zzz.i2p') -%} +zzz's Java-based open tracker. More info +here. +{%- endtrans %} + [{{ _('plugin') }}]

    ED2K

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

    Gnutella

    • -

      I2Phex — Port - of the Phex Gnutella client. Website - for plugin version here. - [plugin, standalone]

      +

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

    • -

      jwebcache - — Cache for Gnutella peers on I2P. Website for plugin version here. - [plugin, standalone]

      +

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

    -

    Network -Administration

    +

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

    -

    General-purpose -socket utilities

    +

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

    • netcat — - Unix standard tool for socket relaying. Several clones, ports, and forks - have appeared over the years. [standalone]

      +{% trans -%} +Unix standard tool for socket relaying. Several clones, ports, and forks +have appeared over the years. +{%- endtrans %} + [{{ _('standalone') }}]

    • -

      socat — Like - netcat but more powerful. [standalone]

      +

      socat — + {% trans %}Like netcat but more powerful.{% endtrans %} + [{{ _('standalone') }}]

    • -

      tsocks - — Proxy providing simple, transparent SOCKS-ification of network - applications. [standalone]

      +

      tsocks — + {% trans %}Proxy providing simple, transparent SOCKS-ification of network applications.{% endtrans %} + [{{ _('standalone') }}]

    @@ -408,213 +454,249 @@ socket utilities

    • -

      OpenSSH — Most - popular implementation of the Secure Shell (SSH) protocol and related - tools. [standalone]

      +

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

    • -

      PuTTY - — Open source Secure Shell (SSH) client for Windows. - [standalone]

      +

      PuTTY — + {% trans %}Open source Secure Shell (SSH) client for Windows.{% endtrans %} + [{{ _('standalone') }}]

    -

    Real-time Chat

    +

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

    -

    Instant messaging -clients

    +

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

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

    IRC clients

    +

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

    -

    Many IRC clients leak identifying information to servers or other +

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

    +/me command) which isn't inherently dangerous. +{%- endtrans %}

    -

    I2P's IRC filtering may not cover every possible leak — users should also +

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

    +developers; they may be able to solve it via additional filtering. +{%- endtrans %}

    • jIRCii — - Small Java-based IRC client. Plugin available here. - [plugin, standalone]

      +{% trans stats=i2pconv('stats.i2p') -%} +Small Java-based IRC client. Plugin available here. +{%- endtrans %} + [{{ _('plugin') }}, {{ _('standalone') }}]

    • XChat — - Cross-platform graphical IRC client. - [standalone]

      + {% trans %}Cross-platform graphical IRC client.{% endtrans %} + [{{ _('standalone') }}]

    • -

      irssi — Unixy - terminal-based IRC client. [standalone]

      +

      irssi — + {% trans %}Unixy terminal-based IRC client.{% endtrans %} + [{{ _('standalone') }}]

    • WeeChat — - Another Unixy terminal-based IRC client. - [standalone]

      + {% trans %}Another Unixy terminal-based IRC client.{% endtrans %} + [{{ _('standalone') }}]

    -

    IRC servers

    +

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

    • -

      ngIRCd — IRC - server developed from scratch. [standalone/mod]

      +

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

    • -

      UnrealIRCd - — Most popular IRC server. [standalone/mod]

      +

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

    -

    Web Browsing

    +

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

    -

    Anonymous websites

    +

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

    • -

      Eepsites — Any website hosted anonymously on I2P, - reachable through the I2P router's HTTP proxy. - [service]

      +

      Eepsites — +{% trans -%} +Any website hosted anonymously on I2P, reachable through the I2P router's HTTP proxy. +{%- endtrans %} + [{{ _('service') }}]

    • -

      Deepsites — Distributed anonymous websites hosted - using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P - clients or through the Tahoe-LAFS-I2P HTTP proxy. - [service]

      +

      Deepsites — +{% trans -%} +Distributed anonymous websites hosted +using Tahoe-LAFS-I2P, currently only reachable with Tahoe-LAFS-I2P +clients or through the Tahoe-LAFS-I2P HTTP proxy. +{%- endtrans %} + [{{ _('service') }}]

    • -

      i2host.i2p — - Website for sponge's jump service. - Source code available. [service]

      +

      {{ i2pconv('i2host.i2p') }} — +{% trans sponge=i2pconv('sponge.i2p') -%} +Website for sponge's jump service. +Source code available. +{%- endtrans %} + [{{ _('service') }}]

    • -

      i2jump.i2p — - Another jump service. [service]

      +

      {{ i2pconv('i2jump.i2p') }} — + {% trans %}Another jump service.{% endtrans %} + [{{ _('service') }}]

    • -

      perv.i2p — - Dynamically updated eepsite index. [service]

      +

      {{ i2pconv('perv.i2p') }} — + {% trans %}Dynamically updated eepsite index.{% endtrans %} + [{{ _('service') }}]

    • -

      stats.i2p — Website - for zzz's jump service. - [service]

      +

      {{ i2pconv('stats.i2p') }} — + {% trans zzz=i2pconv('zzz.i2p') %}Website for zzz's jump service.{% endtrans %} + [{{ _('service') }}]

    -

    Proxy software

    +

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

    • -

      Polipo - — SOCKS-enabled caching web proxy with basic filtering capabilities. - [standalone]

      +

      Polipo — + {% trans %}SOCKS-enabled caching web proxy with basic filtering capabilities.{% endtrans %} + [{{ _('standalone') }}]

    • Privoxy — - Privacy-focused non-caching web proxy with advanced filtering - capabilities. Excels at removing ads and other junk. - [standalone]

      +{% trans -%} +Privacy-focused non-caching web proxy with advanced filtering +capabilities. Excels at removing ads and other junk. +{%- endtrans %} + [{{ _('standalone') }}]

    • Squid — - Venerable caching web proxy. [standalone]

      + {% trans %}Venerable caching web proxy.{% endtrans %} + [{{ _('standalone') }}]

    -

    Inproxies

    +

    {% trans %}Inproxies{% endtrans %}

    -

    Gateways allowing users on the public Internet to access eepsites.

    +

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

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

    Outproxies

    +

    {% trans %}Outproxies{% endtrans %}

    -

    Gateways allowing I2P users to access content hosted on the public -Internet.

    +

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

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

    Website Hosting

    +

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

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

    Web servers

    +

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

    -

    In addition to Jetty, any web server should function over I2P without +

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

    +currently serve content on the I2P network are: +{%- endtrans %}

    • -

      Apache HTTP - Server — Most popular web server on the public WWW. - [standalone]

      +

      Apache HTTP Server — + {% trans %}Most popular web server on the public WWW.{% endtrans %} + [{{ _('standalone') }}]

    • -

      Apache - Tomcat — Web server and Java servlet container. More - features than Jetty. [standalone]

      +

      Apache Tomcat — + {% trans %}Web server and Java servlet container. More features than Jetty.{% endtrans %} + [{{ _('standalone') }}]

    • lighttpd — - Fast lightweight web server. [standalone]

      + {% trans %}Fast lightweight web server.{% endtrans %} + [{{ _('standalone') }}]

    • nginx — - High-performance lightweight web server. - [standalone]

      + {% trans %}High-performance lightweight web server.{% endtrans %} + [{{ _('standalone') }}]

    From c9f436c73879d5c1093764cea74e2e89a595ac8f Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 31 Jan 2013 02:15:30 +0000 Subject: [PATCH 363/498] Added translation tags to docs/discussions/naming --- .../pages/site/docs/discussions/naming.html | 198 ++++++++++++------ 1 file changed, 130 insertions(+), 68 deletions(-) diff --git a/i2p2www/pages/site/docs/discussions/naming.html b/i2p2www/pages/site/docs/discussions/naming.html index 1c30a8d0..1ae02e26 100644 --- a/i2p2www/pages/site/docs/discussions/naming.html +++ b/i2p2www/pages/site/docs/discussions/naming.html @@ -1,22 +1,22 @@ {% extends "global/layout.html" %} -{% block title %}Naming discussion{% endblock %} +{% block title %}{% trans %}Naming discussion{% endtrans %}{% endblock %} {% block content %} -

    +

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

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

    -

    Discarded alternatives

    +

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

    -

    +

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

    +{%- endtrans %}

    -

    +

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

    +{%- endtrans %}

    -

    +

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

    +{%- endtrans %}

    -

    +

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

    +{%- endtrans %}

    Discussion

    -

    +

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

    +{%- endtrans %}

    Comments by jrandom

    -

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

    -

    +

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

    +

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

    +{%- endtrans %}

    +

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

    +{%- endtrans %}

    +

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

    +{%- endtrans %}

    +

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

    +{%- endtrans %}

    Comments by zzz

    -

    The following from zzz is a review of several common +

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

      -
    • Inefficiency
      +
    • +

      {% trans -%} +Inefficiency: The whole hosts.txt is downloaded (if it has changed, since eepget uses the etag and last-modified headers). It's about 400K right now for almost 800 hosts. -

      +{%- endtrans %}

      +

      {% trans -%} True, but this isn't a lot of traffic in the context of i2p, which is itself wildly inefficient (floodfill databases, huge encryption overhead and padding, garlic routing, etc.). If you downloaded a hosts.txt file from someone every 12 hours it averages out to about 10 bytes/sec. -

      +{%- endtrans %}

      +

      {% trans -%} As is usually the case in i2p, there is a fundamental tradeoff here between anonymity and efficiency. Some would say that using the etag and last-modified headers is hazardous because it exposes when you last requested the data. Others have suggested asking for specific keys only (similar to what jump services do, but in a more automated fashion), possibly at a further cost in anonymity. -

      -Possible improvements would be a replacement or supplement to addressbook (see i2host.i2p), +{%- endtrans %}

      +

      {% trans i2host=i2pconv('i2host.i2p') -%} +Possible improvements would be a replacement or supplement to addressbook (see {{ i2host }}p), or something simple like subscribing to http://example.i2p/cgi-bin/recenthosts.cgi rather than http://example.i2p/hosts.txt. If a hypothetical recenthosts.cgi distributed all hosts from the last 24 hours, for example, that could be both more efficient and more anonymous than the current hosts.txt with last-modified and etag. -

      +{%- endtrans %}

      +

      {% trans url='http://'+i2pconv('stats.i2p')+'/cgi-bin/newhosts.txt' -%} A sample implementation is on stats.i2p at -http://stats.i2p/cgi-bin/newhosts.txt. +{{ url }}. This script returns an Etag with a timestamp. When a request comes in with the If-None-Match etag, the script ONLY returns new hosts since that timestamp, or 304 Not Modified if there are none. In this way, the script efficiently returns only the hosts the subscriber does not know about, in an addressbook-compatible manner. - - -

      +{%- endtrans %}

      +

      {% trans -%} So the inefficiency is not a big issue and there are several ways to improve things without radical change. +{%- endtrans %}

      -
    • Not Scalable
      +
    • +

      {% trans -%} +Not Scalable: The 400K hosts.txt (with linear search) isn't that big at the moment and we can probably grow by 10x or 100x before it's a problem. -

      +{%- endtrans %}

      +

      {% trans -%} As far as network traffic see above. But unless you're going to do a slow real-time query over the network for a key, you need to have the whole set of keys stored locally, at a cost of about 500 bytes per key. -

    • Requires configuration and "trust"
      +{%- endtrans %}

      + +
    • +

      {% trans -%} +Requires configuration and "trust": Out-of-the-box addressbook is only subscribed to http://www.i2p2.i2p/hosts.txt, which is rarely updated, leading to poor new-user experience. -

      +{%- endtrans %}

      +

      {% trans -%} This is very much intentional. jrandom wants a user to "trust" a hosts.txt provider, and as he likes to say, "trust is not a boolean". The configuration step attempts to force users to think about issues of trust in an anonymous network. -

      +{%- endtrans %}

      +

      {% trans -%} As another example, the "Eepsite Unknown" error page in the HTTP Proxy lists some jump services, but doesn't "recommend" any one in particular, and it's up to the user to pick one (or not). jrandom would say we trust the listed providers enough to list them but not enough to automatically go fetch the key from them. -

      +{%- endtrans %}

      +

      {% trans -%} How successful this is, I'm not sure. But there must be some sort of hierarchy of trust for the naming system. To treat everyone equally may increase the risk of hijacking. +{%- endtrans %}

      -
    • It isn't DNS
      +
    • +

      {% trans -%} +It isn't DNS +{%- endtrans %}

      +

      {% trans -%} Unfortunately real-time lookups over i2p would significantly slow down web browsing. -

      +{%- endtrans %}

      +

      {% trans -%} Also, DNS is based on lookups with limited caching and time-to-live, while i2p keys are permanent. -

      +{%- endtrans %}

      +

      {% trans -%} Sure, we could make it work, but why? It's a bad fit. -

    • Not reliable
      +{%- endtrans %}

      + +
    • +

      {% trans -%} +Not reliable: It depends on specific servers for addressbook subscriptions. -

      +{%- endtrans %}

      +

      {% trans -%} Yes it depends on a few servers that you have configured. Within i2p, servers and services come and go. Any other centralized system (for example DNS root servers) would have the same problem. A completely decentralized system (everybody is authoritative) is possible by implementing an "everybody is a root DNS server" solution, or by something even simpler, like a script that adds everybody in your hosts.txt to your addressbook. -

      +{%- endtrans %}

      +

      {% trans -%} People advocating all-authoritative solutions generally haven't thought through the issues of conflicts and hijacking, however. +{%- endtrans %}

      -
    • Awkward, not real-time
      +
    • +

      {% trans -%} +Awkward, not real-time: It's a patchwork of hosts.txt providers, key-add web form providers, jump service providers, eepsite status reporters. Jump servers and subscriptions are a pain, it should just work like DNS. -

      +{%- endtrans %}

      +

      {% trans -%} See the reliability and trust sections. -

      +{%- endtrans %}

      +
    -

    So, in summary, the current system is not horribly broken, inefficient, or un-scalable, +

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

    +{%- endtrans %}

    -

    Alternatives

    -

    The I2P source contains several pluggable naming systems and supports configuration options +

    {% trans %}Alternatives{% endtrans %}

    +

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

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

    +

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

    +{%- endtrans %}

    +

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

    -

    Certificates

    -

    +

    {% trans %}Certificates{% endtrans %}

    +

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

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

    +{%- endtrans %}

    +

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

    +

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

    +{%- endtrans %}

    +

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

    +{%- endtrans %}

    +

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

    +{%- endtrans %}

    {% endblock %} From b09a7f4099030f1a82ca7e3390d200ada12cdf4a Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 31 Jan 2013 02:23:23 +0000 Subject: [PATCH 364/498] Added placeholder CSS files to the other themes --- i2p2www/static/styles/danimoth/default.css | 0 i2p2www/static/styles/danimoth/mobile.css | 0 i2p2www/static/styles/dark/default.css | 0 i2p2www/static/styles/dark/mobile.css | 0 i2p2www/static/styles/light/default.css | 0 i2p2www/static/styles/light/mobile.css | 0 6 files changed, 0 insertions(+), 0 deletions(-) create mode 100644 i2p2www/static/styles/danimoth/default.css create mode 100644 i2p2www/static/styles/danimoth/mobile.css create mode 100644 i2p2www/static/styles/dark/default.css create mode 100644 i2p2www/static/styles/dark/mobile.css create mode 100644 i2p2www/static/styles/light/default.css create mode 100644 i2p2www/static/styles/light/mobile.css diff --git a/i2p2www/static/styles/danimoth/default.css b/i2p2www/static/styles/danimoth/default.css new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/static/styles/danimoth/mobile.css b/i2p2www/static/styles/danimoth/mobile.css new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/static/styles/dark/default.css b/i2p2www/static/styles/dark/default.css new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/static/styles/dark/mobile.css b/i2p2www/static/styles/dark/mobile.css new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/static/styles/light/default.css b/i2p2www/static/styles/light/default.css new file mode 100644 index 00000000..e69de29b diff --git a/i2p2www/static/styles/light/mobile.css b/i2p2www/static/styles/light/mobile.css new file mode 100644 index 00000000..e69de29b From 05df4171d68339d11f710ffb1c08a95baf176b49 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 31 Jan 2013 03:20:24 +0000 Subject: [PATCH 365/498] Fixed URLs in docs/how/intro --- i2p2www/pages/site/docs/how/intro.html | 32 +++++++++++++------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html index 200a2281..a9374630 100644 --- a/i2p2www/pages/site/docs/how/intro.html +++ b/i2p2www/pages/site/docs/how/intro.html @@ -25,7 +25,7 @@ is quite likely that any outbound proxies to the normal Internet will be monitor even taken over to attempt more malicious attacks. {%- endtrans %}

    -

    {% trans i2ptunnel=site_url('docs/applications/i2ptunnel') -%} +

    {% trans i2ptunnel=site_url('docs/api/i2ptunnel') -%} The network itself is message oriented - it is essentially a secure and anonymous IP layer, where messages are addressed to cryptographic keys (Destinations) and can be significantly larger than IP packets. Some example uses of the network include "eepsites" (webservers hosting normal web @@ -37,7 +37,7 @@ of the I2P enabled applications, or perhaps as a little controller app to turn o proxies to enable the anonymizing functionality. {%- endtrans %}

    -

    {% trans threatmodel=site_url('docs/how/threatmodel') -%} +

    {% trans threatmodel=site_url('docs/how/threat-model') -%} An essential part of designing, developing, and testing an anonymizing network is to define the threat model, since there is no such thing as "true" anonymity, just increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to @@ -49,16 +49,16 @@ from the others. {%- endtrans %}

    {% trans %}Why?{% endtrans %}

    -

    {% trans networkcomparisons=site_url('docs/how/networkcomparisons') -%} +

    {% trans comparisons=site_url('comparison') -%} There are a multitude of reasons why we need a system to support anonymous communication, and -everyone has their own personal rationale. There are many other +everyone has their own personal rationale. There are many other efforts working on finding ways to provide varying degrees of anonymity to people through the Internet, but we could not find any that met our needs or threat model. {%- endtrans %}

    {% trans %}How?{% endtrans %}

    -

    {% trans tunnelrouting=site_url('docs/how/tunnelrouting'), netdb=site_url('docs/how/networkdatabase') -%} +

    {% trans tunnelrouting=site_url('docs/how/tunnel-routing'), netdb=site_url('docs/how/network-database') -%} The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional inbound and outbound virtual paths ("tunnels", as outlined on the tunnel routing page). Each router is identified by a cryptographic RouterIdentity which is @@ -85,7 +85,7 @@ to those tunnels on the correct router by querying the network database, which i as new leases are authorized and old ones expire. {%- endtrans %}

    -

    {% trans garlicrouting=site_url('docs/how/garlicrouting') -%} +

    {% trans garlicrouting=site_url('docs/how/garlic-routing') -%} If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things easier, most messages sent between Alice and Bob are garlic @@ -93,7 +93,7 @@ wrapped, bundling the sender's own current lease information so that the recipie immediately without having to look in the network database for the current data. {%- endtrans %}

    -

    {% trans peerselection=site_url('docs/how/peerselection') -%} +

    {% trans peerselection=site_url('docs/how/peer-selection') -%} To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and hence there are no directory servers keeping statistics regarding the performance and reliability of routers within the network. As such, each router must keep and maintain profiles of various routers @@ -102,7 +102,7 @@ reliability needs of the users, as described in the 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 @@ -128,7 +128,7 @@ applications running atop of I2P.

    {% trans %}End to end layered encryption{% endtrans %}
    -

    {% trans crypto=site_url('docs/how/cryptography') -%} +

    {% trans cryptography=site_url('docs/how/cryptography') -%} The specific use of these algorithms are outlined elsewhere. {%- endtrans %}

    @@ -141,7 +141,7 @@ people to set up and operate behind restricted routes (perhaps with trusted peer deployment of more flexible and anonymous transports. {%- endtrans %}

    -

    {% trans netdb=site_url('docs/how/networkdatabase') -%} +

    {% trans netdb=site_url('docs/how/network-database') -%} Some questions have been raised with regards to the scalability of I2P, and reasonably so. There will certainly be more analysis over time, but peer lookup and integration should be bounded by O(log(N)) due to the network database's algorithm, while end @@ -151,7 +151,7 @@ the network (N) bears no impact. {%- endtrans %}

    {% trans %}When?{% endtrans %}

    -

    {% trans roadmap=site_url('volunteer/roadmap') -%} +

    {% trans roadmap=site_url('get-involved/roadmap') -%} I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate transports, such as JMS, then grew into its own as an @@ -161,7 +161,7 @@ starting in August '03. I2P is currently under development, following the

    {% trans %}Who?{% endtrans %}

    -

    {% trans team=site_url('team') -%} +

    {% trans team=site_url('about/team') -%} We have a small team spread around several continents, working to advance different aspects of the project. We are very open to other developers who want to get involved and anyone else who would like to contribute in other ways, such as critiques, peer review, testing, @@ -173,19 +173,19 @@ on Sun Java SE and other Java Virtual Machines {%- endtrans %}

    {% trans %}Where?{% endtrans %}

    -

    {% trans meetings=url_for('meetings_index', lang=g.lang) -%} +

    {% trans meetings=get_url('meetings_index') -%} Anyone interested should join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de). There are currently no scheduled development meetings, however archives are available. {%- endtrans %}

    -

    {% trans monotone=site_url('develop/monotone') -%} +

    {% trans monotone=site_url('get-involved/guides/monotone') -%} The current source is available in monotone. {%- endtrans %}

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

    -

    {% trans how_index=site_url('docs/how') -%} -See the Index to Technical Documentation. +

    {% trans docs=site_url('docs') -%} +See the Index to Technical Documentation. {%- endtrans %}

    {% endblock %} From 5c112cc5cb53947e8614e55b8732d9536ad1037a Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 31 Jan 2013 03:21:08 +0000 Subject: [PATCH 366/498] Added translation tags to docs/how/cryptography --- i2p2www/pages/site/docs/how/cryptography.html | 346 ++++++++++-------- 1 file changed, 195 insertions(+), 151 deletions(-) diff --git a/i2p2www/pages/site/docs/how/cryptography.html b/i2p2www/pages/site/docs/how/cryptography.html index 02bbf107..93b2e2c0 100644 --- a/i2p2www/pages/site/docs/how/cryptography.html +++ b/i2p2www/pages/site/docs/how/cryptography.html @@ -1,45 +1,53 @@ {% extends "global/layout.html" %} -{% block title %}Low-level Cryptography Details{% endblock %} -{% block lastupdated %}March 2012{% endblock %} +{% block title %}{% trans %}Low-level Cryptography Details{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.8.13{% endblock %} {% block content %} -

    +

    {% trans -%} This page specifies the low-level details of the cryptography in I2P. -

    +{%- endtrans %}

    + +

    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%} There are a handful of cryptographic algorithms in use within I2P, but we have reduced them to a bare minimum to deal with our needs - one symmetric algorithm one asymmetric algorithm, one signing algorithm, and one hashing algorithm. However, we do combine them in some particular ways to provide message integrity (rather than relying on a MAC). In addition, as much as we hate doing anything new in regards to cryptography, we can't seem to find a reference discussing (or even naming) the -technique used in ElGamal/AES+SessionTag (but we're sure others have done it). -

    -

    ElGamal encryption

    +technique used in ElGamal/AES+SessionTag (but we're sure others have done it). +{%- endtrans %}

    -

    +

    {% trans %}ElGamal encryption{% endtrans %}

    + +

    {% trans %} ElGamal is used for asymmetric encryption. ElGamal is used in several places in I2P: -

    -

    +

    {% trans -%} We use common primes for 2048 ElGamal encryption and decryption, as given by IETF RFC-3526. We currently only use ElGamal to encrypt the IV and session key in a single block, followed by the AES encrypted payload using that key and IV. -

    +{%- endtrans %}

    + +

    {% trans -%} The unencrypted ElGamal contains: -

    -

    -

    +{%- endtrans %}

    +
        +----+----+----+----+----+----+----+----+
        |nonz|           H(data)                |
        +----+                                  +
    @@ -52,8 +60,8 @@ The unencrypted ElGamal contains:
        |    |  data...
        +----+----+----+--//                   
     
    -
    -

    +

    +

    {% trans -%} The H(data) is the SHA256 of the data that is encrypted in the ElGamal block, and is preceded by a nonzero byte. This byte could be random, but as implemented it is always 0xFF. @@ -63,11 +71,13 @@ As the encrypted data may contain a substantial number of zeros if the cleartext is smaller than 222 bytes, it is recommended that higher layers pad the cleartext to 222 bytes with random data. Total length: typically 255 bytes. -

    +{%- endtrans %}

    + +

    {% trans -%} The encrypted ElGamal contains: +{%- endtrans %}

    -

    -

    +
        +----+----+----+----+----+----+----+----+
        |  zero padding...       |              |
        +----+----+----+--// ----+              +
    @@ -88,25 +98,31 @@ The encrypted ElGamal contains:
        |         +
        +----+----+
     
    -
    +
    +

    {% trans -%} Each encrypted part is prepended with zeros to a size of exactly 257 bytes. Total length: 514 bytes. In typical usage, higher layers pad the cleartext data to 222 bytes, resulting in an unencrypted block of 255 bytes. This is encoded as two 256-byte encrypted parts, and there is a single byte of zero padding before each part at this layer. -

    -See -the ElGamal code. -

    -The shared prime is the +{%- endtrans %}

    +

    {% trans url='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/ElGamalEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%} +See the ElGamal code. +{%- endtrans %}

    + +

    {% trans -%} +The shared prime is the [Oakley prime for 2048 bit keys] -

    +{%- endtrans %}

    +
      2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
    -
    +
    +

    {% trans -%} or as a hexadecimal value: -

    +{%- endtrans %}

    +
      FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
      29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
      EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
    @@ -118,64 +134,79 @@ or as a hexadecimal value:
      E39E772C 180E8603 9B2783A2 EC07A28F B5C55DF0 6F4C52C9
      DE2BCBF6 95581718 3995497C EA956AE5 15D22618 98FA0510
      15728E5A 8AACAA68 FFFFFFFF FFFFFFFF
    -
    -

    +

    +

    {% trans -%} Using 2 as the generator. -

    Short Exponent

    +{%- endtrans %}

    + +

    {% trans %}Short Exponent{% endtrans %}

    +

    {% trans commonstructures=site_url('docs/spec/common-structures'), +pdf='http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&rep=rep1&type=pdf', +benchmarks=site_url('misc/benchmarks') -%} While the standard exponent size is 2048 bits (256 bytes) and the I2P -PrivateKey +PrivateKey is a full 256 bytes, we use the short exponent size of 226 bits (28.25 bytes). -This should be safe for use with the Oakley primes, -per - -On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner -at EuroCrypt 96, and -crypto++'s benchmarks. +This should be safe for use with the Oakley primes, per +On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner +at EuroCrypt 96, and crypto++'s benchmarks. Benchmarks originally at this link, now dead, rescued from the wayback machine, dated Apr 23, 2008. -

    -Also, - -Koshiba & Kurosawa: Short Exponent Diffie-Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186) - -(full text on google books) -apparently supports this, according to -this sci.crypt thread. -The remainder of the PrivateKey is padded with zeroes. +{%- endtrans %}

    -

    Obsolescence

    -

    +

    {% trans book='http://www.springerlink.com/content/2jry7cftp5bpdghm/', +fulltext='http://books.google.com/books?id=cXyiNZ2_Pa0C&lpg=PA173&ots=PNIz3dWe4g&pg=PA173#v=onepage&q&f=false', +thread='http://groups.google.com/group/sci.crypt/browse_thread/thread/1855a5efa7416677/339fa2f945cc9ba0#339fa2f945cc9ba0' -%} +Also, Koshiba & Kurosawa: Short Exponent Diffie-Hellman Problems (PKC 2004, LNCS 2947, pp. 173-186) +(full text on Google Books) apparently supports this, according to +this sci.crypt thread. +The remainder of the PrivateKey is padded with zeroes. +{%- endtrans %}

    + +

    {% trans %}Obsolescence{% endtrans %}

    +

    {% trans -%} The vulnerability of the network to an ElGamal attack and the impact of transitioning to a longer bit length is to be studied. It may be quite difficult to make any change backward-compatible. -

    +{%- endtrans %}

    -

    AES

    +

    AES

    -

    +

    {% trans -%} AES is used for symmetric encryption, in several cases: -

    + +

    {% trans rfc2313='http://tools.ietf.org/html/rfc2313', +code1='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/CryptixAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4', +code2='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/CryptixRijndael_Algorithm.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4', +code3='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/ElGamalAESEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%} We use AES with 256 bit keys and 128 bit blocks in CBC mode. -The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)). +The padding used is specified in IETF RFC-2313 (PKCS#5 1.5, section 8.1 (for block type 02)). In this case, padding exists of pseudorandomly generated octets to match 16 byte blocks. -Specifically, see -[the CBC code] -and the Cryptix AES -[implementation], -as well as the padding, found in the -ElGamalAESEngine.getPadding function. +Specifically, see [the CBC code] and the Cryptix AES +[implementation], as well as the padding, found in the +ElGamalAESEngine.getPadding function. +{%- endtrans %}

    -

    Obsolescence

    -

    +

    {% trans %}Obsolescence{% endtrans %}

    +

    {% trans -%} The vulnerability of the network to an AES attack and the impact of transitioning to a longer bit length is to be studied. It may be quite difficult to make any change backward-compatible. -

    +{%- endtrans %}

    -

    References

    +

    {% trans %}References{% endtrans %}

    -

    DSA

    +

    DSA

    -

    +

    {% trans code='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/DSAEngine.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%} Signatures are generated and verified with 1024 bit DSA (L=1024, N=160), as implemented in -[DSAEngine]. +[DSAEngine]. DSA was chosen because it is much faster for signatures than ElGamal. -

    -

    The DSA constants

    +{%- endtrans %}

    -

    +

    {% trans %}The DSA constants{% endtrans %}

    -

    SEED

    +

    SEED

    160 bit

    -
    +
      86108236b8526e296e923a4015b4282845b572cc
    -
    -

    Counter

    +
    -
    +

    Counter

    + +
      33
    -
    +

    DSA prime (p)

    1024 bit

    -

    +
      9C05B2AA 960D9B97 B8931963 C9CC9E8C 3026E9B8 ED92FAD0
      A69CC886 D5BF8015 FCADAE31 A0AD18FA B3F01B00 A358DE23
      7655C496 4AFAA2B3 37E96AD3 16B9FB1C C564B5AE C5B69A9F
      F6C3E454 8707FEF8 503D91DD 8602E867 E6D35D22 35C1869C
      E2479C3B 9D5401DE 04E0727F B33D6511 285D4CF2 9538D9E3
      B6051F5B 22CC1C93
    -
    +

    DSA quotient (q)

    -

    +
      A5DFC28F EF4CA1E2 86744CD8 EED9D29D 684046B7
    -
    +

    DSA generator (g)

    1024 bit

    -

    +
      C1F4D27D 40093B42 9E962D72 23824E0B BC47E7C8 32A39236
      FC683AF8 48895810 75FF9082 ED32353D 4374D730 1CDA1D23
      C431F469 8599DDA0 2451824F F3697525 93647CC3 DDC197DE
      985E43D1 36CDCFC6 BD5409CD 2F450821 142A5E6F 8EB1C3AB
      5D0484B8 129FCF17 BCE4F7F3 3321C3CB 3DBB14A9 05E7B2B3
      E93BE470 8CBCC82
    -
    +
    -

    -The Signing Public Key is 1024 bits. -The Signing Private Key is 160 bits. -

    +

    {% trans commonstructures=site_url('docs/spec/common-structures') -%} +The Signing Public Key is 1024 bits. +The Signing Private Key is 160 bits. +{%- endtrans %}

    -

    Obsolescence

    -

    -NIST 800-57 +

    {% trans %}Obsolescence{% endtrans %}

    +

    {% trans pdf='http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf' -%} +NIST 800-57 recommends a minimum of (L=2048, N=224) for usage beyond 2010. This may be mitigated somewhat by the "cryptoperiod", or lifespan of a given key. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} The prime number was chosen in 2003, and the person that chose the number (TheCrypto) is currently no longer an I2P developer. As such, we do not know if the prime chosen is a 'strong prime'. If a larger prime is chosen for future purposes, this should be a strong prime, and we will document the construction process. -

    -

    +{%- endtrans %}

    + +

    {% trans -%} The vulnerability of the network to a DSA attack and the impact of transitioning to longer keys is to be studied. It may be quite difficult to make any change backward-compatible. -

    +{%- endtrans %}

    -

    References

    +

    {% trans %}References{% endtrans %}

    @@ -339,25 +373,25 @@ It may be quite difficult to make any change backward-compatible.

    SHA256

    -

    +

    {% trans code='http://'+i2pconv('trac.i2p2.i2p')+'/browser/core/java/src/net/i2p/crypto/SHA256Generator.java?rev=85a542c53d910dffbf34cdcefb8a2faeee96adc4' -%} Hashes within I2P are plain old SHA256, as implemented in -[SHA256Generator] +[SHA256Generator] +{%- endtrans %}

    - -

    Obsolescence

    -

    +

    {% trans %}Obsolescence{% endtrans %}

    +

    {% trans -%} The vulnerability of the network to a SHA-256 attack and the impact of transitioning to a longer hash is to be studied. It may be quite difficult to make any change backward-compatible. -

    +{%- endtrans %}

    -

    References

    +

    {% trans %}References{% endtrans %}

    -

    Transports

    -

    +

    {% trans %}Transports{% endtrans %}

    +

    {% trans -%} At the lowest protocol layer, point-to-point inter-router communication is protected by the transport layer security. Both transports use 256 byte (2048 bit) Diffie-Hellman key exchange @@ -367,52 +401,62 @@ followed by symmetric AES encryption as described above. This provides perfect forward secrecy on the transport links. -

    +{%- endtrans %}

    -

    NTCP connections

    +

    {% trans %}NTCP connections{% endtrans %}

    -

    +

    {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%} NTCP connections are negotiated with a 2048 Diffie-Hellman implementation, using the router's identity to proceed with a station to station agreement, followed by some encrypted protocol specific fields, with all subsequent data encrypted with AES (as above). -The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not. -

    -

    +The primary reason to do the DH negotiation instead of using ElGamalAES+SessionTag is that it provides '(perfect) forward secrecy', while ElGamalAES+SessionTag does not. +{%- endtrans %}

    + +

    {% trans -%} In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed: -

    -

      -
    1. can we somehow reestablish sessions securely (ala session tags) or do we need to do full negotiation each time? -
    2. can we simplify/avoid the x509 or other certificate formats and use our own RouterInfo structure (which - contains the ElGamal and DSA keys)? - -
    -

    -See the NTCP specification for details. - -

    UDP connections

    +{%- endtrans %}

    +
      +
    1. {% trans -%} +Can we somehow reestablish sessions securely (ala session tags) or do we need to do full negotiation each time? +{%- endtrans %}
    2. +
    3. {% trans -%} +Can we simplify/avoid the x509 or other certificate formats and use our own RouterInfo structure (which +contains the ElGamal and DSA keys)? +{%- endtrans %}
    4. +
    +

    {% trans ntcp=site_url('docs/transport/ntcp') -%} +See the NTCP specification for details. +{%- endtrans %}

    +

    {% trans %}UDP connections{% endtrans %}

    +

    {% trans -%} SSU (the UDP transport) encrypts each packet with AES256/CBC with both an explicit IV and MAC (HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048 bit Diffie-Hellman exchange, station-to-station authentication with the other router's DSA key, plus each network message has their own hash for local integrity checking. -

    -See the SSU specification for details. -

    +{%- endtrans %}

    + +

    {% trans ssu=site_url('docs/transport/ssu') -%} +See the SSU specification for details. +{%- endtrans %}

    + +

    {% trans statusnotes=get_url('blog_post', slug='2005/07/05/status') -%} WARNING - I2P's HMAC-MD5-128 used in SSU is apparently non-standard. Apparently, an early version of SSU used HMAC-SHA256, and then it was switched to MD5-128 for performance reasons, but left the 32-byte buffer size intact. See HMACGenerator.java and -the 2005-07-05 status notes +the 2005-07-05 status notes for details. +{%- endtrans %}

    -

    References

    +

    {% trans %}References{% endtrans %}

    - {% endblock %} From dc6608837506efc7cc21b227f305aec02eaa8266 Mon Sep 17 00:00:00 2001 From: str4d Date: Thu, 31 Jan 2013 11:40:21 +0000 Subject: [PATCH 367/498] Added translation tags to docs/how/threat-model --- i2p2www/pages/site/docs/how/threat-model.html | 857 +++++++++++------- 1 file changed, 506 insertions(+), 351 deletions(-) diff --git a/i2p2www/pages/site/docs/how/threat-model.html b/i2p2www/pages/site/docs/how/threat-model.html index 5ab111bf..09d3c402 100644 --- a/i2p2www/pages/site/docs/how/threat-model.html +++ b/i2p2www/pages/site/docs/how/threat-model.html @@ -1,65 +1,82 @@ {% extends "global/layout.html" %} -{% block title %}I2P's Threat Model{% endblock %} -{% block lastupdated %}November 2010{% endblock %} +{% block title %}{% trans %}I2P's Threat Model{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}November 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8.1{% endblock %} {% block content %} -

    What do we mean by "anonymous"?

    +

    {% trans %}What do we mean by "anonymous"?{% endtrans %}

    -

    Your level of anonymity can be described as "how hard it is for someone +

    {% trans -%} +Your level of anonymity can be described as "how hard it is for someone to find out information you don't want them to know?" - who you are, where you are located, who you communicate with, or even when you communicate. "Perfect" anonymity is not a useful concept here - software will not make you indistinguishable from people that don't use computers or who are not on the Internet. Instead, we are working to provide sufficient anonymity to meet the real needs of whomever we can - from those simply browsing websites, to those exchanging -data, to those fearful of discovery by powerful organizations or states.

    +data, to those fearful of discovery by powerful organizations or states. +{%- endtrans %}

    -

    The question of whether I2P provides sufficient anonymity for your +

    {% trans -%} +The question of whether I2P provides sufficient anonymity for your particular needs is a hard one, but this page will hopefully assist in answering that question by exploring how I2P operates under various attacks -so that you may decide whether it meets your needs.

    +so that you may decide whether it meets your needs. +{%- endtrans %}

    -

    We welcome further research and analysis on I2P's resistance to the threats described below. +

    {% trans -%} +We welcome further research and analysis on I2P's resistance to the threats described below. More review of existing literature (much of it focused on Tor) and original -work focused on I2P is needed.

    +work focused on I2P is needed. +{%- endtrans %}

    -

    Network Topology Summary

    -

    I2P builds off the ideas of many other -systems, but a few key points should be kept in mind when -reviewing related literature:

      -
    • I2P is a free route mixnet - the message creator explicitly defines the - path that messages will be sent out (the outbound tunnel), and the message - recipient explicitly defines the path that messages will be received on (the - inbound tunnel). -
    • -
    • I2P has no official entry and exit points - all peers fully participate in the - mix, and there are no network layer in- or out-proxies (however, at the - application layer, a few proxies do exist)
    • -
    • I2P is fully distributed - there are no central controls or authorities. - One could modify some routers to operate mix cascades (building tunnels and giving - out the keys necessary to control the forwarding at the tunnel endpoint) or directory - based profiling and selection, all without breaking compatibility with the rest of - the network, but doing so is of course not necessary (and may even harm one's - anonymity).
    • +

      {% trans %}Network Topology Summary{% endtrans %}

      +

      {% trans comparisons=site_url('comparison'), links=site_url('links') -%} +I2P builds off the ideas of many other +systems, but a few key points should be kept in mind when +reviewing related literature: +{%- endtrans %}

      +
        +
      • {% trans -%} +I2P is a free route mixnet - the message creator explicitly defines the +path that messages will be sent out (the outbound tunnel), and the message +recipient explicitly defines the path that messages will be received on (the +inbound tunnel). +{%- endtrans %}
      • +
      • {% trans -%} +I2P has no official entry and exit points - all peers fully participate in the +mix, and there are no network layer in- or out-proxies (however, at the +application layer, a few proxies do exist) +{%- endtrans %}
      • +
      • {% trans -%} +I2P is fully distributed - there are no central controls or authorities. +One could modify some routers to operate mix cascades (building tunnels and giving +out the keys necessary to control the forwarding at the tunnel endpoint) or directory +based profiling and selection, all without breaking compatibility with the rest of +the network, but doing so is of course not necessary (and may even harm one's +anonymity). +{%- endtrans %}
      -

      - We have documented plans to implement - nontrivial delays and batching strategies - whose existence is only known to the particular hop or tunnel gateway that - receives the message, allowing a mostly low latency mixnet to provide cover - traffic for higher latency communication (e.g. email). - However we are aware that significant delays are required to provide meaningful - protection, and that implementation of such delays will be a significant challenge. - It is not clear at this time whether we will actually implement these delay features. -

      - In theory, routers along the message path may inject an - arbitrary number of hops before forwarding the message to the next peer, though - the current implementation does not. -

      + +

      {% trans todo=site_url('get-involved/todo') -%} +We have documented plans to implement nontrivial delays +and batching strategies +whose existence is only known to the particular hop or tunnel gateway that +receives the message, allowing a mostly low latency mixnet to provide cover +traffic for higher latency communication (e.g. email). +However we are aware that significant delays are required to provide meaningful +protection, and that implementation of such delays will be a significant challenge. +It is not clear at this time whether we will actually implement these delay features. +{%- endtrans %}

      + +

      {% trans -%} +In theory, routers along the message path may inject an +arbitrary number of hops before forwarding the message to the next peer, though +the current implementation does not. +{%- endtrans %}

      -

      The Threat Model (Attacks)

      -

      +

      {% trans %}The Threat Model (Attacks){% endtrans %}

      +

      {% trans -%} I2P design started in 2003, not long after the advent of [Onion Routing], [Freenet], and @@ -67,18 +84,24 @@ I2P design started in 2003, not long after the advent of Our design benefits substantially from the research published around that time. I2P uses several onion routing techniques, so we continue to benefit from the significant academic interest in Tor. -

      +{%- endtrans %}

      + +

      {% trans -%} Taking from the attacks and analysis put forth in the anonymity literature (largely Traffic Analysis: Protocols, Attacks, Design Issues and Open Problems), the following briefly describes a wide variety of attacks as well as many of I2Ps defenses. We update this list to include new attacks as they are identified. -

      +{%- endtrans %}

      + +

      {% trans -%} Included are some attacks that may be unique to I2P. We do not have good answers for all these attacks, however we continue to do research and improve our defenses. -

      +{%- endtrans %}

      + +

      {% trans -%} In addition, many of these attacks are significantly easier than they should be, due to the modest size of the current network. While we are aware of some limitations that need to be addressed, @@ -86,38 +109,41 @@ I2P is designed to support hundreds of thousands, or millions, of participants. As we continue to spread the word and grow the network, these attacks will become much harder. -

      -The -network comparisons and -"garlic" terminology pages may also be helpful -to review. -

      +{%- endtrans %}

      -

      Index

      +

      {% trans comparisons=site_url('comparison'), garlicrouting=site_url('docs/how/garlic-routing') -%} +The +network comparisons and +"garlic" terminology pages may also be helpful +to review. +{%- endtrans %}

      + +

      {% trans %}Index{% endtrans %}

      -

      Brute force attacks

      +

      {% trans %}Brute force attacks{% endtrans %}

      -

      A brute force attack can be mounted by a global passive or active adversary, +

      {% trans -%} +A brute force attack can be mounted by a global passive or active adversary, watching all the messages pass between all of the nodes and attempting to correlate which message follows which path. Mounting this attack against I2P should be nontrivial, as all peers in the network are frequently sending messages (both @@ -125,9 +151,11 @@ end to end and network maintenance messages), plus an end to end message changes size and data along its path. In addition, the external adversary does not have access to the messages either, as inter-router communication is both encrypted and streamed (making two 1024 byte messages indistinguishable from one 2048 byte -message).

      +message). +{%- endtrans %}

      -

      However, a powerful attacker can use brute force to detect trends - if they +

      {% trans -%} +However, a powerful attacker can use brute force to detect trends - if they can send 5GB to an I2P destination and monitor everyone's network connection, they can eliminate all peers who did not receive 5GB of data. Techniques to defeat this attack exist, but may be prohibitively expensive (see: @@ -141,193 +169,238 @@ would want to take appropriate countermeasures, such as setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites. Other countermeasures, such as nontrivial delays and restricted routes, are not currently implemented. -

      +{%- endtrans %}

      + +

      {% trans peerselection=site_url('docs/how/peer-selection') -%} As a partial defense against a single router or group of routers trying to route all the network's traffic, routers contain limits as to how many tunnels can be routed through a single peer. As the network grows, these limits are subject to further adjustment. Other mechanisms for peer rating, selection and avoidance are discussed on the -peer selection page. -

      +peer selection page. +{%- endtrans %}

      -

      Timing attacks

      +

      {% trans %}Timing attacks{% endtrans %}

      -

      I2P's messages are unidirectional and do not necessarily imply that a reply +

      {% trans -%} +I2P's messages are unidirectional and do not necessarily imply that a reply will be sent. However, applications on top of I2P will most likely have recognizable patterns within the frequency of their messages - for instance, an HTTP request will be a small message with a large sequence of reply messages containing the HTTP response. Using this data as well as a broad view of the network topology, an attacker may be able to disqualify some links as being too -slow to have passed the message along.

      +slow to have passed the message along. +{%- endtrans %}

      -

      This sort of attack is powerful, but its applicability to I2P is non obvious, +

      {% trans -%} +This sort of attack is powerful, but its applicability to I2P is non obvious, as the variation on message delays due to queuing, message processing, and throttling will often meet or exceed the time of passing a message along a single link - even when the attacker knows that a reply will be sent as soon as the message is received. There are some scenarios which will expose fairly automatic replies though - the streaming library does (with the SYN+ACK) as does the -message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).

      +message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage). +{%- endtrans %}

      -

      Without protocol scrubbing or higher latency, global active adversaries can +

      {% trans todo=site_url('get-involved/todo') -%} +Without protocol scrubbing or higher latency, global active adversaries can gain substantial information. As such, people concerned with these attacks could -increase the latency (using nontrivial delays or -batching strategies), include protocol scrubbing, or -other advanced tunnel routing techniques, +increase the latency (using nontrivial delays or +batching strategies), include protocol scrubbing, or +other advanced tunnel routing techniques, but these are unimplemented in I2P. -

      +{%- endtrans %}

      -

      References: -Low-Resource Routing Attacks Against Anonymous Systems -

      +

      {% trans pdf='http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf' -%} +References: Low-Resource Routing Attacks Against Anonymous Systems +{%- endtrans %}

      -

      Intersection attacks

      +

      {% trans %}Intersection attacks{% endtrans %}

      -

      Intersection attacks against low latency systems are extremely powerful - +

      {% trans -%} +Intersection attacks against low latency systems are extremely powerful - periodically make contact with the target and keep track of what peers are on the network. Over time, as node churn occurs the attacker will gain significant information about the target by simply intersecting the sets of peers that are online when a message successfully goes through. The cost of this attack is significant as the network grows, but may be feasible in some -scenarios.

      - -

      +scenarios. +{%- endtrans %}

      + +

      {% trans url='https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting' -%} In summary, if an attacker is at both ends of your tunnel at the same time, he may be successful. I2P does not have a full defense to this for low latency communication. This is an inherent weakness of low-latency onion routing. -Tor provides a similar disclaimer. -

      +Tor provides a similar disclaimer. +{%- endtrans %}

      + +

      {% trans -%} Partial defenses implemented in I2P: -

      • -strict ordering of peers -
      • -peer profiling and selection from a small group that changes slowly -
      • +{%- endtrans %}

        +
          +
        • {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%} +strict ordering of peers +{%- endtrans %}
        • +
        • {% trans peerselection=site_url('docs/how/peer-selection') -%} +peer profiling and selection from a small group that changes slowly +{%- endtrans %}
        • +
        • {% trans -%} Limits on the number of tunnels routed through a single peer -
        • +{%- endtrans %}
        • +
        • {% trans -%} Prevention of peers from the same /16 IP range from being members of a single tunnel -
        • +{%- endtrans %}
        • +
        • {% trans -%} For eepsites or other hosted services, we support simultaneous hosting on multiple routers, or -multihoming -
        +multihoming +{%- endtrans %}
      • +
      +

      {% trans -%} Even in total, these defenses are not a complete solution. Also, we have made some design choices that may significantly increase our vulnerability: -

      • +{%- endtrans %}

        +
          +
        • {% trans -%} We do not use low-bandwidth "guard nodes" -
        • +{%- endtrans %}
        • +
        • {% trans -%} We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel. -
        • +{%- endtrans %}
        • +
        • {% trans -%} Tunnels are not long-lived; new tunnels are built every 10 minutes. -
        • +{%- endtrans %}
        • +
        • {% trans -%} Tunnel lengths are configurable. While 3-hop tunnels are recommended for full protection, several applications and services use 2-hop tunnels by default. -
        +{%- endtrans %}
      • +
      - -

      +

      {% trans todo=site_url('get-involved/todo') -%} In the future, it could -for peers who can afford significant delays (per nontrivial -delays and batching strategies). In addition, +for peers who can afford significant delays (per nontrivial +delays and batching strategies). In addition, this is only relevant for destinations that other people know about - a private group whose destination is only known to trusted peers does not have to worry, as an adversary can't "ping" them to mount the attack.

      +{%- endtrans %}

      -

      Reference: -One Cell Enough -

      +

      {% trans oce='http://blog.torproject.org/blog/one-cell-enough' -%} +Reference: One Cell Enough +{%- endtrans %}

      +

      {% trans %}Denial of service attacks{% endtrans %}

      -

      Denial of service attacks

      - -

      There are a whole slew of denial of service attacks available against I2P, -each with different costs and consequences:

        -
      • Greedy user attack: This is simply - people trying to consume significantly more resources than they are - willing to contribute. The defense against this is:
          -
        • Set defaults so that most users provide resources to the network. - In I2P, users route traffic by default. In sharp distinction to - other networks, - over 95% of I2P users relay traffic for others. -
        • -
        • Provide easy configuration options so that users may increase their - contribution (share percentage) to the network. Display easy-to-understand - metrics such as "share ratio" so that users may see what they are contributing. -
        • - Maintain a strong community with blogs, forums, IRC, and other means of communication. -
        -
      • Starvation attack: A hostile user may attempt to harm the network by - creating a significant number of peers in the network who are not identified as - being under control of the same entity (as with Sybil). These nodes then - decide not to provide any resources to the network, causing existing peers - to search through a larger network database or request more tunnels than - should be necessary. - Alternatively, the nodes may provide intermittent service by periodically - dropping selected traffic, or refusing connections to certain peers. - This behavior may be indistinguishable from that of a heavily-loaded or failing node. - I2P addresses these issues by maintaining profiles on the - peers, attempting to identify underperforming ones and simply ignoring - them, or using them rarely. - We have significantly enhanced the - ability to recognize and avoid troublesome peers; however there are still - significant efforts required in this area. -
      • -
      • Flooding attack: A hostile user may attempt to flood the network, - a peer, a destination, or a tunnel. Network and peer flooding is possible, - and I2P does nothing to prevent standard IP layer flooding. The flooding of - a destination with messages by sending a large number to the target's various - inbound tunnel gateways is possible, but the destination will know this both - by the contents of the message and because the tunnel's tests will fail. The - same goes for flooding just a single tunnel. I2P has no defenses for a network - flooding attack. For a destination and tunnel flooding attack, the target - identifies which tunnels are unresponsive and builds new ones. New code could - also be written to add even more tunnels if the client wishes to handle the - larger load. If, on the other hand, the load is more than the client can - deal with, they can instruct the tunnels to throttle the number of messages or - bytes they should pass on (once the advanced tunnel - operation is implemented).
      • -
      • CPU load attack: There are currently some methods for people to - remotely request that a peer perform some cryptographically expensive - operation, and a hostile attacker could use these to flood that peer with - a large number of them in an attempt to overload the CPU. Both using good - engineering practices and potentially requiring nontrivial certificates - (e.g. HashCash) to be attached to these expensive requests should mitigate - the issue, though there may be room for an attacker to exploit various - bugs in the implementation.
      • -
      • Floodfill DOS attack: A hostile user may attempt to harm the network by - becoming a floodfill router. The current defenses against unreliable, - intermittent, or malicious floodfill routers are poor. - A floodfill router may provide bad or no response to lookups, and - it may also interfere with inter-floodfill communication. - Some defenses and - peer profiling are implemented, - however there is much more to do. - For more information see the - network database page. +

        {% trans -%} +There are a whole slew of denial of service attacks available against I2P, +each with different costs and consequences: +{%- endtrans %}

        +
          +
        • {% trans -%} +Greedy user attack: This is simply +people trying to consume significantly more resources than they are +willing to contribute. The defense against this is: +{%- endtrans %} +
            +
          • {% trans comparisons=site_url('comparison') -%} +Set defaults so that most users provide resources to the network. +In I2P, users route traffic by default. In sharp distinction to +other networks, +over 95% of I2P users relay traffic for others. +{%- endtrans %}
          • +
          • {% trans -%} +Provide easy configuration options so that users may increase their +contribution (share percentage) to the network. Display easy-to-understand +metrics such as "share ratio" so that users may see what they are contributing. +{%- endtrans %}
          • +
          • {% trans -%} +Maintain a strong community with blogs, forums, IRC, and other means of communication. +{%- endtrans %}
          • +
        • +
        • {% trans peerselection=site_url('docs/how/peer-selection') -%} +Starvation attack: A hostile user may attempt to harm the network by +creating a significant number of peers in the network who are not identified as +being under control of the same entity (as with Sybil). These nodes then +decide not to provide any resources to the network, causing existing peers +to search through a larger network database or request more tunnels than +should be necessary. +Alternatively, the nodes may provide intermittent service by periodically +dropping selected traffic, or refusing connections to certain peers. +This behavior may be indistinguishable from that of a heavily-loaded or failing node. +I2P addresses these issues by maintaining profiles on the +peers, attempting to identify underperforming ones and simply ignoring +them, or using them rarely. +We have significantly enhanced the +ability to recognize and avoid troublesome peers; however there are still +significant efforts required in this area. +{%- endtrans %}
        • +
        • {% trans todo=site_url('get-involved/todo') -%} +Flooding attack: A hostile user may attempt to flood the network, +a peer, a destination, or a tunnel. Network and peer flooding is possible, +and I2P does nothing to prevent standard IP layer flooding. The flooding of +a destination with messages by sending a large number to the target's various +inbound tunnel gateways is possible, but the destination will know this both +by the contents of the message and because the tunnel's tests will fail. The +same goes for flooding just a single tunnel. I2P has no defenses for a network +flooding attack. For a destination and tunnel flooding attack, the target +identifies which tunnels are unresponsive and builds new ones. New code could +also be written to add even more tunnels if the client wishes to handle the +larger load. If, on the other hand, the load is more than the client can +deal with, they can instruct the tunnels to throttle the number of messages or +bytes they should pass on (once the advanced tunnel +operation is implemented). +{%- endtrans %}
        • +
        • {% trans -%} +CPU load attack: There are currently some methods for people to +remotely request that a peer perform some cryptographically expensive +operation, and a hostile attacker could use these to flood that peer with +a large number of them in an attempt to overload the CPU. Both using good +engineering practices and potentially requiring nontrivial certificates +(e.g. HashCash) to be attached to these expensive requests should mitigate +the issue, though there may be room for an attacker to exploit various +bugs in the implementation. +{%- endtrans %}
        • +
        • {% trans peerselection=site_url('docs/how/peer-selection'), +netdb=site_url('docs/how/network-database') -%} +Floodfill DOS attack: A hostile user may attempt to harm the network by +becoming a floodfill router. The current defenses against unreliable, +intermittent, or malicious floodfill routers are poor. +A floodfill router may provide bad or no response to lookups, and +it may also interfere with inter-floodfill communication. +Some defenses and +peer profiling are implemented, +however there is much more to do. +For more information see the +network database page. +{%- endtrans %}
        -

        Tagging attacks

        -

        Tagging attacks - modifying a message so that it can later be identified +

        {% trans %}Tagging attacks{% endtrans %}

        +

        {% trans todo=site_url('get-involved/todo') -%} +Tagging attacks - modifying a message so that it can later be identified further along the path - are by themselves impossible in I2P, as messages passed through tunnels are signed. However, if an attacker is the inbound tunnel gateway as well as a participant further along in that tunnel, with collusion they can identify the fact that they are in the same tunnel (and -prior to adding unique hop ids and other updates, +prior to adding unique hop ids and other updates, colluding peers within the same tunnel can recognize that fact without any effort). An attacker in an outbound tunnel and any part of an inbound tunnel cannot collude however, as the tunnel encryption pads and modifies the data separately for the inbound and outbound tunnels. External attackers cannot do anything, -as the links are encrypted and messages signed.

        +as the links are encrypted and messages signed. +{%- endtrans %}

        -

        Partitioning attacks

        +

        {% trans %}Partitioning attacks{% endtrans %}

        -

        Partitioning attacks - finding ways to segregate (technically or analytically) +

        {% trans -%} +Partitioning attacks - finding ways to segregate (technically or analytically) the peers in a network - are important to keep in mind when dealing with a powerful adversary, since the size of the network plays a key role in determining your anonymity. Technical partitioning by cutting links between peers to create @@ -339,142 +412,177 @@ isolating the target, no amount of network database healing will fix it. At that point, the only thing the router can hope to do is notice that a significant number of previously reliable peers have become unavailable and alert the client that it is temporarily disconnected (this detection code is not implemented at -the moment).

        +the moment). +{%- endtrans %}

        -

        Partitioning the network analytically by looking for differences in how routers +

        {% trans todo=site_url('get-involved/todo') -%} +Partitioning the network analytically by looking for differences in how routers and destinations behave and grouping them accordingly is also a very powerful attack. For instance, an attacker harvesting the network database will know when a particular destination has 5 inbound tunnels in their LeaseSet while others have only 2 or 3, allowing the adversary to potentially partition clients by the number of tunnels selected. Another partition is -possible when dealing with the nontrivial delays and -batching strategies, as the tunnel gateways and the +possible when dealing with the nontrivial delays and +batching strategies, as the tunnel gateways and the particular hops with non-zero delays will likely stand out. However, this data is only exposed to those specific hops, so to partition effectively on that matter, the attacker would need to control a significant portion of the network (and still that would only be a probabilistic partition, as they wouldn't know which other tunnels or messages have those delays). -

        -Also discussed on the - network database page (bootstrap attack). -

        +{%- endtrans %}

        -

        Predecessor attacks

        +

        {% trans netdb=site_url('docs/how/networkdatabase') -%} +Also discussed on the network database page (bootstrap attack). +{%- endtrans %}

        -

        The predecessor attack is passively gathering statistics in an attempt to see +

        {% trans %}Predecessor attacks{% endtrans %}

        + +

        {% trans -%} +The predecessor attack is passively gathering statistics in an attempt to see what peers are 'close' to the destination by participating in their tunnels and keeping track of the previous or next hop (for outbound or inbound tunnels, respectively). Over time, using a perfectly random sample of peers and random ordering, an attacker would be able to see which peer shows up as 'closer' statistically more than the rest, and that peer would in turn be where the -target is located.

        +target is located. +{%- endtrans %}

        -

        I2P avoids this in four ways: first, the peers selected to participate in +

        {% trans peerselection=site_url('docs/how/peer-selection'), +tunnelimpl=site_url('docs/tunnels/implementation'), +todo=site_url('get-involved/todo') -%} +I2P avoids this in four ways: first, the peers selected to participate in tunnels are not randomly sampled throughout the network - they are derived from -the peer selection algorithm which breaks them -into tiers. Second, with strict ordering of peers +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 +the source. Third, with permuted tunnel length (not enabled by default) even 0 hop tunnels can provide plausible deniability as the occasional variation of the gateway will look like normal tunnels. Fourth, with -restricted routes (unimplemented), only the peer with +restricted routes (unimplemented), only the peer with a restricted connection to the target will ever contact the target, while attackers will merely run into that gateway. -

        -The current -tunnel build method +{%- endtrans %}

        + +

        {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%} +The current tunnel build method was specifically designed to combat the predecessor attack. See also the intersection attack. -

        +{%- endtrans %}

        -

        References: -http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf +

        {% trans pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf', +pdf2004='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf' -%} +References: {{ pdf2008 }} which is an update to the 2004 predecessor attack paper -http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf. -

        +{{ pdf2004 }}. +{%- endtrans %}

        -

        Harvesting attacks

        -

        +

        {% trans %}Harvesting attacks{% endtrans %}

        +

        {% trans -%} "Harvesting" means compiling a list of users running I2P. It can be used for legal attacks and to help other attacks by simply running a peer, seeing who it connects to, and harvesting whatever references to other peers it can find. -

        +{%- endtrans %}

        + +

        {% trans -%} I2P itself is not designed with effective defenses against this attack, since there is the distributed network database containing just this information. The following factors make the attack somewhat harder in practice: -

        • +{%- endtrans %}

          +
            +
          • {% trans -%} Network growth will make it more difficult to obtain a given proportion of the network -
          • +{%- endtrans %}
          • +
          • {% trans -%} Floodfill routers implement query limits as DOS protection -
          • +{%- endtrans %}
          • +
          • {% trans -%} "Hidden mode", which prevents a router from publishing its information to the netDb, (but also prevents it from relaying data) is not widely used now but could be. -
          +{%- endtrans %}
        • +
        + +

        {% trans todo=site_url('get-involved/todo') -%} In future implementations, -basic and -comprehensive restricted routes, +basic and +comprehensive restricted routes, this attack loses much of its power, as the "hidden" peers do not publish their contact addresses in the network database - only the tunnels through which they can be reached (as well as their public keys, etc). -

        +{%- endtrans %}

        + +

        {% trans -%} In the future, routers could use GeoIP to identify if they are in a particular country where identification as an I2P node would be risky. In that case, the router could automatically enable hidden mode, or enact other restricted route methods. -

        +{%- endtrans %}

        - -

        Identification Through Traffic Analysis

        -

        +

        {% trans %}Identification Through Traffic Analysis{% endtrans %}

        +

        {% trans transport=site_url('docs/transport') -%} By inspecting the traffic into and out of a router, a malicious ISP or state-level firewall could identify that a computer is running I2P. As discussed above, I2P is not specifically designed to hide that a computer is running I2P. However, several design decisions made in the design of the -transport layer and protocols +transport layer and protocols make it somewhat difficult to identify I2P traffic: -

        • +{%- endtrans %}

          +
            +
          • {% trans -%} Random port selection -
          • +{%- endtrans %}
          • +
          • {% trans -%} Point-to-Point Encryption of all traffic -
          • +{%- endtrans %}
          • +
          • {% trans -%} DH key exchange with no protocol bytes or other unencrypted constant fields -
          • +{%- endtrans %}
          • +
          • {% trans ntcp=site_url('docs/transport/ntcp'), ssu=site_url('docs/transport/ssu') -%} Simultaneous use of both -TCP and -UDP transports. +TCP and +UDP transports. UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track. -
          +{%- endtrans %}
        • +
        +

        {% trans -%} In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including: -

        • +{%- endtrans %}

          +
            +
          • {% trans -%} Padding at the transport layer to random lengths, especially during the connection handshake -
          • +{%- endtrans %}
          • +
          • {% trans -%} Study of packet size distribution signatures, and additional padding as necessary -
          • +{%- endtrans %}
          • +
          • {% trans -%} Development of additional transport methods that mimic SSL or other common protocols -
          • +{%- endtrans %}
          • +
          • {% trans -%} Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer -
          • +{%- endtrans %}
          • +
          • {% trans -%} Review of methods implemented by various state-level firewalls to block Tor -
          • +{%- endtrans %}
          • +
          • {% trans -%} Working directly with DPI and obfuscation experts -
          -

          -Reference: -Breaking and Improving Protocol Obfuscation -

          +{%- endtrans %}
        • +
        + +

        {% trans pdf='http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf' -%} +Reference: Breaking and Improving Protocol Obfuscation +{%- endtrans %}

        +

        {% trans %}Sybil attacks{% endtrans %}

        -

        Sybil attacks

        - -

        Sybil describes a category of attacks where the adversary creates arbitrarily +

        {% trans -%} +Sybil describes a category of attacks where the adversary creates arbitrarily large numbers of colluding nodes and uses the increased numbers to help mounting other attacks. For instance, if an attacker is in a network where peers are selected randomly and they want an 80% chance to be one of those peers, they @@ -489,39 +597,47 @@ identity. We currently have not implemented any particular technique to address Sybil, but do include placeholder certificates in the router's and destination's data structures which can contain a HashCash certificate of appropriate value when necessary (or some other certificate proving scarcity). -

        +{%- endtrans %}

        + +

        {% trans -%} Requiring HashCash Certificates in various places has two major problems: -

        • +{%- endtrans %}

          +
            +
          • {% trans -%} Maintaining backward compatibility -
          • +{%- endtrans %}
          • +
          • {% trans -%} The classic HashCash problem - selecting HashCash values that are meaningful proofs of work on high-end machines, while still being feasible on low-end machines such as mobile devices. -
          -

          +{%- endtrans %}

        • +
        + +

        {% trans -%} Various limitations on the number of routers in a given IP range restrict the vulnerability to attackers that don't have the ability to put machines in several IP blocks. However, this is not a meaningful defense against a powerful adversary. -

        -See the - network database page +{%- endtrans %}

        + +

        {% trans netdb=site_url('docs/how/network-database') -%} +See the network database page for more Sybil discussion. -

        +{%- endtrans %}

        -

        Buddy Exhaustion attacks

        -

        - (Reference: - In Search of an Anonymouns and Secure Lookup Section 5.2) -

        -

        +

        {% trans %}Buddy Exhaustion attacks{% endtrans %}

        +

        {% trans pdf='https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf' -%} +(Reference: In Search of an Anonymouns and Secure Lookup Section 5.2) +{%- endtrans %}

        + +

        {% trans peerselection=site_url('docs/how/peer-selection') -%} By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure that a tunnel is formed wholly from its set of colluding routers. The chances of success are enhanced if there is a large number of colluding routers, i.e. a Sybil attack. This is somewhat mitigated by our -peer profiling methods used to monitor the performance +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. @@ -529,17 +645,16 @@ The malicous routers could also maintain connections to the target router and pr excellent forwarding bandwidth for traffic over those connections, in an attempt to manipulate the profiles managed by the target and appear attractive. Further research and defenses may be necessary. -

        +{%- endtrans %}

        -

        Cryptographic attacks

        +

        {% trans %}Cryptographic attacks{% endtrans %}

        -

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} We use strong cryptography with long keys, and we assume the security of the industry-standard cryptographic primitives used in I2P, as documented -on the low-level cryptography page. -Security features -include the immediate detection of +on the low-level cryptography page. +Security features include the immediate detection of altered messages along the path, the inability to decrypt messages not addressed to you, and defense against man-in-the-middle attacks. The key sizes chosen in 2003 were quite conservative at the time, and are still longer than @@ -552,53 +667,56 @@ the advent of faster processors, cryptographic research, and advancements in methods such as rainbow tables, clusters of video game hardware, etc. Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change shared secret values while maintaining backward compatibility. -

        +{%- endtrans %}

        + +

        {% trans cryptography=site_url('docs/how/cryptography') -%} Upgrading the various data structures and protocols to support longer keys will have to be tackled eventually, and this will be a -major undertaking, just as it will be for +major undertaking, just as it will be for others. Hopefully, through careful planning, we can minimize the disruption, and implement mechanisms to make it easier for future transitions. -

        -In the future, -several I2P protocols and data structures +{%- endtrans %}

        + +

        {% trans -%} +In the future, several I2P protocols and data structures support securely padding messages to arbitrary sizes, so messages could be made constant size or garlic messages could be modified randomly so that some cloves appear to contain more subcloves than they actually do. At the moment, however, garlic, tunnel, and -end to end messages include simple random padding.

        +end to end messages include simple random padding. +{%- endtrans %}

        -

        Floodfill Anonymity attacks

        -

        +

        {% trans %}Floodfill Anonymity attacks{% endtrans %}

        +

        {% trans netdb=site_url('docs/how/network-database') -%} In addition to the floodfill DOS attacks described above, floodfill routers are uniquely positioned to learn about network participants, due to their role in the netDb, and the high frequency of communication with those participants. This is somewhat mitigated because floodfill routers only manage a portion of the total keyspace, and the keyspace rotates daily, as explained -on the - network database page. +on the 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. -

        +{%- endtrans %}

        -

        Other Network Database attacks

        -

        - A hostile user may attempt to harm the network by - creating one or more floodfill routers and crafting them to offer - bad, slow, or no responses. - Several scenarios are discussed on the - network database page. -

        +

        {% trans %}Other Network Database attacks{% endtrans %}

        +

        {% trans netdb=site_url('docs/how/network-database') -%} +A hostile user may attempt to harm the network by +creating one or more floodfill routers and crafting them to offer +bad, slow, or no responses. +Several scenarios are discussed on the +network database page. +{%- endtrans %}

        -

        Central Resource Attacks

        -

        +

        {% trans %}Central Resource Attacks{% endtrans %}

        +

        {% trans -%} There are a few centralized or limited resources (some inside I2P, some not) that could be attacked or used as a vector for attacks. The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008, @@ -606,65 +724,90 @@ highlighted numerous centralized resources in the development and operation of t most of which are now distributed. Attacks on externally-reachable resources mainly affect the ability of new users to find us, not the operation of the network itself. +{%- endtrans %}

          -
        • The website is mirrored and uses DNS round-robin for external public access. -
        • Routers now support multiple external reseed locations, - however more reseed hosts may be needed, and the handling of unreliable or malicious - reseed hosts may need improvement. -
        • Routers now support multiple update file locations. - A malicious update host could feed a huge file, need to limit the size. -
        • Routers now support multiple default trusted update signers. -
        • Routers now better handle multiple unreliable floodfill peers. - Malicious floodfills needs more study. -
        • The code is now stored in a distributed source control system. -
        • Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host. - A malicious news host could feed a huge file, need to limit the size. -
        • Naming system services, including addressbook subscription providers, add-host services, - and jump services, could be malicious. Substantial protections for subscriptions were implemented - in release 0.6.1.31, with additional enhancements in subsequent releases. - However, all naming services require some measure of trust, see - the naming page for details. -
        • We remain reliant on the DNS service for i2p2.de, losing this would cause substantial - disruption in our ability to attract new users, - and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did. +
        • {% trans site=site_url() -%} +The website is mirrored and uses DNS round-robin for external public access. +{%- endtrans %}
        • +
        • {% trans faq=site_url('faq') -%} +Routers now support multiple external reseed locations, +however more reseed hosts may be needed, and the handling of unreliable or malicious +reseed hosts may need improvement. +{%- endtrans %}
        • +
        • {% trans -%} +Routers now support multiple update file locations. +A malicious update host could feed a huge file, need to limit the size. +{%- endtrans %}
        • +
        • {% trans -%} +Routers now support multiple default trusted update signers. +{%- endtrans %}
        • +
        • {% trans -%} +Routers now better handle multiple unreliable floodfill peers. +Malicious floodfills needs more study. +{%- endtrans %}
        • +
        • {% trans monotone=site_url('get-involved/guides/monotone') -%} +The code is now stored in a distributed source control system. +{%- endtrans %}
        • +
        • {% trans -%} +Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host. +A malicious news host could feed a huge file, need to limit the size. +{%- endtrans %}
        • +
        • {% trans naming=site_url('docs/naming') -%} +Naming system services, including addressbook subscription providers, add-host services, +and jump services, could be malicious. Substantial protections for subscriptions were implemented +in release 0.6.1.31, with additional enhancements in subsequent releases. +However, all naming services require some measure of trust, see +the naming page for details. +{%- endtrans %}
        • +
        • {% trans -%} +We remain reliant on the DNS service for i2p2.de, losing this would cause substantial +disruption in our ability to attract new users, +and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did. +{%- endtrans %}
        -

        Development attacks

        +

        {% trans %}Development attacks{% endtrans %}

        -

        +

        {% trans -%} These attacks aren't directly on the network, but instead go after its development team by either introducing legal hurdles on anyone contributing to the development of the software, or by using whatever means are available to get the developers to subvert the software. Traditional technical measures cannot defeat these attacks, and if someone threatened the life or livelihood of a developer (or even just issuing a court order along with a gag order, under threat of prison), we would have a big problem. -

        +{%- endtrans %}

        -

        +

        {% trans -%} However, two techniques help defend against these attacks: +{%- endtrans %}

          -
        • All components of the network must be open source to enable inspection, verification, - modification, and improvement. If a developer is compromised, once it is noticed - the community should demand explanation and cease to accept that developer's work. - All checkins to our distributed source control system - are cryptographically signed, and the release packagers use a trust-list system - to restrict modifications to those previously approved. -
        • -
        • Development over the network itself, allowing developers to stay anonymous but still - secure the development process. All I2P development can occur through I2P - using - a distributed source control system, - a distributed source control system, IRC chat, - public web servers, - discussion forums (forum.i2p), and the software distribution sites, - all available within I2P.
        • +
        • {% trans monotone=site_url('get-involved/guides/monotone') -%} +All components of the network must be open source to enable inspection, verification, +modification, and improvement. If a developer is compromised, once it is noticed +the community should demand explanation and cease to accept that developer's work. +All checkins to our distributed source control system +are cryptographically signed, and the release packagers use a trust-list system +to restrict modifications to those previously approved. +{%- endtrans %}
        • +
        • {% trans monotone=site_url('get-involved/guides/monotone') -%} +Development over the network itself, allowing developers to stay anonymous but still +secure the development process. All I2P development can occur through I2P - using +a distributed source control system, +a distributed source control system, IRC chat, +public web servers, +discussion forums (forum.i2p), and the software distribution sites, +all available within I2P. +{%- endtrans %}
        + +

        {% trans -%} We also maintain relationships with various organizations that offer legal advice, should any defense be necessary. -

        +{%- endtrans %}

        -

        Implementation attacks (bugs)

        -

        +

        {% trans %}Implementation attacks (bugs){% endtrans %}

        +

        {% trans -%} Try as we might, most nontrivial applications include errors in the design or implementation, and I2P is no exception. There may be bugs that could be exploited to attack the anonymity or security of the communication running over I2P in unexpected @@ -673,7 +816,9 @@ all designs and documentation and solicit review and criticism with the hope that many eyes will improve the system. We do not believe in security through obscurity. -

        +{%- endtrans %}

        + +

        {% trans -%} In addition, the code is being treated the same way, with little aversion towards reworking or throwing out something that isn't meeting the needs of the software system (including ease of @@ -681,57 +826,67 @@ modification). Documentation for the design and implementation of the network a the software components are an essential part of security, as without them it is unlikely that developers would be willing to spend the time to learn the software enough to identify shortcomings and bugs. -

        +{%- endtrans %}

        + +

        {% trans -%} Our software is likely, in particular, to contain bugs related to denial of service through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues in the router console, and other vulnerabilities to non-standard inputs via the various protocols. -

        +{%- endtrans %}

        + +

        {% trans volunteer=site_url('get-involved') -%} I2P is still a small network with a small development community and almost no interest from academic or research groups. Therefore we lack the analysis that other anonymity networks may have received. We continue to recruit people to -get involved and help. -

        +get involved and help. +{%- endtrans %}

        -

        Other Defenses

        -

        Blocklists

        -

        +

        {% trans %}Other Defenses{% endtrans %}

        +

        {% trans %}Blocklists{% endtrans %}

        +

        {% trans -%} To some extent, I2P could be enhanced to avoid peers operating at IP addresses listed in a blocklist. Several blocklists are commonly available in standard formats, listing anti-P2P organizations, potential state-level adversaries, and others. -

        +{%- endtrans %}

        + +

        {% trans -%} To the extent that active peers actually do show up in the actual blocklist, blocking by only a subset of peers would tend to segment the network, exacerbate reachability problems, and decrease overall reliability. Therefore we would want to agree on a particular blocklist and enable it by default. +{%- endtrans %}

        -

        +

        {% trans -%} Blocklists are only a part (perhaps a small part) of an array of defenses against maliciousness. In large part the profiling system does a good job of measuring router behavior so that we don't need to trust anything in netDb. However there is more that can be done. For each of the areas in the list above there are improvements we can make in detecting badness. -

        +{%- endtrans %}

        + +

        {% trans -%} If a blocklist is hosted at a central location with automatic updates the network is vulnerable to a central resource attack. Automatic subscription to a list gives the list provider the power to shut the i2p network down. Completely. -

        +{%- endtrans %}

        + +

        {% trans -%} Currently, a default blocklist is distributed with our software, listing only the IPs of past DOS sources. -There -is no automatic update mechanism. +There is no automatic update mechanism. Should a particular IP range implement serious attacks on the I2P network, we would have to ask people to update their blocklist manually through out-of-band mechanisms such as forums, blogs, etc. -

        +{%- endtrans %}

        {% endblock %} From 39e335455f63678da381c32560612093da54a2a1 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 10:16:08 +0000 Subject: [PATCH 368/498] Added translation tags to docs/how/tech-intro --- i2p2www/pages/site/docs/how/tech-intro.html | 1820 ++++++++++--------- 1 file changed, 1001 insertions(+), 819 deletions(-) diff --git a/i2p2www/pages/site/docs/how/tech-intro.html b/i2p2www/pages/site/docs/how/tech-intro.html index b27a092b..aa7fdc9e 100644 --- a/i2p2www/pages/site/docs/how/tech-intro.html +++ b/i2p2www/pages/site/docs/how/tech-intro.html @@ -1,888 +1,1070 @@ {% extends "global/layout.html" %} -{% block title %}Introducing I2P{% endblock %} +{% block title %}{% trans %}Introducing I2P{% endtrans %}{% endblock %} {% block content %} -

        I2P: A scalable framework for anonymous communication

        +

        {% trans %}I2P: A scalable framework for anonymous communication{% endtrans %}


        -

        Introduction

        -

        - I2P is a scalable, self organizing, resilient packet switched anonymous - network layer, upon which any number of different anonymity or security conscious - applications can operate. Each of these applications may make their own anonymity, - latency, and throughput tradeoffs without worrying about the proper implementation - of a free route mixnet, allowing them to blend their activity with the larger - anonymity set of users already running on top of I2P. -

        -

        - Applications available already provide the full range of typical Internet activities - - anonymous web browsing, web hosting, chat, file sharing, e-mail, - blogging and content syndication, newsgroups, as well as several other applications under development. +

        {% trans %}Introduction{% endtrans %}

        +

        {% trans -%} +I2P is a scalable, self organizing, resilient packet switched anonymous +network layer, upon which any number of different anonymity or security conscious +applications can operate. Each of these applications may make their own anonymity, +latency, and throughput tradeoffs without worrying about the proper implementation +of a free route mixnet, allowing them to blend their activity with the larger +anonymity set of users already running on top of I2P. +{%- endtrans %}

        + +

        {% trans -%} +Applications available already provide the full range of typical Internet activities - +anonymous web browsing, web hosting, chat, file sharing, e-mail, +blogging and content syndication, newsgroups, as well as several other applications under development. +{%- endtrans %}

          -
        • Web browsing: using any existing browser that supports using a proxy.
        • -
        • Chat: IRC, Jabber, I2P-Messenger.
        • -
        • File sharing: I2PSnark, Robert, iMule, - I2Phex, PyBit, I2P-bt - and others. -
        • -
        • E-mail: susimail and I2P-Bote.
        • -
        • Blog: using e.g. the pebble plugin or the distributed blogging software Syndie.
        • -
        • Distributed Data Store: Save your data redundantly in the Tahoe-LAFS cloud over I2P.
        • -
        • Newsgroups: using any newsgroup reader that supports using a proxy.
        • +
        • {% trans %}Web browsing: using any existing browser that supports using a proxy.{% endtrans %}
        • +
        • {% trans %}Chat: IRC, Jabber, I2P-Messenger.{% endtrans %}
        • +
        • {% trans -%} +File sharing: I2PSnark, Robert, iMule, +I2Phex, PyBit, I2P-bt +and others. +{%- endtrans %}
        • +
        • {% trans %}E-mail: susimail and I2P-Bote.{% endtrans %}
        • +
        • {% trans %}Blog: using e.g. the pebble plugin or the distributed blogging software Syndie.{% endtrans %}
        • +
        • {% trans %}Distributed Data Store: Save your data redundantly in the Tahoe-LAFS cloud over I2P.{% endtrans %}
        • +
        • {% trans %}Newsgroups: using any newsgroup reader that supports using a proxy.{% endtrans %}
        -

        - Unlike web sites hosted within content distribution networks like Freenet - or GNUnet, the services hosted on - I2P are fully interactive - there are traditional web-style search engines, - bulletin boards, blogs you can comment on, database driven sites, and bridges - to query static systems like Freenet without needing to install it locally. -

        -

        - With all of these anonymity enabled applications, I2P takes on the role - of the message oriented middleware - applications say that they want to send - some data to a cryptographic identifier (a "destination") and I2P takes care - of making sure it gets there securely and anonymously. I2P also bundles a - simple streaming library to allow I2P's anonymous - best-effort messages to transfer as reliable, in-order streams, transparently - offering a TCP based congestion control algorithm tuned for the high bandwidth - delay product of the network. While there have been several simple SOCKS proxies - available to tie existing applications into the network, their value has been - limited as nearly every application routinely exposes what, in an anonymous - context, is sensitive information. The only safe way to go is to fully audit - an application to ensure proper operation and to assist in that we provide - a series of APIs in various languages which can be used to make the most out - of the network. -

        -

        - I2P is not a research project - academic, commercial, or governmental, but - is instead an engineering effort aimed at doing whatever is necessary to provide - a sufficient level of anonymity to those who need it. It has been in active - development since early 2003 with one full time developer and a dedicated - group of part time contributors from all over the world. All of the work done - on I2P is open source and freely available on the website, - with the majority of the code released outright into the public domain, though - making use of a few cryptographic routines under BSD-style licenses. The people - working on I2P do not control what people release client applications under, - and there are several GPL'ed applications available (I2PTunnel, - susimail, I2PSnark, I2P-Bote, - I2Phex and others.). - Funding for I2P comes entirely from donations, - and does not receive any tax breaks in any jurisdiction at this time, - as many of the developers are themselves anonymous. -

        -

        Operation

        -

        Overview

        -

        - To understand I2P's operation, it is essential to understand a few key concepts. - First, I2P makes a strict separation between the software participating in - the network (a "router") and the anonymous endpoints ("destinations") associated - with individual applications. The fact that someone is running I2P is not - usually a secret. What is hidden is information on what the user is doing, - if anything at all, as well as what router a particular destination is connected - to. End users will typically have several local destinations on their router - - for instance, one proxying in to IRC servers, another supporting the user's - anonymous webserver ("eepsite"), another for an I2Phex instance, another for - torrents, etc. -

        -

        - Another critical concept to understand is the "tunnel". - A tunnel is a directed path through an explicitly selected list of routers. - Layered encryption is used, so each of the routers can only decrypt a single layer. - The decrypted information contains the IP of the next router, along with - the encrypted information to be forwarded. - Each tunnel has a starting point (the first router, also known as "gateway") - and an end point. Messages can be sent only in one way. To send messages back, - another tunnel is required. -

        + +

        {% trans -%} +Unlike web sites hosted within content distribution networks like Freenet +or GNUnet, the services hosted on +I2P are fully interactive - there are traditional web-style search engines, +bulletin boards, blogs you can comment on, database driven sites, and bridges +to query static systems like Freenet without needing to install it locally. +{%- endtrans %}

        + +

        {% trans -%} +With all of these anonymity enabled applications, I2P takes on the role +of the message oriented middleware - applications say that they want to send +some data to a cryptographic identifier (a "destination") and I2P takes care +of making sure it gets there securely and anonymously. I2P also bundles a +simple streaming library to allow I2P's anonymous +best-effort messages to transfer as reliable, in-order streams, transparently +offering a TCP based congestion control algorithm tuned for the high bandwidth +delay product of the network. While there have been several simple SOCKS proxies +available to tie existing applications into the network, their value has been +limited as nearly every application routinely exposes what, in an anonymous +context, is sensitive information. The only safe way to go is to fully audit +an application to ensure proper operation and to assist in that we provide +a series of APIs in various languages which can be used to make the most out +of the network. +{%- endtrans %}

        + +

        {% trans site=site_url(), halloffame=site_url('about/hall-of-fame') -%} +I2P is not a research project - academic, commercial, or governmental, but +is instead an engineering effort aimed at doing whatever is necessary to provide +a sufficient level of anonymity to those who need it. It has been in active +development since early 2003 with one full time developer and a dedicated +group of part time contributors from all over the world. All of the work done +on I2P is open source and freely available on the website, +with the majority of the code released outright into the public domain, though +making use of a few cryptographic routines under BSD-style licenses. The people +working on I2P do not control what people release client applications under, +and there are several GPL'ed applications available (I2PTunnel, +susimail, I2PSnark, I2P-Bote, +I2Phex and others.). +Funding for I2P comes entirely from donations, +and does not receive any tax breaks in any jurisdiction at this time, +as many of the developers are themselves anonymous. +{%- endtrans %}

        + +

        {% trans %}Operation{% endtrans %}

        +

        {% trans %}Overview{% endtrans %}

        +

        {% trans -%} +To understand I2P's operation, it is essential to understand a few key concepts. +First, I2P makes a strict separation between the software participating in +the network (a "router") and the anonymous endpoints ("destinations") associated +with individual applications. The fact that someone is running I2P is not +usually a secret. What is hidden is information on what the user is doing, +if anything at all, as well as what router a particular destination is connected +to. End users will typically have several local destinations on their router +- for instance, one proxying in to IRC servers, another supporting the user's +anonymous webserver ("eepsite"), another for an I2Phex instance, another for +torrents, etc. +{%- endtrans %}

        + +

        {% trans -%} +Another critical concept to understand is the "tunnel". +A tunnel is a directed path through an explicitly selected list of routers. +Layered encryption is used, so each of the routers can only decrypt a single layer. +The decrypted information contains the IP of the next router, along with +the encrypted information to be forwarded. +Each tunnel has a starting point (the first router, also known as "gateway") +and an end point. Messages can be sent only in one way. To send messages back, +another tunnel is required. +{%- endtrans %}

        - Inbound and outbound tunnel schematic + {{ _('Inbound and outbound tunnel schematic') }}

        - Figure 1: Two types of tunnels exist: inbound and outbound. + {% trans %}Figure 1: Two types of tunnels exist: inbound and outbound.{% endtrans %}
        -
        -

        - Two types of tunnels exist: - "outbound" tunnels send messages away from the tunnel creator, - while "inbound" tunnels bring messages to the tunnel creator. - Combining these two tunnels allows users to send messages to each other. - The sender ("Alice" in the above image) sets up an outbound tunnel, - while the receiver ("Bob" in the above image) creates an inbound tunnel. - The gateway of an inbound tunnel can receive messages from any other user - and will send them on until the endpoint ("Bob"). - The endpoint of the outbound tunnel will need to send the message - on to the gateway of the inbound tunnel. - To do this, the sender ("Alice") adds instructions to her encrypted message. - Once the endpoint of the outbound tunnel decrypts the message, - it will have instructions to forward the message to the correct - inbound gateway (the gateway to "Bob"). -

        -

        - A third critical concept to understand is I2P's "network database" (or "netDb") - - a pair of algorithms used to share network metadata. The two types of metadata - carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the - data necessary for contacting a particular router (their public keys, transport - addresses, etc), while the leaseSet gives routers the information necessary - for contacting a particular destination. A leaseSet contains a number of "leases". - Each of this leases specifies a tunnel gateway, which allows reaching a specific destination. - The full information contained in a lease: + +

        {% trans -%} +Two types of tunnels exist: +"outbound" tunnels send messages away from the tunnel creator, +while "inbound" tunnels bring messages to the tunnel creator. +Combining these two tunnels allows users to send messages to each other. +The sender ("Alice" in the above image) sets up an outbound tunnel, +while the receiver ("Bob" in the above image) creates an inbound tunnel. +The gateway of an inbound tunnel can receive messages from any other user +and will send them on until the endpoint ("Bob"). +The endpoint of the outbound tunnel will need to send the message +on to the gateway of the inbound tunnel. +To do this, the sender ("Alice") adds instructions to her encrypted message. +Once the endpoint of the outbound tunnel decrypts the message, +it will have instructions to forward the message to the correct +inbound gateway (the gateway to "Bob"). +{%- endtrans %}

        + +

        {% trans -%} +A third critical concept to understand is I2P's "network database" (or "netDb") +- a pair of algorithms used to share network metadata. The two types of metadata +carried are "routerInfo" and "leaseSets" - the routerInfo gives routers the +data necessary for contacting a particular router (their public keys, transport +addresses, etc), while the leaseSet gives routers the information necessary +for contacting a particular destination. A leaseSet contains a number of "leases". +Each of this leases specifies a tunnel gateway, which allows reaching a specific destination. +The full information contained in a lease: +{%- endtrans %}

          -
        • Inbound gateway for a tunnel that allows reaching a specific destination.
        • -
        • Time when a tunnel expires.
        • -
        • Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).
        • +
        • {% trans %}Inbound gateway for a tunnel that allows reaching a specific destination.{% endtrans %}
        • +
        • {% trans %}Time when a tunnel expires.{% endtrans %}
        • +
        • {% trans %}Pair of public keys to be able to encrypt messages (to send through the tunnel and reach the destination).{% endtrans %}
        - Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels - (leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets). -

        -

        - We can combine the above concepts to build successful connections in the network. -

        -

        - To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo. - This way, she gathers lists of peers she can use as hops in her tunnels. - She can then send a build message to the first hop, requesting the construction of a tunnel and asking - that router to send the construction message onward, until the tunnel has been constructed. -

        +

        {% trans -%} +Routers themselves send their routerInfo to the netDb directly, while leaseSets are sent through outbound tunnels +(leaseSets need to be sent anonymously, to avoid correlating a router with his leaseSets). +{%- endtrans %}

        + +

        {% trans -%} +We can combine the above concepts to build successful connections in the network. +{%- endtrans %}

        + +

        {% trans -%} +To build up her own inbound and outbound tunnels, Alice does a lookup in the netDb to collect routerInfo. +This way, she gathers lists of peers she can use as hops in her tunnels. +She can then send a build message to the first hop, requesting the construction of a tunnel and asking +that router to send the construction message onward, until the tunnel has been constructed. +{%- endtrans %}

        - Request information on other routers + {{ _('Request information on other routers') }}                     - Build tunnel using router information + {{ _('Build tunnel using router information') }}

        - Figure 2: Router information is used to build tunnels. + {% trans %}Figure 2: Router information is used to build tunnels.{% endtrans %}

        -

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

        +

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

        - Connect tunnels using leaseSets + {{ _('Connect tunnels using LeaseSets') }}

        - Figure 3: Leasesets are used to connect outbound and inbound tunnels. + {% trans %}Figure 3: LeaseSets are used to connect outbound and inbound tunnels.{% endtrans %}

        -

        - While the tunnels themselves have layered encryption to prevent unauthorized - disclosure to peers inside the network (as the transport layer itself does - to prevent unauthorized disclosure to peers outside the network), it is necessary - to add an additional end to end layer of encryption to hide the message from - the outbound tunnel endpoint and the inbound tunnel gateway. This "garlic - encryption" lets Alice's router wrap up multiple messages into a single - "garlic message", encrypted to a particular public key so that intermediary - peers cannot determine either how many messages are within the garlic, what - those messages say, or where those individual cloves are destined. For typical - end to end communication between Alice and Bob, the garlic will be encrypted - to the public key published in Bob's leaseSet, allowing the message to be - encrypted without giving out the public key to Bob's own router. -

        -

        - Another important fact to keep in mind is that I2P is entirely message based - and that some messages may be lost along the way. Applications using I2P can - use the message oriented interfaces and take care of their own congestion - control and reliability needs, but most would be best served by reusing the - provided streaming library to view I2P as a streams - based network. -

        -

        Tunnels

        -

        - Both inbound and outbound tunnels work along similar principles. - The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing - them into something for tunnel delivery. Next, the gateway encrypts that preprocessed - data and forwards it to the first hop. That peer and subsequent tunnel participants - add on a layer of encryption after verifying that it isn't a duplicate before - forward it on to the next peer. Eventually, the message arrives at the endpoint - where the messages are split out again and forwarded on as requested. The - difference arises in what the tunnel's creator does - for inbound tunnels, - the creator is the endpoint and they simply decrypt all of the layers added, - while for outbound tunnels, the creator is the gateway and they pre-decrypt - all of the layers so that after all of the layers of per-hop encryption are - added, the message arrives in the clear at the tunnel endpoint. -

        -

        - The choice of specific peers to pass on messages as well as their particular - ordering is important to understanding both I2P's anonymity and performance - characteristics. While the network database (below) has its own criteria for - picking what peers to query and store entries on, tunnel creators may use any peers - in the network in any order (and even any number of times) in a single tunnel. - If perfect latency and capacity data were globally known, selection and ordering - would be driven by the particular needs of the client in tandem with their - threat model. Unfortunately, latency and capacity data is not trivial to gather - anonymously, and depending upon untrusted peers to provide this information - has its own serious anonymity implications. -

        -

        - From an anonymity perspective, the simplest technique would be to pick peers - randomly from the entire network, order them randomly and use those peers - in that order for all eternity. From a performance perspective, the simplest - technique would be to pick the fastest peers with the necessary spare capacity, - spreading the load across different peers to handle transparent failover, - and to rebuild the tunnel whenever capacity information changes. While the - former is both brittle and inefficient, the later requires inaccessible information - and offers insufficient anonymity. I2P is instead working on offering a range - of peer selection strategies, coupled with anonymity aware measurement code - to organize the peers by their profiles. -

        -

        - As a base, I2P is constantly profiling the peers with which it interacts - with by measuring their indirect behavior - for instance, when a peer responds - to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the - profiles for all of the routers involved in the two tunnels (inbound and outbound) - through which the request and response passed, as well as the queried peer's - profile. Direct measurement, such as transport layer latency or congestion, - is not used as part of the profile, as it can be manipulated and associated - with the measuring router, exposing them to trivial attacks. While gathering - these profiles, a series of calculations are run on each to summarize its - performance - its latency, capacity to handle lots of activity, whether they - are currently overloaded, and how well integrated into the network they seem - to be. These calculations are then compared for active peers to organize the - routers into four tiers - fast and high capacity, high capacity, not failing, - and failing. The thresholds for those tiers are determined dynamically, and - while they currently use fairly simple algorithms, alternatives exist. -

        -

        Using this profile data, the simplest reasonable peer selection strategy - is to pick peers randomly from the top tier (fast and high capacity), and - this is currently deployed for client tunnels. Exploratory tunnels (used for - netDb and tunnel management) pick peers randomly from the "not failing" tier - (which includes routers in 'better' tiers as well), allowing the peer to sample - routers more widely, in effect optimizing the peer selection through randomized - hill climbing. These strategies alone do however leak information regarding - the peers in the router's top tier through predecessor and netDb harvesting - attacks. In turn, several alternatives exist which, while not balancing the - load as evenly, will address the attacks mounted by particular classes of - adversaries. -

        -

        - By picking a random key and ordering the peers according to their XOR distance - from it, the information leaked is reduced in predecessor and harvesting attacks - according to the peers' failure rate and the tier's churn. Another simple - strategy for dealing with netDb harvesting attacks is to simply fix the inbound - tunnel gateway(s) yet randomize the peers further on in the tunnels. To deal - with predecessor attacks for adversaries which the client contacts, the outbound - tunnel endpoints would also remain fixed. The selection of which peer to fix - on the most exposed point would of course need to have a limit to the duration, - as all peers fail eventually, so it could either be reactively adjusted or - proactively avoided to mimic a measured mean time between failures of other - routers. These two strategies can in turn be combined, using a fixed exposed - peer and an XOR based ordering within the tunnels themselves. A more rigid - strategy would fix the exact peers and ordering of a potential tunnel, only - using individual peers if all of them agree to participate in the same way - each time. This varies from the XOR based ordering in that the predecessor - and successor of each peer is always the same, while the XOR only makes sure - their order doesn't change. -

        -

        - As mentioned before, I2P currently (release 0.8) includes the tiered - random strategy above, with XOR-based ordering. A - more detailed discussion of the mechanics involved in tunnel operation, management, - and peer selection can be found in the tunnel spec. -

        -

        Network Database

        -

        - As mentioned earlier, I2P's netDb works to share the network's metadata. - This is detailed in the networkdatabase page, - but a basic explanation is available below. -

        -

        - A percentage of I2P users are appointed as 'floodfill peers'. - Currently, I2P installations that have a lot of bandwidth and are fast enough, - will appoint themselves as floodfill as soon as the number of existing floodfill routers - drops too low. -

        -

        - Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills. - If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers - using the Kademlia algorithm. - The 'lookup' queries currently function differently, to avoid an important - security issue. - When a lookup is done, the floodfill router will not forward the lookup to other peers, - but will always answer by itself (if it has the requested data). -

        -

        - Two types of information are stored in the network database. +

        {% trans -%} +While the tunnels themselves have layered encryption to prevent unauthorized +disclosure to peers inside the network (as the transport layer itself does +to prevent unauthorized disclosure to peers outside the network), it is necessary +to add an additional end to end layer of encryption to hide the message from +the outbound tunnel endpoint and the inbound tunnel gateway. This "garlic +encryption" lets Alice's router wrap up multiple messages into a single +"garlic message", encrypted to a particular public key so that intermediary +peers cannot determine either how many messages are within the garlic, what +those messages say, or where those individual cloves are destined. For typical +end to end communication between Alice and Bob, the garlic will be encrypted +to the public key published in Bob's leaseSet, allowing the message to be +encrypted without giving out the public key to Bob's own router. +{%- endtrans %}

        + +

        {% trans -%} +Another important fact to keep in mind is that I2P is entirely message based +and that some messages may be lost along the way. Applications using I2P can +use the message oriented interfaces and take care of their own congestion +control and reliability needs, but most would be best served by reusing the +provided streaming library to view I2P as a streams +based network. +{%- endtrans %}

        + +

        {% trans %}Tunnels{% endtrans %}

        +

        {% trans -%} +Both inbound and outbound tunnels work along similar principles. +The tunnel gateway accumulates a number of tunnel messages, eventually preprocessing +them into something for tunnel delivery. Next, the gateway encrypts that preprocessed +data and forwards it to the first hop. That peer and subsequent tunnel participants +add on a layer of encryption after verifying that it isn't a duplicate before +forward it on to the next peer. Eventually, the message arrives at the endpoint +where the messages are split out again and forwarded on as requested. The +difference arises in what the tunnel's creator does - for inbound tunnels, +the creator is the endpoint and they simply decrypt all of the layers added, +while for outbound tunnels, the creator is the gateway and they pre-decrypt +all of the layers so that after all of the layers of per-hop encryption are +added, the message arrives in the clear at the tunnel endpoint. +{%- endtrans %}

        + +

        {% trans -%} +The choice of specific peers to pass on messages as well as their particular +ordering is important to understanding both I2P's anonymity and performance +characteristics. While the network database (below) has its own criteria for +picking what peers to query and store entries on, tunnel creators may use any peers +in the network in any order (and even any number of times) in a single tunnel. +If perfect latency and capacity data were globally known, selection and ordering +would be driven by the particular needs of the client in tandem with their +threat model. Unfortunately, latency and capacity data is not trivial to gather +anonymously, and depending upon untrusted peers to provide this information +has its own serious anonymity implications. +{%- endtrans %}

        + +

        {% trans -%} +From an anonymity perspective, the simplest technique would be to pick peers +randomly from the entire network, order them randomly and use those peers +in that order for all eternity. From a performance perspective, the simplest +technique would be to pick the fastest peers with the necessary spare capacity, +spreading the load across different peers to handle transparent failover, +and to rebuild the tunnel whenever capacity information changes. While the +former is both brittle and inefficient, the later requires inaccessible information +and offers insufficient anonymity. I2P is instead working on offering a range +of peer selection strategies, coupled with anonymity aware measurement code +to organize the peers by their profiles. +{%- endtrans %}

        + +

        {% trans -%} +As a base, I2P is constantly profiling the peers with which it interacts +with by measuring their indirect behavior - for instance, when a peer responds +to a netDb lookup in 1.3 seconds, that round trip latency is recorded in the +profiles for all of the routers involved in the two tunnels (inbound and outbound) +through which the request and response passed, as well as the queried peer's +profile. Direct measurement, such as transport layer latency or congestion, +is not used as part of the profile, as it can be manipulated and associated +with the measuring router, exposing them to trivial attacks. While gathering +these profiles, a series of calculations are run on each to summarize its +performance - its latency, capacity to handle lots of activity, whether they +are currently overloaded, and how well integrated into the network they seem +to be. These calculations are then compared for active peers to organize the +routers into four tiers - fast and high capacity, high capacity, not failing, +and failing. The thresholds for those tiers are determined dynamically, and +while they currently use fairly simple algorithms, alternatives exist. +{%- endtrans %}

        + +

        {% trans -%} +Using this profile data, the simplest reasonable peer selection strategy +is to pick peers randomly from the top tier (fast and high capacity), and +this is currently deployed for client tunnels. Exploratory tunnels (used for +netDb and tunnel management) pick peers randomly from the "not failing" tier +(which includes routers in 'better' tiers as well), allowing the peer to sample +routers more widely, in effect optimizing the peer selection through randomized +hill climbing. These strategies alone do however leak information regarding +the peers in the router's top tier through predecessor and netDb harvesting +attacks. In turn, several alternatives exist which, while not balancing the +load as evenly, will address the attacks mounted by particular classes of +adversaries. +{%- endtrans %}

        + +

        {% trans -%} +By picking a random key and ordering the peers according to their XOR distance +from it, the information leaked is reduced in predecessor and harvesting attacks +according to the peers' failure rate and the tier's churn. Another simple +strategy for dealing with netDb harvesting attacks is to simply fix the inbound +tunnel gateway(s) yet randomize the peers further on in the tunnels. To deal +with predecessor attacks for adversaries which the client contacts, the outbound +tunnel endpoints would also remain fixed. The selection of which peer to fix +on the most exposed point would of course need to have a limit to the duration, +as all peers fail eventually, so it could either be reactively adjusted or +proactively avoided to mimic a measured mean time between failures of other +routers. These two strategies can in turn be combined, using a fixed exposed +peer and an XOR based ordering within the tunnels themselves. A more rigid +strategy would fix the exact peers and ordering of a potential tunnel, only +using individual peers if all of them agree to participate in the same way +each time. This varies from the XOR based ordering in that the predecessor +and successor of each peer is always the same, while the XOR only makes sure +their order doesn't change. +{%- endtrans %}

        + +

        {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%} +As mentioned before, I2P currently (release 0.8) includes the tiered +random strategy above, with XOR-based ordering. A +more detailed discussion of the mechanics involved in tunnel operation, management, +and peer selection can be found in the tunnel spec. +{%- endtrans %}

        + +

        {% trans %}Network Database{% endtrans %}

        +

        {% trans netdb=site_url('docs/how/network-database') -%} +As mentioned earlier, I2P's netDb works to share the network's metadata. +This is detailed in the network database page, +but a basic explanation is available below. +{%- endtrans %}

        + +

        {% trans -%} +A percentage of I2P users are appointed as 'floodfill peers'. +Currently, I2P installations that have a lot of bandwidth and are fast enough, +will appoint themselves as floodfill as soon as the number of existing floodfill routers +drops too low. +{%- endtrans %}

        + +

        {% trans netdb=site_url('docs/how/network-database') -%} +Other I2P routers will store their data and lookup data by sending simple 'store' and 'lookup' queries to the floodfills. +If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers +using the Kademlia algorithm. +The 'lookup' queries currently function differently, to avoid an important +security issue. +When a lookup is done, the floodfill router will not forward the lookup to other peers, +but will always answer by itself (if it has the requested data). +{%- endtrans %}

        + +

        {% trans -%} +Two types of information are stored in the network database. +{%- endtrans %}

          -
        • A routerInfo stores information on a specific I2P router and how to contact it
        • -
        • A leaseSet stores information on a specific destination (e.g. I2P website, e-mail server...)
        • +
        • {% trans %}A RouterInfo stores information on a specific I2P router and how to contact it{% endtrans %}
        • +
        • {% trans %}A LeaseSet stores information on a specific destination (e.g. I2P website, e-mail server...){% endtrans %}
        - All of this information is signed by the publishing party and verified by any I2P router using or storing the information. - In addition, the data contains timing information, to avoid storage of old entries and possible attacks. - This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers - (the pool.ntp.org round robin by default) - and detecting skew between routers at the transport layer. -

        -

        - Some additional remarks are also important. +

        {% trans -%} +All of this information is signed by the publishing party and verified by any I2P router using or storing the information. +In addition, the data contains timing information, to avoid storage of old entries and possible attacks. +This is also why I2P bundles the necessary code for maintaining the correct time, occasionally querying some SNTP servers +(the pool.ntp.org round robin by default) +and detecting skew between routers at the transport layer. +{%- endtrans %}

        + +

        {% trans -%} +Some additional remarks are also important. +{%- endtrans %}

        • - Unpublished and encrypted leasesets: -

          - One could only want specific people to be able to reach a destination. - This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means. - An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key. -

          + {% trans %}Unpublished and encrypted leasesets:{% endtrans %} +

          {% trans -%} +One could only want specific people to be able to reach a destination. +This is possible by not publishing the destination in the netDb. You will however have to transmit the destination by other means. +An alternative are the 'encrypted leaseSets'. These leaseSets can only be decoded by people with access to the decryption key. +{%- endtrans %}

        • - Bootstrapping: -

          - Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer, - it can query that router for references to other routers in the network. - Currently, a number of users post their routerInfo files to a website to make this information available. - I2P automatically connects to one of these websites to gather routerInfo files and bootstrap. -

          + {% trans %}Bootstrapping:{% endtrans %} +

          {% trans -%} +Bootstrapping the netDb is quite simple. Once a router manages to receive a single routerInfo of a reachable peer, +it can query that router for references to other routers in the network. +Currently, a number of users post their routerInfo files to a website to make this information available. +I2P automatically connects to one of these websites to gather routerInfo files and bootstrap. +{%- endtrans %}

        • - Lookup scalability: -

          - Lookups in the I2P network are not forwarded to other netDb routers. - Currently, this is not a major problem, since the network is not very large. - However, as the network grows, not all routerInfo and leaseSet files will be present - on each netDb router. This will cause a deterioration of the percentage of successful lookups. - Because of this, refinements to the netDb will be done in the next releases. -

          + {% trans %}Lookup scalability:{% endtrans %} +

          {% trans -%} +Lookups in the I2P network are not forwarded to other netDb routers. +Currently, this is not a major problem, since the network is not very large. +However, as the network grows, not all routerInfo and leaseSet files will be present +on each netDb router. This will cause a deterioration of the percentage of successful lookups. +Because of this, refinements to the netDb will be done in the next releases. +{%- endtrans %}

        -

        -

        Transport protocols

        -

        Communication between routers needs to provide confidentiality and integrity - against external adversaries while authenticating that the router contacted - is the one who should receive a given message. The particulars of how routers - communicate with other routers aren't critical - three separate protocols - have been used at different points to provide those bare necessities.

        -

        I2P started with a TCP-based protocol which - has since been disabled. Then, to accommodate the need for high degree communication - (as a number of routers will end up speaking with many others), I2P moved - from a TCP based transport to a UDP-based one - "Secure - Semireliable UDP", or "SSU".

        -

        As described in the SSU spec:

        -
        The goal of this protocol is to provide secure, authenticated, - semireliable and unordered message delivery, exposing only a minimal amount - of data easily discernible to third parties. It should support high degree - communication as well as TCP-friendly congestion control and may include - PMTU detection. It should be capable of efficiently moving bulk data at rates - sufficient for home users. In addition, it should support techniques for addressing - network obstacles, like most NATs or firewalls.
        -

        Following the introduction of SSU, after issues with congestion collapse - appeared, a new NIO-based TCP transport called NTCP - was implemented. It is enabled by default for outbound connections only. Those - who configure their NAT/firewall to allow inbound connections and specify - the external host and port (dyndns/etc is ok) on /config.jsp can receive inbound - connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread - per connection issues of the old TCP transport.

        -

        I2P supports multiple transports simultaneously. A particular transport - for an outbound connection is selected with "bids". Each transport bids for - the connection and the relative value of these bids assigns the priority. - Transports may reply with different bids, depending on whether there is already - an established connection to the peer.

        -

        The current implementation ranks NTCP as the highest-priority transport - for outbound connections in most situations. SSU is enabled for both outbound - and inbound connections. Your firewall and your I2P router must be configured - to allow inbound NTCP connections. For further information see the NTCP - page.

        -

        Cryptography

        -

        A bare minimum set of cryptographic primitives are combined together to - provide I2P's layered defenses against a variety of adversaries. At the lowest - level, inter router communication is protected by the transport layer security - - SSU encrypts each packet with AES256/CBC with both an explicit IV and MAC - (HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048bit - Diffie-Hellman exchange, station-to-station authentication with the other - router's DSA key, plus each network message has their own hash for local integrity - checking. Tunnel messages passed over the transports - have their own layered AES256/CBC encryption with an explicit IV and verified - at the tunnel endpoint with an additional SHA256 hash. Various other messages - are passed along inside "garlic messages", which are encrypted with ElGamal/AES+SessionTags - (explained below).

        -

        Garlic messages

        -

        Garlic messages are an extension of "onion" layered encryption, allowing - the contents of a single message to contain multiple "cloves" - fully formed - messages alongside their own instructions for delivery. Messages are wrapped - into a garlic message whenever the message would otherwise be passing in cleartext - through a peer who should not have access to the information - for instance, - when a router wants to ask another router to participate in a tunnel, they - wrap the request inside a garlic, encrypt that garlic to the receiving router's - 2048bit ElGamal public key, and forward it through a tunnel. Another example - is when a client wants to send a message to a destination - the sender's router - will wrap up that data message (alongside some other messages) into a garlic, - encrypt that garlic to the 2048bit ElGamal public key published in the recipient's - leaseSet, and forward it through the appropriate tunnels.

        -

        The "instructions" attached to each clove inside the encryption layer includes - the ability to request that the clove be forwarded locally, to a remote router, - or to a remote tunnel on a remote router. There are fields in those instructions - allowing a peer to request that the delivery be delayed until a certain time - or condition has been met, though they won't be honored until the nontrivial - delays are deployed. It is possible to explicitly route garlic messages - any number of hops without building tunnels, or even to reroute tunnel messages - by wrapping them in garlic messages and forwarding them a number of hops prior - to delivering them to the next hop in the tunnel, but those techniques are - not currently used in the existing implementation.

        -

        Session tags

        -

        As an unreliable, unordered, message based system, I2P uses a simple combination - of asymmetric and symmetric encryption algorithms to provide data confidentiality - and integrity to garlic messages. As a whole, the combination is referred - to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe - the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces.

        -

        The first time a router wants to encrypt a garlic message to another router, - they encrypt the keying material for an AES256 session key with ElGamal and - append the AES256/CBC encrypted payload after that encrypted ElGamal block. - In addition to the encrypted payload, the AES encrypted section contains the - payload length, the SHA256 hash of the unencrypted payload, as well as a number - of "session tags" - random 32 byte nonces. The next time the sender wants - to encrypt a garlic message to another router, rather than ElGamal encrypt - a new session key they simply pick one of the previously delivered session - tags and AES encrypt the payload like before, using the session key used with - that session tag, prepended with the session tag itself. When a router receives - a garlic encrypted message, they check the first 32 bytes to see if it matches - an available session tag - if it does, they simply AES decrypt the message, - but if it does not, they ElGamal decrypt the first block.

        -

        Each session tag can be used only once so as to prevent internal adversaries - from unnecessarily correlating different messages as being between the same - routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses - when and how many tags to deliver, prestocking the recipient with enough tags - to cover a volley of messages. Garlic messages may detect the successful tag - delivery by bundling a small additional message as a clove (a "delivery status - message") - when the garlic message arrives at the intended recipient and - is decrypted successfully, this small delivery status message is one of the - cloves exposed and has instructions for the recipient to send the clove back - to the original sender (through an inbound tunnel, of course). When the original - sender receives this delivery status message, they know that the session tags - bundled in the garlic message were successfully delivered.

        -

        Session tags themselves have a very short lifetime, after which they are - discarded if not used. In addition, the quantity stored for each key is limited, - as are the number of keys themselves - if too many arrive, either new or old - messages may be dropped. The sender keeps track whether messages using session - tags are getting through, and if there isn't sufficient communication it may - drop the ones previously assumed to be properly delivered, reverting back - to the full expensive ElGamal encryption.

        -

        One alternative is to transmit only a single session tag, and from that, - seed a deterministic PRNG for determining what tags to use or expect. By keeping - this PRNG roughly synchronized between the sender and recipient (the recipient - precomputes a window of the next e.g. 50 tags), the overhead of periodically - bundling a large number of tags is removed, allowing more options in the space/time - tradeoff, and perhaps reducing the number of ElGamal encryptions necessary. - However, it would depend upon the strength of the PRNG to provide the necessary - cover against internal adversaries, though perhaps by limiting the amount - of times each PRNG is used, any weaknesses can be minimized. At the moment, - there are no immediate plans to move towards these synchronized PRNGs.

        -

        Future

        -

        While I2P is currently functional and sufficient for many scenarios, there - are several areas which require further improvement to meet the needs of those - facing more powerful adversaries as well as substantial user experience optimization. -

        -

        Restricted route operation

        -

        I2P is an overlay network designed to be run on top of a functional packet - switched network, exploiting the end to end principle to offer anonymity and - security. While the Internet no longer fully embraces the end to end principle - (due to the usage of NAT), - I2P does require a substantial portion of the network to be reachable - there - may be a number of peers along the edges running using restricted routes, - but I2P does not include an appropriate routing algorithm for the degenerate - case where most peers are unreachable. It would, however work on top of a - network employing such an algorithm.

        -

        Restricted route operation, where there are limits to what peers are reachable - directly, has several different functional and anonymity implications, dependent - upon how the restricted routes are handled. At the most basic level, restricted - routes exist when a peer is behind a NAT or firewall which does not allow - inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating - distributed hole punching into the transport layer, allowing people behind - most NATs and firewalls to receive unsolicited connections without any configuration. - However, this does not limit the exposure of the peer's IP address to routers - inside the network, as they can simply get introduced to the peer through - the published introducer.

        -

        Beyond the functional handling of restricted routes, there are two levels - of restricted operation that can be used to limit the exposure of one's IP - address - using router-specific tunnels for communication, and offering 'client - routers'. For the former, routers can either build a new pool of tunnels or - reuse their exploratory pool, publishing the inbound gateways to some of them - as part of their routerInfo in place of their transport addresses. When a - peer wants to get in touch with them, they see those tunnel gateways in the - netDb and simply send the relevant message to them through one of the published - tunnels. If the peer behind the restricted route wants to reply, it may do - so either directly (if they are willing to expose their IP to the peer) or - indirectly through their outbound tunnels. When the routers that the peer - has direct connections to want to reach it (to forward tunnel messages, for - instance), they simply prioritize their direct connection over the published - tunnel gateway. The concept of 'client routers' simply extends the restricted - route by not publishing any router addresses. Such a router would not even - need to publish their routerInfo in the netDb, merely providing their self - signed routerInfo to the peers that it contacts (necessary to pass the router's - public keys). Both levels of restricted route operation are planned for I2P - 2.0.

        -

        There are tradeoffs for those behind restricted routes, as they would likely - participate in other people's tunnels less frequently, and the routers which - they are connected to would be able to infer traffic patterns that would not - otherwise be exposed. On the other hand, if the cost of that exposure is less - than the cost of an IP being made available, it may be worthwhile. This, of - course, assumes that the peers that the router behind a restricted route contacts - are not hostile - either the network is large enough that the probability - of using a hostile peer to get connected is small enough, or trusted (and - perhaps temporary) peers are used instead.

        -

        Variable latency

        -

        Even though the bulk of I2P's initial efforts have been on low latency communication, - it was designed with variable latency services in mind from the beginning. - At the most basic level, applications running on top of I2P can offer the - anonymity of medium and high latency communication while still blending their - traffic patterns in with low latency traffic. Internally though, I2P can offer - its own medium and high latency communication through the garlic encryption - - specifying that the message should be sent after a certain delay, at a certain - time, after a certain number of messages have passed, or another mix strategy. - With the layered encryption, only the router that the clove exposed the delay - request would know that the message requires high latency, allowing the traffic - to blend in further with the low latency traffic. Once the transmission precondition - is met, the router holding on to the clove (which itself would likely be a - garlic message) simply forwards it as requested - to a router, to a tunnel, - or, most likely, to a remote client destination.

        -

        There are a substantial number of ways to exploit this capacity for high - latency comm in I2P, but for the moment, doing so has been scheduled for the - I2P 3.0 release. In the meantime, those requiring the anonymity that high - latency comm can offer should look towards the application layer to provide - it.

        -

        Open questions

        -
        -How to get rid of the timing constraint?
        -Can we deal with the sessionTags more efficiently?
        -What, if any, batching/mixing strategies should be made available on the tunnels?
        -What other tunnel peer selection and ordering strategies should be available?
        -
        -

        Similar systems

        -

        I2P's architecture builds on the concepts of message oriented middleware, - the topology of DHTs, the anonymity and cryptography of free route mixnets, - and the adaptability of packet switched networking. The value comes not from - novel concepts of algorithms though, but from careful engineering combining - the research results of existing systems and papers. While there are a few - similar efforts worth reviewing, both for technical and functional comparisons, - two in particular are pulled out here - Tor and Freenet.

        -

        See also the Network Comparisons Page. -

        + +

        {% trans %}Transport protocols{% endtrans %}

        +

        {% trans -%} +Communication between routers needs to provide confidentiality and integrity +against external adversaries while authenticating that the router contacted +is the one who should receive a given message. The particulars of how routers +communicate with other routers aren't critical - three separate protocols +have been used at different points to provide those bare necessities. +{%- endtrans %}

        + +

        {% trans ssu=site_url('docs/transport/ssu') -%} +I2P started with a TCP-based protocol which +has since been disabled. Then, to accommodate the need for high degree communication +(as a number of routers will end up speaking with many others), I2P moved +from a TCP based transport to a UDP-based one - "Secure +Semireliable UDP", or "SSU". +{%- endtrans %}

        + +

        {% trans ssu=site_url('docs/transport/ssu') -%} +As described in the SSU spec: +{%- endtrans %}

        + +
        {% trans -%} +The goal of this protocol is to provide secure, authenticated, +semireliable and unordered message delivery, exposing only a minimal amount +of data easily discernible to third parties. It should support high degree +communication as well as TCP-friendly congestion control and may include +PMTU detection. It should be capable of efficiently moving bulk data at rates +sufficient for home users. In addition, it should support techniques for addressing +network obstacles, like most NATs or firewalls. +{%- endtrans %}
        + +

        {% trans ntcp=site_url('docs/transport/ntcp') -%} +Following the introduction of SSU, after issues with congestion collapse +appeared, a new NIO-based TCP transport called NTCP +was implemented. It is enabled by default for outbound connections only. Those +who configure their NAT/firewall to allow inbound connections and specify +the external host and port (dyndns/etc is ok) on /config.jsp can receive inbound +connections. As NTCP is NIO based, so it doesn't suffer from the 1 thread +per connection issues of the old TCP transport. +{%- endtrans %}

        + +

        {% trans -%} +I2P supports multiple transports simultaneously. A particular transport +for an outbound connection is selected with "bids". Each transport bids for +the connection and the relative value of these bids assigns the priority. +Transports may reply with different bids, depending on whether there is already +an established connection to the peer. +{%- endtrans %}

        + +

        {% trans ntcp=site_url('docs/transport/ntcp') -%} +The current implementation ranks NTCP as the highest-priority transport +for outbound connections in most situations. SSU is enabled for both outbound +and inbound connections. Your firewall and your I2P router must be configured +to allow inbound NTCP connections. For further information see the NTCP +page. +{%- endtrans %}

        + +

        {% trans %}Cryptography{% endtrans %}

        +

        {% trans -%} +A bare minimum set of cryptographic primitives are combined together to +provide I2P's layered defenses against a variety of adversaries. At the lowest +level, inter router communication is protected by the transport layer security +- SSU encrypts each packet with AES256/CBC with both an explicit IV and MAC +(HMAC-MD5-128) after agreeing upon an ephemeral session key through a 2048bit +Diffie-Hellman exchange, station-to-station authentication with the other +router's DSA key, plus each network message has their own hash for local integrity +checking. Tunnel messages passed over the transports +have their own layered AES256/CBC encryption with an explicit IV and verified +at the tunnel endpoint with an additional SHA256 hash. Various other messages +are passed along inside "garlic messages", which are encrypted with ElGamal/AES+SessionTags +(explained below). +{%- endtrans %}

        + +

        {% trans %}Garlic messages{% endtrans %}

        +

        {% trans -%} +Garlic messages are an extension of "onion" layered encryption, allowing +the contents of a single message to contain multiple "cloves" - fully formed +messages alongside their own instructions for delivery. Messages are wrapped +into a garlic message whenever the message would otherwise be passing in cleartext +through a peer who should not have access to the information - for instance, +when a router wants to ask another router to participate in a tunnel, they +wrap the request inside a garlic, encrypt that garlic to the receiving router's +2048bit ElGamal public key, and forward it through a tunnel. Another example +is when a client wants to send a message to a destination - the sender's router +will wrap up that data message (alongside some other messages) into a garlic, +encrypt that garlic to the 2048bit ElGamal public key published in the recipient's +leaseSet, and forward it through the appropriate tunnels. +{%- endtrans %}

        + +

        {% trans -%} +The "instructions" attached to each clove inside the encryption layer includes +the ability to request that the clove be forwarded locally, to a remote router, +or to a remote tunnel on a remote router. There are fields in those instructions +allowing a peer to request that the delivery be delayed until a certain time +or condition has been met, though they won't be honored until the nontrivial +delays are deployed. It is possible to explicitly route garlic messages +any number of hops without building tunnels, or even to reroute tunnel messages +by wrapping them in garlic messages and forwarding them a number of hops prior +to delivering them to the next hop in the tunnel, but those techniques are +not currently used in the existing implementation. +{%- endtrans %}

        + +

        {% trans %}Session tags{% endtrans %}

        +

        {% trans -%} +As an unreliable, unordered, message based system, I2P uses a simple combination +of asymmetric and symmetric encryption algorithms to provide data confidentiality +and integrity to garlic messages. As a whole, the combination is referred +to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe +the simple use of 2048bit ElGamal, AES256, SHA256 and 32 byte nonces. +{%- endtrans %}

        + +

        {% trans -%} +The first time a router wants to encrypt a garlic message to another router, +they encrypt the keying material for an AES256 session key with ElGamal and +append the AES256/CBC encrypted payload after that encrypted ElGamal block. +In addition to the encrypted payload, the AES encrypted section contains the +payload length, the SHA256 hash of the unencrypted payload, as well as a number +of "session tags" - random 32 byte nonces. The next time the sender wants +to encrypt a garlic message to another router, rather than ElGamal encrypt +a new session key they simply pick one of the previously delivered session +tags and AES encrypt the payload like before, using the session key used with +that session tag, prepended with the session tag itself. When a router receives +a garlic encrypted message, they check the first 32 bytes to see if it matches +an available session tag - if it does, they simply AES decrypt the message, +but if it does not, they ElGamal decrypt the first block. +{%- endtrans %}

        + +

        {% trans -%} +Each session tag can be used only once so as to prevent internal adversaries +from unnecessarily correlating different messages as being between the same +routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses +when and how many tags to deliver, prestocking the recipient with enough tags +to cover a volley of messages. Garlic messages may detect the successful tag +delivery by bundling a small additional message as a clove (a "delivery status +message") - when the garlic message arrives at the intended recipient and +is decrypted successfully, this small delivery status message is one of the +cloves exposed and has instructions for the recipient to send the clove back +to the original sender (through an inbound tunnel, of course). When the original +sender receives this delivery status message, they know that the session tags +bundled in the garlic message were successfully delivered. +{%- endtrans %}

        + +

        {% trans -%} +Session tags themselves have a very short lifetime, after which they are +discarded if not used. In addition, the quantity stored for each key is limited, +as are the number of keys themselves - if too many arrive, either new or old +messages may be dropped. The sender keeps track whether messages using session +tags are getting through, and if there isn't sufficient communication it may +drop the ones previously assumed to be properly delivered, reverting back +to the full expensive ElGamal encryption. +{%- endtrans %}

        + +

        {% trans -%} +One alternative is to transmit only a single session tag, and from that, +seed a deterministic PRNG for determining what tags to use or expect. By keeping +this PRNG roughly synchronized between the sender and recipient (the recipient +precomputes a window of the next e.g. 50 tags), the overhead of periodically +bundling a large number of tags is removed, allowing more options in the space/time +tradeoff, and perhaps reducing the number of ElGamal encryptions necessary. +However, it would depend upon the strength of the PRNG to provide the necessary +cover against internal adversaries, though perhaps by limiting the amount +of times each PRNG is used, any weaknesses can be minimized. At the moment, +there are no immediate plans to move towards these synchronized PRNGs. +{%- endtrans %}

        + +

        {% trans %}Future{% endtrans %}

        +

        {% trans -%} +While I2P is currently functional and sufficient for many scenarios, there +are several areas which require further improvement to meet the needs of those +facing more powerful adversaries as well as substantial user experience optimization. +{%- endtrans %}

        + +

        {% trans %}Restricted route operation{% endtrans %}

        +

        {% trans -%} +I2P is an overlay network designed to be run on top of a functional packet +switched network, exploiting the end to end principle to offer anonymity and +security. While the Internet no longer fully embraces the end to end principle +(due to the usage of NAT), +I2P does require a substantial portion of the network to be reachable - there +may be a number of peers along the edges running using restricted routes, +but I2P does not include an appropriate routing algorithm for the degenerate +case where most peers are unreachable. It would, however work on top of a +network employing such an algorithm. +{%- endtrans %}

        + +

        {% trans -%} +Restricted route operation, where there are limits to what peers are reachable +directly, has several different functional and anonymity implications, dependent +upon how the restricted routes are handled. At the most basic level, restricted +routes exist when a peer is behind a NAT or firewall which does not allow +inbound connections. This was largely addressed in I2P 0.6.0.6 by integrating +distributed hole punching into the transport layer, allowing people behind +most NATs and firewalls to receive unsolicited connections without any configuration. +However, this does not limit the exposure of the peer's IP address to routers +inside the network, as they can simply get introduced to the peer through +the published introducer. +{%- endtrans %}

        + +

        {% trans -%} +Beyond the functional handling of restricted routes, there are two levels +of restricted operation that can be used to limit the exposure of one's IP +address - using router-specific tunnels for communication, and offering 'client +routers'. For the former, routers can either build a new pool of tunnels or +reuse their exploratory pool, publishing the inbound gateways to some of them +as part of their routerInfo in place of their transport addresses. When a +peer wants to get in touch with them, they see those tunnel gateways in the +netDb and simply send the relevant message to them through one of the published +tunnels. If the peer behind the restricted route wants to reply, it may do +so either directly (if they are willing to expose their IP to the peer) or +indirectly through their outbound tunnels. When the routers that the peer +has direct connections to want to reach it (to forward tunnel messages, for +instance), they simply prioritize their direct connection over the published +tunnel gateway. The concept of 'client routers' simply extends the restricted +route by not publishing any router addresses. Such a router would not even +need to publish their routerInfo in the netDb, merely providing their self +signed routerInfo to the peers that it contacts (necessary to pass the router's +public keys). Both levels of restricted route operation are planned for I2P +2.0. +{%- endtrans %}

        + +

        {% trans -%} +There are tradeoffs for those behind restricted routes, as they would likely +participate in other people's tunnels less frequently, and the routers which +they are connected to would be able to infer traffic patterns that would not +otherwise be exposed. On the other hand, if the cost of that exposure is less +than the cost of an IP being made available, it may be worthwhile. This, of +course, assumes that the peers that the router behind a restricted route contacts +are not hostile - either the network is large enough that the probability +of using a hostile peer to get connected is small enough, or trusted (and +perhaps temporary) peers are used instead. +{%- endtrans %}

        + +

        {% trans %}Variable latency{% endtrans %}

        +

        {% trans -%} +Even though the bulk of I2P's initial efforts have been on low latency communication, +it was designed with variable latency services in mind from the beginning. +At the most basic level, applications running on top of I2P can offer the +anonymity of medium and high latency communication while still blending their +traffic patterns in with low latency traffic. Internally though, I2P can offer +its own medium and high latency communication through the garlic encryption +- specifying that the message should be sent after a certain delay, at a certain +time, after a certain number of messages have passed, or another mix strategy. +With the layered encryption, only the router that the clove exposed the delay +request would know that the message requires high latency, allowing the traffic +to blend in further with the low latency traffic. Once the transmission precondition +is met, the router holding on to the clove (which itself would likely be a +garlic message) simply forwards it as requested - to a router, to a tunnel, +or, most likely, to a remote client destination. +{%- endtrans %}

        + +

        {% trans -%} +There are a substantial number of ways to exploit this capacity for high +latency comm in I2P, but for the moment, doing so has been scheduled for the +I2P 3.0 release. In the meantime, those requiring the anonymity that high +latency comm can offer should look towards the application layer to provide +it. +{%- endtrans %}

        + +

        {% trans %}Open questions{% endtrans %}

        +
          +
        • {% trans %}How to get rid of the timing constraint?{% endtrans %}
        • +
        • {% trans %}Can we deal with the sessionTags more efficiently?{% endtrans %}
        • +
        • {% trans %}What, if any, batching/mixing strategies should be made available on the tunnels?{% endtrans %}
        • +
        • {% trans %}What other tunnel peer selection and ordering strategies should be available?{% endtrans %}
        • +
        + +

        {% trans %}Similar systems{% endtrans %}

        + +

        {% trans -%} +I2P's architecture builds on the concepts of message oriented middleware, +the topology of DHTs, the anonymity and cryptography of free route mixnets, +and the adaptability of packet switched networking. The value comes not from +novel concepts of algorithms though, but from careful engineering combining +the research results of existing systems and papers. While there are a few +similar efforts worth reviewing, both for technical and functional comparisons, +two in particular are pulled out here - Tor and Freenet. +{%- endtrans %}

        + +

        {% trans comparisons=site_url('comparison') -%} +See also the Network Comparisons Page. +{%- endtrans %}

        Tor

        -

        website

        -

        At first glance, Tor and I2P have many functional and anonymity related - similarities. While I2P's development began before we were aware of the early - stage efforts on Tor, many of the lessons of the original onion routing and - ZKS efforts were integrated into I2P's design. Rather than building an essentially - trusted, centralized system with directory servers, I2P has a self organizing - network database with each peer taking on the responsibility of profiling - other routers to determine how best to exploit available resources. Another - key difference is that while both I2P and Tor use layered and ordered paths - (tunnels and circuits/streams), I2P is fundamentally a packet switched network, - while Tor is fundamentally a circuit switched one, allowing I2P to transparently - route around congestion or other network failures, operate redundant pathways, - and load balance the data across available resources. While Tor offers the - useful outproxy functionality by offering integrated outproxy discovery and - selection, I2P leaves such application layer decisions up to applications - running on top of I2P - in fact, I2P has even externalized the TCP-like streaming - library itself to the application layer, allowing developers to experiment - with different strategies, exploiting their domain specific knowledge to offer - better performance.

        -

        From an anonymity perspective, there is much similarity when the core networks - are compared. However, there are a few key differences. When dealing with - an internal adversary or most external adversaries, I2P's simplex tunnels - expose half as much traffic data than would be exposed with Tor's duplex circuits - by simply looking at the flows themselves - an HTTP request and response would - follow the same path in Tor, while in I2P the packets making up the request - would go out through one or more outbound tunnels and the packets making up - the response would come back through one or more different inbound tunnels. - While I2P's peer selection and ordering strategies should sufficiently address - predecessor attacks, should a switch to bidirectional tunnels be necessary, - we could simply build an inbound and outbound tunnel along the same routers.

        -

        Another anonymity issue comes up in Tor's use of telescopic tunnel creation, - as simple packet counting and timing measurements as the cells in a circuit - pass through an adversary's node exposes statistical information regarding - where the adversary is within the circuit. I2P's unidirectional tunnel creation - with a single message so that this data is not exposed. Protecting the position - in a tunnel is important, as an adversary would otherwise be able to mount - a series of powerful predecessor, intersection, and traffic confirmation attacks. -

        -

        Tor's support for a second tier of "onion proxies" does offer a non-trivial - degree of anonymity while requiring a low cost of entry, while I2P will not - offer this topology until 2.0.

        -

        On the whole, Tor and I2P complement each other in their focus - Tor works - towards offering high speed anonymous Internet outproxying, while I2P works - towards offering a decentralized resilient network in itself. In theory, both - can be used to achieve both purposes, but given limited development resources, - they both have their strengths and weaknesses. The I2P developers have considered - the steps necessary to modify Tor to take advantage of I2P's design, but concerns - of Tor's viability under resource scarcity suggest that I2P's packet switching - architecture will be able to exploit scarce resources more effectively.

        +

        {% trans %}website{% endtrans %}

        + +

        {% trans -%} +At first glance, Tor and I2P have many functional and anonymity related +similarities. While I2P's development began before we were aware of the early +stage efforts on Tor, many of the lessons of the original onion routing and +ZKS efforts were integrated into I2P's design. Rather than building an essentially +trusted, centralized system with directory servers, I2P has a self organizing +network database with each peer taking on the responsibility of profiling +other routers to determine how best to exploit available resources. Another +key difference is that while both I2P and Tor use layered and ordered paths +(tunnels and circuits/streams), I2P is fundamentally a packet switched network, +while Tor is fundamentally a circuit switched one, allowing I2P to transparently +route around congestion or other network failures, operate redundant pathways, +and load balance the data across available resources. While Tor offers the +useful outproxy functionality by offering integrated outproxy discovery and +selection, I2P leaves such application layer decisions up to applications +running on top of I2P - in fact, I2P has even externalized the TCP-like streaming +library itself to the application layer, allowing developers to experiment +with different strategies, exploiting their domain specific knowledge to offer +better performance. +{%- endtrans %}

        + +

        {% trans -%} +From an anonymity perspective, there is much similarity when the core networks +are compared. However, there are a few key differences. When dealing with +an internal adversary or most external adversaries, I2P's simplex tunnels +expose half as much traffic data than would be exposed with Tor's duplex circuits +by simply looking at the flows themselves - an HTTP request and response would +follow the same path in Tor, while in I2P the packets making up the request +would go out through one or more outbound tunnels and the packets making up +the response would come back through one or more different inbound tunnels. +While I2P's peer selection and ordering strategies should sufficiently address +predecessor attacks, should a switch to bidirectional tunnels be necessary, +we could simply build an inbound and outbound tunnel along the same routers. +{%- endtrans %}

        + +

        {% trans -%} +Another anonymity issue comes up in Tor's use of telescopic tunnel creation, +as simple packet counting and timing measurements as the cells in a circuit +pass through an adversary's node exposes statistical information regarding +where the adversary is within the circuit. I2P's unidirectional tunnel creation +with a single message so that this data is not exposed. Protecting the position +in a tunnel is important, as an adversary would otherwise be able to mount +a series of powerful predecessor, intersection, and traffic confirmation attacks. +{%- endtrans %}

        + +

        {% trans -%} +Tor's support for a second tier of "onion proxies" does offer a non-trivial +degree of anonymity while requiring a low cost of entry, while I2P will not +offer this topology until 2.0. +{%- endtrans %}

        + +

        {% trans -%} +On the whole, Tor and I2P complement each other in their focus - Tor works +towards offering high speed anonymous Internet outproxying, while I2P works +towards offering a decentralized resilient network in itself. In theory, both +can be used to achieve both purposes, but given limited development resources, +they both have their strengths and weaknesses. The I2P developers have considered +the steps necessary to modify Tor to take advantage of I2P's design, but concerns +of Tor's viability under resource scarcity suggest that I2P's packet switching +architecture will be able to exploit scarce resources more effectively. +{%- endtrans %}

        Freenet

        -

        website

        -

        Freenet played a large part in the initial stages of I2P's design - giving - proof to the viability of a vibrant pseudonymous community completely contained - within the network, demonstrating that the dangers inherent in outproxies - could be avoided. The first seed of I2P began as a replacement communication - layer for Freenet, attempting to factor out the complexities of a scalable, - anonymous and secure point to point communication from the complexities of - a censorship resistant distributed data store. Over time however, some of - the anonymity and scalability issues inherent in Freenet's algorithms made - it clear that I2P's focus should stay strictly on providing a generic anonymous - communication layer, rather than as a component of Freenet. Over the years, - the Freenet developers have come to see the weaknesses in the older design, - prompting them to suggest that they will require a "premix" layer to offer - substantial anonymity. In other words, Freenet needs to run on top of a mixnet - such as I2P or Tor, with "client nodes" requesting and publishing data through - the mixnet to the "server nodes" which then fetch and store the data according - to Freenet's heuristic distributed data storage algorithms.

        -

        Freenet's functionality is very complementary to I2P's, as Freenet natively - provides many of the tools for operating medium and high latency systems, - while I2P natively provides the low latency mix network suitable for offering - adequate anonymity. The logic of separating the mixnet from the censorship- - resistant distributed data store still seems self-evident from an engineering, - anonymity, security, and resource allocation perspective, so hopefully the - Freenet team will pursue efforts in that direction, if not simply reusing - (or helping to improve, as necessary) existing mixnets like I2P or Tor.

        -

        It is worth mentioning that there has recently been discussion and work - by the Freenet developers on a "globally scalable darknet" using restricted - routes between peers of various trust. While insufficient information has - been made publicly available regarding how such a system would operate for - a full review, from what has been said the anonymity and scalability claims - seem highly dubious. In particular, the appropriateness for use in hostile - regimes against state level adversaries has been tremendously overstated, - and any analysis on the implications of resource scarcity upon the scalability - of the network has seemingly been avoided. Further questions regarding susceptibility - to traffic analysis, trust and other topics do exist, but a more in-depth - review of this "globally scalable darknet" will have to wait until the Freenet - team makes more information available.

        +

        {% trans %}website{% endtrans %}

        + +

        {% trans -%} +Freenet played a large part in the initial stages of I2P's design - giving +proof to the viability of a vibrant pseudonymous community completely contained +within the network, demonstrating that the dangers inherent in outproxies +could be avoided. The first seed of I2P began as a replacement communication +layer for Freenet, attempting to factor out the complexities of a scalable, +anonymous and secure point to point communication from the complexities of +a censorship resistant distributed data store. Over time however, some of +the anonymity and scalability issues inherent in Freenet's algorithms made +it clear that I2P's focus should stay strictly on providing a generic anonymous +communication layer, rather than as a component of Freenet. Over the years, +the Freenet developers have come to see the weaknesses in the older design, +prompting them to suggest that they will require a "premix" layer to offer +substantial anonymity. In other words, Freenet needs to run on top of a mixnet +such as I2P or Tor, with "client nodes" requesting and publishing data through +the mixnet to the "server nodes" which then fetch and store the data according +to Freenet's heuristic distributed data storage algorithms. +{%- endtrans %}

        + +

        {% trans -%} +Freenet's functionality is very complementary to I2P's, as Freenet natively +provides many of the tools for operating medium and high latency systems, +while I2P natively provides the low latency mix network suitable for offering +adequate anonymity. The logic of separating the mixnet from the censorship- +resistant distributed data store still seems self-evident from an engineering, +anonymity, security, and resource allocation perspective, so hopefully the +Freenet team will pursue efforts in that direction, if not simply reusing +(or helping to improve, as necessary) existing mixnets like I2P or Tor. +{%- endtrans %}

        + +

        {% trans -%} +It is worth mentioning that there has recently been discussion and work +by the Freenet developers on a "globally scalable darknet" using restricted +routes between peers of various trust. While insufficient information has +been made publicly available regarding how such a system would operate for +a full review, from what has been said the anonymity and scalability claims +seem highly dubious. In particular, the appropriateness for use in hostile +regimes against state level adversaries has been tremendously overstated, +and any analysis on the implications of resource scarcity upon the scalability +of the network has seemingly been avoided. Further questions regarding susceptibility +to traffic analysis, trust and other topics do exist, but a more in-depth +review of this "globally scalable darknet" will have to wait until the Freenet +team makes more information available. +{%- endtrans %}

        Appendix A: Application layer

        +

        {% trans -%} +I2P itself doesn't really do much - it simply sends messages to remote destinations +and receives messages targeting local destinations - most of the interesting +work goes on at the layers above it. By itself, I2P could be seen as an anonymous +and secure IP layer, and the bundled streaming library +as an implementation of an anonymous and secure TCP layer on top of it. Beyond +that, I2PTunnel exposes a generic TCP proxying +system for either getting into or out of the I2P network, plus a variety of +network applications provide further functionality for end users. +{%- endtrans %}

        -

        - I2P itself doesn't really do much - it simply sends messages to remote destinations - and receives messages targeting local destinations - most of the interesting - work goes on at the layers above it. By itself, I2P could be seen as an anonymous - and secure IP layer, and the bundled streaming library - as an implementation of an anonymous and secure TCP layer on top of it. Beyond - that, I2PTunnel exposes a generic TCP proxying - system for either getting into or out of the I2P network, plus a variety of - network applications provide further functionality for end users. -

        +

        {% trans %}Streaming library{% endtrans %}

        +

        {% trans -%} +The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets), +and the implementation supports a sliding window protocol +with several optimizations, to take into account the high delay over I2P. +Individual streams may adjust the maximum packet size and +other options, though the default of 4KB compressed seems a reasonable tradeoff +between the bandwidth costs of retransmitting lost messages and the latency +of multiple messages. +{%- endtrans %}

        -

        Streaming library

        -

        - The I2P streaming library can be viewed as a generic streaming interface (mirroring TCP sockets), - and the implementation supports a sliding window protocol - with several optimizations, to take into account the high delay over I2P. - Individual streams may adjust the maximum packet size and - other options, though the default of 4KB compressed seems a reasonable tradeoff - between the bandwidth costs of retransmitting lost messages and the latency - of multiple messages. -

        -

        - In addition, in consideration of the relatively high cost of subsequent - messages, the streaming library's protocol for scheduling and delivering messages - has been optimized to allow individual messages passed to contain as much - information as is available. For instance, a small HTTP transaction proxied - through the streaming library can be completed in a single round trip - the - first message bundles a SYN, FIN and the small payload (an HTTP request typically - fits) and the reply bundles the SYN, FIN, ACK and the small payload (many - HTTP responses fit). While an additional ACK must be transmitted to tell the - HTTP server that the SYN/FIN/ACK has been received, the local HTTP proxy can - deliver the full response to the browser immediately. -

        -

        - On the whole, however, the streaming library bears much resemblance to an - abstraction of TCP, with its sliding windows, congestion control algorithms - (both slow start and congestion avoidance), and general packet behavior (ACK, - SYN, FIN, RST, etc). -

        +

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

        -

        Naming library and addressbook

        -

        For more information see the Naming and Addressbook - page.

        -

        Developed by: mihi, Ragnarok

        -

        Naming within I2P has been an oft-debated topic since the very beginning - with advocates across the spectrum of possibilities. However, given I2P's - inherent demand for secure communication and decentralized operation, the - traditional DNS-style naming system is clearly out, as are "majority rules" - voting systems. Instead, I2P ships with a generic naming library and a base - implementation designed to work off a local name to destination mapping, as - well as an optional add-on application called the "addressbook". The addressbook - is a web-of-trust-driven secure, distributed, and human readable naming system, - sacrificing only the call for all human readable names to be globally unique - by mandating only local uniqueness. While all messages in I2P are cryptographically - addressed by their destination, different people can have local addressbook - entries for "Alice" which refer to different destinations. People can still - discover new names by importing published addressbooks of peers specified - in their web of trust, by adding in the entries provided through a third party, - or (if some people organize a series of published addressbooks using a first - come first serve registration system) people can choose to treat these addressbooks - as name servers, emulating traditional DNS.

        -

        I2P does not promote the use of DNS-like services though, as the damage - done by hijacking a site can be tremendous - and insecure destinations have - no value. DNSsec itself still falls back on registrars and certificate authorities, - while with I2P, requests sent to a destination cannot be intercepted or the - reply spoofed, as they are encrypted to the destination's public keys, and - a destination itself is just a pair of public keys and a certificate. DNS-style - systems on the other hand allow any of the name servers on the lookup path - to mount simple denial of service and spoofing attacks. Adding on a certificate - authenticating the responses as signed by some centralized certificate authority - would address many of the hostile nameserver issues but would leave open replay - attacks as well as hostile certificate authority attacks.

        -

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

        -

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

        +

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

        + +

        {% trans %}Naming library and addressbook{% endtrans %}

        +

        {% trans naming=site_url('docs/naming') -%} +For more information see the Naming and Addressbook page. +{%- endtrans %}

        + +

        {% trans dev='mihi, Ragnarok' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +Naming within I2P has been an oft-debated topic since the very beginning +with advocates across the spectrum of possibilities. However, given I2P's +inherent demand for secure communication and decentralized operation, the +traditional DNS-style naming system is clearly out, as are "majority rules" +voting systems. Instead, I2P ships with a generic naming library and a base +implementation designed to work off a local name to destination mapping, as +well as an optional add-on application called the "addressbook". The addressbook +is a web-of-trust-driven secure, distributed, and human readable naming system, +sacrificing only the call for all human readable names to be globally unique +by mandating only local uniqueness. While all messages in I2P are cryptographically +addressed by their destination, different people can have local addressbook +entries for "Alice" which refer to different destinations. People can still +discover new names by importing published addressbooks of peers specified +in their web of trust, by adding in the entries provided through a third party, +or (if some people organize a series of published addressbooks using a first +come first serve registration system) people can choose to treat these addressbooks +as name servers, emulating traditional DNS. +{%- endtrans %}

        + +

        {% trans -%} +I2P does not promote the use of DNS-like services though, as the damage +done by hijacking a site can be tremendous - and insecure destinations have +no value. DNSsec itself still falls back on registrars and certificate authorities, +while with I2P, requests sent to a destination cannot be intercepted or the +reply spoofed, as they are encrypted to the destination's public keys, and +a destination itself is just a pair of public keys and a certificate. DNS-style +systems on the other hand allow any of the name servers on the lookup path +to mount simple denial of service and spoofing attacks. Adding on a certificate +authenticating the responses as signed by some centralized certificate authority +would address many of the hostile nameserver issues but would leave open replay +attacks as well as hostile certificate authority attacks. +{%- endtrans %}

        + +

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

        + +

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

        Syndie

        -

        The old Syndie bundled with I2P has been replaced by the new Syndie which - is distributed separately. For more information see the Syndie - pages.

        -

        Syndie is a safe, anonymous blogging / content publication / content aggregation - system. It lets you create information, share it with others, and read posts - from those you're interested in, all while taking into consideration your - needs for security and anonymity. Rather than building its own content distribution - network, Syndie is designed to run on top of existing networks, syndicating - content through eepsites, Tor hidden services, Freenet freesites, normal websites, - usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie - is done so as to offer pseudonymous authentication to anyone reading or archiving - it.

        +

        {% trans -%} +The old Syndie bundled with I2P has been replaced by the new Syndie which +is distributed separately. For more information see the Syndie +pages. +{%- endtrans %}

        + +

        {% trans -%} +Syndie is a safe, anonymous blogging / content publication / content aggregation +system. It lets you create information, share it with others, and read posts +from those you're interested in, all while taking into consideration your +needs for security and anonymity. Rather than building its own content distribution +network, Syndie is designed to run on top of existing networks, syndicating +content through eepsites, Tor hidden services, Freenet freesites, normal websites, +usenet newsgroups, email lists, RSS feeds, etc. Data published with Syndie +is done so as to offer pseudonymous authentication to anyone reading or archiving +it. +{%- endtrans %}

        I2PTunnel

        -

        Developed by: mihi

        -

        I2PTunnel is probably I2P's most popular and versatile client application, - allowing generic proxying both into and out of the I2P network. I2PTunnel - can be viewed as four separate proxying applications - a "client" which receives - inbound TCP connections and forwards them to a given I2P destination, an "httpclient" - (aka "eepproxy") which acts like an HTTP proxy and forwards the requests to - the appropriate I2P destination (after querying the naming service if necessary), - a "server" which receives inbound I2P streaming connections on a destination - and forwards them to a given TCP host+port, and an "httpserver" which extends - the "server" by parsing the HTTP request and responses to allow safer operation. - There is an additional "socksclient" application, but its use is not encouraged - for reasons previously mentioned.

        -

        I2P itself is not an outproxy network - the anonymity and security concerns - inherent in a mix net which forwards data into and out of the mix have kept - I2P's design focused on providing an anonymous network which capable of meeting - the user's needs without requiring external resources. However, the I2PTunnel - "httpclient" application offers a hook for outproxying - if the hostname requested - doesn't end in ".i2p", it picks a random destination from a user-provided - set of outproxies and forwards the request to them. These destinations are - simply I2PTunnel "server" instances run by volunteers who have explicitly - chosen to run outproxies - no one is an outproxy by default, and running an - outproxy doesn't automatically tell other people to proxy through you. While - outproxies do have inherent weaknesses, they offer a simple proof of concept - for using I2P and provide some functionality under a threat model which may - be sufficient for some users.

        -

        I2PTunnel enables most of the applications in use. An "httpserver" pointing - at a webserver lets anyone run their own anonymous website (or "eepsite") - - a webserver is bundled with I2P for this purpose, but any webserver can - be used. Anyone may run a "client" pointing at one of the anonymously hosted - IRC servers, each of which are running a "server" pointing at their local - IRCd and communicating between IRCds over their own "client" tunnels. End - users also have "client" tunnels pointing at I2Pmail's - POP3 and SMTP destinations (which in turn are simply "server" instances pointing - at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS - server, allowing anonymous development. At times people have even run "client" - proxies to access the "server" instances pointing at an NNTP server.

        +

        {% trans dev='mihi' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +I2PTunnel is probably I2P's most popular and versatile client application, +allowing generic proxying both into and out of the I2P network. I2PTunnel +can be viewed as four separate proxying applications - a "client" which receives +inbound TCP connections and forwards them to a given I2P destination, an "httpclient" +(aka "eepproxy") which acts like an HTTP proxy and forwards the requests to +the appropriate I2P destination (after querying the naming service if necessary), +a "server" which receives inbound I2P streaming connections on a destination +and forwards them to a given TCP host+port, and an "httpserver" which extends +the "server" by parsing the HTTP request and responses to allow safer operation. +There is an additional "socksclient" application, but its use is not encouraged +for reasons previously mentioned. +{%- endtrans %}

        + +

        {% trans -%} +I2P itself is not an outproxy network - the anonymity and security concerns +inherent in a mix net which forwards data into and out of the mix have kept +I2P's design focused on providing an anonymous network which capable of meeting +the user's needs without requiring external resources. However, the I2PTunnel +"httpclient" application offers a hook for outproxying - if the hostname requested +doesn't end in ".i2p", it picks a random destination from a user-provided +set of outproxies and forwards the request to them. These destinations are +simply I2PTunnel "server" instances run by volunteers who have explicitly +chosen to run outproxies - no one is an outproxy by default, and running an +outproxy doesn't automatically tell other people to proxy through you. While +outproxies do have inherent weaknesses, they offer a simple proof of concept +for using I2P and provide some functionality under a threat model which may +be sufficient for some users. +{%- endtrans %}

        + +

        {% trans -%} +I2PTunnel enables most of the applications in use. An "httpserver" pointing +at a webserver lets anyone run their own anonymous website (or "eepsite") +- a webserver is bundled with I2P for this purpose, but any webserver can +be used. Anyone may run a "client" pointing at one of the anonymously hosted +IRC servers, each of which are running a "server" pointing at their local +IRCd and communicating between IRCds over their own "client" tunnels. End +users also have "client" tunnels pointing at I2Pmail's +POP3 and SMTP destinations (which in turn are simply "server" instances pointing +at POP3 and SMTP servers), as well as "client" tunnels pointing at I2P's CVS +server, allowing anonymous development. At times people have even run "client" +proxies to access the "server" instances pointing at an NNTP server. +{%- endtrans %}

        i2p-bt

        -

        Developed by: duck, et al

        -

        i2p-bt is a port of the mainline python BitTorrent client to run both the - tracker and peer communication over I2P. Tracker requests are forwarded through - the eepproxy to eepsites specified in the torrent file while tracker responses - refer to peers by their destination explicitly, allowing i2p-bt to open up - a streaming lib connection to query them for - blocks.

        -

        In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making - a few modifications as necessary to strip any anonymity-compromising information - from the application and to take into consideration the fact that IPs cannot - be used for identifying peers.

        +

        {% trans dev='duck, et al' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +i2p-bt is a port of the mainline python BitTorrent client to run both the +tracker and peer communication over I2P. Tracker requests are forwarded through +the eepproxy to eepsites specified in the torrent file while tracker responses +refer to peers by their destination explicitly, allowing i2p-bt to open up +a streaming lib connection to query them for +blocks. +{%- endtrans %}

        + +

        {% trans -%} +In addition to i2p-bt, a port of bytemonsoon has been made to I2P, making +a few modifications as necessary to strip any anonymity-compromising information +from the application and to take into consideration the fact that IPs cannot +be used for identifying peers. +{%- endtrans %}

        I2PSnark

        -

        I2PSnark developed: jrandom, et al, ported from {% trans -%} +I2PSnark developed: jrandom, et al, ported from mjw's Snark client

        -

        Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent - client with multitorrent capabilities, exposing all of the functionality through - a plain HTML web interface.

        +href="http://www.klomp.org/snark/">Snark client +{%- endtrans %}

        + +

        {% trans -%} +Bundled with the I2P install, I2PSnark offers a simple anonymous BitTorrent +client with multitorrent capabilities, exposing all of the functionality through +a plain HTML web interface. +{%- endtrans %}

        Robert

        -

        Developed by: sponge

        -

        Robert is a Bittorrent client written in Python. - It is hosted on http://bob.i2p/Robert.html

        +

        {% trans dev='sponge' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans bob=i2pconv('bob.i2p') -%} +Robert is a Bittorrent client written in Python. +It is hosted on http://{{ bob }}/Robert.html +{%- endtrans %}

        PyBit

        -

        Developed by: Blub

        -

        PyBit is a Bittorrent client written in Python. - It is hosted on http://pebcache.i2p/

        +

        {% trans dev='Blub' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans pebcache=i2pconv('pebcache.i2p') -%} +PyBit is a Bittorrent client written in Python. +It is hosted on http://{{ pebcache }}/ +{%- endtrans %}

        I2Phex

        -

        Developed by: sirup

        -

        I2Phex is a fairly direct port of the Phex Gnutella filesharing client to - run entirely on top of I2P. While it has disabled some of Phex's functionality, - such as integration with Gnutella webcaches, the basic file sharing and chatting - system is fully functional.

        -

        iMule

        -

        Developed by: mkvore

        -

        iMule is a fairly direct port of the aMule filesharing client - running entirely inside I2P.

        +

        {% trans dev='sirup' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +I2Phex is a fairly direct port of the Phex Gnutella filesharing client to +run entirely on top of I2P. While it has disabled some of Phex's functionality, +such as integration with Gnutella webcaches, the basic file sharing and chatting +system is fully functional. +{%- endtrans %}

        + +

        iMule

        +

        {% trans dev='mkvore' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +iMule is a fairly direct port of the aMule filesharing client +running entirely inside I2P. +{%- endtrans %}

        +

        I2Pmail/susimail

        -

        Developed by: postman, susi23, mastiejaner

        -

        I2Pmail is more a service than an application - postman offers both internal - and external email with POP3 and SMTP service through I2PTunnel instances - accessing a series of components developed with mastiejaner, allowing people - to use their preferred mail clients to send and receive mail pseudonymously. - However, as most mail clients expose substantial identifying information, - I2P bundles susi23's web based susimail client which has been built specifically - with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent - virus filtering as well as denial of service prevention with hashcash augmented - quotas. In addition, each user has control of their batching strategy prior - to delivery through the mail.i2p outproxies, which are separate from the mail.i2p - SMTP and POP3 servers - both the outproxies and inproxies communicate with - the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those - non-anonymous locations does not give access to the mail accounts or activity - patterns of the user. At the moment the developers work on a decentralized - mailsystem, called "v2mail". More information can be found on the eepsite - hq.postman.i2p.

        +

        {% trans dev='postman, susi23, mastiejaner' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans postman=i2pconv('hq.postman.i2p') -%} +I2Pmail is more a service than an application - postman offers both internal +and external email with POP3 and SMTP service through I2PTunnel instances +accessing a series of components developed with mastiejaner, allowing people +to use their preferred mail clients to send and receive mail pseudonymously. +However, as most mail clients expose substantial identifying information, +I2P bundles susi23's web based susimail client which has been built specifically +with I2P's anonymity needs in mind. The I2Pmail/mail.i2p service offers transparent +virus filtering as well as denial of service prevention with hashcash augmented +quotas. In addition, each user has control of their batching strategy prior +to delivery through the mail.i2p outproxies, which are separate from the mail.i2p +SMTP and POP3 servers - both the outproxies and inproxies communicate with +the mail.i2p SMTP and POP3 servers through I2P itself, so compromising those +non-anonymous locations does not give access to the mail accounts or activity +patterns of the user. At the moment the developers work on a decentralized +mailsystem, called "v2mail". More information can be found on the eepsite +{{ postman }}. +{%- endtrans %}

        I2P-Bote

        -

        Developed by: HungryHobo

        -

        - I2P-Bote is a distributed e-mail application. It does not use the traditional - e-mail concept of sending an e-mail to a server and retrieving it from a server. - Instead, it uses a Kademlia Distributed Hash Table to store mails. - One user can push a mail into the DHT, while another can request the e-mail from the DHT. - And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end.
        - Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity. -

        +

        {% trans dev='HungryHobo' -%}Developed by: {{ dev }}{%- endtrans %}

        + +

        {% trans -%} +I2P-Bote is a distributed e-mail application. It does not use the traditional +e-mail concept of sending an e-mail to a server and retrieving it from a server. +Instead, it uses a Kademlia Distributed Hash Table to store mails. +One user can push a mail into the DHT, while another can request the e-mail from the DHT. +And all the mails sent within the I2P-Bote network are automatically encrypted end-to-end.
        +Furthermore, I2P-Bote offers a remailer function on top of I2P, for increased high-latency anonymity. +{%- endtrans %}

        I2P-Messenger

        -

        - I2P-Messenger is an end-to-end encrypted serverless communication application. - For communication between two users, they need to give each other their destination keys, to allow the other to connect. - It supports file transfer and has a search for other users, based on Seedless. -

        +

        {% trans -%} +I2P-Messenger is an end-to-end encrypted serverless communication application. +For communication between two users, they need to give each other their destination keys, to allow the other to connect. +It supports file transfer and has a search for other users, based on Seedless. +{%- endtrans %}

        {% endblock %} From ae9ca4497e2189fdd8e537d57f214025792ab722 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 10:49:46 +0000 Subject: [PATCH 369/498] Added translation tags to docs/how/garlic-routing --- .../pages/site/docs/how/garlic-routing.html | 252 +++++++++++------- 1 file changed, 152 insertions(+), 100 deletions(-) diff --git a/i2p2www/pages/site/docs/how/garlic-routing.html b/i2p2www/pages/site/docs/how/garlic-routing.html index 9bf8daf8..767b2018 100644 --- a/i2p2www/pages/site/docs/how/garlic-routing.html +++ b/i2p2www/pages/site/docs/how/garlic-routing.html @@ -1,69 +1,80 @@ {% extends "global/layout.html" %} -{% block title %}Garlic Routing{% endblock %} -{% block lastupdated %}August 2010{% endblock %} +{% block title %}{% trans %}Garlic Routing{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        Garlic Routing and "Garlic" Terminology

        -

        +

        {% trans %}Garlic Routing and "Garlic" Terminology{% endtrans %}

        +

        {% trans -%} The terms "garlic routing" and "garlic encryption" are often used rather loosely when referring to I2P's technology. Here, we explain the history of the terms, the various meanings, and the usage of "garlic" methods in I2P. -

        +{%- endtrans %}

        + +

        {% trans -%} "Garlic routing" was first coined by Michael J. Freedman in Roger Dingledine's Free Haven Master's thesis Section 8.1.1 (June 2000), as derived from Onion Routing. -

        +{%- endtrans %}

        + +

        {% trans -%} "Garlic" may have been used originally by I2P developers because I2P implements a form of bundling as Freedman describes, or simply to emphasize general differences from Tor. The specific reasoning may be lost to history. Generally, when referring to I2P, the term "garlic" may mean one of three things: -

        1. -Layered Encryption -
        2. -Bundling multiple messages together -
        3. -ElGamal/AES Encryption -
        +{%- endtrans %}

        +
          +
        1. {% trans %}Layered Encryption{% endtrans %}
        2. +
        3. {% trans %}Bundling multiple messages together{% endtrans %}
        4. +
        5. {% trans %}ElGamal/AES Encryption{% endtrans %}
        6. +
        + +

        {% trans -%} Unfortunately, I2P's usage of "garlic" terminology over the past seven years has not always been precise; therefore the reader is cautioned when encountering the term. Hopefully, the explanation below will make things clear. -

        +{%- endtrans %}

        -

        Layered Encryption

        -

        +

        {% trans %}Layered Encryption{% endtrans %}

        +

        {% trans -%} Onion routing is a technique for building paths, or tunnels, through a series of peers, and then using that tunnel. Messages are repeatedly encrypted by the originator, and then decrypted by each hop. During the building phase, only the routing instructions for the next hop are exposed to each peer. During the operating phase, messages are passed through the tunnel, and the message and its routing instructions are only exposed to the endpoint of the tunnel. -

        +{%- endtrans %}

        + +

        {% trans comparisons=site_url('comparison') -%} This is similar to the way Mixmaster -(see network comparisons) sends messages - taking a message, encrypting it +(see network comparisons) sends messages - taking a message, encrypting it to the recipient's public key, taking that encrypted message and encrypting it (along with instructions specifying the next hop), and then taking that resulting encrypted message and so on, until it has one layer of encryption per hop along the path. -

        +{%- endtrans %}

        + +

        {% trans -%} In this sense, "garlic routing" as a general concept is identical to "onion routing". As implemented in I2P, of course, there are several differences from the implementation in Tor; see below. Even so, there are substantial similarities such that I2P benefits from a large amount of academic research on onion routing, Tor, and similar mixnets. -

        +{%- endtrans %}

        -

        Bundling Multiple Messages

        -

        +

        {% trans %}Bundling Multiple Messages{% endtrans %}

        +

        {% trans -%} Michael Freedman defined "garlic routing" as an extension to onion routing, in which multiple messages are bundled together. He called each message a "bulb". All the messages, each with its own delivery instructions, are exposed at the endpoint. This allows the efficient bundling of an onion routing "reply block" with the original message. -

        +{%- endtrans %}

        + +

        {% trans -%} This concept is implemented in I2P, as described below. Our term for garlic "bulbs" is "cloves". Any number of messages can be @@ -71,88 +82,107 @@ contained, instead of just a single message. This is a significant distinction from the onion routing implemented in Tor. However, it is only one of many major architectural differences between I2P and Tor; perhaps it is not, by itself, enough to justify a change in terminology. +{%- endtrans %}

        -

        +

        {% trans -%} Another difference from the method described by Freedman is that the path is unidirectional - there is no "turning point" as seen in onion routing or mixmaster reply blocks, which greatly simplifies the algorithm and allows for more flexible and reliable delivery. -

        +{%- endtrans %}

        -

        ElGamal/AES Encryption

        +

        {% trans %}ElGamal/AES Encryption{% endtrans %}

        +

        {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%} In some cases, "garlic encryption" may simply mean -ElGamal/AES+SessionTag encryption +ElGamal/AES+SessionTag encryption (without multiple layers). +{%- endtrans %}

        -

        "Garlic" Methods in I2P

        - -

        +

        {% trans %}"Garlic" Methods in I2P{% endtrans %}

        +

        {% trans -%} Now that we've defined various "garlic" terms, we can say that I2P uses garlic routing, bundling and encryption in three places: +{%- endtrans %}

          -
        1. For building and routing through tunnels (layered encryption) -
        2. For determining the success or failure of end to end message delivery (bundling) -
        3. For publishing some network database entries (dampening the probability of a successful traffic analysis attack) - (ElGamal/AES) +
        4. {% trans %}For building and routing through tunnels (layered encryption){% endtrans %} +
        5. {% trans %}For determining the success or failure of end to end message delivery (bundling){% endtrans %} +
        6. {% trans %}For publishing some network database entries (dampening the probability of a successful traffic analysis attack) (ElGamal/AES){% endtrans %}
        -

        + +

        {% trans -%} There are also significant ways that this technique can be used to improve the performance of the network, exploiting transport latency/throughput tradeoffs, and branching data through redundant paths to increase reliability. +{%- endtrans %}

        -

        Tunnel Building and Routing

        -

        +

        {% trans %}Tunnel Building and Routing{% endtrans %}

        +

        {% trans -%} In I2P, tunnels are unidirectional. Each party builds two tunnels, one for outbound and one for inbound traffic. Therefore, four tunnels are required for a single round-trip message and reply. -

        +{%- endtrans %}

        + +

        {% trans tunnelimpl=site_url('docs/tunnels/implementation'), +tunnelcreation=site_url('docs/spec/tunnel-creation'), +elgamalaes=site_url('docs/how/elgamal-aes') -%} Tunnels are built, and then used, with layered encryption. This is described on the -tunnel implementation page. +tunnel implementation page. Tunnel building details are defined on -this page. +this page. We use -ElGamal/AES+SessionTag for the encryption. -

        +ElGamal/AES+SessionTag for the encryption. +{%- endtrans %}

        + +

        {% trans i2np=site_url('docs/protocol/i2np'), i2npspec=site_url('docs/spec/i2np') -%} Tunnels are a general-purpose mechanism to transport all -I2NP messages, and -Garlic Messages are not used to build tunnels. +I2NP messages, and +Garlic Messages are not used to build tunnels. We do not bundle multiple -I2NP messages into a single -Garlic Message for unwrapping at the outbound tunnel endpoint; +I2NP messages into a single +Garlic Message for unwrapping at the outbound tunnel endpoint; the tunnel encryption is sufficient. -

        +{%- endtrans %}

        -

        End-to-End Message Bundling

        -

        +

        {% trans %}End-to-End Message Bundling{% endtrans %}

        +

        {% trans commonstructures=site_url('docs/spec/common-structures'), +elgamalaes=site_url('docs/how/elgamal-aes'), +i2cp=site_url('docs/protocol/i2cp'), +i2npspec=site_url('docs/spec/i2np'), +tunnelmessage=site_url('docs/spec/tunnel-message') -%} At the layer above tunnels, I2P delivers end-to-end messages between -Destinations. +Destinations. Just as within a single tunnel, we use -ElGamal/AES+SessionTag for the encryption. +ElGamal/AES+SessionTag for the encryption. Each client message as delivered to the router through the -I2CP interface becomes a single -Garlic Clove +I2CP interface becomes a single +Garlic Clove with its own -Delivery Instructions, +Delivery Instructions, inside a -Garlic Message. +Garlic Message. Delivery Instructions may specify a Destination, Router, or Tunnel. -

        +{%- endtrans %}

        + +

        {% trans -%} Generally, a Garlic Message will contain only one clove. However, the router will periodically bundle two additional cloves in the Garlic Message: -Garlic Message Cloves +{%- endtrans %}

        +{{ _('Garlic Message Cloves') }} -
        1. +
            +
          1. {% trans i2npspec=site_url('docs/spec/i2np'), +tunnelmessage=site_url('docs/spec/tunnel-message') -%} A -Delivery Status Message, +Delivery Status Message, with -Delivery Instructions +Delivery Instructions specifying that it be sent back to the originating router as an acknowledgment. This is similar to the "reply block" or "reply onion" described in the references. @@ -160,99 +190,121 @@ It is used for determining the success or failure of end to end message delivery The originating router may, upon failure to receive the Delivery Status Message within the expected time period, modify the routing to the far-end Destination, or take other actions. - -
          2. +{%- endtrans %}
          3. +
          4. {% trans i2npspec=site_url('docs/spec/i2np'), +commonstructures=site_url('docs/spec/common-structures'), +tunnelmessage=site_url('docs/spec/tunnel-message'), +netdb=site_url('docs/how/network-database') -%} A -Database Store Message, +Database Store Message, containing a -LeaseSet +LeaseSet for the originating Destination, with -Delivery Instructions +Delivery Instructions specifying the far-end destination's router. By periodically bundling a LeaseSet, the router ensures that the far-end will be able to maintain communications. Otherwise the far-end would have to query a floodfill router for the network database entry, and all LeaseSets would have to be published to the network database, as explained on the -network database page. -
          +network database page. +{%- endtrans %}
        2. +
        -

        +

        {% trans commonstructures=site_url('docs/spec/common-structures') -%} In the current implementation, the Delivery Status and Database Store Messages are bundled when the local LeaseSet changes, when additional -Session Tags +Session Tags are delivered, or if the messages have not been bundled in the previous minute. +{%- endtrans %}

        -

        +

        {% trans -%} Obviously, the additional messages are currently bundled for specific purposes, and not part of a general-purpose routing scheme. -

        +{%- endtrans %}

        -

        Storage to the Floodfill Network Database

        -

        + +

        {% trans %}Storage to the Floodfill Network Database{% endtrans %}

        +

        {% trans netdb=site_url('docs/how/network-database'), +commonstructures=site_url('docs/spec/common-structures'), +i2npspec=site_url('docs/spec/i2np') -%} As explained on the -network database page, +network database page, local -LeaseSets +LeaseSets are sent to floodfill routers in a -Database Store Message +Database Store Message wrapped in a -Garlic Message +Garlic Message so it is not visible to the tunnel's outbound gateway. -

        +{%- endtrans %}

        -

        Future Work

        -

        +

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

        +

        {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%} The Garlic Message mechanism is very flexible and provides a structure for implementing many types of mixnet delivery methods. Together with the unused delay option in the -tunnel message Delivery Instructions, +tunnel message Delivery Instructions, a wide spectrum of batching, delay, mixing, and routing strategies are possible. -

        +{%- endtrans %}

        + +

        {% trans -%} In particular, there is potential for much more flexibility at the outbound tunnel endpoint. Messages could possibly be routed from there to one of several tunnels (thus minimizing point-to-point connections), or multicast to several tunnels for redundancy, or streaming audio and video. -

        +{%- endtrans %}

        + +

        {% trans -%} Such experiments may conflict with the need to ensure security and anonymity, such as limiting certain routing paths, restricting the types of I2NP messages that may be forwarded along various paths, and enforcing certain message expiration times. -

        +{%- endtrans %}

        + +

        {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%} As a part of -ElGamal/AES encryption, +ElGamal/AES encryption, a garlic message contains a sender specified amount of padding data, allowing the sender to take active countermeasures against traffic analysis. This is not currently used, beyond the requirement to pad to a multiple of 16 bytes. -

        +{%- endtrans %}

        + +

        {% trans netdb=site_url('docs/how/network-database') -%} Encryption of additional messages to and from the -floodfill routers. -

        +floodfill routers. +{%- endtrans %}

        -

        References

        - {% endblock %} From 7a4c7df89928e43f4e0bb60a1d91021157386f28 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 19:50:20 +0000 Subject: [PATCH 370/498] Removed translation tags from names in the nav bar and footer --- i2p2www/pages/global/footer.html | 8 ++++---- i2p2www/pages/global/nav.html | 24 ++++++++++++------------ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/i2p2www/pages/global/footer.html b/i2p2www/pages/global/footer.html index d4ab7104..ef6f899b 100644 --- a/i2p2www/pages/global/footer.html +++ b/i2p2www/pages/global/footer.html @@ -1,10 +1,10 @@
        diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 391da543..558a9b33 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -7,9 +7,9 @@
      • @@ -37,15 +37,15 @@
      • @@ -58,8 +58,8 @@
      • From b8bfbc41c3770b9589691c15273dbd8b16d4cc57 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 19:52:41 +0000 Subject: [PATCH 371/498] Put blog post excerpts on a single line so translators don't break the Markdown --- i2p2www/blog/2012/10/27/0.9.3-Release.rst | 8 +------- i2p2www/blog/2012/12/17/0.9.4-Release.rst | 6 +----- 2 files changed, 2 insertions(+), 12 deletions(-) diff --git a/i2p2www/blog/2012/10/27/0.9.3-Release.rst b/i2p2www/blog/2012/10/27/0.9.3-Release.rst index 0572f8a8..4b8e655c 100644 --- a/i2p2www/blog/2012/10/27/0.9.3-Release.rst +++ b/i2p2www/blog/2012/10/27/0.9.3-Release.rst @@ -4,13 +4,7 @@ .. meta:: :date: 2012-10-27 :category: release - :excerpt: {% trans %} - 0.9.3 includes extensive low-level changes to the queueing of messages in the router. - We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the - queueing and priority mechanisms in the transports to aid diagnosis and reduce network - latency. Work continues on fixing UDP transport bugs and making UDP more resistant to - attacks. There are more changes to improve the performance of the router and reduce its - memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default.{% endtrans %} + :excerpt: {% trans %}0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default.{% endtrans %} {% trans -%} 0.9.3 includes extensive low-level changes to the queueing of messages in the router. diff --git a/i2p2www/blog/2012/12/17/0.9.4-Release.rst b/i2p2www/blog/2012/12/17/0.9.4-Release.rst index 9f1bd991..13d45281 100644 --- a/i2p2www/blog/2012/12/17/0.9.4-Release.rst +++ b/i2p2www/blog/2012/12/17/0.9.4-Release.rst @@ -4,11 +4,7 @@ .. meta:: :date: 2012-12-17 :category: release - :excerpt: {% trans %} - 0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, - that was reducing network performance and reliability. It also includes - major changes in the in-network update system, and adds the capability - to update via in-network torrents.{% endtrans %} + :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} {% trans -%} 0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, From ac070805e477dbca1290d79ca6342cb1c5678a01 Mon Sep 17 00:00:00 2001 From: dg2 Date: Fri, 1 Feb 2013 20:12:08 +0000 Subject: [PATCH 372/498] misc/* translation tagging, URLs need fixing before it will parse correctly. First commit, huzzah. --- i2p2www/pages/site/misc/clt.html | 15 ++- i2p2www/pages/site/misc/cvs.html | 12 ++- .../pages/site/misc/i2ptunnel-migration.html | 22 ++-- .../pages/site/misc/i2ptunnel-services.html | 101 +++++++++--------- i2p2www/pages/site/misc/invisiblenet.html | 3 +- i2p2www/pages/site/misc/jbigi.html | 101 ++++++++++-------- i2p2www/pages/site/misc/jrandom-awol.html | 11 +- i2p2www/pages/site/misc/manual-wrapper.html | 35 +++--- i2p2www/pages/site/misc/minwww.html | 54 ++++++---- i2p2www/pages/site/misc/myi2p.html | 17 +-- i2p2www/pages/site/misc/ratestats.html | 10 +- i2p2www/pages/site/misc/transition-guide.html | 15 +-- i2p2www/pages/site/misc/upgrade-0.6.1.30.html | 28 ++--- 13 files changed, 241 insertions(+), 183 deletions(-) diff --git a/i2p2www/pages/site/misc/clt.html b/i2p2www/pages/site/misc/clt.html index 9a529f74..f6d99154 100644 --- a/i2p2www/pages/site/misc/clt.html +++ b/i2p2www/pages/site/misc/clt.html @@ -1,13 +1,12 @@ {% extends "global/layout.html" %} {% block title %}I2P at CLT and PetCon 2009.1{% endblock %} -{% block content %}

        Members of I2P will held a talk at CLT and PetCon 2009.1

        -Two members of the I2P team will be at two forthcoming Linux day and security convention. -On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon.
        -Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props!
        -Show your support!
        -
        -Just 10 days later the Privacy and Data Security convention in Dresden will take place.
        +{% block content %}{% trans -%}

        +Members of I2P will held a talk at CLT and PetCon 2009.1 +Two members of the I2P team will be at two forthcoming Linux day and security convention.

        +On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon. +Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props! Show your support!

        +Just 10 days later the Privacy and Data Security convention in Dresden will take place. Again, echelon will attend this event and hold a short talk about general introduction to I2P. Another talk about the profiling by the I2P clients will be held. -
        +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/misc/cvs.html b/i2p2www/pages/site/misc/cvs.html index 52365d9d..05ca9df6 100644 --- a/i2p2www/pages/site/misc/cvs.html +++ b/i2p2www/pages/site/misc/cvs.html @@ -1,11 +1,13 @@ {% extends "global/layout.html" %} {% block title %}CVS{% endblock %} -{% block content %}

        The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository. +{% block content %}

        {% trans -%} +The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository. For those who aren't very familiar with CVS, there is a fantastic book on the subject (developers only need to deal with the first chapter - "An Overview of CVS", as subsequent chapters go into some nasty details very few ever need to -touch).

        +touch). +{%- endtrans %}

        Unix CVS

        cvs -d:pserver:anoncvs@cvs.i2p.net:/cvsroot login
        @@ -25,6 +27,8 @@ Password: anoncvs

        Commits are sent to the CVS mailinglist

        -

        Humorous quote from WinCVS: "Did you know... Never experiment with new CVS -commands on your working repository. Create a sample module instead."

        +

        {% trans -%} +Humorous quote from WinCVS: "Did you know... Never experiment with new CVS +commands on your working repository. Create a sample module instead." +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/misc/i2ptunnel-migration.html b/i2p2www/pages/site/misc/i2ptunnel-migration.html index 0c5fa751..b585bc3d 100644 --- a/i2p2www/pages/site/misc/i2ptunnel-migration.html +++ b/i2p2www/pages/site/misc/i2ptunnel-migration.html @@ -1,16 +1,18 @@ {% extends "global/layout.html" %} {% block title %}i2ptunnel migration{% endblock %} -{% block content %}

        I2PTunnel migration:

        +{% block content %}

        {% trans -%}I2PTunnel migration:{%- endtrans %}

        -

        After upgrading to the new architecture, you'll have to do a +

        {% trans -%} +After upgrading to the new architecture, you'll have to do a little work to get your old I2PTunnel-driven servers running. Lets walk through a simple example. For an eepsite with the -old clientApp configuration, you had:

        +old clientApp configuration, you had: +{%- endtrans %}

           -e "server localhost 80 myWebPriv.dat"
         
        -

        To provide that same functionality on the new web architecture:

        +

        {% trans -%}To provide that same functionality on the new web architecture:{%- endtrans %}

        -

        That's it! Creating a new I2PTunnel server works the same way too, except you +

        {% trans -%} +That's it! Creating a new I2PTunnel server works the same way too, except you don't need to "copy the old file", obviously. Behind the scenes, it is all driven by the i2ptunnel.config file, which you may modify externally (if you do, hit "Reload config" on the I2PTunnel web page, which will tear down all of your -existing tunnels and rebuild new ones)

        +existing tunnels and rebuild new ones) +{%- endtrans %}

        -

        Note that you WILL need to wait until your router is integrated +

        {% trans -%} +Note that you WILL need to wait until your router is integrated into the network before you are able to use the /i2ptunnel/ web interface. It will say "Please be patient" if you try to beforehand, which means that it is still trying to build the -necessary I2PTunnel sessions it has been configured to create.

        {% endblock %} +necessary I2PTunnel sessions it has been configured to create. +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/misc/i2ptunnel-services.html b/i2p2www/pages/site/misc/i2ptunnel-services.html index a9e9433a..5fec5bc5 100644 --- a/i2p2www/pages/site/misc/i2ptunnel-services.html +++ b/i2p2www/pages/site/misc/i2ptunnel-services.html @@ -1,109 +1,112 @@ {% extends "global/layout.html" %} {% block title %}i2ptunnel services{% endblock %} -{% block content %}Below is quick copy of aum's eepsite deployment guide. -
        +{% block content %}{% trans -%} +Below is quick copy of aum's eepsite deployment guide. +{%- endtrans %}

        -1. - Deploy a local server
        • For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up. +{% trans -%} +1. - Deploy a local server +{%- endtrans %}
          • {% trans %}For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up. {% endtrans %}
            -
          • I recommend the Tiny Httpd web server , thttpd, (windows version available on site) although you can use anything that you feel comfortable with. +
          • {% trans %}I recommend the Tiny Httpd web server , thttpd, (windows version available on site) although you can use anything that you feel comfortable with.{% endtrans %}
            -
          • Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help. +
          • {% trans %}Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help. {% endtrans %}
            -
          • With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880. +
          • {% trans %}With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880. {% endtrans %}
            -
          • Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity). +
          • {% trans %}Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity). {% endtrans %}
            -
          • Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen). +
          • {% trans %}Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen). {% endtrans %}
            -
          • Once your webserver is working, and you can access it locally with your browser, continue to the next step. +
          • {% trans %}Once your webserver is working, and you can access it locally with your browser, continue to the next step. {% endtrans %}
            -
          2 - Generate an I2P Destination Keypair
          • I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys. +
          {% trans %}2 - Generate an I2P Destination Keypair {% endtrans %}
          • {% trans %}I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys. {% endtrans %}
            -
          • A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets) +
          • {% trans %}A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets) {% endtrans %}
            -
          • To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways) +
          • {% trans %}To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways) {% endtrans %}
            -
          • Each service you run on I2P requires a different keypair. +
          • {% trans %}Each service you run on I2P requires a different keypair. {% endtrans %}
            -
          • To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line) +
          • {% trans %}To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line) {% endtrans %}
            -
          • In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" +
          • {% trans %}In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" {% endtrans %}
            -
          • The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices. +
          • {% trans %}The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices. {% endtrans %}
            -
          • We now need to export your public key into base64 format, which you will share with others. +
          • {% trans %} We now need to export your public key into base64 format, which you will share with others. {% endtrans %}
            -
          • To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line). +
          • {% trans %}To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line). {% endtrans %}
            -
          • This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine. +
          • {% trans %}This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine. {% endtrans %}
            -
          • However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key. +
          • {% trans %}However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key. {% endtrans %}
            -
          3 - Open a 'Tunnel' from I2P To Your Server
          • For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server +
          {% trans %}3 - Open a 'Tunnel' from I2P To Your Server{% endtrans %}
          • {% trans %}For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server {% endtrans %}
            -
          • To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line) +
          • {% trans %}To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line) {% endtrans %}
            -
          • If you used different filenames or port number earlier on, change these accordingly +
          • {% trans %}If you used different filenames or port number earlier on, change these accordingly {% endtrans %}
            -
          • Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" +
          • {% trans %}Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" {% endtrans %}
            -
          • Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it. +
          • {% trans %}Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it. {% endtrans %}
            -
          4 - Update Your hosts.txt File
          • To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server. +
          {% trans %}4 - Update Your hosts.txt File {% endtrans %}
          • {% trans %}To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server. {% endtrans %}
            -
          • Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt +
          • {% trans %}Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt {% endtrans %}
            -
          • With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar. +
          • {% trans %}With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar. {% endtrans %}
            -
          5 - Surf Your Site Within I2P
          • Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p +
          {% trans %}5 - Surf Your Site Within I2P{% endtrans %}
          • {% trans %}Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p{% endtrans %}
            -
          • You should see the main page of your webserver come up. +
          • {% trans %}You should see the main page of your webserver come up. {% endtrans %}
            -
          6 - Create a Local Client Tunnel Connection
          • We now have to think beyond just web servers. +
          {% trans %}6 - Create a Local Client Tunnel Connection {% endtrans %}
          • {% trans %}We now have to think beyond just web servers. {% endtrans %}
            -
          • As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients. +
          • {% trans %}As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients. {% endtrans %}
            -
          • The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network. +
          • {% trans %}The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network. {% endtrans %}
            -
          • You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode. +
          • {% trans %}You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode. {% endtrans %}
            -
          • Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end. +
          • {% trans %}Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end. {% endtrans %}
            -
          • To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line). +
          • {% trans %}To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line). {% endtrans %}
            -
          • The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on. +
          • {% trans %}The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on. {% endtrans %}
            -
          • textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p) +
          • {% trans %}textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p) {% endtrans %}
            -
          • Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use. +
          • {% trans %}Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use. {% endtrans %}
            -
          • Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888 +
          • {% trans %}Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888 {% endtrans %}
            -
          • Verify that the main page of your server eventually comes up in your browser. +
          • {% trans %}Verify that the main page of your server eventually comes up in your browser. {% endtrans %}
            -
          • You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content. +
          • {% trans %}You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content. {% endtrans %}
            -
          7 - Share your server details with others
          • Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity. +
          {% trans %}7 - Share your server details with others{% endtrans %}
          • {% trans %}Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity. {% endtrans %}
            -
          • Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address. +
          • {% trans %}Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address. {% endtrans %}
            -
          8 - Write Some Scripts To Handle All This Menial Nonsense
          • It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client. +
          {% trans %}8 - Write Some Scripts To Handle All This Menial Nonsense{% endtrans %}
          • {% trans %}It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client. {% endtrans %}
            -
          • Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent. +
          • {% trans %}Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent. {% endtrans %}
            -
          • So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language. +
          • {% trans %}So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language. {% endtrans %}
            -
          • Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here. +
          • {% trans %}Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here. {% endtrans %}
            -
          • Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file. +
          • {% trans %}Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file. { %endtrans % }
          {% endblock %} diff --git a/i2p2www/pages/site/misc/invisiblenet.html b/i2p2www/pages/site/misc/invisiblenet.html index 5c2c7a10..1d941e18 100644 --- a/i2p2www/pages/site/misc/invisiblenet.html +++ b/i2p2www/pages/site/misc/invisiblenet.html @@ -2,12 +2,13 @@ {% block title %}Old Documents{% endblock %} {% block content %} +{% trans -%} Following is a list of documents originally on www.invisiblenet.net/i2p/ and rescued via the Wayback Machine. They are quite dated and may or may not be accurate. However, the I2CP and I2NP documents in particular have some good information. - +{%- endtrans %}

          Index of /i2p

          Name                    Last modified       Size
          diff --git a/i2p2www/pages/site/misc/jbigi.html b/i2p2www/pages/site/misc/jbigi.html
          index 5a123c5b..e531c722 100644
          --- a/i2p2www/pages/site/misc/jbigi.html
          +++ b/i2p2www/pages/site/misc/jbigi.html
          @@ -3,12 +3,14 @@
           {% block lastupdated %}August 2011{% endblock %}
           {% block accuratefor %}0.8.7{% endblock %}
           {% block content %}
          -

          Overview

          -

          Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a little +

          {% trans %}Overview{% endtrans %}

          +

          {% trans -%} +Using JNI (Java Native Interface), a bit of C code (thanks ugha!), a little manual work and a piece of chewing gum we have made several -cryptography operations quite a bit faster.

          +cryptography operations quite a bit faster. +{%- endtrans %}

          -

          +

          {% trans -%} The speedup comes from the super-fast GNU MP Bignum library (libgmp). We use a single function from libgmp - @@ -16,9 +18,9 @@ We use a single function from libgmp - as a replacement for the Java Math library's BigInteger modPow(). As modPow() is a significant computational portion of many crypto operations, this is of significant benefit. -

          +{%- endtrans %}

          -

          +

          {% trans -%} The standard I2P installation includes about 20 versions of the library for different platforms, each about 50KB, inside the jbigi.jar file. The initialization of the JBigI library, including CPU identification, selection, and extraction @@ -27,68 +29,79 @@ of the correct loadable module, is handled by the If no module is available for the current platform, the standard Java Math library's BigInteger modPow() is used. -

          +{%- endtrans %}

          -

          Rebuilding and Testing JBigI

          -Following are the instructions to build a new jbigi library for your own platform -and testing its performance. +

          {% trans %}Rebuilding and Testing JBigI{% endtrans %}

          +{% trans %}Following are the instructions to build a new jbigi library for your own platform +and testing its performance.{% endtrans %} -

          Requirements

          -

          This works on Linux, and with a few changes in build.sh probably also on +

          {% trans %}Requirements{% endtrans %}

          +

          {% trans -%} +This works on Linux, and with a few changes in build.sh probably also on other platforms. FreeBSD has also been reported to work too. On Kaffee the speedup is very small, because it already uses native BitInteger internally. Blackdown seems to cause strange errors. Because you are going to do -compilation, you need JDK; JRE won't work.

          -

          The required code is available in monotone database and the latest source tarball.

          -

          The GNU MP Bignum library (libgmp) needs to be installed, if it isn't +compilation, you need JDK; JRE won't work. +{%- endtrans %}

          +

          {% trans %}The required code is available in monotone database and the latest source tarball. {% endtrans %}

          +

          {% trans -%} +The GNU MP Bignum library (libgmp) needs to be installed, if it isn't included in your OS / distribution or installed already, it can be received from http://gmplib.org/#DOWNLOAD. Even if you have already installed it as binary, it might still be worth a try to compile GMP yourself, since then it will be able to use the specific instructions of your processor. The latest GMP may also be used instead of GMP 5.0.2, but it hasn't been tested by us. -

          +{%- endtrans %}

          -

          Step-by-step instructions

          +

          {% trans %}Step-by-step instructions{% endtrans %}

            -
          1. Look at your running environment on the logs.jsp page. -There should be one of two status messages for JBigI - either +
          2. {% trans %}Look at your running environment on the logs.jsp page. +There should be one of two status messages for JBigI - either{% endtrans %} -Locally optimized native BigInteger loaded from the library path +{% trans %}Locally optimized native BigInteger loaded from the library path{% endtrans %} -or +{% trans %}or{% endtrans %} -Native BigInteger library jbigi not loaded - using pure java. -If the native BitInteger library was NOT loaded, you definitely need to +{% trans %}Native BigInteger library jbigi not loaded - using pure java{% endtrans %}. +{% trans %}If the native BitInteger library was NOT loaded, you definitely need to compile your own. Certain platforms, such as OS X, OpenSolaris, and 64-bit systems, may require you to compile your own library. If the BigInteger library was loaded, do at least the next step to see -what your performance is. +what your performance is.{% endtrans %}
          3. -
          4. Look on http://localhost:7657/stats.jsp +
          5. {% trans -%} +Look on http://localhost:7657/stats.jsp to see what the lifetime average values for crypto.elGamal.decrypt and crypto.elGamal.encrypt are. The numbers are times in milliseconds. Copy these somewhere so you can compare them later on. The network average for encrypt time is about 20ms. If your encrypt time is less than 50ms for a relatively new processor, or less than 100ms for an older processor, and the native BigInteger library was loaded, you are probably fine. -
          6. -
          7. Get the latest released source code of I2P from +{%- endtrans %}
          8. +
          9. {% trans -%} +Get the latest released source code of I2P from the download page, or get the cutting-edge source -out of the monotone database mtn.i2p2.de
          10. -
          11. Inside the source tree change directory to: core/c/jbigi
          12. -
          13. Read the README file. +out of the monotone database mtn.i2p2.de +{%- endtrans %}
          14. +
          15. {$ trans %}Inside the source tree change directory to: core/c/jbigi{% endtrans %}
          16. +
          17. {% trans -%} +Read the README file. If you have a /usr/lib/libgmp.so file, you do not have to download GMP. Use the 'dynamic' argument to build.sh. Otherwise, you must download GMP version 5.0.2 from from http://gmplib.org/#DOWNLOAD, saving it to gmp-5.0.2.tar.bz2. If you decide to use a newer version, change the VER= line in core/c/jbigi/build.sh. -
          18. Take a look at build.sh, if your JAVA_HOME +{%- endtrans %} +
          19. {% trans -%} +Take a look at build.sh, if your JAVA_HOME environment variable is set and you are using Linux then it might just work. -Otherwise change the settings. Remember, you need the Java SDK installed.
          20. -
          21. Run build.sh (if you downloaded GMP) or +Otherwise change the settings. Remember, you need the Java SDK installed. +{%- endtrans %}
          22. +
          23. {% trans -%} +Run build.sh (if you downloaded GMP) or build.sh dynamic (if you have /usr/lib/libgmp.so).
            Maybe the build spewed out some errors of missing jni.h and jni_md.h files. Either copy these files from your java install into the core/c/jbigi/jbigi/include/ directory, @@ -97,24 +110,26 @@ You can run the build.sh from the core/c/ directory wh build all available jbigi libs into a jbigi.jar.
            A file named libjbigi.so should be created in the current directory. If this doesn't happen and/or you get errors then please report -them.
          24. -
          25. Follow the instructions in core/c/README to install the library and run +them. +{%- endtrans %}
          26. +
          27. {% trans -%} +Follow the instructions in core/c/README to install the library and run the speed test. Read the final lines of the speed test's output for some additional info, it will be something like this: -
            +{%- endtrans %}
             native run time:  5842ms ( 57ms each)
             java run time:   41072ms (406ms each)
             native = 14.223802103622907% of pure java time
             
            -If the native is indeed 5-7x faster (or more) then it looks all good. If not, please -report.
          28. -
          29. Copy libjbigi.so to your i2p directory
          30. -
          31. Restart your I2P programs.
          32. -
          33. On -http://localhost:7657/stats.jsp +{% trans %}If the native is indeed 5-7x faster (or more) then it looks all good. If not, please +report.{% endtrans %}
          34. +
          35. {% trans %}Copy libjbigi.so to your i2p directory{% endtrans %}
          36. +
          37. {% trans %}Restart your I2P programs.{% endtrans %}
          38. +
          39. {% trans %}On{% endtrans %} +{% trans %}http://localhost:7657/stats.jsp the crypto.elGamal.decrypt and crypto.elGamal.encrypt -should be a lot faster.
          40. +should be a lot faster.{% endtrans %}
          diff --git a/i2p2www/pages/site/misc/jrandom-awol.html b/i2p2www/pages/site/misc/jrandom-awol.html index a5ea40c6..d2c816d3 100644 --- a/i2p2www/pages/site/misc/jrandom-awol.html +++ b/i2p2www/pages/site/misc/jrandom-awol.html @@ -1,9 +1,9 @@ {% extends "global/layout.html" %} {% block title %}Jrandom's Announcement{% endblock %} {% block content %} -The following message was received in mid-November 2007. We have no further information -on jrandom's status. -

          +{% trans %}The following message was received in mid-November 2007. We have no further information +on jrandom's status.{% endtrans %} +

          {% trans -%} Subsequently, in an unrelated incident, the hosting company for all *.i2p.net servers (except forum.i2p.net) suffered a power outage on January 13, 2008, and the i2p.net servers did not fully return to service. @@ -11,10 +11,11 @@ As only jrandom has the credentials required to restore service, and he could not be contacted, we moved all public services to www.i2p2.de and related subdomains. -

          +{%- endtrans %}

          +

          {% trans -%} Approximately two months later, for unrelated reasons, forum.i2p.net was moved to forum.i2p2.de. -

          +{%- endtrans %}

           -----BEGIN PGP SIGNED MESSAGE-----
           Hash: SHA1
          diff --git a/i2p2www/pages/site/misc/manual-wrapper.html b/i2p2www/pages/site/misc/manual-wrapper.html
          index 3aba9b90..ddd83e52 100644
          --- a/i2p2www/pages/site/misc/manual-wrapper.html
          +++ b/i2p2www/pages/site/misc/manual-wrapper.html
          @@ -1,38 +1,39 @@
           {% extends "global/layout.html" %}
           {% block title %}Manually Installing the Java Wrapper{% endblock %}
           {% block content %}
          -

          Manually Installing the Java Wrapper

          +

          {% trans %}Manually Installing the Java Wrapper{% endtrans %}

          -

          The installation package for the I2P router comes +

          {% trans -%} +The installation package for the I2P router comes with a Java wrapper for the most common architectures. If your system is not supported by our installer—or if you want to update the wrapper to a newer version—the following steps describe installing the wrapper manually. -

          +{%- endtrans %}

            -
          • Check Tanuki Software's download page +
          • {% trans %}Check Tanuki Software's download page for your platform. Is your platform listed? If so, you're in luck! Download the most recent version of the Community Edition for your OS and - CPU and move to the next step
          • -
          • If your platform does not have an already compiled wrapper available, you + CPU and move to the next step{% endtrans %}
          • +
          • {% trans %}If your platform does not have an already compiled wrapper available, you may be able to compile it yourself. If you are willing to have a go at it, move - on to compiling the wrapper for your system.
          • + on to compiling the wrapper for your system.{% endtrans %}
          -

          Using existing binaries

          -In the steps below, $I2P means the location I2P was installed to. +

          {% trans %}Using existing binaries{% endtrans %}

          +{% trans %}In the steps below, $I2P means the location I2P was installed to.{% endtrans %}
          1. tar xzf wrapper-*.tar.gz
          2. cp wrapper*/bin/wrapper $I2P/i2psvc
          3. cp wrapper*/lib/wrapper.jar $I2P/lib
          4. cp wrapper*/lib/libwrapper.so $I2P/lib
          5. -
          6. Try to start I2P using $I2P/i2prouter start
          7. +
          8. {% trans %}Try to start I2P using {% endtrans %}$I2P/i2prouter start
          9. tail -f /tmp/wrapper.log and look for any problems.
          -If this did not work you'll need to use runplain.sh to start I2P. -

          Compiling from source

          -These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system. +{% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %} +

          {% trans %}Compiling from source{% endtrans %}

          +{% trans %}These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system.{% endtrans %}
            -
          1. Download the source archive for the community version of the wrapper from wrapper download page.
          2. -
          3. Extract the tarball
            +
          4. {% trans %}Download the source archive for the community version of the wrapper from wrapper download page.{% endtrans %}
          5. +
          6. {% trans %}Extract the tarball{% endtrans %}
                tar xzf wrapper_3.5.13_src.tar.gz
          7. Set environment variables ANT_HOME and JAVA_HOME. In Debian, one can
                export ANT_HOME=/usr/share/ant
            @@ -47,8 +48,8 @@ These steps worked to compile the wrapper for use on a mipsel system running Deb
          8. cp lib/wrapper.jar $I2P/lib
          9. cp lib/libwrapper.so $I2P/lib
      • -
      • Try to start I2P using $I2P/i2prouter start
      • +
      • {% trans %}Try to start I2P using $I2P/i2prouter start{% endtrans %}
      • tail -f /tmp/wrapper.log and look for any problems.
      • -If this did not work you'll need to use runplain.sh to start I2P. +{% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %} {% endblock %} diff --git a/i2p2www/pages/site/misc/minwww.html b/i2p2www/pages/site/misc/minwww.html index a4307741..658df060 100644 --- a/i2p2www/pages/site/misc/minwww.html +++ b/i2p2www/pages/site/misc/minwww.html @@ -1,13 +1,17 @@ {% extends "global/layout.html" %} {% block title %}minwww{% endblock %} -{% block content %}

        Here's an outline and rationale for a minimal WWW proxy app for use over -I2P.

        -

        HTTP operation over I2P using I2PTunnel. When the base SocketLibrary +{% block content %}

        {% trans -%} +Here's an outline and rationale for a minimal WWW proxy app for use over +I2P. +{%- endtrans %}

        +

        {% trans -%} +HTTP operation over I2P using I2PTunnel. When the base SocketLibrary is out, the only significant difference will be the 'wrapRequest' and 'unwrapRequest' will functionally be placed in the socketLibrary, not in the router (but later versions of the SocketLibrary will be able to use selective ACK and large window sizes, allowing more ACKs to be -skipped)

        +skipped) +{%- endtrans %}

         ---BROWSER--->-I2PTUNNEL--->-ROUTERA--->-ROUTERB--->-I2PTUNNEL--->-HTTPD----------
          1: openCon
        @@ -38,8 +42,10 @@ skipped)

        26: receiveACK receiveClose 27: sentSuccess
        -

        An optimized form, designed to handle only 128KB [1] files and pages, can -operate significantly faster:

        +

        {% trans -%} +An optimized form, designed to handle only 128KB [1] files and pages, can +operate significantly faster: +{%- endtrans %}

            BROWSER --> MinWWW   --> ROUTERA --> ROUTERB --> MinWWW    --> HTTPD
          1: openCon
        @@ -59,7 +65,8 @@ operate significantly faster:

        15: closeCon 16: closed
        -

        The difference in network load and latency is significant - this is +

        {% trans -%} +The difference in network load and latency is significant - this is essentially a UDP version of HTTP. On the normal web, we can't really do that, since most HTTP requests and responses are orders of magnitude larger than UDP packets functionally support, but in I2P, messages can be large. The savings @@ -67,20 +74,26 @@ for the network load comes from the fact that we don't need to send any ACK messages - rather than the earlier wrap/unwrap request (that bundles a DataMessage with a DeliveryStatusMessage to provide guaranteed delivery), the MinWWW proxy deals with resends (if necessary - in I2PTunnel today, there are no -resends).

        -

        The data that the MinWWW proxy and server need to wrap is trivial - when the +resends). +{%- endtrans %}

        +

        {% trans -%} +The data that the MinWWW proxy and server need to wrap is trivial - when the proxy wants to send "GET /", it prepends it with the I2P Destination sending the request, followed by a 4 byte request ID. The MinWWW server receives those requests, contacts the appropriate HTTPD, sends the request, waits for the response, and sends a reply to the MinWWW proxy containing the response, prefixed with the original request ID. That response is taken and passed back -to the browser and the connection is closed.

        -

        In addition, the MinWWW proxy can choose the MinWWW server to use from a +to the browser and the connection is closed. +{%- endtrans %}

        +

        {% trans -%} +In addition, the MinWWW proxy can choose the MinWWW server to use from a list, going through some round robin or other algorithm, so that there are multiple outproxies merged transparently. The bandwidth required for running one of these outproxies is also greatly reduced, since it will only handle 128KB -files (aka no one is going to be downloading porn, warez, etc).

        -

        The functionality /is/ limited, but 128KB of data is a lot for a single HTTP +files (aka no one is going to be downloading porn, warez, etc). +{%- endtrans %}

        +

        {% trans -%} +The functionality /is/ limited, but 128KB of data is a lot for a single HTTP request or response. The above diagrams are also unrealistic in their hops - ROUTERA will really never talk directly to ROUTERB. ROUTERA will send each of the messages through two additional outbound routers, then forwarded to @@ -88,16 +101,21 @@ two additional inbound routers to ROUTERB, so the lag there is significant - while the above only saves 11 steps, 8 of those steps need to traverse the entire tunnel path (4+ remote hops each time when tunnels are 2 remote hops in each stretch), leaving MinWWW with only two full traversals (one for the -request, one for the response), instead of 10.

        -

        Implementing the MinWWW proxy and server should be fairly easy - read an HTTP +request, one for the response), instead of 10. +{%- endtrans %}

        +

        {% trans -%} +Implementing the MinWWW proxy and server should be fairly easy - read an HTTP request from the client fully (perhaps only start out with HTTP GET, leaving HTTP POST for later), wrap the message, and wait for the response. The server in turn simply needs to parse the request to either open a socket or URL, send the request, wait for the response, and send it back through the network. -If someone were to implement this, it would be Good :)

        -

        [1] Why 128KB files? Currently I2CP allows functionally arbitrary message +If someone were to implement this, it would be Good :) +{%- endtrans %}

        +

        {% trans -%} +[1] Why 128KB files? Currently I2CP allows functionally arbitrary message size, but that's going to be going away since it involves either excessive memory overhead on intermediary routers, or additional implementation details to handle. I2PTunnel is currently limited to 128KB and hasn't been a burden, -so perhaps it could be increased to 256KB when the I2CP spec is updated)

        +so perhaps it could be increased to 256KB when the I2CP spec is updated) +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/misc/myi2p.html b/i2p2www/pages/site/misc/myi2p.html index e78b1b93..a0b15440 100644 --- a/i2p2www/pages/site/misc/myi2p.html +++ b/i2p2www/pages/site/misc/myi2p.html @@ -1,12 +1,14 @@ {% extends "global/layout.html" %} {% block title %}MYI2P{% endblock %} -{% block content %}

        There has been discussion about a distributed blogging application for a few +{% block content %}

        {% trans -%} +There has been discussion about a distributed blogging application for a few months now called "MyI2P". While the original discussions were lost, we were able to retrieve a Google cache of it. It isn't pretty, but it includes the basic overview and some discussion -that ensued.

        +that ensued.{%- endtrans %}

        -

        The application itself is not yet implemented, and the ideas behind it have +

        {% trans -%} +The application itself is not yet implemented, and the ideas behind it have been made less ambitious over time, but they are still valid and the current plan is to have the core MyI2P functionality available along side the I2P 1.0 release. That will include a distributed address book @@ -19,12 +21,15 @@ system using a reduced and secured subset of bbcode to essentially provide an anonymous LiveJournal with a 'friends list' and transparent access control (authenticated by the I2P -datagrams with rules defined based on the address book).

        +datagrams with rules defined based on the address book). +{%- endtrans %}

        -

        Additional functionality, such as integration with a DHT backing store or +

        {% trans -%} +Additional functionality, such as integration with a DHT backing store or swarming file transfers for 'attachments' can be added later. Email may or may not get in the first pass either, though its implementation is essentially just a blog entry with private access, so perhaps some UI designer can come up with something. Exporting the data to RSS or access through ATOM will be an option -down the road as well.

        +down the road as well. +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/misc/ratestats.html b/i2p2www/pages/site/misc/ratestats.html index 83cd79b7..7ad450c1 100644 --- a/i2p2www/pages/site/misc/ratestats.html +++ b/i2p2www/pages/site/misc/ratestats.html @@ -1,15 +1,15 @@ {% extends "global/layout.html" %} {% block title %}RateStat list{% endblock %} {% block content %} -

        RateStat list

        -

        I2P enables the collection of a wide range of rates, the list published here is accurate as of I2P version 0.8.7.

        -

        The list was gathered using the following command in the top directory of the branch i2p.i2p, +

        {% trans %}RateStat list{% endtrans %}

        +

        {% trans %}I2P enables the collection of a wide range of rates, the list published here is accurate as of I2P version 0.8.7.{% endtrans %}

        +

        {% trans %}The list was gathered using the following command in the top directory of the branch i2p.i2p,

         find . -name '*' -print | xargs --max-args=3 grep -n --color=auto addRateData | awk 'match($0, /addRateData\(\"(.*)\"/, a) {print a[1]}' | awk '!_[$0]++' | sort > rates.txt
         
        -All options aren't needed, but it works. +All options aren't needed, but it works.{% endtrans %}

        -

        RateStats

        +

        {% trans %}RateStats{% endtrans %}

         bwLimiter.inboundDelayedTime
         bwLimiter.outboundDelayedTime
        diff --git a/i2p2www/pages/site/misc/transition-guide.html b/i2p2www/pages/site/misc/transition-guide.html
        index 4480f02d..119eb5ea 100644
        --- a/i2p2www/pages/site/misc/transition-guide.html
        +++ b/i2p2www/pages/site/misc/transition-guide.html
        @@ -1,6 +1,7 @@
         {% extends "global/layout.html" %}
         {% block title %}Monotone{% endblock %}
        -{% block content %}

        The I2P sourcecode is kept in several distributed monotone repositories. +{% block content %}

        {% trans -%} +The I2P sourcecode is kept in several distributed monotone repositories. See the Monotone website for information on monotone. @@ -9,17 +10,17 @@ See for more information on how to get started and check out the source anonymously. There is also a quick-start guide on the new developer's page. -

        +{%- endtrans %}

        -

        +

        {% trans -%} If you want to get the source non-anonymously, pull from the public server mtn.welterde.de. The i2p source code branch is "i2p.i2p". -

        +{%- endtrans %}

        -

        Guide

        -

        +

        {% trans %} Guide {% endtrans %}

        +

        {%- trans %} The following is a detailed guide by Complication. -

        +{%- endtrans %}

           {% include "site/misc/transition-guide.txt" %}
         
        diff --git a/i2p2www/pages/site/misc/upgrade-0.6.1.30.html b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html index 0d5b3e2c..91dd2d46 100644 --- a/i2p2www/pages/site/misc/upgrade-0.6.1.30.html +++ b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html @@ -3,21 +3,24 @@ {% block content %}

        • -2008-02-05: Upgrading from 0.6.1.30 and Earlier Releases -

        +2008-02-05: {% trans %}Upgrading from 0.6.1.30 and Earlier Releases{% endtrans %} +

        +

        {% trans -%} Since i2p's lead developer has gone AWOL, we do not have his update signing key or access to www.i2p[.net] or dev.i2p[.net]. Complication and zzz have generated new signing keys, and they and Amiga are providing update file hosting. These changes must be configured in your router to take effect. -

        +{%- endtrans %}

        +

        {% trans -%} Make the following configuration changes and your router will automatically install the latest release. -

        +{%- endtrans %}

        +

        {% trans -%} We recommend the automated process as it will verify the key of the signed update file. If you do not make these changes, -you may manually download the i2pupdate.zip file from +you may manually download the i2pupdate.zip file from{% endtrans %} the download page.

        1. On @@ -25,7 +28,7 @@ On
          1. Change the News URL to: http://complication.i2p/news.xml
          2. -Select ONE of the following new Update URLs at random and enter it into the Update URL box: +{% trans %}Select ONE of the following new Update URLs at random and enter it into the Update URL box: {% endtrans %}
            http://amiga.i2p/i2p/i2pupdate.sud
            http://complication.i2p/i2p/i2pupdate.sud
            http://stats.i2p/i2p/i2pupdate.sud @@ -44,17 +47,18 @@ Add the following line:
          3. Click "Apply"
          -
        2. -You are now ready to automatically receive the release update file, +
        3. {% trans -%}You are now ready to automatically receive the release update file, either by setting your update policy to "download and install" or by clicking on the "update available" link when it appears. -
        -

        +{%- endtrans %} +

        +

        {% trans -%} If you would like to verify the trusted update keys, they are also posted and signed here. Thank you for your support during this transition. For help please contact us on #i2p. -

        +{%- endtrans %}

        +

        {% trans -%} Amiga, Complication, welterde, zzz -

        +{%- endtrans %}

        {% endblock %} From c78d3bbb5799b8bba3843444722d2ac50302b780 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 22:20:09 +0000 Subject: [PATCH 373/498] Tag tweaks and URL fixes for misc/* --- i2p2www/pages/site/misc/clt.html | 19 +- i2p2www/pages/site/misc/cvs.html | 5 +- .../pages/site/misc/i2ptunnel-migration.html | 34 ++- .../pages/site/misc/i2ptunnel-services.html | 268 +++++++++++------- i2p2www/pages/site/misc/invisiblenet.html | 6 +- i2p2www/pages/site/misc/jbigi.html | 40 +-- i2p2www/pages/site/misc/jrandom-awol.html | 16 +- i2p2www/pages/site/misc/manual-wrapper.html | 57 ++-- i2p2www/pages/site/misc/minwww.html | 14 +- i2p2www/pages/site/misc/myi2p.html | 12 +- i2p2www/pages/site/misc/ratestats.html | 12 +- i2p2www/pages/site/misc/transition-guide.html | 9 +- i2p2www/pages/site/misc/upgrade-0.6.1.30.html | 65 +++-- 13 files changed, 337 insertions(+), 220 deletions(-) diff --git a/i2p2www/pages/site/misc/clt.html b/i2p2www/pages/site/misc/clt.html index f6d99154..f3264513 100644 --- a/i2p2www/pages/site/misc/clt.html +++ b/i2p2www/pages/site/misc/clt.html @@ -1,11 +1,18 @@ {% extends "global/layout.html" %} -{% block title %}I2P at CLT and PetCon 2009.1{% endblock %} -{% block content %}{% trans -%}

        +{% block title %}{% trans %}I2P at CLT and PetCon 2009.1{% endtrans %}{% endblock %} +{% block content %} +

        {% trans -%} Members of I2P will held a talk at CLT and PetCon 2009.1 -Two members of the I2P team will be at two forthcoming Linux day and security convention.

        -On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon. -Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props! Show your support!

        -Just 10 days later the Privacy and Data Security convention in Dresden will take place. +Two members of the I2P team will be at two forthcoming Linux day and security convention. +{%- endtrans %}

        + +

        {% trans chemnitzer='http://chemnitzer.linux-tage.de/2009/info/' -%} +On 14th march of 2009 there will be a short talk about general introduction to I2P at the Chemnitz Linux Tag 2009 hold by echelon. +Echelon and some other members of the I2P family will attend to the Linux meeting the whole two days (Saturday and Sunday) and will be recognizable as I2P family members. Meet them, ask them your questions, show them your props! Show your support! +{%- endtrans %}

        + +

        {% trans petcon='http://www.pet-con.org/index.php/PET_Convention_2009.1' -%} +Just 10 days later the Privacy and Data Security convention in Dresden will take place. Again, echelon will attend this event and hold a short talk about general introduction to I2P. Another talk about the profiling by the I2P clients will be held. {%- endtrans %}

        diff --git a/i2p2www/pages/site/misc/cvs.html b/i2p2www/pages/site/misc/cvs.html index 05ca9df6..554cd63c 100644 --- a/i2p2www/pages/site/misc/cvs.html +++ b/i2p2www/pages/site/misc/cvs.html @@ -1,7 +1,8 @@ {% extends "global/layout.html" %} {% block title %}CVS{% endblock %} -{% block content %}

        {% trans -%} -The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in an Monotone repository. +{% block content %} +

        {% trans monotone=site_url('get-involved/guides/monotone') -%} +The I2P sourcecode was kept in a CVS repository. Nowadays it is kept in a Monotone repository. For those who aren't very familiar with CVS, there is a fantastic book on the subject (developers only need to deal with the first chapter - "An Overview of diff --git a/i2p2www/pages/site/misc/i2ptunnel-migration.html b/i2p2www/pages/site/misc/i2ptunnel-migration.html index b585bc3d..ab32d273 100644 --- a/i2p2www/pages/site/misc/i2ptunnel-migration.html +++ b/i2p2www/pages/site/misc/i2ptunnel-migration.html @@ -1,6 +1,7 @@ {% extends "global/layout.html" %} -{% block title %}i2ptunnel migration{% endblock %} -{% block content %}

        {% trans -%}I2PTunnel migration:{%- endtrans %}

        +{% block title %}{% trans %}I2PTunnel migration{% endtrans %}{% endblock %} +{% block content %} +

        {% trans %}I2PTunnel migration{% endtrans %}

        {% trans -%} After upgrading to the new architecture, you'll have to do a @@ -14,19 +15,21 @@ old clientApp configuration, you had:

        {% trans -%}To provide that same functionality on the new web architecture:{%- endtrans %}

          -
        • Jump to http://localhost:7657/i2ptunnel/
        • -
        • Click on Add new: [Server tunnel] "GO"
        • +
        • {% trans url='http://localhost:7657/i2ptunnel/' %}Jump to {{ url }}{% endtrans %}
        • +
        • {% trans %}Click on Add new: [Server tunnel] "GO"{% endtrans %}
          • -
          • For the name: "eepsite"
          • -
          • For the description: "My eepsite, isn't it pretty?"
          • -
          • For the target host: localhost
          • -
          • For the target port: 80
          • -
          • For the private key file: path to "myWebPriv.dat"
            - (it is recommended to copy that .dat to your new install dir)
          • -
          • Check the "Start automatically?" checkbox [X]
          • -
          • Click "Save"
          • +
          • {% trans %}For the name: "eepsite"{% endtrans %}
          • +
          • {% trans %}For the description: "My eepsite, isn't it pretty?"{% endtrans %}
          • + For the target host:{% endtrans %} localhost +
          • {% trans %}For the target port:{% endtrans %} 80
          • +
          • {% trans -%} +For the private key file: path to "myWebPriv.dat"
            +(it is recommended to copy that .dat to your new install dir) +{%- endtrans %}
          • +
          • {% trans %}Check the "Start automatically?" checkbox{% endtrans %} [X]
          • +
          • {% trans %}Click "Save"{% endtrans %}
        • -
        • It will come back saying:
          +
        • {% trans %}It will come back saying:{% endtrans %}
             * Not overwriting existing private keys in /usr/home/jrandom/routers/i2p/myWebPriv.dat
             * Ready!
          @@ -36,7 +39,7 @@ old clientApp configuration, you had:
           

          {% trans -%} That's it! Creating a new I2PTunnel server works the same way too, except you don't need to "copy the old file", obviously. Behind the scenes, it is all driven -by the i2ptunnel.config file, which you may modify externally (if you do, +by the i2ptunnel.config file, which you may modify externally (if you do, hit "Reload config" on the I2PTunnel web page, which will tear down all of your existing tunnels and rebuild new ones) {%- endtrans %}

          @@ -47,4 +50,5 @@ into the network before you are able to use the /i2ptunnel/ web interface. It will say "Please be patient" if you try to beforehand, which means that it is still trying to build the necessary I2PTunnel sessions it has been configured to create. -{%- endtrans %}

          {% endblock %} +{%- endtrans %}

          +{% endblock %} diff --git a/i2p2www/pages/site/misc/i2ptunnel-services.html b/i2p2www/pages/site/misc/i2ptunnel-services.html index 5fec5bc5..c9c6f6cf 100644 --- a/i2p2www/pages/site/misc/i2ptunnel-services.html +++ b/i2p2www/pages/site/misc/i2ptunnel-services.html @@ -1,112 +1,180 @@ {% extends "global/layout.html" %} -{% block title %}i2ptunnel services{% endblock %} -{% block content %}{% trans -%} +{% block title %}{% trans %}I2PTunnel services{% endtrans %}{% endblock %} +{% block content %} +

          {% trans -%} Below is quick copy of aum's eepsite deployment guide. -{%- endtrans %}
          +{%- endtrans %}

          -
          -{% trans -%} -1. - Deploy a local server -{%- endtrans %}
          • {% trans %}For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up. {% endtrans %} -
            +{% trans %}1. - Deploy a local server{%- endtrans %} +
              +
            • {% trans -%} +For simplicity's sake, we will walk through the setup of a web server; however, this procedure is the same regardless what protocol of servers and/or clients you are setting up. +{%- endtrans %}
            • +
            • {% trans -%} +I recommend the Tiny Httpd web server, thttpd, (windows version available on site) although you can use anything that you feel comfortable with. +{%- endtrans %}
            • +
            • {% trans -%} +Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help. +{%- endtrans %}
            • +
            • {% trans -%} +With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880. +{%- endtrans %}
            • +
            • {% trans -%} +Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity). +{%- endtrans %}
            • +
            • {% trans -%} +Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen). +{%- endtrans %}
            • +
            • {% trans -%} +Once your webserver is working, and you can access it locally with your browser, continue to the next step. +{%- endtrans %}
            • +
            -
          • {% trans %}I recommend the Tiny Httpd web server , thttpd, (windows version available on site) although you can use anything that you feel comfortable with.{% endtrans %} -
            -
          • {% trans %}Another more robust option would be to use EasyPHP, which is also open source. It comes with PHP, PHPmyadmin, mySQL, and Apache web server. For newbies who have no experience setting up and hosting content over servers, see the hosting page for help. {% endtrans %} -
            -
          • {% trans %}With the web server you've chosen, configure it to listen on a port of your choice, and serve its documents from a directory of your choice. For this example, we'll assume port 10880. {% endtrans %} -
            -
          • {% trans %}Make sure your firewall is set up so that you cannot receive incoming connections on this port (which would breach your anonymity). {% endtrans %} -
            -
          • {% trans %}Test the webserver, by pointing your normal browser (the one with the "direct connection") at http://localhost:10880 (changing the 10880 to the port number you have chosen). {% endtrans %} -
            -
          • {% trans %}Once your webserver is working, and you can access it locally with your browser, continue to the next step. {% endtrans %} -
            -
          {% trans %}2 - Generate an I2P Destination Keypair {% endtrans %}
          • {% trans %}I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys. {% endtrans %} +{% trans %}2 - Generate an I2P Destination Keypair{% endtrans %} +
              +
            • {% trans -%} +I2P does not deal in IP addresses. To protect your anonymity, it deals in unique addresses called destination keys. +{%- endtrans %}
            • +
            • {% trans -%} +A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets) +{%- endtrans %}
            • +
            • {% trans -%} +To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways) +{%- endtrans %}
            • +
            • {% trans -%} +Each service you run on I2P requires a different keypair. +{%- endtrans %}
            • +
            • {% trans -%} +To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line) +{%- endtrans %}
            • +
            • {% trans -%} +In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" +{%- endtrans %}
            • +
            • {% trans -%} +The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices. +{%- endtrans %}
            • +
            • {% trans -%} +We now need to export your public key into base64 format, which you will share with others. +{%- endtrans %}
            • +
            • {% trans -%} +To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line). +{%- endtrans %}
            • +
            • {% trans -%} +This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine. +{%- endtrans %}
            • +
            • {% trans -%} +However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key. +{%- endtrans %}
            • +
            -
            -
          • {% trans %}A destination key works a lot like a regular IP address, except that it can't be traced to your IP address or physical location. When users place a request to speak with you, your gateways are the ones that answer for you. So the requesting user can only know the IP address of your gateways. However, gateways don't know your IP address, because gateways are the last nodes on your tunnels, and you anonymously create tunnels by way of garlic routing. (So gateways are like puppets that can't see their masters, and everyone communicates through these puppets) {% endtrans %} -
            -
          • {% trans %}To deploy a server on I2P, you create a destination keypair. You use the private key to authenticate your server when connecting it to I2P, and you make the public key (aka destination key) known publicly, so others can connect to your server. (indirectly, through your gateways) {% endtrans %} -
            -
          • {% trans %}Each service you run on I2P requires a different keypair. {% endtrans %} -
            -
          • {% trans %}To generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" (all on one line) {% endtrans %} -
            -
          • {% trans %}In windows, to generate your keypair, type the command: java -jar lib/i2ptunnel.jar -nogui -e "genkeys myWebPrivKey.dat myWebPubKey.dat" {% endtrans %} -
            -
          • {% trans %}The filenames myWebPrivKey.dat and myWebPubKey.dat are arbitrary - choose whatever you want here, as long as you understand your own choices. {% endtrans %} -
            -
          • {% trans %} We now need to export your public key into base64 format, which you will share with others. {% endtrans %} -
            -
          • {% trans %}To convert your myWebPubKey.dat file into shareable base64, type the command java -cp lib/i2p.jar net.i2p.data.Base64 encode myWebPubKey.dat > myWebPubKey.txt (all on one line). {% endtrans %} +{% trans %}3 - Open a 'Tunnel' from I2P To Your Server{% endtrans %} +
              +
            • {% trans -%} +For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server. +{%- endtrans %}
            • +
            • {% trans -%} +To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line). +{%- endtrans %}
            • +
            • {% trans -%} +If you used different filenames or port number earlier on, change these accordingly +{%- endtrans %}
            • +
            • {% trans -%} +Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" +{%- endtrans %}
            • +
            • {% trans -%} +Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it. +{%- endtrans %}
            • +
            -
            -
          • {% trans %}This file you have just generated, myWebPubKey.txt, contains a long base64 string (516 chars at last count), which we call a destination key. All you need to know about this string for now is that it allows remote clients to uniquely pinpoint and connect to your server, just the same way as an IP address allows remote machines to pinpoint and connect to your machine. {% endtrans %} -
            -
          • {% trans %}However, in contrast to an IP address, there is no way to trace your machine's physical location - even though your server can be addressed via I2P, your IP address cannot be traced or associated with this destination key. {% endtrans %} -
            -
          {% trans %}3 - Open a 'Tunnel' from I2P To Your Server{% endtrans %}
          • {% trans %}For clients elsewhere in I2P to be able to access your server, you must run a 'bridge' or 'tunnel', which takes connections from these clients and forwards them to your local server {% endtrans %} -
            -
          • {% trans %}To activate such a tunnel, type the command java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" (all one line) {% endtrans %} -
            -
          • {% trans %}If you used different filenames or port number earlier on, change these accordingly {% endtrans %} -
            -
          • {% trans %}Windows users, remember to replace apostrophes with double quotes. Thus: java -jar lib/i2ptunnel.jar -nogui -e "server localhost 10880 myWebPrivKey.dat" {% endtrans %} -
            -
          • {% trans %}Within a few seconds, the 'tunnel' should now be active, and remote clients should be able to reach your server anonymously. Remember to let your router "warm up" before opening clients to it. {% endtrans %} -
            -
          {% trans %}4 - Update Your hosts.txt File {% endtrans %}
          • {% trans %}To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server. {% endtrans %} +{% trans %}4 - Update Your hosts.txt File {% endtrans %} +
              +
            • {% trans -%} +To test your own server locally, you'll need to create an entry in your hosts.txt file, so I2P can translate the simple URL you place in the browser's address bar into the full public key text needed to find your server. +{%- endtrans %}
            • +
            • {% trans -%} +Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt +{%- endtrans %}
            • +
            • {% trans -%} +With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar. +{%- endtrans %}
            • +
            -
            -
          • {% trans %}Edit your hosts.txt, and add the line myserver.i2p=blahblahblah, where myserver.i2p is an I2P 'domain' you want to associate with your site, and the blahblahblah is the text of the base64 public key you created earlier in the file myWebPubKey.txt {% endtrans %} -
            -
          • {% trans %}With this in place, you and others can reach your server with the simple domain name myserver.i2p in the browser's address bar. {% endtrans %} -
            -
          {% trans %}5 - Surf Your Site Within I2P{% endtrans %}
          • {% trans %}Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p{% endtrans %} -
            -
          • {% trans %}You should see the main page of your webserver come up. {% endtrans %} -
            -
          {% trans %}6 - Create a Local Client Tunnel Connection {% endtrans %}
          • {% trans %}We now have to think beyond just web servers. {% endtrans %} -
            -
          • {% trans %}As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients. {% endtrans %} -
            +{% trans %}5 - Surf Your Site Within I2P{% endtrans %} +
              +
            • {% trans -%} +Using your secondary browser - the one you earlier configured to use localhost:4444 as a proxy - point this browser to the address http://myserver.i2p +{%- endtrans %}
            • +
            • {% trans -%} +You should see the main page of your webserver come up. +{%- endtrans %}
            • +
            -
          • {% trans %}The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network. {% endtrans %} -
            -
          • {% trans %}You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode. {% endtrans %} -
            -
          • {% trans %}Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end. {% endtrans %} -
            -
          • {% trans %}To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line). {% endtrans %} -
            -
          • {% trans %}The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on. {% endtrans %} -
            -
          • {% trans %}textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p) {% endtrans %} -
            -
          • {% trans %}Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use. {% endtrans %} -
            -
          • {% trans %}Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888 {% endtrans %} +{% trans %}6 - Create a Local Client Tunnel Connection {% endtrans %} +
              +
            • {% trans -%} +We now have to think beyond just web servers. +{%- endtrans %}
            • +
            • {% trans -%} +As you grow into I2P and get more of a 'feel' for it, you will want to use all manner of servers and clients. +{%- endtrans %}
            • +
            • {% trans -%} +The beauty of I2P is that it allows standard Internet clients and servers for most protocols to be transparently 'tunneled' through the anonymous network. +{%- endtrans %}
            • +
            • {% trans -%} +You can run mailservers/clients, nameservers/clients, newsservers/clients - almost anything at all - perhaps even FTP in passive mode. +{%- endtrans %}
            • +
            • {% trans -%} +Now, we'll create a client tunnel. This is like the server tunnel we created earlier, but works in reverse. It listens to a port on your local machine; your local client connects to this port; the connection gets forwarded through I2P to the service on the other end. +{%- endtrans %}
            • +
            • {% trans -%} +To open your client tunnel for your server, type the command java -jar lib/i2ptunnel.jar -nogui -e "config localhost 7654" -e "client 10888 textofbase64key" (all one line). +{%- endtrans %}
            • +
            • {% trans -%} +The port 10888 is arbitrary - it just needs to be something other than the physical port your server is listening on. +{%- endtrans %}
            • +
            • {% trans -%} +textofbase64key is simply the contents of the public key text file myWebPubKey.txt, reproduced fully on one line (alternately, instead of textofbase64key, you can specify the name from your hosts.txt - e.g. myserver.i2p) +{%- endtrans %}
            • +
            • {% trans -%} +Within a minute or two of launching this command, the client tunnel from your local machine into I2P will be open and ready for use. +{%- endtrans %}
            • +
            • {% trans -%} +Point your regular web browser (ie, not the one you configured to use localhost:4444), and point it to http://localhost:10888 +{%- endtrans %}
            • +
            • {% trans -%} +Verify that the main page of your server eventually comes up in your browser. +{%- endtrans %}
            • +
            • {% trans -%} +You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content. +{%- endtrans %}
            • +
            -
            -
          • {% trans %}Verify that the main page of your server eventually comes up in your browser. {% endtrans %} -
            -
          • {% trans %}You use the same procedure for using any local client program to access a remote I2P server - just get the base64 public key (called destination key) of the remote server, choose a local port to connect to the remote server, open the tunnel, and just connect with your client to your heart's content. {% endtrans %} -
            -
          {% trans %}7 - Share your server details with others{% endtrans %}
          • {% trans %}Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity. {% endtrans %} -
            -
          • {% trans %}Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address. {% endtrans %} -
            -
          {% trans %}8 - Write Some Scripts To Handle All This Menial Nonsense{% endtrans %}
          • {% trans %}It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client. {% endtrans %} -
            -
          • {% trans %}Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent. {% endtrans %} +{% trans %}7 - Share your server details with others{% endtrans %} +
              +
            • {% trans -%} +Using an anonymous medium (eg the one of the I2P IRC servers or ugha's wiki), post your domain name (eg www.mynick.i2p as well as your destination key. Others will then be able to reach your server remotely, without either of you jeopardizing your anonymity. +{%- endtrans %}
            • +
            • {% trans -%} +Remember, you can go to What's on I2P and find the latest public keys linked to their URL. You should also post your own public key and URL their. However, you will want to do this anonymously, of course. Drupal.i2p.net is currently, as of this writing, only accessible from the net. So, to access the outside WWW anonymously from inside of I2P, you will need to start up your script called startSquid. Do it the same way you have been doing these other scripts. Reconfigure your browser to proxy on localhost:5555, as defined in the script, and when the script has generated it's keys, you can access the squid proxy. Put any WWW URL (such as Google or this i2p site) into your browser's address bar and you will be surfing the World Wide Web anonymously. Now you can safely post your public key, and no one can detect your IP address. +{%- endtrans %}
            • +
            -
            -
          • {% trans %}So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language. {% endtrans %} -
            -
          • {% trans %}Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here. {% endtrans %} -
            -
          • {% trans %}Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file. { %endtrans % } -
            +{% trans %}8 - Write Some Scripts To Handle All This Menial Nonsense{% endtrans %} +
              +
            • {% trans -%} +It would drive most people crazy, going through all these steps every time one sets up an I2P server, and/or deploys a client. +{%- endtrans %}
            • +
            • {% trans -%} +Aum's website http://www.freenet.org.nz/i2p/ has a script called setupServer.py which automates all this nonsense into one simple command line . But I respect that people's tastes in user interfaces differ, and trying to write something which satisfies everyone's needs usually results in something so complex that it turns into newbie-repellent. +{%- endtrans %}
            • +
            • {% trans -%} +So please feel free to use and/or customize setupServer.py to taste, or write your own in Python or another language. +{%- endtrans %}
            • +
            • {% trans -%} +Also, you may want to write a script which handles the startup of the I2P Router, the eepProxy, plus any and all tunnels you are using. I've got such a script called startEverything.sh, which gets launched at system startup. (Be sure to search this site for template scripts to automate your I2P commands. If I create a page for one, I'll try to remember to link it here. +{%- endtrans %}
            • +
            • {% trans -%} +Exercise for Windows users - port setupServer.py into a MS-DOS .BAT file. +{%- endtrans %}
            {% endblock %} diff --git a/i2p2www/pages/site/misc/invisiblenet.html b/i2p2www/pages/site/misc/invisiblenet.html index 1d941e18..7331d313 100644 --- a/i2p2www/pages/site/misc/invisiblenet.html +++ b/i2p2www/pages/site/misc/invisiblenet.html @@ -1,14 +1,14 @@ {% extends "global/layout.html" %} -{% block title %}Old Documents{% endblock %} +{% block title %}{% trans %}Old Documents{% endtrans %}{% endblock %} {% block content %} -{% trans -%} +

            {% trans -%} Following is a list of documents originally on www.invisiblenet.net/i2p/ and rescued via the Wayback Machine. They are quite dated and may or may not be accurate. However, the I2CP and I2NP documents in particular have some good information. -{%- endtrans %} +{%- endtrans %}

            Index of /i2p

            Name                    Last modified       Size
            diff --git a/i2p2www/pages/site/misc/jbigi.html b/i2p2www/pages/site/misc/jbigi.html
            index e531c722..caa4123f 100644
            --- a/i2p2www/pages/site/misc/jbigi.html
            +++ b/i2p2www/pages/site/misc/jbigi.html
            @@ -1,6 +1,6 @@
             {% extends "global/layout.html" %}
             {% block title %}jbigi{% endblock %}
            -{% block lastupdated %}August 2011{% endblock %}
            +{% block lastupdated %}{% trans %}August 2011{% endtrans %}{% endblock %}
             {% block accuratefor %}0.8.7{% endblock %}
             {% block content %}
             

            {% trans %}Overview{% endtrans %}

            @@ -10,24 +10,27 @@ manual work and a piece of chewing gum we have made several cryptography operations quite a bit faster. {%- endtrans %}

            -

            {% trans -%} +

            {% trans gmplib='http://gmplib.org/', +func='http://gmplib.org/manual-4.3.2/Integer-Exponentiation.html#Integer-Exponentiation', +bigint='http://download.oracle.com/javase/1.5.0/docs/api/java/math/BigInteger.html#modPow%28java.math.BigInteger,%20java.math.BigInteger%29' -%} The speedup comes from the super-fast -GNU MP Bignum library (libgmp). +GNU MP Bignum library (libgmp). We use a single function from libgmp - -mpz_powm() +mpz_powm() as a replacement for the -Java Math library's BigInteger modPow(). +Java Math library's BigInteger modPow(). As modPow() is a significant computational portion of many crypto operations, this is of significant benefit. {%- endtrans %}

            -

            {% trans -%} +

            {% trans nativebigint='http://docs.i2p-projekt.de/javadoc/net/i2p/util/NativeBigInteger.html', +bigint='http://download.oracle.com/javase/1.5.0/docs/api/java/math/BigInteger.html#modPow%28java.math.BigInteger,%20java.math.BigInteger%29' -%} The standard I2P installation includes about 20 versions of the library for different platforms, each about 50KB, inside the jbigi.jar file. The initialization of the JBigI library, including CPU identification, selection, and extraction of the correct loadable module, is handled by the -NativeBigInteger class. +NativeBigInteger class. If no module is available for the current platform, the standard -Java Math library's BigInteger modPow() +Java Math library's BigInteger modPow() is used. {%- endtrans %}

            @@ -81,12 +84,12 @@ The network average for encrypt time is about 20ms. If your encrypt time is less than 50ms for a relatively new processor, or less than 100ms for an older processor, and the native BigInteger library was loaded, you are probably fine. {%- endtrans %}
          • -
          • {% trans -%} +
          • {% trans downloads=get_url('downloads_list') -%} Get the latest released source code of I2P from -the download page, or get the cutting-edge source +the download page, or get the cutting-edge source out of the monotone database mtn.i2p2.de {%- endtrans %}
          • -
          • {$ trans %}Inside the source tree change directory to: core/c/jbigi{% endtrans %}
          • +
          • {% trans %}Inside the source tree change directory to: core/c/jbigi{% endtrans %}
          • {% trans -%} Read the README file. If you have a /usr/lib/libgmp.so file, you do not have to download GMP. @@ -102,7 +105,7 @@ Otherwise change the settings. Remember, you need the Java SDK installed. {%- endtrans %}
          • {% trans -%} Run build.sh (if you downloaded GMP) or - build.sh dynamic (if you have /usr/lib/libgmp.so).
            +build.sh dynamic (if you have /usr/lib/libgmp.so).
            Maybe the build spewed out some errors of missing jni.h and jni_md.h files. Either copy these files from your java install into the core/c/jbigi/jbigi/include/ directory, or fix $JAVA_HOME.
            @@ -122,16 +125,13 @@ native run time: 5842ms ( 57ms each) java run time: 41072ms (406ms each) native = 14.223802103622907% of pure java time
          -{% trans %}If the native is indeed 5-7x faster (or more) then it looks all good. If not, please -report.{% endtrans %}
        • +{% trans %}If the native is indeed 5-7x faster (or more) then it looks all good. If not, please report.{% endtrans %}
        • {% trans %}Copy libjbigi.so to your i2p directory{% endtrans %}
        • {% trans %}Restart your I2P programs.{% endtrans %}
        • -
        • {% trans %}On{% endtrans %} -{% trans %}http://localhost:7657/stats.jsp +
        • {% trans -%} +On http://localhost:7657/stats.jsp the crypto.elGamal.decrypt and crypto.elGamal.encrypt -should be a lot faster.
        • {% endtrans %} +should be a lot faster. +{%- endtrans %} - - - {% endblock %} diff --git a/i2p2www/pages/site/misc/jrandom-awol.html b/i2p2www/pages/site/misc/jrandom-awol.html index d2c816d3..afdbf49e 100644 --- a/i2p2www/pages/site/misc/jrandom-awol.html +++ b/i2p2www/pages/site/misc/jrandom-awol.html @@ -1,20 +1,24 @@ {% extends "global/layout.html" %} -{% block title %}Jrandom's Announcement{% endblock %} +{% block title %}{% trans %}Jrandom's Announcement{% endtrans %}{% endblock %} {% block content %} -{% trans %}The following message was received in mid-November 2007. We have no further information -on jrandom's status.{% endtrans %}

          {% trans -%} +The following message was received in mid-November 2007. We have no further information +on jrandom's status. +{%- endtrans %}

          + +

          {% trans site=site_url() -%} Subsequently, in an unrelated incident, the hosting company for all *.i2p.net servers (except forum.i2p.net) suffered a power outage on January 13, 2008, and the i2p.net servers did not fully return to service. As only jrandom has the credentials required to restore service, and he could not be contacted, -we moved all public services to www.i2p2.de +we moved all public services to www.i2p2.de and related subdomains. {%- endtrans %}

          -

          {% trans -%} + +

          {% trans forum=i2pconv('forum.i2p') -%} Approximately two months later, for unrelated reasons, -forum.i2p.net was moved to forum.i2p2.de. +forum.i2p.net was moved to {{ forum }}. {%- endtrans %}

           -----BEGIN PGP SIGNED MESSAGE-----
          diff --git a/i2p2www/pages/site/misc/manual-wrapper.html b/i2p2www/pages/site/misc/manual-wrapper.html
          index ddd83e52..9b08a600 100644
          --- a/i2p2www/pages/site/misc/manual-wrapper.html
          +++ b/i2p2www/pages/site/misc/manual-wrapper.html
          @@ -1,55 +1,68 @@
           {% extends "global/layout.html" %}
          -{% block title %}Manually Installing the Java Wrapper{% endblock %}
          +{% block title %}{% trans %}Manually Installing the Java Wrapper{% endtrans %}{% endblock %}
           {% block content %}
           

          {% trans %}Manually Installing the Java Wrapper{% endtrans %}

          -

          {% trans -%} -The installation package for the I2P router comes +

          {% trans downloads=get_url('downloads_list') -%} +The installation package for the I2P router comes with a Java wrapper for the most common architectures. If your system is not supported by our installer—or if you want to update the wrapper to a newer version—the following steps describe installing the wrapper manually. {%- endtrans %}

            -
          • {% trans %}Check Tanuki Software's download page - for your platform. Is your platform listed? If so, you're in - luck! Download the most recent version of the Community Edition for your OS and - CPU and move to the next step{% endtrans %}
          • -
          • {% trans %}If your platform does not have an already compiled wrapper available, you - may be able to compile it yourself. If you are willing to have a go at it, move - on to compiling the wrapper for your system.{% endtrans %}
          • +
          • {% trans -%} +Check Tanuki Software's download page +for your platform. Is your platform listed? If so, you're in +luck! Download the most recent version of the Community Edition for your OS and +CPU and move to the next step. +{%- endtrans %}
          • +
          • {% trans -%} +If your platform does not have an already compiled wrapper available, you +may be able to compile it yourself. If you are willing to have a go at it, move +on to compiling the wrapper for your system. +{%- endtrans %}
          +

          {% trans %}Using existing binaries{% endtrans %}

          -{% trans %}In the steps below, $I2P means the location I2P was installed to.{% endtrans %} +

          {% trans -%} +In the steps below, $I2P means the location I2P was installed to. +{%- endtrans %}

          1. tar xzf wrapper-*.tar.gz
          2. cp wrapper*/bin/wrapper $I2P/i2psvc
          3. cp wrapper*/lib/wrapper.jar $I2P/lib
          4. cp wrapper*/lib/libwrapper.so $I2P/lib
          5. -
          6. {% trans %}Try to start I2P using {% endtrans %}$I2P/i2prouter start
          7. -
          8. tail -f /tmp/wrapper.log and look for any problems.
          -{% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %} +
        • {% trans %}Try to start I2P using $I2P/i2prouter start{% endtrans %}
        • +
        • {% trans %}tail -f /tmp/wrapper.log and look for any problems.{% endtrans %}
        • + +

          {% trans -%} +If this did not work you'll need to use runplain.sh to start I2P. +{%- endtrans %}

          +

          {% trans %}Compiling from source{% endtrans %}

          -{% trans %}These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system.{% endtrans %} +

          {% trans -%} +These steps worked to compile the wrapper for use on a mipsel system running Debian. The steps will need to be altered for your system. +{%- endtrans %}

          1. {% trans %}Download the source archive for the community version of the wrapper from wrapper download page.{% endtrans %}
          2. {% trans %}Extract the tarball{% endtrans %}
                tar xzf wrapper_3.5.13_src.tar.gz
          3. -
          4. Set environment variables ANT_HOME and JAVA_HOME. In Debian, one can
            +
          5. {% trans %}Set environment variables ANT_HOME and JAVA_HOME. For example, in Debian:{% endtrans %}
                export ANT_HOME=/usr/share/ant
                export JAVA_HOME=/usr/lib/jvm/default-java
          6. -
          7. Since there isn't a Makefile for Mipsel, we'll make a copy of an already existing makefile
            +
          8. {% trans %}Since there isn't a Makefile for Mipsel, we'll make a copy of an already existing makefile:{% endtrans %}
                cp src/c/Makefile-linux-x86-32.make src/c/Makefile-linux-mipsel-32.make
          9. -
          10. Now we can attempt to compile the wrapper
            -    ./build32.sh (use ./build64.sh if you have a 64bit CPU and JVM)
          11. -
          12. Copy the wrapper into its proper place: +
          13. {% trans %}Now we can attempt to compile the wrapper:{% endtrans %}
            +    ./build32.sh ({% trans %}use ./build64.sh if you have a 64bit CPU and JVM{% endtrans %})
          14. +
          15. {% trans %}Copy the wrapper into its proper place:{% endtrans %}
            • cp bin/wrapper $I2P/i2psvc
            • cp lib/wrapper.jar $I2P/lib
            • cp lib/libwrapper.so $I2P/lib
          16. {% trans %}Try to start I2P using $I2P/i2prouter start{% endtrans %}
          17. -
          18. tail -f /tmp/wrapper.log and look for any problems.
          19. +
          20. {% trans %}tail -f /tmp/wrapper.log and look for any problems.{% endtrans %}
          -{% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %} +

          {% trans %}If this did not work you'll need to use runplain.sh to start I2P.{% endtrans %}

          {% endblock %} diff --git a/i2p2www/pages/site/misc/minwww.html b/i2p2www/pages/site/misc/minwww.html index 658df060..c6590361 100644 --- a/i2p2www/pages/site/misc/minwww.html +++ b/i2p2www/pages/site/misc/minwww.html @@ -1,9 +1,10 @@ {% extends "global/layout.html" %} {% block title %}minwww{% endblock %} -{% block content %}

          {% trans -%} -Here's an outline and rationale for a minimal WWW proxy app for use over -I2P. +{% block content %} +

          {% trans -%} +Here's an outline and rationale for a minimal WWW proxy app for use over I2P. {%- endtrans %}

          +

          {% trans -%} HTTP operation over I2P using I2PTunnel. When the base SocketLibrary is out, the only significant difference will be the 'wrapRequest' and @@ -42,6 +43,7 @@ skipped) 26: receiveACK receiveClose 27: sentSuccess

          +

          {% trans -%} An optimized form, designed to handle only 128KB [1] files and pages, can operate significantly faster: @@ -65,6 +67,7 @@ operate significantly faster: 15: closeCon 16: closed

        +

        {% trans -%} The difference in network load and latency is significant - this is essentially a UDP version of HTTP. On the normal web, we can't really do that, @@ -76,6 +79,7 @@ DataMessage with a DeliveryStatusMessage to provide guaranteed delivery), the MinWWW proxy deals with resends (if necessary - in I2PTunnel today, there are no resends). {%- endtrans %}

        +

        {% trans -%} The data that the MinWWW proxy and server need to wrap is trivial - when the proxy wants to send "GET /", it prepends it with the I2P Destination sending @@ -85,6 +89,7 @@ response, and sends a reply to the MinWWW proxy containing the response, prefixed with the original request ID. That response is taken and passed back to the browser and the connection is closed. {%- endtrans %}

        +

        {% trans -%} In addition, the MinWWW proxy can choose the MinWWW server to use from a list, going through some round robin or other algorithm, so that there are @@ -92,6 +97,7 @@ multiple outproxies merged transparently. The bandwidth required for running one of these outproxies is also greatly reduced, since it will only handle 128KB files (aka no one is going to be downloading porn, warez, etc). {%- endtrans %}

        +

        {% trans -%} The functionality /is/ limited, but 128KB of data is a lot for a single HTTP request or response. The above diagrams are also unrealistic in their hops - @@ -103,6 +109,7 @@ entire tunnel path (4+ remote hops each time when tunnels are 2 remote hops in each stretch), leaving MinWWW with only two full traversals (one for the request, one for the response), instead of 10. {%- endtrans %}

        +

        {% trans -%} Implementing the MinWWW proxy and server should be fairly easy - read an HTTP request from the client fully (perhaps only start out with HTTP GET, leaving @@ -111,6 +118,7 @@ in turn simply needs to parse the request to either open a socket or URL, send the request, wait for the response, and send it back through the network. If someone were to implement this, it would be Good :) {%- endtrans %}

        +

        {% trans -%} [1] Why 128KB files? Currently I2CP allows functionally arbitrary message size, but that's going to be going away since it involves either excessive memory diff --git a/i2p2www/pages/site/misc/myi2p.html b/i2p2www/pages/site/misc/myi2p.html index a0b15440..e7457b05 100644 --- a/i2p2www/pages/site/misc/myi2p.html +++ b/i2p2www/pages/site/misc/myi2p.html @@ -1,16 +1,18 @@ {% extends "global/layout.html" %} {% block title %}MYI2P{% endblock %} -{% block content %}

        {% trans -%} +{% block content %} +

        {% trans -%} There has been discussion about a distributed blogging application for a few months now called "MyI2P". While the original discussions were lost, we were able to retrieve a Google cache of it. It isn't pretty, but it includes the basic overview and some discussion -that ensued.{%- endtrans %}

        +that ensued. +{%- endtrans %}

        -

        {% trans -%} +

        {% trans roadmap=site_url('get-involved/roadmap'), datagrams=site_url('docs/spec/datagrams') -%} The application itself is not yet implemented, and the ideas behind it have been made less ambitious over time, but they are still valid and the current -plan is to have the core MyI2P functionality available +plan is to have the core MyI2P functionality available along side the I2P 1.0 release. That will include a distributed address book to enable secure, distributed, and human readable naming by sacrificing the need for global uniqueness - basically everyone has their own local address book @@ -21,7 +23,7 @@ system using a reduced and secured subset of bbcode to essentially provide an anonymous LiveJournal with a 'friends list' and transparent access control (authenticated by the I2P -datagrams with rules defined based on the address book). +datagrams with rules defined based on the address book). {%- endtrans %}

        {% trans -%} diff --git a/i2p2www/pages/site/misc/ratestats.html b/i2p2www/pages/site/misc/ratestats.html index 7ad450c1..6a1fb1ac 100644 --- a/i2p2www/pages/site/misc/ratestats.html +++ b/i2p2www/pages/site/misc/ratestats.html @@ -1,15 +1,15 @@ {% extends "global/layout.html" %} -{% block title %}RateStat list{% endblock %} +{% block title %}{% trans %}RateStat list{% endtrans %}{% endblock %} +{% block accuratefor %}0.8.7{% endblock %} {% block content %}

        {% trans %}RateStat list{% endtrans %}

        -

        {% trans %}I2P enables the collection of a wide range of rates, the list published here is accurate as of I2P version 0.8.7.{% endtrans %}

        -

        {% trans %}The list was gathered using the following command in the top directory of the branch i2p.i2p, +

        {% trans %}I2P enables the collection of a wide range of rates.{% endtrans %}

        +

        {% trans %}The list was gathered using the following command in the top directory of the branch i2p.i2p:{% endtrans %}

         find . -name '*' -print | xargs --max-args=3 grep -n --color=auto addRateData | awk 'match($0, /addRateData\(\"(.*)\"/, a) {print a[1]}' | awk '!_[$0]++' | sort > rates.txt
         
        -All options aren't needed, but it works.{% endtrans %} -

        +

        {% trans %}All options aren't needed, but it works.{% endtrans %}

        -

        {% trans %}RateStats{% endtrans %}

        +

        RateStats

         bwLimiter.inboundDelayedTime
         bwLimiter.outboundDelayedTime
        diff --git a/i2p2www/pages/site/misc/transition-guide.html b/i2p2www/pages/site/misc/transition-guide.html
        index 119eb5ea..7b6ce216 100644
        --- a/i2p2www/pages/site/misc/transition-guide.html
        +++ b/i2p2www/pages/site/misc/transition-guide.html
        @@ -1,15 +1,16 @@
         {% extends "global/layout.html" %}
         {% block title %}Monotone{% endblock %}
        -{% block content %}

        {% trans -%} +{% block content %} +

        {% trans forum=i2pconv('forum.i2p'), newdevs=site_url('get-involved/guides/new-developers') -%} The I2P sourcecode is kept in several distributed monotone repositories. See the Monotone website for information on monotone. See -this forum post on i2p monotone +this forum post on i2p monotone for more information on how to get started and check out the source anonymously. There is also a quick-start guide on the -new developer's page. +new developer's page. {%- endtrans %}

        {% trans -%} @@ -17,7 +18,7 @@ If you want to get the source non-anonymously, pull from the public server mtn.w The i2p source code branch is "i2p.i2p". {%- endtrans %}

        -

        {% trans %} Guide {% endtrans %}

        +

        {% trans %}Guide{% endtrans %}

        {%- trans %} The following is a detailed guide by Complication. {%- endtrans %}

        diff --git a/i2p2www/pages/site/misc/upgrade-0.6.1.30.html b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html index 91dd2d46..c0d267fc 100644 --- a/i2p2www/pages/site/misc/upgrade-0.6.1.30.html +++ b/i2p2www/pages/site/misc/upgrade-0.6.1.30.html @@ -1,64 +1,73 @@ {% extends "global/layout.html" %} -{% block title %}How to Upgrade from 0.6.1.30 and Earlier{% endblock %} +{% block title %}{% trans %}How to Upgrade from 0.6.1.30 and Earlier{% endtrans %}{% endblock %} {% block content %}

        • 2008-02-05: {% trans %}Upgrading from 0.6.1.30 and Earlier Releases{% endtrans %}

        -

        {% trans -%} +

        {% trans jrandom=site_url('misc/jrandom-awol') -%} Since i2p's lead developer -has gone AWOL, +has gone AWOL, we do not have his update signing key or access to www.i2p[.net] or dev.i2p[.net]. Complication and zzz have generated new signing keys, and they and Amiga are providing update file hosting. These changes must be configured in your router to take effect. {%- endtrans %}

        +

        {% trans -%} Make the following configuration changes and your router will automatically install the latest release. {%- endtrans %}

        -

        {% trans -%} + +

        {% trans downloads=get_url('downloads_list') -%} We recommend the automated process as it will verify the key of the signed update file. If you do not make these changes, -you may manually download the i2pupdate.zip file from{% endtrans %} -the download page. -

        1. +you may manually download the i2pupdate.zip file from +the download page. +{%- endtrans %}

          + +
            +
          1. On configupdate.jsp: -
            1. -Change the News URL to: http://complication.i2p/news.xml -
            2. +
                +
              1. {% trans url='http://complication.i2p/news.xml' -%} +Change the News URL to: {{ url }} +{%- endtrans %}
              2. +
              3. {% trans %}Select ONE of the following new Update URLs at random and enter it into the Update URL box: {% endtrans %}
                http://amiga.i2p/i2p/i2pupdate.sud
                http://complication.i2p/i2p/i2pupdate.sud
                http://stats.i2p/i2p/i2pupdate.sud -
              4. -Check the box "Update through the eepProxy?" -
              5. -Click "Save" -
              +
            3. +
            4. {% trans %}Check the box "Update through the eepProxy?"{% endtrans %}
            5. +
            6. {% trans %}Click "Save"{% endtrans %}
            7. +
            +
          2. On configadvanced.jsp: -
            1. -Add the following line: +
                +
              1. {% trans %}Add the following line:{% endtrans %}
                -
              2. -Click "Apply" -
              -
            2. {% trans -%}You are now ready to automatically receive the release update file, +
            3. +
            4. {% trans %}Click "Apply"{% endtrans %}
            5. +
            +
          3. +
          4. {% trans -%} +You are now ready to automatically receive the release update file, either by setting your update policy to "download and install" or by clicking on the "update available" link when it appears. -{%- endtrans %}
          -

          -

          {% trans -%} +{%- endtrans %}

        2. +
        + +

        {% trans url='http://'+i2pconv('stats.i2p')+'/i2p/signingkeys.html' -%} If you would like to verify the trusted update keys, they are also -posted and signed here. +posted and signed here. Thank you for your support during this transition. For help please contact us on #i2p. {%- endtrans %}

        -

        {% trans -%} -Amiga, Complication, welterde, zzz -{%- endtrans %}

        + +

        Amiga, Complication, welterde, zzz

        {% endblock %} From dd2ac0f87670d2d8d7eb14d993f9c316c9b496c6 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 23:05:16 +0000 Subject: [PATCH 374/498] Added translation tags to docs/how/peer-selection --- .../pages/site/docs/how/peer-selection.html | 264 +++++++++++------- 1 file changed, 159 insertions(+), 105 deletions(-) diff --git a/i2p2www/pages/site/docs/how/peer-selection.html b/i2p2www/pages/site/docs/how/peer-selection.html index 032a25da..2537ef3e 100644 --- a/i2p2www/pages/site/docs/how/peer-selection.html +++ b/i2p2www/pages/site/docs/how/peer-selection.html @@ -1,35 +1,41 @@ {% extends "global/layout.html" %} -{% block title %}Peer Profiling and Selection{% endblock %} -{% block lastupdated %}July 2010{% endblock %} +{% block title %}{% trans %}Peer Profiling and Selection{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}July 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        Overview

        +

        {% trans %}Overview{% endtrans %}

        -

        Peer Profiling

        +

        {% trans %}Peer Profiling{% endtrans %}

        -

        Peer profiling is the process of collecting data based on the observed performance +

        {% trans netdb=site_url('docs/how/network-database') -%} +Peer profiling is the process of collecting data based on the observed performance of other routers or peers, and classifying those peers into groups. Profiling does not use any claimed performance data published by the peer itself -in the network database. +in the network database. +{%- endtrans %}

        -

        -Profiles are used for two purposes: +

        {% trans %}Profiles are used for two purposes:{% endtrans %}

          -
        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 +
        3. {% trans %}Selecting peers to relay our traffic through, which is discussed below{% endtrans %}
        4. +
        5. {% trans netdb=site_url('docs/how/network-database') -%} +Choosing peers from the set of floodfill routers to use for network database storage and queries, +which is discussed on the network database page +{%- endtrans %}
        -

        Peer Selection

        -

        Peer selection is the process of choosing which routers +

        {% trans %}Peer Selection{% endtrans %}

        +

        {% trans -%} +Peer selection is the process of choosing which routers on the network we want to relay our messages to go through (which peers will we ask to join our tunnels). To accomplish this, we keep track of how each peer performs (the peer's "profile") and use that data to estimate how fast they are, how often they will be able to accept our requests, and whether they seem to be overloaded or otherwise unable to perform what -they agree to reliably.

        -

        +they agree to reliably. +{%- endtrans %}

        + +

        {% trans threatmodel=site_url('docs/how/threat-model') -%} Unlike some other anonymous networks, in I2P, claimed bandwidth is untrusted and is only used to avoid those peers advertising very low bandwidth insufficient for routing tunnels. @@ -37,61 +43,64 @@ 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. -

        -

        +{%- endtrans %}

        + +

        {% trans -%} Peer selection is done quite frequently, as a router may maintain a large number of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes. +{%- endtrans %}

        -

        Further Information

        -

        +

        {% trans %}Further Information{% endtrans %}

        +

        {% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf'), +url='http://www.pet-con.org/index.php/PET_Convention_2009.1' -%} For more information see the paper -Peer Profiling and Selection in the I2P Anonymous Network -presented at -PET-CON 2009.1. +Peer Profiling and Selection in the I2P Anonymous Network +presented at PET-CON 2009.1. See below for notes on minor changes since the paper was published. -

        +{%- endtrans %}

        -

        Profiles

        - -

        Each peer has a set of data points collected about them, including statistics +

        {% trans %}Profiles{% endtrans %}

        +

        {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/PeerProfile.html' -%} +Each peer has a set of data points collected about them, including statistics about how long it takes for them to reply to a network database query, how often their tunnels fail, and how many new peers they are able to introduce us to, as well as simple data points such as when we last heard from them or when the last communication error occurred. The specific data points gathered -can be found in the code -

        +can be found in the code. +{%- endtrans %}

        -

        +

        {% trans -%} Profiles are fairly small, a few KB. To control memory usage, the profile expiration time lessens as the number of profiles grows. Profiles are kept in memory until router shutdown, when they are written to disk. At startup, the profiles are read so the router need not reinitialize all profiles, thus allowing a router to quickly re-integrate into the network after startup. -

        +{%- endtrans %}

        -

        Peer Summaries

        - -

        While the profiles themselves can be considered a summary of a peer's +

        {% trans %}Peer Summaries{% endtrans %}

        +

        {% trans -%} +While the profiles themselves can be considered a summary of a peer's performance, to allow for effective peer selection we break each summary down into four simple values, representing the peer's speed, its capacity, how well -integrated into the network it is, and whether it is failing.

        +integrated into the network it is, and whether it is failing. +{%- endtrans %}

        -

        Speed

        - -

        The speed calculation +

        {% trans %}Speed{% endtrans %}

        +

        {% trans -%} +The speed calculation simply goes through the profile and estimates how much data we can send or receive on a single tunnel through the peer in a minute. For this estimate it just looks at performance in the previous minute. -

        +{%- endtrans %}

        -

        Capacity

        - -

        The capacity calculation +

        {% trans %}Capacity{% endtrans %}

        +

        {% trans -%} +The capacity calculation simply goes through the profile and estimates how many tunnels the peer would agree to participate in over a given time period. For this estimate it looks at how many tunnel build requests @@ -99,7 +108,9 @@ the peer has accepted, rejected, and dropped, and how many of the agreed-to tunnels later failed. While the calculation is time-weighted so that recent activity counts more than later activity, statistics up to 48 hours old may be included. -

        +{%- endtrans %}

        + +

        {% trans -%} Recognizing and avoiding unreliable and unreachable peers is critically important. Unfortunately, as the tunnel building and testing require the participation of several peers, @@ -107,152 +118,195 @@ it is difficult to positively identify the cause of a dropped build request or t The router assigns a probability of failure to each of the peers, and uses that probability in the capacity calculation. Drops and test failures are weighted much higher than rejections. -

        +{%- endtrans %}

        -

        Peer organization

        - -

        As mentioned above, we drill through each peer's profile to come up with a +

        {% trans %}Peer organization{% endtrans %}

        +

        {% trans -%} +As mentioned above, we drill through each peer's profile to come up with a few key calculations, and based upon those, we organize each peer into three groups - fast, high capacity, and standard. +{%- endtrans %}

        -

        The groupings are not mutually exclusive, nor are they unrelated:

          -
        • A peer is considered "high capacity" if its capacity calculation meets or - exceeds the median of all peers.
        • -
        • A peer is considered "fast" if they are already "high capacity" and their - speed calculation meets or exceeds the median of all peers.
        • -
        • A peer is considered "standard" if it is not "high capacity"
        • +

          {% trans -%} +The groupings are not mutually exclusive, nor are they unrelated: +{%- endtrans %}

          +
            +
          • {% trans -%} +A peer is considered "high capacity" if its capacity calculation meets or +exceeds the median of all peers. +{%- endtrans %}
          • +
          • {% trans -%} +A peer is considered "fast" if they are already "high capacity" and their +speed calculation meets or exceeds the median of all peers. +{%- endtrans %}
          • +
          • {% trans %}A peer is considered "standard" if it is not "high capacity"{% endtrans %}
          -These groupings are implemented in the router's ProfileOrganizer. - -

          Group size limits

          +

          {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/router/peermanager/ProfileOrganizer.html' -%} +These groupings are implemented in the router's +ProfileOrganizer. +{%- endtrans %}

          +

          {% trans %}Group size limits{% endtrans %}

          +

          {% trans -%} The size of the groups may be limited. +{%- endtrans %}

            -
          • The fast group is limited to 30 peers. - If there would be more, only the ones with the highest speed rating are placed in the group. -
          • The high capacity group is limited to 75 peers (including the fast group) - If there would be more, only the ones with the highest capacity rating are placed in the group. -
          • The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos - stored in the local network database. - On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles - (including those in the fast and high capacity groups) +
          • {% trans -%} +The fast group is limited to 30 peers. +If there would be more, only the ones with the highest speed rating are placed in the group. +{%- endtrans %}
          • +
          • {% trans -%} +The high capacity group is limited to 75 peers (including the fast group) +If there would be more, only the ones with the highest capacity rating are placed in the group. +{%- endtrans %}
          • +
          • {% trans -%} +The standard group has no fixed limit, but is somewhat smaller than the number of RouterInfos +stored in the local network database. +On an active router in today's network, there may be about 1000 RouterInfos and 500 peer profiles +(including those in the fast and high capacity groups) +{%- endtrans %}
          -

          Recalculation and Stability

          +

          {% trans %}Recalculation and Stability{% endtrans %}

          +

          {% trans -%} Summaries are recalculated, and peers are resorted into groups, every 45 seconds. +{%- endtrans %}

          -

          +

          {% trans -%} The groups tend to be fairly stable, that is, there is not much "churn" in the rankings at each recalculation. Peers in the fast and high capacity groups get more tunnels build through them, which increases their speed and capacity ratings, which reinforces their presence in the group. +{%- endtrans %}

          -

          Peer Selection

          - +

          {% trans %}Peer Selection{% endtrans %}

          +

          {% trans -%} The router selects peers from the above groups to build tunnels through. +{%- endtrans %}

          -

          Peer Selection for Client Tunnels

          - +

          {% trans %}Peer Selection for Client Tunnels{% endtrans %}

          +

          {% trans -%} Client tunnels are used for application traffic, such as for HTTP proxies and web servers. -

          +{%- endtrans %}

          + +

          {% trans -%} To reduce the susceptibility to some attacks, and increase performance, peers for building client tunnels are chosen randomly from the smallest group, which is the "fast" group. There is no bias toward selecting peers that were previously participants in a tunnel for the same client. +{%- endtrans %}

          -

          Peer Selection for Exploratory Tunnels

          - +

          {% trans %}Peer Selection for Exploratory Tunnels{% endtrans %}

          +

          {% trans -%} Exploratory tunnels are used for router administrative purposes, such as network database traffic and testing client tunnels. Exploratory tunnels are also used to contact previously unconnected routers, which is why they are called "exploratory". These tunnels are usually low-bandwidth. -

          +{%- endtrans %}

          + +

          {% trans -%} Peers for building exploratory tunnels are generally chosen randomly from the standard group. If the success rate of these build attempts is low compared to the client tunnel build success rate, the router will select a weighted average of peers randomly from the high capacity group instead. This helps maintain a satisfactory build success rate even when network performance is poor. There is no bias toward selecting peers that were previously participants in an exploratory tunnel. -

          +{%- endtrans %}

          + +

          {% trans -%} As the standard group includes a very large subset of all peers the router knows about, exploratory tunnels are essentially built through a random selection of all peers, until the build success rate becomes too low. +{%- endtrans %}

          -

          Restrictions

          +

          {% trans %}Restrictions{% endtrans %}

          +

          {% trans -%} To prevent some simple attacks, and for performance, there are the following restrictions: +{%- endtrans %}

            -
          • +
          • {% trans -%} Two peers from the same /16 IP space may not be in the same tunnel. -
          • +{%- endtrans %}
          • +
          • {% trans -%} A peer may participate in a maximum of 33% of all tunnels created by the router. -
          • +{%- endtrans %}
          • +
          • {% trans -%} Peers with extremely low bandwidth are not used. -
          • +{%- endtrans %}
          • +
          • {% trans -%} Peers for which a recent connection attempt failed are not used. +{%- endtrans %}
          -

          Peer Ordering in Tunnels

          - +

          {% trans %}Peer Ordering in Tunnels{% endtrans %}

          +

          {% trans pdf='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf', +pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf', +tunnelimpl=site_url('docs/tunnels/implementation') -%} Peers are ordered within tunnels to -to deal with the predecessor -attack (2008 -update). -More information is on the tunnel page. +to deal with the predecessor attack +(2008 update). +More information is on the tunnel page. +{%- endtrans %}

          -

          Future Work

          +

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

            -
          • +
          • {% trans -%} Continue to analyze an tune speed and capacity calculations as necessary -
          • +{%- endtrans %}
          • +
          • {% trans -%} Implement a more aggressive ejection strategy if necessary to control memory usage as the network grows -
          • +{%- endtrans %}
          • +
          • {% trans -%} Evaluate group size limits -
          • +{%- endtrans %}
          • +
          • {% trans -%} Use GeoIP data to include or exclude certain peers, if configured +{%- endtrans %}
          -

          Notes

          +

          {% trans %}Notes{% endtrans %}

          +

          {% trans pdf=url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') -%} For those reading the paper -Peer Profiling and Selection in the I2P Anonymous Network, +Peer Profiling and Selection in the I2P Anonymous Network, please keep in mind the following minor changes in I2P since the paper's publication: +{%- endtrans %}

            -
          • The Integration calculation is still not used -
          • In the paper, "groups" are called "tiers" -
          • The "Failing" tier is no longer used -
          • The "Not Failing" tier is now named "Standard" +
          • {% trans %}The Integration calculation is still not used{% endtrans %}
          • +
          • {% trans %}In the paper, "groups" are called "tiers"{% endtrans %}
          • +
          • {% trans %}The "Failing" tier is no longer used{% endtrans %}
          • +
          • {% trans %}The "Not Failing" tier is now named "Standard"{% endtrans %}
          -

          References

          +

          {% trans %}References{% endtrans %}

          {% endblock %} From a37f4f9a6165feae5534b2c13860f5d14db36ec0 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 23:26:00 +0000 Subject: [PATCH 375/498] Added translation tags to docs/how/elgamal-aes --- i2p2www/pages/site/docs/how/elgamal-aes.html | 255 ++++++++++++------- 1 file changed, 166 insertions(+), 89 deletions(-) diff --git a/i2p2www/pages/site/docs/how/elgamal-aes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html index 70fcd456..0d9cbc07 100644 --- a/i2p2www/pages/site/docs/how/elgamal-aes.html +++ b/i2p2www/pages/site/docs/how/elgamal-aes.html @@ -1,18 +1,23 @@ {% extends "global/layout.html" %} -{% block title %}ElGamal/AES + SessionTag Encryption{% endblock %} -{% block lastupdated %}February 2011{% endblock %} +{% block title %}{% trans %}ElGamal/AES + SessionTag Encryption{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}February 2011{% endtrans %}{% endblock %} {% block accuratefor %}0.8.3{% endblock %} {% block content %} -

          Overview

          -

          +

          {% trans %}Overview{% endtrans %}

          +

          {% trans -%} ElGamal/AES+SessionTags is used for end-to-end encryption. -

          -

          As an unreliable, unordered, message based system, I2P uses a simple combination +{%- endtrans %}

          + +

          {% trans -%} +As an unreliable, unordered, message based system, I2P uses a simple combination of asymmetric and symmetric encryption algorithms to provide data confidentiality and integrity to garlic messages. As a whole, the combination is referred to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe - the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces.

          -

          The first time a router wants to encrypt a garlic message to another router, + the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. +{%- endtrans %}

          + +

          {% trans -%} +The first time a router wants to encrypt a garlic message to another router, they encrypt the keying material for an AES256 session key with ElGamal and append the AES256/CBC encrypted payload after that encrypted ElGamal block. In addition to the encrypted payload, the AES encrypted section contains the @@ -24,8 +29,11 @@ ElGamal/AES+SessionTags is used for end-to-end encryption. that session tag, prepended with the session tag itself. When a router receives a garlic encrypted message, they check the first 32 bytes to see if it matches an available session tag - if it does, they simply AES decrypt the message, - but if it does not, they ElGamal decrypt the first block.

          -

          Each session tag can be used only once so as to prevent internal adversaries + but if it does not, they ElGamal decrypt the first block. +{%- endtrans %}

          + +

          {% trans -%} +Each session tag can be used only once so as to prevent internal adversaries from unnecessarily correlating different messages as being between the same routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses when and how many tags to deliver, prestocking the recipient with enough tags @@ -36,8 +44,11 @@ ElGamal/AES+SessionTags is used for end-to-end encryption. cloves exposed and has instructions for the recipient to send the clove back to the original sender (through an inbound tunnel, of course). When the original sender receives this delivery status message, they know that the session tags - bundled in the garlic message were successfully delivered.

          -

          Session tags themselves have a short lifetime, after which they are + bundled in the garlic message were successfully delivered. +{%- endtrans %}

          + +

          {% trans -%} +Session tags themselves have a short lifetime, after which they are discarded if not used. In addition, the quantity stored for each key is limited, as are the number of keys themselves - if too many arrive, either new or old messages may be dropped. The sender keeps track whether messages using session @@ -45,44 +56,54 @@ ElGamal/AES+SessionTags is used for end-to-end encryption. drop the ones previously assumed to be properly delivered, reverting back to the full expensive ElGamal encryption. A session will continue to exist until all its tags are exhausted or expire. -

          +{%- endtrans %}

          + +

          {% trans -%} Sessions are unidirectional. Tags are delivered from Alice to Bob, and Alice then uses the tags, one by one, in subsequent messages to Bob. -

          +{%- endtrans %}

          + +

          {% trans -%} Sessions may be established between Destinations, between Routers, or between a Router and a Destination. Each Router and Destination maintains its own Session Key Manager to keep track of Session Keys and Session Tags. Separate Session Key Managers prevents correlation of multiple Destinations to each other or a Router by adversaries. -

          +{%- endtrans %}

          -

          Message Reception

          -

          +

          {% trans %}Message Reception{% endtrans %}

          +

          {% trans -%} Each message received has one of two the two possible conditions:

          +{%- endtrans %}

          -
            -
          1. It is part of an existing session and contains a Session Tag and an AES encrypted block
          2. -
          3. It is for a new session and contains both ElGamal and AES encrypted blocks
          4. -
          +
            +
          1. {% trans %}It is part of an existing session and contains a Session Tag and an AES encrypted block{% endtrans %}
          2. +
          3. {% trans %}It is for a new session and contains both ElGamal and AES encrypted blocks{% endtrans %}
          4. +
          + +

          {% trans -%} When a router receives a message, it will first assume it is from an existing session and attempt to look up the Session Tag and decrypt the following data using AES. If that fails, it will assume it is for a new session and attempt to decrypt it using ElGamal. -

          +{%- endtrans %}

          -

          New Session Message Specification

          -

          +

          {% trans %}New Session Message Specification{% endtrans %}

          +

          {% trans -%} A New Session ElGamal Message contains two parts, an encrypted ElGamal block and an encrypted AES block. -

          +{%- endtrans %}

          + +

          {% trans -%} The encrypted message contains: -

          +{%- endtrans %}

          +
              +----+----+----+----+----+----+----+----+
              |                                       |
              +                                       +
          @@ -101,14 +122,17 @@ The encrypted message contains:
              |         +
              +----+----+
           
          -
          -

          -

          ElGamal Block

          -

          +

          + +

          {% trans %}ElGamal Block{% endtrans %}

          +

          {% trans -%} The encrypted ElGamal Block is always 514 bytes long. -

          +{%- endtrans %}

          + +

          {% trans -%} The unencrypted ElGamal data is 222 bytes long, containing: -

          +{%- endtrans %}

          +
              +----+----+----+----+----+----+----+----+
              |                                       |
              +                                       +
          @@ -135,21 +159,28 @@ The unencrypted ElGamal data is 222 bytes long, containing:
              +                             +----+----+
              |                             |
              +----+----+----+----+----+----+
          -
          +
          + +

          {% trans commonstructures=site_url('docs/spec/common-structures') -%} The 32-byte -Session Key +Session Key is the identifier for the session. The 32-byte Pre-IV will be used to generate the IV for the AES block that follows; the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV. -

          +{%- endtrans %}

          + +

          {% trans cryptography=site_url('docs/how/cryptography') -%} The 222 byte payload is encrypted -using ElGamal +using ElGamal and the encrypted block is 514 bytes long.

          +{%- endtrans %}

          -

          AES Block

          -

          The unencrypted data in the AES block contains the following: -

          +

          {% trans %}AES Block{% endtrans %}

          +

          {% trans -%} +The unencrypted data in the AES block contains the following: +{%- endtrans %}

          +
              +----+----+----+----+----+----+----+----+
              |tag count|                             |
              +----+----+                             +
          @@ -190,56 +221,73 @@ and the encrypted block is 514 bytes long.
              |          Padding to 16 bytes          |
              +----+----+----+----+----+----+----+----+
           
          -tag count: 2-byte Integer, 0-200
          +tag count: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
          +2-byte Integer, 0-200
          +{%- endtrans %}
           
          -Session Tags: That many 32-byte Session Tags
          +Session Tags: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
          +That many 32-byte Session Tags
          +{%- endtrans %}
           
          -payload size: 4-byte Integer
          +payload size: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
          +4-byte Integer
          +{%- endtrans %}
           
          -Payload Hash: The 32-byte SHA256 Hash of the payload
          +Payload Hash: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
          +The 32-byte SHA256 Hash of the payload
          +{%- endtrans %}
           
          -flag: A one-byte value. Normally == 0. If == 0x01, a Session Key follows
          +flag: {% trans -%}
          +A one-byte value. Normally == 0. If == 0x01, a Session Key follows
          +{%- endtrans %}
           
          -New Session Key: A 32-byte Session Key,
          +New Session Key: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
          +A 32-byte Session Key,
                            to replace the old key, and is only present if preceding flag is 0x01
          +{%- endtrans %}
           
          -Payload: the data
          +Payload: {% trans %}the data{% endtrans %}
           
          -Padding: Random data to a multiple of 16 bytes for the total length.
          +Padding: {% trans -%}
          +Random data to a multiple of 16 bytes for the total length.
                    May contain more than the minimum required padding.
          +{%- endtrans %}
           
          -Minimum length: 48 bytes
          +{% trans %}Minimum length: 48 bytes{% endtrans %}
           
          -
          +
          -

          -The data is then AES Encrypted, +

          {% trans cryptography=site_url('docs/how/cryptography') -%} +The data is then AES Encrypted, using the session key and IV (calculated from the pre-IV) from the ElGamal section. The encrypted AES Block length is variable but is always a multiple of 16 bytes.

          -

          Notes

          +{%- endtrans %}

          + +

          {% trans %}Notes{% endtrans %}

            -
          • - Actual max payload length, and max block length, is less than 64 KB; see the I2NP Overview. -
          • -New Session Key is currently unused and is never present. -
          +
        • {% trans i2np=site_url('docs/protocol/i2np') -%} +Actual max payload length, and max block length, is less than 64 KB; see the I2NP Overview. +{%- endtrans %}
        • +
        • {% trans %}New Session Key is currently unused and is never present.{% endtrans %}
        • +
        -

        Existing Session Message Specification

        - -

        The session tags delivered successfully are remembered for a +

        {% trans %}Existing Session Message Specification{% endtrans %}

        +

        {% trans -%} +The session tags delivered successfully are remembered for a brief period (15 minutes currently) until they are used or discarded. A tag is used by packaging one in an Existing Session Message that -contains only an AES encrypted block, and - is not preceded by an +contains only an AES encrypted block, and is not preceded by an ElGamal block. -

        +{%- endtrans %}

        + +

        {% trans -%} The existing session message is as follows: - -

        +{%- endtrans %}

        +
            +----+----+----+----+----+----+----+----+
            |                                       |
            +                                       +
        @@ -258,72 +306,101 @@ as follows:
            |                                       |
            +----+----+----+----+----+----+----+----+
         
        -Session Tag: A 32-byte Session Tag
        +Session Tag: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
        +A 32-byte Session Tag
                      previously delivered in an AES block
        +{%- endtrans %}
         
        -AES Encrypyted Block: As specified above.
        +AES Encrypyted Block: {% trans %}As specified above.{% endtrans %}
         
        -
        +
        + +

        {% trans -%} The session tag also serves as the pre-IV. The IV is the first 16 bytes of the SHA-256 Hash of the sessionTag. -

        +{%- endtrans %}

        + +

        {% trans -%} To decode a message from an existing session, a router looks up the Session Tag to find an associated Session Key. If the Session Tag is found, the AES block is decrypted using the associated Session Key. If the tag is not found, the message is assumed to be a New Session Message. -

        +{%- endtrans %}

        -

        Future Work

        -

        +

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

        +

        {% trans -%} There are many possible areas to tune the Session Key Manager's algorithms; some may interact with the streaming library behavior, or have significant impact on overall performance. -

        • +{%- endtrans %}

          +
            +
          • {% trans -%} Delivery of too many tags at one time may impose substantial overhead for brief streaming connections or datagrams, and increase the chance of message loss. We currently deliver 40 tags at a time (1280 bytes). 32 (1024 bytes) may be better for tunnel fragmentation. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} A few tags could be delivered in each of several messages, or lots of tags all at once. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} It is also important to study and tune the low-tag thresholds at which more tags are sent. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The number of tags delivered could depend on message size, keeping in mind the eventual padding to 1KB at the tunnel message layer. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Clients could send an estimate of session lifetime to the router, as an advisory on the number of tags required. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Delivery of too few tags causes the router to fall back to an expensive ElGamal encryption. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The router may assume delivery of Session Tags, or await acknowledgement before using them; there are tradeoffs for each strategy. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} For very brief messages, almost the full 222 bytes of the pre-IV and padding fields in the ElGamal block could be used for the entire message, instead of establishing a session. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Evaluate padding strategy; currently we pad to a minimum of 128 bytes. Would be better to add a few tags to small messages than pad. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Perhaps things could be more efficient if the Session Tag system was bidirectional, so tags delivered in the 'forward' path could be used in the 'reverse' path, thus avoiding ElGamal in the initial response. The router currently plays some tricks like this when sending tunnel test messages to itself. -
          • +{%- endtrans %}
          • + +
          • {% trans futureperf=site_url('about/performance/future') -%} Change from Session Tags to -a synchronized PRNG. -
          • +a synchronized PRNG. +{%- endtrans %}
          • + +
          • {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%} Several of these ideas may require a new I2NP message type, or set a flag in the -Delivery Instructions, +Delivery Instructions, or set a magic number in the first few bytes of the Session Key field and accept a small risk of the random Session Key matching the magic number. -
          - -

          +{%- endtrans %}
        • +
        From 6d9a03af992d0883441e8aa3b780c13b0034f615 Mon Sep 17 00:00:00 2001 From: str4d Date: Fri, 1 Feb 2013 23:29:14 +0000 Subject: [PATCH 376/498] Removed some whitespace from tagged paragraphs --- i2p2www/pages/site/docs/how/elgamal-aes.html | 68 ++++++++++---------- 1 file changed, 34 insertions(+), 34 deletions(-) diff --git a/i2p2www/pages/site/docs/how/elgamal-aes.html b/i2p2www/pages/site/docs/how/elgamal-aes.html index 0d9cbc07..ec84bc47 100644 --- a/i2p2www/pages/site/docs/how/elgamal-aes.html +++ b/i2p2www/pages/site/docs/how/elgamal-aes.html @@ -10,52 +10,52 @@ ElGamal/AES+SessionTags is used for end-to-end encryption.

        {% trans -%} As an unreliable, unordered, message based system, I2P uses a simple combination - of asymmetric and symmetric encryption algorithms to provide data confidentiality - and integrity to garlic messages. As a whole, the combination is referred - to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe - the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. +of asymmetric and symmetric encryption algorithms to provide data confidentiality +and integrity to garlic messages. As a whole, the combination is referred +to as ElGamal/AES+SessionTags, but that is an excessively verbose way to describe +the use of 2048bit ElGamal, AES256, SHA256, and 32 byte nonces. {%- endtrans %}

        {% trans -%} The first time a router wants to encrypt a garlic message to another router, - they encrypt the keying material for an AES256 session key with ElGamal and - append the AES256/CBC encrypted payload after that encrypted ElGamal block. - In addition to the encrypted payload, the AES encrypted section contains the - payload length, the SHA256 hash of the unencrypted payload, as well as a number - of "session tags" - random 32 byte nonces. The next time the sender wants - to encrypt a garlic message to another router, rather than ElGamal encrypt - a new session key they simply pick one of the previously delivered session - tags and AES encrypt the payload like before, using the session key used with - that session tag, prepended with the session tag itself. When a router receives - a garlic encrypted message, they check the first 32 bytes to see if it matches - an available session tag - if it does, they simply AES decrypt the message, - but if it does not, they ElGamal decrypt the first block. +they encrypt the keying material for an AES256 session key with ElGamal and +append the AES256/CBC encrypted payload after that encrypted ElGamal block. +In addition to the encrypted payload, the AES encrypted section contains the +payload length, the SHA256 hash of the unencrypted payload, as well as a number +of "session tags" - random 32 byte nonces. The next time the sender wants +to encrypt a garlic message to another router, rather than ElGamal encrypt +a new session key they simply pick one of the previously delivered session +tags and AES encrypt the payload like before, using the session key used with +that session tag, prepended with the session tag itself. When a router receives +a garlic encrypted message, they check the first 32 bytes to see if it matches +an available session tag - if it does, they simply AES decrypt the message, +but if it does not, they ElGamal decrypt the first block. {%- endtrans %}

        {% trans -%} Each session tag can be used only once so as to prevent internal adversaries - from unnecessarily correlating different messages as being between the same - routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses - when and how many tags to deliver, prestocking the recipient with enough tags - to cover a volley of messages. Garlic messages may detect the successful tag - delivery by bundling a small additional message as a clove (a "delivery status - message") - when the garlic message arrives at the intended recipient and - is decrypted successfully, this small delivery status message is one of the - cloves exposed and has instructions for the recipient to send the clove back - to the original sender (through an inbound tunnel, of course). When the original - sender receives this delivery status message, they know that the session tags - bundled in the garlic message were successfully delivered. +from unnecessarily correlating different messages as being between the same +routers. The sender of an ElGamal/AES+SessionTag encrypted message chooses +when and how many tags to deliver, prestocking the recipient with enough tags +to cover a volley of messages. Garlic messages may detect the successful tag +delivery by bundling a small additional message as a clove (a "delivery status +message") - when the garlic message arrives at the intended recipient and +is decrypted successfully, this small delivery status message is one of the +cloves exposed and has instructions for the recipient to send the clove back +to the original sender (through an inbound tunnel, of course). When the original +sender receives this delivery status message, they know that the session tags +bundled in the garlic message were successfully delivered. {%- endtrans %}

        {% trans -%} Session tags themselves have a short lifetime, after which they are - discarded if not used. In addition, the quantity stored for each key is limited, - as are the number of keys themselves - if too many arrive, either new or old - messages may be dropped. The sender keeps track whether messages using session - tags are getting through, and if there isn't sufficient communication it may - drop the ones previously assumed to be properly delivered, reverting back - to the full expensive ElGamal encryption. - A session will continue to exist until all its tags are exhausted or expire. +discarded if not used. In addition, the quantity stored for each key is limited, +as are the number of keys themselves - if too many arrive, either new or old +messages may be dropped. The sender keeps track whether messages using session +tags are getting through, and if there isn't sufficient communication it may +drop the ones previously assumed to be properly delivered, reverting back +to the full expensive ElGamal encryption. +A session will continue to exist until all its tags are exhausted or expire. {%- endtrans %}

        {% trans -%} From 0156918e7aef4c4bbd0c3fd0d6b85e16b8467b00 Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 2 Feb 2013 01:15:22 +0000 Subject: [PATCH 377/498] Added translation tags to docs/how/tunnel-routing --- .../pages/site/docs/how/tunnel-routing.html | 332 ++++++++++-------- 1 file changed, 189 insertions(+), 143 deletions(-) diff --git a/i2p2www/pages/site/docs/how/tunnel-routing.html b/i2p2www/pages/site/docs/how/tunnel-routing.html index a0820a46..31c0fd3b 100644 --- a/i2p2www/pages/site/docs/how/tunnel-routing.html +++ b/i2p2www/pages/site/docs/how/tunnel-routing.html @@ -1,14 +1,16 @@ {% extends "global/layout.html" %} -{% block title %}Tunnel Overview{% endblock %} -{% block lastupdated %}July 2011{% endblock %} +{% block title %}{% trans %}Tunnel Overview{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}July 2011{% endtrans %}{% endblock %} {% block accuratefor %}0.8.7{% endblock %} {% block content %} -

        Tunnel Overview

        -

        +

        {% trans %}Tunnel Overview{% endtrans %}

        +

        {% trans -%} This page contains an overview of I2P tunnel terminology and operation, with links to more technical pages, details, and specifications. -

        -

        As briefly explained in the introduction, I2P builds virtual "tunnels" - +{%- endtrans %}

        + +

        {% trans intro=site_url('docs/how/intro') -%} +As briefly explained in the introduction, I2P builds virtual "tunnels" - temporary and unidirectional paths through a sequence of routers. These tunnels are classified as either inbound tunnels (where everything given to it goes towards the creator of the tunnel) or outbound tunnels @@ -16,119 +18,142 @@ given to it goes towards the creator of the tunnel) or outbound tunnels wants to send a message to Bob, she will (typically) send it out one of her existing outbound tunnels with instructions for that tunnel's endpoint to forward it to the gateway router for one of Bob's current inbound -tunnels, which in turn passes it to Bob.

        +tunnels, which in turn passes it to Bob. +{%- endtrans %}

        +

        -Tunnel +{{ _('Alice connecting through her outbound tunnel to Bob via his inbound tunnel') }}

        -A: Outbound Gateway (Alice)
        -B: Outbound Participant
        -C: Outbound Endpoint
        -D: Inbound Gateway
        -E: Inbound Participant
        -F: Inbound Endpoint (Bob)
        +A: {% trans %}Outbound Gateway{% endtrans %} (Alice)
        +B: {% trans %}Outbound Participant{% endtrans %}
        +C: {% trans %}Outbound Endpoint{% endtrans %}
        +D: {% trans %}Inbound Gateway{% endtrans %}
        +E: {% trans %}Inbound Participant{% endtrans %}
        +F: {% trans %}Inbound Endpoint{% endtrans %} (Bob)
         

        -

        Tunnel vocabulary

        +

        {% trans %}Tunnel vocabulary{% endtrans %}

          -
        • Tunnel gateway - the first router in a tunnel. For inbound tunnels, - this is the one mentioned in the LeaseSet published in the - network database. For outbound tunnels, the - gateway is the originating router. (e.g. both A and D above)
        • -
        • Tunnel endpoint - the last router in a tunnel. (e.g. both C and F above)
        • -
        • Tunnel participant - all routers in a tunnel except for the gateway or - endpoint (e.g. both B and E above)
        • -
        • n-Hop tunnel - a tunnel with a specific number of inter-router jumps, e.g.: -
            -
          • 0-hop tunnel - a tunnel where the gateway is also the endpoint
          • -
          • 1-hop tunnel - a tunnel where the gateway talks directly to the - endpoint
          • -
          • 2-(or more)-hop tunnel - a tunnel where there is at least one intermediate - tunnel participant. (the above diagram includes two 2-hop tunnels - one - outbound from Alice, one inbound to Bob)
          • -
          -
        • -
        • Tunnel ID - A 4 byte integer - different for each hop in a tunnel, and unique among all tunnels on a router. - Chosen randomly by the tunnel creator.
        • +
        • {% trans netdb=site_url('docs/how/network-database') -%} +Tunnel gateway - the first router in a tunnel. For inbound tunnels, +this is the one mentioned in the LeaseSet published in the +network database. For outbound tunnels, the +gateway is the originating router. (e.g. both A and D above) +{%- endtrans %}
        • +
        • {% trans %}Tunnel endpoint - the last router in a tunnel. (e.g. both C and F above){% endtrans %}
        • +
        • {% trans -%} +Tunnel participant - all routers in a tunnel except for the gateway or +endpoint (e.g. both B and E above) +{%- endtrans %}
        • +
        • {% trans %}n-Hop tunnel - a tunnel with a specific number of inter-router jumps, e.g.:{% endtrans %} +
            +
          • {% trans %}0-hop tunnel - a tunnel where the gateway is also the endpoint{% endtrans %}
          • +
          • {% trans %}1-hop tunnel - a tunnel where the gateway talks directly to the endpoint{% endtrans %}
          • +
          • {% trans -%} +2-(or more)-hop tunnel - a tunnel where there is at least one intermediate +tunnel participant. (the above diagram includes two 2-hop tunnels - one +outbound from Alice, one inbound to Bob) +{%- endtrans %}
          • +
          +
        • +
        • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +Tunnel ID - A 4 byte integer +different for each hop in a tunnel, and unique among all tunnels on a router. +Chosen randomly by the tunnel creator. +{%- endtrans %}
        -

        Tunnel Build Information

        -

        Routers performing the three roles (gateway, participant, endpoint) are given +

        {% trans %}Tunnel Build Information{% endtrans %}

        +

        {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%} +Routers performing the three roles (gateway, participant, endpoint) are given different pieces of data in the initial -Tunnel Build Message -to accomplish their tasks:

        - +Tunnel Build Message +to accomplish their tasks: +{%- endtrans %}

          -
        • The tunnel gateway gets: -
            -
          • tunnel encryption key - an AES private key for encrypting - messages and instructions to the next hop
          • -
          • tunnel IV key - an AES private key for double-encrypting - the IV to the next hop
          • -
          • reply key - an AES public key for encrypting - the reply to the tunnel build request
          • -
          • reply IV - the IV for encrypting - the reply to the tunnel build request
          • -
          • tunnel id - 4 byte integer (inbound gateways only) -
          • -
          • next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint)
          • -
          • next tunnel id - The tunnel ID on the next hop
          • -
          -
        • -
        • All intermediate tunnel participants get: -
            -
          • tunnel encryption key - an AES private key for encrypting - messages and instructions to the next hop
          • -
          • tunnel IV key - an AES private key for double-encrypting - the IV to the next hop
          • -
          • reply key - an AES public key for encrypting - the reply to the tunnel build request
          • -
          • reply IV - the IV for encrypting - the reply to the tunnel build request
          • -
          • tunnel id - 4 byte integer -
          • -
          • next hop - what router is the next one in the path
          • -
          • next tunnel id - The tunnel ID on the next hop
          • -
          -
        • -
        • The tunnel endpoint gets: -
            -
          • tunnel encryption key - an AES private key for encrypting - messages and instructions to the the endpoint (itself)
          • -
          • tunnel IV key - an AES private key for double-encrypting - the IV to the endpoint (itself)
          • -
          • reply key - an AES public key for encrypting - the reply to the tunnel build request (outbound endpoints only)
          • -
          • reply IV - the IV for encrypting - the reply to the tunnel build request (outbound endpoints only)
          • -
          • tunnel id - 4 byte integer (outbound endpoints only) -
          • -
          • reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only)
          • -
          • reply tunnel id - The tunnel ID of the reply router (outbound endpoints only)
          • -
          -
        • +
        • {% trans %}The tunnel gateway gets:{% endtrans %} +
            +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel encryption key - an AES private key for encrypting +messages and instructions to the next hop +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel IV key - an AES private key for double-encrypting +the IV to the next hop +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +reply key - an AES public key for encrypting +the reply to the tunnel build request +{%- endtrans %}
          • +
          • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request{% endtrans %}
          • +
          • {% trans %}tunnel id - 4 byte integer (inbound gateways only){% endtrans %}
          • +
          • {% trans %}next hop - what router is the next one in the path (unless this is a 0-hop tunnel, and the gateway is also the endpoint){% endtrans %}
          • +
          • {% trans %}next tunnel id - The tunnel ID on the next hop{% endtrans %}
          • +
          +
        • +
        • {% trans %}All intermediate tunnel participants get:{% endtrans %} +
            +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel encryption key - an AES private key for encrypting +messages and instructions to the next hop +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel IV key - an AES private key for double-encrypting +the IV to the next hop +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +reply key - an AES public key for encrypting +the reply to the tunnel build request +{%- endtrans %}
          • +
          • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request{% endtrans %}
          • +
          • {% trans %}tunnel id - 4 byte integer{% endtrans %}
          • +
          • {% trans %}next hop - what router is the next one in the path{% endtrans %}
          • +
          • {% trans %}next tunnel id - The tunnel ID on the next hop{% endtrans %}
          • +
          +
        • +
        • {% trans %}The tunnel endpoint gets:{% endtrans %} +
            +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel encryption key - an AES private key for encrypting +messages and instructions to the the endpoint (itself) +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +tunnel IV key - an AES private key for double-encrypting +the IV to the endpoint (itself) +{%- endtrans %}
          • +
          • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +reply key - an AES public key for encrypting +the reply to the tunnel build request (outbound endpoints only) +{%- endtrans %}
          • +
          • {% trans %}reply IV - the IV for encrypting the reply to the tunnel build request (outbound endpoints only){% endtrans %}
          • +
          • {% trans %}tunnel id - 4 byte integer (outbound endpoints only){% endtrans %}
          • +
          • {% trans %}reply router - the inbound gateway of the tunnel to send the reply through (outbound endpoints only){% endtrans %}
          • +
          • {% trans %}reply tunnel id - The tunnel ID of the reply router (outbound endpoints only){% endtrans %}
          • +
          +
        -

        +

        {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%} Details are in the -tunnel creation specification. -

        +tunnel creation specification. +{%- endtrans %}

        -

        Tunnel pooling

        -

        +

        {% trans %}Tunnel pooling{% endtrans %}

        +

        {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%} Several tunnels for a particular purpose may be grouped into a "tunnel pool", as described in the -tunnel specification. +tunnel specification. This provides redundancy and additional bandwidth. The pools used by the router itself are called "exploratory tunnels". The pools used by applications are called "client tunnels". -

        +{%- endtrans %}

        -

        Tunnel length

        -

        As mentioned above, each client requests that their router provide tunnels to +

        {% trans %}Tunnel length{% endtrans %}

        +

        {% trans i2cp=site_url('docs/protocol/i2cp') -%} +As mentioned above, each client requests that their router provide tunnels to include at least a certain number of hops. The decision as to how many routers to have in one's outbound and inbound tunnels has an important effect upon the @@ -138,116 +163,137 @@ likely that one of those routers will fail prematurely. The less routers in a tunnel, the easier it is for an adversary to mount traffic analysis attacks and pierce someone's anonymity. Tunnel lengths are specified by clients via -I2CP options. +I2CP options. The maximum number of hops in a tunnel is 7. -

        +{%- endtrans %}

        -

        0-hop tunnels

        -

        With no remote routers in a tunnel, the user has very basic plausible +

        {% trans %}0-hop tunnels{% endtrans %}

        +

        {% trans -%} +With no remote routers in a tunnel, the user has very basic plausible deniability (since no one knows for sure that the peer that sent them the message wasn't simply just forwarding it on as part of the tunnel). However, it would be fairly easy to mount a statistical analysis attack and notice that messages targeting a specific destination are always sent through a single gateway. Statistical analysis against outbound 0-hop tunnels are more complex, -but could show similar information (though would be slightly harder to mount)

        +but could show similar information (though would be slightly harder to mount). +{%- endtrans %}

        -

        1-hop tunnels

        -

        With only one remote router in a tunnel, the user has both plausible +

        {% trans %}1-hop tunnels{% endtrans %}

        +

        {% trans threatmodel=site_url('docs/how/threat-model') -%} +With only one remote router in a tunnel, the user has both plausible deniability and basic anonymity, as long as they are not up against an internal -adversary (as described on threat model). However, +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.

        +to mount the above statistical traffic analysis attack. +{%- endtrans %}

        -

        2-hop tunnels

        -

        With two or more remote routers in a tunnel, the costs of mounting the traffic +

        {% trans %}2-hop tunnels{% endtrans %}

        +

        {% trans -%} +With two or more remote routers in a tunnel, the costs of mounting the traffic analysis attack increases, since many remote routers would have to be compromised -to mount it.

        +to mount it. +{%- endtrans %}

        -

        3-hop (or more) tunnels

        -To reduce the susceptibility to some attacks, +

        {% trans %}3-hop (or more) tunnels{% endtrans %}

        +

        {% trans url='http://blog.torproject.org/blog/one-cell-enough' -%} +To reduce the susceptibility to some attacks, 3 or more hops are recommended for the highest level of protection. -recent studies +Recent studies also conclude that more than 3 hops does not provide additional protection. +{%- endtrans %}

        -

        Tunnel default lengths

        -

        The router uses 2-hop tunnels by default for its exploratory tunnels. +

        {% trans %}Tunnel default lengths{% endtrans %}

        +

        {% trans i2cp=site_url('docs/protocol/i2cp') -%} +The router uses 2-hop tunnels by default for its exploratory tunnels. Client tunnel defaults are set by the application, using -I2CP options. +I2CP options. Most applications use 2 or 3 hops as their default. -

        +{%- endtrans %}

        -

        Tunnel testing

        -

        All tunnels are periodically tested by their creator by sending a +

        {% trans %}Tunnel testing{% endtrans %}

        +

        {% trans peerselection=site_url('docs/how/peer-selection') -%} +All tunnels are periodically tested by their creator by sending a DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunnel (testing both tunnels at once). If either fails a number of consecutive tests, it is marked as no longer functional. If it was used for a client's inbound tunnel, a new leaseSet is created. Tunnel test failures are also reflected in the -capacity rating in the peer profile. -

        +capacity rating in the peer profile. +{%- endtrans %}

        -

        Tunnel creation

        -

        Tunnel creation is handled by garlic routing +

        {% trans %}Tunnel creation{% endtrans %}

        +

        {% trans garlicrouting=site_url('docs/how/garlic-routing'), +tunnelcreation=site_url('docs/spec/tunnel-creation') -%} +Tunnel creation is handled by garlic routing a Tunnel Build Message to a router, requesting that they participate in the tunnel (providing them with all of the appropriate information, as above, along with a certificate, which right now is a 'null' cert, but will support hashcash or other non-free certificates when necessary). That router forwards the message to the next hop in the tunnel. Details are in the -tunnel creation specification. -

        +tunnel creation specification. +{%- endtrans %}

        Tunnel encryption

        -

        Multi-layer encryption is handled by garlic encryption +

        {% trans garlicrouting=site_url('docs/how/garlic-routing'), +tunnelimpl=site_url('docs/tunnels/implementation') -%} +Multi-layer encryption is handled by garlic encryption of tunnel messages. Details are in the -tunnel specification. +tunnel specification. The IV of each hop is encrypted with a separate key as explained there. -

        +{%- endtrans %}

        -

        Future Work

        -
        • +

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

          +
            +
          • {% trans -%} Other tunnel test techniques could be used, such as garlic wrapping a number of tests into cloves, testing individual tunnel -participants separately, -etc. -
          • +participants separately, etc. +{%- endtrans %}
          • + +
          • {% trans -%} Move to 3-hop exploratory tunnels defaults. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} In a distant future release, options specifying the pooling, mixing, and chaff generation settings may be implemented. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} In a distant future release, limits on the quantity and size of messages allowed during the tunnel's lifetime may be implemented (e.g. no more than 300 messages or 1MB per minute). -
          +{%- endtrans %}
        • +
        -

        See Also

        +

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

        {% endblock %} From db4a3c796847500b26f58086c36cd29942fa81fc Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 2 Feb 2013 23:17:39 +0000 Subject: [PATCH 378/498] Added translation tags to docs/how/network-database --- .../pages/site/docs/how/network-database.html | 1295 +++++++++-------- 1 file changed, 667 insertions(+), 628 deletions(-) diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index 8c003bf0..4c677a7b 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -1,761 +1,800 @@ {% extends "global/layout.html" %} -{% block title %}The Network Database{% endblock %} -{% block lastupdated %}June 2012{% endblock %} +{% block title %}{% trans %}The Network Database{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}June 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9{% endblock %} {% block content %} -

        Overview

        +

        {% trans %}Overview{% endtrans %}

        -

        - I2P's netDb is a specialized distributed database, containing - just two types of data - router contact information (RouterInfos) and destination contact - information (LeaseSets). Each piece of data is signed by the appropriate party and verified - by anyone who uses or stores it. In addition, the data has liveliness information - within it, allowing irrelevant entries to be dropped, newer entries to replace - older ones, and protection against certain classes of attack. -

        +

        {% trans -%} +I2P's netDb is a specialized distributed database, containing +just two types of data - router contact information (RouterInfos) and destination contact +information (LeaseSets). Each piece of data is signed by the appropriate party and verified +by anyone who uses or stores it. In addition, the data has liveliness information +within it, allowing irrelevant entries to be dropped, newer entries to replace +older ones, and protection against certain classes of attack. +{%- endtrans %}

        -

        - The netDb is distributed with a simple technique called "floodfill", - where a subset of all routers, called "floodfill routers", maintains the distributed database. -

        +

        {% trans -%} +The netDb is distributed with a simple technique called "floodfill", +where a subset of all routers, called "floodfill routers", maintains the distributed database. +{%- endtrans %}

        RouterInfo

        -

        - When an I2P router wants to contact another router, they need to know some - key pieces of data - all of which are bundled up and signed by the router into - a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity - as the key. The structure itself contains: -

        +

        {% trans -%} +When an I2P router wants to contact another router, they need to know some +key pieces of data - all of which are bundled up and signed by the router into +a structure called the "RouterInfo", which is distributed with the SHA256 of the router's identity +as the key. The structure itself contains: +{%- endtrans %}

          -
        • The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate)
        • -
        • The contact addresses at which it can be reached (e.g. TCP: example.org port 4108)
        • -
        • When this was published
        • -
        • A set of arbitrary text options
        • -
        • The signature of the above, generated by the identity's DSA signing key
        • +
        • {% trans %}The router's identity (a 2048bit ElGamal encryption key, a 1024bit DSA signing key, and a certificate){% endtrans %}
        • +
        • {% trans %}The contact addresses at which it can be reached (e.g. TCP: example.org port 4108){% endtrans %}
        • +
        • {% trans %}When this was published{% endtrans %}
        • +
        • {% trans %}A set of arbitrary text options{% endtrans %}
        • +
        • {% trans %}The signature of the above, generated by the identity's DSA signing key{% endtrans %}
        -

        - The following text options, while not strictly required, are expected - to be present: -

        +

        {% trans -%} +The following text options, while not strictly required, are expected +to be present: +{%- endtrans %}

        • caps - (Capabilities flags - used to indicate floodfill participation, approximate bandwidth, and perceived reachability) +({% trans %}Capabilities flags - used to indicate floodfill participation, approximate bandwidth, and perceived reachability{% endtrans %}) +
        • coreVersion - (The core library version, always the same as the router version) +({% trans %}The core library version, always the same as the router version{% endtrans %}) +
        • netId = 2 - (Basic network compatibility - A router will refuse to communicate with a peer having a different netId) +({% trans %}Basic network compatibility - A router will refuse to communicate with a peer having a different netId{% endtrans %}) +
        • router.version - (Used to determine compatibility with newer features and messages) +({% trans %}Used to determine compatibility with newer features and messages{% endtrans %}) +
        • stat_uptime = 90m - (Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime, - and only sent tunnel requests to peers whose was more than 60m) +({% trans %}Always sent as 90m, for compatibility with an older scheme where routers published their actual uptime, +and only sent tunnel requests to peers whose was more than 60m{% endtrans %}) +
        -

        - These values are used by other routers for basic decisions. - Should we connect to this router? Should we attempt to route a tunnel through this router? - The bandwidth capability flag, in particular, is used only to determine whether - the router meets a minimum threshold for routing tunnels. - Above the minimum threshold, the advertised bandwidth is not used or trusted anywhere - in the router, except for display in the user interface and for debugging and network analysis. -

        +

        {% trans -%} +These values are used by other routers for basic decisions. +Should we connect to this router? Should we attempt to route a tunnel through this router? +The bandwidth capability flag, in particular, is used only to determine whether +the router meets a minimum threshold for routing tunnels. +Above the minimum threshold, the advertised bandwidth is not used or trusted anywhere +in the router, except for display in the user interface and for debugging and network analysis. +{%- endtrans %}

        -

        - Additional text options include - a small number of statistics about the router's health, which are aggregated by - sites such as stats.i2p - for network performance analysis and debugging. - These statistics were chosen to provide data crucial to the developers, - such as tunnel build success rates, while balancing the need for such data - with the side-effects that could result from revealing this data. - Current statistics are limited to: -

        +

        {% trans stats=i2pconv('stats.i2p') -%} +Additional text options include +a small number of statistics about the router's health, which are aggregated by +sites such as {{ stats }} +for network performance analysis and debugging. +These statistics were chosen to provide data crucial to the developers, +such as tunnel build success rates, while balancing the need for such data +with the side-effects that could result from revealing this data. +Current statistics are limited to: +{%- endtrans %}

          -
        • Client and exploratory tunnel build success, reject, and timeout rates -
        • 1 hour average number of participating tunnels +
        • {% trans %}Client and exploratory tunnel build success, reject, and timeout rates{% endtrans %} +
        • {% trans %}1 hour average number of participating tunnels{% endtrans %}
        -

        - The data - published can be seen in the router's user interface, - but is not used or trusted within the router. - As the network has matured, we have gradually removed most of the published - statistics to improve anonymity, and we plan to remove more in future releases. -

        +

        {% trans -%} +The data published can be seen in the router's user interface, +but is not used or trusted within the router. +As the network has matured, we have gradually removed most of the published +statistics to improve anonymity, and we plan to remove more in future releases. +{%- endtrans %}

        - RouterInfo specification + {% trans %}RouterInfo specification{% endtrans %}

        - RouterInfo Javadoc + {% trans %}RouterInfo Javadoc{% endtrans %}

        -

        RouterInfo Expiration

        -

        - RouterInfos have no set expiration time. - Each router is free to maintain its own local policy to trade off the frequency of RouterInfo lookups - with memory or disk usage. - In the current implementation, there are the following general policies: -

        +

        {% trans %}RouterInfo Expiration{% endtrans %}

        +

        {% trans -%} +RouterInfos have no set expiration time. +Each router is free to maintain its own local policy to trade off the frequency of RouterInfo lookups +with memory or disk usage. +In the current implementation, there are the following general policies: +{%- endtrans %}

          -
        • There is no expiration during the first hour of uptime, as the persistent stored data may be old.
        • -
        • There is no expiration if there are 25 or less RouterInfos.
        • -
        • As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain - a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours, - while expiration time with 300 routers is around 30 hours.
        • -
        • RouterInfos containing SSU introducers expire in about an hour, as - the introducer list expires in about that time.
        • -
        • Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will - be frequently republished to them.
        • +
        • {% trans -%} +There is no expiration during the first hour of uptime, as the persistent stored data may be old. +{%- endtrans %}
        • +
        • {% trans -%} +There is no expiration if there are 25 or less RouterInfos. +{%- endtrans %}
        • +
        • {% trans -%} +As the number of local RouterInfos grows, the expiration time shrinks, in an attempt to maintain +a reasonable number RouterInfos. The expiration time with less than 120 routers is 72 hours, +while expiration time with 300 routers is around 30 hours. +{%- endtrans %}
        • +
        • {% trans ssu=site_url('docs/transport/ssu') -%} +RouterInfos containing SSU introducers expire in about an hour, as +the introducer list expires in about that time. +{%- endtrans %}
        • +
        • {% trans -%} +Floodfills use a short expiration time (1 hour) for all local RouterInfos, as valid RouterInfos will +be frequently republished to them. +{%- endtrans %}
        -

        RouterInfo Persistent Storage

        +

        {% trans %}RouterInfo Persistent Storage{% endtrans %}

        -

        - RouterInfos are periodically written to disk so that they are available after a restart. -

        +

        {% trans -%} +RouterInfos are periodically written to disk so that they are available after a restart. +{%- endtrans %}

        LeaseSet

        -

        - The second piece of data distributed in the netDb is a "LeaseSet" - documenting - a group of tunnel entry points (leases) for a particular client destination. - Each of these leases specify the following information: +

        {% trans -%} +The second piece of data distributed in the netDb is a "LeaseSet" - documenting +a group of tunnel entry points (leases) for a particular client destination. +Each of these leases specify the following information: +{%- endtrans %}

          -
        • The tunnel gateway router (by specifying its identity)
        • -
        • The tunnel ID on that router to send messages with (a 4 byte number)
        • -
        • When that tunnel will expire.
        • +
        • {% trans %}The tunnel gateway router (by specifying its identity){% endtrans %}
        • +
        • {% trans %}The tunnel ID on that router to send messages with (a 4 byte number){% endtrans %}
        • +
        • {% trans %}When that tunnel will expire.{% endtrans %}
        - The LeaseSet itself is stored in the netDb under - the key derived from the SHA256 of the destination. -

        +

        {% trans -%} +The LeaseSet itself is stored in the netDb under +the key derived from the SHA256 of the destination. +{%- endtrans %}

        -

        - In addition to these leases, the LeaseSet includes: +

        {% trans -%} +In addition to these leases, the LeaseSet includes: +{%- endtrans %}

          -
        • The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate)
        • -
        • Additional encryption public key: used for end-to-end encryption of garlic messages
        • -
        • Additional signing public key: intended for LeaseSet revocation, but is currently unused.
        • -
        • Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.
        • +
        • {% trans %}The destination itself (a 2048bit ElGamal encryption key, 1024bit DSA signing key and a certificate){% endtrans %}
        • +
        • {% trans %}Additional encryption public key: used for end-to-end encryption of garlic messages{% endtrans %}
        • +
        • {% trans %}Additional signing public key: intended for LeaseSet revocation, but is currently unused.{% endtrans %}
        • +
        • {% trans %}Signature of all the LeaseSet data, to make sure the Destination published the LeaseSet.{% endtrans %}
        -

        - Lease specification + {% trans %}Lease specification{% endtrans %}
        - LeaseSet specification + {% trans %}LeaseSet specification{% endtrans %}

        - Lease Javadoc + {% trans %}Lease Javadoc{% endtrans %}
        - LeaseSet Javadoc + {% trans %}LeaseSet Javadoc{% endtrans %}

        -

        Unpublished LeaseSets

        -

        - A LeaseSet for a destination used only for outgoing connections is unpublished. - It is never sent for publication to a floodfill router. - "Client" tunnels, such as those for web browsing and IRC clients, are unpublished. - Servers will still be able to send messages back to those unpublished destinations, - because of I2NP storage messages. -

        +

        {% trans %}Unpublished LeaseSets{% endtrans %}

        +

        {% trans -%} +A LeaseSet for a destination used only for outgoing connections is unpublished. +It is never sent for publication to a floodfill router. +"Client" tunnels, such as those for web browsing and IRC clients, are unpublished. +Servers will still be able to send messages back to those unpublished destinations, +because of I2NP storage messages. +{%- endtrans %}

        -

        Revoked LeaseSets

        -

        - A LeaseSet may be revoked by publishing a new LeaseSet with zero leases. - Revocations must be signed by the additional signing key in the LeaseSet. - Revocations are not fully implemented, and it is unclear if they have any practical use. - This is the only planned use for that signing key, so it is currently unused. -

        +

        {% trans %}Revoked LeaseSets{% endtrans %}

        +

        {% trans -%} +A LeaseSet may be revoked by publishing a new LeaseSet with zero leases. +Revocations must be signed by the additional signing key in the LeaseSet. +Revocations are not fully implemented, and it is unclear if they have any practical use. +This is the only planned use for that signing key, so it is currently unused. +{%- endtrans %}

        -

        Encrypted LeaseSets

        -

        - In an encrypted LeaseSet, all Leases are encrypted with a separate DSA key. - The leases may only be decoded, and thus the destination may only be contacted, - by those with the key. - There is no flag or other direct indication that the LeaseSet is encrypted. - Encrypted LeaseSets are not widely used, and it is a topic for future work to - research whether the user interface and implementation of encrypted LeaseSets could be improved. -

        +

        {% trans %}Encrypted LeaseSets{% endtrans %}

        +

        {% trans -%} +In an encrypted LeaseSet, all Leases are encrypted with a separate DSA key. +The leases may only be decoded, and thus the destination may only be contacted, +by those with the key. +There is no flag or other direct indication that the LeaseSet is encrypted. +Encrypted LeaseSets are not widely used, and it is a topic for future work to +research whether the user interface and implementation of encrypted LeaseSets could be improved. +{%- endtrans %}

        -

        LeaseSet Expiration

        -

        - All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet expires - 10 minutes after the earliest creation time of all its Leases. -

        +

        {% trans %}LeaseSet Expiration{% endtrans %}

        +

        {% trans -%} +All Leases (tunnels) are valid for 10 minutes; therefore, a LeaseSet expires +10 minutes after the earliest creation time of all its Leases. +{%- endtrans %}

        -

        LeaseSet Persistent Storage

        -

        - There is no persistent storage of LeaseSet data since they expire so quickly. -

        +

        {% trans %}LeaseSet Persistent Storage{% endtrans %}

        +

        {% trans -%} +There is no persistent storage of LeaseSet data since they expire so quickly. +{%- endtrans %}

        -

        Bootstrapping

        -

        - The netDb is decentralized, however you do need at - least one reference to a peer so that the integration process - ties you in. This is accomplished by "reseeding" your router with the RouterInfo - of an active peer - specifically, by retrieving their routerInfo-$hash.dat - file and storing it in your netDb/ directory. Anyone can provide - you with those files - you can even provide them to others by exposing your own - netDb directory. To simplify the process, - volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network, - and the URLs of these directories are hardcoded in I2P. - When the router starts up for the first time, it automatically fetches from - one of these URLs, selected at random. -

        +

        {% trans %}Bootstrapping{% endtrans %}

        +

        {% trans -%} +The netDb is decentralized, however you do need at +least one reference to a peer so that the integration process +ties you in. This is accomplished by "reseeding" your router with the RouterInfo +of an active peer - specifically, by retrieving their routerInfo-$hash.dat +file and storing it in your netDb/ directory. Anyone can provide +you with those files - you can even provide them to others by exposing your own +netDb directory. To simplify the process, +volunteers publish their netDb directories (or a subset) on the regular (non-i2p) network, +and the URLs of these directories are hardcoded in I2P. +When the router starts up for the first time, it automatically fetches from +one of these URLs, selected at random. +{%- endtrans %}

        -

        Floodfill

        -

        - The floodfill netDb is a simple distributed storage mechanism. - The storage algorithm is simple: send the data to the closest peer that has advertised itself - as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them - for the entry to be sent, verifying its proper insertion / distribution. If the - verification peer doesn't reply, or they don't have the entry, the sender - repeats the process. When the peer in the floodfill netDb receives a netDb - store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers. - The peers selected are the ones closest (according to the XOR-metric) to a specific key. -

        -

        - Determining who is part of the floodfill netDb is trivial - it is exposed in each - router's published routerInfo as a capability. -

        -

        - Floodfills have no central authority and do not form a "consensus" - - they only implement a simple DHT overlay. -

        +

        {% trans %}Floodfill{% endtrans %}

        +

        {% trans -%} +The floodfill netDb is a simple distributed storage mechanism. +The storage algorithm is simple: send the data to the closest peer that has advertised itself +as a floodfill router. Then wait 10 seconds, pick another floodfill router and ask them +for the entry to be sent, verifying its proper insertion / distribution. If the +verification peer doesn't reply, or they don't have the entry, the sender +repeats the process. When the peer in the floodfill netDb receives a netDb +store from a peer not in the floodfill netDb, they send it to a subset of the floodfill netDb-peers. +The peers selected are the ones closest (according to the XOR-metric) to a specific key. +{%- endtrans %}

        + +

        {% trans -%} +Determining who is part of the floodfill netDb is trivial - it is exposed in each +router's published routerInfo as a capability. +{%- endtrans %}

        + +

        {% trans -%} +Floodfills have no central authority and do not form a "consensus" - +they only implement a simple DHT overlay. +{%- endtrans %}

        -

        Floodfill Router Opt-in

        +

        {% trans %}Floodfill Router Opt-in{% endtrans %}

        -

        - Unlike Tor, where the directory servers are hardcoded and trusted, - and operated by known entities, - the members of the I2P floodfill peer set need not be trusted, and - change over time. -

        -

        - To increase reliability of the netDb, and minimize the impact - of netDb traffic on a router, floodfill is automatically enabled - only on routers that are configured with high bandwidth limits. - Routers with high bandwidth limits (which must be manually configured, - as the default is much lower) are presumed to be on lower-latency - connections, and are more likely to be available 24/7. - The current minimum share bandwidth for a floodfill router is 128 KBytes/sec. -

        -

        - In addition, a router must pass several additional tests for health - (outbound message queue time, job lag, etc.) before floodfill operation is - automatically enabled. -

        -

        - With the current rules for automatic opt-in, approximately 6% of - the routers in the network are floodfill routers. -

        +

        {% trans -%} +Unlike Tor, where the directory servers are hardcoded and trusted, +and operated by known entities, +the members of the I2P floodfill peer set need not be trusted, and +change over time. +{%- endtrans %}

        -

        - While some peers are manually configured to be floodfill, - others are simply high-bandwidth routers who automatically volunteer - when the number of floodfill peers drops below a threshold. - This prevents any long-term network damage from losing most or all - floodfills to an attack. - In turn, these peers will un-floodfill themselves when there are - too many floodfills outstanding. -

        +

        {% trans -%} +To increase reliability of the netDb, and minimize the impact +of netDb traffic on a router, floodfill is automatically enabled +only on routers that are configured with high bandwidth limits. +Routers with high bandwidth limits (which must be manually configured, +as the default is much lower) are presumed to be on lower-latency +connections, and are more likely to be available 24/7. +The current minimum share bandwidth for a floodfill router is 128 KBytes/sec. +{%- endtrans %}

        -

        Floodfill Router Roles

        -

        - A floodfill router's only services that are in addition to those of non-floodfill routers - are in accepting netDb stores and responding to netDb queries. - Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels - (i.e. be a "relay" for others), but this is not directly related to their distributed database services. -

        +

        {% trans -%} +In addition, a router must pass several additional tests for health +(outbound message queue time, job lag, etc.) before floodfill operation is +automatically enabled. +{%- endtrans %}

        + +

        {% trans -%} +With the current rules for automatic opt-in, approximately 6% of +the routers in the network are floodfill routers. +{%- endtrans %}

        + +

        {% trans -%} +While some peers are manually configured to be floodfill, +others are simply high-bandwidth routers who automatically volunteer +when the number of floodfill peers drops below a threshold. +This prevents any long-term network damage from losing most or all +floodfills to an attack. +In turn, these peers will un-floodfill themselves when there are +too many floodfills outstanding. +{%- endtrans %}

        + +

        {% trans %}Floodfill Router Roles{% endtrans %}

        +

        {% trans -%} +A floodfill router's only services that are in addition to those of non-floodfill routers +are in accepting netDb stores and responding to netDb queries. +Since they are generally high-bandwidth, they are more likely to participate in a high number of tunnels +(i.e. be a "relay" for others), but this is not directly related to their distributed database services. +{%- endtrans %}

        -

        Kademlia Closeness Metric

        -

        - The netDb uses a simple Kademlia-style XOR metric to determine closeness. - The SHA256 hash of the key being looked up or stored is XOR-ed with - the hash of the router in question to determine closeness. - A modification to this algorithm is done to increase the costs of Sybil attacks. - Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken - of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd). -

        +

        {% trans %}Kademlia Closeness Metric{% endtrans %}

        +

        {% trans -%} +The netDb uses a simple Kademlia-style XOR metric to determine closeness. +The SHA256 hash of the key being looked up or stored is XOR-ed with +the hash of the router in question to determine closeness. +A modification to this algorithm is done to increase the costs of Sybil attacks. +Instead of the SHA256 hash of the key being looked up of stored, the SHA256 hash is taken +of the key appended with the date: yyyyMMdd (SHA256(key + yyyyMMdd). +{%- endtrans %}

        -

        Storage, Verification, and Lookup Mechanics

        +

        {% trans %}Storage, Verification, and Lookup Mechanics{% endtrans %}

        -

        RouterInfo Storage to Peers

        -

        - I2NP DatabaseStoreMessages containing the local RouterInfo are exchanged with peers - as a part of the initialization of a - NTCP - or - SSU - transport connection. -

        +

        {% trans %}RouterInfo Storage to Peers{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np'), ntcp=site_url('docs/transport/ntcp'), ssu=site_url('docs/transport/ssu') -%} +I2NP DatabaseStoreMessages containing the local RouterInfo are exchanged with peers +as a part of the initialization of a NTCP +or SSU transport connection. +{%- endtrans %}

        -

        LeaseSet Storage to Peers

        -

        - I2NP DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers - by bundling them in a garlic message along with normal traffic from the related Destination. - This allows an initial response, and later responses, to be sent to an appropriate Lease, - without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all. -

        +

        {% trans %}LeaseSet Storage to Peers{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +I2NP DatabaseStoreMessages containing the local LeaseSet are periodically exchanged with peers +by bundling them in a garlic message along with normal traffic from the related Destination. +This allows an initial response, and later responses, to be sent to an appropriate Lease, +without requiring any LeaseSet lookups, or requiring the communicating Destinations to have published LeaseSets at all. +{%- endtrans %}

        -

        RouterInfo Storage to Floodfills

        -

        - A router publishes its own RouterInfo by directly connecting to a floodfill router - and sending it a I2NP DatabaseStoreMessage - with a nonzero Reply Token. The message is not end-to-end garlic encrypted, - as this is a direct connection, so there are no intervening routers - (and no need to hide this data anyway). - The floodfill router replies with a - I2NP DeliveryStatusMessage, - with the Message ID set to the value of the Reply Token. -

        +

        {% trans %}RouterInfo Storage to Floodfills{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +A router publishes its own RouterInfo by directly connecting to a floodfill router +and sending it a I2NP DatabaseStoreMessage +with a nonzero Reply Token. The message is not end-to-end garlic encrypted, +as this is a direct connection, so there are no intervening routers +(and no need to hide this data anyway). +The floodfill router replies with a +I2NP DeliveryStatusMessage, +with the Message ID set to the value of the Reply Token. +{%- endtrans %}

        -

        LeaseSet Storage to Floodfills

        -

        - Storage of LeaseSets is much more sensitive than for RouterInfos, as a router - must take care that the LeaseSet cannot be associated with the router. -

        +

        {% trans %}LeaseSet Storage to Floodfills{% endtrans %}

        +

        {% trans -%} +Storage of LeaseSets is much more sensitive than for RouterInfos, as a router +must take care that the LeaseSet cannot be associated with the router. +{%- endtrans %}

        -

        - A router publishes a local LeaseSet by - sending a I2NP DatabaseStoreMessage - with a nonzero Reply Token over an outbound client tunnel for that Destination. - The message is end-to-end garlic encrypted using the Destination's Session Key Manager, - to hide the message from the tunnel's outbound endpoint. - The floodfill router replies with a - I2NP DeliveryStatusMessage, - with the Message ID set to the value of the Reply Token. - This message is sent back to one of the client's inbound tunnels. -

        +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +A router publishes a local LeaseSet by +sending a I2NP DatabaseStoreMessage +with a nonzero Reply Token over an outbound client tunnel for that Destination. +The message is end-to-end garlic encrypted using the Destination's Session Key Manager, +to hide the message from the tunnel's outbound endpoint. +The floodfill router replies with a +I2NP DeliveryStatusMessage, +with the Message ID set to the value of the Reply Token. +This message is sent back to one of the client's inbound tunnels. +{%- endtrans %}

        + + +

        {% trans %}Flooding{% endtrans %}

        +

        {% trans -%} +After a floodfill router receives a DatabaseStoreMessage containing a +valid RouterInfo or LeaseSet which is newer than that previously stored in its +local NetDb, it "floods" it. +To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key +of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.) +{%- endtrans %}

        + +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +It then directly connects to each of the 7 peers +and sends it a I2NP DatabaseStoreMessage +with a zero Reply Token. The message is not end-to-end garlic encrypted, +as this is a direct connection, so there are no intervening routers +(and no need to hide this data anyway). +The other routers do not reply or re-flood, as the Reply Token is zero. +{%- endtrans %}

        + + +

        {% trans %}RouterInfo and LeaseSet Lookup{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +The I2NP DatabaseLookupMessage is used to request a netdb entry from a floodfill router. +Lookups are sent out one of the router's outbound exploratory tunnels. +The replies are specified to return via one of the router's inbound exploratory tunnels. +{%- endtrans %}

        + +

        {% trans -%} +Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel. +{%- endtrans %}

        + +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +If the key is found locally by the floodfill router, it responds with a +I2NP DatabaseStoreMessage. +If the key is not found locally by the floodfill router, it responds with a +I2NP DatabaseSearchReplyMessage +containing a list of other floodfill routers close to the key. +{%- endtrans %}

        + +

        {% trans -%} +Lookups are not encrypted and thus are vulnerable to snooping by the outbound endpoint +(OBEP) of the client tunnel. +{%- endtrans %}

        + +

        {% trans -%} +As the requesting router does not reveal itself, there is no recipient public key for the floodfill router to +encrypt the reply with. Therefore, the reply is exposed to the inbound gateway (IBGW) +of the inbound exploratory tunnel. +An appropriate method of encrypting the reply is a topic for future work. +{%- endtrans %}

        + +

        {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%} +(Reference: Hashing it out in Public Sections 2.2-2.3 for terms below in italics) +{%- endtrans %}

        + +

        {% trans -%} +Due to the relatively small size of the network and the flooding redundancy of 8x, +lookups are usually O(1) rather than O(log n) -- +a router is highly likely to know a floodfill router close enough to the key to get the answer on the first try. +In releases prior to 0.8.9, routers used a lookup redundancy of two +(that is, two lookups were performed in parallel to different peers), and +neither recursive nor iterative routing for lookups was implemented. +Queries were sent through multiple routes simultaneously +to reduce the chance of query failure. +{%- endtrans %}

        + +

        {% trans -%} +As of release 0.8.9, iterative lookups are implemented with no lookup redundancy. +This is a more efficient and reliable lookup that will work much better +when not all floodfill peers are known, and it removes a serious +limitation to network growth. As the network grows and each router knows only a small +subset of the floodfill peers, lookups will become O(log n). +Even if the peer does not return references closer to the key, the lookup continues with +the next-closest peer, for added robustness, and to prevent a malicious floodfill from +black-holing a part of the key space. Lookups continue until a total lookup timeout is reached, +or the maximum number of peers is queried. +{%- endtrans %}

        + +

        {% trans -%} +Node IDs are verifiable in that we use the router hash directly as both the node ID and the Kademlia key. +Incorrect responses that are not closer to the search key are generally ignored. +Given the current size of the network, a router has +detailed knowledge of the neighborhood of the destination ID space. +{%- endtrans %}

        +

        {% trans %}RouterInfo Storage Verification{% endtrans %}

        +

        {% trans -%} +To verify a storage was successful, a router simply waits about 10 seconds, +then sends a lookup to another floodfill router close to the key +(but not the one the store was sent to). +Lookups sent out one of the router's outbound exploratory tunnels. +Lookups are end-to-end garlic encrypted to prevent snooping by the outbound endpoint(OBEP). +{%- endtrans %}

        + +

        {% trans %}LeaseSet Storage Verification{% endtrans %}

        +

        {% trans -%} +To verify a storage was successful, a router simply waits about 10 seconds, +then sends a lookup to another floodfill router close to the key +(but not the one the store was sent to). +Lookups sent out one of the outbound client tunnels for the destination of the LeaseSet being verified. +To prevent snooping by the OBEP of the outbound tunnel, +lookups are end-to-end garlic encrypted. +The replies are specified to return via one of the client's inbound tunnels. +{%- endtrans %}

        + +

        {% trans -%} +As for regular lookups, the reply is unencrypted, +thus exposing the reply to the inbound gateway (IBGW) of the reply tunnel, and +an appropriate method of encrypting the reply is a topic for future work. +As the IBGW for the reply is one of the gateways published in the LeaseSet, +the exposure is minimal. +{%- endtrans %}

        - -

        Flooding

        -

        - After a floodfill router receives a DatabaseStoreMessage containing a - valid RouterInfo or LeaseSet which is newer than that previously stored in its - local NetDb, it "floods" it. - To flood a NetDb entry, it looks up the 7 floodfill routers closest to the key - of the NetDb entry. (The key is the SHA256 Hash of the RouterIdentity or Destination with the date (yyyyMMdd) appended.) -

        -

        - It then directly connects to each of the 7 peers - and sends it a I2NP DatabaseStoreMessage - with a zero Reply Token. The message is not end-to-end garlic encrypted, - as this is a direct connection, so there are no intervening routers - (and no need to hide this data anyway). - The other routers do not reply or re-flood, as the Reply Token is zero. -

        +

        {% trans %}Exploration{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +Exploration is a special form of netdb lookup, where a router attempts to learn about +new routers. +It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random key. +As this lookup will fail, the floodfill would normally respond with a +I2NP DatabaseSearchReplyMessage containing hashes of floodfill routers close to the key. +This would not be helpful, as the requesting router probably already knows those floodfills, +and it would be impractical to add ALL floodfill routers to the "don't include" field of the lookup. +For an exploration query, the requesting router adds a router hash of all zeros to the +"don't include" field of the DatabaseLookupMessage. +The floodfill will then respond only with non-floodfill routers close to the requested key. +{%- endtrans %}

        -

        RouterInfo and LeaseSet Lookup

        -

        - The I2NP DatabaseLookupMessage is used to request a netdb entry from a floodfill router. - Lookups are sent out one of the router's outbound exploratory tunnels. - The replies are specified to return via one of the router's inbound exploratory tunnels. -

        -

        - Lookups are generally sent to the two "good" (the connection doesn't fail) floodfill routers closest to the requested key, in parallel. -

        -

        - If the key is found locally by the floodfill router, it responds with a - I2NP DatabaseStoreMessage. - If the key is not found locally by the floodfill router, it responds with a - I2NP DatabaseSearchReplyMessage - containing a list of other floodfill routers close to the key. -

        - -

        - Lookups are not encrypted and thus are vulnerable to snooping by the outbound endpoint - (OBEP) of the client tunnel. -

        -

        - As the requesting router does not reveal itself, there is no recipient public key for the floodfill router to - encrypt the reply with. Therefore, the reply is exposed to the inbound gateway (IBGW) - of the inbound exploratory tunnel. - An appropriate method of encrypting the reply is a topic for future work. -

        - -

        - (Reference: - Hashing it out in Public Sections 2.2-2.3 for terms below in italics) -

        -

        - Due to the relatively small size of the network and the flooding redundancy of 8x, - lookups are usually O(1) rather than O(log n) -- - a router is highly likely to know a floodfill router close enough to the key to get the answer on the first try. - In releases prior to 0.8.9, routers used a lookup redundancy of two - (that is, two lookups were performed in parallel to different peers), and - neither recursive nor iterative routing for lookups was implemented. - Queries were sent through multiple routes simultaneously - to reduce the chance of query failure. -

        -

        - As of release 0.8.9, iterative lookups are implemented with no lookup redundancy. - This is a more efficient and reliable lookup that will work much better - when not all floodfill peers are known, and it removes a serious - limitation to network growth. As the network grows and each router knows only a small - subset of the floodfill peers, lookups will become O(log n). - Even if the peer does not return references closer to the key, the lookup continues with - the next-closest peer, for added robustness, and to prevent a malicious floodfill from - black-holing a part of the key space. Lookups continue until a total lookup timeout is reached, - or the maximum number of peers is queried. -

        -

        - Node IDs are verifiable in that we use the router hash directly as both the node ID and the Kademlia key. - Incorrect responses that are not closer to the search key are generally ignored. - Given the current size of the network, a router has - detailed knowledge of the neighborhood of the destination ID space. -

        +

        {% trans %}Notes on Lookup Responses{% endtrans %}

        +

        {% trans -%} +The response to a lookup request is either a Database Store Message (on success) or a +Database Search Reply Message (on failure). The DSRM contains a 'from' router hash field +to indicate the source of the reply; the DSM does not. +The DSRM 'from' field is unauthenticated and may be spoofed or invalid. +There are no other response tags. Therefore, when making multiple requests in parallel, it is +difficult to monitor the performance of the various floodfill routers. +{%- endtrans %}

        +

        {% trans %}MultiHoming{% endtrans %}

        -

        RouterInfo Storage Verification

        -

        - To verify a storage was successful, a router simply waits about 10 seconds, - then sends a lookup to another floodfill router close to the key - (but not the one the store was sent to). - Lookups sent out one of the router's outbound exploratory tunnels. - Lookups are end-to-end garlic encrypted to prevent snooping by the outbound endpoint(OBEP). -

        +

        {% trans -%} +Destinations may be hosted on multiple routers simultaneously, by using the same +private and public keys (traditionally stored in eepPriv.dat files). +As both instances will periodically publish their signed LeaseSets to the floodfill peers, +the most recently published LeaseSet will be returned to a peer requesting a database lookup. +As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down, +the outage will be 10 minutes at most, and generally much less than that. +The multihoming function has been verified and is in use by several services on the network. +{%- endtrans %}

        -

        LeaseSet Storage Verification

        -

        - To verify a storage was successful, a router simply waits about 10 seconds, - then sends a lookup to another floodfill router close to the key - (but not the one the store was sent to). - Lookups sent out one of the outbound client tunnels for the destination of the LeaseSet being verified. - To prevent snooping by the OBEP of the outbound tunnel, - lookups are end-to-end garlic encrypted. - The replies are specified to return via one of the client's inbound tunnels. -

        -

        - As for regular lookups, the reply is unencrypted, - thus exposing the reply to the inbound gateway (IBGW) of the reply tunnel, and - an appropriate method of encrypting the reply is a topic for future work. - As the IBGW for the reply is one of the gateways published in the LeaseSet, - the exposure is minimal. -

        +

        {% trans %}Threat Analysis{% endtrans %}

        +

        {% trans threatmodel=site_url('docs/how/threat-model') -%} +Also discussed on the threat model page. +{%- endtrans %}

        + +

        {% trans -%} +A hostile user may attempt to harm the network by +creating one or more floodfill routers and crafting them to offer +bad, slow, or no responses. +Some scenarios are discussed below. +{%- endtrans %}

        + +

        {% trans %}General Mitigation Through Growth{% endtrans %}

        +

        {% trans -%} +There are currently hundreds of floodfill routers in the network. +Most of the following attacks will become more difficult, or have less impact, +as the network size and number of floodfill routers increase. +{%- endtrans %}

        - -

        Exploration

        -

        - Exploration is a special form of netdb lookup, where a router attempts to learn about - new routers. - It does this by sending a floodfill router a I2NP DatabaseLookupMessage, looking for a random key. - As this lookup will fail, the floodfill would normally respond with a - I2NP DatabaseSearchReplyMessage containing hashes of floodfill routers close to the key. - This would not be helpful, as the requesting router probably already knows those floodfills, - and it would be impractical to add ALL floodfill routers to the "don't include" field of the lookup. - For an exploration query, the requesting router adds a router hash of all zeros to the - "don't include" field of the DatabaseLookupMessage. - The floodfill will then respond only with non-floodfill routers close to the requested key. -

        +

        {% trans %}General Mitigation Through Redundancy{% endtrans %}

        +

        {% trans -%} +Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key. +{%- endtrans %}

        -

        Notes on Lookup Responses

        -

        - The response to a lookup request is either a Database Store Message (on success) or a - Database Search Reply Message (on failure). The DSRM contains a 'from' router hash field - to indicate the source of the reply; the DSM does not. - The DSRM 'from' field is unauthenticated and may be spoofed or invalid. - There are no other response tags. Therefore, when making multiple requests in parallel, it is - difficult to monitor the performance of the various floodfill routers. -

        +

        {% trans %}Forgeries{% endtrans %}

        +

        {% trans -%} +All netdb entries are signed by their creators, so no router may forge a +RouterInfo or LeaseSet. +{%- endtrans %}

        - -

        MultiHoming

        - -

        - Destinations may be hosted on multiple routers simultaneously, by using the same - private and public keys (traditionally stored in eepPriv.dat files). - As both instances will periodically publish their signed LeaseSets to the floodfill peers, - the most recently published LeaseSet will be returned to a peer requesting a database lookup. - As LeaseSets have (at most) a 10 minute lifetime, should a particular instance go down, - the outage will be 10 minutes at most, and generally much less than that. - The multihoming function has been verified and is in use by several services on the network. -

        - -

        Threat Analysis

        -

        - Also discussed on the threat model page. -

        -

        - A hostile user may attempt to harm the network by - creating one or more floodfill routers and crafting them to offer - bad, slow, or no responses. - Some scenarios are discussed below. -

        - -

        General Mitigation Through Growth

        -

        - There are currently almost 100 floodfill routers in the network. - Most of the following attacks will become more difficult, or have less impact, - as the network size and number of floodfill routers increase. -

        - - -

        General Mitigation Through Redundancy

        -

        - Via flooding, all netdb entries are stored on the 8 floodfill routers closest to the key. -

        - - -

        Forgeries

        -

        - All netdb entries are signed by their creators, so no router may forge a - RouterInfo or LeaseSet. -

        - -

        Slow or Unresponsive

        -

        - Each router maintains an expanded set of statistics in the - peer profile for each floodfill router, - covering various quality metrics for that peer. - The set includes: -

        +

        {% trans %}Slow or Unresponsive{% endtrans %}

        +

        {% trans peerselection=site_url('docs/how/peer-selection') -%} +Each router maintains an expanded set of statistics in the +peer profile for each floodfill router, +covering various quality metrics for that peer. +The set includes: +{%- endtrans %}

          -
        • Average response time -
        • Percentage of queries answered with the data requested -
        • Percentage of stores that were successfully verified -
        • Last successful store -
        • Last successful lookup -
        • Last response +
        • {% trans %}Average response time{% endtrans %}
        • +
        • {% trans %}Percentage of queries answered with the data requested{% endtrans %}
        • +
        • {% trans %}Percentage of stores that were successfully verified{% endtrans %}
        • +
        • {% trans %}Last successful store{% endtrans %}
        • +
        • {% trans %}Last successful lookup{% endtrans %}
        • +
        • {% trans %}Last response{% endtrans %}
        -

        - Each time a router needs to make a determination on which floodfill router is closest to a key, - it uses these metrics to determine which floodfill routers are "good". - The methods, and thresholds, used to determine "goodness" are relatively new, and - are subject to further analysis and improvement. - While a completely unresponsive router will quickly be identified and avoided, - routers that are only sometimes malicious may be much harder to deal with. -

        +

        {% trans -%} +Each time a router needs to make a determination on which floodfill router is closest to a key, +it uses these metrics to determine which floodfill routers are "good". +The methods, and thresholds, used to determine "goodness" are relatively new, and +are subject to further analysis and improvement. +While a completely unresponsive router will quickly be identified and avoided, +routers that are only sometimes malicious may be much harder to deal with. +{%- endtrans %}

        -

        Sybil Attack (Full Keyspace)

        -

        - An attacker may mount a - Sybil attack - by creating a large number of floodfill routers spread throughout the keyspace. -

        +

        {% trans %}Sybil Attack (Full Keyspace){% endtrans %}

        +

        {% trans url='http://citeseer.ist.psu.edu/douceur02sybil.html' -%} +An attacker may mount a Sybil attack +by creating a large number of floodfill routers spread throughout the keyspace. +{%- endtrans %}

        -

        - (In a related example, a researcher recently created a - large number of Tor relays.) +

        {% trans url='http://blog.torproject.org/blog/june-2010-progress-report' -%} +(In a related example, a researcher recently created a +large number of Tor relays.) +If successful, this could be an effective DOS attack on the entire network. +{%- endtrans %}

        - If successful, this could be an effective DOS attack on the entire network. -

        - -

        - If the floodfills are not sufficiently misbehaving to be marked as "bad" using the peer profile - metrics described above, this is a difficult scenario to handle. - Tor's response can be much more nimble in the relay case, as the suspicious relays - can be manually removed from the consensus. - Some possible responses for the I2P network are listed below, however none of them is completely satisfactory: -

        +

        {% trans -%} +If the floodfills are not sufficiently misbehaving to be marked as "bad" using the peer profile +metrics described above, this is a difficult scenario to handle. +Tor's response can be much more nimble in the relay case, as the suspicious relays +can be manually removed from the consensus. +Some possible responses for the I2P network are listed below, however none of them is completely satisfactory: +{%- endtrans %}

          -
        • Compile a list of bad router hashes or IPs, and announce the list through various means - (console news, website, forum, etc.); users would have to manually download the list and - add it to their local "blacklist" -
        • Ask everyone in the network to enable floodfill manually (fight Sybil with more Sybil) -
        • Release a new software version that includes the hardcoded "bad" list -
        • Release a new software version that improves the peer profile metrics and thresholds, - in an attempt to automatically identify the "bad" peers -
        • Add software that disqualifies floodfills if too many of them are in a single IP block -
        • Implement an automatic subscription-based blacklist controlled by a single individual or group. - This would essentially implement a portion of the Tor "consensus" model. - Unfortunately it would also give a single individual or group the power to - block participation of any particular router or IP in the network, - or even to completely shutdown or destroy the entire network. +
        • {% trans -%} +Compile a list of bad router hashes or IPs, and announce the list through various means +(console news, website, forum, etc.); users would have to manually download the list and +add it to their local "blacklist". +{%- endtrans %}
        • +
        • {% trans %}Ask everyone in the network to enable floodfill manually (fight Sybil with more Sybil){% endtrans %}
        • +
        • {% trans %}Release a new software version that includes the hardcoded "bad" list{% endtrans %}
        • +
        • {% trans -%} +Release a new software version that improves the peer profile metrics and thresholds, +in an attempt to automatically identify the "bad" peers. +{%- endtrans %}
        • +
        • {% trans %}Add software that disqualifies floodfills if too many of them are in a single IP block{% endtrans %}
        • +
        • {% trans -%} +Implement an automatic subscription-based blacklist controlled by a single individual or group. +This would essentially implement a portion of the Tor "consensus" model. +Unfortunately it would also give a single individual or group the power to +block participation of any particular router or IP in the network, +or even to completely shutdown or destroy the entire network. +{%- endtrans %}
        -

        +

        {% trans -%} This attack becomes more difficult as the network size grows. -

        +{%- endtrans %}

        -

        Sybil Attack (Partial Keyspace)

        -

        - An attacker may mount a - Sybil attack - by creating a small number (8-15) of floodfill routers clustered closely in the keyspace, - and distribute the RouterInfos for these routers widely. - Then, all lookups and stores for a key in that keyspace would be directed - to one of the attacker's routers. - If successful, this could be an effective DOS attack on a particular eepsite, for example. -

        -

        - As the keyspace is indexed by the cryptographic (SHA256) Hash of the key, - an attacker must use a brute-force method to repeatedly generate router hashes - until he has enough that are sufficiently close to the key. - The amount of computational power required for this, which is dependent on network - size, is unknown. -

        +

        {% trans %}Sybil Attack (Partial Keyspace){% endtrans %}

        +

        {% trans url='http://citeseer.ist.psu.edu/douceur02sybil.html' -%} +An attacker may mount a Sybil attack +by creating a small number (8-15) of floodfill routers clustered closely in the keyspace, +and distribute the RouterInfos for these routers widely. +Then, all lookups and stores for a key in that keyspace would be directed +to one of the attacker's routers. +If successful, this could be an effective DOS attack on a particular eepsite, for example. +{%- endtrans %}

        -

        - As a partial defense against this attack, - the algorithm used to determine Kademlia "closeness" varies over time. - Rather than using the Hash of the key (i.e. H(k)) to determine closeness, - we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD). - A function called the "routing key generator" does this, which transforms the original key into a "routing key". - In other words, the entire netdb keyspace "rotates" every day at UTC midnight. - Any partial-keyspace attack would have to be regenerated every day, for - after the rotation, the attacking routers would no longer be close - to the target key, or to each other. -

        -

        +

        {% trans -%} +As the keyspace is indexed by the cryptographic (SHA256) Hash of the key, +an attacker must use a brute-force method to repeatedly generate router hashes +until he has enough that are sufficiently close to the key. +The amount of computational power required for this, which is dependent on network +size, is unknown. +{%- endtrans %}

        + +

        {% trans -%} +As a partial defense against this attack, +the algorithm used to determine Kademlia "closeness" varies over time. +Rather than using the Hash of the key (i.e. H(k)) to determine closeness, +we use the Hash of the key appended with the current date string, i.e. H(k + YYYYMMDD). +A function called the "routing key generator" does this, which transforms the original key into a "routing key". +In other words, the entire netdb keyspace "rotates" every day at UTC midnight. +Any partial-keyspace attack would have to be regenerated every day, for +after the rotation, the attacking routers would no longer be close +to the target key, or to each other. +{%- endtrans %}

        + +

        {% trans -%} This attack becomes more difficult as the network size grows. -

        +{%- endtrans %}

        -

        - One consequence of daily keyspace rotation is that the distributed network database - may become unreliable for a few minutes after the rotation -- - lookups will fail because the new "closest" router has not received a store yet. - The extent of the issue, and methods for mitigation - (for example netdb "handoffs" at midnight) - are a topic for further study. -

        +

        {% trans -%} +One consequence of daily keyspace rotation is that the distributed network database +may become unreliable for a few minutes after the rotation -- +lookups will fail because the new "closest" router has not received a store yet. +The extent of the issue, and methods for mitigation +(for example netdb "handoffs" at midnight) +are a topic for further study. +{%- endtrans %}

        -

        Bootstrap Attacks

        -

        - An attacker could attempt to boot new routers into an isolated - or majority-controlled network by taking over a reseed website, - or tricking the developers into adding his reseed website - to the hardcoded list in the router. -

        -

        - Several defenses are possible, and most of these are planned: -

        +

        {% trans %}Bootstrap Attacks{% endtrans %}

        +

        {% trans -%} +An attacker could attempt to boot new routers into an isolated +or majority-controlled network by taking over a reseed website, +or tricking the developers into adding his reseed website +to the hardcoded list in the router. +{%- endtrans %}

        + +

        {% trans -%} +Several defenses are possible, and most of these are planned: +{%- endtrans %}

          -
        • Disallow fallback from HTTPS to HTTP for reseeding. - A MITM attacker could simply block HTTPS, then respond to the HTTP. -
        • Changing the reseed task to fetch a subset of RouterInfos from - each of several reseed sites rather than using only a single site -
        • Creating an out-of-network reseed monitoring service that - periodically polls reseed websites and verifies that the - data are not stale or inconsistent with other views of the network -
        • Bundling reseed data in the installer +
        • {% trans -%} +Disallow fallback from HTTPS to HTTP for reseeding. +A MITM attacker could simply block HTTPS, then respond to the HTTP. +{%- endtrans %}
        • +
        • {% trans -%} +Changing the reseed task to fetch a subset of RouterInfos from +each of several reseed sites rather than using only a single site +{%- endtrans %}
        • +
        • {% trans -%} +Creating an out-of-network reseed monitoring service that +periodically polls reseed websites and verifies that the +data are not stale or inconsistent with other views of the network +{%- endtrans %}
        • +
        • {% trans %}Bundling reseed data in the installer{% endtrans %}
        -

        Query Capture

        -

        - See also lookup - (Reference: - Hashing it out in Public Sections 2.2-2.3 for terms below in italics) -

        -

        - Similar to a bootstrap attack, an attacker using a floodfill router could attempt to "steer" - peers to a subset of routers controlled by him by returning their references. -

        -

        - This is unlikely to work via exploration, because exploration is a low-frequency task. - Routers acquire a majority of their peer references through normal tunnel building activity. - Exploration results are generally limited to a few router hashes, - and each exploration query is directed to a random floodfill router. -

        -

        - As of release 0.8.9, iterative lookups are implemented. - For floodfill router references returned in a - I2NP DatabaseSearchReplyMessage - response to a lookup, - these references are followed if they are closer (or the next closest) to the lookup key. - The requesting router does not trust that the references are - closer to the key (i.e. they are verifiably correct. - The lookup also does not stop when no closer key is found, but continues by querying the - next-closet node, until the timeout or maximum number of queries is reached. - This prevents a malicious floodfill from black-holing a part of the key space. - Also, the daily keyspace rotation requires an attacker to regenerate a router info - within the desired key space region. - This design ensures that the query capture attack described in - Hashing it out in Public - is much more difficult. -

        +

        {% trans %}Query Capture{% endtrans %}

        +

        {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%} +See also lookup +(Reference: Hashing it out in Public Sections 2.2-2.3 for terms below in italics) +{%- endtrans %}

        -

        DHT-Based Relay Selection

        -

        - (Reference: - Hashing it out in Public Section 3) -

        -

        - This doesn't have much to do with floodfill, but see - the peer selection page - for a discussion of the vulnerabilities of peer selection for tunnels. -

        +

        {% trans -%} +Similar to a bootstrap attack, an attacker using a floodfill router could attempt to "steer" +peers to a subset of routers controlled by him by returning their references. +{%- endtrans %}

        -

        Information Leaks

        -

        - (Reference: - In Search of an Anonymous and Secure Lookup Section 3) -

        -

        - This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN. - At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN - is significantly different from that in I2P. Second, I2P's network database lookups are only - loosely correlated to the peer selection and - tunnel building processes; only previously-known peers - are used for tunnels. - Also, peer selection is unrelated to any notion of DHT key-closeness. -

        -

        - Some of this may actually be more interesting when the I2P network gets much larger. - Right now, each router knows a large proportion of the network, so looking up a particular - Router Info in the network database is not strongly indicative of a future intent to use - that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be - more correlative. Of course, a larger network makes a Sybil attack that much harder. -

        -

        - However, the general issue of DHT information leakage in I2P needs further investigation. - The floodfill routers are in a position to observe queries and gather information. - Certainly, at a level of f = 0.2 (20% malicious nodes, as specifed in the paper) - we expect that many of the Sybil threats we describe - (here, - here and - here) - become problematic for several reasons. -

        +

        {% trans -%} +This is unlikely to work via exploration, because exploration is a low-frequency task. +Routers acquire a majority of their peer references through normal tunnel building activity. +Exploration results are generally limited to a few router hashes, +and each exploration query is directed to a random floodfill router. +{%- endtrans %}

        + +

        {% trans i2np=site_url('docs/protocol/i2np'), +pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%} +As of release 0.8.9, iterative lookups are implemented. +For floodfill router references returned in a +I2NP DatabaseSearchReplyMessage +response to a lookup, +these references are followed if they are closer (or the next closest) to the lookup key. +The requesting router does not trust that the references are +closer to the key (i.e. they are verifiably correct. +The lookup also does not stop when no closer key is found, but continues by querying the +next-closet node, until the timeout or maximum number of queries is reached. +This prevents a malicious floodfill from black-holing a part of the key space. +Also, the daily keyspace rotation requires an attacker to regenerate a router info +within the desired key space region. +This design ensures that the query capture attack described in +Hashing it out in Public +is much more difficult. +{%- endtrans %}

        + +

        {% trans %}DHT-Based Relay Selection{% endtrans %}

        +

        {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%} +(Reference: Hashing it out in Public Section 3) +{%- endtrans %}

        + +

        {% trans peerselection=site_url('docs/how/peer-selection') -%} +This doesn't have much to do with floodfill, but see +the peer selection page +for a discussion of the vulnerabilities of peer selection for tunnels. +{%- endtrans %}

        + +

        {% trans %}Information Leaks{% endtrans %}

        +

        {% trans pdf='https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf' -%} +(Reference: In Search of an Anonymous and Secure Lookup Section 3) +{%- endtrans %}

        + +

        {% trans peerselection=site_url('docs/how/peer-selection'), +tunnelrouting=site_url('docs/how/tunnel-routing') -%} +This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN. +At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN +is significantly different from that in I2P. Second, I2P's network database lookups are only +loosely correlated to the peer selection and +tunnel building processes; only previously-known peers +are used for tunnels. +Also, peer selection is unrelated to any notion of DHT key-closeness. +{%- endtrans %}

        + +

        {% trans -%} +Some of this may actually be more interesting when the I2P network gets much larger. +Right now, each router knows a large proportion of the network, so looking up a particular +Router Info in the network database is not strongly indicative of a future intent to use +that router in a tunnel. Perhaps when the network is 100 times larger, the lookup may be +more correlative. Of course, a larger network makes a Sybil attack that much harder. +{%- endtrans %}

        + +

        {% trans threatmodel=site_url('docs/how/threat-model') -%} +However, the general issue of DHT information leakage in I2P needs further investigation. +The floodfill routers are in a position to observe queries and gather information. +Certainly, at a level of f = 0.2 (20% malicious nodes, as specifed in the paper) +we expect that many of the Sybil threats we describe +(here, +here and +here) +become problematic for several reasons. +{%- endtrans %}

        -

        History

        +

        {% trans %}History{% endtrans %}

        - Moved to the netdb discussion page. + {% trans %}Moved to the netdb discussion page{% endtrans %}.

        -

        Future Work

        -

        - End-to-end encryption of additional netDb lookups and responses. -

        -

        - Better methods for tracking lookup responses. -

        +

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

        +

        {% trans -%} +End-to-end encryption of additional netDb lookups and responses. +{%- endtrans %}

        +

        {% trans -%} +Better methods for tracking lookup responses. +{%- endtrans %}

        {% endblock %} From b3281bbd56e3661f053f0b47445051c160403f1a Mon Sep 17 00:00:00 2001 From: str4d Date: Sat, 2 Feb 2013 23:18:39 +0000 Subject: [PATCH 379/498] Fixed bug on docs/discussions/netdb --- i2p2www/pages/site/docs/discussions/netdb.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/site/docs/discussions/netdb.html b/i2p2www/pages/site/docs/discussions/netdb.html index 6dd537ea..ab3769b4 100644 --- a/i2p2www/pages/site/docs/discussions/netdb.html +++ b/i2p2www/pages/site/docs/discussions/netdb.html @@ -241,7 +241,7 @@ This just accounts for the stores - what about the queries?

        The Return of the Kademlia Algorithm?

        -(this is adapted from the I2P meeting Jan. 2, 2007) +(this is adapted from the I2P meeting Jan. 2, 2007)
        The Kademlia netDb just wasn't working properly. Is it dead forever or will it be coming back? From e76ea72aeaa00186681d2a892ff5d29edb3f1081 Mon Sep 17 00:00:00 2001 From: kytv Date: Sat, 2 Feb 2013 23:25:25 +0000 Subject: [PATCH 380/498] eliminate some redundancy in the POT file --- i2p2www/blog/2012/10/27/0.9.3-Release.rst | 11 ++++------- i2p2www/blog/2012/12/17/0.9.4-Release.rst | 7 ++----- i2p2www/pages/global/layout.html | 2 +- i2p2www/pages/site/about/intro.html | 2 +- i2p2www/pages/site/docs/naming.html | 4 ++-- i2p2www/pages/site/impressum.html | 2 +- 6 files changed, 11 insertions(+), 17 deletions(-) diff --git a/i2p2www/blog/2012/10/27/0.9.3-Release.rst b/i2p2www/blog/2012/10/27/0.9.3-Release.rst index 4b8e655c..24eb013d 100644 --- a/i2p2www/blog/2012/10/27/0.9.3-Release.rst +++ b/i2p2www/blog/2012/10/27/0.9.3-Release.rst @@ -4,15 +4,12 @@ .. meta:: :date: 2012-10-27 :category: release - :excerpt: {% trans %}0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default.{% endtrans %} + :excerpt: {% trans %}0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default.{% endtrans %} {% trans -%} -0.9.3 includes extensive low-level changes to the queueing of messages in the router. -We implement the CoDel Active Queue Management (AQM) algorithm. -We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. -Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. -There are more changes to improve the performance of the router and reduce its memory usage. -Also, we enable i2psnark's DHT support, introduced last release, by default. +0.9.3 includes extensive low-level changes to the queueing of messages in the router. We implement the CoDel Active Queue Management (AQM) algorithm. We also unify the queueing and priority mechanisms in the transports to aid diagnosis and reduce network latency. Work continues on fixing UDP transport bugs and making UDP more resistant to attacks. There are more changes to improve the performance of the router and reduce its memory usage. Also, we enable i2psnark's DHT support, introduced last release, by default. +{%- endtrans %} +{% trans -%} As usual, there's also lots of bug fixes in this release, so updating is recommended. {%- endtrans %} diff --git a/i2p2www/blog/2012/12/17/0.9.4-Release.rst b/i2p2www/blog/2012/12/17/0.9.4-Release.rst index 13d45281..cb457111 100644 --- a/i2p2www/blog/2012/12/17/0.9.4-Release.rst +++ b/i2p2www/blog/2012/12/17/0.9.4-Release.rst @@ -4,13 +4,10 @@ .. meta:: :date: 2012-12-17 :category: release - :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} + :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} {% trans -%} -0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, -that was reducing network performance and reliability. It also includes -major changes in the in-network update system, and adds the capability -to update via in-network torrents. +0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents. {%- endtrans %} {% trans -%} diff --git a/i2p2www/pages/global/layout.html b/i2p2www/pages/global/layout.html index 8917da0f..c63e3f75 100644 --- a/i2p2www/pages/global/layout.html +++ b/i2p2www/pages/global/layout.html @@ -28,7 +28,7 @@

        - +

        {{ self.title() }}

        diff --git a/i2p2www/pages/site/about/intro.html b/i2p2www/pages/site/about/intro.html index e63517a1..5c979f5b 100644 --- a/i2p2www/pages/site/about/intro.html +++ b/i2p2www/pages/site/about/intro.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}{{ _('Intro') }}{% endblock %} {% block content %} -

        {{ _('The Invisible Internet Project (I2P)') }}

        +

        {{ _('The Invisible Internet Project') }} (I2P)

        {% trans -%} I2P is an anonymous network, exposing a simple layer that applications can use to anonymously and securely send messages to each other. The network itself is diff --git a/i2p2www/pages/site/docs/naming.html b/i2p2www/pages/site/docs/naming.html index c8341834..405320df 100644 --- a/i2p2www/pages/site/docs/naming.html +++ b/i2p2www/pages/site/docs/naming.html @@ -180,8 +180,8 @@ to other routers. {%- endtrans %}

        {% trans -%} -Naming rules: -{%- endtrans %}

        +Naming Rules +{%- endtrans %}:

        • {% trans -%} Names are converted to lower case on import. diff --git a/i2p2www/pages/site/impressum.html b/i2p2www/pages/site/impressum.html index 50597ea0..325a9d11 100644 --- a/i2p2www/pages/site/impressum.html +++ b/i2p2www/pages/site/impressum.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}Impressum{% endblock %} {% block content %} -

          [{{ _('German laws...') }}]

          +

          [{{ _('German laws') }}]...

          Tassilo Schweyer
          Weitfelderweg 8b
          89275 Elchingen

          From c20fd0d9086cc6ecb6852ee9200cd98c31993d31 Mon Sep 17 00:00:00 2001 From: kytv Date: Sat, 2 Feb 2013 23:30:13 +0000 Subject: [PATCH 381/498] eliminate dups (it's not very nice to have line lines, but that's why we have word-wrap in our editors) --- i2p2www/blog/2012/12/17/0.9.4-Release.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/blog/2012/12/17/0.9.4-Release.rst b/i2p2www/blog/2012/12/17/0.9.4-Release.rst index cb457111..8ab7476d 100644 --- a/i2p2www/blog/2012/12/17/0.9.4-Release.rst +++ b/i2p2www/blog/2012/12/17/0.9.4-Release.rst @@ -4,7 +4,7 @@ .. meta:: :date: 2012-12-17 :category: release - :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} + :excerpt: {% trans %}0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents.{% endtrans %} {% trans -%} 0.9.4 includes a fix for a network capacity bug, introduced in 0.9.2, that was reducing network performance and reliability. It also includes major changes in the in-network update system, and adds the capability to update via in-network torrents. From c334777f74e840e13d9e96d9127f55130683abee Mon Sep 17 00:00:00 2001 From: kytv Date: Sun, 3 Feb 2013 00:19:36 +0000 Subject: [PATCH 382/498] - make script bourne compatible - check for virtualenv --- setup_venv.sh | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/setup_venv.sh b/setup_venv.sh index 3db2d33c..af98f169 100755 --- a/setup_venv.sh +++ b/setup_venv.sh @@ -1,11 +1,14 @@ -#!/usr/bin/env bash +#!/bin/sh set -e -source ./project.vars +. ./project.vars -if [ ! -d $venv_dir ] ; then - $venv --distribute $venv_dir +if [ ! $venv ]; then + echo "ERROR: virtualenv not found!" >&2 +else + if [ ! -d $venv_dir ] ; then + $venv --distribute $venv_dir + fi + + . $venv_dir/bin/activate + pip install -r reqs.txt fi - -source $venv_dir/bin/activate - -pip install -r reqs.txt From 9e1e5352c2d9f7d05ef1c4da461a259f3e14cdfa Mon Sep 17 00:00:00 2001 From: kytv Date: Sun, 3 Feb 2013 00:19:59 +0000 Subject: [PATCH 383/498] add transifex configs --- .tx/config | 11 +++++++++++ 1 file changed, 11 insertions(+) create mode 100644 .tx/config diff --git a/.tx/config b/.tx/config new file mode 100644 index 00000000..86698fe1 --- /dev/null +++ b/.tx/config @@ -0,0 +1,11 @@ +[I2P.website] +source_file = ./messages.pot +source_lang = en +trans.de = i2p2www/translations/de/LC_MESSAGES/messages.po +trans.es = i2p2www/translations/es/LC_MESSAGES/messages.po +trans.fr = i2p2www/translations/fr/LC_MESSAGES/messages.po +type = PO + +[main] +host = http://www.transifex.net + From 1fee91daab273aa97fbda25dcabc0d17176ef583 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 00:48:42 +0000 Subject: [PATCH 384/498] Added translation tags to docs/tunnels/* docs/tunnels/old-implementation has only been tagged at the top, as it covers old details and so is not urgently required. --- .../site/docs/tunnels/implementation.html | 398 +++++++++++------- .../site/docs/tunnels/old-implementation.html | 6 +- .../site/docs/tunnels/unidirectional.html | 77 ++-- 3 files changed, 292 insertions(+), 189 deletions(-) diff --git a/i2p2www/pages/site/docs/tunnels/implementation.html b/i2p2www/pages/site/docs/tunnels/implementation.html index ad515cac..b10288ee 100644 --- a/i2p2www/pages/site/docs/tunnels/implementation.html +++ b/i2p2www/pages/site/docs/tunnels/implementation.html @@ -1,14 +1,15 @@ {% extends "global/layout.html" %} -{% block title %}Tunnel Implementation{% endblock %} -{% block lastupdated %}October 2010{% endblock %} +{% block title %}{% trans %}Tunnel Implementation{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}October 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -This page documents the current tunnel implementation. +{% trans %}This page documents the current tunnel implementation.{% endtrans %} -

          Tunnel overview

          +

          {% trans %}Tunnel overview{% endtrans %}

          -

          Within I2P, messages are passed in one direction through a virtual +

          {% trans -%} +Within I2P, messages are passed in one direction through a virtual tunnel of peers, using whatever means are available to pass the message on to the next hop. Messages arrive at the tunnel's gateway, get bundled up and/or fragmented into fixed-size tunnel messages, @@ -16,175 +17,215 @@ and are forwarded on to the next hop in the tunnel, which processes and verifies the validity of the message and sends it on to the next hop, and so on, until it reaches the tunnel endpoint. That endpoint takes the messages bundled up by the gateway and forwards them as instructed - either -to another router, to another tunnel on another router, or locally.

          +to another router, to another tunnel on another router, or locally. +{%- endtrans %}

          -

          Tunnels all work the same, but can be segmented into two different +

          {% trans -%} +Tunnels all work the same, but can be segmented into two different groups - inbound tunnels and outbound tunnels. The inbound tunnels have an untrusted gateway which passes messages down towards the tunnel creator, which serves as the tunnel endpoint. For outbound tunnels, the tunnel creator serves as the gateway, passing messages -out to the remote endpoint.

          +out to the remote endpoint. +{%- endtrans %}

          -

          The tunnel's creator selects exactly which peers will participate +

          {% trans -%} +The tunnel's creator selects exactly which peers will participate in the tunnel, and provides each with the necessary configuration data. They may have any number of hops. It is the intent to make it hard for either participants or third parties to determine the length of a tunnel, or even for colluding participants to determine whether they are a part of the same tunnel at all (barring the situation where colluding peers are -next to each other in the tunnel).

          +next to each other in the tunnel). +{%- endtrans %}

          -

          In practice, a series of tunnel pools are used for different +

          {% trans -%} +In practice, a series of tunnel pools are used for different purposes - each local client destination has its own set of inbound tunnels and outbound tunnels, configured to meet its anonymity and performance needs. In addition, the router itself maintains a series of pools for participating in the network database and for managing -the tunnels themselves.

          +the tunnels themselves. +{%- endtrans %}

          -

          I2P is an inherently packet switched network, even with these +

          {% trans -%} +I2P is an inherently packet switched network, even with these tunnels, allowing it to take advantage of multiple tunnels running in parallel, increasing resilience and balancing load. Outside of the core I2P layer, there is an optional end to end streaming library available for client applications, exposing TCP-esque operation, -including message reordering, retransmission, congestion control, etc.

          +including message reordering, retransmission, congestion control, etc. +{%- endtrans %}

          -

          +

          {% trans tunnelrouting=site_url('docs/how/tunnel-routing') -%} An overview of I2P tunnel terminology is -on the tunnel overview page. -

          +on the tunnel overview page. +{%- endtrans %}

          -

          Tunnel Operation (Message Processing)

          -

          Overview

          +

          {% trans %}Tunnel Operation (Message Processing){% endtrans %}

          +

          {% trans %}Overview{% endtrans %}

          -

          After a tunnel is built, I2NP messages are processed and passed through it. +

          {% trans i2np=site_url('docs/spec/i2np') -%} +After a tunnel is built, I2NP messages are processed and passed through it. Tunnel operation has four distinct processes, taken on by various -peers in the tunnel.

          1. First, the tunnel gateway accumulates a number +peers in the tunnel. +{%- endtrans %}

            +
              +
            1. {% trans -%} +First, the tunnel gateway accumulates a number of I2NP messages and preprocesses them into tunnel messages for -delivery.
            2. Next, that gateway encrypts that preprocessed data, then -forwards it to the first hop.
            3. That peer, and subsequent tunnel +delivery. +{%- endtrans %}
            4. +
            5. {% trans -%} +Next, that gateway encrypts that preprocessed data, then +forwards it to the first hop. +{%- endtrans %}
            6. +
            7. {% trans -%} +That peer, and subsequent tunnel participants, unwrap a layer of the encryption, verifying that it isn't -a duplicate, then forward it on to the next peer. -
            8. Eventually, the tunnel messages arrive at the endpoint where the I2NP messages +a duplicate, then forward it on to the next peer. +{%- endtrans %}
            9. +
            10. {% trans -%} +Eventually, the tunnel messages arrive at the endpoint where the I2NP messages originally bundled by the gateway are reassembled and forwarded on as -requested.

            +requested. +{%- endtrans %}
          2. +
          -

          +

          {% trans -%} Intermediate tunnel participants do not know whether they are in an inbound or an outbound tunnel; they always "encrypt" for the next hop. Therefore, we take advantage of symmetric AES encryption to "decrypt" at the outbound tunnel gateway, so that the plaintext is revealed at the outbound endpoint. -

          +{%- endtrans %}

          - Inbound and outbound tunnel schematic + {{ _('Inbound and outbound tunnel schematic') }}

          - - - - + + + + - - - - + + + + + - + + - - + + - + + - - + + - - - - + + + + + - + + - - + + - + + - - + +
          RolePreprocessingEncryption OperationPostprocessing{% trans %}Role{% endtrans %}{% trans %}Preprocessing{% endtrans %}{% trans %}Encryption Operation{% endtrans %}{% trans %}Postprocessing{% endtrans %}
          Outbound Gateway (Creator)Fragment, Batch, and PadIteratively encrypt (using decryption operations)Forward to next hop
          {% trans %}Outbound Gateway (Creator){% endtrans %}{% trans %}Fragment, Batch, and Pad{% endtrans %}{% trans %}Iteratively encrypt (using decryption operations){% endtrans %}{% trans %}Forward to next hop{% endtrans %}
          Participant
          {% trans %}Participant{% endtrans %}  Decrypt (using an encryption operation)Forward to next hop{% trans %}Decrypt (using an encryption operation){% endtrans %}{% trans %}Forward to next hop{% endtrans %}
          Outbound Endpoint
          {% trans %}Outbound Endpoint{% endtrans %}  Decrypt (using an encryption operation) to reveal plaintext tunnel messageReassemble Fragments, Forward as instructed to Inbound Gateway or Router{% trans %}Decrypt (using an encryption operation) to reveal plaintext tunnel message{% endtrans %}{% trans %}Reassemble Fragments, Forward as instructed to Inbound Gateway or Router{% endtrans %}

          Inbound GatewayFragment, Batch, and PadEncryptForward to next hop
          {% trans %}Inbound Gateway{% endtrans %}{% trans %}Fragment, Batch, and Pad{% endtrans %}{% trans %}Encrypt{% endtrans %}{% trans %}Forward to next hop{% endtrans %}
          Participant
          {% trans %}Participant{% endtrans %}  EncryptForward to next hop{% trans %}Encrypt{% endtrans %}{% trans %}Forward to next hop{% endtrans %}
          Inbound Endpoint (Creator)
          {% trans %}Inbound Endpoint (Creator){% endtrans %}  Iteratively decrypt to reveal plaintext tunnel messageReassemble Fragments, Receive data{% trans %}Iteratively decrypt to reveal plaintext tunnel message{% endtrans %}{% trans %}Reassemble Fragments, Receive data{% endtrans %}
          -

          Gateway Processing

          -

          Message Preprocessing

          +

          {% trans %}Gateway Processing{% endtrans %}

          +

          {% trans %}Message Preprocessing{% endtrans %}

          -

          A tunnel gateway's function is to fragment and pack -I2NP messages into fixed-size -tunnel messages +

          {% trans i2np=site_url('docs/spec/i2np'), tunnelmessage=site_url('docs/spec/tunnel-message') -%} +A tunnel gateway's function is to fragment and pack +I2NP messages into fixed-size +tunnel messages and encrypt the tunnel messages. Tunnel messages contain the following: - +{%- endtrans %}

            -
          • A 4 byte Tunnel ID
          • -
          • A 16 byte IV (initialization vector)
          • -
          • A checksum -
          • Padding, if necessary
          • -
          • One or more { delivery instruction, I2NP message fragment } pairs
          • +
          • {% trans %}A 4 byte Tunnel ID{% endtrans %}
          • +
          • {% trans %}A 16 byte IV (initialization vector){% endtrans %}
          • +
          • {% trans %}A checksum{% endtrans %}
          • +
          • {% trans %}Padding, if necessary{% endtrans %}
          • +
          • {% trans %}One or more { delivery instruction, I2NP message fragment } pairs{% endtrans %}
          -

          Tunnel IDs are 4 byte numbers used at each hop - participants know what +

          {% trans -%} +Tunnel IDs are 4 byte numbers used at each hop - participants know what tunnel ID to listen for messages with and what tunnel ID they should be forwarded on as to the next hop, and each hop chooses the tunnel ID which they receive messages on. Tunnels themselves are short-lived (10 minutes). Even if subsequent tunnels are built using the same sequence of -peers, each hop's tunnel ID will change.

          +peers, each hop's tunnel ID will change. +{%- endtrans %}

          -

          To prevent adversaries from tagging the messages along the path by adjusting +

          {% trans -%} +To prevent adversaries from tagging the messages along the path by adjusting the message size, all tunnel messages are a fixed 1024 bytes in size. To accommodate larger I2NP messages as well as to support smaller ones more efficiently, the gateway splits up the larger I2NP messages into fragments contained within each tunnel message. The endpoint will attempt to rebuild the I2NP message from the -fragments for a short period of time, but will discard them as necessary.

          - -

          +fragments for a short period of time, but will discard them as necessary. +{%- endtrans %}

          +

          {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%} Details are in the -tunnel message specification. +tunnel message specification. +{%- endtrans %}

          +

          {% trans %}Gateway Encryption{% endtrans %}

          -

          Gateway Encryption

          - -

          After the preprocessing of messages into a padded payload, the gateway builds +

          {% trans -%} +After the preprocessing of messages into a padded payload, the gateway builds a random 16 byte IV value, iteratively encrypting it and the tunnel message as -necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel message} to the next hop.

          +necessary, and forwards the tuple {tunnelID, IV, encrypted tunnel message} to the next hop. +{%- endtrans %}

          -

          How encryption at the gateway is done depends on whether the tunnel is an +

          {% trans -%} +How encryption at the gateway is done depends on whether the tunnel is an inbound or an outbound tunnel. For inbound tunnels, they simply select a random IV, postprocessing and updating it to generate the IV for the gateway and using that IV along side their own layer key to encrypt the preprocessed data. For outbound tunnels they must iteratively decrypt the (unencrypted) IV and preprocessed data with the IV and layer keys for all hops in the tunnel. The result of the outbound tunnel encryption is that when each peer encrypts it, the endpoint will recover -the initial preprocessed data.

          +the initial preprocessed data. +{%- endtrans %}

          -

          Participant Processing

          -

          When a peer receives a tunnel message, it checks that the message came from +

          {% trans %}Participant Processing{% endtrans %}

          + +

          {% trans -%} +When a peer receives a tunnel message, it checks that the message came from the same previous hop as before (initialized when the first message comes through the tunnel). If the previous peer is a different router, or if the message has already been seen, the message is dropped. The participant then encrypts the @@ -193,9 +234,11 @@ that IV with the participant's layer key to encrypt the data, encrypts the current IV with AES256/ECB using their IV key again, then forwards the tuple {nextTunnelId, nextIV, encryptedData} to the next hop. This double encryption of the IV (both before and after use) help address a certain class of -confirmation attacks.

          +confirmation attacks. +{%- endtrans %}

          -

          Duplicate message detection is handled by a decaying Bloom filter on message +

          {% trans -%} +Duplicate message detection is handled by a decaying Bloom filter on message IVs. Each router maintains a single Bloom filter to contain the XOR of the IV and the first block of the message received for all of the tunnels it is participating in, modified to drop seen entries after 10-20 minutes (when the tunnels will have @@ -203,155 +246,195 @@ expired). The size of the bloom filter and the parameters used are sufficient t more than saturate the router's network connection with a negligible chance of false positive. The unique value fed into the Bloom filter is the XOR of the IV and the first block so as to prevent nonsequential colluding peers in the tunnel -from tagging a message by resending it with the IV and first block switched.

          +from tagging a message by resending it with the IV and first block switched. +{%- endtrans %}

          -

          Endpoint Processing

          -

          After receiving and validating a tunnel message at the last hop in the tunnel, +

          {% trans %}Endpoint Processing{% endtrans %}

          + +

          {% trans -%} +After receiving and validating a tunnel message at the last hop in the tunnel, how the endpoint recovers the data encoded by the gateway depends upon whether the tunnel is an inbound or an outbound tunnel. For outbound tunnels, the endpoint encrypts the message with its layer key just like any other participant, exposing the preprocessed data. For inbound tunnels, the endpoint is also the tunnel creator so they can merely iteratively decrypt the IV and message, using the -layer and IV keys of each step in reverse order.

          +layer and IV keys of each step in reverse order. +{%- endtrans %}

          -

          At this point, the tunnel endpoint has the preprocessed data sent by the gateway, +

          {% trans -%} +At this point, the tunnel endpoint has the preprocessed data sent by the gateway, which it may then parse out into the included I2NP messages and forwards them as -requested in their delivery instructions.

          +requested in their delivery instructions. +{%- endtrans %}

          -

          Tunnel Building

          +

          {% trans %}Tunnel Building{% endtrans %}

          -

          When building a tunnel, the creator must send a request with the necessary +

          {% trans -%} +When building a tunnel, the creator must send a request with the necessary configuration data to each of the hops and wait for all of them to agree before enabling the tunnel. The requests are encrypted so that only the peers who need to know a piece of information (such as the tunnel layer or IV key) has that data. In addition, only the tunnel creator will have access to the peer's reply. There are three important dimensions to keep in mind when producing the tunnels: what peers are used (and where), how the requests are sent (and -replies received), and how they are maintained.

          +replies received), and how they are maintained. +{%- endtrans %}

          -

          Peer Selection

          -

          Beyond the two types of tunnels - inbound and outbound - there are two styles +

          {% trans %}Peer Selection{% endtrans %}

          + +

          {% trans -%} +Beyond the two types of tunnels - inbound and outbound - there are two styles of peer selection used for different tunnels - exploratory and client. Exploratory tunnels are used for both network database maintenance and tunnel -maintenance, while client tunnels are used for end to end client messages.

          +maintenance, while client tunnels are used for end to end client messages. +{%- endtrans %}

          -

          Exploratory tunnel peer selection

          -

          Exploratory tunnels are built out of a random selection of peers from a subset +

          {% trans %}Exploratory tunnel peer selection{% endtrans %}

          + +

          {% trans -%} +Exploratory tunnels are built out of a random selection of peers from a subset of the network. The particular subset varies on the local router and on what their tunnel routing needs are. In general, the exploratory tunnels are built out of randomly selected peers who are in the peer's "not failing but active" profile category. The secondary purpose of the tunnels, beyond merely tunnel routing, is to find underutilized high capacity peers so that they can be promoted for -use in client tunnels.

          +use in client tunnels. +{%- endtrans %}

          -

          +

          {% trans peerselection=site_url('docs/how/peer-selection') -%} Exploratory peer selection is discussed further on the -Peer Profiling and Selection page. +Peer Profiling and Selection page. +{%- endtrans %}

          -

          Client tunnel peer selection

          +

          {% trans %}Client tunnel peer selection{% endtrans %}

          -

          Client tunnels are built with a more stringent set of requirements - the local +

          {% trans -%} +Client tunnels are built with a more stringent set of requirements - the local router will select peers out of its "fast and high capacity" profile category so that performance and reliability will meet the needs of the client application. However, there are several important details beyond that basic selection that -should be adhered to, depending upon the client's anonymity needs.

          - -

          +should be adhered to, depending upon the client's anonymity needs. +{%- endtrans %}

          + +

          {% trans peerselection=site_url('docs/how/peer-selection') -%} Client peer selection is discussed further on the -Peer Profiling and Selection page. +Peer Profiling and Selection page. +{%- endtrans %}

          -

          Peer Ordering within Tunnels

          +

          {% trans %}Peer Ordering within Tunnels{% endtrans %}

          -Peers are ordered within tunnels to -to deal with the predecessor -attack (2008 -update). -

          To frustrate the predecessor +

          {% trans pdf='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf', +pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf' -%} +Peers are ordered within tunnels to deal with the +predecessor attack +(2008 update). +{%- endtrans %}

          + +

          {% trans -%} +To frustrate the predecessor attack, the tunnel selection keeps the peers selected in a strict order - if A, B, and C are in a tunnel for a particular tunnel pool, the hop after A is always B, and the hop after B is always C. +{%- endtrans %}

          -

          Ordering is implemented by generating a random 32-byte key for each +

          {% trans -%} +Ordering is implemented by generating a random 32-byte key for each tunnel pool at startup. Peers should not be able to guess the ordering, or an attacker could craft two router hashes far apart to maximize the chance of being at both ends of a tunnel. Peers are sorted by XOR distance of the SHA256 Hash of (the peer's hash concatenated with the random key) from the random key +{%- endtrans %}

                 p = peer hash
                 k = random key
                 d = XOR(H(p+k), k)
           
          -

          Because each tunnel pool uses a different random key, ordering is consistent +

          {% trans -%} +Because each tunnel pool uses a different random key, ordering is consistent within a single pool but not between different pools. New keys are generated at each router restart. +{%- endtrans %}

          -

          Request delivery

          +

          {% trans %}Request delivery{% endtrans %}

          -

          +

          {% trans pdf='http://www-users.cs.umn.edu/~hopper/hashing_it_out.pdf' -%} A multi-hop tunnel is built using a single build message which is repeatedly -decrypted and forwarded. -In the terminology of -Hashing it out in Public, +decrypted and forwarded. In the terminology of +Hashing it out in Public, this is "non-interactive" telescopic tunnel building. +{%- endtrans %}

          - -

          This tunnel request preparation, delivery, and response method is -designed to reduce the number of +

          {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%} +This tunnel request preparation, delivery, and response method is +designed to reduce the number of predecessors exposed, cuts the number of messages transmitted, verifies proper connectivity, and avoids the message counting attack of traditional telescopic tunnel creation. (This method, which sends messages to extend a tunnel through the already-established part of the tunnel, is termed "interactive" telescopic tunnel building in the "Hashing it out" paper.) +{%- endtrans %}

          -

          The details of tunnel request and response messages, and their encryption, -are specified here. +

          {% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%} +The details of tunnel request and response messages, and their encryption, +are specified here. +{%- endtrans %}

          -

          Peers may reject tunnel creation requests for a variety of reasons, though +

          {% trans -%} +Peers may reject tunnel creation requests for a variety of reasons, though a series of four increasingly severe rejections are known: probabilistic rejection (due to approaching the router's capacity, or in response to a flood of requests), transient overload, bandwidth overload, and critical failure. When received, those four are interpreted by the tunnel creator to help adjust their profile of the router in question. -

          +{%- endtrans %}

          + +

          {% trans peerselection=site_url('docs/how/peer-selection') -%} For more information on peer profiling, see the -Peer Profiling and Selection page. +Peer Profiling and Selection page. +{%- endtrans %}

          -

          Tunnel Pools

          -

          To allow efficient operation, the router maintains a series of tunnel pools, +

          {% trans %}Tunnel Pools{% endtrans %}

          + +

          {% trans i2cp=site_url('docs/spec/i2cp') -%} +To allow efficient operation, the router maintains a series of tunnel pools, each managing a group of tunnels used for a specific purpose with their own configuration. When a tunnel is needed for that purpose, the router selects one out of the appropriate pool at random. Overall, there are two exploratory tunnel pools - one inbound and one outbound - each using the router's default configuration. In addition, there is a pair of pools for each local destination - one inbound and one outbound tunnel pool. Those pools use the configuration specified -when the local destination connects to the router via I2CP, or the router's defaults if -not specified.

          +when the local destination connects to the router via I2CP, or the router's defaults if +not specified. +{%- endtrans %}

          -

          Each pool has within its configuration a few key settings, defining how many +

          {% trans i2cp=site_url('docs/spec/i2cp') -%} +Each pool has within its configuration a few key settings, defining how many tunnels to keep active, how many backup tunnels to maintain in case of failure, how long the tunnels should be, whether those lengths should be randomized, as well as any of the other settings allowed when configuring individual tunnels. -Configuration options are specified on the I2CP page. +Configuration options are specified on the I2CP page. +{%- endtrans %}

          -

          Tunnel Lengths and Defaults

          -On the tunnel overview page. +

          {% trans %}Tunnel Lengths and Defaults{% endtrans %}

          -

          Anticipatory Build Strategy and Priority

          +{% trans %}On the tunnel overview page{% endtrans %}. -

          +

          {% trans %}Anticipatory Build Strategy and Priority{% endtrans %}

          + +

          {% trans -%} Tunnel building is expensive, and tunnels expire a fixed time after they are built. However, when a pool that runs out of tunnels, the Destination is essentially dead. In addition, tunnel build success rate may vary greatly with both local and global @@ -360,8 +443,9 @@ Therefore, it is important to maintain an anticipatory, adaptive build strategy to ensure that new tunnels are successfully built before they are needed, without building an excess of tunnels, building them too soon, or consuming too much CPU or bandwidth creating and sending the encrypted build messages. -

          -

          +{%- endtrans %}

          + +

          {% trans -%} For each tuple {exploratory/client, in/out, length, length variance} the router maintains statistics on the time required for a successful tunnel build. @@ -370,19 +454,21 @@ it should start attempting to build a replacement. As the expiration time approaches without a successful replacement, it starts multiple build attempts in parallel, and then will increase the number of parallel attempts if necessary. -

          -

          +{%- endtrans %}

          + +

          {% trans -%} To cap bandwidth and CPU usage, the router also limits the maximum number of build attempts outstanding across all pools. Critical builds (those for exploratory tunnels, and for pools that have run out of tunnels) are prioritized. -

          +{%- endtrans %}

          -

          Tunnel Message Throttling

          +

          {% trans %}Tunnel Message Throttling{% endtrans %}

          -

          Even though the tunnels within I2P bear a resemblance to a circuit switched +

          {% trans -%} +Even though the tunnels within I2P bear a resemblance to a circuit switched network, everything within I2P is strictly message based - tunnels are merely accounting tricks to help organize the delivery of messages. No assumptions are made regarding reliability or ordering of messages, and retransmissions are left @@ -394,9 +480,10 @@ the averages used by other tunnels the router is participating in, and be able to accept or reject additional tunnel participation requests based on its capacity and utilization. On the other hand, each router can simply drop messages that are beyond its capacity, exploiting the research used on the -normal Internet.

          +normal Internet. +{%- endtrans %}

          -

          +

          {% trans -%} In the current implementation, routers implement a weighted random early discard (WRED) strategy. For all participating routers (internal participant, inbound gateway, and outbound endpoint), @@ -410,31 +497,36 @@ Larger messages are more likely to be dropped. Also, messages are more likely to be dropped at the outbound endpoint than the inbound gateway, as those messages are not as "far along" in their journey and thus the network cost of dropping those messages is lower. -

          +{%- endtrans %}

          -

          Future Work

          -

          Mixing/batching

          +

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

          +

          {% trans %}Mixing/batching{% endtrans %}

          -

          What strategies could be used at the gateway and at each hop for delaying, +

          {% trans -%} +What strategies could be used at the gateway and at each hop for delaying, reordering, rerouting, or padding messages? To what extent should this be done automatically, how much should be configured as a per tunnel or per hop setting, and how should the tunnel's creator (and in turn, user) control this operation? All of this is left as unknown, to be worked out for a distant future release. +{%- endtrans %}

          -

          Padding

          -

          The padding strategies can be used on a variety of levels, addressing the +

          {% trans %}Padding{% endtrans %}

          +

          {% trans -%} +The padding strategies can be used on a variety of levels, addressing the exposure of message size information to different adversaries. The current fixed tunnel message size is 1024 bytes. Within this however, the fragmented messages themselves are not padded by the tunnel at all, though for end to end -messages, they may be padded as part of the garlic wrapping.

          +messages, they may be padded as part of the garlic wrapping. +{%- endtrans %}

          +

          WRED

          -

          +

          {% trans -%} WRED strategies have a significant impact on end-to-end performance, and prevention of network congestion collapse. The current WRED strategy should be carefully evaluated and improved. -

          +{%- endtrans %}

          {% endblock %} diff --git a/i2p2www/pages/site/docs/tunnels/old-implementation.html b/i2p2www/pages/site/docs/tunnels/old-implementation.html index d5f33d5d..f4ad6217 100644 --- a/i2p2www/pages/site/docs/tunnels/old-implementation.html +++ b/i2p2www/pages/site/docs/tunnels/old-implementation.html @@ -1,8 +1,10 @@ {% extends "global/layout.html" %} -{% block title %}Old Tunnel Implementation{% endblock %} +{% block title %}{% trans %}Old Tunnel Implementation{% endtrans %}{% endblock %} {% block content %} -Note: Obsolete - NOT used! Replaced in 0.6.1.10 - see tunnel-alt.html for the current implementation +{% trans tunnelimpl=site_url('docs/tunnels/implementation') -%} +Note: Obsolete - NOT used! Replaced in 0.6.1.10 - see here for the current implementation +{%- endtrans %}
           1) Tunnel overview
          diff --git a/i2p2www/pages/site/docs/tunnels/unidirectional.html b/i2p2www/pages/site/docs/tunnels/unidirectional.html
          index f4f5004b..e913e321 100644
          --- a/i2p2www/pages/site/docs/tunnels/unidirectional.html
          +++ b/i2p2www/pages/site/docs/tunnels/unidirectional.html
          @@ -1,32 +1,33 @@
           {% extends "global/layout.html" %}
          -{% block title %}Unidirectional Tunnels{% endblock %}
          -{% block lastupdated %}July 2011{% endblock %}
          +{% block title %}{% trans %}Unidirectional Tunnels{% endtrans %}{% endblock %}
          +{% block lastupdated %}{% trans %}July 2011{% endtrans %}{% endblock %}
           {% block accuratefor %}0.8.7{% endblock %}
           {% block content %}
          -

          Overview

          -

          +

          {% trans %}Overview{% endtrans %}

          +

          {% trans -%} This page describes the origins and design of I2P's unidirectional tunnels. For further infomrmation see: +{%- endtrans %}

          -

          Review

          +

          {% trans %}Review{% endtrans %}

          -

          +

          {% trans -%} While we aren't aware of any published research on the advantages of unidirecdtional tunnels, they appear to make it harder to detect a @@ -39,17 +40,19 @@ attacker who has only timing and traffic volume data to infer the path a tunnel is taking. Having the response come back along a different path arguably makes it harder. +{%- endtrans %}

          -

          - When dealing with - an internal adversary or most external adversaries, I2P's undirectional tunnels - expose half as much traffic data than would be exposed with bidirectional circuits - by simply looking at the flows themselves - an HTTP request and response would - follow the same path in Tor, while in I2P the packets making up the request - would go out through one or more outbound tunnels and the packets making up - the response would come back through one or more different inbound tunnels. +

          {% trans -%} +When dealing with +an internal adversary or most external adversaries, I2P's undirectional tunnels +expose half as much traffic data than would be exposed with bidirectional circuits +by simply looking at the flows themselves - an HTTP request and response would +follow the same path in Tor, while in I2P the packets making up the request +would go out through one or more outbound tunnels and the packets making up +the response would come back through one or more different inbound tunnels. +{%- endtrans %}

          -

          +

          {% trans -%} The strategy of using two separate tunnels for inbound and outbound communication is not the only technique available, and it does have anonymity implications. On the positive side, by using separate tunnels it lessens the @@ -64,51 +67,57 @@ additional care must be taken to address the increased speed of predecessor attacks. The tunnel pooling and building process (peer selection and ordering strategies) should minimize the worries of the predecessor attack. - -

          +{%- endtrans %}

          -

          Anonymity

          +

          {% trans %}Anonymity{% endtrans %}

          -

          -A recent -paper by Hermann and Grothoff +

          {% trans pdf='http://grothoff.org/christian/i2p.pdf' -%} +A recent paper by Hermann and Grothoff declared that I2P's unidirectional tunnels "seems to be a bad design decision". +{%- endtrans %}

          +

          {% trans -%} The paper's main point is that deanonymizations on unidirectional tunnels take a longer time, which is an advantage, but that an attacker can be more certain in the unidirectional case. Therefore, the paper claims it isn't an advantage at all, but a disadvantage, at least with long-living eepsites. +{%- endtrans %}

          -

          +

          {% trans -%} This conclusion is not fully supported by the paper. Unidirectional tunnels clearly mitigate other attacks and it's not clear how to trade off the risk of the attack in the paper with attacks on a bidirectional tunnel architecture. +{%- endtrans %}

          -

          +

          {% trans -%} This conclusion is based on an arbitrary certainty vs. time weighting (tradeoff) that may not be applicable in all cases. For example, somebody could make a list of possible IPs then issue subpoenas to each. Or the attacker could DDoS each in turn and via a simple intersection attack see if the eepsite goes down or is slowed down. So close may be good enough, or time may be more important. +{%- endtrans %}

          +

          {% trans -%} The conclusion is based on a specific weighting of the importance of certainty vs. time, and that weighting may be wrong, and it's definitely debatable, especially in a real world with subpoenas, search warrants, and other methods available for final confirmation. +{%- endtrans %}

          -

          +

          {% trans -%} A full analysis of the tradeoffs of unidirectional vs. bidirectional tunnels is clearly outside the scope of the paper, and has not been done elsewhere. For example, how does this attack compare to the numerous possible timing attacks published about onion-routed networks? Clearly the authors have not done that analysis, if it's even possible to do it effectively. +{%- endtrans %}

          -

          +

          {% trans -%} Tor uses bidirectional tunnels and has had a lot of academic review. I2P uses unidirectional tunnels and has had very little review. Does the lack of a research paper defending unidirectional tunnels mean that it is a poor design @@ -123,14 +132,14 @@ clearly needs further investigation and analysis? There are several other reason to consider I2P currently inferior to Tor and other projects (small network size, lack of funding, lack of review) but is unidirectional tunnels really a reason? +{%- endtrans %}

          -

          +

          {% trans -%} In summary, "bad design decision" is apparently (since the paper does not label bidirectional tunnels "bad") shorthand for "unidirectional tunnels are unequivocally inferior to bidirectional tunnels", yet this conclusion is not supported by the paper. - -

          +{%- endtrans %}

          {% endblock %} From ca0f74e9babcd28a117d460981367a0d23a19d54 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 01:20:52 +0000 Subject: [PATCH 385/498] Removed stray } --- i2p2www/pages/blog/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/i2p2www/pages/blog/index.html b/i2p2www/pages/blog/index.html index a95e4c1c..c417a067 100644 --- a/i2p2www/pages/blog/index.html +++ b/i2p2www/pages/blog/index.html @@ -1,5 +1,5 @@ {% extends "global/layout.html" %} -{% block title %}{{ _('Blog Index') }}}{% endblock %} +{% block title %}{{ _('Blog Index') }}{% endblock %} {% block headextra %} {%- endblock %} From 508c6f1e8074527f01047ea6f40c3115d7191e1f Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 01:40:47 +0000 Subject: [PATCH 386/498] Render categories properly --- i2p2www/pages/blog/post.html | 3 ++- i2p2www/pages/global/macros | 7 +++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/i2p2www/pages/blog/post.html b/i2p2www/pages/blog/post.html index 22ed3c3d..07b7de72 100644 --- a/i2p2www/pages/blog/post.html +++ b/i2p2www/pages/blog/post.html @@ -1,10 +1,11 @@ {% extends "global/layout.html" %} +{%- from "global/macros" import render_categories with context -%} {% block title %}{{ title }} - {{ _('Blog') }}{% endblock %} {% block content %}
          • {{ meta.date }}
          • {{ meta.author }}
          • -
          • {{ meta.category }}
          • +
          • {{ render_categories(meta.category)|safe }}
          {% autoescape false %} {{ body }} diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index 756ddf75..2bd426c9 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -31,3 +31,10 @@ {%- endif %}
        {%- endmacro -%} + +{%- macro render_categories(categories) -%} +{%- if categories and categories|length %} +{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} +{%- else %}{{ _('None') }} +{%- endif %} +{%- endmacro %} From 535e2f41b0a2b0c0ead2fea884a54b4f14d0ae62 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 02:17:41 +0000 Subject: [PATCH 387/498] Added category view for blog posts --- i2p2www/blog/views.py | 10 ++++++++++ i2p2www/pages/blog/category.html | 4 ++++ i2p2www/pages/global/macros | 3 ++- i2p2www/urls.py | 2 ++ 4 files changed, 18 insertions(+), 1 deletion(-) create mode 100644 i2p2www/pages/blog/category.html diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index b15b48b2..b5ce5a7e 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -18,6 +18,16 @@ def blog_index(page): pagination = Pagination(page, BLOG_POSTS_PER_PAGE, len(all_posts)) return render_template('blog/index.html', pagination=pagination, posts=posts) +@cache.memoize(600) +def blog_category(category, page): + posts = get_blog_posts() + category_posts = [(slug, post) for (slug, post) in posts if post['category'] and category in post['category']] + posts = get_for_page(category_posts, page, BLOG_POSTS_PER_PAGE) + if not posts and page != 1: + abort(404) + pagination = Pagination(page, BLOG_POSTS_PER_PAGE, len(category_posts)) + return render_template('blog/category.html', pagination=pagination, posts=posts, category=category) + @cache.memoize(600) def blog_post(slug): # try to render that blog post.. throws 404 if it does not exist diff --git a/i2p2www/pages/blog/category.html b/i2p2www/pages/blog/category.html new file mode 100644 index 00000000..e81a7b8d --- /dev/null +++ b/i2p2www/pages/blog/category.html @@ -0,0 +1,4 @@ +{% extends "blog/index.html" %} +{% block title %}{{ _('Blog Category') }}: {{ category }}{% endblock %} +{% block headextra %} +{%- endblock %} diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index 2bd426c9..aea4273b 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -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_category' -%}{{ url_for('blog_category', lang=lang, category=category) }} {%- elif request.endpoint == 'blog_post' -%}{{ url_for('blog_post', lang=lang, slug=slug) }} {%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }} {%- elif request.endpoint == 'downloads_select' -%}{{ url_for('downloads_select', lang=lang, file=file) }} @@ -34,7 +35,7 @@ {%- macro render_categories(categories) -%} {%- if categories and categories|length %} -{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} +{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} {%- else %}{{ _('None') }} {%- endif %} {%- endmacro %} diff --git a/i2p2www/urls.py b/i2p2www/urls.py index 7e0921d5..a27833fb 100644 --- a/i2p2www/urls.py +++ b/i2p2www/urls.py @@ -40,6 +40,8 @@ url('//', 'views.site_show') url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) url('//blog/page/', 'blog.views.blog_index') +url('//blog/category/', 'blog.views.blog_category', defaults={'page': 1}) +url('//blog/category//page/', 'blog.views.blog_category') url('//blog/post/', 'blog.views.blog_post') url('//feed/blog/rss', 'blog.views.blog_rss') url('//feed/blog/atom', 'blog.views.blog_atom') From f32b6e3c14292c5a280882bd3d1c5a40796e335c Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 02:24:05 +0000 Subject: [PATCH 388/498] Refactor blog category post selection --- i2p2www/blog/helpers.py | 11 ++++++----- i2p2www/blog/views.py | 3 +-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/i2p2www/blog/helpers.py b/i2p2www/blog/helpers.py index d5a72d41..0122385f 100644 --- a/i2p2www/blog/helpers.py +++ b/i2p2www/blog/helpers.py @@ -37,7 +37,7 @@ def get_blog_feed_items(num=0): items.append(a) return items -def get_blog_posts(num=0, return_parts=False): +def get_blog_posts(num=0, return_parts=False, category=None): """ Returns the latest #num valid posts sorted by date, or all slugs if num=0. """ @@ -49,10 +49,11 @@ def get_blog_posts(num=0, return_parts=False): meta = get_metadata_from_meta(parts['meta']) meta['date'] = meta['date'] if meta['date'] else get_date_from_slug(slug) meta['title'] = parts['title'] - if return_parts: - posts.append((slug, meta, parts)) - else: - posts.append((slug, meta)) + if not category or (meta['category'] and category in meta['category']): + if return_parts: + posts.append((slug, meta, parts)) + else: + posts.append((slug, meta)) return posts def get_blog_slugs(num=0): diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index b5ce5a7e..8e6e36d0 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -20,8 +20,7 @@ def blog_index(page): @cache.memoize(600) def blog_category(category, page): - posts = get_blog_posts() - category_posts = [(slug, post) for (slug, post) in posts if post['category'] and category in post['category']] + category_posts = get_blog_posts(category=category) posts = get_for_page(category_posts, page, BLOG_POSTS_PER_PAGE) if not posts and page != 1: abort(404) From 55af9d11b39a16f408392b963fc0c7ba5f0dd700 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 02:53:58 +0000 Subject: [PATCH 389/498] Add category support to the Atom feed --- i2p2www/blog/helpers.py | 4 ++-- i2p2www/blog/views.py | 10 ++++++---- i2p2www/pages/blog/category.html | 1 + i2p2www/urls.py | 1 + 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/i2p2www/blog/helpers.py b/i2p2www/blog/helpers.py index 0122385f..f5989720 100644 --- a/i2p2www/blog/helpers.py +++ b/i2p2www/blog/helpers.py @@ -23,8 +23,8 @@ LIST_METATAGS = [ ##################### # Blog helper methods -def get_blog_feed_items(num=0): - posts = get_blog_posts(num, True) +def get_blog_feed_items(num=0, category=None): + posts = get_blog_posts(num, True, category=category) items = [] for post in posts: meta = post[1] diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index 8e6e36d0..cdef7765 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -45,10 +45,12 @@ def blog_rss(): pass @cache.cached(600) -def blog_atom(): - # TODO: Only output beginning of each blog post - feed = AtomFeed('I2P Blog', feed_url=request.url, url=request.url_root) - items = get_blog_feed_items(10) +def blog_atom(category=None): + feed_title = 'I2P Blog' + if category: + feed_title = 'I2P Blog Category: %s' % category + feed = AtomFeed(feed_title, feed_url=request.url, url=request.url_root) + items = get_blog_feed_items(10, category=category) for item in items: feed.add(item['title'], item['content'], diff --git a/i2p2www/pages/blog/category.html b/i2p2www/pages/blog/category.html index e81a7b8d..9cd89583 100644 --- a/i2p2www/pages/blog/category.html +++ b/i2p2www/pages/blog/category.html @@ -1,4 +1,5 @@ {% extends "blog/index.html" %} {% block title %}{{ _('Blog Category') }}: {{ category }}{% endblock %} {% block headextra %} + {%- endblock %} diff --git a/i2p2www/urls.py b/i2p2www/urls.py index a27833fb..9008d09b 100644 --- a/i2p2www/urls.py +++ b/i2p2www/urls.py @@ -45,6 +45,7 @@ url('//blog/category//page/', 'blog.views. url('//blog/post/', 'blog.views.blog_post') url('//feed/blog/rss', 'blog.views.blog_rss') url('//feed/blog/atom', 'blog.views.blog_atom') +url('//feed/blog/category//atom', 'blog.views.blog_atom') url('//meetings/', 'meetings.views.meetings_index', defaults={'page': 1}) url('//meetings/page/', 'meetings.views.meetings_index') From 1be4ea4943677e0380740d5f79a78603618596e9 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 02:58:55 +0000 Subject: [PATCH 390/498] Merge blog_index and blog_category views --- i2p2www/blog/views.py | 18 ++++++------------ i2p2www/pages/global/macros | 7 +++++-- i2p2www/urls.py | 4 ++-- 3 files changed, 13 insertions(+), 16 deletions(-) diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index cdef7765..c7a890d8 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -10,22 +10,16 @@ from i2p2www.helpers import Pagination, get_for_page # Blog views @cache.memoize(600) -def blog_index(page): - all_posts = get_blog_posts() +def blog_index(page, category=None): + all_posts = get_blog_posts(category=category) posts = get_for_page(all_posts, page, BLOG_POSTS_PER_PAGE) if not posts and page != 1: abort(404) pagination = Pagination(page, BLOG_POSTS_PER_PAGE, len(all_posts)) - return render_template('blog/index.html', pagination=pagination, posts=posts) - -@cache.memoize(600) -def blog_category(category, page): - category_posts = get_blog_posts(category=category) - posts = get_for_page(category_posts, page, BLOG_POSTS_PER_PAGE) - if not posts and page != 1: - abort(404) - pagination = Pagination(page, BLOG_POSTS_PER_PAGE, len(category_posts)) - return render_template('blog/category.html', pagination=pagination, posts=posts, category=category) + if category: + return render_template('blog/category.html', pagination=pagination, posts=posts, category=category) + else: + return render_template('blog/index.html', pagination=pagination, posts=posts) @cache.memoize(600) def blog_post(slug): diff --git a/i2p2www/pages/global/macros b/i2p2www/pages/global/macros index aea4273b..49642f19 100644 --- a/i2p2www/pages/global/macros +++ b/i2p2www/pages/global/macros @@ -1,6 +1,9 @@ {%- macro change_lang(lang) -%} {%- if request.endpoint == 'site_show' -%}{{ url_for('site_show', lang=lang, page=page) }} -{%- elif request.endpoint == 'blog_category' -%}{{ url_for('blog_category', lang=lang, category=category) }} +{%- elif request.endpoint == 'blog_index' -%} + {%- if category -%}{{ url_for('blog_index', lang=lang, category=category) }} + {%- else -%}{{ url_for('blog_index', lang=lang) }} + {%- endif -%} {%- elif request.endpoint == 'blog_post' -%}{{ url_for('blog_post', lang=lang, slug=slug) }} {%- elif request.endpoint == 'meetings_show' -%}{{ url_for('meetings_show', lang=lang, id=id) }} {%- elif request.endpoint == 'downloads_select' -%}{{ url_for('downloads_select', lang=lang, file=file) }} @@ -35,7 +38,7 @@ {%- macro render_categories(categories) -%} {%- if categories and categories|length %} -{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} +{%- for category in categories %}{{ category }}{% if not loop.last %}, {% endif %}{% endfor %} {%- else %}{{ _('None') }} {%- endif %} {%- endmacro %} diff --git a/i2p2www/urls.py b/i2p2www/urls.py index 9008d09b..e9127f33 100644 --- a/i2p2www/urls.py +++ b/i2p2www/urls.py @@ -40,8 +40,8 @@ url('//', 'views.site_show') url('//blog/', 'blog.views.blog_index', defaults={'page': 1}) url('//blog/page/', 'blog.views.blog_index') -url('//blog/category/', 'blog.views.blog_category', defaults={'page': 1}) -url('//blog/category//page/', 'blog.views.blog_category') +url('//blog/category/', 'blog.views.blog_index', defaults={'page': 1}) +url('//blog/category//page/', 'blog.views.blog_index') url('//blog/post/', 'blog.views.blog_post') url('//feed/blog/rss', 'blog.views.blog_rss') url('//feed/blog/atom', 'blog.views.blog_atom') From de4e51e0b67a763fa8c7ebfd652716854cea0a01 Mon Sep 17 00:00:00 2001 From: str4d Date: Sun, 3 Feb 2013 03:12:31 +0000 Subject: [PATCH 391/498] Factor out blog posts per feed as a constant, halve number of blog posts per page --- i2p2www/__init__.py | 3 ++- i2p2www/blog/views.py | 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/i2p2www/__init__.py b/i2p2www/__init__.py index ac3a4739..d7f9ec1b 100644 --- a/i2p2www/__init__.py +++ b/i2p2www/__init__.py @@ -13,7 +13,8 @@ CURRENT_I2P_VERSION = '0.9.4' CANONICAL_DOMAIN = 'www.i2p2.de' -BLOG_POSTS_PER_PAGE = 20 +BLOG_POSTS_PER_FEED = 10 +BLOG_POSTS_PER_PAGE = 10 MEETINGS_PER_PAGE = 20 SUPPORTED_LANGS = [ diff --git a/i2p2www/blog/views.py b/i2p2www/blog/views.py index c7a890d8..9a1c8b61 100644 --- a/i2p2www/blog/views.py +++ b/i2p2www/blog/views.py @@ -1,7 +1,7 @@ from flask import abort, render_template, request from werkzeug.contrib.atom import AtomFeed -from i2p2www import BLOG_POSTS_PER_PAGE, cache +from i2p2www import BLOG_POSTS_PER_FEED, BLOG_POSTS_PER_PAGE, cache from i2p2www.blog.helpers import get_blog_posts, get_blog_feed_items, get_date_from_slug, get_metadata_from_meta, render_blog_post from i2p2www.helpers import Pagination, get_for_page @@ -44,7 +44,7 @@ def blog_atom(category=None): if category: feed_title = 'I2P Blog Category: %s' % category feed = AtomFeed(feed_title, feed_url=request.url, url=request.url_root) - items = get_blog_feed_items(10, category=category) + items = get_blog_feed_items(BLOG_POSTS_PER_FEED, category=category) for item in items: feed.add(item['title'], item['content'], From ad0f759014da8dcc717aec2765de00fa000b089b Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 5 Feb 2013 02:09:57 +0000 Subject: [PATCH 392/498] Added translation tags to docs/protocol/* --- i2p2www/pages/site/docs/protocol/i2cp.html | 738 +++++++++++++++----- i2p2www/pages/site/docs/protocol/i2np.html | 156 +++-- i2p2www/pages/site/docs/protocol/index.html | 99 +-- 3 files changed, 745 insertions(+), 248 deletions(-) diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html index 26eeca40..00f4eb96 100644 --- a/i2p2www/pages/site/docs/protocol/i2cp.html +++ b/i2p2www/pages/site/docs/protocol/i2cp.html @@ -1,9 +1,10 @@ {% extends "global/layout.html" %} {% block title %}I2CP{% endblock %} -{% block lastupdated %}November 2012{% endblock %} +{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9.3{% endblock %} {% block content %} -

        The I2P Client Protocol (I2CP) exposes a strong separation of concerns between +

        {% trans -%} +The I2P Client Protocol (I2CP) exposes a strong separation of concerns between the router and any client that wishes to communicate over the network. It enables secure and asynchronous messaging by sending and receiving messages over a single TCP socket, yet never exposing any private keys and authenticating itself @@ -12,194 +13,580 @@ router who they are (their "destination"), what anonymity, reliability, and latency tradeoffs to make, and where to send messages. In turn the router uses I2CP to tell the client when any messages have arrived, and to request authorization for some tunnels to be used. -

        +{%- endtrans %}

        -

        +

        {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/client/package-summary.html' -%} The protocol itself has only been implemented in Java, to provide the -Client SDK. +Client SDK. This SDK is exposed in the i2p.jar package, which implements the client-side of I2CP. Clients should never need to access the router.jar package, which contains the router itself and the router-side of I2CP. -

        +{%- endtrans %}

        -

        +

        {% trans streaming=site_url('docs/api/streaming') -%} While implementing the client side of I2CP in a non-Java language is certainly feasible, a non-Java client would also have to implement the -streaming library for TCP-style connections. +streaming library for TCP-style connections. Together, implementing I2CP and the streaming library would be a sizable task. -

        +{%- endtrans %}

        -

        +

        {% trans streaming=site_url('docs/api/streaming'), datagrams=site_url('docs/spec/datagrams'), +sam=site_url('docs/api/sam'), bob=site_url('docs/api/bob') -%} Applications can take advantage of the base I2CP plus the -streaming and datagram libraries -by using the Simple Anonymous Messaging or BOB protocols, +streaming and datagram libraries +by using the Simple Anonymous Messaging or BOB protocols, which do not require clients to deal with any sort of cryptography. Also, clients may access the network by one of several proxies - HTTP, CONNECT, and SOCKS 4/4a/5. Alternatively, Java clients may access those libraries in ministreaming.jar and streaming.jar. So there are several options for both Java and non-Java applications. -

        +{%- endtrans %}

        -

        Client-side end-to-end encryption (encrypting the data over the I2CP connection) +

        {% trans elgamalaes=site_url('docs/how/elgamal-aes'), +cryptography=site_url('docs/how/cryptography'), +i2cp=site_url('docs/spec/i2cp') -%} +Client-side end-to-end encryption (encrypting the data over the I2CP connection) was disabled in I2P release 0.6, -leaving in place the ElGamal/AES end-to-end encryption +leaving in place the ElGamal/AES end-to-end encryption which is implemented in the router. The only cryptography that client libraries must still implement is -DSA public/private key signing -for LeaseSets and -Session Configurations, and management of those keys. -

        +DSA public/private key signing +for LeaseSets and +Session Configurations, and management of those keys. +{%- endtrans %}

        -

        In a standard I2P installation, port 7654 is used by external java clients to communicate +

        {% trans -%} +In a standard I2P installation, port 7654 is used by external java clients to communicate with the local router via I2CP. By default, the router binds to address 127.0.0.1. To bind to 0.0.0.0, set the router advanced configuration option i2cp.tcp.bindAllInterfaces=true and restart. Clients in the same JVM as the router pass messages directly to the router through an internal JVM interface. -

        +{%- endtrans %}

        -

        I2CP Protocol Specification

        -

        -Now on the -I2CP Specification page. -

        +

        {% trans %}I2CP Protocol Specification{% endtrans %}

        +

        {% trans i2cp=site_url('docs/spec/i2cp') -%} +Now on the I2CP Specification page. +{%- endtrans %}

        -

        I2CP Initialization

        -

        +

        {% trans %}I2CP Initialization{% endtrans %}

        +

        {% trans i2cp=site_url('docs/spec/i2cp') -%} When a client connects to the router, it first sends a single protocol version byte (0x2A). -Then it sends a GetDate Message and waits for the SetDate Message response. -Next, it sends a CreateSession Message containing the session configuration. -It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels +Then it sends a GetDate Message and waits for the SetDate Message response. +Next, it sends a CreateSession Message containing the session configuration. +It next awaits a RequestLeaseSet Message from the router, indicating that inbound tunnels have been built, and responds with a CreateLeaseSetMessage containing the signed LeaseSet. The client may now initiate or receive connections from other I2P destinations. +{%- endtrans %}

        -

        I2CP Options

        -

        +

        {% trans %}I2CP Options{% endtrans %}

        +

        {% trans i2cp=site_url('docs/spec/i2cp') -%} The following options are traditionally passed to the router via -a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message. -

        +a SessionConfig contained in a CreateSession Message or a ReconfigureSession Message. +{%- endtrans %}

        - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Router-side Options
        Option Recommended Arguments Allowable RangeDefaultDescription -
        inbound.quantity number from 1 to 3 1 to 162Number of tunnels in. - Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not - currently recommended, as this is untested and is incompatible with older releases. -
        outbound.quantity number from 1 to 3 No limit2Number of tunnels out -
        inbound.length number from 0 to 3 0 to 72Length of tunnels in -
        outbound.length number from 0 to 3 0 to 72Length of tunnels out -
        inbound.lengthVariance number from -1 to 2 -7 to 70Random amount to add or subtract to the length of tunnels in. - A positive number x means add a random amount from 0 to x inclusive. - A negative number -x means add a random amount from -x to x inclusive. - The router will limit the total length of the tunnel to 0 to 7 inclusive. - The default variance was 1 prior to release 0.7.6. -
        outbound.lengthVariance number from -1 to 2 -7 to 70Random amount to add or subtract to the length of tunnels out. - A positive number x means add a random amount from 0 to x inclusive. - A negative number -x means add a random amount from -x to x inclusive. - The router will limit the total length of the tunnel to 0 to 7 inclusive. - The default variance was 1 prior to release 0.7.6. -
        inbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels in -
        outbound.backupQuantity number from 0 to 3 No limit0Number of redundant fail-over for tunnels out -
        inbound.nickname string  Name of tunnel - generally used in routerconsole, which will - use the first few characters of the Base64 hash of the destination by default. -
        outbound.nickname string  Name of tunnel - generally ignored unless inbound.nickname is unset. -
        inbound.allowZeroHop true, false trueIf incoming zero hop tunnel is allowed -
        outbound.allowZeroHop true, false trueIf outgoing zero hop tunnel is allowed -
        inbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if - two routers should not be in the same tunnel. 0 to disable. -
        outbound.IPRestriction number from 0 to 4 0 to 42Number of IP bytes to match to determine if - two routers should not be in the same tunnel. 0 to disable. -
        outbound.prioritynumber from -25 to 25 -25 to 250Priority adjustment for outbound messages. - Higher is higher priority. As of 0.9.4. -
        i2cp.dontPublishLeaseSet true, false falseShould generally be set to true for clients - and false for servers -
        i2cp.messageReliability  BestEffort, NoneBestEffortGuaranteed is disabled; - None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4 -
        i2cp.fastReceive true, falsefalseIf true, the router just sends the MessagePayload instead - of sending a MessageStatus and awaiting a ReceiveMessageBegin. - As of 0.9.4 -
        explicitPeers  nullComma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only -
        i2cp.usernamestring  For authorization, if required by the router (since 0.8.2). - If the client is running in the same JVM as a router, this option is not required. -
        i2cp.passwordstring  For authorization, if required by the router (since 0.8.2). - If the client is running in the same JVM as a router, this option is not required. -
        crypto.tagsToSend 1-12840Number of ElGamal/AES Session Tags to send at a time (since 0.9.2). - For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower. -
        crypto.lowTagThreshold 1-12830Minimum number of ElGamal/AES Session Tags before we send more (since 0.9.2). - Recommended: approximately tagsToSend * 2/3 -
        shouldBundleReplyInfotrue, false trueSet to false to disable ever bundling a reply LeaseSet (since 0.9.2). - For clients that do not publish their LeaseSet, this option must be true - for any reply to be possible. "true" is also recommended for multihomed servers - with long connection times. +
        {% trans %}Router-side Options{% endtrans %}
        {% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
        inbound.quantity {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=1, to=16 %}{{ from }} to {{ to }}{% endtrans %}2{% trans -%} +Number of tunnels in. +Limit was increased from 6 to 16 in release 0.9; however, numbers higher than 6 are not +currently recommended, as this is untested and is incompatible with older releases. +{%- endtrans %}
        outbound.quantity + {% trans from=1, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}2 +{% trans %}Number of tunnels out{% endtrans %}
        inbound.length + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans %}Length of tunnels in{% endtrans %}
        outbound.length + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=7 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans %}Length of tunnels out{% endtrans %}
        inbound.lengthVariance + {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0 +{% trans -%} +Random amount to add or subtract to the length of tunnels in. +A positive number x means add a random amount from 0 to x inclusive. +A negative number -x means add a random amount from -x to x inclusive. +The router will limit the total length of the tunnel to 0 to 7 inclusive. +The default variance was 1 prior to release 0.7.6. +{%- endtrans %}
        outbound.lengthVariance + {% trans from=-1, to=2 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-7, to=7 %}{{ from }} to {{ to }}{% endtrans %}0 +{% trans -%} +Random amount to add or subtract to the length of tunnels out. +A positive number x means add a random amount from 0 to x inclusive. +A negative number -x means add a random amount from -x to x inclusive. +The router will limit the total length of the tunnel to 0 to 7 inclusive. +The default variance was 1 prior to release 0.7.6. +{%- endtrans %}
        inbound.backupQuantity + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0 +{% trans %}Number of redundant fail-over for tunnels in{% endtrans %}
        outbound.backupQuantity + {% trans from=0, to=3 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans %}No limit{% endtrans %}0 +{% trans %}Number of redundant fail-over for tunnels out{% endtrans %}
        inbound.nickname + string +  +  +{% trans -%} +Name of tunnel - generally used in routerconsole, which will +use the first few characters of the Base64 hash of the destination by default. +{%- endtrans %}
        outbound.nickname + string +  +  +{% trans %}Name of tunnel - generally ignored unless inbound.nickname is unset.{% endtrans %}
        inbound.allowZeroHop + true, false +  +true +{% trans %}If incoming zero hop tunnel is allowed{% endtrans %}
        outbound.allowZeroHop + true, false +  +true +{% trans %}If outgoing zero hop tunnel is allowed{% endtrans %}
        inbound.IPRestriction + {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans -%} +Number of IP bytes to match to determine if +two routers should not be in the same tunnel. 0 to disable. +{%- endtrans %}
        outbound.IPRestriction + {% trans from=0, to=4 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=0, to=4 %}{{ from }} to {{ to }}{% endtrans %}2 +{% trans -%} +Number of IP bytes to match to determine if +two routers should not be in the same tunnel. 0 to disable. +{%- endtrans %}
        outbound.priority +0.9.4{% trans from=-25, to=25 %}number from {{ from }} to {{ to }}{% endtrans %}{% trans from=-25, to=25 %}{{ from }} to {{ to }}{% endtrans %}0 +{% trans -%} +Priority adjustment for outbound messages. +Higher is higher priority. +{%- endtrans %}
        i2cp.dontPublishLeaseSet + true, false +  +false +{% trans %}Should generally be set to true for clients and false for servers{% endtrans %}
        i2cp.messageReliability +   +BestEffort, None +BestEffort +{% trans -%} +Guaranteed is disabled; +None implemented in 0.8.1; the streaming lib default is None as of 0.8.1, the client side default is None as of 0.9.4 +{%- endtrans %}
        i2cp.fastReceive +0.9.4  +true, false +false +{% trans -%} +If true, the router just sends the MessagePayload instead +of sending a MessageStatus and awaiting a ReceiveMessageBegin. +{%- endtrans %}
        explicitPeers +   +  +null +{% trans %}Comma-separated list of Base 64 Hashes of peers to build tunnels through; for debugging only{% endtrans %}
        i2cp.username +0.8.2string +  +  +{% trans -%} +For authorization, if required by the router. +If the client is running in the same JVM as a router, this option is not required. +{%- endtrans %}
        i2cp.password +0.8.2string +  +  +{% trans -%} +For authorization, if required by the router. +If the client is running in the same JVM as a router, this option is not required. +{%- endtrans %}
        crypto.tagsToSend +0.9.2  +1-128 +40 +{% trans -%} +Number of ElGamal/AES Session Tags to send at a time. +For clients with relatively low bandwidth per-client-pair (IRC, some UDP apps), this may be set lower. +{%- endtrans %}
        crypto.lowTagThreshold +0.9.2  +1-128 +30 +{% trans -%} +Minimum number of ElGamal/AES Session Tags before we send more. +Recommended: approximately tagsToSend * 2/3 +{%- endtrans %}
        shouldBundleReplyInfo +0.9.2true, false +  +true +{% trans -%} +Set to false to disable ever bundling a reply LeaseSet. +For clients that do not publish their LeaseSet, this option must be true +for any reply to be possible. "true" is also recommended for multihomed servers +with long connection times. +{%- endtrans %} -

        Setting to "false" may save significant outbound bandwidth, especially if - the client is configured with a large number of inbound tunnels (Leases). - If replies are still required, this may shift the bandwidth burden to - the far-end client and the floodfill. - There are several cases where "false" may be appropriate: -

        • - Unidirectional communication, no reply required -
        • - LeaseSet is published and higher reply latency is acceptable -
        • - LeaseSet is published, client is a "server", all connections are inbound - so the connecting far-end destination obviously has the leaseset already. - Connections are either short, or it is acceptable for latency on a long-lived - connection to temporarily increase while the other end re-fetches the LeaseSet - after expiration. - HTTP servers may fit these requirements. -
        -
        inbound.*   Any other options prefixed with "inbound." are stored - in the "unknown options" properties of the inbound tunnel pool's settings. -
        outbound.*   Any other options prefixed with "outbound." are stored - in the "unknown options" properties of the outbound tunnel pool's settings. +

        {% trans -%} +Setting to "false" may save significant outbound bandwidth, especially if +the client is configured with a large number of inbound tunnels (Leases). +If replies are still required, this may shift the bandwidth burden to +the far-end client and the floodfill. +There are several cases where "false" may be appropriate: +{%- endtrans %}

        +
          +
        • {% trans %}Unidirectional communication, no reply required{% endtrans %}
        • +
        • {% trans %}LeaseSet is published and higher reply latency is acceptable{% endtrans %}
        • +
        • {% trans -%} +LeaseSet is published, client is a "server", all connections are inbound +so the connecting far-end destination obviously has the leaseset already. +Connections are either short, or it is acceptable for latency on a long-lived +connection to temporarily increase while the other end re-fetches the LeaseSet +after expiration. +HTTP servers may fit these requirements. +{%- endtrans %}
        • +
        +
        inbound.* +   +  +  +{% trans -%} +Any other options prefixed with "inbound." are stored +in the "unknown options" properties of the inbound tunnel pool's settings. +{%- endtrans %}
        outbound.* +   +  +  +{% trans -%} +Any other options prefixed with "outbound." are stored +in the "unknown options" properties of the outbound tunnel pool's settings. +{%- endtrans %}
        -

        + +

        {% trans -%} Note: Large quantity, length, or variance settings may cause significant performance or reliability problems. -

        +{%- endtrans %}

        + +

        {% trans -%} Note: As of release 0.7.7, option names and values must use UTF-8 encoding. This is primarily useful for nicknames. Prior to that release, options with multi-byte characters were corrupted. +{%- endtrans %}

        -

        +

        {% trans -%} The following options are interpreted on the client side, and will be interpreted if passed to the I2PSession via the I2PClient.createSession() call. The streaming lib should also pass these options through to I2CP. Other implementations may have different defaults. -

        +{%- endtrans %}

        - - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        Client-side Options
        Option As Of ReleaseRecommended Arguments Allowable RangeDefaultDescription -
        i2cp.tcp.host    127.0.0.1Router hostname. - If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. -
        i2cp.tcp.port   1-655357654Router I2CP port. - If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. -
        i2cp.SSL0.8.3true, false falseConnect to the router using SSL. - If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. -
        i2cp.gzip0.6.5true, false  trueGzip outbound data -
        i2cp.reduceOnIdle0.7.1true, false  falseReduce tunnel quantity when idle -
        i2cp.closeOnIdle0.7.1true, false  falseClose I2P session when idle -
        i2cp.reduceIdleTime0.7.11200000300000 minimum (ms) Idle time required (default 20 minutes, minimum 5 minutes) -
        i2cp.closeIdleTime0.7.11800000300000 minimum (ms) Idle time required (default 30 minutes) -
        i2cp.reduceQuantity0.7.111 to 51Tunnel quantity when reduced (applies to both inbound and outbound) -
        i2cp.encryptLeaseSet0.7.1true, false  falseEncrypt the lease -
        i2cp.leaseSetKey0.7.1   Base64 SessionKey (44 characters) -
        i2cp.messageReliability  BestEffort, NoneNoneGuaranteed is disabled; - None implemented in 0.8.1; None is the default as of 0.9.4 -
        i2cp.fastReceive0.9.4 true, falsetrueIf true, the router just sends the MessagePayload instead - of sending a MessageStatus and awaiting a ReceiveMessageBegin. +
        {% trans %}Client-side Options{% endtrans %}
        {% trans %}Option{% endtrans %}{% trans %}As Of Release{% endtrans %}{% trans %}Recommended Arguments{% endtrans %}{% trans %}Allowable Range{% endtrans %}{% trans %}Default{% endtrans %}{% trans %}Description{% endtrans %}
        i2cp.tcp.host +  +  +  +127.0.0.1 +{% trans -%} +Router hostname. +If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. +{%- endtrans %}
        i2cp.tcp.port +  +  +1-65535 +7654 +{% trans -%} +Router I2CP port. +If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. +{%- endtrans %}
        i2cp.SSL +0.8.3 +true, false +  +false +{% trans -%} +Connect to the router using SSL. +If the client is running in the same JVM as a router, this option is ignored, and the client connects to that router internally. +{%- endtrans %}
        i2cp.gzip +0.6.5 +true, false +  +true +{% trans %}Gzip outbound data{% endtrans %}
        i2cp.reduceOnIdle +0.7.1 +true, false +  +false +{% trans %}Reduce tunnel quantity when idle{% endtrans %}
        i2cp.closeOnIdle +0.7.1 +true, false +  +false +{% trans %}Close I2P session when idle{% endtrans %}
        i2cp.reduceIdleTime +0.7.1 +1200000 +{% trans num=300000 %}{{ num }} minimum{% endtrans %} +  +{% trans %}(ms) Idle time required (default 20 minutes, minimum 5 minutes){% endtrans %}
        i2cp.closeIdleTime +0.7.1 +1800000 +{% trans num=300000 %}{{ num }} minimum{% endtrans %} +  +{% trans %}(ms) Idle time required (default 30 minutes){% endtrans %}
        i2cp.reduceQuantity +0.7.1 +1 +{% trans from=1, to=5 %}{{ from }} to {{ to }}{% endtrans %}1 +{% trans %}Tunnel quantity when reduced (applies to both inbound and outbound){% endtrans %}
        i2cp.encryptLeaseSet +0.7.1 +true, false +  +false +{% trans %}Encrypt the lease{% endtrans %}
        i2cp.leaseSetKey +0.7.1 +  +  +  +{% trans %}Base64 SessionKey (44 characters){% endtrans %}
        i2cp.messageReliability +  +  +BestEffort, None +None +{% trans -%} +Guaranteed is disabled; +None implemented in 0.8.1; None is the default as of 0.9.4 +{%- endtrans %}
        i2cp.fastReceive +0.9.4 +  +true, false +true +{% trans -%} +If true, the router just sends the MessagePayload instead +of sending a MessageStatus and awaiting a ReceiveMessageBegin. +{%- endtrans %}
        -

        + +

        {% trans -%} Note: All arguments, including numbers, are strings. True/false values are case-insensitive strings. Anything other than case-insensitive "true" is interpreted as false. All option names are case-sensitive. +{%- endtrans %}

        -

        I2CP Payload Data Format and Multiplexing

        -

        +

        {% trans %}I2CP Payload Data Format and Multiplexing{% endtrans %}

        +

        {% trans i2cp=site_url('docs/spec/i2cp') -%} The end-to-end messages handled by I2CP (i.e. the data sent by the client in a -SendMessageMessage +SendMessageMessage and received by the client in a -MessagePayloadMessage) +MessagePayloadMessage) are gzipped with a standard 10-byte gzip header beginning with 0x1F 0x8B 0x08 as specified by RFC 1952. @@ -207,44 +594,83 @@ As of release 0.7.1, I2P uses ignored portions of the gzip header to include protocol, from-port, and to-port information, thus supporting streaming and datagrams on the same destination, and allowing query/response using datagrams to work reliably in the presence of multiple channels. -

        +{%- endtrans %}

        + +

        {% trans -%} The gzip function cannot be completely turned off, however setting i2cp.gzip=false turns the gzip effort setting to 0, which may save a little CPU. -

        +{%- endtrans %}

        - + + + + + + + + + + + + + + + + + + + + + + + + + +
        BytesContent -
        0-2Gzip header 0x1F 0x8B 0x08 -
        3Gzip flags -
        4-5I2P Source port (Gzip mtime) -
        6-7I2P Destination port (Gzip mtime) -
        8Gzip xflags -
        9I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS) +
        {% trans %}Bytes{% endtrans %}{% trans %}Content{% endtrans %}
        0-2 +{% trans %}Gzip header{% endtrans %} 0x1F 0x8B 0x08 +
        3 +{% trans %}Gzip flags{% endtrans %}
        4-5 +{% trans %}I2P Source port (Gzip mtime){% endtrans %}
        6-7 +{% trans %}I2P Destination port (Gzip mtime){% endtrans %}
        8 +{% trans %}Gzip xflags{% endtrans %}
        9 +{% trans %}I2P Protocol (6 = Streaming, 17 = Datagram, 18 = Raw Datagrams) (Gzip OS){% endtrans %}
        -

        +

        {% trans -%} Data integrity is verified with the standard gzip CRC-32 as specified by RFC 1952. -

        +{%- endtrans %}

        -

        Future Work

        -
        • +

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

          +
            +
          • {% trans -%} Implement I2CP and the streaming library in another programming language. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Is the initial Get Date / Set Date handshake required? -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The current authorization mechanism could be modified to use hashed passwords. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Private Keys are included in the Create Lease Set message, are they really required? Revocation is unimplemented. -
          • +{%- endtrans %}
          • + +
          • {% trans pdf1=url_for('static', filename='pdf/I2CP_spec.pdf'), pdf2=url_for('static', filename='pdf/datastructures.pdf') -%} Some improvements may be able to use messages previously defined but not implemented. For reference, here is the -I2CP Protocol Specification Version 0.9 +I2CP Protocol Specification Version 0.9 (PDF) dated August 28, 2003. That document also references the -Common Data Structures Specification Version 0.9. -
          +Common Data Structures Specification Version 0.9. +{%- endtrans %}
        • +
        diff --git a/i2p2www/pages/site/docs/protocol/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html index 8cb24255..3ee58d06 100644 --- a/i2p2www/pages/site/docs/protocol/i2np.html +++ b/i2p2www/pages/site/docs/protocol/i2np.html @@ -1,24 +1,26 @@ {% extends "global/layout.html" %} {% block title %}I2NP{% endblock %} -{% block lastupdated %}August 2010{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        I2P Network Protocol (I2NP)

        -

        +

        {% trans %}I2P Network Protocol{% endtrans %} (I2NP)

        +

        {% trans -%} The I2P Network Protocol (I2NP), which is sandwiched between I2CP and the various I2P transport protocols, manages the routing and mixing of messages between routers, as well as the selection of what transports to use when communicating with a peer for which there are multiple common transports supported. -

        +{%- endtrans %}

        -

        I2NP Definition

        -

        +

        {% trans %}I2NP Definition{% endtrans %}

        +

        {% trans -%} I2NP (I2P Network Protocol) messages can be used for one-hop, router-to-router, point-to-point messages. By encrypting and wrapping messages in other messages, they can be sent in a secure way through multiple hops to the ultimate destination. Priority is only used locally at the origin, i.e. when queuing for outbound delivery. -

        +{%- endtrans %}

        + +

        {% trans -%} Both the NTCP and UDP transports implement priority transmission, but in quite different manners. UDP has complex code with queues for each priority, however it treats @@ -28,42 +30,49 @@ These are global queues for all peers. NTCP has a trivial linear search for the highest priority within each buffer for a particular peer. This is much less effective. +{%- endtrans %}

        -

        Message Format

        -

        +

        {% trans %}Message Format{% endtrans %}

        - + + + + +
        FieldBytes -
        Unique ID4 -
        Expiration8 -
        Payload Length2 -
        Checksum1 -
        Payload0 - 61.2KB +
        {% trans %}Field{% endtrans %}{% trans %}Bytes{% endtrans %}
        {% trans %}Unique ID{% endtrans %}4
        {% trans %}Expiration{% endtrans %}8
        {% trans %}Payload Length{% endtrans %}2
        {% trans %}Checksum{% endtrans %}1
        {% trans %}Payload{% endtrans %}0 - 61.2KB
        -

        +

        {% trans tunnelimpl=site_url('docs/tunnels/implementation') -%} While the maximum payload size is nominally 64KB, the size is further constrained by the -method of fragmenting I2NP messages into multiple 1KB tunnel messages as described in -tunnel-alt.html. +method of fragmenting I2NP messages into multiple 1KB tunnel messages as described on +the tunnel implementation page. The maximum number of fragments is 64, and the message may not be perfectly aligned, So the message must nominally fit in 63 fragments. -

        +{%- endtrans %}

        + +

        {% trans -%} The maximum size of an initial fragment is 956 bytes (assuming TUNNEL delivery mode); the maximum size of a follow-on fragment is 996 bytes. Therefore the maximum size is approximately 956 + (62 * 996) = 62708 bytes, or 61.2 KB. -

        -

        +{%- endtrans %}

        + +

        {% trans -%} In addition, the transports may have additional restrictions. NTCP currently limits to 16KB - 6 = 16378 bytes but this will be increased in a future release. The SSU limit is approximately 32 KB. -

        +{%- endtrans %}

        + +

        {% trans -%} Note that these are not the limits for datagrams that the client sees, as the router may bundle a reply leaseset and/or session tags together with the client message in a garlic message. The leaseset and tags together may add about 5.5KB. Therefore the current datagram limit is about 10KB. This limit will be increased in a future release. +{%- endtrans %}

        -

        Message Types

        +

        {% trans %}Message Types{% endtrans %}

        +

        {% trans -%} Higher-numbered priority is higher priority. The majority of traffic is TunnelDataMessages (priority 400), so anything above 400 is essentially high priority, and @@ -72,115 +81,162 @@ Note also that many of the messages are generally routed through exploratory tunnels, not client tunnels, and therefore may not be in the same queue unless the first hops happen to be on the same peer. -

        +{%- endtrans %}

        + +

        {% trans -%} Also, not all message types are sent unencrypted. For example, when testing a tunnel, the router wraps a DeliveryStatusMessage, which is wrapped in a GarlicMessage, which is wrapped in a DataMessage. -

        +{%- endtrans %}

        - + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
        MessageTypePayload LengthPriorityComments +
        {% trans %}Message{% endtrans %}{% trans %}Type{% endtrans %}{% trans %}Payload Length{% endtrans %}{% trans %}Priority{% endtrans %}{% trans %}Comments{% endtrans %}
        DatabaseLookupMessage 2   100/400 -400 normally; 100 if from HarvesterJob and sent directly; +{% trans -%} +400 normally; 100 if from HarvesterJob and sent directly; 400 for a router lookup +{%- endtrans %}
        DatabaseSearchReplyMessage 3 Typ. 161 300 -Size is 65 + 32*(number of hashes) where typically, the hashes for +{% trans -%} +Size is 65 + 32*(number of hashes) where typically, the hashes for three floodfill routers are returned. +{%- endtrans %}
        DatabaseStoreMessage 1 -Varies +{% trans %}Varies{% endtrans %} 100/400 -Usually 100 (why?) +{% trans -%} +Usually 100 (why?) Size is 898 bytes for a typical 2-lease leaseSet. RouterInfo structures are compressed, and size varies; however there is a continuing effort to reduce the amount of data published in a RouterInfo as we approach release 1.0. +{%- endtrans %}
        DataMessage 20 4 - 62080 400 +
        DeliveryStatusMessage 10 12   -Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage +{% trans %}Used for message replies, and for testing tunnels - generally wrapped in a GarlicMessage{% endtrans %}
        -GarlicMessage +GarlicMessage 11     -Generally wrapped in a DataMessage - +{% trans -%} +Generally wrapped in a DataMessage - but when unwrapped, given a priority of 100 by the forwarding router +{%- endtrans %}
        -TunnelBuildMessage +TunnelBuildMessage 21 4224 300/500 -Usually 500 (why?) +{% trans %}Usually 500 (why?){% endtrans %}
        -TunnelBuildReplyMessage +TunnelBuildReplyMessage 22 4224 300 +
        TunnelDataMessage 18 1028 400 -The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was - reduced to 200 as of release 0.6.1.33. - Outbound gateway messages (i.e. those originated locally) remains at 400. +{% trans -%} +The most common message. Priority for tunnel participants, outbound endpoints, and inbound gateways was +reduced to 200 as of release 0.6.1.33. +Outbound gateway messages (i.e. those originated locally) remains at 400. +{%- endtrans %}
        TunnelGatewayMessage 19   300/400 +
        VariableTunnelBuildMessage 23 1057 - 4225 300/500 -Shorter TunnelBuildMessage as of 0.7.12 +{% trans %}Shorter TunnelBuildMessage as of 0.7.12{% endtrans %}
        VariableTunnelBuildReplyMessage 24 1057 - 4225 300 -Shorter TunnelBuildReplyMessage as of 0.7.12 -
        -Others listed in -2003 Spec +{% trans %}Shorter TunnelBuildReplyMessage as of 0.7.12{% endtrans %}
        {% trans pdf=url_for('static', filename='pdf/I2NP_spec.pdf') -%} +Others listed in 2003 Spec +{%- endtrans %} 0,4-9,12     -Obsolete, Unused +{% trans %}Obsolete, Unused{% endtrans %} +
        -

        Full Protocol Specification

        -On the I2NP Specification page. +

        {% trans %}Full Protocol Specification{% endtrans %}

        +

        {% trans i2npspec=site_url('docs/specs/i2np'), commonstructures=site_url('docs/specs/common-structures') -%} +On the I2NP Specification page. See also the -Common Data Structure Specification page. +Common Data Structure Specification page. +{%- endtrans %}

        -

        Future Work

        -

        +

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

        +

        {% trans -%} It isn't clear whether the current priority scheme is generally effective, and whether the priorities for various messages should be adjusted further. This is a topic for further research, analysis and testing. +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/docs/protocol/index.html b/i2p2www/pages/site/docs/protocol/index.html index 117d7f55..d2869502 100644 --- a/i2p2www/pages/site/docs/protocol/index.html +++ b/i2p2www/pages/site/docs/protocol/index.html @@ -1,73 +1,88 @@ {% extends "global/layout.html" %} -{% block title %}Protocol Stack{% endblock %} -{% block lastupdated %}August 2010{% endblock %} +{% block title %}{% trans %}Protocol Stack{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        +

        {% trans docs=site_url('docs') -%} Here is the protocol stack for I2P. -See also the Index to Technical Documentation. -

        +See also the Index to Technical Documentation. +{%- endtrans %}

        -

        +

        {% trans -%} Each of the layers in the stack provides extra capabilities. The capabilities are listed below, starting at the bottom of the protocol stack. +{%- endtrans %}

        • - Internet Layer: + {% trans %}Internet Layer:{% endtrans %}
          - IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery. + {% trans %}IP: Internet Protocol, allow addressing hosts on the regular internet and routing packets across the internet using best-effort delivery.{% endtrans %}
        • - Transport Layer: + {% trans %}Transport Layer:{% endtrans %}
          - TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet. + {% trans %}TCP: Transmission Control Protocol, allow reliable, in-order delivery of packets across the internet.{% endtrans %}
          - UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet. + {% trans %}UDP: User Datagram Protocol, allow unreliable, out-of-order delivery of packets across the internet.{% endtrans %}
        • - I2P Transport Layer: provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection. - Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP. +{% trans -%} +I2P Transport Layer: provide encrypted connections between 2 I2P routers. These are not anonymous yet, this is strictly a hop-to-hop connection. +Two protocols are implemented to provide these capabilities. NTCP builds on top of TCP, while SSU uses UDP. +{%- endtrans %}
          - NTCP: NIO-based TCP + NTCP: {% trans %}NIO-based TCP{% endtrans %}
          - SSU: Secure Semi-reliable UDP + SSU: {% trans %}Secure Semi-reliable UDP{% endtrans %}
        • - I2P Tunnel Layer: provide full encrypted tunnel connections. + {% trans %}I2P Tunnel Layer: provide full encrypted tunnel connections.{% endtrans %}
          - Tunnel messages: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery. - The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key), - so it will be forwarded. +{% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%} +Tunnel messages: tunnel messages are large messages containing encrypted I2NP (see below) messages and encrypted instructions for their delivery. +The encryption is layered. The first hop will decrypt the tunnel message and read a part. Another part can still be encrypted (with another key), +so it will be forwarded. +{%- endtrans %}
          - I2NP messages: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages. +{% trans i2np=site_url('docs/protocol/i2np') -%} +I2NP messages: I2P Network Protocol messages are used to pass messages through multiple routers. These I2NP messages are combined in tunnel messages. +{%- endtrans %}
        • - I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P message delivery. + {% trans %}I2P Garlic Layer: provide encrypted and anonymous end-to-end I2P message delivery.{% endtrans %}
          - I2NP messages: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous. +{% trans i2np=site_url('docs/protocol/i2np') -%} +I2NP messages: I2P Network Protocol messages are wrapped in each other and used to ensure encryption between two tunnels and are passed along from source to destination, keeping both anonymous. +{%- endtrans %}
        -

        -

        +

        {% trans -%} The following layers are strictly speaking no longer part of the I2P Protocol stack, they are not part of the core 'I2P router' functionality. However, each of these layers adds additional functionality, to allow applications simple and convenient I2P usage. +{%- endtrans %}

        • - I2P Client Layer: allow any client to use I2P functionality, without requiring the direct use of the router API. + {% trans %}I2P Client Layer: allow any client to use I2P functionality, without requiring the direct use of the router API.{% endtrans %}
          - I2CP: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket. +{% trans i2cp=site_url('docs/protocol/i2cp') -%} +I2CP: I2P Client Protocol, allows secure and asynchronous messaging over I2P by communicating messages over the I2CP TCP socket. +{%- endtrans %}
        • - I2P End-to-end Transport Layer: allow TCP- or UDP-like functionality on top of I2P. + {% trans %}I2P End-to-end Transport Layer: allow TCP- or UDP-like functionality on top of I2P.{% endtrans %}
          - Streaming Library: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P. +{% trans streaming=site_url('docs/api/streaming') -%} +Streaming Library: an implementation of TCP-like streams over I2P. This allows easier porting of existing applications to I2P. +{%- endtrans %}
          - Datagram Library: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P. +{% trans datagrams=site_url('docs/spec/datagrams') -%} +Datagram Library: an implementation of UDP-like messages over I2P. This allows easier porting of existing applications to I2P. +{%- endtrans %}
        • - I2P Application Interface Layer: additional (optional) libraries allowing easier implementations on top of I2P. + {% trans %}I2P Application Interface Layer: additional (optional) libraries allowing easier implementations on top of I2P.{% endtrans %}
          I2PTunnel
          @@ -75,32 +90,32 @@ However, each of these layers adds additional functionality, to allow applicatio BOB
        • - I2P Application Proxy Layer: proxy systems. + {% trans %}I2P Application Proxy Layer: proxy systems.{% endtrans %}
          - HTTP Client/Server, IRC Client, SOCKS, Streamr + {% trans socks=site_url('docs/api/socks') %}HTTP Client/Server, IRC Client, SOCKS, Streamr{% endtrans %}
        -

        -

        + +

        {% trans -%} Finally, what could be considered the 'I2P application layer', is a large number of applications on top of I2P. We can order this based on the I2P stack layer they use. +{%- endtrans %}

          -
        • Streaming/datagram applications: i2psnark, Syndie, i2phex...
        • -
        • SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert...
        • -
        • Other I2P applications: Syndie, EepGet, plugins...
        • -
        • Regular applications: Jetty, Apache, Monotone, CVS, browsers, e-mail...
        • +
        • {% trans %}Streaming/datagram applications: i2psnark, Syndie, i2phex...{% endtrans %}
        • +
        • {% trans %}SAM/BOB applications: IMule, i2p-bt, i2prufus, Robert...{% endtrans %}
        • +
        • {% trans plugins=site_url('docs/plugins') %}Other I2P applications: Syndie, EepGet, plugins...{% endtrans %}
        • +
        • {% trans %}Regular applications: Jetty, Apache, Monotone, CVS, browsers, e-mail...{% endtrans %}
        -

        - I2P Network stack + {{ _('I2P Network stack') }}

        - Figure 1: The layers in the I2P Network stack. + {% trans %}Figure 1: The layers in the I2P Network stack.{% endtrans %}

        -* Note: SAM/SAMv2 can use both the streaming lib and datagrams. +* {% trans %}Note: SAM/SAMv2 can use both the streaming lib and datagrams.{% endtrans %}

        {% endblock %} From 98b90ec20af1533034adf59e712c5aa0366b8de3 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 5 Feb 2013 04:39:24 +0000 Subject: [PATCH 393/498] Added translation tags to docs/transport/* --- i2p2www/pages/site/docs/transport/index.html | 148 +++++--- i2p2www/pages/site/docs/transport/ntcp.html | 312 ++++++++------- i2p2www/pages/site/docs/transport/ssu.html | 376 ++++++++++++------- 3 files changed, 505 insertions(+), 331 deletions(-) diff --git a/i2p2www/pages/site/docs/transport/index.html b/i2p2www/pages/site/docs/transport/index.html index 10f0e78c..7ab5ad92 100644 --- a/i2p2www/pages/site/docs/transport/index.html +++ b/i2p2www/pages/site/docs/transport/index.html @@ -1,126 +1,158 @@ {% extends "global/layout.html" %} -{% block title %}Transport Overview{% endblock %} -{% block lastupdated %}July 2010{% endblock %} +{% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}July 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        Transports in I2P

        +

        {% trans %}Transports in I2P{% endtrans %}

        +

        {% trans -%} A "transport" in I2P is a method for direct, point-to-point communication between two routers. Transports must provide confidentiality and integrity against external adversaries while authenticating that the router contacted is the one who should receive a given message. +{%- endtrans %}

        -

        I2P supports multiple transports simultaneously. +

        {% trans -%} +I2P supports multiple transports simultaneously. There are two transports currently implemented: +{%- endtrans %}

          -
        1. NTCP, a Java New I/O (NIO) TCP transport -
        2. SSU, or Secure Semireliable UDP +
        3. {% trans ntcp=site_url('docs/transport/ntcp') %}NTCP, a Java New I/O (NIO) TCP transport{% endtrans %}
        4. +
        5. {% trans ssu=site_url('docs/transport/ssu') %} SSU, or Secure Semireliable UDP{% endtrans %}
        +

        {% trans -%} Each provides a "connection" paradigm, with authentication, flow control, acknowledgments and retransmission. +{%- endtrans %}

        -

        Transport Services

        +

        {% trans %}Transport Services{% endtrans %}

        +

        {% trans -%} The transport subsystem in I2P provides the following services: +{%- endtrans %}

          -
        • Maintain a set of router addresses, one or more for each transport, - that the router publishes as its global contact information (the RouterInfo) -
        • Selection of the best transport for each outgoing message -
        • Queueing of outbound messages by priority -
        • Bandwidth limiting, both outbound and inbound, according to router configuration -
        • Setup and teardown of transport connections -
        • Encryption of point-to-point communications -
        • Maintenance of connection limits for each transport, implementation of various thresholds for these limits, - and communication of threshold status to the router so it may make operational changes based on the status -
        • Firewall port opening using UPnP (Universal Plug and Play) -
        • Cooperative NAT/Firewall traversal -
        • Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices -
        • Coordination of firewall status and local IP, and changes to either, among the transports -
        • Communication of firewall status and local IP, and changes to either, to the router and the user interface -
        • Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP -
        • Maintenance of status for each peer, including whether it is connected, whether it was recently connected, - and whether it was reachable in the last attempt -
        • Qualification of valid IP addresses according to a local rule set -
        • Honoring the automated and manual lists of banned peers maintained by the router, - and refusing outbound and inbound connections to those peers +
        • {% trans -%} +Maintain a set of router addresses, one or more for each transport, +that the router publishes as its global contact information (the RouterInfo) +{%- endtrans %}
        • +
        • {% trans %}Selection of the best transport for each outgoing message{% endtrans %}
        • +
        • {% trans %}Queueing of outbound messages by priority{% endtrans %}
        • +
        • {% trans %}Bandwidth limiting, both outbound and inbound, according to router configuration{% endtrans %}
        • +
        • {% trans %}Setup and teardown of transport connections{% endtrans %}
        • +
        • {% trans %}Encryption of point-to-point communications{% endtrans %}
        • +
        • {% trans -%} +Maintenance of connection limits for each transport, implementation of various thresholds for these limits, +and communication of threshold status to the router so it may make operational changes based on the status +{%- endtrans %}
        • +
        • {% trans %}Firewall port opening using UPnP (Universal Plug and Play){% endtrans %}
        • +
        • {% trans %}Cooperative NAT/Firewall traversal{% endtrans %}
        • +
        • {% trans %}Local IP detection by various methods, including UPnP, inspection of incoming connections, and enumeration of network devices{% endtrans %}
        • +
        • {% trans %}Coordination of firewall status and local IP, and changes to either, among the transports{% endtrans %}
        • +
        • {% trans %}Communication of firewall status and local IP, and changes to either, to the router and the user interface{% endtrans %}
        • +
        • {% trans %}Determination of a consensus clock, which is used to periodically update the router's clock, as a backup for NTP{% endtrans %}
        • +
        • {% trans -%} +Maintenance of status for each peer, including whether it is connected, whether it was recently connected, +and whether it was reachable in the last attempt +{%- endtrans %}
        • +
        • {% trans %}Qualification of valid IP addresses according to a local rule set{% endtrans %}
        • +
        • {% trans -%} +Honoring the automated and manual lists of banned peers maintained by the router, +and refusing outbound and inbound connections to those peers +{%- endtrans %}
        -

        Transport Addresses

        +

        {% trans %}Transport Addresses{% endtrans %}

        +

        {% trans -%} The transport subsystem maintains a set of router addresses, each of which lists a transport method, IP, and port. These addresses constitute the advertised contact points, and are published by the router to the network database. -

        -Typical scenarios are: +{%- endtrans %}

        + +

        {% trans %}Typical scenarios are:{% endtrans %}

          -
        • A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections -
        • A router is firewalled, and therefore publishes an SSU address which contains a list of cooperating - peers or "introducers" who will assist in NAT traversal (see the SSU spec for details) -
        • A router is not firewalled or its NAT ports are open; it publishes both NTCP and SSU addresses containing - directly-accessible IP and ports. +
        • {% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}
        • +
        • {% trans ssu=site_url('docs/transport/ssu') -%} +A router is firewalled, and therefore publishes an SSU address which contains a list of cooperating +peers or "introducers" who will assist in NAT traversal (see the SSU spec for details) +{%- endtrans %}
        • +
        • {% trans -%} +A router is not firewalled or its NAT ports are open; it publishes both NTCP and SSU addresses containing +directly-accessible IP and ports. +{%- endtrans %}
        -

        Transport Selection

        +

        {% trans %}Transport Selection{% endtrans %}

        -The transport system delivers I2NP messages. The transport selected for any message is +

        {% trans i2np=site_url('docs/protocol/i2np') -%} +The transport system delivers I2NP messages. The transport selected for any message is independent of the application-layer protocol (TCP or UDP). -

        +{%- endtrans %}

        +

        {% trans -%} For each outgoing message, the transport system solicits "bids" from each transport. The transport bidding the lowest (best) value wins the bid and receives the message for delivery. A transport may refuse to bid. -

        +{%- endtrans %}

        + +

        {% trans -%} Whether a transport bids, and with what value, depend on numerous factors: +{%- endtrans %}

          -
        • Configuration of transport preferences -
        • Whether the transport is already connected to the peer -
        • The number of current connections compared to various connection limit thresholds -
        • Whether recent connection attempts to the peer have failed -
        • The size of the message, as different transports have different size limits -
        • Whether the peer can accept incoming connections for that transport, as advertised in its RouterInfo -
        • Whether the connection would be indirect (requiring introducers) or direct -
        • The peer's transport preference, as advertised in its RouterInfo +
        • {% trans %}Configuration of transport preferences{% endtrans %}
        • +
        • {% trans %}Whether the transport is already connected to the peer{% endtrans %}
        • +
        • {% trans %}The number of current connections compared to various connection limit thresholds{% endtrans %}
        • +
        • {% trans %}Whether recent connection attempts to the peer have failed{% endtrans %}
        • +
        • {% trans %}The size of the message, as different transports have different size limits{% endtrans %}
        • +
        • {% trans %}Whether the peer can accept incoming connections for that transport, as advertised in its RouterInfo{% endtrans %}
        • +
        • {% trans %}Whether the connection would be indirect (requiring introducers) or direct{% endtrans %}
        • +
        • {% trans %}The peer's transport preference, as advertised in its RouterInfo{% endtrans %}
        -

        +

        {% trans -%} In general, the bid values are selected so that two routers are only connected by a single transport at any one time. However, this is not a requirement. +{%- endtrans %}

        -

        New Transports and Future Work

        +

        {% trans %}New Transports and Future Work{% endtrans %}

        +

        {% trans -%} Additional transports may be developed, including: +{%- endtrans %}

          -
        • A TLS/SSH look-alike transport -
        • An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes") +
        • {% trans %}A TLS/SSH look-alike transport{% endtrans %}
        • +
        • {% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}
        -

        +

        {% trans -%} Also, the existing transports will be enhanced to support multiple addresses within a single transport, including IPV6 addresses. Currently, a transport may only advertise a single IPV4 address. +{%- endtrans %}

        -

        +

        {% trans -%} Work continues on adjusting default connection limits for each transport. I2P is designed as a "mesh network", where it is assumed that any router can connect to any other router. This assumption may be broken by routers that have exceeded their connection limits, and by routers that are behind restrictive state firewalls (restricted routes). +{%- endtrans %}

        -

        +

        {% trans -%} The current connection limits are higher for SSU than for NTCP, based on the assumption that the memory requirements for an NTCP connection are higher than that for SSU. However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap, that assumption is difficult to verify. +{%- endtrans %}

        -

        -Analyze -Breaking and Improving Protocol Obfuscation +

        {% trans pdf='http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf' -%} +Analyze Breaking and Improving Protocol Obfuscation and see how transport-layer padding may improve things. -

        +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/docs/transport/ntcp.html b/i2p2www/pages/site/docs/transport/ntcp.html index 509551a3..bb7053e0 100644 --- a/i2p2www/pages/site/docs/transport/ntcp.html +++ b/i2p2www/pages/site/docs/transport/ntcp.html @@ -1,64 +1,65 @@ {% extends "global/layout.html" %} {% block title %}NTCP{% endblock %} -{% block lastupdated %}August 2010{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

        NTCP (NIO-based TCP)

        +

        {% trans %}NTCP (NIO-based TCP){% endtrans %}

        -

        -NTCP -is one of two transports currently implemented in I2P. -The other is SSU. -NTCP -is a Java NIO-based transport -introduced in I2P release 0.6.1.22. +

        {% trans transports=site_url('docs/transport'), ssu=site_url('docs/transport/ssu') -%} +NTCP is one of two transports currently implemented in I2P. +The other is SSU. +NTCP is a Java NIO-based transport introduced in I2P release 0.6.1.22. Java NIO (new I/O) does not suffer from the 1 thread per connection issues of the old TCP transport. -

        +{%- endtrans %}

        -By default, -NTCP uses the IP/Port +

        {% trans -%} +By default, NTCP uses the IP/Port auto-detected by SSU. When enabled on config.jsp, SSU will notify/restart NTCP when the external address changes or when the firewall status changes. Now you can enable inbound TCP without a static IP or dyndns service. -

        +{%- endtrans %}

        +

        {% trans -%} The NTCP code within I2P is relatively lightweight (1/4 the size of the SSU code) because it uses the underlying Java TCP transport for reliable delivery. -

        +{%- endtrans %}

        -

        NTCP Protocol Specification

        +

        {% trans %}NTCP Protocol Specification{% endtrans %}

        -

        Standard Message Format

        -

        - After establishment, - the NTCP transport sends individual I2NP messages, with a simple checksum. - The unencrypted message is encoded as follows: +

        {% trans %}Standard Message Format{% endtrans %}

        +

        {% trans -%} +After establishment, +the NTCP transport sends individual I2NP messages, with a simple checksum. +The unencrypted message is encoded as follows: +{%- endtrans %}

          *  +-------+-------+--//--+---//----+-------+-------+-------+-------+
          *  | sizeof(data)  | data | padding | Adler checksum of sz+data+pad |
          *  +-------+-------+--//--+---//----+-------+-------+-------+-------+
         
        - The data is then AES/256/CBC encrypted. The session key for the encryption - is negotiated during establishment (using Diffie-Hellman 2048 bit). - The establishment between two routers is implemented in the EstablishState class - and detailed below. - The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message. -

        +

        {% trans -%} +The data is then AES/256/CBC encrypted. The session key for the encryption +is negotiated during establishment (using Diffie-Hellman 2048 bit). +The establishment between two routers is implemented in the EstablishState class +and detailed below. +The IV for AES/256/CBC encryption is the last 16 bytes of the previous encrypted message. +{%- endtrans %}

        -

        +

        {% trans -%} 0-15 bytes of padding are required to bring the total message length (including the six size and checksum bytes) to a multiple of 16. The maximum message size is currently 16 KB. Therefore the maximum data size is currently 16 KB - 6, or 16378 bytes. The minimum data size is 1. -

        +{%- endtrans %}

        -

        Time Sync Message Format

        -

        - One special case is a metadata message where the sizeof(data) is 0. In - that case, the unencrypted message is encoded as: +

        {% trans %}Time Sync Message Format{% endtrans %}

        +

        {% trans -%} +One special case is a metadata message where the sizeof(data) is 0. In +that case, the unencrypted message is encoded as: +{%- endtrans %}

          *  +-------+-------+-------+-------+-------+-------+-------+-------+
          *  |       0       |      timestamp in seconds     | uninterpreted             
        @@ -66,19 +67,25 @@ The minimum data size is 1.
          *          uninterpreted           | Adler checksum of bytes 0-11  |
          *  +-------+-------+-------+-------+-------+-------+-------+-------+
         
        +

        {% trans -%} Total length: 16 bytes. The time sync message is sent at approximately 15 minute intervals. The message is encrypted just as standard messages are. +{%- endtrans %}

        -

        Checksums

        +

        {% trans %}Checksums{% endtrans %}

        +

        {% trans rfc1950='http://tools.ietf.org/html/rfc1950' -%} The standard and time sync messages use the Adler-32 checksum -as defined in the ZLIB Specification. +as defined in the ZLIB Specification. +{%- endtrans %}

        -

        Establishment Sequence

        +

        {% trans %}Establishment Sequence{% endtrans %}

        +

        {% trans -%} In the establish state, there is a 4-phase message sequence to exchange DH keys and signatures. In the first two messages there is a 2048-bit Diffie Hellman exchange. Then, DSA signatures of the critical data are exchanged to confirm the connection. +{%- endtrans %}

          * Alice                   contacts                      Bob
          * =========================================================
        @@ -90,57 +97,58 @@ Then, DSA signatures of the critical data are exchanged to confirm the connectio
         
        -  Legend:
        -    X, Y: 256 byte DH public keys
        +  {% trans %}Legend:{% endtrans %}
        +    X, Y: {% trans %}256 byte DH public keys{% endtrans %}
             H(): 32 byte SHA256 Hash
             E(data, session key, IV): AES256 Encrypt
             S(): 40 byte DSA Signature
        -    tsA, tsB: timestamps (4 bytes, seconds since epoch)
        -    sk: 32 byte Session key
        -    sz: 2 byte size of Alice identity to follow
        +    tsA, tsB: {% trans %}timestamps (4 bytes, seconds since epoch){% endtrans %}
        +    sk: {% trans %}32 byte Session key{% endtrans %}
        +    sz: {% trans %}2 byte size of Alice identity to follow{% endtrans %}
         
        -

        DH Key Exchange

        -

        +

        {% trans %}DH Key Exchange{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} The initial 2048-bit DH key exchange uses the same shared prime (p) and generator (g) as that used for I2P's -ElGamal encryption. -

        +ElGamal encryption. +{%- endtrans %}

        -

        +

        {% trans -%} The DH key exchange consists of a number of steps, displayed below. The mapping between these steps and the messages sent between I2P routers, is marked in bold. +{%- endtrans %}

          -
        1. Alice generates a secret 226-bit integer x. - She then calculates X = g^x mod p. -
        2. -
        3. Alice sends X to Bob (Message 1).
        4. -
        5. Bob generates a secret 226-bit integer y. - He then calculates Y = g^y mod p.
        6. -
        7. Bob sends Y to Alice.(Message 2)
        8. -
        9. Alice can now compute sessionKey = Y^x mod p.
        10. -
        11. Bob can now compute sessionKey = X^y mod p.
        12. -
        13. Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.
        14. +
        15. {% trans %}Alice generates a secret 226-bit integer x. She then calculates X = g^x mod p.{% endtrans %}
        16. +
        17. {% trans %}Alice sends X to Bob (Message 1).{% endtrans %}
        18. +
        19. {% trans %}Bob generates a secret 226-bit integer y. He then calculates Y = g^y mod p.{% endtrans %}
        20. +
        21. {% trans %}Bob sends Y to Alice.(Message 2){% endtrans %}
        22. +
        23. {% trans %}Alice can now compute sessionKey = Y^x mod p.{% endtrans %}
        24. +
        25. {% trans %}Bob can now compute sessionKey = X^y mod p.{% endtrans %}
        26. +
        27. {% trans %}Both Alice and Bob now have a shared key sessionKey = g^(x*y) mod p.{% endtrans %}
        +

        {% trans -%} The sessionKey is then used to exchange identities in Message 3 and Message 4. -

        +{%- endtrans %}

        -

        Message 1 (Session Request)

        -This is the DH request. -Alice already has Bob's -Router Identity, +

        {% trans %}Message 1 (Session Request){% endtrans %}

        +

        {% trans commonstructures=site_url('docs/spec/common-structures'), +netdb=site_url('docs/how/network-database') -%} +This is the DH request. Alice already has Bob's +Router Identity, IP address, and port, as contained in his -Router Info, +Router Info, which was published to the -network database. +network database. Alice sends Bob: +{%- endtrans %}

          *  X+(H(X) xor Bob.identHash)----------------------------->
         
        -    Size: 288 bytes
        +    {% trans %}Size:{% endtrans %} 288 bytes
         
        -Contents: +

        {% trans %}Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |         X, as calculated from DH      |
        @@ -158,28 +166,32 @@ Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  X: 256 byte X from Diffie Hellman
        +  X: {% trans %}256 byte X from Diffie Hellman{% endtrans %}
         
        -  HXxorHI:  SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)
        +  HXxorHI:  {% trans commonstructures=site_url('docs/spec/common-structures') -%}
        +SHA256 Hash(X) xored with SHA256 Hash(Bob's Router Identity)
        +{%- endtrans %}
                     (32 bytes)
         
         
        -

        Notes: -

        • +

          {% trans %}Notes:{% endtrans %} +

          • {% trans -%} Bob verifies HXxorHI using his own router hash. If it does not verify, Alice has contacted the wrong router, and Bob drops the connection. -
          +{%- endtrans %}
        -

        Message 2 (Session Created)

        +

        {% trans %}Message 2 (Session Created){% endtrans %}

        +

        {% trans -%} This is the DH reply. Bob sends Alice: +{%- endtrans %}

          *  <----------------------------------------Y+E(H(X+Y)+tsB+padding, sk, Y[239:255])
         
        -    Size: 304 bytes
        +    {% trans %}Size:{% endtrans %} 304 bytes
         
        -Unencrypted Contents: +

        {% trans %}Unencrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |         Y as calculated from DH       |
        @@ -201,19 +213,19 @@ Unencrypted Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  Y: 256 byte Y from Diffie Hellman
        +  Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %}
         
        -  HXY:  SHA256 Hash(X concatenated with Y)
        +  HXY:  {% trans %}SHA256 Hash(X concatenated with Y){% endtrans %}
                 (32 bytes)
         
        -  tsB: 4 byte timestamp (seconds since the epoch)
        +  tsB: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %}
         
        -  padding: 12 bytes random data
        +  padding: {% trans %}12 bytes random data{% endtrans %}
         
         
        -Encrypted Contents: +

        {% trans %}Encrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |         Y as calculated from DH       |
        @@ -235,29 +247,31 @@ Encrypted Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  Y: 256 byte Y from Diffie Hellman
        +  Y: {% trans %}256 byte Y from Diffie Hellman{% endtrans %}
         
        -  encrypted data: 48 bytes AES encrypted using the DH session key and
        -                  the last 16 bytes of Y as the IV
        +  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
        +48 bytes AES encrypted using the DH session key and
        +                  the last 16 bytes of Y as the IV{% endtrans %}
         
         
        -

        Notes: -

        • +

          {% trans %}Notes:{% endtrans %}

          +
          • {% trans -%} Alice may drop the connection if the clock skew with Bob is too high as calculated using tsB. -
          -

          +{%- endtrans %}
        -

        Message 3 (Session Confirm A)

        +

        {% trans %}Message 3 (Session Confirm A){% endtrans %}

        +

        {% trans -%} This contains Alice's router identity, and a DSA signature of the critical data. Alice sends Bob: +{%- endtrans %}

          *  E(sz+Alice.identity+tsA+padding+S(X+Y+Bob.identHash+tsA+tsB), sk, hX_xor_Bob.identHash[16:31])--->
         
        -    Size: 448 bytes (typ. for 387 byte identity)
        +    {% trans %}Size:{% endtrans %} 448 bytes (typ. for 387 byte identity)
         
        -Unencrypted Contents: +

        {% trans %}Unencrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |   sz    | Alice's Router Identity     |
        @@ -283,21 +297,25 @@ Unencrypted Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  sz: 2 byte size of Alice's router identity to follow (should always be 387)
        +  sz: {% trans %}2 byte size of Alice's router identity to follow (should always be 387){% endtrans %}
         
        -  ident: Alice's 387 byte Router Identity
        +  ident: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
        +Alice's 387 byte Router Identity
        +{%- endtrans %}
         
        -  tsA: 4 byte timestamp (seconds since the epoch)
        +  tsA: {% trans %}4 byte timestamp (seconds since the epoch){% endtrans %}
         
        -  padding: 15 bytes random data
        +  padding: {% trans %}15 bytes random data{% endtrans %}
         
        -  signature: the 40 byte DSA signature of the following concatenated data:
        -             X, Y, Bob's Router Identity, tsA, tsB.
        -             Alice signs it with the private signing key associated with the public signing key in her Router Identity
        +  signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
        +the 40 byte DSA signature of the following concatenated data:
        +             X, Y, Bob's Router Identity, tsA, tsB.
        +             Alice signs it with the private signing key associated with the public signing key in her Router Identity
        +{%- endtrans %}
         
         
        -Encrypted Contents: +

        {% trans %}Encrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |                                       |
        @@ -307,30 +325,36 @@ Encrypted Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  encrypted data: 448 bytes AES encrypted using the DH session key and
        +  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
        +448 bytes AES encrypted using the DH session key and
                           the last 16 bytes of HXxorHI (i.e., the last 16 bytes of message #1) as the IV
        +{%- endtrans %}
         
         
        -

        Notes: -

        • +

          {% trans %}Notes:{% endtrans %}

          +
            +
          • {% trans -%} Bob verifies the signature, and on failure, drops the connection. -
          • +{%- endtrans %}
          • +
          • {% trans -%} Bob may drop the connection if the clock skew with Alice is too high as calculated using tsA. -
          -

          +{%- endtrans %}
        • +
        -

        Message 4 (Session Confirm B)

        +

        {% trans %}Message 4 (Session Confirm B){% endtrans %}

        +

        {% trans -%} This is a DSA signature of the critical data. Bob sends Alice: +{%- endtrans %}

          *  <----------------------E(S(X+Y+Alice.identHash+tsA+tsB)+padding, sk, prev)
         
        -    Size: 48 bytes
        +    {% trans %}Size:{% endtrans %} 48 bytes
         
        -Unencrypted Contents: +

        {% trans %}Unencrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |                                       |
        @@ -347,16 +371,18 @@ Unencrypted Contents:
          +----+----+----+----+----+----+----+----+
         
         
        -  signature: the 40 byte DSA signature of the following concatenated data:
        -             X, Y, Alice's Router Identity, tsA, tsB.
        -             Bob signs it with the private signing key associated with the public signing key in his Router Identity
        +  signature: {% trans commonstructures=site_url('docs/spec/common-structures') -%}
        +the 40 byte DSA signature of the following concatenated data:
        +             X, Y, Alice's Router Identity, tsA, tsB.
        +             Bob signs it with the private signing key associated with the public signing key in his Router Identity
        +{%- endtrans %}
         
        -  padding: 8 bytes random data
        +  padding: {% trans %}8 bytes random data{% endtrans %}
         
         
        -Encrypted Contents: +

        {% trans %}Encrypted Contents:{% endtrans %}

          +----+----+----+----+----+----+----+----+
          |                                       |
        @@ -366,68 +392,82 @@ Encrypted Contents:
          |                                       |
          +----+----+----+----+----+----+----+----+
         
        -  encrypted data: 48 bytes AES encrypted using the DH session key and
        +  encrypted data: {% trans cryptography=site_url('docs/how/cryptography') -%}
        +48 bytes AES encrypted using the DH session key and
                           the last 16 bytes of the encrypted contents of message #2 as the IV
        +{%- endtrans %}
         
         
        -

        Notes: -

        • +

          Notes:

          +
          • {% trans -%} Alice verifies the signature, and on failure, drops the connection. -
          -

          +{%- endtrans %}
        -

        After Establishment

        -

        +

        {% trans %}After Establishment{% endtrans %}

        +

        {% trans -%} The connection is established, and standard or time sync messages may be exchanged. All subsequent messages are AES encrypted using the negotiated DH session key. Alice will use the last 16 bytes of the encrypted contents of message #3 as the next IV. Bob will use the last 16 bytes of the encrypted contents of message #4 as the next IV. -

        +{%- endtrans %}

        -

        Check Connection Message

        +

        {% trans %}Check Connection Message{% endtrans %}

        +

        {% trans -%} Alternately, when Bob receives a connection, it could be a check connection (perhaps prompted by Bob asking for someone to verify his listener). Check Connection is not currently used. However, for the record, check connections are formatted as follows. - A check info connection will receive 256 bytes containing: +A check info connection will receive 256 bytes containing: +{%- endtrans %}

          -
        • 32 bytes of uninterpreted, ignored data -
        • 1 byte size -
        • that many bytes making up the local router's IP address (as reached by the remote side) -
        • 2 byte port number that the local router was reached on -
        • 4 byte i2p network time as known by the remote side (seconds since the epoch) -
        • uninterpreted padding data, up to byte 223 -
        • xor of the local router's identity hash and the SHA256 of bytes 32 through bytes 223 +
        • {% trans %}32 bytes of uninterpreted, ignored data{% endtrans %}
        • +
        • {% trans %}1 byte size{% endtrans %}
        • +
        • {% trans %}that many bytes making up the local router's IP address (as reached by the remote side){% endtrans %}
        • +
        • {% trans %}2 byte port number that the local router was reached on{% endtrans %}
        • +
        • {% trans %}4 byte i2p network time as known by the remote side (seconds since the epoch){% endtrans %}
        • +
        • {% trans %}uninterpreted padding data, up to byte 223{% endtrans %}
        • +
        • {% trans %}xor of the local router's identity hash and the SHA256 of bytes 32 through bytes 223{% endtrans %}
        -

        Discussion

        -Now on the NTCP Discussion Page. +

        {% trans %}Discussion{% endtrans %}

        +

        {% trans ntcpdisc=site_url('docs/discussions/ntcp') -%} +Now on the NTCP Discussion Page. +{%- endtrans %}

        -

        Future Work

        -
        • +

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

          +
            +
          • {% trans -%} The maximum message size should be increased to approximately 32 KB. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} A set of fixed packet sizes may be appropriate to further hide the data fragmentation to external adversaries, but the tunnel, garlic, and end to end padding should be sufficient for most needs until then. However, there is currently no provision for padding beyond the next 16-byte boundary, to create a limited number of message sizes. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Memory utilization (including that of the kernel) for NTCP should be compared to that for SSU. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Can the establishment messages be randomly padded somehow, to frustrate identification of I2P traffic based on initial packet sizes? -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Review and possibly disable 'check connection' -
          -

          +{%- endtrans %}
        • +
        {% endblock %} diff --git a/i2p2www/pages/site/docs/transport/ssu.html b/i2p2www/pages/site/docs/transport/ssu.html index 1992bb64..a7ae3caa 100644 --- a/i2p2www/pages/site/docs/transport/ssu.html +++ b/i2p2www/pages/site/docs/transport/ssu.html @@ -1,50 +1,60 @@ {% extends "global/layout.html" %} -{% block title %}SSU Transport{% endblock %} -{% block lastupdated %}October 2012{% endblock %} +{% block title %}{% trans %}SSU Transport{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}October 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9.2{% endblock %} {% block content %} -

        Secure Semireliable UDP (SSU)

        -

        +

        {% trans %}Secure Semireliable UDP{% endtrans %} (SSU)

        +

        {% trans transports=site_url('docs/transport'), ntcp=site_url('docs/transport/ntcp') -%} SSU (also called "UDP" in much of the I2P documentation and user interfaces) -is one of two transports currently implemented in I2P. -The other is NTCP. -

        +is one of two transports currently implemented in I2P. +The other is NTCP. +{%- endtrans %}

        + +

        {% trans -%} SSU is the newer of the two transports, introduced in I2P release 0.6. In a standard I2P installation, the router uses both NTCP and SSU for outbound connections. +{%- endtrans %}

        -

        SSU Services

        +

        {% trans %}SSU Services{% endtrans %}

        +

        {% trans -%} Like the NTCP transport, SSU provides reliable, encrypted, connection-oriented, point-to-point data transport. Unique to SSU, it also provides IP detection and NAT traversal services, including: +{%- endtrans %}

          -
        • Cooperative NAT/Firewall traversal using introducers -
        • Local IP detection by inspection of incoming packets and peer testing -
        • Communication of firewall status and local IP, and changes to either to NTCP -
        • Communication of firewall status and local IP, and changes to either, to the router and the user interface +
        • {% trans %}Cooperative NAT/Firewall traversal using introducers{% endtrans %}
        • +
        • {% trans %}Local IP detection by inspection of incoming packets and peer testing{% endtrans %}
        • +
        • {% trans %}Communication of firewall status and local IP, and changes to either to NTCP{% endtrans %}
        • +
        • {% trans %}Communication of firewall status and local IP, and changes to either, to the router and the user interface{% endtrans %}
        -

        Protocol Details

        +

        {% trans %}Protocol Details{% endtrans %}

        -

        Congestion control

        +

        {% trans %}Congestion control{% endtrans %}

        -

        SSU's need for only semireliable delivery, TCP-friendly operation, +

        {% trans -%} +SSU's need for only semireliable delivery, TCP-friendly operation, and the capacity for high throughput allows a great deal of latitude in congestion control. The congestion control algorithm outlined below is -meant to be both efficient in bandwidth as well as simple to implement.

        +meant to be both efficient in bandwidth as well as simple to implement. +{%- endtrans %}

        -

        Packets are scheduled according to the router's policy, taking care +

        {% trans -%} +Packets are scheduled according to the router's policy, taking care not to exceed the router's outbound capacity or to exceed the measured capacity of the remote peer. The measured capacity operates along the lines of TCP's slow start and congestion avoidance, with additive increases to the sending capacity and multiplicative decreases in face of congestion. Unlike for TCP, routers may give up on some messages after a given period or number of retransmissions while continuing to transmit -other messages.

        +other messages. +{%- endtrans %}

        -

        The congestion detection techniques vary from TCP as well, since each +

        {% trans -%} +The congestion detection techniques vary from TCP as well, since each message has its own unique and nonsequential identifier, and each message has a limited size - at most, 32KB. To efficiently transmit this feedback to the sender, the receiver periodically includes a list of fully ACKed @@ -52,48 +62,62 @@ message identifiers and may also include bitfields for partially received messages, where each bit represents the reception of a fragment. If duplicate fragments arrive, the message should be ACKed again, or if the message has still not been fully received, the bitfield should be -retransmitted with any new updates.

        +retransmitted with any new updates. +{%- endtrans %}

        -

        The current implementation does not pad the packets to +

        {% trans -%} +The current implementation does not pad the packets to any particular size, but instead just places a single message fragment into a packet and sends it off (careful not to exceed the MTU). -

        +{%- endtrans %}

        MTU

        -

        +

        {% trans -%} As of router version 0.8.12, two MTU values are used: 620 and 1484. The MTU value is adjusted based on the percentage of packets that are retransmitted. -

        +{%- endtrans %}

        + +

        {% trans -%} For both MTU values, it is desirable that (MTU % 16) == 12, so that the payload portion after the 28-byte IP/UDP header is a multiple of 16 bytes, for encryption purposes. This calculation is for IPv4 only. While the protocol as specified supports IPv6 addresses, IPv6 is not yet implemented. -

        +{%- endtrans %}

        + +

        {% trans -%} For the small MTU value, it is desirable to pack a 2646-byte Variable Tunnel Build Message efficiently into multiple packets; with a 620-byte MTU, it fits into 5 packets with nicely. -

        +{%- endtrans %}

        + +

        {% trans -%} Based on measurements, 1492 fits nearly all reasonably small I2NP messages (larger I2NP messages may be up to 1900 to 4500 bytes, which isn't going to fit into a live network MTU anyway). -

        +{%- endtrans %}

        + +

        {% trans -%} The MTU values were 608 and 1492 for releases 0.8.9 - 0.8.11. The large MTU was 1350 prior to release 0.8.9. -

        +{%- endtrans %}

        + +

        {% trans -%} The maximum receive packet size is 1571 bytes as of release 0.8.12. For releases 0.8.9 - 0.8.11 it was 1535 bytes. Prior to release 0.8.9 it was 2048 bytes. -

        +{%- endtrans %}

        + +

        {% trans -%} As of release 0.9.2, if a router's network interface MTU is less than 1484, it will publish that in the network database, and other routers should honor that when a connection is established. -

        +{%- endtrans %}

        -

        Message Size Limits

        -

        +

        {% trans %}Message Size Limits{% endtrans %}

        +

        {% trans -%} While the maximum message size is nominally 32KB, the practical limit differs. The protocol limits the number of fragments to 7 bits, or 128. The current implementation, however, limits each message to a maximum of 64 fragments, @@ -102,97 +126,115 @@ Due to overhead for bundled LeaseSets and session keys, the practical limit at the application level is about 6KB lower, or about 26KB. Further work is necessary to raise the UDP transport limit above 32KB. For connections using the larger MTU, larger messages are possible. -

        +{%- endtrans %}

        -

        Keys

        +

        {% trans %}Keys{% endtrans %}

        -

        All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs. +

        {% trans -%} +All encryption used is AES256/CBC with 32 byte keys and 16 byte IVs. The MAC and session keys are negotiated as part of the DH exchange, used for the HMAC and encryption, respectively. Prior to the DH exchange, -the publicly knowable introKey is used for the MAC and encryption.

        +the publicly knowable introKey is used for the MAC and encryption. +{%- endtrans %}

        -

        When using the introKey, both the initial message and any subsequent +

        {% trans -%} +When using the introKey, both the initial message and any subsequent reply use the introKey of the responder (Bob) - the responder does not need to know the introKey of the requester (Alice). The DSA signing key used by Bob should already be known to Alice when she contacts him, though Alice's DSA key may not already be known by -Bob.

        +Bob. +{%- endtrans %}

        -

        Upon receiving a message, the receiver checks the "from" IP address and port +

        {% trans -%} +Upon receiving a message, the receiver checks the "from" IP address and port with all established sessions - if there are matches, that session's MAC keys are tested in the HMAC. If none of those verify or if there are no matching IP addresses, the receiver tries their introKey in the MAC. If that does not verify, the packet is dropped. If it does verify, it is interpreted according to the message type, though if the receiver is overloaded, -it may be dropped anyway.

        +it may be dropped anyway. +{%- endtrans %}

        -

        If Alice and Bob have an established session, but Alice loses the +

        {% trans -%} +If Alice and Bob have an established session, but Alice loses the keys for some reason and she wants to contact Bob, she may at any time simply establish a new session through the SessionRequest and related messages. If Bob has lost the key but Alice does not know that, she will first attempt to prod him to reply, by sending a DataMessage with the wantReply flag set, and if Bob continually fails to reply, she will assume the key is lost and reestablish a -new one.

        +new one. +{%- endtrans %}

        -

        For the DH key agreement, -RFC3526 2048bit -MODP group (#14) is used:

        +

        {% trans rfc3526='http://www.faqs.org/rfcs/rfc3526.html' -%} +For the DH key agreement, +RFC3526 2048bit +MODP group (#14) is used: +{%- endtrans %}

           p = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }
           g = 2
         
        -

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} These are the same p and g used for I2P's -ElGamal encryption. -

        +ElGamal encryption. +{%- endtrans %}

        -

        Replay prevention

        +

        {% trans %}Replay prevention{% endtrans %}

        -

        Replay prevention at the SSU layer occurs by rejecting packets +

        {% trans -%} +Replay prevention at the SSU layer occurs by rejecting packets with exceedingly old timestamps or those which reuse an IV. To detect duplicate IVs, a sequence of Bloom filters are employed to -"decay" periodically so that only recently added IVs are detected.

        +"decay" periodically so that only recently added IVs are detected. +{%- endtrans %}

        -

        The messageIds used in DataMessages are defined at layers above +

        {% trans -%} +The messageIds used in DataMessages are defined at layers above the SSU transport and are passed through transparently. These IDs are not in any particular order - in fact, they are likely to be entirely random. The SSU layer makes no attempt at messageId -replay prevention - higher layers should take that into account.

        +replay prevention - higher layers should take that into account. +{%- endtrans %}

        -

        Addressing

        +

        {% trans %}Addressing{% endtrans %}

        -

        To contact an SSU peer, one of two sets of information is necessary: -a direct address, for when the peer is publicly reachable, or an -indirect address, for using a third party to introduce the peer. -There is no restriction on the number of addresses a peer may have.

        +

        {% trans -%} +To contact an SSU peer, one of two sets of information is necessary: +a direct address, for when the peer is publicly reachable, or an +indirect address, for using a third party to introduce the peer. +There is no restriction on the number of addresses a peer may have. +{%- endtrans %}

             Direct: host, port, introKey, options
           Indirect: tag, relayhost, port, relayIntroKey, targetIntroKey, options
         
        -

        Each of the addresses may also expose a series of options - special +

        {% trans -%} +Each of the addresses may also expose a series of options - special capabilities of that particular peer. For a list of available -capabilities, see below.

        +capabilities, see below. +{%- endtrans %}

        -

        -The addresses, options, and capabilities are published in the network database. -

        +

        {% trans netdb=site_url('docs/how/network-database') -%} +The addresses, options, and capabilities are published in the network database. +{%- endtrans %}

        -

        Direct Session Establishment

        -

        +

        {% trans %}Direct Session Establishment{% endtrans %}

        +

        {% trans -%} Direct session establishment is used when no third party is required for NAT traversal. The message sequence is as follows: -

        +{%- endtrans %}

        -

        Connection establishment (direct)

        -

        +

        {% trans %}Connection establishment (direct){% endtrans %}

        +

        {% trans -%} Alice connects directly to Bob. -

        +{%- endtrans %}

                 Alice                         Bob
             SessionRequest --------------------->
        @@ -203,28 +245,35 @@ Alice connects directly to Bob.
             DatabaseStoreMessage --------------->
             Data <---------------------------> Data
         
        -

        + +

        {% trans i2npspec=site_url('docs/spec/i2np') -%} After the SessionConfirmed message is received, Bob sends a small -DeliveryStatus message +DeliveryStatus message as a confirmation. In this message, the 4-byte message ID is set to a random number, and the 8-byte "arrival time" is set to the current network-wide ID, which is 2 (i.e. 0x0000000000000002). -

        +{%- endtrans %}

        + +

        {% trans i2npspec=site_url('docs/spec/i2np'), +commonstructures=site_url('docs/spec/common-structures') -%} After the status message is sent, the peers exchange -DatabaseStore messages +DatabaseStore messages containing their -RouterInfos. -

        +RouterInfos. +{%- endtrans %}

        + +

        {% trans -%} It does not appear that the type of the status message or its contents matters. It was originally added becasue the DatabaseStore message was delayed several seconds; since the store is now sent immediately, perhaps the status message can be eliminated. -

        +{%- endtrans %}

        -

        Introduction

        +

        {% trans %}Introduction{% endtrans %}

        -

        Introduction keys are delivered through an external channel +

        {% trans -%} +Introduction keys are delivered through an external channel (the network database, where they are identical to the router Hash for now) and must be used when establishing a session key. For the indirect address, the peer must first contact the relayhost and ask them for @@ -234,9 +283,11 @@ peer telling them to contact the requesting peer, and also gives the requesting peer the IP and port on which the addressed peer is located. In addition, the peer establishing the connection must already know the public keys of the peer they are connecting to (but -not necessary to any intermediary relay peer).

        +not necessary to any intermediary relay peer). +{%- endtrans %}

        -

        Indirect session establishment by means of a third party introduction +

        {% trans -%} +Indirect session establishment by means of a third party introduction is necessary for efficient NAT traversal. Charlie, a router behind a NAT or firewall which does not allow unsolicited inbound UDP packets, first contacts a few peers, choosing some to serve as introducers. Each @@ -251,7 +302,8 @@ Alice back a RelayResponse packet containing Charlie's public IP and port number. When Charlie receives the RelayIntro packet, he sends off a small random packet to Alice's IP and port (poking a hole in his NAT/firewall), and when Alice receives Bob's RelayResponse packet, she begins a new -full direction session establishment with the specified IP and port.

        +full direction session establishment with the specified IP and port. +{%- endtrans %}

        -

        Connection establishment (indirect using an introducer)

        +

        {% trans %}Connection establishment (indirect using an introducer){% endtrans %}

        +

        {% trans -%} Alice first connects to introducer Bob, who relays the request to Charlie. +{%- endtrans %}

                 Alice                         Bob                  Charlie
        @@ -279,18 +333,20 @@ Alice first connects to introducer Bob, who relays the request to Charlie.
             Data <--------------------------------------------------> Data
         
        -

        +

        {% trans -%} After the hole punch, the session is established between Alice and Charlie as in a direct establishment. -

        +{%- endtrans %}

        -

        Peer testing

        +

        {% trans %}Peer testing{% endtrans %}

        -

        The automation of collaborative reachability testing for peers is +

        {% trans -%} +The automation of collaborative reachability testing for peers is enabled by a sequence of PeerTest messages. With its proper execution, a peer will be able to determine their own reachability and may update its behavior accordingly. The testing process is -quite simple:

        +quite simple: +{%- endtrans %}

                 Alice                  Bob                  Charlie
        @@ -303,147 +359,193 @@ quite simple:

        <------------------------------------------PeerTest
        -

        Each of the PeerTest messages carry a nonce identifying the +

        {% trans -%} +Each of the PeerTest messages carry a nonce identifying the test series itself, as initialized by Alice. If Alice doesn't get a particular message that she expects, she will retransmit accordingly, and based upon the data received or the messages missing, she will know her reachability. The various end states -that may be reached are as follows:

        +that may be reached are as follows: +{%- endtrans %}

          -
        • If she doesn't receive a response from Bob, she will retransmit +
        • {% trans -%} +If she doesn't receive a response from Bob, she will retransmit up to a certain number of times, but if no response ever arrives, she will know that her firewall or NAT is somehow misconfigured, rejecting all inbound UDP packets even in direct response to an outbound packet. Alternately, Bob may be down or unable to get -Charlie to reply.
        • +Charlie to reply. +{%- endtrans %} -
        • If Alice doesn't receive a PeerTest message with the +
        • {% trans -%} +If Alice doesn't receive a PeerTest message with the expected nonce from a third party (Charlie), she will retransmit her initial request to Bob up to a certain number of times, even if she has received Bob's reply already. If Charlie's first message still doesn't get through but Bob's does, she knows that she is behind a NAT or firewall that is rejecting unsolicited connection attempts and that port forwarding is not operating properly (the -IP and port that Bob offered up should be forwarded).
        • +IP and port that Bob offered up should be forwarded). +{%- endtrans %} -
        • If Alice receives Bob's PeerTest message and both of Charlie's +
        • {% trans -%} +If Alice receives Bob's PeerTest message and both of Charlie's PeerTest messages but the enclosed IP and port numbers in Bob's and Charlie's second messages don't match, she knows that she is behind a symmetric NAT, rewriting all of her outbound packets with different 'from' ports for each peer contacted. She will need to explicitly forward a port and always have that port exposed for -remote connectivity, ignoring further port discovery.
        • +remote connectivity, ignoring further port discovery. +{%- endtrans %} -
        • If Alice receives Charlie's first message but not his second, +
        • {% trans -%} +If Alice receives Charlie's first message but not his second, she will retransmit her PeerTest message to Charlie up to a certain number of times, but if no response is received she knows -that Charlie is either confused or no longer online.
        • +that Charlie is either confused or no longer online. +{%- endtrans %}
        -

        Alice should choose Bob arbitrarily from known peers who seem +

        {% trans -%} +Alice should choose Bob arbitrarily from known peers who seem to be capable of participating in peer tests. Bob in turn should choose Charlie arbitrarily from peers that he knows who seem to be capable of participating in peer tests and who are on a different IP from both Bob and Alice. If the first error condition occurs (Alice doesn't get PeerTest messages from Bob), Alice may decide -to designate a new peer as Bob and try again with a different nonce.

        +to designate a new peer as Bob and try again with a different nonce. +{%- endtrans %}

        -

        Alice's introduction key is included in all of the PeerTest +

        {% trans -%} +Alice's introduction key is included in all of the PeerTest messages so that she doesn't need to already have an established session with Bob and so that Charlie can contact her without knowing any additional information. Alice may go on to establish a session -with either Bob or Charlie, but it is not required.

        +with either Bob or Charlie, but it is not required. +{%- endtrans %}

        -

        Transmission window, ACKs and Retransmissions

        -

        +

        {% trans %}Transmission window, ACKs and Retransmissions{% endtrans %}

        +

        {% trans ssuspec=site_url('docs/spec/ssu') -%} The DATA message may contain ACKs of full messages and partial ACKs of individual fragments of a message. See the data message section of -the protocol specification page +the protocol specification page for details. -

        +{%- endtrans %}

        + +

        {% trans streaming=site_url('docs/api/streaming') -%} The details of windowing, ACK, and retransmission strategies are not specified here. See the Java code for the current implementation. During the establishment phase, and for peer testing, routers should implement exponential backoff for retransmission. For an established connection, routers should implement an adjustable transmission window, RTT estimate and timeout, similar to TCP -or streaming. +or streaming. See the code for initial, min and max parameters. -

        +{%- endtrans %}

        -

        Security

        -

        +

        {% trans %}Security{% endtrans %}

        +

        {% trans -%} UDP source addresses may, of course, be spoofed. Additionally, the IPs and ports contained inside specific SSU messages (RelayRequest, RelayResponse, RelayIntro, PeerTest) may not be legitimate. Also, certain actions and responses may need to be rate-limited. -

        +{%- endtrans %}

        + +

        {% trans -%} The details of validation are not specified here. Implementers should add defenses where appropriate. -

        +{%- endtrans %}

        -

        Peer capabilities

        +

        {% trans %}Peer capabilities{% endtrans %}

        B
        -
        If the peer address contains the 'B' capability, that means - they are willing and able to participate in peer tests as - a 'Bob' or 'Charlie'.
        +
        {% trans -%} +If the peer address contains the 'B' capability, that means +they are willing and able to participate in peer tests as +a 'Bob' or 'Charlie'. +{%- endtrans %}
        C
        -
        If the peer address contains the 'C' capability, that means - they are willing and able to serve as an introducer - serving - as a Bob for an otherwise unreachable Alice.
        +
        {% trans -%} +If the peer address contains the 'C' capability, that means +they are willing and able to serve as an introducer - serving +as a Bob for an otherwise unreachable Alice. +{%- endtrans %}
        -

        Future Work

        -
        • +

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

          +
            +
          • {% trans -%} Analysis of current SSU performance, including assessment of window size adjustment and other parameters, and adjustment of the protocol implementation to improve performance, is a topic for future work. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The current implementation repeatedly sends acknowledgments for the same packets, which unnecessarily increases overhead. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The default small MTU value of 620 should be analyzed and possibly increased. The current MTU adjustment strategy should be evaluated. Does a streaming lib 1730-byte packet fit in 3 small SSU packets? Probably not. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The protocol should be extended to exchange MTUs during the setup. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Rekeying is currently unimplemented and may never be. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} The potential use of the 'challenge' fields in RelayIntro and RelayResponse, and use of the padding field in SessionRequest and SessionCreated, is undocumented. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} Instead of a single fragment per packet, a more efficient strategy may be to bundle multiple message fragments into the same packet, so long as it doesn't exceed the MTU. -
          • +{%- endtrans %}
          • + +
          • {% trans -%} A set of fixed packet sizes may be appropriate to further hide the data fragmentation to external adversaries, but the tunnel, garlic, and end to end padding should be sufficient for most needs until then. -
          • -Why are introduction keys the same as the router hash, should it be changed, would there be any benefit? -
          • -Capacities appear to be unused. -
          • -Signed-on times in SessionCreated and SessionConfirmed appear to be unused or unverified. -
          +{%- endtrans %}
        • -

          Implementation Diagram

          +
        • {% trans -%} +Why are introduction keys the same as the router hash, should it be changed, would there be any benefit? +{%- endtrans %}
        • + +
        • {% trans -%} +Capacities appear to be unused. +{%- endtrans %}
        • + +
        • {% trans -%} +Signed-on times in SessionCreated and SessionConfirmed appear to be unused or unverified. +{%- endtrans %}
        • +
        + +

        {% trans %}Implementation Diagram{% endtrans %}

        +

        {% trans -%} This diagram should accurately reflect the current implementation, however there may be small differences. +{%- endtrans %}

        -

        Specification

        -Now on the SSU specification page. +

        {% trans %}Specification{% endtrans %}

        +{% trans %}Now on the SSU specification page{% endtrans %}. {% endblock %} From 9b9145e185e21b29287ad2c59fc53a299b09cfbb Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 5 Feb 2013 23:23:58 +0000 Subject: [PATCH 394/498] Started adding translation tags to docs/spec/* --- i2p2www/pages/site/docs/spec/blockfile.html | 117 +++-- .../site/docs/spec/common-structures.html | 494 ++++++++++-------- .../pages/site/docs/spec/configuration.html | 119 +++-- i2p2www/pages/site/docs/spec/datagrams.html | 133 +++-- i2p2www/pages/site/docs/spec/updates.html | 113 ++-- 5 files changed, 540 insertions(+), 436 deletions(-) diff --git a/i2p2www/pages/site/docs/spec/blockfile.html b/i2p2www/pages/site/docs/spec/blockfile.html index b3709af3..5077195a 100644 --- a/i2p2www/pages/site/docs/spec/blockfile.html +++ b/i2p2www/pages/site/docs/spec/blockfile.html @@ -1,17 +1,17 @@ {% extends "global/layout.html" %} -{% block title %}I2P Blockfile Specification{% endblock %} -{% block lastupdated %}January 2012{% endblock %} +{% block title %}{% trans %}I2P Blockfile Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}January 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.8.12{% endblock %} {% block content %} -

        -Blockfile and Hosts Database Specification -

        -

        Overview

        -

        +

        {% trans %}Blockfile and Hosts Database Specification{% endtrans %}

        +

        {% trans %}Overview{% endtrans %}

        +

        {% trans naming=site_url('docs/naming') -%} This document specifies the I2P blockfile file format -and the tables in the hostsdb.blockfile used by the Blockfile Naming Service. -

        +and the tables in the hostsdb.blockfile used by the Blockfile Naming Service. +{%- endtrans %}

        + +

        {% trans -%} The blockfile provides fast Destination lookup in a compact format. While the blockfile page overhead is substantial, the destinations are stored in binary rather than in Base 64 as in the hosts.txt format. In addition, the blockfile provides the capability of arbitrary metadata storage @@ -19,30 +19,37 @@ In addition, the blockfile provides the capability of arbitrary metadata storage The metadata may be used in the future to provide advanced addressbook features. The blockfile storage requirement is a modest increase over the hosts.txt format, and the blockfile provides approximately 10x reduction in lookup times. -

        +{%- endtrans %}

        + +

        {% trans url='http://www.metanotion.net/software/sandbox/block.html' -%} A blockfile is simply on-disk storage of multiple sorted maps (key-value pairs), implemented as skiplists. The blockfile format is adopted from the -Metanotion Blockfile Database. +Metanotion Blockfile Database. First we will define the file format, then the use of that format by the BlockfileNamingService. +{%- endtrans %}

        -

        Blockfile Format

        -

        +

        {% trans %}Blockfile Format{% endtrans %}

        +

        {% trans -%} The original blockfile spec was modified to add magic numbers to each page. The file is structured in 1024-byte pages. Pages are numbered starting from 1. The "superblock" is always at page 1, i.e. starting at byte 0 in the file. The metaindex skiplist is always at page 2, i.e. starting at byte 1024 in the file. -

        +{%- endtrans %}

        + +

        {% trans -%} All 2-byte integer values are unsigned. All 4-byte integer values (page numbers) are signed and negative values are illegal. -

        +{%- endtrans %}

        + +

        {% trans -%} The database is designed to be opened and accessed by a single thread. The BlockfileNamingService provides synchronization. -

        +{%- endtrans %}

        -

        +

        {% trans -%} Superblock format: -

        +{%- endtrans %}

         Byte	Contents
         0-5	Magic number	0x3141de493250 ("1A" 0xde "I2P")
        @@ -55,9 +62,9 @@ Byte	Contents
         24-1023	unused
         
        -

        +

        {% trans -%} Skip list block page format: -

        +{%- endtrans %}

         Byte	Contents
         0-7	Magic number	0x536b69704c697374 "SkipList"
        @@ -70,10 +77,10 @@ Byte	Contents
         
        -

        +

        {% trans -%} Skip level block page format is as follows. All levels have a span. Not all spans have levels. -

        +{%- endtrans %}

         Byte	Contents
         0-7	Magic number	0x42534c6576656c73 "BSLevels"
        @@ -85,12 +92,12 @@ remaining bytes unused
         
        -

        +

        {% trans -%} Skip span block page format is as follows. Key/value structures are sorted by key within each span and across all spans. Key/value structures are sorted by key within each span. Spans other than the first span may not be empty. -

        +{%- endtrans %}

         Byte	Contents
         0-3	Magic number	0x5370616e "Span"
        @@ -102,9 +109,9 @@ Byte	Contents
         20-1023	key/value structures
         
        -

        +

        {% trans -%} Span Continuation block page format: -

        +{%- endtrans %}

         Byte	Contents
         0-3	Magic number	0x434f4e54 "CONT"
        @@ -113,14 +120,14 @@ Byte	Contents
         
        -

        +

        {% trans -%} Key/value structure format is as follows. Key and value lengths must not be split across pages, i.e. all 4 bytes must be on the same page. If there is not enough room the last 1-3 bytes of a page are unused and the lengths will be at offset 8 in the continuation page. Key and value data may be split across pages. Max key and value lengths are 65535 bytes. -

        +{%- endtrans %}

         Byte	Contents
         0-1	key length in bytes
        @@ -129,9 +136,9 @@ Byte	Contents
         	value data
         
        -

        +

        {% trans -%} Free list block page format: -

        +{%- endtrans %}

         Byte	Contents
         0-7	Magic number	0x2366724c69737423 "#frList#"
        @@ -141,32 +148,32 @@ Byte	Contents
         
        -

        +

        {% trans -%} Free page block format: -

        +{%- endtrans %}

         Byte	Contents
         0-7	Magic number	0x7e2146524545217e "~!FREE!~"
         8-1023	unused
         
        -

        +

        {% trans -%} The metaindex (located at page 2) is a mapping of US-ASCII strings to 4-byte integers. The key is the name of the skiplist and the value is the page index of the skiplist. -

        +{%- endtrans %}

        -

        Blockfile Naming Service Tables

        -

        +

        {% trans %}Blockfile Naming Service Tables{% endtrans %}

        +

        {% trans -%} The tables created and used by the BlockfileNamingService are as follows. The maximum number of entries per span is 16. -

        +{%- endtrans %}

        -

        Properties Skiplist

        -

        -"%%__INFO__%%" is the master database skiplist with String/Properties key/value entries containing only one entry: -

        +

        {% trans %}Properties Skiplist{% endtrans %}

        +

        {% trans -%} +"%%__INFO__%%" is the master database skiplist with String/Properties key/value entries containing only one entry: +{%- endtrans %}

        -    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
        +    "info": a Properties (UTF-8 String/String Map), serialized as a Mapping:
                     "version":   "2"
                     "created":   Java long time (ms)
                     "upgraded":  Java long time (ms) (as of database version 2)
        @@ -174,14 +181,14 @@ The maximum number of entries per span is 16.
                                  searched in-order for lookups. Almost always "privatehosts.txt,userhosts.txt,hosts.txt".
         
        -

        Reverse Lookup Skiplist

        -

        +

        {% trans %}Reverse Lookup Skiplist{% endtrans %}

        +

        {% trans -%} "%%__REVERSE__%%" is the reverse lookup skiplist with Integer/Properties key/value entries (as of database version 2): -

        +{%- endtrans %}

             The skiplist keys are 4-byte Integers, the first 4 bytes of the hash of the Destination.
        -    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
        +    The skiplist values are each a Properties (a UTF-8 String/String Map) serialized as a Mapping
                 There may be multiple entries in the properties, each one is a reverse mapping,
                    as there may be more than one hostname for a given destination,
                    or there could be collisions with the same first 4 bytes of the hash.
        @@ -189,28 +196,30 @@ The maximum number of entries per span is 16.
                 Each property value is the empty string.
         
        -

        hosts.txt, userhosts.txt, and privatehosts.txt Skiplists

        -

        +

        {% trans %}hosts.txt, userhosts.txt, and privatehosts.txt Skiplists{% endtrans %}

        +

        {% trans -%} For each host database, there is a skiplist containing the hosts for that database. The keys/values in these skiplists are as follows: -

        +{%- endtrans %}

              key:    a UTF-8 String (the hostname)
        -     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
        -             followed by a binary Destination (serialized as usual).
        +     value:  a DestEntry, which is a Properties (a UTF-8 String/String Map) serialized as a Mapping
        +             followed by a binary Destination (serialized as usual).
         
        -

        +

        {% trans -%} The DestEntry Properties typically contains: -

        +{%- endtrans %}

                     "a":     The time added (Java long time in ms)
                     "s":     The original source of the entry (typically a file name or subscription URL)
                     others:  TBD
         
        -

        + +

        {% trans -%} Hostname keys are stored in lower-case and always end in ".i2p". +{%- endtrans %}

        {% endblock %} diff --git a/i2p2www/pages/site/docs/spec/common-structures.html b/i2p2www/pages/site/docs/spec/common-structures.html index ed8c102e..7dacf0e6 100644 --- a/i2p2www/pages/site/docs/spec/common-structures.html +++ b/i2p2www/pages/site/docs/spec/common-structures.html @@ -1,182 +1,184 @@ {% extends "global/layout.html" %} -{% block title %}Common structure Specification{% endblock %} -{% block lastupdated %}March 2012{% endblock %} +{% block title %}{% trans %}Common structure Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}March 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.8.13{% endblock %} {% block content %} -

        Data types Specification

        -

        - This document describes some data types common to all I2P protocols, like - I2NP, - I2CP, - SSU, - etc. -

        +

        {% trans %}Data types Specification{% endtrans %}

        +

        {% trans i2np=site_url('docs/protocol/i2np'), +i2cp=site_url('docs/protocol/i2cp'), +ssu=site_url('docs/transport/ssu') -%} +This document describes some data types common to all I2P protocols, like +I2NP, I2CP, +SSU, etc. +{%- endtrans %}

        Integer

        -

        Description

        -

        - Represents a non-negative integer. -

        -

        Contents

        -

        - 1 to 8 bytes in network byte order representing an unsigned integer -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +Represents a non-negative integer. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +1 to 8 bytes in network byte order representing an unsigned integer +{% endtrans %}

        Date

        -

        Description

        -

        - The number of milliseconds since midnight on January 1, 1970 in the GMT timezone. - If the number is 0, the date is undefined or null. -

        -

        Contents

        -

        - 8 byte Integer -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +The number of milliseconds since midnight on January 1, 1970 in the GMT timezone. +If the number is 0, the date is undefined or null. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +8 byte Integer +{% endtrans %}

        String

        -

        Description

        -

        - Represents a UTF-8 encoded string. -

        -

        Contents

        -

        - 1 or more bytes where the first byte is the number of bytes (not characters!) - in the string and the remaining 0-255 bytes are the non-null terminated UTF-8 encoded character array. - Length limit is 255 bytes (not characters). Length may be 0. -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +Represents a UTF-8 encoded string. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +1 or more bytes where the first byte is the number of bytes (not characters!) +in the string and the remaining 0-255 bytes are the non-null terminated UTF-8 encoded character array. +Length limit is 255 bytes (not characters). Length may be 0. +{% endtrans %}

        Boolean

        -

        Description

        -

        - A boolean value, supporting null/unknown representation - 0=false, 1=true, 2=unknown/null -

        -

        Contents

        -

        - 1 byte Integer -

        -

        Notes

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +A boolean value, supporting null/unknown representation +0=false, 1=true, 2=unknown/null +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +1 byte Integer +{% endtrans %}

        +

        {% trans %}Notes{% endtrans %}

        +

        {% trans -%} Deprecated - unused +{% endtrans %}

        PublicKey

        -

        Description

        -

        - This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in - the cryptography specification. -

        -

        Contents

        -

        - 256 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} +This structure is used in ElGamal encryption, representing only the exponent, not the primes, which are constant and defined in +the cryptography specification. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +256 bytes +{% endtrans %}

        Javadoc

        PrivateKey

        -

        Description

        -

        - This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in - the cryptography specification. -

        -

        Contents

        -

        - 256 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} +This structure is used in ElGamal decryption, representing only the exponent, not the primes which are constant and defined in +the cryptography specification. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +256 bytes +{% endtrans %}

        Javadoc

        SessionKey

        -

        Description

        -

        - This structure is used for AES256 encryption and decryption. -

        -

        Contents

        -

        - 32 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +This structure is used for AES256 encryption and decryption. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +32 bytes +{% endtrans %}

        Javadoc

        SigningPublicKey

        -

        Description

        -

        - This structure is used for verifying DSA signatures. -

        -

        Contents

        -

        - 128 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} +This structure is used for verifying DSA signatures. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +128 bytes +{% endtrans %}

        Javadoc

        SigningPrivateKey

        -

        Description

        -

        - This structure is used for creating DSA signatures. -

        -

        Contents

        -

        - 20 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} +This structure is used for creating DSA signatures. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +20 bytes +{% endtrans %}

        Javadoc

        Signature

        -

        Description

        -

        - This structure represents the DSA signature of some data. -

        -

        Contents

        -

        - 40 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans cryptography=site_url('docs/how/cryptography') -%} +This structure represents the DSA signature of some data. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +40 bytes +{% endtrans %}

        Javadoc

        Hash

        -

        Description

        -

        - Represents the SHA256 of some data. -

        -

        Contents

        -

        - 32 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +Represents the SHA256 of some data. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +32 bytes +{% endtrans %}

        Javadoc

        Session Tag

        -

        Description

        -

        - A random number -

        -

        Contents

        -

        - 32 bytes -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +A random number +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +32 bytes +{% endtrans %}

        Javadoc

        TunnelId

        -

        Description

        -

        - Defines an identifier that is unique to each router in a tunnel. -

        -

        Contents

        -

        - 4 byte Integer -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +Defines an identifier that is unique to each router in a tunnel. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +4 byte Integer +{% endtrans %}

        Javadoc

        Certificate

        -

        Description

        -

        - A certificate is a container for various receipts or proof of works used throughout the I2P network. -

        -

        Contents

        -

        - 1 byte Integer specifying certificate type, followed by a 2 Integer specifying the size of the certificate payload, then that many bytes. -

        +

        {% trans %}Description{% endtrans %}

        +

        {% trans -%} +A certificate is a container for various receipts or proof of works used throughout the I2P network. +{% endtrans %}

        +

        {% trans %}Contents{% endtrans %}

        +

        {% trans -%} +1 byte Integer specifying certificate type, followed by a 2 Integer specifying the size of the certificate payload, then that many bytes. +{% endtrans %}

         {% filter escape %}
         +----+----+----+----+----+--//
        @@ -200,31 +202,38 @@ payload :: data
         {% endfilter %}
         
        -

        Notes

        +

        {% trans %}Notes{% endtrans %}

          -
        • +
        • {% trans -%} For Router Identities, the Certificate is always NULL, no others are currently implemented. -
        • -For Garlic Cloves, the Certificate is always NULL, no others are currently implemented. -
        • -For Garlic Messages, the Certificate is always NULL, no others are currently implemented. -
        • +{%- endtrans %}
        • + +
        • {% trans i2np=site_url('docs/spec/i2np') -%} +For Garlic Cloves, the Certificate is always NULL, no others are currently implemented. +{%- endtrans %}
        • + +
        • {% trans i2np=site_url('docs/spec/i2np') -%} +For Garlic Messages, the Certificate is always NULL, no others are currently implemented. +{%- endtrans %}
        • + +
        • {% trans -%} For Destinations, the Certificate may be non-NULL, however non-NULL certs are not widely used, and any checking is left to the application-level. -
        +{%- endtrans %} +

      Javadoc

      Mapping

      -

      Description

      -

      - A set of key/value mappings or properties -

      -

      Contents

      -

      - A 2-byte size Integer followed by a series of String=String; pairs -

      +

      {% trans %}Description{% endtrans %}

      +

      {% trans -%} +A set of key/value mappings or properties +{% endtrans %}

      +

      {% trans %}Contents{% endtrans %}

      +

      {% trans -%} +A 2-byte size Integer followed by a series of String=String; pairs +{% endtrans %}

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -249,40 +258,51 @@ val string :: String
       {% endfilter %}
       
      -

      Notes

      +

      {% trans %}Notes{% endtrans %}

        -
      • +
      • {% trans -%} The encoding isn't optimal - we either need the '=' and ';' characters, or the string lengths, but not both -
      • +{%- endtrans %}
      • + +
      • {% trans -%} Some documentation says that the strings may not include '=' or ';' but this encoding supports them -
      • +{%- endtrans %}
      • + +
      • {% trans -%} Strings are defined to be UTF-8 but in the current implementation, I2CP uses UTF-8 but I2NP does not. For example, UTF-8 strings in a RouterInfo options mapping in a I2NP Database Store Message will be corrupted. -
      • +{%- endtrans %}
      • + +
      • {% trans -%} Mappings contained in I2NP messages (i.e. in a RouterAddress or RouterInfo) must be sorted by key so that the signature will be invariant. -
      • +{%- endtrans %}
      • + +
      • {% trans -%} Key and value string length limits are 255 bytes (not characters) each, plus the length byte. Length byte may be 0. -
      • +{%- endtrans %}
      • + +
      • {% trans -%} Total length limit is 65535 bytes, plus the 2 byte size field, or 65537 total. +{%- endtrans %}

      Javadoc

      -

      Common structure specification

      +

      {% trans %}Common structure specification{% endtrans %}

      RouterIdentity

      -

      Description

      -

      - Defines the way to uniquely identify a particular router -

      -

      Contents

      -

      - PublicKey followed by SigningPublicKey and then a Certificate -

      +

      {% trans %}Description{% endtrans %}

      +

      {% trans -%} +Defines the way to uniquely identify a particular router +{% endtrans %}

      +

      {% trans %}Contents{% endtrans %}

      +

      {% trans -%} +PublicKey followed by SigningPublicKey and then a Certificate +{% endtrans %}

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -318,20 +338,22 @@ Total length: 387+ bytes
       {% endfilter %}
       
      -

      Notes

      +

      {% trans %}Notes{% endtrans %}

      +

      {% trans -%} The certificate for a RouterIdentity is currently unused and is always NULL. +{%- endtrans %}

      Javadoc

      Destination

      -

      Description

      -

      - A Destination defines a particular endpoint to which messages can be directed for secure delivery. -

      -

      Contents

      -

      - PublicKey followed by a SigningPublicKey and then a Certificate -

      +

      {% trans %}Description{% endtrans %}

      +

      {% trans -%} +A Destination defines a particular endpoint to which messages can be directed for secure delivery. +{% endtrans %}

      +

      {% trans %}Contents{% endtrans %}

      +

      {% trans -%} +PublicKey followed by a SigningPublicKey and then a Certificate +{% endtrans %}

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -370,15 +392,15 @@ Total length: 387+ bytes
       

      Javadoc

      Lease

      -

      Description

      -

      - Defines the authorization for a particular tunnel to receive messages targeting a Destination. -

      -

      Contents

      -

      - SHA256 Hash of the - RouterIdentity of the gateway router, then the TunnelId, and finally an end Date -

      +

      {% trans %}Description{% endtrans %}

      +

      {% trans -%} +Defines the authorization for a particular tunnel to receive messages targeting a Destination. +{% endtrans %}

      +

      {% trans %}Contents{% endtrans %}

      +

      {% trans -%} +SHA256 Hash of the +RouterIdentity of the gateway router, then the TunnelId, and finally an end Date +{% endtrans %}

       {% filter escape %}
       +----+----+----+----+----+----+----+----+
      @@ -406,27 +428,29 @@ end_date :: Date
       {% endfilter %}
       
      -

      Notes

      +

      {% trans %}Notes{% endtrans %}

        -
      • +
      • {% trans -%} Total size: 44 bytes -
      +{%- endtrans %} +

    Javadoc

    LeaseSet

    -

    Description

    -

    - Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be encrypted, - and then the public key that can be used to revoke this particular version of the structure. The LeaseSet is one of the two structures stored in the network database( - the other being RouterInfo), and is keyed under the SHA256 of the contained Destination. -

    -

    Contents

    -

    - Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to revoke this version of the LeaseSet, - then a 1 byte Integer specifying how many Lease structures are in the set, followed by the actual Lease structures and finally a Signature of the previous - bytes signed by the Destination's SigningPrivateKey +

    {% trans %}Description{% endtrans %}

    +

    {% trans -%} +Contains all of the currently authorized Leases for a particular Destination, the PublicKey to which garlic messages can be encrypted, +and then the public key that can be used to revoke this particular version of the structure. The LeaseSet is one of the two structures stored in the network database( +the other being RouterInfo), and is keyed under the SHA256 of the contained Destination. +{% endtrans %}

    +

    {% trans %}Contents{% endtrans %}

    +

    {% trans -%} +Destination, followed by a PublicKey for encryption, then a SigningPublicKey which can be used to revoke this version of the LeaseSet, +then a 1 byte Integer specifying how many Lease structures are in the set, followed by the actual Lease structures and finally a Signature of the previous +bytes signed by the Destination's SigningPrivateKey +{%- endtrans %}

     {% filter escape %}
     +----+----+----+----+----+----+----+----+
    @@ -514,35 +538,43 @@ signature :: Signature
     {% endfilter %}
     
    -

    Notes

    -
    • +

      {% trans %}Notes{% endtrans %}

      +
        +
      • {% trans -%} The public key of the destination was used for the old i2cp-to-i2cp encryption which was disabled in version 0.6, it is currently unused? -
      • -The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption. +{%- endtrans %}
      • + +
      • {% trans elgamalaes=site_url('docs/how/elgamal-aes') -%} +The encryption key is used for end-to-end ElGamal/AES+SessionTag encryption. It is currently generated anew at every router startup, it is not persistent. -
      • +{%- endtrans %}
      • + +
      • {% trans -%} The signature may be verified using the signing public key of the destination. -
      • +{%- endtrans %}
      • + +
      • {% trans -%} The signing_key is currently unused. It was intended for LeaseSet revocation, which is unimplemented. It is currently generated anew at every router startup, it is not persistent. -
      +{%- endtrans %}
    • +

    Javadoc

    RouterAddress

    -

    Description

    -

    - This structure defines the means to contact a router through a transport protocol. -

    -

    Contents

    -

    - 1 byte Integer defining the relative cost of using the address, where 0 is free and 255 is expensive, followed by the expiration Date after which the address should not be used, or if null, the address never expires. - After that comes a String defining the transport protocol this router address uses. Finally there is a Mapping containing all of the transport specific options necessary to establish the connection, such as - IP address, port number, email address, URL, etc. -

    +

    {% trans %}Description{% endtrans %}

    +

    {% trans -%} +This structure defines the means to contact a router through a transport protocol. +{% endtrans %}

    +

    {% trans %}Contents{% endtrans %}

    +

    {% trans -%} +1 byte Integer defining the relative cost of using the address, where 0 is free and 255 is expensive, followed by the expiration Date after which the address should not be used, or if null, the address never expires. +After that comes a String defining the transport protocol this router address uses. Finally there is a Mapping containing all of the transport specific options necessary to establish the connection, such as +IP address, port number, email address, URL, etc. +{% endtrans %}

     {% filter escape %}
     +----+
    @@ -573,27 +605,30 @@ options :: Mapping
     {% endfilter %}
     
    -

    Notes

    +

    {% trans %}Notes{% endtrans %}

      -
    • +
    • {% trans -%} Cost is typically 5 or 6 for SSU, and 10 or 11 for NTCP. -
    • +{%- endtrans %}
    • + +
    • {% trans -%} Expiration is currently unused, always null (all zeroes)) -
    +{%- endtrans %} +

    Javadoc

    RouterInfo

    -

    Description

    -

    - Defines all of the data that a router wants to publish for the network to see. The RouterInfo is one of two structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of - the contained RouterIdentity. -

    -

    Contents

    -

    - RouterIdentity followed by the Date, when the entry was published -

    +

    {% trans %}Description{% endtrans %}

    +

    {% trans -%} +Defines all of the data that a router wants to publish for the network to see. The RouterInfo is one of two structures stored in the network database(the other being LeaseSet, and is keyed under the SHA256 of +the contained RouterIdentity. +{% endtrans %}

    +

    {% trans %}Contents{% endtrans %}

    +

    {% trans -%} +RouterIdentity followed by the Date, when the entry was published +{% endtrans %}

     {% filter escape %}
     +----+----+----+----+----+----+----+----+
    @@ -671,16 +706,21 @@ signature :: Signature
     {% endfilter %}
     
    -

    Notes

    +

    {% trans %}Notes{% endtrans %}

    +

    {% trans -%} The peer_size Integer may be followed by a list of that many router hashes. This is currently unused. It was intended for a form of restricted routes, which is unimplemented. -

    +{% endtrans %}

    + +

    {% trans -%} The signature may be verified using the signing public key of the router_ident. +{% endtrans %}

    Javadoc

    Delivery Instructions

    -Defined in the Tunnel Message Specification. - +

    {% trans tunnelmessage=site_url('docs/spec/tunnel-message') -%} +Defined in the Tunnel Message Specification. +{% endtrans %}

    {% endblock %} diff --git a/i2p2www/pages/site/docs/spec/configuration.html b/i2p2www/pages/site/docs/spec/configuration.html index 4cd384ae..1080f830 100644 --- a/i2p2www/pages/site/docs/spec/configuration.html +++ b/i2p2www/pages/site/docs/spec/configuration.html @@ -1,104 +1,107 @@ {% extends "global/layout.html" %} -{% block title %}Configuration File Specification{% endblock %} -{% block lastupdated %}September 2012{% endblock %} +{% block title %}{% trans %}Configuration File Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}September 2012{% endtrans %}{% endblock %} {% block accuratefor %}0.9.2{% endblock %} {% block content %} -

    Overview

    -

    +

    {% trans %}Overview{% endtrans %}

    +

    {% trans -%} This page provides a general specification of I2P configuration files, used by the router and various applications. It also gives an overview of the information contained in the various files, and links to detailed documentation where available. -

    +{%- endtrans %}

    -

    General Format

    -

    +

    {% trans %}General Format{% endtrans %}

    +

    {% trans url='http://docs.oracle.com/javase/1.5.0/docs/api/java/util/Properties.html#load%28java.io.InputStream%29' -%} An I2P configuration file is formatted as specified in -Java Properties +Java Properties with the following exceptions: +{%- endtrans %}

      -
    • Encoding must be UTF-8 -
    • Does not use or recognize any escapes, including '\', so lines may not be continued -
    • '#' or ';' starts a comment, but '!' does not -
    • '#' starts a comment in any position but ';' must be in column 1 to start a comment -
    • Leading and trailing whitespace is not trimmed on keys -
    • Leading and trailing whitespace is trimmed on values -
    • '=' is the only key-termination character (not ':' or whitespace) -
    • Lines without '=' are ignored. It does not store the key with a value of "" -
    • As there are no escapes, - keys may not contain '#', '=', or '\n', or start with ';' -
    • As there are no escapes, - values may not contain '#' or '\n', or start or end with '\r' or whitespace +
    • {% trans %}Encoding must be UTF-8{% endtrans %}
    • +
    • {% trans %}Does not use or recognize any escapes, including '\', so lines may not be continued{% endtrans %}
    • +
    • {% trans %}'#' or ';' starts a comment, but '!' does not{% endtrans %}
    • +
    • {% trans %}'#' starts a comment in any position but ';' must be in column 1 to start a comment{% endtrans %}
    • +
    • {% trans %}Leading and trailing whitespace is not trimmed on keys{% endtrans %}
    • +
    • {% trans %}Leading and trailing whitespace is trimmed on values{% endtrans %}
    • +
    • {% trans %}'=' is the only key-termination character (not ':' or whitespace){% endtrans %}
    • +
    • {% trans %}Lines without '=' are ignored. It does not store the key with a value of ""{% endtrans %}
    • +
    • {% trans %}As there are no escapes, keys may not contain '#', '=', or '\n', or start with ';'{% endtrans %}
    • +
    • {% trans %}As there are no escapes, values may not contain '#' or '\n', or start or end with '\r' or whitespace{% endtrans %}
    -

    + +

    {% trans -%} The file need not be sorted, but most applications do sort by key when writing to the file, for ease of reading and manual editing. -

    +{%- endtrans %}

    + +

    {% trans url='http://docs.i2p-projekt.de/javadoc/net/i2p/data/DataHelper.html', +commonstructures=site_url('docs/spec/common-structures') -%} Reads and writes are implemented in -DataHelper loadProps() and storeProps(). +DataHelper loadProps() and storeProps(). Note that the file format is significantly different than the serialized format for I2P protocols specified in -Mapping. -

    +Mapping. +{%- endtrans %}

    -

    Core library and router

    +

    {% trans %}Core library and router{% endtrans %}

    -

    Clients (clients.config)

    -

    +

    {% trans %}Clients{% endtrans %} (clients.config)

    +

    {% trans -%} Configured via /configclients in the router console. -

    +{%- endtrans %}

    -

    Logger (logger.config)

    -

    +

    {% trans %}Logger{% endtrans %} (logger.config)

    +

    {% trans -%} Configured via /configlogging in the router console. -

    +{%- endtrans %}

    -

    Individual Plugin (xxx/plugin.config)

    -

    -See the plugin specification. -

    +

    {% trans %}Individual Plugin{% endtrans %} (xxx/plugin.config)

    +

    {% trans pluginspec=site_url('docs/spec/plugin') -%} +See the plugin specification. +{%- endtrans %}

    -

    Plugins (plugins.config)

    -

    -Enable/disable for each installed plugin.. -

    +

    {% trans %}Plugins{% endtrans %} (plugins.config)

    +

    {% trans -%} +Enable/disable for each installed plugin. +{%- endtrans %}

    -

    Router (router.config)

    -

    +

    {% trans %}Router{% endtrans %} (router.config)

    +

    {% trans -%} Configured via /configadvanced in the router console. -

    +{%- endtrans %}

    -

    Applications

    +

    {% trans %}Applications{% endtrans %}

    -

    Addressbook (addressbook/config.txt)

    -

    +

    {% trans %}Addressbook{% endtrans %} (addressbook/config.txt)

    +

    {% trans -%} See documentation in SusiDNS. -

    +{%- endtrans %}

    I2PSnark (i2psnark.config)

    -

    +

    {% trans -%} Configured via the application gui. -

    +{%- endtrans %}

    I2PTunnel (i2ptunnel.config)

    -

    +

    {% trans -%} Configured via the /i2ptunnel application in the router console. -

    +{%- endtrans %}

    -

    Router Console

    -

    +

    {% trans %}Router Console{% endtrans %}

    +

    {% trans -%} The router console uses the router.config file. -

    +{%- endtrans %}

    SusiMail (susimail.config)

    -

    +

    {% trans -%} See post on zzz.i2p. -

    - +{%- endtrans %}

    + {% endblock %} diff --git a/i2p2www/pages/site/docs/spec/datagrams.html b/i2p2www/pages/site/docs/spec/datagrams.html index 0ea4ce19..cc55da37 100644 --- a/i2p2www/pages/site/docs/spec/datagrams.html +++ b/i2p2www/pages/site/docs/spec/datagrams.html @@ -1,100 +1,120 @@ {% extends "global/layout.html" %} -{% block title %}Datagram Specification{% endblock %} -{% block lastupdated %}August 2010{% endblock %} +{% block title %}{% trans %}Datagram Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

    Datagram Overview

    -

    Datagrams build upon the base I2CP to provide authenticated +

    {% trans %}Datagram Overview{% endtrans %}

    +

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

    -

    -Datagrams, like streaming library packets, +message and sender are authenticated by signing the payload. +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    Application Guide

    -

    Applications written in Java may use the -datagram API, +

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

    +

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

    +{%- endtrans %}

    -

    Datagram Length

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    +{%- endtrans %}

    -

    I2CP Protocol Number and Ports

    -

    +

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

    +

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

    -

    +{%- endtrans %}

    + +

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

    -

    +the I2CP page. +{%- endtrans %}

    + +

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

    -

    +{%- endtrans %}

    + +

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

    +I2PSessionMuxedImpl. +{%- endtrans %}

    -

    Data Integrity

    +

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

    +

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

    -

    Packet Encapsulation

    +

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

    +

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

    +

    {% trans %}Specification{% endtrans %}

    -

    Specification

    - -

    Non-Repliable Datagrams

    +

    {% trans %}Non-Repliable Datagrams{% endtrans %}

    +

    {% trans -%} Non-repliable datagrams have no 'from' address and are not authenticated. They are also called "raw" datagrams. Strictly speaking, they are not "datagrams" at all, they are just raw data. They are not handled by the datagram API. However, SAM and the I2PTunnel classes support "raw datagrams". +{%- endtrans %}

    -

    Format

    +

    {% trans %}Format{% endtrans %}

     +----+----+----+----+----//
     | payload...
    @@ -104,16 +124,20 @@ However, SAM and the I2PTunnel classes support "raw datagrams".
     Length: 0 - unlimited (see notes)
     
    -

    Notes

    +

    {% trans %}Notes{% endtrans %}

    +

    {% trans tunnelmessage=site_url('docs/spec/tunnel-message'), +transports=site_url('docs/transport') -%} The practical length is limited by lower layers of protocols - the -tunnel message spec +tunnel message spec limits messages to about 61.2 KB and the -transports +transports currently limit messages to about 32 KB, although this may be raised in the future. +{%- endtrans %}

    - -

    Repliable Datagrams

    +

    {% trans %}Repliable Datagrams{% endtrans %}

    +

    {% trans -%} Repliable datagrams contain a 'from' address and a signature. These add 427 bytes of overhead. +{%- endtrans %}

    Format

     +----+----+----+----+----+----+----+----+
    @@ -142,11 +166,11 @@ Repliable datagrams contain a 'from' address and a signature. These add 427 byte
     
     
     
    -from      :: a Destination
    +from      :: a Destination
                    length: 387+ bytes
                    The originator and signer of the datagram
     
    -signature :: a Signature
    +signature :: a Signature
                  length: 40 bytes
                  The DSA signature of the SHA256 hash of the payload, which may be verified by the
                  DSA signing public key of the 'from' Destination
    @@ -159,12 +183,13 @@ Total length: Payload length + 427+
     
     
    -

    Notes

    +

    {% trans %}Notes{% endtrans %}

    +

    {% trans transports=site_url('docs/transport') -%} The practical length is limited by lower layers of protocols - the -transports +transports currently limit messages to about 32 KB, so the data length here is limited to about 31.5 KB. - +{%- endtrans %}

    diff --git a/i2p2www/pages/site/docs/spec/updates.html b/i2p2www/pages/site/docs/spec/updates.html index 72e1d2bf..6a69f1d3 100644 --- a/i2p2www/pages/site/docs/spec/updates.html +++ b/i2p2www/pages/site/docs/spec/updates.html @@ -1,71 +1,85 @@ {% extends "global/layout.html" %} -{% block title %}I2P Software Update Specification{% endblock %} -{% block lastupdated %}November 2011{% endblock %} +{% block title %}{% trans %}I2P Software Update Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}November 2011{% endtrans %}{% endblock %} {% block accuratefor %}0.8.12{% endblock %} {% block content %} -

    Overview

    -

    +

    {% trans %}Overview{% endtrans %}

    +

    {% trans -%} I2P uses a simple, yet secure, system for automated software update. The router console periodically pulls a news file from a configurable I2P URL. There is a hardcoded backup URL pointing to the project website, in case the default project news host goes down. -

    +{%- endtrans %}

    + +

    {% trans -%} The contents of the news file are displayed on the home page of the router console. In addition, the news file contains the most recent version number of the software. If the version is higher than the router's version number, it will display an indication to the user that an update is available. -

    +{%- endtrans %}

    + +

    {% trans -%} The router may optionally download, or download and install, the new version if configured to do so. -

    +{%- endtrans %}

    -

    News File Specification

    -

    +

    {% trans %}News File Specification{% endtrans %}

    +

    {% trans -%} The news.xml file may contain the following elements: -

    +{%- endtrans %}

     <i2p.news date="$Date: 2010-01-22 00:00:00 $" />
     <i2p.release version="0.7.14" date="2010/01/22" minVersion="0.6" />
     
    -

    +

    {% trans -%} The elements may be included inside XML comments to prevent interpretation by browsers. The i2p.release element and version are required. All others are optional and are currently unused. -

    +{%- endtrans %}

    + +

    {% trans -%} The news source is trusted only to indicate that a new version is available. It does not specify the URL of the update, the checksum, or any other information. -

    +{%- endtrans %}

    -

    Update File Specification

    -

    +

    {% trans %}Update File Specification{% endtrans %}

    +

    {% trans -%} The signed update file, traditionally named i2pupdate.sud, is simply a zip file with a prepended 56 byte header. The header contains: +{%- endtrans %}

      -
    • -A 40-byte DSA signature -
    • +
    • {% trans commonstructures=site_url('docs/spec/common-structures') -%} +A 40-byte DSA signature +{%- endtrans %}
    • +
    • {% trans -%} A 16-byte I2P version in UTF-8, padded with trailing zeroes if necessary -
    -

    +{%- endtrans %} + + +

    {% trans commonstructures=site_url('docs/spec/common-structures') -%} The signature covers only the zip archive - not the prepended version. -The signature must match one of the DSA public keys configured into the router, +The signature must match one of the DSA public keys configured into the router, which has a hardcoded default list of keys of the current project release managers. -

    +{%- endtrans %}

    + +

    {% trans -%} For version comparison purposes, version fields contain [0-9]*, field separators are '-', '_', and '.', and all other characters are ignored. -

    +{%- endtrans %}

    + +

    {% trans -%} As of version 0.8.8, the version must also be specified as a zip file comment in UTF-8, without the trailing zeroes. The updating router verifes that the version in the header (not covered by the signature) matches the version in the zip file comment, which is covered by the signature. This prevents spoofing of the version number in the header. -

    +{%- endtrans %}

    -

    Download and Installation

    -

    +

    {% trans %}Download and Installation{% endtrans %}

    +

    {% trans -%} The router first downloads the header of the update file from one in a configurable list of I2P URLs, using the built-in HTTP client and proxy, and checks that the version is newer. @@ -74,45 +88,58 @@ The router then downloads the full update file. The router verifies that the update file version is newer before installation. It also, of course, verifies the signature, and verifes that the zip file comment matches the header version, as explained above. -

    +{%- endtrans %}

    + +

    {% trans -%} The zip file is extracted in the base $I2P installation directory. -

    +{%- endtrans %}

    + +

    {% trans -%} As of release 0.7.12, the router supports Pack200 decompression. Files inside the zip archive with a .jar.pack or .war.pack suffix are transparently decompressed to a .jar or .war file. Update files containing .pack files are traditionally named with a '.su2' suffix. Pack200 shrinks the update files by about 60%. -

    +{%- endtrans %}

    + +

    {% trans -%} As of release 0.8.7, the router will delete the libjbigi.so and libjcpuid.so files if the zip archive contains a lib/jbigi.jar file, so that the new files will be extracted from jbigi.jar. -

    +{%- endtrans %}

    + +

    {% trans -%} As of release 0.8.12, if the zip archive contains a file deletelist.txt, the router will delete the files listed there. The format is: -

    • -One file name per line -
    • -All file names are relative to the installation directory; no absolute file names allowed, no files starting with ".." -
    • -Comments start with '#' -
    +{%- endtrans %}

    +
      +
    • {% trans %}One file name per line{% endtrans %}
    • +
    • {% trans %}All file names are relative to the installation directory; no absolute file names allowed, no files starting with ".."{% endtrans %}
    • +
    • {% trans %}Comments start with '#'{% endtrans %}
    • +
    + +

    {% trans -%} The router will then delete the deletelist.txt file. -

    +{%- endtrans %}

    -

    Future Work

    -
    • +

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

      +
        +
      • {% trans -%} When a new update file specification is defined, it should use a larger DSA signature, and the signature should cover the version. A file format version number might be a good idea too. -
      • +{%- endtrans %}
      • +
      • {% trans -%} The network will eventually grow too large for update over HTTP. The built-in BitTorrent client, i2psnark, may be used as a distributed update method. This development effort was started in 2009 but is on hold until it is required. -
      • +{%- endtrans %}
      • +
      • {% trans -%} The router update mechanism is part of the web router console. There is currently no provision for updates of an embedded router lacking the router console. -
      +{%- endtrans %}
    • +
    From 5494286c55a7282a8a3600a43cea5e29215c4dd0 Mon Sep 17 00:00:00 2001 From: str4d Date: Tue, 5 Feb 2013 23:32:57 +0000 Subject: [PATCH 395/498] Split the datagrams page between docs/api/ and docs/spec/ --- i2p2www/legacy.py | 2 +- i2p2www/pages/global/nav.html | 1 + i2p2www/pages/site/docs/api/datagrams.html | 114 ++++++++++++++++++++ i2p2www/pages/site/docs/spec/datagrams.html | 102 +----------------- 4 files changed, 119 insertions(+), 100 deletions(-) create mode 100644 i2p2www/pages/site/docs/api/datagrams.html diff --git a/i2p2www/legacy.py b/i2p2www/legacy.py index c185e8e8..685dc8c5 100644 --- a/i2p2www/legacy.py +++ b/i2p2www/legacy.py @@ -34,7 +34,7 @@ LEGACY_PAGES_MAP={ 'configuration': 'docs/spec/configuration', 'contact': 'about/contact', 'cvs': 'misc/cvs', - 'datagrams': 'docs/spec/datagrams', + 'datagrams': 'docs/api/datagrams', 'dev-guidelines': 'volunteer/guides/dev-guidelines', 'developerskeys': 'volunteer/develop/developers-keys', 'donate': 'volunteer/donate', diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index 558a9b33..b1051bb7 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -45,6 +45,7 @@
  • +
  • diff --git a/i2p2www/pages/site/docs/api/datagrams.html b/i2p2www/pages/site/docs/api/datagrams.html new file mode 100644 index 00000000..176bd237 --- /dev/null +++ b/i2p2www/pages/site/docs/api/datagrams.html @@ -0,0 +1,114 @@ +{% extends "global/layout.html" %} +{% block title %}{% trans %}Datagrams{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} +{% block accuratefor %}0.8{% endblock %} +{% block content %} +

    {% trans %}Datagram Overview{% endtrans %}

    +

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

    + +

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

    + +

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

    +

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

    + +

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

    +

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

    + +

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

    + +

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

    +

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

    + +

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

    + +

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

    + +

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

    + +

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

    +

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

    + +

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

    +

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

    + +

    {% trans %}Specification{% endtrans %}

    + +

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

    + + + +{% endblock %} diff --git a/i2p2www/pages/site/docs/spec/datagrams.html b/i2p2www/pages/site/docs/spec/datagrams.html index cc55da37..a64a328e 100644 --- a/i2p2www/pages/site/docs/spec/datagrams.html +++ b/i2p2www/pages/site/docs/spec/datagrams.html @@ -3,105 +3,9 @@ {% block lastupdated %}{% trans %}August 2010{% endtrans %}{% endblock %} {% block accuratefor %}0.8{% endblock %} {% block content %} -

    {% trans %}Datagram Overview{% endtrans %}

    -

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

    - -

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

    - -

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

    -

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

    - -

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

    -

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

    - -

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

    - -

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

    -

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

    - -

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

    - -

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

    - -

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

    - -

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

    -

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

    - -

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

    -

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

    +

    {% trans -%} +See the Datagrams page for an overview of the Datagrams API. +{%- endtrans %}

    {% trans %}Specification{% endtrans %}

    From d5a8e1b958f28bb3cd0326c3f8b2f34123f08221 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 6 Feb 2013 00:27:20 +0000 Subject: [PATCH 396/498] Split streaming library page between docs/api/ and docs/spec/ --- i2p2www/pages/global/nav.html | 1 + i2p2www/pages/site/docs/api/streaming.html | 125 +----------------- i2p2www/pages/site/docs/spec/streaming.html | 135 ++++++++++++++++++++ 3 files changed, 139 insertions(+), 122 deletions(-) create mode 100644 i2p2www/pages/site/docs/spec/streaming.html diff --git a/i2p2www/pages/global/nav.html b/i2p2www/pages/global/nav.html index b1051bb7..286e00e8 100644 --- a/i2p2www/pages/global/nav.html +++ b/i2p2www/pages/global/nav.html @@ -73,6 +73,7 @@
  • +
  • diff --git a/i2p2www/pages/site/docs/api/streaming.html b/i2p2www/pages/site/docs/api/streaming.html index 13616fa8..b6d5601d 100644 --- a/i2p2www/pages/site/docs/api/streaming.html +++ b/i2p2www/pages/site/docs/api/streaming.html @@ -282,129 +282,10 @@ How long to block on write/flush, in milliseconds. Negative means indefinitely.

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

    -

    {% trans %}Packet Format{% endtrans %}

    -

    {% trans -%} -The format of a single packet in the streaming protocol is: -{%- endtrans %}

    -
     
    -+----+----+----+----+----+----+----+----+
    -| send Stream ID    | rcv Stream ID     |
    -+----+----+----+----+----+----+----+----+
    -| sequence  Num     | ack Through       |
    -+----+----+----+----+----+----+----+----+
    -| nc |   NACKs ...
    -+----+----+----+----+----+----+----+----+
    -     | rd |  flags  | opt size| opt data
    -+----+----+----+----+----+----+----+----+
    -   ...                                  |
    -+----+----+----+----+----+----+----+----+
    -|   payload ...
    -+----+----+----+----//
    -
    -
    -
    - - -
    {{ _('Field') }}{{ _('Length') }}{{ _('Contents') }} -
    sendStreamId 4 byte IntegerRandom number selected by the connection recipient -and constant for the life of the connection. -0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received, -containing the peer's stream ID. - -
    receiveStreamId 4 byte IntegerRandom number selected by the connection originator -and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet. - -
    sequenceNum 4 byte Integer -The sequence for this message, starting at 0 in the SYN message, -and incremented by 1 in each message except for plain ACKs and retransmissions. -If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK -packet that should not be ACKed. - -
    ackThrough 4 byte Integer -The highest packet sequence number that was received -on the receiveStreamId. This field is ignored on the initial -connection packet (where receiveStreamId is the unknown id) or -if the NO_ACK flag set. -All packets up to and including this sequence number are ACKed, -EXCEPT for those listed in NACKs below. - -
    NACK count1 byte Integer -The number of 4-byte NACKs in the next field - -
    NACKs n * 4 byte Integers -Sequence numbers less than ackThrough that are not yet received. -Two NACKs of a packet is a request for a 'fast retransmit' of that packet. - -
    resendDelay1 byte Integer -How long is the creator of this packet going to wait before -resending this packet (if it hasn't yet been ACKed). The -value is seconds since the packet was created. -Currently ignored on receive. - -
    flags 2 byte value -See below. - -
    option size2 byte Integer -The number of bytes in the next field - -
    option data0 or more bytes -As specified by the flags. See below. - -
    payload remaining packet size -
    - -

    {% trans %}Flags and Option Data Fields{% endtrans %}

    -

    {% trans -%} -The flags field above specifies some metadata about the packet, and in -turn may require certain additional data to be included. The flags are -as follows. Any data structures specified must be added to the options area -in the given order. -{%- endtrans %}

    - -

    -Bit order: 15....0 (15 is MSB) -

    - -
    BitFlagOption DataFunction -
    0SYNCHRONIZE-- -Similar to TCP SYN. Set in the initial packet and in the first response. -FROM_INCLUDED and SIGNATURE_INCLUDED must be set also. -
    1CLOSE-- -Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response -will contain both SYNCHRONIZE and CLOSE. -SIGNATURE_INCLUDED must be set also. -
    2RESET-- -Abnormal close. -SIGNATURE_INCLUDED must be set also. -
    3SIGNATURE_INCLUDED40 byte DSA Signature - -Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where it is required. -The signature uses the Destination's DSA signing keys -to sign the entire header and payload with the 40-byte space in the option data field -for the signature being set to all zeroes. -
    4SIGNATURE_REQUESTED-- -Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED -
    5FROM_INCLUDED387+ byte Destination - -Currently sent only with SYNCHRONIZE, where it is required. -
    6DELAY_REQUESTED2 byte Integer -Optional delay. -How many milliseconds the sender of this packet wants the recipient -to wait before sending any more data. -A value greater than 60000 indicates choking. -
    7MAX_PACKET_SIZE_INCLUDED2 byte Integer -Currently sent with SYNCHRONIZE only. -Was also sent in retransmitted packets until release 0.9.1. -
    8PROFILE_INTERACTIVE-- -Unused or ignored; the interactive profile is unimplemented. -
    9ECHO-- -Unused except by ping programs -
    10NO_ACK-- -This flag simply tells the recipient to ignore the ackThrough field in the header. -Currently unused, the ackThrough field is always valid. -
    11-15unused -
    +

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

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

    diff --git a/i2p2www/pages/site/docs/spec/streaming.html b/i2p2www/pages/site/docs/spec/streaming.html new file mode 100644 index 00000000..05db8ba0 --- /dev/null +++ b/i2p2www/pages/site/docs/spec/streaming.html @@ -0,0 +1,135 @@ +{% extends "global/layout.html" %} +{% block title %}{% trans %}Streaming Library Specification{% endtrans %}{% endblock %} +{% block lastupdated %}{% trans %}November 2012{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.3{% endblock %} +{% block content %} +

    {% trans -%} +See the Streaming page for an overview of the Streaming Library. +{%- endtrans %}

    + +

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

    +

    {% trans %}Packet Format{% endtrans %}

    +

    {% trans -%} +The format of a single packet in the streaming protocol is: +{%- endtrans %}

    +
    +
    ++----+----+----+----+----+----+----+----+
    +| send Stream ID    | rcv Stream ID     |
    ++----+----+----+----+----+----+----+----+
    +| sequence  Num     | ack Through       |
    ++----+----+----+----+----+----+----+----+
    +| nc |   NACKs ...
    ++----+----+----+----+----+----+----+----+
    +     | rd |  flags  | opt size| opt data
    ++----+----+----+----+----+----+----+----+
    +   ...                                  |
    ++----+----+----+----+----+----+----+----+
    +|   payload ...
    ++----+----+----+----//
    +
    +
    +
    + + +
    {{ _('Field') }}{{ _('Length') }}{{ _('Contents') }} +
    sendStreamId 4 byte IntegerRandom number selected by the connection recipient +and constant for the life of the connection. +0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received, +containing the peer's stream ID. + +
    receiveStreamId 4 byte IntegerRandom number selected by the connection originator +and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet. + +
    sequenceNum 4 byte Integer +The sequence for this message, starting at 0 in the SYN message, +and incremented by 1 in each message except for plain ACKs and retransmissions. +If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK +packet that should not be ACKed. + +
    ackThrough 4 byte Integer +The highest packet sequence number that was received +on the receiveStreamId. This field is ignored on the initial +connection packet (where receiveStreamId is the unknown id) or +if the NO_ACK flag set. +All packets up to and including this sequence number are ACKed, +EXCEPT for those listed in NACKs below. + +
    NACK count1 byte Integer +The number of 4-byte NACKs in the next field + +
    NACKs n * 4 byte Integers +Sequence numbers less than ackThrough that are not yet received. +Two NACKs of a packet is a request for a 'fast retransmit' of that packet. + +
    resendDelay1 byte Integer +How long is the creator of this packet going to wait before +resending this packet (if it hasn't yet been ACKed). The +value is seconds since the packet was created. +Currently ignored on receive. + +
    flags 2 byte value +See below. + +
    option size2 byte Integer +The number of bytes in the next field + +
    option data0 or more bytes +As specified by the flags. See below. + +
    payload remaining packet size +
    + +

    {% trans %}Flags and Option Data Fields{% endtrans %}

    +

    {% trans -%} +The flags field above specifies some metadata about the packet, and in +turn may require certain additional data to be included. The flags are +as follows. Any data structures specified must be added to the options area +in the given order. +{%- endtrans %}

    + +

    +Bit order: 15....0 (15 is MSB) +

    + +
    BitFlagOption DataFunction +
    0SYNCHRONIZE-- +Similar to TCP SYN. Set in the initial packet and in the first response. +FROM_INCLUDED and SIGNATURE_INCLUDED must be set also. +
    1CLOSE-- +Similar to TCP FIN. If the response to a SYNCHRONIZE fits in a single message, the response +will contain both SYNCHRONIZE and CLOSE. +SIGNATURE_INCLUDED must be set also. +
    2RESET-- +Abnormal close. +SIGNATURE_INCLUDED must be set also. +
    3SIGNATURE_INCLUDED40 byte DSA Signature + +Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where it is required. +The signature uses the Destination's DSA signing keys +to sign the entire header and payload with the 40-byte space in the option data field +for the signature being set to all zeroes. +
    4SIGNATURE_REQUESTED-- +Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED +
    5FROM_INCLUDED387+ byte Destination + +Currently sent only with SYNCHRONIZE, where it is required. +
    6DELAY_REQUESTED2 byte Integer +Optional delay. +How many milliseconds the sender of this packet wants the recipient +to wait before sending any more data. +A value greater than 60000 indicates choking. +
    7MAX_PACKET_SIZE_INCLUDED2 byte Integer +Currently sent with SYNCHRONIZE only. +Was also sent in retransmitted packets until release 0.9.1. +
    8PROFILE_INTERACTIVE-- +Unused or ignored; the interactive profile is unimplemented. +
    9ECHO-- +Unused except by ping programs +
    10NO_ACK-- +This flag simply tells the recipient to ignore the ackThrough field in the header. +Currently unused, the ackThrough field is always valid. +
    11-15unused +
    + +{% endblock %} From b455e878c7f27349cf0c0b15abccf113fd69c79c Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 6 Feb 2013 01:55:33 +0000 Subject: [PATCH 397/498] Assorted internal and external URL fixes --- i2p2www/pages/site/about/browser-config.html | 4 +-- i2p2www/pages/site/about/hall-of-fame.html | 6 ++--- i2p2www/pages/site/about/intro.html | 4 +-- .../pages/site/about/performance/history.html | 5 ++-- i2p2www/pages/site/about/team.html | 2 +- i2p2www/pages/site/comparison/freenet.html | 4 +-- .../pages/site/comparison/other-networks.html | 14 +++++----- i2p2www/pages/site/contact.html | 2 +- i2p2www/pages/site/docs/api/i2pcontrol.html | 2 +- i2p2www/pages/site/docs/api/sam.html | 12 ++++----- i2p2www/pages/site/docs/api/samv2.html | 12 ++++----- i2p2www/pages/site/docs/api/samv3.html | 12 ++++----- i2p2www/pages/site/docs/api/streaming.html | 2 +- .../site/docs/applications/supported.html | 12 ++++----- .../pages/site/docs/discussions/netdb.html | 8 +++--- i2p2www/pages/site/docs/how/cryptography.html | 5 ++-- .../pages/site/docs/how/garlic-routing.html | 2 +- i2p2www/pages/site/docs/how/intro.html | 5 ++-- .../pages/site/docs/how/network-database.html | 2 +- .../pages/site/docs/how/peer-selection.html | 6 ++--- i2p2www/pages/site/docs/how/threat-model.html | 8 +++--- i2p2www/pages/site/docs/index.html | 2 +- i2p2www/pages/site/docs/spec/streaming.html | 26 +++++++++---------- 23 files changed, 80 insertions(+), 77 deletions(-) diff --git a/i2p2www/pages/site/about/browser-config.html b/i2p2www/pages/site/about/browser-config.html index ac2056bd..e3b56988 100644 --- a/i2p2www/pages/site/about/browser-config.html +++ b/i2p2www/pages/site/about/browser-config.html @@ -91,10 +91,10 @@ that only set amount of accesses are allowed per client. Once the limit is reached, the client is blocked out for a timeframe of 1min/1h/1 day. Be respectful and do not overload these services with too many requests! {%- endtrans %}

    -

    {% trans -%} +

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

    diff --git a/i2p2www/pages/site/about/hall-of-fame.html b/i2p2www/pages/site/about/hall-of-fame.html index 346feb8a..833f8ff9 100644 --- a/i2p2www/pages/site/about/hall-of-fame.html +++ b/i2p2www/pages/site/about/hall-of-fame.html @@ -14,11 +14,11 @@ Current balance: as of {{ date }} {% trans euroval='100.0' %}{{ euroval }} €{% endtrans %}
    {{ _('I2PHex bounty') }}: {% trans euroval='60.0' %}{{ euroval }} €{% endtrans %}
    -{{ _('I2P in debian mirrors') }}: +{{ _('I2P in debian mirrors') }}: {% trans euroval='113.0' %}{{ euroval }} €{% endtrans %}
    -{{ _('Bitcoin client for I2P') }}: +{{ _('Bitcoin client for I2P') }}: {% trans euroval='30.0', btcval='118.34' %}{{ euroval }} € and {{ btcval }} BTC{% endtrans %}
    -{{ _('Unit Tests for I2P router') }}: +{{ _('Unit Tests for I2P router') }}: {% trans euroval='2700' %}{{ euroval }} €{% endtrans %}
    {{ _('Bounty Robert') }}: 0
    {{ _('Bounty Syndie') }}: 100 BTC
    diff --git a/i2p2www/pages/site/about/intro.html b/i2p2www/pages/site/about/intro.html index 5c979f5b..4516f101 100644 --- a/i2p2www/pages/site/about/intro.html +++ b/i2p2www/pages/site/about/intro.html @@ -66,8 +66,8 @@ technique to run an anonymous IRC network (where the IRC server is hosted anonymously, and standard IRC clients use an I2PTunnel to contact it). There are other application development efforts going on as well, such as one to build an optimized swarming file transfer application (a la -BitTorrent), a -distributed data store (a la Freenet / +BitTorrent), a +distributed data store (a la Freenet / MNet), and a blogging system (a fully distributed LiveJournal), but those are not ready for use yet. diff --git a/i2p2www/pages/site/about/performance/history.html b/i2p2www/pages/site/about/performance/history.html index f8984dac..59f92ba9 100644 --- a/i2p2www/pages/site/about/performance/history.html +++ b/i2p2www/pages/site/about/performance/history.html @@ -9,13 +9,14 @@ for current issues and thoughts.

    {{ _('Native math') }}

    [{{ _('implemented') }}] -

    {% trans modpow='http://java.sun.com/j2se/1.4.2/docs/api/java/math/BigInteger.html#modPow(java.math.BigInteger,%20java.math.BigInteger)', +

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

    diff --git a/i2p2www/pages/site/about/team.html b/i2p2www/pages/site/about/team.html index bbdff18f..68974c6e 100644 --- a/i2p2www/pages/site/about/team.html +++ b/i2p2www/pages/site/about/team.html @@ -37,7 +37,7 @@ network. {{ _('manage the project mirrors') }} - {% trans monotone=site_url('get-involved/develop/monotone') %}Monotone guru{% endtrans %} + {% trans monotone=site_url('get-involved/guides/monotone') %}Monotone guru{% endtrans %} welterde, eche|on {{ _('manage the public monotone repositories') }} diff --git a/i2p2www/pages/site/comparison/freenet.html b/i2p2www/pages/site/comparison/freenet.html index 1597cf79..cc4c1dbe 100644 --- a/i2p2www/pages/site/comparison/freenet.html +++ b/i2p2www/pages/site/comparison/freenet.html @@ -13,7 +13,7 @@ built applications on top of it to do more generic anonymous communication, such static websites and message boards. {%- endtrans %}

    -

    {% trans -%} +

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

    diff --git a/i2p2www/pages/site/comparison/other-networks.html b/i2p2www/pages/site/comparison/other-networks.html index a8040c4e..61373ac3 100644 --- a/i2p2www/pages/site/comparison/other-networks.html +++ b/i2p2www/pages/site/comparison/other-networks.html @@ -23,8 +23,8 @@ You may contribute an analysis by entering a

    Morphmix / Tarzan

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

    {% trans threatmodel=site_url('docs/how/threat-model') -%} Morphmix and Tarzan are both fully distributed, peer to peer networks of @@ -174,7 +174,7 @@ both Mixminion and Mixmaster take the directory based approach as well.

    JAP

    [JAP] -

    {% trans -%} +

    {% trans url='https://www.datenschutzzentrum.de/material/themen/presse/anonip3_e.htm' -%} JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests, and as such it has a few centralized nodes (participants in the cascade) that blend and mix requests from clients through the sequence of nodes (the cascade) before @@ -184,7 +184,7 @@ are not satisfied with an Anonymizer-like service, JAP is worth reviewing. One caution to note is that anyone under the jurisdiction of the German courts may want to take care, as the German Federal Bureau of Criminal Investigation (FBCI) has successfully mounted an -attack +attack on the network. Even though the method of this attack was later found to be illegal in the German courts, the fact that the data was successfully collected is the concern. Courts change their minds based upon circumstance, and this is evidence that @@ -194,11 +194,11 @@ if it may be found inadmissible in some courts later)

    MUTE / AntsP2P

    [MUTE] - [AntsP2P] + [AntsP2P] -

    {% trans -%} +

    {% trans antnet='http://citeseer.ist.psu.edu/57701.html' -%} Both of these systems work through the same basic -antnet routing, providing some degree of +antnet routing, providing some degree of anonymity based on the threat model of providing plausible deniability against a simple non-colluding adversary. With the antnet routing, they first either do a random walk or a broadcast search to find some peer with the data or identity desired, and then use a feedback diff --git a/i2p2www/pages/site/contact.html b/i2p2www/pages/site/contact.html index c10ee671..e8c5502f 100644 --- a/i2p2www/pages/site/contact.html +++ b/i2p2www/pages/site/contact.html @@ -4,7 +4,7 @@

    IRC

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

    diff --git a/i2p2www/pages/site/docs/api/i2pcontrol.html b/i2p2www/pages/site/docs/api/i2pcontrol.html index c5052edf..d3f50466 100644 --- a/i2p2www/pages/site/docs/api/i2pcontrol.html +++ b/i2p2www/pages/site/docs/api/i2pcontrol.html @@ -57,7 +57,7 @@ Parameters are only provided in a named way (maps).
      GetRate – {% trans %}Fetches rateStat from router statManager. Creates stat if not already created.{% endtrans %}
        {{ _('Request:') }} -
      • Stat – [String] {% trans %}Determines which rateStat to fetch, see ratestats.{% endtrans %}
      • +
      • Stat – [String] {% trans ratestats=site_url('misc/ratestats') %}Determines which rateStat to fetch, see ratestats.{% endtrans %}
      • Period – [long] {% trans %}Determines which period a stat is fetched for. Measured in ms.{% endtrans %}
      • Token – [String] {% trans %}Token used for authenticating the client. Is provided by the server via the 'Authenticate' RPC method.{% endtrans %}
      diff --git a/i2p2www/pages/site/docs/api/sam.html b/i2p2www/pages/site/docs/api/sam.html index 2f789bd1..3297fe63 100644 --- a/i2p2www/pages/site/docs/api/sam.html +++ b/i2p2www/pages/site/docs/api/sam.html @@ -34,9 +34,9 @@ the key=value pairs can change (e.g. "ONE TWO A=B C=D" or addition, the protocol is case-sensitive. Communication can take three distinct forms: -* Virtual streams -* Repliable datagrams (messages with a FROM field) -* Anonymous datagrams (raw anonymous messages) +* Virtual streams +* Repliable datagrams (messages with a FROM field) +* Anonymous datagrams (raw anonymous messages) ---------------------------------------------------------------------- SAM connection handshake @@ -334,8 +334,8 @@ Tunnel, I2CP, and Streaming Options These options may be passed in as name=value pairs at the end of a SAM SESSION CREATE line. -All sessions may include I2CP options such as tunnel lengths. -STREAM sessions may include Streaming lib options. +All sessions may include I2CP options such as tunnel lengths. +STREAM sessions may include Streaming lib options. See those references for option names and defaults. @@ -351,7 +351,7 @@ Client library implementations: ---------------------------------------------------------------------- Client libraries are available for C, C++, C#, Perl, and Python. -These are in the apps/sam/ directory in the I2P Source Package. +These are in the apps/sam/ directory in the I2P Source Package. ---------------------------------------------------------------------- diff --git a/i2p2www/pages/site/docs/api/samv2.html b/i2p2www/pages/site/docs/api/samv2.html index 296d0cba..b4707c90 100644 --- a/i2p2www/pages/site/docs/api/samv2.html +++ b/i2p2www/pages/site/docs/api/samv2.html @@ -47,9 +47,9 @@ the key=value pairs can change (e.g. "ONE TWO A=B C=D" or addition, the protocol is case-sensitive. Communication can take three distinct forms: -* Virtual streams -* Repliable datagrams (messages with a FROM field) -* Anonymous datagrams (raw anonymous messages) +* Virtual streams +* Repliable datagrams (messages with a FROM field) +* Anonymous datagrams (raw anonymous messages) ---------------------------------------------------------------------- SAM connection handshake @@ -401,8 +401,8 @@ Tunnel, I2CP, and Streaming Options These options may be passed in as name=value pairs at the end of a SAM SESSION CREATE line. -All sessions may include I2CP options such as tunnel lengths. -STREAM sessions may include Streaming lib options. +All sessions may include I2CP options such as tunnel lengths. +STREAM sessions may include Streaming lib options. See those references for option names and defaults. @@ -417,7 +417,7 @@ Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~ Client library implementations: ---------------------------------------------------------------------- Client libraries are available for C, C++, C#, Perl, and Python. -These are in the apps/sam/ directory in the I2P Source Package. +These are in the apps/sam/ directory in the I2P Source Package. Some may be older and have not been updated for SAMv2 support. diff --git a/i2p2www/pages/site/docs/api/samv3.html b/i2p2www/pages/site/docs/api/samv3.html index 81db268f..5c46f858 100644 --- a/i2p2www/pages/site/docs/api/samv3.html +++ b/i2p2www/pages/site/docs/api/samv3.html @@ -56,9 +56,9 @@ messages sent by the client to the SAM bridge, and by "<- " for messages sent by the SAM bridge to the client. I2P communications can take three distinct forms: -* Virtual streams -* Repliable datagrams (messages with a FROM field) -* Anonymous datagrams (raw anonymous messages) +* Virtual streams +* Repliable datagrams (messages with a FROM field) +* Anonymous datagrams (raw anonymous messages) I2P communications are supported by I2P sessions, and each I2P session is bound to an address (called destination). An I2P session @@ -485,8 +485,8 @@ Tunnel, I2CP, and Streaming Options These options may be passed in as name=value pairs at the end of a SAM SESSION CREATE line. -All sessions may include I2CP options such as tunnel lengths. -STREAM sessions may include Streaming lib options. +All sessions may include I2CP options such as tunnel lengths. +STREAM sessions may include Streaming lib options. See those references for option names and defaults. @@ -501,7 +501,7 @@ Base 64 encoding must use the I2P standard Base 64 alphabet "A-Z, a-z, 0-9, -, ~ Client library implementations: ---------------------------------------------------------------------- Client libraries are available for C, C++, C#, Perl, and Python. -These are in the apps/sam/ directory in the I2P Source Package. +These are in the apps/sam/ directory in the I2P Source Package. Some may be older and have not been updated for SAMv3 support. diff --git a/i2p2www/pages/site/docs/api/streaming.html b/i2p2www/pages/site/docs/api/streaming.html index b6d5601d..a7c60e2a 100644 --- a/i2p2www/pages/site/docs/api/streaming.html +++ b/i2p2www/pages/site/docs/api/streaming.html @@ -67,7 +67,7 @@ streaming library, to be interpreted by I2CP.

      {% trans i2cp=site_url('docs/protocol/i2cp'), i2psktmf='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManagerFactory.html', i2psktm='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocketManager.html', -i2psess='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSession.html', +i2psess='http://docs.i2p-projekt.de/javadoc/net/i2p/client/I2PSession.html', i2pskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PSocket.html', i2psskt='http://docs.i2p-projekt.de/javadoc/net/i2p/client/streaming/I2PServerSocket.html' -%} The standard interface to the streaming lib is for the application to use the diff --git a/i2p2www/pages/site/docs/applications/supported.html b/i2p2www/pages/site/docs/applications/supported.html index 52f0ce66..f454e644 100644 --- a/i2p2www/pages/site/docs/applications/supported.html +++ b/i2p2www/pages/site/docs/applications/supported.html @@ -197,7 +197,7 @@ shortcuts. -->

    • -

      El Dorado — +

      El Dorado — {% trans %}Lightweight forum software.{% endtrans %} [{{ _('standalone/mod') }}]

    • @@ -209,7 +209,7 @@ shortcuts.
    • -

      phpBB — +

      phpBB — {% trans %}Most popular open source forum software.{% endtrans %} [{{ _('standalone/mod') }}]

    • @@ -253,7 +253,7 @@ distributed file system to the I2P network. Controller plugin
    • -

      Monotone — +

      Monotone — {% trans monotone=site_url('get-involved/guides/monotone') -%} Another distributed version control system. Currently used in I2P development. @@ -407,7 +407,7 @@ branch of the I2P Monotone repository.

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

      @@ -502,7 +502,7 @@ developers; they may be able to solve it via additional filtering.
      • -

        jIRCii — +

        jIRCii — {% trans stats=i2pconv('stats.i2p') -%} Small Java-based IRC client. Plugin available here. @@ -694,7 +694,7 @@ currently serve content on the I2P network are:

      • -

        nginx — +

        nginx — {% trans %}High-performance lightweight web server.{% endtrans %} [{{ _('standalone') }}]

      • diff --git a/i2p2www/pages/site/docs/discussions/netdb.html b/i2p2www/pages/site/docs/discussions/netdb.html index ab3769b4..55b8c9fc 100644 --- a/i2p2www/pages/site/docs/discussions/netdb.html +++ b/i2p2www/pages/site/docs/discussions/netdb.html @@ -3,7 +3,7 @@ {% block content %}

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

        History

        @@ -241,7 +241,7 @@ This just accounts for the stores - what about the queries?

        The Return of the Kademlia Algorithm?

        -(this is adapted from the I2P meeting Jan. 2, 2007) +(this is adapted from the I2P meeting Jan. 2, 2007)
        The Kademlia netDb just wasn't working properly. Is it dead forever or will it be coming back? @@ -282,7 +282,7 @@ Not necessarily DHT-based.

        Floodfill TODO List

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

        The network was down to only one floodfill for a couple of hours on March 13, 2008 (approx. 18:00 - 20:00 UTC), @@ -365,7 +365,7 @@ we are now at the minimum number of stats required to monitor the network.

      • [In Release 0.6.3] Manual list of floodfill peers to exclude? -(blocklists by router ident) +(blocklists by router ident)
      • [In Release 0.6.3] Better floodfill peer selection for stores: diff --git a/i2p2www/pages/site/docs/how/cryptography.html b/i2p2www/pages/site/docs/how/cryptography.html index 93b2e2c0..c0bb0602 100644 --- a/i2p2www/pages/site/docs/how/cryptography.html +++ b/i2p2www/pages/site/docs/how/cryptography.html @@ -142,7 +142,8 @@ Using 2 as the generator.

        {% trans %}Short Exponent{% endtrans %}

        {% trans commonstructures=site_url('docs/spec/common-structures'), pdf='http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.14.5952&rep=rep1&type=pdf', -benchmarks=site_url('misc/benchmarks') -%} +benchmarks=site_url('misc/benchmarks'), +oldbenchmarks='http://www.eskimo.com/~weidai/benchmarks.html' -%} While the standard exponent size is 2048 bits (256 bytes) and the I2P PrivateKey is a full 256 bytes, @@ -150,7 +151,7 @@ we use the short exponent size of 226 bits (28.25 bytes). This should be safe for use with the Oakley primes, per On Diffie-Hellman Key Agreement with Short Exponents - van Oorschot, Weiner at EuroCrypt 96, and crypto++'s benchmarks. -Benchmarks originally at this link, now dead, +Benchmarks originally at {{ oldbenchmarks }} (now dead), rescued from the wayback machine, dated Apr 23, 2008. {%- endtrans %}

        diff --git a/i2p2www/pages/site/docs/how/garlic-routing.html b/i2p2www/pages/site/docs/how/garlic-routing.html index 767b2018..f98d6f91 100644 --- a/i2p2www/pages/site/docs/how/garlic-routing.html +++ b/i2p2www/pages/site/docs/how/garlic-routing.html @@ -15,7 +15,7 @@ the usage of "garlic" methods in I2P. Michael J. Freedman in Roger Dingledine's Free Haven Master's thesis Section 8.1.1 (June 2000), as derived from -Onion Routing. +Onion Routing. {%- endtrans %}

        {% trans -%} diff --git a/i2p2www/pages/site/docs/how/intro.html b/i2p2www/pages/site/docs/how/intro.html index a9374630..93ec5cc1 100644 --- a/i2p2www/pages/site/docs/how/intro.html +++ b/i2p2www/pages/site/docs/how/intro.html @@ -151,10 +151,11 @@ the network (N) bears no impact. {%- endtrans %}

        {% trans %}When?{% endtrans %}

        -

        {% trans roadmap=site_url('get-involved/roadmap') -%} +

        {% trans roadmap=site_url('get-involved/roadmap'), +jms='http://www.oracle.com/technetwork/java/jms/index.html' -%} I2P initially began in Feb 2003 as a proposed modification to Freenet to allow it to use alternate transports, such as JMS, then grew into its own as an +href="{{ jms }}">JMS, then grew into its own as an 'anonCommFramework' in April 2003, turning into I2P in July, with code being written in earnest starting in August '03. I2P is currently under development, following the roadmap. diff --git a/i2p2www/pages/site/docs/how/network-database.html b/i2p2www/pages/site/docs/how/network-database.html index 4c677a7b..45bde67c 100644 --- a/i2p2www/pages/site/docs/how/network-database.html +++ b/i2p2www/pages/site/docs/how/network-database.html @@ -747,7 +747,7 @@ for a discussion of the vulnerabilities of peer selection for tunnels. {%- endtrans %}

        {% trans %}Information Leaks{% endtrans %}

        -

        {% trans pdf='https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf' -%} +

        {% trans pdf='http://www.eecs.berkeley.edu/~pmittal/publications/nisan-torsk-ccs10.pdf' -%} (Reference: In Search of an Anonymous and Secure Lookup Section 3) {%- endtrans %}

        diff --git a/i2p2www/pages/site/docs/how/peer-selection.html b/i2p2www/pages/site/docs/how/peer-selection.html index 2537ef3e..fd26f061 100644 --- a/i2p2www/pages/site/docs/how/peer-selection.html +++ b/i2p2www/pages/site/docs/how/peer-selection.html @@ -250,8 +250,8 @@ Peers for which a recent connection attempt failed are not used.

        {% trans %}Peer Ordering in Tunnels{% endtrans %}

        -

        {% trans pdf='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf', -pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf', +

        {% trans pdf='http://forensics.umass.edu/pubs/wright-tissec.pdf', +pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf', tunnelimpl=site_url('docs/tunnels/implementation') -%} Peers are ordered within tunnels to to deal with the predecessor attack @@ -306,7 +306,7 @@ please keep in mind the following minor changes in I2P since the paper's publica

      • {% trans %}Tune-up for Tor{% endtrans %}
      • -{% trans %}Low-resource Routing Attacks Against Tor{% endtrans %} +{% trans %}Low-resource Routing Attacks Against Tor{% endtrans %}
      {% endblock %} diff --git a/i2p2www/pages/site/docs/how/threat-model.html b/i2p2www/pages/site/docs/how/threat-model.html index 09d3c402..33f1cd35 100644 --- a/i2p2www/pages/site/docs/how/threat-model.html +++ b/i2p2www/pages/site/docs/how/threat-model.html @@ -431,7 +431,7 @@ matter, the attacker would need to control a significant portion of the network which other tunnels or messages have those delays). {%- endtrans %}

      -

      {% trans netdb=site_url('docs/how/networkdatabase') -%} +

      {% trans netdb=site_url('docs/how/network-database') -%} Also discussed on the network database page (bootstrap attack). {%- endtrans %}

      @@ -470,8 +470,8 @@ was specifically designed to combat the predecessor attack. See also the intersection attack. {%- endtrans %}

      -

      {% trans pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf', -pdf2004='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf' -%} +

      {% trans pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf', +pdf2004='http://forensics.umass.edu/pubs/wright-tissec.pdf' -%} References: {{ pdf2008 }} which is an update to the 2004 predecessor attack paper {{ pdf2004 }}. @@ -627,7 +627,7 @@ for more Sybil discussion.

      {% trans %}Buddy Exhaustion attacks{% endtrans %}

      -

      {% trans pdf='https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf' -%} +

      {% trans pdf='http://www.eecs.berkeley.edu/~pmittal/publications/nisan-torsk-ccs10.pdf' -%} (Reference: In Search of an Anonymouns and Secure Lookup Section 5.2) {%- endtrans %}

      diff --git a/i2p2www/pages/site/docs/index.html b/i2p2www/pages/site/docs/index.html index 5f8a2341..5b860b55 100644 --- a/i2p2www/pages/site/docs/index.html +++ b/i2p2www/pages/site/docs/index.html @@ -227,7 +227,7 @@ Traditionally used only by Java applications and higher-level APIs.
    • {{ _('Source translation at Transifex') }}
    • -{{ _('0.9 roadmap wiki') }} ({{ _('not current') }}) +{{ _('Roadmap wiki') }}
    • {{ _('Old roadmap') }} ({{ _('not current') }})
    • diff --git a/i2p2www/pages/site/docs/spec/streaming.html b/i2p2www/pages/site/docs/spec/streaming.html index 05db8ba0..41e49de9 100644 --- a/i2p2www/pages/site/docs/spec/streaming.html +++ b/i2p2www/pages/site/docs/spec/streaming.html @@ -33,21 +33,21 @@ The format of a single packet in the streaming protocol is:
      {{ _('Field') }}{{ _('Length') }}{{ _('Contents') }} -
      sendStreamId 4 byte IntegerRandom number selected by the connection recipient +
      sendStreamId 4 byte IntegerRandom number selected by the connection recipient and constant for the life of the connection. 0 in the SYN message sent by the originator, and in subsequent messages, until a SYN reply is received, containing the peer's stream ID. -
      receiveStreamId 4 byte IntegerRandom number selected by the connection originator +
      receiveStreamId 4 byte IntegerRandom number selected by the connection originator and constant for the life of the connection. May be 0 if unknown, for example in a RESET packet. -
      sequenceNum 4 byte Integer +
      sequenceNum 4 byte Integer The sequence for this message, starting at 0 in the SYN message, and incremented by 1 in each message except for plain ACKs and retransmissions. If the sequenceNum is 0 and the SYN flag is not set, this is a plain ACK packet that should not be ACKed. -
      ackThrough 4 byte Integer +
      ackThrough 4 byte Integer The highest packet sequence number that was received on the receiveStreamId. This field is ignored on the initial connection packet (where receiveStreamId is the unknown id) or @@ -55,14 +55,14 @@ if the NO_ACK flag set. All packets up to and including this sequence number are ACKed, EXCEPT for those listed in NACKs below. -
      NACK count1 byte Integer +
      NACK count1 byte Integer The number of 4-byte NACKs in the next field -
      NACKs n * 4 byte Integers +
      NACKs n * 4 byte Integers Sequence numbers less than ackThrough that are not yet received. Two NACKs of a packet is a request for a 'fast retransmit' of that packet. -
      resendDelay1 byte Integer +
      resendDelay1 byte Integer How long is the creator of this packet going to wait before resending this packet (if it hasn't yet been ACKed). The value is seconds since the packet was created. @@ -71,7 +71,7 @@ Currently ignored on receive.
      flags 2 byte value See below. -
      option size2 byte Integer +
      option size2 byte Integer The number of bytes in the next field
      option data0 or more bytes @@ -103,23 +103,23 @@ SIGNATURE_INCLUDED must be set also.
      2RESET-- Abnormal close. SIGNATURE_INCLUDED must be set also. -
      3SIGNATURE_INCLUDED40 byte DSA Signature +
      3SIGNATURE_INCLUDED40 byte DSA Signature Currently sent only with SYNCHRONIZE, CLOSE, and RESET, where it is required. -The signature uses the Destination's DSA signing keys +The signature uses the Destination's DSA signing keys to sign the entire header and payload with the 40-byte space in the option data field for the signature being set to all zeroes.
      4SIGNATURE_REQUESTED-- Unused. Requests every packet in the other direction to have SIGNATURE_INCLUDED -
      5FROM_INCLUDED387+ byte Destination +
      5FROM_INCLUDED387+ byte Destination Currently sent only with SYNCHRONIZE, where it is required. -
      6DELAY_REQUESTED2 byte Integer +
      6DELAY_REQUESTED2 byte Integer Optional delay. How many milliseconds the sender of this packet wants the recipient to wait before sending any more data. A value greater than 60000 indicates choking. -
      7MAX_PACKET_SIZE_INCLUDED2 byte Integer +
      7MAX_PACKET_SIZE_INCLUDED2 byte Integer Currently sent with SYNCHRONIZE only. Was also sent in retransmitted packets until release 0.9.1.
      8PROFILE_INTERACTIVE-- From 5422df80eabc07268a99505415d67698d6f4b6f9 Mon Sep 17 00:00:00 2001 From: str4d Date: Wed, 6 Feb 2013 03:24:18 +0000 Subject: [PATCH 398/498] More assorted internal and external URL fixes --- i2p2www/pages/site/docs/protocol/i2np.html | 2 +- .../pages/site/docs/tunnels/implementation.html | 4 ++-- .../site/docs/tunnels/old-implementation.html | 2 +- .../site/get-involved/bounties/unit-tests.html | 4 ++-- .../site/get-involved/develop/licenses.html | 16 ++++++++-------- .../site/get-involved/develop/signed-keys.html | 2 +- i2p2www/pages/site/get-involved/donate.html | 6 +++--- .../pages/site/get-involved/guides/monotone.html | 2 +- .../site/get-involved/guides/new-developers.html | 6 +++--- .../get-involved/guides/new-translators.html | 4 ++-- i2p2www/pages/site/get-involved/todo.html | 6 +++--- i2p2www/pages/site/links.html | 10 +++++----- i2p2www/pages/site/research/papers.html | 2 -- 13 files changed, 32 insertions(+), 34 deletions(-) diff --git a/i2p2www/pages/site/docs/protocol/i2np.html b/i2p2www/pages/site/docs/protocol/i2np.html index 3ee58d06..02ea85b2 100644 --- a/i2p2www/pages/site/docs/protocol/i2np.html +++ b/i2p2www/pages/site/docs/protocol/i2np.html @@ -226,7 +226,7 @@ Others listed in 2003 Spec

      {% trans %}Full Protocol Specification{% endtrans %}

      -

      {% trans i2npspec=site_url('docs/specs/i2np'), commonstructures=site_url('docs/specs/common-structures') -%} +

      {% trans i2npspec=site_url('docs/spec/i2np'), commonstructures=site_url('docs/spec/common-structures') -%} On the I2NP Specification page. See also the Common Data Structure Specification page. diff --git a/i2p2www/pages/site/docs/tunnels/implementation.html b/i2p2www/pages/site/docs/tunnels/implementation.html index b10288ee..3c8989a3 100644 --- a/i2p2www/pages/site/docs/tunnels/implementation.html +++ b/i2p2www/pages/site/docs/tunnels/implementation.html @@ -328,8 +328,8 @@ Client peer selection is discussed further on the

      {% trans %}Peer Ordering within Tunnels{% endtrans %}

      -

      {% trans pdf='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf', -pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf' -%} +

      {% trans pdf='http://forensics.umass.edu/pubs/wright-tissec.pdf', +pdf2008='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf' -%} Peers are ordered within tunnels to deal with the predecessor attack (2008 update). diff --git a/i2p2www/pages/site/docs/tunnels/old-implementation.html b/i2p2www/pages/site/docs/tunnels/old-implementation.html index f4ad6217..88c5c40d 100644 --- a/i2p2www/pages/site/docs/tunnels/old-implementation.html +++ b/i2p2www/pages/site/docs/tunnels/old-implementation.html @@ -531,6 +531,6 @@ reordering, rerouting, or padding messages? To what extent should this be done automatically, how much should be configured as a per tunnel or per hop setting, and how should the tunnel's creator (and in turn, user) control this operation? All of this is left as unknown, to be worked out for -I2P 3.0

      +I2P 3.0

      {% endblock %} diff --git a/i2p2www/pages/site/get-involved/bounties/unit-tests.html b/i2p2www/pages/site/get-involved/bounties/unit-tests.html index 5cfb6e3a..9a14fe2c 100644 --- a/i2p2www/pages/site/get-involved/bounties/unit-tests.html +++ b/i2p2www/pages/site/get-involved/bounties/unit-tests.html @@ -42,11 +42,11 @@ The server needs to be run long term. {% trans euro=150 %}Bounty: {{ euro }} € {%- endtrans %} {{ _('paid to str4d') }}
      -

      {% trans -%} +

      {% trans clover='https://www.atlassian.com/software/clover/overview' -%} To collect this bounty, the existing SDK tests must be checked and made to work again. The need to be integrated into the ant build scripts ("ant test"), and tied in with a code coverage tool (e.g. -Clover). The ant script +Clover). The ant script must be capable of generating test status results as a web page, which will be published online. {%- endtrans %}

      diff --git a/i2p2www/pages/site/get-involved/develop/licenses.html b/i2p2www/pages/site/get-involved/develop/licenses.html index a009fef5..9010e94e 100644 --- a/i2p2www/pages/site/get-involved/develop/licenses.html +++ b/i2p2www/pages/site/get-involved/develop/licenses.html @@ -137,7 +137,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib mihi - SAM Bridge + SAM Bridge apps/sam sam.jar @@ -150,12 +150,12 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib human - SAM perl library + SAM perl library apps/sam/perl SAM.pm - Artistic + Artistic Public domain
      Cryptix
      @@ -164,7 +164,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib BrianR - SAM C library + SAM C library apps/sam/c libSAM @@ -177,7 +177,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib Nightblade - SAM Python library + SAM Python library apps/sam/python i2p.py @@ -190,7 +190,7 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib Connelly - SAM C# library + SAM C# library apps/sam/csharp/ n/a @@ -269,9 +269,9 @@ to what licenses meet the above four guarantees for inclusion in the I2P distrib

      {{ _('GPL + java exception') }}

      -

      {% trans -%} +

      {% trans gpl='https://www.gnu.org/licenses/gpl.html' -%} While it may be redundant, just for clarity the -GPL'ed code included within +GPL'ed code included within I2PTunnel and other apps must be released under the GPL with an additional "exception" explicitly authorizing the use of Java's standard libraries: {%- endtrans %}

      diff --git a/i2p2www/pages/site/get-involved/develop/signed-keys.html b/i2p2www/pages/site/get-involved/develop/signed-keys.html index bbbf0296..3befbb97 100644 --- a/i2p2www/pages/site/get-involved/develop/signed-keys.html +++ b/i2p2www/pages/site/get-involved/develop/signed-keys.html @@ -7,7 +7,7 @@ verified differently, since he's away, and only left a binary detached signature for his key. {%- endtrans %}

        -
      1. {{ _('Monotone keys for zzz') }}
      2. +
      3. {{ _('Monotone keys for zzz') }}
      4. {{ _('Monotone keys for welterde') }}
      5. {{ _('Monotone keys for Complication') }}
      6. {{ _('Monotone keys for jrandom') }}
      7. diff --git a/i2p2www/pages/site/get-involved/donate.html b/i2p2www/pages/site/get-involved/donate.html index 546a1f8f..3d4e7c3b 100644 --- a/i2p2www/pages/site/get-involved/donate.html +++ b/i2p2www/pages/site/get-involved/donate.html @@ -81,14 +81,14 @@ You can donate direct via PayPal to the account "{{ account }}".
        -

        Flattr

        +

        Flattr

        {{ _('Flattr this') }}

        -

        Bitcoin

        +

        Bitcoin

        {% trans account='1HkJCceXf7of1sTNRVJbXiZHfDTLL71Siy' -%} -As of December 2010, eche|on has been running a Bitcoin account for the I2P project. +As of December 2010, eche|on has been running a Bitcoin account for the I2P project. If you'd like to donate using Bitcoin, just transfer your desired amount of coins to the account {{ account }} and leave eche|on a note if you'd like your donation to be mentioned on the I2P webpage. {%- endtrans %}

        diff --git a/i2p2www/pages/site/get-involved/guides/monotone.html b/i2p2www/pages/site/get-involved/guides/monotone.html index e7c783a3..362b62f1 100644 --- a/i2p2www/pages/site/get-involved/guides/monotone.html +++ b/i2p2www/pages/site/get-involved/guides/monotone.html @@ -260,7 +260,7 @@

        {% trans -%} - More information about Trust Evauluation Hooks can be found in the official Monotone documentation. + More information about Trust Evauluation Hooks can be found in the official Monotone documentation. {%- endtrans %}

        diff --git a/i2p2www/pages/site/get-involved/guides/new-developers.html b/i2p2www/pages/site/get-involved/guides/new-developers.html index a2d0178a..277b62f0 100644 --- a/i2p2www/pages/site/get-involved/guides/new-developers.html +++ b/i2p2www/pages/site/get-involved/guides/new-developers.html @@ -51,7 +51,7 @@ Monotone is a version control system. We use it because it allows us to keep track of who does what changes to the source code (and for a lot of complicated things, but 'keeping track of changes' is the basic idea). {%- endtrans %}
      8. {% trans -%} -Skim over the monotone tutorial, to make sure you understand the concepts. +Skim over the monotone tutorial, to make sure you understand the concepts. {%- endtrans %}
      9. {% trans -%} @@ -102,7 +102,7 @@ The initial pull may take several hours using the tunnel. If it fails after a partial pull, simply rerun it, it will start where it left off. If you are in a hurry, use the non-anonymous access. {%- endtrans %}

        -

        {% trans viewmtn='http://stats.i2p/cgi-bin/viewmtn/' -%} +

        {% trans viewmtn='http://'+i2pconv('stats.i2p')+'/cgi-bin/viewmtn/' -%} A full list of branches, including i2p.i2p and i2p.www can be found on viewmtn. {%- endtrans %}

        {% trans monotone=site_url('get-involved/guides/monotone') -%} @@ -111,7 +111,7 @@ A long explanation about using monotone is available on the {% trans %}Building I2P{% endtrans %} -

        {% trans sunjdk6='http://java.sun.com/javase/downloads/index.jsp' -%} +

        {% trans sunjdk6='http://www.oracle.com/technetwork/java/javase/downloads/index.html' -%} To compile the code, you need the Sun Java Development Kit 6 or higher, or equivalent JDK (Sun JDK 6 strongly recommended) and Apache ant diff --git a/i2p2www/pages/site/get-involved/guides/new-translators.html b/i2p2www/pages/site/get-involved/guides/new-translators.html index 82754f24..43849b96 100644 --- a/i2p2www/pages/site/get-involved/guides/new-translators.html +++ b/i2p2www/pages/site/get-involved/guides/new-translators.html @@ -16,7 +16,7 @@ Alternatively it can be done "the old way" as outlined below.

      10. {% trans %}Preparation{% endtrans %}
          -
        1. {% trans url='http://ugha.i2p/i2pTranslation' -%} +
        2. {% trans url='http://'+i2pconv('ugha.i2p')+'/i2pTranslation' -%} Come to #i2p-dev on irc and talk to people. Claim the language - To make sure other coworkers don't bump onto the files you are working on, @@ -81,7 +81,7 @@ Alternatively it can be done "the old way" as outlined below.
        3. {% trans %}Preparation{% endtrans %}
            -
          1. {% trans url='http://ugha.i2p/i2pTranslation' -%} +
          2. {% trans url='http://'+i2pconv('ugha.i2p')+'/i2pTranslation' -%} Come to #i2p-dev on irc and talk to people. Claim the language - To make sure other coworkers don't bump onto the files you are working on, diff --git a/i2p2www/pages/site/get-involved/todo.html b/i2p2www/pages/site/get-involved/todo.html index 4d988452..166d8e11 100644 --- a/i2p2www/pages/site/get-involved/todo.html +++ b/i2p2www/pages/site/get-involved/todo.html @@ -49,7 +49,7 @@ Advanced tunnel operation (batching/mixing/throttling/padding) Stop & go mix w/ garlics & tunnels {%- endtrans %}
    -

    {{ _('Performance') }} [{{ _('link') }}]

    +

    {{ _('Performance') }} [{{ _('link') }}]

    {{ _('Core functionality') }}

      @@ -299,8 +299,8 @@ Strict ordering of participants within tunnels

    {% trans link='http://article.gmane.org/gmane.network.i2p/22/', -pdf1='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf', -pdf2='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf' -%} +pdf1='http://forensics.umass.edu/pubs/wright-tissec.pdf', +pdf2='http://forensics.umass.edu/pubs/wright.tissec.2008.pdf' -%} As Connelly proposed to deal with the predecessor attack (2008 update), keeping the order of peers within our tunnels consistent diff --git a/i2p2www/pages/site/links.html b/i2p2www/pages/site/links.html index 53d5be6a..eb137ba3 100644 --- a/i2p2www/pages/site/links.html +++ b/i2p2www/pages/site/links.html @@ -2,16 +2,16 @@ {% block title %}{{ _('Links') }}{% endblock %} {% block content %}

    {{ _('Recommended Links & Resources') }}

    -

    {% trans papers=site_url('about/papers') -%} +

    {% trans media=site_url('about/media') -%} See also the page with -links to papers, presentations, videos, and tutorials about I2P. +links to presentations, videos, and tutorials about I2P. {%- endtrans %}