注意：以下是关于 I2P 命名系统背后原因的讨论，包括常见争论和可能的替代方案。请参阅命名页面 了解当前文档。
废弃的替代方案
在I2P中的命名一直是一个自项目诞生以来就经常被讨论的话题，支持者们对各种可能性都有不同观点。然而，考虑到I2P对安全通信和去中心化运行的内在需求，传统的DNS式命名系统显然不适用，“多数决定"的投票系统也是如此。
不过，I2P 并不提倡使用类似 DNS 的服务，因为劫持网站造成的损害可能是巨大的——而不安全的目标地址毫无价值。DNSsec 本身仍然依赖于注册商和证书颁发机构，而在 I2P 中，发送到目标地址的请求无法被拦截，回复也无法被伪造，因为它们都使用目标地址的公钥进行加密，而目标地址本身只是一对公钥和一个证书。另一方面，DNS 风格的系统允许查找路径上的任何域名服务器发起简单的拒绝服务和欺骗攻击。添加由某个集中式证书颁发机构签名认证响应的证书可以解决许多恶意域名服务器问题，但仍会留下重放攻击以及恶意证书颁发机构攻击的隐患。
投票式命名同样是危险的，特别是考虑到女巫攻击在匿名系统中的有效性——攻击者可以简单地创建任意数量的节点，并用每个节点进行"投票"来接管给定的名称。工作量证明方法可以用来使身份获取变得有成本，但随着网络的增长，联系所有人进行在线投票所需的负载是不现实的，或者如果不查询整个网络，可能会得到不同的答案集。
然而，与互联网一样，I2P 将命名系统的设计和运行保持在（类似IP的）通信层之外。捆绑的命名库包含一个简单的服务提供者接口，替代命名系统 可以插入其中，允许最终用户决定他们偏好的命名权衡方式。
讨论
另请参阅 Names: Decentralized, Secure, Human-Meaningful: Choose Two 。
jrandom 的评论
（改编自旧版 Syndie 中的一篇帖子，2005年11月26日）
问：如果某些主机对一个地址无法达成一致，并且某些地址可以工作而其他地址无法工作，该怎么办？谁是名称的正确来源？
答：你不能。这实际上是I2P中名称与DNS工作方式之间的关键区别——I2P中的名称是人类可读的、安全的，但不是全局唯一的。这是设计如此，也是我们对安全性需求的固有部分。
如果我能以某种方式说服你更改与某个名称关联的目标地址，我就能成功"接管"该网站，而这在任何情况下都是不可接受的。相反，我们所做的是让名称本地唯一：它们是你用来称呼网站的名称，就像你可以在浏览器书签或即时通讯客户端的好友列表中随意称呼它们一样。你称为"老板"的人可能是别人眼中的"莎莉”。
名称永远不可能既安全可读又全局唯一。
zzz 的评论
以下是 zzz 对 I2P 命名系统几个常见抱怨的评述。
- 低效性： 整个 hosts.txt 都会被下载（如果它已更改，因为 eepget 使用 etag 和 last-modified 头部）。目前大约有 400K，包含近 800 个主机。
确实如此，但在I2P的背景下这并不算大量流量，I2P本身就极其低效（floodfill数据库、巨大的加密开销和填充、garlic routing等）。如果你每12小时从某人那里下载一个hosts.txt文件，平均下来大约是10字节/秒。
与I2P中通常的情况一样，这里在匿名性和效率之间存在基本权衡。一些人认为使用etag和last-modified头是危险的，因为它暴露了你上次请求数据的时间。其他人建议只请求特定的键（类似于jump服务的做法，但以更自动化的方式），这可能会进一步牺牲匿名性。
可能的改进方案包括替换或补充地址簿（参见 i2host.i2p），或者采用简单的方式，比如订阅 http://example.i 2p/cgi-bin/recenthosts.cgi 而不是 http://example.i 2p/hosts.txt。例如，如果假设的 recenthosts.cgi 分发过去 24 小时内的所有主机信息，这可能比当前使用 last-modified 和 etag 的 hosts.txt 更高效、更匿名。
一个示例实现位于 stats.i2p 的 http://stats.i 2p/cgi-bin/newhosts.txt。此脚本返回带有时间戳的 Etag。当收到带有 If-None-Match etag 的请求时，脚本仅返回该时间戳之后的新主机，如果没有新主机则返回 304 Not Modified。通过这种方式，脚本以与地址簿兼容的方式高效地只返回订阅者不知道的主机。
因此效率低下并不是一个大问题，而且有几种方法可以在不进行根本性改变的情况下改进情况。
- 不可扩展： 40万个hosts.txt文件（使用线性搜索）目前还不算很大，我们可能可以增长10倍或100倍才会成为问题。
就网络流量而言，请参见上文。但除非你打算通过网络进行缓慢的实时密钥查询，否则你需要在本地存储整套密钥，每个密钥大约需要500字节的存储成本。
- 需要配置和"信任"： 开箱即用的地址簿仅订阅了 http://www.i2p2.i 2p/hosts.txt，这个文件很少更新，导致新用户体验不佳。
这是非常有意图的设计。jrandom希望用户能够"信任"hosts.txt提供者，正如他喜欢说的那样，“信任不是布尔值”。配置步骤试图强迫用户思考匿名网络中的信任问题。
另一个例子是，HTTP 代理中的"I2P Site Unknown"错误页面列出了一些跳转服务，但并不"推荐"任何特定的服务，由用户自行选择（或不选择）。jrandom 会说我们对列出的提供商有足够的信任来列出他们，但不足以自动从他们那里获取密钥。
我不确定这种做法会有多成功。但命名系统必须有某种信任层次结构。平等对待每个人可能会增加被劫持的风险。
- 这不是 DNS
不幸的是，通过 I2P 进行实时查询会显著降低网页浏览速度。
此外，DNS 基于有限缓存和生存时间的查找机制，而 I2P 密钥是永久性的。
当然，我们可以让它运行起来，但为什么要这样做呢？这并不合适。
- 不可靠： 它依赖于特定服务器来进行地址簿订阅。
是的，这取决于你配置的几个服务器。在I2P中，服务器和服务会来来去去。任何其他中心化系统（例如DNS根服务器）都会有同样的问题。完全去中心化的系统（每个人都是权威的）是可能的，可以通过实现"每个人都是根DNS服务器"的解决方案来实现，或者通过更简单的方法，比如一个脚本将你hosts.txt文件中的每个人都添加到你的地址簿中。
然而，倡导全威威解决方案的人们通常没有深入思考冲突和劫持问题。
- 笨拙，非实时： 这是一个由hosts.txt提供商、密钥添加网页表单提供商、跳转服务提供商、I2P站点状态报告商组成的拼凑系统。跳转服务器和订阅很麻烦，它应该像DNS一样正常工作。
参见可靠性和信任部分。
总而言之，当前的系统并没有严重损坏、效率低下或无法扩展，而那些"直接使用DNS"的提议也没有经过深思熟虑。
替代方案
I2P 源代码包含多个可插拔的命名系统，并支持配置选项以便进行命名系统实验。
- Meta - 按顺序调用两个或更多其他命名系统。默认情况下，调用 PetName 然后是 HostsTxt。
- PetName - 在 petnames.txt 文件中查找。此文件的格式与 hosts.txt 不同。
- HostsTxt - 按顺序在以下文件中查找：
- privatehosts.txt
- userhosts.txt
- hosts.txt
- AddressDB - 每个主机在 addressDb/ 目录中的单独文件中列出。
- Eepget - 从外部服务器执行 HTTP 查找请求 - 必须在 Meta 中的 HostsTxt 查找之后堆叠。这可以增强或替代跳转系统。包含内存缓存。
- Exec - 调用外部程序进行查找，允许在查找方案中进行额外实验，独立于 java。可以在 HostsTxt 之后使用或作为唯一的命名系统。包含内存缓存。
- Dummy - 用作 Base64 名称的后备，否则失败。
当前的命名系统可以通过高级配置选项 i2p.naming.impl 进行更改（需要重启）。详情请参见 core/java/src/net/i2p/client/naming。
任何新系统都应该与 HostsTxt 堆叠，或者应该实现本地存储和/或地址簿订阅功能，因为地址簿只了解 hosts.txt 文件和格式。
证书
I2P destinations 包含一个证书，但目前该证书始终为空。当证书为空时，base64 destinations 总是 516 字节，以 “AAAA” 结尾，这在地址簿合并机制中会被检查，可能在其他地方也会被检查。此外，目前没有可用的方法来生成证书或将其添加到 destination 中。因此，需要更新这些部分来实现证书功能。
证书的一个可能用途是用于工作量证明 。
另一种是让"子域名"（加引号是因为实际上并不存在这种东西，I2P 使用扁平命名系统）由二级域名的密钥进行签名。
任何证书实现都必须配备验证证书的方法。据推测，这应该在地址簿合并代码中进行。是否有支持多种证书类型或多个证书的方法？
添加一个证书来验证响应是由某个中心化证书颁发机构签名的，这将解决许多恶意域名服务器问题，但仍会留下重放攻击以及恶意证书颁发机构攻击的漏洞。