diff --git a/www.i2p2/pages/how_intro.html b/www.i2p2/pages/how_intro.html
index bb822e7074b43dbc0d92909af6533e71b67bb113..25ae49eaa7ca138d91b66c4e77436999c8dd5d3e 100644
--- a/www.i2p2/pages/how_intro.html
+++ b/www.i2p2/pages/how_intro.html
@@ -37,15 +37,14 @@ app to turn on and off various proxies to enable the anonymizing functionality.<
<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
increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate
-in arbitrarily hostile environments by providing militant grade anonymity, mixed in with sufficient cover
-traffic provided by the activity of people who require less anonymity. This includes letting Joe Sixpack
-chat with his buddies without anyone listening in, Jane Filetrader to share files knowing that large
-corporations cannot identify her, as well as Will Whistleblower to publish sensitive documents -
+in arbitrarily hostile environments by providing good anonymity, mixed in with sufficient cover
+traffic provided by the activity of people who require less anonymity. This way, some users can avoid
+detection by a very powerful adversary, while others will try to evade a weaker entity,
<i>all on the same network</i>, where each one's messages are essentially indistinguishable from the
others.</p>
<h2>Why?</h2>
-<p>There are a multitude of fantastic reasons why we need a system to support
+<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
anonymity to people through the Internet, but we could not find any that met our needs or threat
@@ -87,13 +86,12 @@ routers within the network. As such, each router must keep and maintain profiles
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>
-<p>The network itself makes use of a significant number of cryptographic techniques and algorithms -
+<p>The network itself makes use of a significant number of <a href="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>
-<p>Content sent over I2P is encrypted through three <strike>or four</strike> layers - <strike>end to end encryption (absolutely
-no routers get the plaintext, ever),</strike> garlic encryption (used to verify the delivery of the message to
+<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
gateway to the tunnel endpoint), and inter router transport layer encryption (e.g. the TCP transport
uses AES256 with ephemeral keys):</p>
@@ -107,7 +105,7 @@ A and h are the routers of Alice and Bob, while Alice and Bob in following chart
<p>The specific use of these algorithms are outlined <a href="how_cryptography">elsewhere</a>.</p>
-<p>The two main mechanisms for allowing people who need militant grade anonymity use the network are
+<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
and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no
delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set
@@ -118,7 +116,8 @@ flexible and anonymous transports.</p>
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
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 - the size of the network (N) bears no impact.</p>
+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>
<h2>When?</h2>
<p>I2P initially began in Feb 2003 as a proposed modification to
@@ -130,22 +129,19 @@ Release 0.5 followed in early '05 and 0.6 in mid-'05.
I2P is currently moving forward according to
the <a href="roadmap">roadmap</a>.</p>
-<p>The network itself is not ready for general use, and should not be used by those who need anonymity
-until it has been met with sufficient peer review.</p>
-
<h2>Who?</h2>
<p>We have a small <a href="team">team</a> spread around several continents, working to advance different
aspects of the project. We are very open to other developers who want to get involved and anyone else
who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled
applications, or documentation. The entire system is open source - the router and most of the SDK are
outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel
-and I2PSnark are GPL. Almost everything is written in Java (1.3+), though some third party applications
-are being written in Python. The code works on the current <a href="http://www.kaffe.org/">Kaffe</a>, and
+and I2PSnark are GPL. Almost everything is written in Java (1.5+), though some third party applications
+are being written in Python. The code works on <a href="http://java.com/en/">Sun Java SE</a>, on the current <a href="http://www.kaffe.org/">Kaffe</a>, and
we are hoping to get it working on <a href="http://gcc.gnu.org/java/">GCJ</a> sooner rather than later.</p>
<h2>Where?</h2>
<p>Anyone interested should
-join us on the IRC channel #i2p (hosted concurrently on irc.freenode.net, irc.postman.i2p, and irc.freshcoffee.i2p).
+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>
diff --git a/www.i2p2/pages/roadmap.html b/www.i2p2/pages/roadmap.html
index c903ac9d46a65ee0947d717ccbf964fc38c239c8..c8edec92a7804534fd522127b44187ae179639d3 100644
--- a/www.i2p2/pages/roadmap.html
+++ b/www.i2p2/pages/roadmap.html
@@ -2,16 +2,6 @@
{% block title %}Roadmap{% endblock %}
{% block content %}
-<h2 id="0.8">0.8</h2>
-July 2010
-<ul>
-<li>Further research and improve the <a href="i2np.html">Message Priority System</a></li>
-<li>Reduce <a href="how_peerselection.html">peer profile</a> size, implement better ejection strategy </li>
-<li>Expand and rework the floodfill pool, bring back simplified Kademlia searches and stores for the pool</li>
-<li>Distributed / enhanced i2pupdate distribution, set default to download</li>
-<li>Better better docs and website</li>
-</ul>
-
<h2 id="0.9">0.9</h2>
<ul>
<li>Include some seed data in the distribution so a central reseed location isn't required?