diff --git a/www.i2p2/i2p2www/pages/global/nav.html b/www.i2p2/i2p2www/pages/global/nav.html
index 7a839d29186cffa8163d0551cdb2bb8273838d86..6744c27dc7c9b881cd1da74b1d6934bb77cee7b4 100644
--- a/www.i2p2/i2p2www/pages/global/nav.html
+++ b/www.i2p2/i2p2www/pages/global/nav.html
@@ -3,8 +3,8 @@
<li><a href="{{ url_for('downloads_list', lang=g.lang) }}">Download</a></li>
<li><a href="#">Docs</a>
<ul>
- <li><a href="how.html"> How does it work?</a></li>
- <li><a href="techintro.html"> Tech intro</a></li>
+ <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}"> How does it work?</a></li>
+ <li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}"> Tech intro</a></li>
<li><a href="howto.html"> Howto docs</a></li>
<li><a href="applications.html"> Applications</a></li>
</ul>
diff --git a/www.i2p2/pages/how_cryptography.html b/www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
similarity index 91%
rename from www.i2p2/pages/how_cryptography.html
rename to www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
index 08377b1f42cd6d22f728cccacc8ed66791cfe9b1..c5ffc62a00dbe53ac48067e179f72a3f2f240436 100644
--- a/www.i2p2/pages/how_cryptography.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/cryptography.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Low-level Cryptography Details{% endblock %}
{% block content %}
<p>
@@ -12,7 +12,7 @@ one asymmetric algorithm, one signing algorithm, and one hashing algorithm. How
we do combine them in some particular ways to provide message integrity (rather than
relying on a MAC). In addition, as much as we hate doing anything new in regards to
cryptography, we can't seem to find a reference discussing (or even naming) the
-technique used in <a href="how_elgamalaes">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
+technique used in <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> (but we're sure others have done it).
<p>
<H2><a name="elgamal">ElGamal encryption</a></H2>
@@ -25,7 +25,7 @@ To encrypt router-to-router <a href="tunnel-alt-creation.html">Tunnel Build Mess
For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
using the encryption key in the <a href="common_structures_spec.html#struct_LeaseSet">LeaseSet</a>
</li><li>
-For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
+For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li></ul>
@@ -158,13 +158,13 @@ AES is used for symmetric encryption, in several cases:
<ul><li>
For <a href="#transports">transport encryption</a> after DH key exchange
</li><li>
-For end-to-end (destination-to-destination) encryption as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+For end-to-end (destination-to-destination) encryption as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
-For encryption of some <a href="how_networkdatabase.html#delivery">netDb stores and queries sent to floodfill routers</a>
-as a part of <a href="how_elgamalaes">ElGamal/AES+SessionTag</a>
+For encryption of some <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">netDb stores and queries sent to floodfill routers</a>
+as a part of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
(destination-to-router or router-to-router).
</li><li>
-For encryption of <a href="how_tunnelrouting.html#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
+For encryption of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}#testing">periodic tunnel test messages</a> sent from the router to itself, through its own tunnels.
</li></ul>
</p><p>
We use AES with 256 bit keys and 128 bit blocks in CBC mode.
@@ -327,9 +327,9 @@ It may be quite difficult to make any change backward-compatible.
<H4>References</H4>
<ul>
<li>
-<a href="meeting51.html">Meeting 51</a>
+<a href="{{ url_for('meetings_show', lang=g.lang, id=51) }}">Meeting 51</a>
<li>
-<a href="meeting52.html">Meeting 52</a>
+<a href="{{ url_for('meetings_show', lang=g.lang, id=52) }}">Meeting 52</a>
<li>
<a name="choosing_constants" href="http://article.gmane.org/gmane.comp.security.invisiblenet.iip.devel/343">Choosing the constants</a>
<li>
@@ -376,7 +376,7 @@ NTCP connections are negotiated with a 2048 Diffie-Hellman implementation,
using the router's identity to proceed with a station to station agreement, followed by
some encrypted protocol specific fields, with all subsequent data encrypted with AES
(as above).
-The primary reason to do the DH negotiation instead of using <a href="how_elgamalaes">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="how_elgamalaes">ElGamalAES+SessionTag</a> does not.
+The primary reason to do the DH negotiation instead of using <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> is that it provides '<a href="http://en.wikipedia.org/wiki/Perfect_forward_secrecy">(perfect) forward secrecy</a>', while <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamalAES+SessionTag</a> does not.
</p>
<p>
In order to migrate to a more standardized implementation (TLS/SSL or even SSH), the following issues must be addressed:
diff --git a/www.i2p2/pages/how_elgamalaes.html b/www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
similarity index 98%
rename from www.i2p2/pages/how_elgamalaes.html
rename to www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
index b2b501fdc4194c6d3102a19050b962a110c7afa1..01e45f7c47a4cf5a9240c83c931b780619099f41 100644
--- a/www.i2p2/pages/how_elgamalaes.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/elgamalaes.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}ElGamal/AES + SessionTag Encryption{% endblock %}
{% block content %}
Updated February 2011, current as of router version 0.8.3
@@ -142,7 +142,7 @@ The 32-byte Pre-IV will be used to generate the IV for the AES block that follow
the IV is the first 16 bytes of the SHA-256 Hash of the Pre-IV.
</p><p>
The 222 byte payload is encrypted
-<a href="how_cryptography.html#elgamal">using ElGamal</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#elgamal">using ElGamal</a>
and the encrypted block is 514 bytes long.
</p>
@@ -212,7 +212,7 @@ Minimum length: 48 bytes
</PRE>
</p><p>
-The data is then <a href="how_cryptography">AES Encrypted</a>,
+The data is then <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">AES Encrypted</a>,
using the session key and IV (calculated from the pre-IV) from the ElGamal section.
The encrypted AES Block length is variable but is always a multiple of 16 bytes.
</p>
diff --git a/www.i2p2/pages/how_garlicrouting.html b/www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
similarity index 90%
rename from www.i2p2/pages/how_garlicrouting.html
rename to www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
index 718414924694a3f215874775ab1412e1562ea571..cd311d88dc944537704e5014de3126d6eec64525 100644
--- a/www.i2p2/pages/how_garlicrouting.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/garlicrouting.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Garlic Routing{% endblock %}
{% block content %}<p>
Updated August 2010 for release 0.8
@@ -42,7 +42,7 @@ During the operating phase, messages are passed through the tunnel, and the
message and its routing instructions are only exposed to the endpoint of the tunnel.
</p><p>
This is similar to the way Mixmaster
-(see <a href="how_networkcomparisons">network comparisons</a>) sends messages - taking a message, encrypting it
+(see <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a>) sends messages - taking a message, encrypting it
to the recipient's public key, taking that encrypted message and encrypting
it (along with instructions specifying the next hop), and then taking that
resulting encrypted message and so on, until it has one layer of encryption
@@ -84,7 +84,7 @@ and reliable delivery.
<h3>ElGamal/AES Encryption</h3>
In some cases, "garlic encryption" may simply mean
-<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> encryption
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption
(without multiple layers).
@@ -117,7 +117,7 @@ This is described on the
Tunnel building details are defined on
<a href="tunnel-alt-creation.html">this page</a>.
We use
-<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> for the encryption.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
</p><p>
Tunnels are a general-purpose mechanism to transport all
<a href="i2np.html">I2NP messages</a>, and
@@ -134,7 +134,7 @@ the tunnel encryption is sufficient.
At the layer above tunnels, I2P delivers end-to-end messages between
<a href="common_structures_spec#struct_Destination">Destinations</a>.
Just as within a single tunnel, we use
-<a href="how_elgamalaes">ElGamal/AES+SessionTag</a> for the encryption.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> for the encryption.
Each client message as delivered to the router through the
<a href="i2cp.html">I2CP interface</a> becomes a single
<a href="i2np.html#struct_GarlicClove">Garlic Clove</a>
@@ -174,7 +174,7 @@ By periodically bundling a LeaseSet, the router ensures that the far-end will be
to maintain communications.
Otherwise the far-end would have to query a floodfill router for the network database entry,
and all LeaseSets would have to be published to the network database, as explained on the
-<a href="how_networkdatabase.html">network database page</a>.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database page</a>.
</li></ol>
</p><p>
@@ -191,7 +191,7 @@ and not part of a general-purpose routing scheme.
<h3> Storage to the Floodfill Network Database</h3>
</p>
As explained on the
-<a href="how_networkdatabase.html#delivery">network database page</a>,
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">network database page</a>,
local
<a href="common_structures_spec#struct_LeaseSet">LeaseSets</a>
are sent to floodfill routers in a
@@ -220,14 +220,14 @@ as limiting certain routing paths, restricting the types of I2NP messages that m
be forwarded along various paths, and enforcing certain message expiration times.
</p><p>
As a part of
-<a href="how_elgamalaes">ElGamal/AES encryption</a>,
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES encryption</a>,
a garlic message contains a sender
specified amount of padding data, allowing the sender to take active countermeasures
against traffic analysis.
This is not currently used, beyond the requirement to pad to a multiple of 16 bytes.
</p><p>
Encryption of additional messages to and from the
-<a href="how_networkdatabase.html#delivery">floodfill routers</a>.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">floodfill routers</a>.
</p>
@@ -246,7 +246,7 @@ see Section 8.1.1 authored by
</li><li>
<a href="http://en.wikipedia.org/wiki/Garlic_routing">Garlic Routing on Wikipedia</a>
</li><li>
-<a href="meeting58.html">I2P Meeting 58</a> (2003) discussing the implementation of garlic routing
+<a href="{{ url_for('meetings_show', lang=g.lang, id=58) }}">I2P Meeting 58</a> (2003) discussing the implementation of garlic routing
</li><li>
<a href="https://www.torproject.org/">Tor</a>
</li><li>
diff --git a/www.i2p2/pages/how.html b/www.i2p2/i2p2www/pages/site/docs/how/index.html
similarity index 76%
rename from www.i2p2/pages/how.html
rename to www.i2p2/i2p2www/pages/site/docs/how/index.html
index f91216355aead2ac88e04bd91d51f02097a411e5..0d6950df26e264420d632cdb9625df4c1736be5f 100644
--- a/www.i2p2/pages/how.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/index.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Index to Technical Documentation{% endblock %}
{% block content %}
<h1>How does I2P work?</h1>
@@ -21,13 +21,13 @@ If you find any inaccuracies in the documents linked below, please
<h3>Overview</h3>
<ul class="helplist">
-<li><a href="techintro.html">Technical Introduction</a></li>
-<li><a href="how_intro.html">A Less-Technical Introduction</a></li>
-<li><a href="how_threatmodel.html">Threat model and analysis</a></li>
-<li><a href="how_networkcomparisons.html">Comparisons to other anonymous networks</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/techintro') }}">Technical Introduction</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/intro') }}">A Less-Technical Introduction</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">Threat model and analysis</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Comparisons to other anonymous networks</a></li>
<li><a href="protocols.html">Protocol stack chart</a></li>
<li><a href="papers.html">Papers and Presentations on I2P</a></li>
-<li><a href="/_static/pdf/i2p_philosophy.pdf">Invisible Internet Project (I2P) Project Overview</a> August 28, 2003 (pdf)</li>
+<li><a href="{{ url_for('static', filename='pdf/i2p_philosophy.pdf') }}">Invisible Internet Project (I2P) Project Overview</a> August 28, 2003 (pdf)</li>
</ul>
<h3>Application-Layer Topics</h3>
@@ -101,16 +101,16 @@ Traditionally used only by Java applications and higher-level APIs.
<h3>End-to-End Encryption</h3>
How client messages are end-to-end encrypted by the router.
<ul>
-<li><a href="how_elgamalaes">ElGamal/AES+SessionTag</a> encryption</li>
-<li><a href="how_cryptography.html">ElGamal and AES cryptography details</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a> encryption</li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
</ul>
<h3>Network Database</h3>
Distributed storage and retrieval of information about routers and clients.
<ul>
-<li><a href="how_networkdatabase.html">Network database overview, details, and threat analysis</a></li>
-<li><a href="how_cryptography.html#SHA256">Cryptographic hashes</a></li>
-<li><a href="how_cryptography.html#DSA">Cryptographic signatures</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">Network database overview, details, and threat analysis</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#SHA256">Cryptographic hashes</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#DSA">Cryptographic signatures</a></li>
</ul>
<h3>Router Message Protocol</h3>
@@ -130,16 +130,16 @@ I2P is a message-oriented router. The messages sent between routers are defined
<h3>Tunnels</h3>
Selecting peers, requesting tunnels through those peers, and encrypting and routing messages through these tunnels.
<ul>
-<li><a href="how_peerselection.html">Peer profiling and selection</a></li>
-<li><a href="how_tunnelrouting.html">Tunnel routing overview</a></li>
-<li><a href="how_garlicrouting.html">Garlic routing and "garlic" terminology</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">Peer profiling and selection</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">Tunnel routing overview</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">Garlic routing and "garlic" terminology</a></li>
<li><a href="tunnel-alt.html">Tunnel building and encryption</a></li>
-<li><a href="how_elgamalaes.html">ElGamal/AES</a> for build request encryption</li>
-<li><a href="how_cryptography.html">ElGamal and AES cryptography details</a></li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES</a> for build request encryption</li>
+<li><a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">ElGamal and AES cryptography details</a></li>
<li><a href="tunnel-alt-creation.html">Tunnel building specification</a></li>
<li><a href="tunnel_message_spec.html">Low-level tunnel message specification</a></li>
<li><a href="unidirectional-tunnels.html">Unidirectional Tunnels</a></li>
-<li><a href="/_static/pdf/I2P-PET-CON-2009.1.pdf">Peer Profiling and Selection in the I2P Anonymous Network</a>
+<li><a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
2009 paper (pdf), not current but still generally accurate</li>
</ul>
@@ -154,9 +154,9 @@ The protocols for direct (point-to-point) router to router communication.
</li><li>
<a href="udp_spec.html">SSU specification</a>
</li><li>
-<a href="how_cryptography.html#tcp">NTCP transport encryption</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#tcp">NTCP transport encryption</a>
</li><li>
-<a href="how_cryptography.html#udp">SSU transport encryption</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}#udp">SSU transport encryption</a>
</li><li>
<a href="http://docs.i2p-projekt.de/javadoc/net/i2p/router/transport/package-summary.html">Transport Javadoc</a>
</li><li>
diff --git a/www.i2p2/pages/how_intro.html b/www.i2p2/i2p2www/pages/site/docs/how/intro.html
similarity index 81%
rename from www.i2p2/pages/how_intro.html
rename to www.i2p2/i2p2www/pages/site/docs/how/intro.html
index d56bf2cadc931b960e7aebd3b2574024c7d29ddd..b460686dfc210467da2b82d978428ddbf1e71028 100644
--- a/www.i2p2/pages/how_intro.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/intro.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}A Gentle Introduction{% endblock %}
{% block content %}
@@ -32,7 +32,7 @@ Instead their view will be of one of the I2P enabled applications, or perhaps as
app to turn on and off various proxies to enable the anonymizing functionality.</p>
<p>An essential part of designing, developing, and testing an anonymizing network is to define the
-<a href="how_threatmodel">threat model</a>, since there is no such thing as "true" anonymity, just
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>, since there is no such thing as "true" anonymity, just
increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate
in arbitrarily hostile environments by providing good anonymity, mixed in with sufficient cover
traffic provided by the activity of people who require less anonymity. This way, some users can avoid
@@ -43,23 +43,23 @@ others.</p>
<h2>Why?</h2>
<p>There are a multitude of reasons why we need a system to support
anonymous communication, and everyone has their own personal rationale. There are many
-<a href="how_networkcomparisons">other efforts</a> working on finding ways to provide varying degrees of
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other efforts</a> working on finding ways to provide varying degrees of
anonymity to people through the Internet, but we could not find any that met our needs or threat
model.</p>
<h2>How?</h2>
<p>The network at a glance is made up of a set of nodes ("routers") with a number of unidirectional
-inbound and outbound virtual paths ("tunnels", as outlined on the <a href="how_tunnelrouting">tunnel routing</a> page).
+inbound and outbound virtual paths ("tunnels", as outlined on the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel routing</a> page).
Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers
communicate with each other through existing transport mechanisms (TCP, UDP, etc), passing various
messages. Client applications have their own cryptographic identifier ("Destination") which enables it
to send and receive messages. These clients can connect to any router and authorize the temporary
allocation ("lease") of some tunnels that will be used for sending and receiving messages through the
-network. I2P has its own internal <a href="how_networkdatabase">network database</a> (using a modification of
+network. I2P has its own internal <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> (using a modification of
the Kademlia algorithm) for distributing routing and contact information securely.</p>
-<div class="box" style="text-align:center;"><img src="_static/images/net.png" alt="Network topology example" title="Network topology example" /></div>
+<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/net.png') }}" alt="Network topology example" title="Network topology example" /></div>
<p>In the above, Alice, Bob, Charlie, and Dave are all running routers with a single Destination on their
@@ -73,7 +73,7 @@ network database, which is constantly updated as new leases are authorized and o
<p>If Bob wants to reply to Alice, he simply goes through the same process - send a message out one of his
outbound tunnels targeting one of Alice's inbound tunnels (tunnel 1 or 2). To make things easier, most
-messages sent between Alice and Bob are <a href="how_garlicrouting">garlic</a> wrapped, bundling the
+messages sent between Alice and Bob are <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic</a> wrapped, bundling the
sender's own current lease information so that the recipient can reply immediately without having to look
in the network database for the current data.</p>
@@ -81,12 +81,12 @@ in the network database for the current data.</p>
hence there are no directory servers keeping statistics regarding the performance and reliability of
routers within the network. As such, each router must keep and maintain profiles of various routers
and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability
-needs of the users, as described in the <a href="how_peerselection">peer selection</a> page.</p>
+needs of the users, as described in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> page.</p>
-<p>The network itself makes use of a significant number of <a href="how_cryptography">cryptographic techniques and algorithms</a> -
+<p>The network itself makes use of a significant number of <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">cryptographic techniques and algorithms</a> -
a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding,
1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to
-station authentication, and <a href="how_elgamalaes">ElGamal / AES+SessionTag</a>.</p>
+station authentication, and <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal / AES+SessionTag</a>.</p>
<p>Content sent over I2P is encrypted through three layers garlic encryption (used to verify the delivery of the message to
the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel
@@ -98,9 +98,9 @@ Notice the different use of terms! All data from a to h is end-to-end encrypted,
between the I2P router and the applications is not end-to-end encrypted!
A and h are the routers of Alice and Bob, while Alice and Bob in following chart are the applications running atop of I2P.</p>
-<div class="box" style="text-align:center;"><img src="_static/images/endToEndEncryption.png" alt="End to end layered encryption" title="End to end layered encryption." /></div>
+<div class="box" style="text-align:center;"><img src="{{ url_for('static', filename='images/endToEndEncryption.png') }}" alt="End to end layered encryption" title="End to end layered encryption." /></div>
-<p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a>.</p>
+<p>The specific use of these algorithms are outlined <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">elsewhere</a>.</p>
<p>The two main mechanisms for allowing people who need strong anonymity to use the network are
explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling
@@ -111,7 +111,7 @@ flexible and anonymous transports.</p>
<p>Some questions have been raised with regards to the scalability of I2P, and reasonably so. There
will certainly be more analysis over time, but peer lookup and integration should be bounded by
-<code>O(log(N))</code> due to the <a href="how_networkdatabase">network database</a>'s algorithm, while end to end
+<code>O(log(N))</code> due to the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>'s algorithm, while end to end
messages should be <code>O(1)</code> (scale free), since messages go out K hops through the outbound
tunnel and another K hops through the inbound tunnel, with K no longer than 3.
The size of the network (N) bears no impact.</p>
@@ -138,13 +138,13 @@ are being written in Python and other languages. The code works on <a href="http
<p>Anyone interested should
join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, irc.freshcoffee.i2p, irc.welterde.i2p and irc.einirc.de).
There are currently no scheduled development meetings, however
-<a href="meetings">archives are available</a>.</p>
+<a href="{{ url_for('meetings_index', lang=g.lang) }}">archives are available</a>.</p>
<p>The current source is available in <a href="monotone.html">monotone</a>.</p>
<h2>Additional Information</h2>
<p>
-See <a href="how.html">the Index to Technical Documentation</a>
+See <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">the Index to Technical Documentation</a>
</p>
{% endblock %}
diff --git a/www.i2p2/pages/how_networkcomparisons.html b/www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
similarity index 97%
rename from www.i2p2/pages/how_networkcomparisons.html
rename to www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
index f3733e99006e951f0dbba0802a650dd754088946..2a15493cb567d1ae935a7d5d1bab566a7bd057e6 100644
--- a/www.i2p2/pages/how_networkcomparisons.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/networkcomparisons.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}I2P Compared to Tor and Freenet{% endblock %}
{% block content %}<p>There are a great many other applications and projects working on anonymous
communication and I2P has been inspired by much of their efforts. This is not
@@ -37,8 +37,8 @@ supports hidden services as well). In addition, Tor
takes the directory-based approach - providing a
centralized point to manage the overall 'view' of the
network, as well as gather and report statistics, as
-opposed to I2P's distributed <a href="how_networkdatabase">network
-database</a> and <a href="how_peerselection">peer selection</a>.</p>
+opposed to I2P's distributed <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network
+database</a> and <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a>.</p>
<p>The I2P/Tor outproxy functionality does have a few
substantial weaknesses against certain attackers -
diff --git a/www.i2p2/pages/how_networkdatabase.html b/www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
similarity index 97%
rename from www.i2p2/pages/how_networkdatabase.html
rename to www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
index 3f44ccbad33d1dbd9b89a2862880c3b5009bc171..f05d9761b17a4f34c6047944d2eccc8fa44404cb 100644
--- a/www.i2p2/pages/how_networkdatabase.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/networkdatabase.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}The Network Database{% endblock %}
{% block content %}
@@ -506,7 +506,7 @@
<h2 id="threat">Threat Analysis</h2>
<p>
- Also discussed on <a href="how_threatmodel.html#floodfill">the threat model page</a>.
+ Also discussed on <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#floodfill">the threat model page</a>.
</p>
<p>
A hostile user may attempt to harm the network by
@@ -538,7 +538,7 @@
<h3>Slow or Unresponsive</h3>
<p>
Each router maintains an expanded set of statistics in the
- <a href="how_peerselection.html">peer profile</a> for each floodfill router,
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profile</a> for each floodfill router,
covering various quality metrics for that peer.
The set includes:
</p>
@@ -709,7 +709,7 @@ This attack becomes more difficult as the network size grows.
</p>
<p>
This doesn't have much to do with floodfill, but see
- the <a href="how_peerselection">peer selection page</a>
+ the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>
for a discussion of the vulnerabilities of peer selection for tunnels.
</p>
@@ -722,8 +722,8 @@ This attack becomes more difficult as the network size grows.
This paper addresses weaknesses in the "Finger Table" DHT lookups used by Torsk and NISAN.
At first glance, these do not appear to apply to I2P. First, the use of DHT by Torsk and NISAN
is significantly different from that in I2P. Second, I2P's network database lookups are only
- loosely correlated to the <a href="how_peerselection">peer selection</a> and
- <a href="how_tunnelrouting">tunnel building</a> processes; only previously-known peers
+ loosely correlated to the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> and
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/tunnelrouting') }}">tunnel building</a> processes; only previously-known peers
are used for tunnels.
Also, peer selection is unrelated to any notion of DHT key-closeness.
</p>
@@ -739,7 +739,7 @@ This attack becomes more difficult as the network size grows.
The floodfill routers are in a position to observe queries and gather information.
Certainly, at a level of <i>f</i> = 0.2 (20% malicious nodes, as specifed in the paper)
we expect that many of the Sybil threats we describe
- (<a href="how_threatmodel.html#sybil">here</a>,
+ (<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#sybil">here</a>,
<a href="#sybil">here</a> and
<a href="#sybil-partial">here</a>)
become problematic for several reasons.
diff --git a/www.i2p2/pages/how_peerselection.html b/www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
similarity index 92%
rename from www.i2p2/pages/how_peerselection.html
rename to www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
index 429a028d96e25dc46ba00e0db115a669062c1ef2..693d5c1bb346bfca77eaf54d4e8ffd3ddf90f9b4 100644
--- a/www.i2p2/pages/how_peerselection.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/peerselection.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Peer Profiling and Selection{% endblock %}
{% block content %}
@@ -11,14 +11,14 @@ Updated July 2010 for release 0.8
<p><b>Peer profiling</b> is the process of collecting data based on the <b>observed</b> performance
of other routers or peers, and classifying those peers into groups.
Profiling does <b>not</b> use any claimed performance data published by the peer itself
-in the <a href="how_networkdatabase.html">network database</a>.
+in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>.
<p>
Profiles are used for two purposes:
<ol>
<li>Selecting peers to relay our traffic through, which is discussed below
<li>Choosing peers from the set of floodfill routers to use for network database storage and queries,
- which is discussed on the <a href="how_networkdatabase.html">network database</a> page
+ which is discussed on the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a> page
</ol>
@@ -38,7 +38,7 @@ All peer selection is done through profiling.
This prevents simple attacks based on peers claiming high bandwidth
in order to capture large numbers of tunnels.
It also makes
-<a href="how_threatmodel.html#timing">timing attacks</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#timing">timing attacks</a>
more difficult.
</p>
<p>
@@ -49,7 +49,7 @@ of client and exploratory tunnels, and a tunnel lifetime is only 10 minutes.
<h3>Further Information</h3>
<p>
For more information see the paper
-<a href="/_static/pdf/I2P-PET-CON-2009.1.pdf">Peer Profiling and Selection in the I2P Anonymous Network</a>
+<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
presented at
<a href="http://www.pet-con.org/index.php/PET_Convention_2009.1">PET-CON 2009.1</a>.
See <a href="#notes">below</a> for notes on minor changes since the paper was published.
@@ -230,7 +230,7 @@ Use GeoIP data to include or exclude certain peers, if configured
<h2 id="notes">Notes</h2>
For those reading the paper
-<a href="/_static/pdf/I2P-PET-CON-2009.1.pdf">Peer Profiling and Selection in the I2P Anonymous Network</a>,
+<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>,
please keep in mind the following minor changes in I2P since the paper's publication:
<ul>
<li>The Integration calculation is still not used
@@ -243,7 +243,7 @@ please keep in mind the following minor changes in I2P since the paper's publica
<h2>References</h2>
<ul>
<li>
-<a href="/_static/pdf/I2P-PET-CON-2009.1.pdf">Peer Profiling and Selection in the I2P Anonymous Network</a>
+<a href="{{ url_for('static', filename='pdf/I2P-PET-CON-2009.1.pdf') }}">Peer Profiling and Selection in the I2P Anonymous Network</a>
<li>
<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
<li>
diff --git a/www.i2p2/pages/how_threatmodel.html b/www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
similarity index 94%
rename from www.i2p2/pages/how_threatmodel.html
rename to www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
index 604cd01cf49833088dbb07802131204758074455..f82c345522074d81250949f62075df5d2a2f3bc1 100644
--- a/www.i2p2/pages/how_threatmodel.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/threatmodel.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}I2P's Threat Model{% endblock %}
{% block content %}
@@ -24,7 +24,7 @@ More review of existing literature (much of it focused on Tor) and original
work focused on I2P is needed.</p>
<h2>Network Topology Summary</h2>
-<p>I2P builds off the ideas of many <a href="how_networkcomparisons">other</a>
+<p>I2P builds off the ideas of many <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">other</a>
<a href="links">systems</a>, but a few key points should be kept in mind when
reviewing related literature:</p><ul>
<li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
@@ -88,8 +88,8 @@ As we continue to spread the word and grow the network,
these attacks will become much harder.
</p><p>
The
-<a href="how_networkcomparisons.html">network comparisons</a> and
-<a href="how_garlicrouting.html">"garlic" terminology</a> pages may also be helpful
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">network comparisons</a> and
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
to review.
</p>
@@ -147,7 +147,7 @@ routers contain limits as to how many tunnels can be routed through a single pee
As the network grows, these limits are subject to further adjustment.
Other mechanisms for peer rating, selection and avoidance
are discussed on the
-<a href="how_peerselection.html">peer selection page</a>.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection page</a>.
</p>
@@ -203,7 +203,7 @@ Partial defenses implemented in I2P:
<ul><li>
<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
</li><li>
-<a href="how_peerselection.html">peer profiling and selection</a> from a small group that changes slowly
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
</li><li>
Limits on the number of tunnels routed through a single peer
</li><li>
@@ -211,7 +211,7 @@ Prevention of peers from the same /16 IP range from being members of a single tu
</li><li>
For eepsites or other hosted services, we support
simultaneous hosting on multiple routers, or
-<a href="http://www.i2p2.i2p/how_threatmodel#intersection">multihoming</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}#intersection">multihoming</a>
</li></ul>
Even in total, these defenses are not a complete solution.
@@ -270,7 +270,7 @@ each with different costs and consequences:</p><ul>
Alternatively, the nodes may provide intermittent service by periodically
dropping selected traffic, or refusing connections to certain peers.
This behavior may be indistinguishable from that of a heavily-loaded or failing node.
- I2P addresses these issues by maintaining <a href="how_peerselection.html">profiles</a> on the
+ I2P addresses these issues by maintaining <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">profiles</a> on the
peers, attempting to identify underperforming ones and simply ignoring
them, or using them rarely.
We have significantly enhanced the
@@ -305,10 +305,10 @@ each with different costs and consequences:</p><ul>
A floodfill router may provide bad or no response to lookups, and
it may also interfere with inter-floodfill communication.
Some defenses and
- <a href="how_peerselection">peer profiling</a> are implemented,
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> are implemented,
however there is much more to do.
For more information see the
- <a href="how_networkdatabase.html#threat">network database page</a>.
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
</li>
</ul>
@@ -356,7 +356,7 @@ matter, the attacker would need to control a significant portion of the network
which other tunnels or messages have those delays).
</p><p>
Also discussed on the
- <a href="how_networkdatabase.html#threat">network database page</a> (bootstrap attack).
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
</p>
<h3 id="predecessor">Predecessor attacks</h3>
@@ -371,7 +371,7 @@ target is located. </p>
<p>I2P avoids this in four ways: first, the peers selected to participate in
tunnels are not randomly sampled throughout the network - they are derived from
-the <a href="how_peerselection">peer selection</a> algorithm which breaks them
+the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
into tiers. Second, with <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
in a tunnel, the fact that a peer shows up more frequently does not mean they're
the source. Third, with <a href="tunnel-alt.html#length">permuted tunnel length</a>
@@ -505,7 +505,7 @@ in several IP blocks.
However, this is not a meaningful defense against a powerful adversary.
</p><p>
See the
- <a href="how_networkdatabase.html#threat">network database page</a>
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>
for more Sybil discussion.
</p>
@@ -521,7 +521,7 @@ that a tunnel is formed wholly from its set of colluding routers.
The chances of success are enhanced if there is a large number of colluding routers,
i.e. a <a href="#sybil">Sybil attack</a>.
This is somewhat mitigated by our
-<a href="how_peerselection">peer profiling</a> methods used to monitor the performance
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
of peers.
However, this is a powerful attack as the number of routers approaches
<i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
@@ -537,7 +537,7 @@ Further research and defenses may be necessary.
<p>
We use strong cryptography with long keys, and
we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
-<a href="how_cryptography">on the low-level cryptography page</a>.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">on the low-level cryptography page</a>.
Security features
include the immediate detection of
altered messages along the path, the inability to decrypt messages not addressed to you,
@@ -555,7 +555,7 @@ shared secret values while maintaining backward compatibility.
</p><p>
Upgrading the various data structures and protocols to support longer keys
will have to be tackled eventually, and this will be a
-<a href="how_cryptography">major undertaking</a>, just as it will be for
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/cryptography') }}">major undertaking</a>, just as it will be for
<a href="https://torproject.org/">others</a>.
Hopefully, through careful planning, we can minimize the disruption, and
implement mechanisms to make it easier for future transitions.
@@ -578,9 +578,9 @@ in the netDb, and the high frequency of communication with those participants.
This is somewhat mitigated because floodfill routers only manage a portion
of the total keyspace, and the keyspace rotates daily, as explained
on the
- <a href="how_networkdatabase.html#threat">network database page</a>.
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
The specific mechanisms by which routers communicate with floodfills have been
- <a href="how_networkdatabase.html#delivery">carefully designed</a>.
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#delivery">carefully designed</a>.
However, these threats should be studied further.
The specific potential threats and corresponding defenses are a topic for future research.
</p>
@@ -592,7 +592,7 @@ The specific potential threats and corresponding defenses are a topic for future
creating one or more floodfill routers and crafting them to offer
bad, slow, or no responses.
Several scenarios are discussed on the
- <a href="how_networkdatabase.html#threat">network database page</a>.
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#threat">network database page</a>.
</p>
diff --git a/www.i2p2/pages/how_tunnelrouting.html b/www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
similarity index 90%
rename from www.i2p2/pages/how_tunnelrouting.html
rename to www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
index cc9849de804938bcc9ab59581c440b40bbf69542..43ae9767d90de407b15d06a8ca469b87a55e2a64 100644
--- a/www.i2p2/pages/how_tunnelrouting.html
+++ b/www.i2p2/i2p2www/pages/site/docs/how/tunnelrouting.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Tunnel Overview{% endblock %}
{% block content %}
<p>
@@ -10,7 +10,7 @@ Updated July 2011 for release 0.8.7
This page contains an overview of I2P tunnel terminology and operation, with
links to more technical pages, details, and specifications.
</p>
-<p>As briefly explained in the <a href="how_intro">introduction</a>, I2P builds virtual "tunnels" -
+<p>As briefly explained in the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how') }}">introduction</a>, I2P builds virtual "tunnels" -
temporary and unidirectional paths through a sequence of routers. These
tunnels are classified as either inbound tunnels (where everything
given to it goes towards the creator of the tunnel) or outbound tunnels
@@ -20,7 +20,7 @@ her existing outbound tunnels with instructions for that tunnel's endpoint
to forward it to the gateway router for one of Bob's current inbound
tunnels, which in turn passes it to Bob.</p>
<p style="text-align:center;">
-<img src="/_static/images/tunnelSending.png" alt="Tunnel" />
+<img src="{{ url_for('static', filename='images/tunnelSending.png') }}" alt="Tunnel" />
<pre>
A: Outbound Gateway (Alice)
B: Outbound Participant
@@ -35,7 +35,7 @@ F: Inbound Endpoint (Bob)
<ul>
<li class="gap"><b>Tunnel gateway</b> - the first router in a tunnel. For inbound tunnels,
this is the one mentioned in the LeaseSet published in the
- <a href="how_networkdatabase">network database</a>. For outbound tunnels, the
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">network database</a>. For outbound tunnels, the
gateway is the originating router. (e.g. both A and D above)</li>
<li class="gap"><b>Tunnel endpoint</b> - the last router in a tunnel. (e.g. both C and F above)</li>
<li class="gap"><b>Tunnel participant</b> - all routers in a tunnel except for the gateway or
@@ -157,7 +157,7 @@ but could show similar information (though would be slightly harder to mount)</p
<h3>1-hop tunnels</h3>
<p>With only one remote router in a tunnel, the user has both plausible
deniability and basic anonymity, as long as they are not up against an internal
-adversary (as described on <a href="how_threatmodel">threat model</a>). However,
+adversary (as described on <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/threatmodel') }}">threat model</a>). However,
if the adversary ran a sufficient number of routers such that the single remote
router in the tunnel is often one of those compromised ones, they would be able
to mount the above statistical traffic analysis attack.</p>
@@ -190,12 +190,12 @@ DeliveryStatusMessage out an outbound tunnel and bound for another inbound tunne
functional. If it was used for a client's inbound tunnel, a new leaseSet
is created.
Tunnel test failures are also reflected in the
-<a href="how_peerselection.html#capacity">capacity rating in the peer profile</a>.
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/peerselection') }}#capacity">capacity rating in the peer profile</a>.
</p>
<h2>Tunnel creation</h2>
-<p>Tunnel creation is handled by <a href="how_garlicrouting">garlic routing</a>
+<p>Tunnel creation is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
a Tunnel Build Message to a router, requesting that they participate in the
tunnel (providing them with all of the appropriate information, as above, along
with a certificate, which right now is a 'null' cert, but will support hashcash
@@ -207,7 +207,7 @@ Details are in the
<h2>Tunnel encryption</h2>
-<p>Multi-layer encryption is handled by <a href="how_garlicrouting">garlic encryption</a>
+<p>Multi-layer encryption is handled by <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic encryption</a>
of tunnel messages.
Details are in the
<a href="tunnel-alt.html">tunnel specification</a>.
@@ -245,9 +245,9 @@ tunnel's lifetime may be implemented (e.g. no more than 300 messages or
</li><li>
<a href="tunnel_message_spec.html">tunnel message specification</a>
</li><li>
-<a href="how_garlicrouting.html">garlic routing</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/garlicrouting') }}">garlic routing</a>
</li><li>
-<a href="how_elgamalaes.html">ElGamal/AES+SessionTag</a>
+<a href="{{ url_for('site_show', lang=g.lang, page='docs/how/elgamalaes') }}">ElGamal/AES+SessionTag</a>
</li><li>
<a href="i2cp.html#options">I2CP options</a>
</li>
diff --git a/www.i2p2/pages/techintro.html b/www.i2p2/i2p2www/pages/site/docs/techintro.html
similarity index 98%
rename from www.i2p2/pages/techintro.html
rename to www.i2p2/i2p2www/pages/site/docs/techintro.html
index 3e4645f20aa7cd23dc8becd6ccf70616e8f0c394..e05b35c99fd688f5de63bd46114cf6e1a2b10b16 100644
--- a/www.i2p2/pages/techintro.html
+++ b/www.i2p2/i2p2www/pages/site/docs/techintro.html
@@ -1,4 +1,4 @@
-{% extends "_layout.html" %}
+{% extends "global/layout.html" %}
{% block title %}Introducing I2P{% endblock %}
{% block content %}
@@ -111,7 +111,7 @@
another tunnel is required.
</p>
<div class="box" style="text-align:center;">
- <img src="_static/images/tunnels.png" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
+ <img src="{{ url_for('static', filename='images/tunnels.png') }}" alt="Inbound and outbound tunnel schematic" title="Inbound and outbound tunnel schematic" />
<br /><br />
Figure 1: Two types of tunnels exist: inbound and outbound.
</div>
@@ -159,9 +159,9 @@
that router to send the construction message onward, until the tunnel has been constructed.
</p>
<div class="box" style="text-align:center;">
- <img src="_static/images/netdb_get_routerinfo_1.png" alt="Request information on other routers" title="Request information on other routers" />
+ <img src="{{ url_for('static', filename='images/netdb_get_routerinfo_1.png') }}" alt="Request information on other routers" title="Request information on other routers" />
- <img src="_static/images/netdb_get_routerinfo_2.png" alt="Build tunnel using router information" title="Build tunnel using router information" />
+ <img src="{{ url_for('static', filename='images/netdb_get_routerinfo_2.png') }}" alt="Build tunnel using router information" title="Build tunnel using router information" />
<br /><br />
Figure 2: Router information is used to build tunnels.
</div>
@@ -183,7 +183,7 @@
for it when he wants to reply, but this is optional.
</p>
<div class="box" style="text-align:center;">
- <img src="_static/images/netdb_get_leaseset.png" alt="Connect tunnels using leaseSets" title="Connect tunnels using leaseSets" />
+ <img src="{{ url_for('static', filename='images/netdb_get_leaseset.png') }}" alt="Connect tunnels using leaseSets" title="Connect tunnels using leaseSets" />
<br /><br />
Figure 3: Leasesets are used to connect outbound and inbound tunnels.
</div>
@@ -306,7 +306,7 @@
<h2 id="op.netdb">Network Database</h2>
<p>
As mentioned earlier, I2P's netDb works to share the network's metadata.
- This is detailed in <a href="how_networkdatabase.html">the networkdatabase</a> page,
+ This is detailed in <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}">the networkdatabase</a> page,
but a basic explanation is available below.
</p>
<p>
@@ -320,7 +320,7 @@
If a floodfill router receives a 'store' query, it will spread the information to other floodfill routers
using the <a href="http://en.wikipedia.org/wiki/Kademlia">Kademlia algorithm</a>.
The 'lookup' queries currently function differently, to avoid an important
- <a href="how_networkdatabase.html#lookup">security issue</a>.
+ <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkdatabase') }}#lookup">security issue</a>.
When a lookup is done, the floodfill router will not forward the lookup to other peers,
but will always answer by itself (if it has the requested data).
</p>
@@ -576,7 +576,7 @@ What other tunnel peer selection and ordering strategies should be available?
the research results of existing systems and papers. While there are a few
similar efforts worth reviewing, both for technical and functional comparisons,
two in particular are pulled out here - Tor and Freenet. </p>
- <p> See also the <a href="how_networkcomparisons.html">Network Comparisons Page</a>.
+ <p> See also the <a href="{{ url_for('site_show', lang=g.lang, page='docs/how/networkcomparisons') }}">Network Comparisons Page</a>.
</p>
<h2 id="similar.tor">Tor</h2>