翻译：DeepL，Google Translate 校对： 李林
我曾经被这种关于 “内容寻址"的谈话所迷惑。它听起来非常好。你知道某个文件的存在，你知道可能有人拥有它，但你不知道它在哪里，或者它是否被托管在某个域名上。有了内容寻址，你可以仅仅说 “开始”，下载就开始了，不用操心。
其他能解决常见问题的神奇属性：网页不会下线，链接不会中断，总能找到有价值的内容，其他人会为你分发你的网站，任何内容都可以很容易地传送给你附近的人，任何人都不必依赖第三方集中式服务器。
但你知道吗？说一件事是好的并不自动使它变得可能和实现。例如：说东西是由他们的内容来解决的，并不能改变互联网是 “位置寻址"的事实，你仍然必须知道拥有你想要的数据的同行在哪里，并与他们连接。
这方面的解决方案是什么呢？一个DHT!
DHT?
事实证明，DHTs有糟糕的激励结构（正如你所期望的那样，没有人愿意免费持有和提供他们不关心的数据给别人），而且IPFS的经验证明，即使在像今天的IPFS这样的小网络中也是行不通的。
如果你运行过IPFS客户端，你会注意到它是多么的堵塞你的电脑。或者你不知道，如果你很有钱，有一台非常强大的电脑，但是，它仍然不适合在整个世界上运行，也不适合在网页、服务器和移动设备上运行。我想象可能有很多未优化的代码和技术债务造成了这些和其他问题，但DHT肯定是其中最大的一部分。IPFS默认可以打开1000个连接，并吸走你所有的带宽–而这只是为了与其他DHT对等体交换密钥。
即使你在 “客户端 “模式下限制了你的连接，你仍然会被那些不知道干啥的连接所淹没–而且把IPFS节点作为客户端运行是没有意义的，这违背了让每个人托管他们拥有的文件和内容可寻址性的整个目的，把网络集中化，并回到了IPFS要取代的客户端/服务器模式。
连接?
因此，对于一个计划做大做强的星际网络来说，DHT是一个致命的缺陷。但这并不是唯一的问题。
在IPFS上寻找内容是有史以来最慢的体验，而且由于一些我不理解的原因，下载就更慢了。即使你在另一台有你需要的内容的机器的同一局域网内，仍然需要几个小时来下载一些你用scp可以在几秒钟内完成的小文件–这是考虑到IPFS设法找到另一台机器，否则你的命令就会卡住好几天。
现在，即使你忽略了IPFS对象应该是可寻址的内容而不是可寻址的位置，并且知道哪个点有你想要的内容，你去那里并明确告诉IPFS直接连接到对等体，也许你可以得到几秒钟的（缓慢的）下载，但随后IPFS将放弃连接，下载将停止。有时–但不总是–将对方地址添加到你的引导节点列表中是有帮助的（但注意这根本不是你应该做的事情）。
IPFS应用程序？
现在考虑一下IPFS的营销方式：它告诉人们在IPFS上建立 “应用程序”。它在IPFS的基础上赞助 “数据库”。它基本上把自己宣传成一个地方，开发者只要把他们的应用程序连接到那里，所有的用户就会自动地相互连接，数据将被保存在他们之间的某个地方，并立即可用，一切都将以点对点的方式工作。
除了它根本不是那样工作的。“libp2p”，用于连接人们的IPFS库，已经坏了，每6个月就会重写一次，但他们保留了他们漂亮的介绍页面，说一切都神奇地工作，你可以直接用。我不是说他们应该让一切都完美，但至少他们应该对他们真正拥有的东西诚实。
它不可能与其他人连接，多年来没有js-ipfs和go-ipfs的互操作性（但他们却宣传将有python-ipfs、haskell-ipfs、whoknowswhat-ipfs），连接被中断，还有许多其他问题。
因此，基本上所有的IPFS “应用程序 “都只是想连接两个对等体的应用程序，但不能手动操作，因为浏览器和IPv4/NAT网络没有提供简单的方法，WebRTC也很难，需要服务器。他们与 “内容寻址 “没有任何关系，他们不是要建立 “Merkle树的森林”，也不是要分发或存档内容，以便所有人都能访问。我不明白为什么IPFS把它的核心信息改成了这个 “全栈p2p网络 “的东西，而不是基本的内容可寻址的想法。
IPNS?
那么数据库的事情呢？你怎么能用一个一定改变的值来 “内容地址 “数据库呢？他们的方法是保存所有的值，过去的和现在的，然后用新的DHT条目来传达什么是最新的值。这就是IPNS的事情。
显然，就在提出了内容可寻址的想法之后，IPFS的人意识到这永远无法取代正常的互联网，因为没有人会知道有什么样的内容存在，或者一些内容是什么时候更新的–他们不想与正常的互联网共存，他们想把它全部取代，因为这种信息更大胆，得到更多的资金，也许？
所以他们发明了IPNS，这个名称系统将位置可寻址性重新引入本应只有内容可寻址的系统。
他们是如何做到这一点的呢？还是DHTs。它起作用了吗？并非如此。它是有限的，缓慢的，比正常的内容寻址要慢得多，大多数时候它甚至在下班后都不工作。但是，尽管开发人员会告诉它还没有工作，但IPFS的营销人员会谈论它，好像它是一个东西。
内容归档?
我对IPFS的主要使用情况是存储我个人关心的内容，以及其他人可能也关心的内容，如来自死亡网站的旧文章和视频，有时是在整个网站被撤下之前。
所以我就这么做了。在许多个月里，我把东西归档在IPFS上。IPFS的API和CLI并不能让我很容易地追踪东西的位置。pin命令也无济于事，因为它只是把你钉的哈希值扔到了哈希值和子哈希值的海洋中，你就再也找不到你所钉的东西了。
IPFS守护进程有一个假的文件系统，其功能半生不熟，但允许你在树状结构中通过名称对事物进行本地定位。更新或添加新的东西非常困难，但还是可以做到的。它允许你给哈希值起名字，基本上。我甚至开始为它写一个包装器，但在经过许多星期的精心策划和分发后，我在假文件系统中的所有条目突然都消失了。
尽管没有丢失任何文件，但我确实失去了一切，因为我无法在我自己的电脑中的哈希值的海洋中找到它们。经过一些挖掘和IPFS开发者的帮助，我设法恢复了一部分，但这涉及到技巧。我的东西消失的原因是假文件系统的一个错误。这个错误被修复了，但不久之后我又遇到了一个类似的（新）错误。在那之后，我甚至试图建立一个哈希存档和发现的服务，但由于上面列出的所有问题开始堆积，我最终放弃了。还有内容规范化的问题，IPFS守护程序用于通过HTTP提供默认HTML内容的代码，IPFS浏览器扩展的问题以及其他问题。
适应未来的？
IPFS的一个核心宣传点是它使内容面向未来。我不确定他们是否使用了这种表达方式，但基本上你有内容，你对其进行散列，你得到一个永远不会过期的地址，现在每个人都可以用同样的名字来引用同样的东西。事实上，这更好：内容被分割并在merkle-tree中散列，所以有细粒度的重复数据删除，人们可以只存储大块的文件，当一个文件要被下载时，很多人可以同时提供它，就像torrents。
但接下来是协议的升级。IPFS用过不同的散列算法，不同的散列格式，并将改变构建Merkle树的默认算法，所以基本上相同的内容现在有大量可能的名称/地址，这违背了整个目的，而且是的，使用不同策略散列的文件并不自动兼容。
以太坊?
这也是一个大问题。IPFS是由Ethereum的爱好者建立的。我无法读懂IPFS背后的人的想法，但我可以想象他们对激励机制的理解和以太坊的人一样差，他们倾向于类似于骗子的行为，比如为投资者获取大量资金，以换取他们不知道能不能实现的承诺（比如Filecoin和IPFS本身），基于半真半假的说法，在中途改变东西，因为一些高层管理人员决定要改变（行动迅速，破坏东西），蹲守 “分布式网络 “等花哨名字。
他们将IPFS（这不是IPFS最初设计的主要内容）作为 “点对点云 “进行营销的方式对以太坊开发者非常有诱惑力，就像以太坊本身一样：作为一个地方，它将为你运行你的代码，所以你不必托管服务器或承担任何责任，然后Infura将向所有人提供内容。同样，Infura这几天也在为以太坊开发者免费托管和提供IPFS内容。具有讽刺意味的是，就像以太坊骗取点对点货币一样，随着事情越来越集中，IPFS点对点网络可能开始对终端用户更好地发挥作用。