Inside I2P

Understanding the Invisible Internet

Most people who want online anonymity default to using Tor as it's well documented, and using the Onion Browser makes using it trivial. Tor does hidden services too, but it was designed to give you anonymous access to the regular internet, clearnet sites, just without your IP attached.

I2P stands for Invisible Internet Project. It's an anon network layer that's been running since 2003. Tor is an anonymous proxy to the outside world, I2P is a network within itself. Its purpose is to communicate, share, and host services in a space that is entirely self-contained and decentralised.

Everything on I2P runs inside I2P. Websites (.i2p domains called eepsites), forums, file sharing, messaging. You browse to a hidden service that only exists within the network not the clearnet.


Garlic Routing

Tor uses onion routing where your traffic is wrapped in layers of encryption and passes through relays. The entry node knows your IP, the exit node knows the destination, but neither knows both your identity and destination together.

I2P uses garlic routing, which takes this further, instead of sending one message through a chain, I2P bundles multiple encrypted messages together into a single packet and routes them through the network together. This makes traffic correlation significantly harder, because an observer can't easily match a single message going in with a single message coming out.

More importantly, I2P tunnels are unidirectional. Your outbound traffic and inbound traffic travel through completely separate tunnels. Your connection is encrypted through a chain of six random nodes by default, three for outbound, three for inbound. If one drops, I2P rebuilds the tunnel automatically.

Decentralisation vs Tor

Tor has directory authorities, a small number of trusted servers that maintain a list of all relays. When you start Tor, you contact these servers to get the current relay list. They are a central point of trust, and theoretically of failure or attack.

Instead of a central directory, I2P uses a distributed hash table called the NetDB. Every I2P node stores a portion of the network's router information. When you join, you reseed from a few bootstrap nodes to get your initial list, and from there the network is entirely peer-to-peer. There is no list of relays to seize and no directory authority is present.

Every I2P node also routes transit traffic for others by default, making the network more resilient and due to this, traffic analysis harder because everyone's node is simultaneously sending and receiving traffic for multiple parties.


The Ecosystem

Because I2P is self-contained, it has its own ecosystem that's been active for over two decades:

  • Eepsites: websites hosted inside I2P, accessible only from within the network. .i2p domains are resolved internally. There are forums, wikis, Gitlab instances, and communities that exist nowhere on the clearnet.
  • I2PSnark: a built-in torrent client that operates entirely within I2P. Popular for obvious reasons.
  • I2P-Bote: serverless, encrypted email over I2P. No mail server, messages are stored in a distributed hash table.
  • I2P Messenger: real-time messaging within the network.

The ecosystem is less polished than Tor's but it's more self-sufficient. Tor's hidden services exist largely as an extension of the clearnet whereas I2P's hidden services are the center of the network.


i2pd

The original I2P router is written in Java, which was heavy, not ideal for a Pi or a lightweight VM. i2pd is a full C++ reimplementation, lighter and better suited for always-on nodes and low-power hardware.

Installation on Debian/Ubuntu is straightforward:

sudo add-apt-repository ppa:purplei2p/i2pd
sudo apt-get update
sudo apt-get install i2pd

Once running, i2pd exposes a web console at localhost:7070 where you can monitor tunnel status, bandwidth, known routers, and network health. The router selects a random port between 9000 and 31000 for inbound traffic on first run. Worth port forwarding this if you want full connectivity rather than firewalled status.

Unlike Reticulum which is immediately connected, I2P takes time to integrate into the network. Tunnel build success rates start low and improve over hours and days as your node builds a profile of reliable peers.

Running a Node

As said before, running an i2pd node makes you an active participant. Your node routes transit traffic, contributes bandwidth, and over time becomes a known reliable peer. The longer it runs, the better your tunnel build success rate and the more you contribute to the network's resilience. A regular node routes traffic but does not store network topology data, floodfill is an optional step up from there.

A floodfill node also stores and serves RouterInfo and LeaseSet records to other nodes, basically hosting a shard of the NetDB, the distributed hash table that holds the network together. Without enough floodfill nodes the network degrades, so running one is a meaningful contribution if you have a stable public IP, an open port, and spare bandwidth.

Edit /etc/i2pd/i2pd.conf and add:

[router]
floodfill = true

[bandwidth]
limit = O #Means 256 KB/s which is the minimum recommended for floodfill. Use "X" for unlimited.

Restart i2pd after:

sudo systemctl restart i2pd

Your router status in the web console at localhost:7070 will update to reflect floodfill mode once the network recognises it, which can take a few hours.


Final Thoughts

I2P has been running for over 20 years and continues running strong. If you are serious about decentralised, censorship-resistant communication, hosting a hidden service or simply contributing to infrastructure that has no kill switch, check out I2P.