forked from I2P_Developers/i2p.www
Migrated intro page
This commit is contained in:
@@ -114,6 +114,7 @@
|
||||
</li>
|
||||
<li class="has-sub"><a href="#"><span>{{ _('About') }}</span></a>
|
||||
<ul>
|
||||
<li><a href="{{ site_url('about/intro') }}"><span>{{ _('Introduction to I2P') }}</span></a></li>
|
||||
<li><a href="{{ site_url('about/team') }}"><span>{{ _('Team') }}</span></a></li>
|
||||
<li><a href="{{ site_url('about/halloffame') }}"><span>{{ _('Hall of Fame') }}</span></a></li>
|
||||
<li><a href="{{ site_url('about/papers') }}"><span>{{ _('Papers and presentations') }}</span></a></li>
|
||||
|
86
i2p2www/pages/site/about/intro.html
Normal file
86
i2p2www/pages/site/about/intro.html
Normal file
@@ -0,0 +1,86 @@
|
||||
{% extends "global/layout.html" %}
|
||||
{% block title %}Intro{% endblock %}
|
||||
{% block content %}
|
||||
<h1>The Invisible Internet Project (I2P)</h1>
|
||||
<p>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
|
||||
strictly message based (a la
|
||||
<a href="http://en.wikipedia.org/wiki/Internet_Protocol">IP</a>), but there is a
|
||||
library available to allow reliable streaming communication on top of it (a la
|
||||
<a href="http://en.wikipedia.org/wiki/Transmission_Control_Protocol">TCP</a>).
|
||||
All communication is end to end encrypted (in total there are four layers of
|
||||
encryption used when sending a message), and even the end points ("destinations")
|
||||
are cryptographic identifiers (essentially a pair of <a href="http://en.wikipedia.org/wiki/Public_key_encryption">public keys</a>).</p>
|
||||
|
||||
<h2>How does it work?</h2>
|
||||
|
||||
<p>To anonymize the messages sent, each client application has their I2P "router"
|
||||
build a few inbound and outbound "<a href="{{ site_url('docs/how/tunnelrouting') }}">tunnels</a>" - a
|
||||
sequence of peers that pass messages in one direction (to and from the client,
|
||||
respectively). In turn, when a client wants to send a message to another client,
|
||||
the client passes that message out one of their outbound tunnels targeting one of the
|
||||
other client's inbound tunnels, eventually reaching the destination. Every
|
||||
participant in the network chooses the length of these tunnels, and in doing so,
|
||||
makes a tradeoff between anonymity, latency, and throughput according to their
|
||||
own needs. The result is that the number of peers relaying each end to end
|
||||
message is the absolute minimum necessary to meet both the sender's and the
|
||||
receiver's threat model.</p>
|
||||
|
||||
<p>The first time a client wants to contact another client, they make a query
|
||||
against the fully distributed "<a href="{{ site_url('docs/how/networkdatabase') }}">network
|
||||
database</a>" - a custom structured <a href="http://en.wikipedia.org/wiki/Distributed_hash_table">
|
||||
distributed hash table (DHT)</a> based off the
|
||||
<a href="http://en.wikipedia.org/wiki/Kademlia"> Kademlia algorithm</a>. This is done
|
||||
to find the other client's inbound tunnels efficiently, but subsequent messages
|
||||
between them usually includes that data so no further network database lookups
|
||||
are required.</p>
|
||||
|
||||
<p>More details about how I2P works are <a href="{{ site_url('docs') }}">available</a>.</p>
|
||||
|
||||
<h2>What can you do with it?</h2>
|
||||
|
||||
<p>Within the I2P network, applications are not restricted in how they can
|
||||
communicate - those that typically use UDP can make use of the base I2P
|
||||
functionality, and those that typically use TCP can use the TCP-like streaming
|
||||
library. We have a generic TCP/I2P bridge application
|
||||
("<a href="{{ site_url('docs/api/i2ptunnel') }}">I2PTunnel</a>") that enables people to forward TCP streams
|
||||
into the I2P network as well as to receive streams out of the network and
|
||||
forward them towards a specific TCP/IP address.</p>
|
||||
|
||||
<p>I2PTunnel is currently used to let people run their own anonymous website
|
||||
("eepsite") by running a normal webserver and pointing an I2PTunnel 'server'
|
||||
at it, which people can access anonymously over I2P with a normal web browser
|
||||
by running an I2PTunnel HTTP proxy ("eepproxy"). In addition, we use the same
|
||||
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
|
||||
<a href="http://bitconjurer.org/BitTorrent/">BitTorrent</a>), a
|
||||
distributed data store (a la <a href="http://freenetproject.org/">Freenet</a> /
|
||||
<a href="http://mnetproject.org/">MNet</a>), and a blogging system (a fully
|
||||
distributed <a href="http://www.livejournal.com/">LiveJournal</a>), but those are
|
||||
not ready for use yet.</p>
|
||||
|
||||
<p>I2P is not inherently an "outproxy" network - the client you send a message
|
||||
to is the cryptographic identifier, not some IP address, so the message must
|
||||
be addressed to someone running I2P. However, it is possible for that client
|
||||
to be an outproxy, allowing you to anonymously make use of their Internet
|
||||
connection. To demonstrate this, the "eepproxy" will accept normal non-I2P
|
||||
URLs (e.g. "http://www.i2p.net") and forward them to a specific destination
|
||||
that runs a <a href="http://www.squid-cache.org/">squid</a> HTTP proxy, allowing
|
||||
simple anonymous browsing of the normal web. Simple outproxies like that are
|
||||
not viable in the long run for several reasons (including the cost of running
|
||||
one as well as the anonymity and security issues they introduce), but in
|
||||
certain circumstances the technique could be appropriate.</p>
|
||||
|
||||
<p>The I2P development <a href="{{ site_url('about/team') }}">team</a> is an open group, welcome to all
|
||||
who are interested in <a href="{{ site_url('volunteer') }}">getting involved</a>, and all of
|
||||
the code is <a href="{{ site_url('volunteer/develop/licenses') }}">open source</a>. The core I2P SDK and the
|
||||
current router implementation is done in Java (currently working with both
|
||||
sun and kaffe, gcj support planned for later), and there is a
|
||||
<a href="{{ site_url('docs/api/sam') }}">simple socket based API</a> for accessing the network from
|
||||
other languages (with a C library available, and both Python and Perl in
|
||||
development). The network is actively being developed and has not yet reached
|
||||
the 1.0 release, but the current <a href="{{ site_url('volunteer/roadmap') }}">roadmap</a> describes
|
||||
our schedule.</p>
|
||||
{% endblock %}
|
Reference in New Issue
Block a user