作者： fiatjaf https://fiatjaf.com/d5031e5b.html
IPFS的破损设计 #
2020-01-20
我曾经上过这个关于 “内容-地址 “的当。它听起来非常好。你知道某个文件的存在，你知道可能有人拥有它，但你不知道它在哪里，或者它是否被托管在某个域名上。有了内容寻址，你可以只说 “开始”，下载就开始了。你不需要关心。 其他解决常见难题的神奇属性：网页不会下线，链接不会中断，有价值的内容总能找到它，其他人会为你分发你的网站，任何内容都可以很容易地传送给你附近的人，任何人都不必依赖第三方集中式服务器。 但你知道吗？说一件事是好的并不自动使它成为可能和有效运转。例如：说东西是由他们的内容来解决的，并不能改变互联网是 “location-addressed”的事实，你仍然必须知道拥有你想要的数据的peers在哪里，并与他们连接。
这方面的解决方案是什么呢？一个DHT!
DHT？ #
事实证明，DHT的激励结构很糟糕（正如你所期望的那样，没有人愿意免费持有和提供他们不关心的数据给别人），而且IPFS的经验证明，即使在像今天的IPFS这样的小网络中也是行不通的。 如果你运行过IPFS客户端，你会注意到它是多么的堵塞你的电脑。也许你不知道，如果你很有钱并有一台非常强大的电脑，但是，它仍然不适合在整个世界上运行，也不适合在网页、服务器和移动设备上运行。我想象可能有很多未优化的代码和技术债务造成了这些和其他问题，但DHT肯定是其中最大的一部分。IPFS在默认情况下可以打开多达1000个连接，并吸走你所有的带宽–而这仅仅是为了与其他DHT Peers 交换密钥。
即使你在 “客户端 “模式下限制了你的连接，你仍然会被那些不明连接所淹没–而且把IPFS节点作为客户端运行是没有意义的，这违背了让每个人托管他们所拥有的文件和内容寻址的整个目的，使网络中心化，使IPFS补创建时要取代的对立的客户端/服务器出现了。
连接？ #
因此，DHTs对于一个计划成为大的和星际的网络来说是一个致命的缺陷。但这并不是唯一的问题。 在IPFS上寻找内容是有史以来/最慢的体验，而且由于某些我不理解的原因，下载的速度更慢。即使你在另一台有你需要的内容的机器的同一局域网内，仍然需要几个小时来下载一些你用=scp=几秒钟就能完成的小文件–这是考虑到IPFS设法找到另一台机器，否则你的命令就会被卡住好几天。
现在，即使你忽略了IPFS对象应该是可寻址的内容而不是可寻址的位置，并且知道哪个peer有你想要的内容，你去那里并明确告诉IPFS直接连接peers，也许你可以得到几秒钟的（缓慢的）下载，但随后IPFS将放弃连接，下载将停止。有时–但并不总是–将peer地址添加到你的引导节点列表中是有帮助的（但注意这根本不是你应该做的事情）。
IPFS应用程序？ #
现在考虑一下IPFS的营销方式：它告诉人们在IPFS上建立 “应用程序”。它赞助在IPFS之上的 “数据库”。它基本上把自己宣传成一个这样的地方：开发者只要把他们的应用程序连接到那里，所有的用户就会自动地相互连接，数据将被保存在他们之间的某个地方，并立即可用，一切都将以点对点的方式工作。 除了它根本不是那样工作的。“libp2p”，用于连接人们的IPFS库，已经坏了，每6个月就会重写一次，但他们保留了他们美丽的登陆页面，说一切都神奇地运行着，你可以直接插入。我不是说他们应该让一切都完美，但至少他们应该对他们真正拥有的东西诚实。
它不可能与其他人连接，多年来没有js-ipfs和go-ipfs的互操作性（但他们却宣传将有python-ipfs、haskell-ipfs、whoknowswhat-ipfs），连接被切断，还有许多其他问题。
因此，基本上所有的IPFS “应用程序 “都只是想连接两个peer的应用程序，但不能手动操作，因为浏览器和IPv4/NAT网络没有提供简单的方法，WebRTC也很难，需要服务器。他们与 “内容寻址 “没有任何关系，他们不是要建立 “Merkle树的森林”，也不是要分发或存档内容，以便所有人都能访问。我不明白为什么IPFS把它的核心信息改为这个 “全栈p2p网络 “的东西，而不是基本的内容可寻址的想法。
IPNS？ #
那数据库呢？你怎么能用一个应该改变的值来 “内容寻址 “数据库？他们的方法是保存所有的值，过去的和现在的，然后用新的DHT条目来传达什么是最新的值。这就是IPNS。
显然，就在提出了内容可寻址的想法之后，IPFS的人意识到这永远无法取代正常的互联网，因为没有人会知道存在什么样的内容，或者一些内容何时被更新–他们不想与正常的互联网共存，他们想把它全部取代，因为这个目标更大胆，可以获得更多的资金，也许？
所以他们发明了IPNS，这个名称系统将位置可寻址性重新引入本应只有内容可寻址的系统。
他们是如何做到这一点的呢？还是DHTs。它起作用了吗？并非如此。它是有限的，缓慢的，比正常的内容寻址要慢得多，大多数时候它甚至在下班后都不工作。但是，尽管开发人员会告诉它还没有工作，但IPFS的营销人员会谈论它，好像它是一个东西。
归档内容？ #
我对IPFS的主要使用情况是存储我个人关心的内容，以及其他人可能也关心的内容，比如来自死掉网站的旧文章和视频，有时是在整个网站被撤下之前。 所以我就这么做了。在许多个月里，我把东西归档在IPFS上。IPFS的API和CLI并不容易追踪东西的位置。=pin=命令也无济于事，因为它只是把你钉的哈希值扔在哈希值和子哈希值的海洋中，你再也找不到你钉的东西了。 IPFS daemon有一个假的文件系统，其功能半生不熟，但允许你在树状结构中通过名称对事物进行本地定位。更新或添加新的东西非常困难，但还是可以做到的。它允许你给哈希值起名字，基本上。我甚至开始为它写一个包装器，但在经过许多星期的精心策划和分发后，我在假文件系统中的所有条目突然消失了。
尽管没有丢失任何文件，但我还是失去了一切，因为我无法在我自己的电脑中的哈希值的海洋中找到它们。经过一些挖掘和IPFS开发者的帮助，我设法恢复了一部分，但这涉及到黑客。我的东西消失的原因是假文件系统的一个错误。这个错误被修复了，但不久之后我又遇到了一个类似的（新）错误。在那之后，我甚至试图建立一个哈希存档和发现的服务，但由于上面列出的所有问题开始堆积，我最终放弃了。还有内容规范化的问题，IPFS daemon 用于通过HTTP提供默认HTML内容的代码，IPFS浏览器扩展的问题以及其他问题。
面向未来？ #
IPFS的核心宣传特点之一是它使内容面向未来。我不确定他们是否使用了这种表达方式，但基本上你有内容，你对其进行哈希计算，你将得到一个永远不会过期的地址，现在每个人都可以用同样的名字来引用同样的东西。事实上，这更好：内容被分割并在merkle-tree中的有哈希值，所以有细粒度的重复数据删除，人们可以只存储大块的文件，当一个文件要被下载时，很多人可以同时提供它，像torrents一样。
但接下来是协议的升级。IPFS使用了不同的哈希算法，不同的哈希格式，并将改变构建Merkle树的默认算法，所以基本上相同的内容现在有大量可能的名称/地址，这违背了整个目的，而且是的，使用不同策略哈希的文件并不自动兼容。 实际上，从一开始，merkle算法就可以由每个人在每个文件的基础上进行改变（例如，你可以按章节或页面而不是按字节块来分割一个图书文件）–尽管可能没有人这么做。我知道一开始就想出完美的合希策略是不容易的，但是处理这些问题的方式让我怀疑IPFS的发起人并没有真正担心面向未来的问题，或者我们只是永远处于Beta阶段。
Ethereum？ #
这也是一个大问题。IPFS是由Ethereum的爱好者建立的。我无法读懂IPFS背后的人的想法，但我可以想象他们对激励机制的理解和以太坊的人一样差，他们倾向于类似于骗子的行为，比如为投资者获得一大笔资金，以换取他们不知道能不能实现的承诺（比如Filecoin和IPFS本身），基于半真半假的说法，在中途改变东西，因为一些高层管理人员决定要改变（动作快，破坏东西），用花哨的名字如 “分布式网络”。
他们把IPFS（这不是IPFS最初设计的主要内容）作为 “点对点云 “来推销，对以太坊开发者来说非常有诱惑力，就像以太坊本身一样：作为一个为你运行你的代码的地方，这样你就不必托管服务器或承担任何责任，然后Infura将向所有人提供内容。同样，Infura这几天也在为以太坊开发者免费托管和提供IPFS内容。具有讽刺意味的是，就像以太坊骗局一样，随着它越来越中心化，IPFS点对点网络可能开始对终端用户更好地工作。
IPFS的问题。太多的不可更改性 #
有了描述每块内容的索引或数据库，内容寻址就无法使用。由于IPFS是完全的内容寻址，除非你有一个非IPFS的索引或数据库，或一个动态和可更新的链接的内部协议，否则什么都不能做。
IPFS的自负使他们选择了第二种方案，这被证明失败。他们甚至鼓励创建一个由IPFS驱动的数据库，这不能不说是一种误导。
2019-01-08
IPFS的问题-太多的不可改变性 #
有了描述每块内容的索引或数据库，内容寻址就无法使用。由于IPFS是完全的内容寻址，除非你有一个非IPFS的索引或数据库，或者一个动态和可更新的链接的内部协议，否则什么都不能做。
IPFS的概念使他们选择了第二种方案，这被证明败。他们甚至激励创建一个由IPFS驱动的数据库，这不能不说是一种误导。
2019-01-08
IPFS问题-混乱 #
大多数IPFS开源项目、库和应用程序（不包括Ethereum的东西）是严重依赖动态数据和临时链接的东西。在关注IPFS社区时，你会看到最常见的项目是聊天室和类似的东西。我已经见过几十个这样的聊天室了。还有一个著名的由IPFS支持的数据库。你怎么能用内容寻址来做这些事情是个迷。当然，他们可能依赖于IPNS或其他外部地址系统。
在IPFS上还有一堆的 “文件共享”。人们用来临时为第三方提供一个文件的那种东西。在IPFS上有图像共享，在IPFS上有粘贴式文件，等等。人们似乎并不认同这里对断裂链接的关注。
2019-04-28
IPFS问题-垃圾币工厂 #
IPFS从一开始就被宣传为以太坊社区 “存储 “数据的一种方式，用于他们的 “dApps”。我不认为这在任何方面是有害的，但由于某些原因，它可能导致IPFS开发人员过多地关注Ethereum的东西。有一次我看了一个讲座，显示libp2p开发者–尽管被Ethereum团队忽视了（最终创建了他们自己的不可知的p2p库）–投入了大量的工作，让一个在浏览器中运行的libp2p应用与一个正常的Ethereum节点对话。
总是有点被遗弃的 “Awesome IPFS “网站是一个大的 “dApps “库，其中一些甚至没有他们的登陆页面了，还有无用的以太坊智能合约，出于某种原因使用IPFS来存储他们的用户产生的任何无用数据。 同样，以太坊人使用IPFS本身并不是一个问题，但它至少是令人困惑的，也许是误导，当你搜索IPFS时，大多数的使用案例实际上是以太坊的无用案例。
IPFS问题- 社区 #
直到昨天，我还是一个狂热的IPFS用户。很多时候，我问一些简单的问题，而这些问题我在互联网上找不到答案，在#ipfs Freenode上的IRC频道。大多数时候我都没有得到答案，即使我得到了答案，也很少是对IPFS有深刻了解的人。我曾经在js-ipfs仓库中的问题被搁置了一年之久–其中一个问题是提高了人们对一个问题的认识，而这个问题在几个月后通过完全重写得到了修复，我在几个月后意识到这一点后关闭了自己的问题，我认为负责重写的人从未承认他修复了我的问题。 几天前，我问了一些关于IPFS协议内部如何工作的问题，真诚地想了解在IPFS上寻找和获取内容的低效率。我指出，最好能有一张图来显示，这样人们就会明白其中的困难（我没有），也不会因为速度慢而感到生气。我被告知要阅读白皮书。我已经看过白皮书了，但又读了一遍相关部分。白皮书并没有解释任何关于DHT和IPFS如何寻找内容的问题。我在房间里说了这一点，被告知要再读一遍。 在有人误读这部分内容之前，我想说，我理解如果你忙于开发具有星际意义的东西，在IRC上不断回答别人是一件很痛苦的事情，而且我没有付钱给任何人，也没有被回答的权利。另一方面，如果你正在开发一个超级重要的协议，由数百万美元资助，很多人在你的软件上撞得头破血流，却没有人帮助他们；你总是很忙，却从来没有提供给你的用户带来快乐的东西，那么事情就很不对劲了。我真诚地不知道IPFS的开发者在做什么，如果他们这么说，我不会怀疑他们在做重要的事情，但我看到的–以及许多其他用户看到的（看看IPFS Discourse论坛）是bug，到处都是bug，混乱的用户体验，几乎没有帮助。
2019-02-14
IPFS问题- 钉 #
“Pin “是IPFS团队想出的一个很好的词，用来指定告诉你的节点永久地存储一些内容，不要把它当作垃圾来收集。这个想法是，你将存储你获取的所有内容，并自动将这些内容转发给其他人，但每隔一段时间，你的节点上所有没有明确 “钉住 “的内容都将被删除，所以你不应该担心存储太多的其他人的东西，但也可以为保持你喜欢的内容而做出贡献。
然而，“钉 “有一个很大的问题：你无法知道你钉了什么。你添加的每一个钉子都会被保存在你的电脑上，你将无法取消钉子，因为你不知道什么是什么，最后你会留下一个装满钉子的磁盘，在对整个IPFS实验感到沮丧之后，你可能会失去这个磁盘，或者删除所有东西，为其他东西打开空间。
审视一下这个模型中的激励机制：我们依靠的是分享是由人们在不情愿和不知道的情况下做出的。用户在节点上花费电力，而这些节点应该是一直在运行并为他人提供内容的。只有当有人决定钉住它们时，链接才会保持不中断，但由于没有秩序，钉子注定会被到处抹去。
2019-02-14
IPFS问题-自负 #
IPFS正试图做许多事情。IPFS的领导者是革命者，他们认为自己比整个行业的其他人都要聪明。
他们首先提出了一个用于点对点分发不可改变的、有内容地址的对象的协议，后来又试图用他们自己的半生不熟的解决方案（IPNS）来解决同样的问题，这是一个例子。
其他的例子是他们以一种非常不具体的方式呼吁去中心化，他们过度的与以太坊的调情和他们永远无法完成的永远无法工作的/Filecoin/项目。
他们本可以专注于通过哈希值（不是说这实际上是一个好主意，但它有一些潜力）在点对点网络上分配对象的基础设施，但在试图重新发明整个互联网时，他们把一切都搞砸了。
2019-01-10
IPFS的问题-效率低下 #
想象一下，你有两个IPFS节点，并且在第一个节点上有由你创建的独特内容。从第二个节点，你可以连接到第一个节点，一切看起来都很正常。然后你试图获取这些内容。几秒钟后，内容开始出现，进度条开始移动，这很慢，非常慢，做rsync会快20倍。
进度条停止了。你调查了一下，第二个节点没有再连接到第一个节点。为什么，如果那是我们试图获取的文件的唯一来源？这至今仍是个谜。你手动重新连接，进度条再次移动，停止了，你又被断开了。你没有重新连接，而是决定将第二个节点添加到第一个节点的 “Bootstrap “列表中。
我曾经试图在VPS上运行一个IPFS节点，并在S3上存储内容。有两个S3数据存储插件可用。在修复了其中一个的一些问题后，重新编译go-ipfs，弄清楚如何从IPFS配置文件中读取设置，创建一个init profile并再次重新编译，我得到了节点的运行。它成功了。我的想法是在这个节点上托管一堆数据。数据将按需从S3获取，所以从任何IPFS节点或网关都可以廉价而快速地访问它。 IPFS开始每分钟对S3进行数百次调用–如果我没有在插件代码中插入一些日志语句，我是说在AWS的巨额账单到来之前，我不会知道这件事。很明显，这是参与DHT的一部分。调整一些设置后，我的节点按照我的意图变成了一个只听不看的东西，但我不是100%确定它能作为一个有效的内容提供者工作，而且我永远不会知道，因为内存和CPU使用率对我简陋的VPS来说变得太高了，我不得不把它关掉。
2019-02-14
IPFS问题-动态链接 #
内容可寻址性很酷，我们都喜欢它，但我们也都知道，我们不能生活在一个没有可读和可记的名字的世界里。IPFS从一开始就提出了IPNS，即星际名称系统（名字确实非常酷）（也许是在IPFS的第一个想法之后的几个月，这将表明这个问题是事后才想到的）。
有人说IPNS的工作方式类似于Git头和分支（这可能是Juan Benet在最初几年大量重复的营销宣传的一部分，即IPFS是Torrents、Git和其他一些很酷的技术的混合）。然而，这仍然是一个遥远的承诺。在过去的几年里，IPNS一直是一种非常缓慢的、不被他们自己的开发者所推荐的、无法使用的处理内容的方式，基本上只是一个从公钥到对象哈希的指针。 建议使用域名和dnslink，这是告诉IPFS节点你拥有一个域名的方法，可以用来识别一个对象哈希值。那是可行的，但它不是承诺的去中心化的奇迹，而且，它仍然只是一个指针。任何键值存储、文件系统的数据库都可以做指针。
在这里，我并不是说，像互联网上大量愚蠢的人那样，IPFS应该支持动态链接，这样我们就可以在上面建立网络应用。不，我只对静态内容使用静态链接就很好，而对需要动态的东西继续使用其他互联网协议。
2019-02-14
为什么IPFS不能成功，再次解释 #
2021-05-13 https://fiatjaf.com/b8e2f959.html 想象一下，有人想出了一个P2P内容地址数据共享的解决方案，这个方案将所有文件的内容存储在网络的所有计算机中。这不可能实现，是吧？太多的数据，如果你认为这可行，那么你就像一个BSV爱好者。
然后有人想出了一个主意：不把所有的东西都存储在所有的计算机上，而只把一些东西存储在一些计算机上，根据一些算法和给定的pub key来确定一个节点 上会存储什么数据。这仍然行不通，是吧？不管如何这样分散存储，数据还是太多，主要是激励措施没协调好，所以第一天就会内爆。
现在想象一下，有人说他们将做同样的事情，但不是存储全部内容，而是每个节点只存储一个指针，指向每个数据实际可用的地方。这是否使它变得更好？几乎没有。这只是在转移问题。
这就是IPFS。
现在，你在每台计算机上的数据减少了，但在全球范围内，这仍然是一个很大的数据。
没有激励措施。
而且现在你有一个寻找数据的问题。首先，如果你有一些你想让全世界都能访问的数据，你必须广播有关信息，让这个信息充斥着网络–而且每个人都必须为每一个可用的文件（或文件碎片）不断地做这件事。
然后，每当有人想要一些数据时，他们必须找到知道这些数据的人，这意味着他们将用请求充斥(flooding)整个网络，在peer之间传递，直到他们到达正确的peer。
你越是强迫每个peer存储，运行节点和代表他人存储数据的情况就越糟糕–但你越是不强迫每个peer存储，你在全球网络上flooding就越多，任何人真正得到任何文件的速度就越慢。
但是，如果每个人都只是把所有的东西都保存到Infura或Cloudflare，那么它就能运行了，真是魔幻的“去中心化”技术。