From 6b1ac31c06758c6670ebee023d0cf4862d1f1c7c Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Fri, 30 Aug 2013 08:58:59 +0000
Subject: [PATCH] More archive.org link treatment
---
i2p2www/pages/site/about/performance/history.html | 2 +-
i2p2www/pages/site/docs/discussions/tunnel.html | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/i2p2www/pages/site/about/performance/history.html b/i2p2www/pages/site/about/performance/history.html
index d919c51a6..646f64405 100644
--- a/i2p2www/pages/site/about/performance/history.html
+++ b/i2p2www/pages/site/about/performance/history.html
@@ -140,7 +140,7 @@ message based, with the router providing delivery guarantees by garlic wrapping
an "ACK" message in with the payload, so once the data gets to the target, the
ACK message is forwarded back to us [through tunnels, of course]).
{%- endtrans %}</p>
-<p>{% trans link='http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
+<p>{% trans link='http://web.archive.org/web/20070607220008/http://dev.i2p.net/pipermail/i2p/2004-March/000167.html' -%}
As I've <a href="{{ link }}">said</a>, having
I2PTunnel (and the ministreaming lib) go this route was the best thing that
could be done, but more efficient mechanisms are available. When we rip out the
diff --git a/i2p2www/pages/site/docs/discussions/tunnel.html b/i2p2www/pages/site/docs/discussions/tunnel.html
index e8a3b5ce1..bd8995b7f 100644
--- a/i2p2www/pages/site/docs/discussions/tunnel.html
+++ b/i2p2www/pages/site/docs/discussions/tunnel.html
@@ -35,7 +35,7 @@ None of these are currently implemented.
<p>These padding strategies can be used on a variety of levels, addressing the
exposure of message size information to different adversaries. After gathering
-and reviewing some <a href="http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
+and reviewing some <a href="http://web.archive.org/web/20050413140457/http://dev.i2p.net/~jrandom/messageSizes/">statistics</a>
from the 0.4 network, as well as exploring the anonymity tradeoffs, we're starting
with a fixed tunnel message size of 1024 bytes. Within this however, the fragmented
messages themselves are not padded by the tunnel at all (though for end to end
--
GitLab