[$ xmrhost] _

$ diff /etc/overlay/{tor,i2p,lokinet}

[$ ] Tor vs I2P vs Lokinet — for overlay anonymity hosting

// TLDR

Three different design points, three different operational realities. Tor: largest network, mature documentation, the canonical choice for clearnet-bridging anonymity (exits, hidden services). I2P: smaller network, garlic-routing internal applications, no exits in the standard model. Lokinet: stake-collateral routing, OXEN-bonded exits, smallest network, narrowest application coverage. Choose Tor for hidden services and exits; I2P for federated internal services where you do not need to bridge clearnet; Lokinet only if the stake-collateral model is itself a feature (it usually is not).

// AT A GLANCE

$ compare --short

// dimension // tor // i2p // lokinet
routing primitive onion (3 hops, telescoped) garlic (multi-message bundles) onion (LLARP, UDP)
network size (relays) ~7,500 ~30,000 routers ~2,000 service nodes
hidden-service addressing .onion (Ed25519, 56 chars) .b32.i2p (52 chars) .loki (zhash-derived)
exits to clearnet yes (~1,500 exits) limited (outproxies, rare) yes (staked)
node-operation gating none (volunteer) none (volunteer) OXEN stake required
transport protocol TCP TCP + UDP (NTCP2 + SSU) UDP (LLARP)
latency profile 300-800ms typical 500ms-2s typical ~similar to Tor
application coverage browser + service ecosystem internal services (BitTorrent, IRC, eepsites) VPN-style overlay; growing
XMRHost hosting tor-1 / tor-2 / tor-4 (hidden service) i2p-1 (router / floodfill) lokinet-1 (exit, stake brought by tenant)

// TOR — DESIGN POINT

$ man tor

Tor is the largest of the three networks, the most documented, and the one the academic literature on overlay anonymity has tracked continuously since 2004. The design is onion routing (Goldschlag, Reed, Syverson 1996) over a telescoped three-hop circuit. The guard-relay-then-middle-then-exit topology is canon; departures from it (single-hop modes for very-low-latency clearnet bridging) are explicitly out of scope.

For a hosting operator the relevant Tor surfaces are:

  • Hidden services (v3 onion services) — protocol rend-spec-v3, .onion addresses derived from an Ed25519 long-term identity key. The service is not on the public internet; the connection is end-to-end encrypted between client and service through three Tor hops on each side. XMRHost's Tor plans target this profile (hardened tor.conf, no clearnet listener, sshd via onion-auth).
  • Middle relays (non-exit) — forwards traffic between other relays only. Carries no abuse-mail load. Recommended starting profile for a XMRHost VPS contributing to the network.
  • Exit relays — forward traffic to clearnet on behalf of clients. High abuse-mail load; XMRHost does not run exits from its standard Tor tier (the workload routes to /node/lokinet-exit).
  • obfs4 bridges — pluggable-transport-equipped relays that obfuscate the Tor handshake for clients in censorship-active jurisdictions.

// I2P — DESIGN POINT

$ man i2p

I2P (Invisible Internet Project) is older than Tor's hidden-service feature in some respects (initial 2003 release) but has remained substantially smaller. The routing primitive is "garlic routing" — a generalisation of onion routing where each layer can carry multiple bundled messages, which complicates traffic-analysis attacks that work cleanly on Tor's one-message-per-hop model.

Notable I2P design choices:

  • Bidirectional tunnels — each I2P node operates an inbound tunnel and a separate outbound tunnel. A client and a service exchanging messages each terminate two tunnels of their own; the path between them composes four tunnels.
  • netDb (DHT) — Kademlia-derived. Floodfill nodes serve LeaseSet and RouterInfo lookups. Running a floodfill contributes meaningfully to network resilience; XMRHost's i2p-1 plan can run a floodfill or non-exit profile.
  • Application coverage — internal services (eepsites, I2P-native BitTorrent, IRC) are mature; outproxies to clearnet exist but are rare and not part of the protocol's design centre. I2P is not a "browse the open web anonymously" network in the way Tor is via Tor Browser; it is "operate a federated service that other I2P users can reach".
  • UDP support — SSU (newer SSU2) makes I2P viable over NAT-traversed paths where Tor's TCP-only stack struggles.

// LOKINET — DESIGN POINT

$ man lokinet

Lokinet is the youngest of the three. The distinguishing design choice is staking: every Lokinet service node operator locks OXEN tokens as a service-node bond. The bond is an economic primitive against Sybil attacks (an attacker spinning up N service nodes pays for N bonds) and against operator misbehaviour (slashing).

The trade-offs:

  • Sybil resistance vs. accessibility — staking shrinks the operator pool to those willing to lock collateral. Tor and I2P run on volunteer relays; Lokinet runs on bonded service nodes. The latter is harder to flood with adversarial nodes; it is also harder to grow.
  • UDP-based LLARP — Lokinet's transport. Lower latency than Tor in many measurements; works through restrictive NATs better than TCP-onion-routing. Less mature toolchain.
  • VPN-style usage — the canonical Lokinet client model is "tunnel everything through Lokinet" rather than "bookmark a few hidden services". Closer to a privacy VPN with anonymity properties than to Tor's hidden-service-centric model.
  • OXEN-bonded exits — Lokinet supports exits to clearnet. XMRHost hosts the exit infrastructure on the lokinet-1 plan; the tenant brings the OXEN stake and the wallet integration.

// HOW TO CHOOSE

$ man choose-network

Decide on the workload, not on the network's reputation. The common cases:

  • Hosting a website / API reachable from a normal browser via .onion bookmark — Tor v3 hidden service. Tor Browser is the only mainstream client that ships .onion routing by default.
  • Federated internal service (Matrix, BitTorrent tracker, internal IRC, BBS-style forum) for an audience that runs an I2P router — I2P. The garlic routing primitive is well-suited to applications that exchange many small messages.
  • Personal-VPN-style anonymity overlay where the stake-collateral pool is itself a property you value — Lokinet. Less common than the other two.
  • Running a Tor exit relay because you want to contribute exit bandwidth to the network — Tor exit relay (NOT on XMRHost's standard Tor tier — different operator posture). See /playbook/tor-relay.
  • Operating a Lokinet exit (collateral provided) — /node/lokinet-exit.
  • Running an I2P floodfill or non-exit router as contribution to network health — /node/i2p-node.

// SEE ALSO

$ ls /usr/share/doc/xmrhost/networks