I2P — the Invisible Internet Project — has been in continuous development since around 2003. It is overshadowed by Tor in almost every public discussion, and that is partly fair: Tor has a larger network, more academic scrutiny, and a clearer story for the most common use case. But I2P is not a worse Tor. It is a network optimized for a different goal, and the architectural decisions that follow from that goal are genuinely instructive.
The cleanest way to describe the difference: Tor was designed primarily to let you reach the ordinary internet anonymously, with hidden services bolted on later. I2P was designed primarily to host services inside the network, with reaching the ordinary internet treated as an afterthought. That single difference in priority explains nearly everything else.
Everyone Is a Router
In Tor's model there is a meaningful distinction between clients (people using the network) and relays (volunteers donating bandwidth). Most Tor users are pure clients and never relay anyone else's traffic. A relatively small set of well-provisioned relays carries the load, and a directory of them is published by a handful of trusted directory authorities.
I2P erases that distinction. When you run I2P, you are a router. Your node participates in carrying other people's encrypted traffic by default. This is a deliberate anonymity decision: when every participant relays, the act of relaying tells an observer nothing about whether you are also originating traffic. The cost is that I2P's behavior on a residential connection is more demanding and less predictable than running a Tor client, and the network is smaller — fewer total participants means a smaller anonymity set in absolute terms.
Tor concentrates trust and bandwidth in a curated set of relays governed by directory authorities. I2P distributes both across all participants with no central directory. Concentration buys performance and auditability; distribution buys resilience and removes a coordination chokepoint — at the cost of speed.
Garlic Routing, Not Just Onion Routing
Tor uses onion routing: a message is wrapped in successive layers of encryption, one per relay in the circuit, and each relay peels exactly one layer. I2P uses a variant its designers call garlic routing. The name extends the vegetable metaphor: instead of a single message passing through the layers, I2P can bundle multiple messages — called "cloves" — together into one encrypted unit, like cloves in a bulb of garlic.
Bundling has two benefits. It lets the network batch unrelated messages together, which complicates traffic analysis, and it lets a sender attach delivery instructions and acknowledgements to the same encrypted package. The underlying principle is the same layered encryption that makes onion services work, but the grouping is an extra tool against an observer trying to correlate individual messages.
Unidirectional Tunnels
This is the design choice that surprises people most. A Tor circuit is bidirectional: the same path carries your request out and the response back. I2P instead builds separate inbound and outbound tunnels. When your node sends a message, it leaves through your outbound tunnel; the reply comes back through a different inbound tunnel built from different routers.
The reasoning is that a single observer who compromises one tunnel sees only half of a conversation — only the requests, or only the responses, but not both ends of the same exchange. It doubles the number of tunnels the network has to maintain and makes latency harder to reason about, which is part of why I2P feels slower and bursty compared to a tuned Tor circuit. Tunnels are also short-lived, rebuilt roughly every ten minutes, so the path your traffic takes is constantly rotating.
The netDb Instead of Directory Authorities
Tor's directory authorities are a small number of trusted servers that publish a signed consensus of which relays exist. It is an elegant and auditable design, but it is also a point of centralization — those authorities are a known, named set of machines.
I2P replaces them with the network database, or netDb: a distributed store, built on a Kademlia-style distributed hash table, that holds two kinds of records. "RouterInfo" records describe how to contact a given router; "LeaseSet" records describe how to reach a particular destination (an internal service) through its current inbound tunnels. This information is spread across a subset of participating routers rather than published by a central authority. There is no single list of the whole network to subpoena or block, which is the resilience payoff — at the cost of the clean, globally consistent view that Tor's consensus provides.
Eepsites and the Inside-Out Network
Services hosted inside I2P use .i2p addresses and are historically called "eepsites." Because hosting internal services is I2P's primary design goal rather than a later addition, the network is comfortable being a self-contained space: internal websites, file sharing, email through internal providers, and chat all live within it.
I2P can reach the ordinary internet through "outproxies," which are the rough equivalent of Tor exit nodes — but there are very few of them, they are not a core part of the design, and you should not think of I2P as a general tool for browsing the clearnet anonymously. If reaching the public web anonymously is your goal, Tor is simply the better-fit tool, and it is worth understanding how Tor itself compares to a VPN before reaching for either.
Tor and I2P Side by Side
| Property | Tor | I2P |
|---|---|---|
| Primary use case | Anonymous access to the public internet | Anonymous services hosted inside the network |
| Roles | Distinct clients and relays | Every participant is a router |
| Routing | Onion routing, one message per circuit | Garlic routing, messages bundled as cloves |
| Tunnels | Bidirectional circuits | Separate inbound and outbound tunnels |
| Network view | Signed consensus from directory authorities | Distributed netDb (Kademlia-style DHT) |
| Reaching the clearnet | Core feature, many exit nodes | Possible via rare outproxies, not a focus |
What I2P Does Not Solve
No amount of clever routing changes the fundamentals of anonymity. A global passive adversary who can watch enough of the network's edges can still attempt traffic-analysis and timing correlation against I2P just as against Tor; the smaller network arguably makes some of those attacks easier, not harder, because there is less cover traffic to hide in. I2P also does not encrypt what you do once you reach the clearnet through an outproxy — the same exit-node trust problem Tor has, with far fewer eyes auditing the operators.
And like every anonymity network, I2P protects the network layer, not the application layer. If you log into an account that identifies you, no tunnel design will help. Anonymity is a property of the whole stack, not a single tool.
Where This Fits in a Privacy Stack
I2P is worth understanding because it makes the design trade-offs of anonymous networking unusually visible. It chose distribution over concentration, internal services over clearnet access, and a constantly churning mesh over a curated relay set — and each of those choices has a clear cost as well as a clear benefit. That is the honest shape of every privacy technology: there is no free anonymity, only a choice about where to spend.
For most people, most of the time, the relevant question is not "Tor or I2P" but "what am I actually protecting against, and at which layer?" An anonymity network hides where your traffic comes from. It does not encrypt your conversations end to end, verify who you are talking to, or keep your messages private from the service you are using. Those are the jobs of the application — which is where Haven focuses: encrypting email and chat content under keys that never leave your device, so that the contents of what you send are protected regardless of which network carries the packets.