Context: This page archives long-running debates from the early I2P design era. It captures why the project favoured locally trusted address books over DNS-style lookups or majority-vote registries. For current usage guidance, see the Naming documentation.
Discarded Alternatives
I2P’s security goals rule out familiar naming schemes:
- DNS-style resolution. Any resolver on the lookup path could spoof or censor answers. Even with DNSSEC, compromised registrars or certificate authorities remain a single point of failure. In I2P, destinations are public keys—hijacking a lookup would completely compromise an identity.
- Voting-based naming. An adversary can mint unlimited identities (a Sybil attack) and “win” votes for popular names. Proof-of-work mitigations raise the cost but introduce heavy coordination overhead.
Instead, I2P deliberately keeps naming above the transport layer. The bundled naming library offers a service-provider interface so alternate schemes can coexist—users decide which address books or jump services they trust.
Local vs Global Names (jrandom, 2005)
- Names in I2P are locally unique but human readable. Your
boss.i2pmay not match somebody else’sboss.i2p, and that is by design. - If a malicious actor tricked you into changing the destination behind a name, they would effectively hijack a service. Refusing global uniqueness prevents that class of attack.
- Treat names like bookmarks or IM nicknames—you choose which destinations to trust by subscribing to specific address books or adding keys manually.
Common Objections & Responses (zzz)
| Concern | Response |
|---|---|
| “Downloading hosts.txt is inefficient.” | At ~400 KB for ~800 hosts the bandwidth impact is minor (~10 B/s if refreshed twice daily). ETags already avoid unnecessary transfers. Alternate formats (for example recenthosts.cgi) can deliver only new entries. |
| “It won’t scale.” | A hosts.txt entry is ~500 bytes; storing thousands locally is practical. Real-time lookups would dramatically slow browsing. |
| “Requires trust and manual setup.” | True—and intentional. Users must choose address book providers they trust. Trust is not binary; forcing configuration encourages users to think about it. |
| “Why not just use DNS?” | DNS depends on short TTLs and can be hijacked mid-path. I2P destinations are immutable public keys, so DNS semantics map poorly. |
| “Subscriptions rely on specific servers.” | Subscriptions are decentralised—you can add multiple providers or run your own. Completely decentralised systems struggle with conflict resolution and hijacking. |
| “Jump services and hosts.txt feel awkward.” | They are pragmatic trade-offs. Jump services provide just-in-time lookups; subscriptions keep a local cache for performance. |
Efficiency Ideas Discussed
- Serve incremental updates (only destinations added since the last fetch).
- Offer supplemental feeds (
recenthosts.cgi) alongside full hosts files. - Explore scriptable tooling (for example,
i2host.i2p) to merge feeds or filter by trust levels.
Takeaways
- Security wins over global consensus: locally curated address books minimise hijacking risk.
- Multiple naming approaches can coexist through the naming API—users decide what to trust.
- Completely decentralised global naming remains an open research problem; trade-offs among security, human memorability, and global uniqueness still mirror Zooko’s triangle.