我现在在文档中找不到它，但我记得有如下解释：
IPFS 是一个文件系统，对于文件系统，您使用路径而不是 URL。 URL 可以理解为一种丑陋，它代表了在本地机器和远程机器上无法统一访问。 IPFS 通过同等对待本地和远程文件来避免这种丑陋，并且寻址文件的方法是标准路径。

想象一下将整个 IPFS 挂载在 /ipfs 下，然后像下面这样访问文件可能会有所帮助：文件系统中的文件。

lamarpavel 于 2017-02-25

附加阅读材料：

长篇讨论： https :
当前共识的简短摘要： https :

此外，正在进行的工作是将 IPFS 绝对地址与标准 URL 解析相协调，并解决使用（或不使用？） fs: paths 识别来源的问题。

lidel 于 2017-02-25

和https://github.com/ipfs/in-web-browsers/issues/28链接到草案规范。抄送@lgierth

hsanjuan 于 2017-02-25

:( 阅读 ipfs/go-ipfs#1678 之后，我什至不确定我是否对 IPFS 感兴趣 :( 。这是一个糟糕的不讨论。

我真的不想进入自行车棚，但是这个

It might help to imagine mounting the entire IPFS under /ipfs and then accessing the files like they are just that: Files in your file system.
不是一个让我兴奋的想法。我想突然之间有一个看起来像的系统根目录
/btrfs/dev/sda1/.. /fat32/dev/sda2/.. /ext3/dev/sda3/boot/..

这不是一个吸引我的概念。我习惯于按我喜欢的方式组织我的系统并根据我的选择安装我的文件系统。但这并不是真正让我失望的原因。您可以自由地将 ipfs 挂载到任何您想要的位置。我被那种狂妄自大的“让我们重新发明一切”的方法拒之门外。我来到 IPFS 是因为我想要一个分布式 CAS。这就是我感兴趣的全部。我不关心将 unix 与 web 合并。但是在阅读了该讨论之后，IPFS 似乎不再是一个可以帮助我获得分布式 CAS 的产品，它似乎是一个决定我如何使用和命名我的计算机文件系统的产品，一旦作者决定一件事，也许他们会有关于如何配置和组织我的计算机的其他一些新想法。我无法预测未来，但我不喜欢这种方法。

这太糟糕了，因为我真的很喜欢 IPFS 的分布式 CAS 实现。很长一段时间以来，我一直梦想拥有一个分布式 CAS :(。所以我必须回到研究模式，看看其他一些分布式 CAS ......

timthelion 于 2017-02-25

👍16 👎6

@timthelion我看到你（就像我一样）非常关心 CAS 和 IPFS。
我会尽我所能减轻你的担忧。

我很确定您可以将 IPFS 用作 CAS，而无需将其安装在系统的任何位置。
我对/ipfs/Qm..路径的看法是，它们只是一种简化对话和链接的心理捷径（就像常规 URL 一样）。

就我个人而言，我同意“协议处理程序”和“规范地址语义”的情况现在对于旁观者来说可能看起来一团糟，但是正在研究务实解决方案的好人现在可能会奏效（例如 https://github.com/ ipfs/in-web-browsers/issues/3，https://github.com/ipfs/in-web-browsers/issues/7）。

这是一个持续的对话，这些事情需要时间。

项目的总体方向（我个人的看法）是_“制作有用的工具，在可行的情况下重用行业标准”_而不是_“无论如何都要重新发明一切”_。

我认为你不应该担心未来。 IPFS 工具遵循_“unix 方式”_，这意味着可以将许多只做一件事的小工具、库和命令（类似于git子命令）链接在一起以构建更大的东西。

您是决定使用哪些部件的人。 ⚙️🔧

lidel 于 2017-02-25

我希望没有人以错误的方式接受我的最后一篇文章。我并不是说“你们都是我要离开的混蛋”。我想成千上万的人看过 IPFS，决定他们不喜欢某样东西，然后离开，却没有写下原因……我经常这样做。我只是随便看看一项技术，然后根据一些让我误会的小细节选择不同的技术。我决定不这样做，因为我不想成为沉默的大多数人中的沉默成员，而且，因为我没有很多其他选择：D，但看起来我将不得不等待ipfs 以支持 fs:// 或项目负责人在我开始在当前项目中使用 ipfs 之前选择的任何内容，并且我只能认真地开始查看 IPFS，直到存在一些真正的正常 URL。

timthelion 于 2017-02-25

我被狂妄自大的“让我们重新发明一切”的方法关闭。

你被冲昏了头脑，这不是“自大狂”甚至是重新发明。我们正在谈论像往常一样使用的文件路径。 /ipfs 上的挂载只是说明问题的一个例子，而不是核心思想。

lamarpavel 于 2017-02-26

我习惯于按我喜欢的方式组织我的系统并根据我的选择安装我的文件系统。

没有人强迫您将 IPFS 挂载为本地文件系统@timthelion 。这是您可以使用的功能，您可以决定它安装在哪些路径上。在我看来，不喜欢默认禁用的功能听起来像是将 IPFS 作为一个整体驳回的弱理由。但是，我希望你以后改变主意，再次加入我们。

hsanjuan 于 2017-02-26

👍1

我还没有看到每个人都喜欢每个功能的单一产品。

还值得一提的是，这实际上并没有重新发明任何东西。它是“不发明”的东西。

不管我们有什么不同的意见， fs://处理程序——它将为您提供所需的无缝支持——正如我们所说的那样正在实施，并且您已经能够将它与浏览器扩展一起使用。我们还在研究 PoC 实现，让浏览器原生使用它。您还可以在电子包装的应用程序中实现对它的支持。也许您可以为这些努力做出贡献，以使它们更快。

jbenet 于 2017-02-26

“你被冲昏了头脑，这不是‘自大狂’，甚至是重新发明。”

我将https://github.com/multiformats/multiaddr解释为狂妄自大和重新发明。它与 URL 的格式不同，但代表相同的数据。你需要一个该死的好理由来重新发明这样一个重要的标准。

我会更详细一点。

“我们谈论的是像往常一样使用的文件路径。”

我想我明白你们的想法。您试图解决不能像普通文件一样对待 Web 资源的事实是“错误”吗？像那样我不能做cat http://google.com/index.html吗？我同意你的观点，这是不可能的，这很可悲。如果我要编写一个操作系统，我会让open函数能够打开文件的 URL。也许甚至可以对 linux 做出这样的改变。您的方法不同，您尝试将 Web 资源插入 POSIX 文件层次结构。如果您认为 URL 错误有其他原因，请告知我。

我绝对可以同情您使 Web 资源像普通文件一样的目标。但是，在我看来，您解决“错误”的方法似乎很滑。如果我确实选择挂载 ipfs 文件系统，那么它们的挂载点对我来说是一种新行为。我想不出可以在我的系统上安装的任何其他用户模式程序，它会直接在我的根目录中创建多个目录。

今天，当我做ls /我得到：

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/

使用 multiaddr 提出的路径，我会看到：

$ ls / bin/ bitcoin/ boot/ dev/ dns/ dns4/ dns6/ etc/ home/ http/ https/ initrd.img@ ipfs/ lib/ lib64/ libp2p-circuit-relay/ libp2p-webrtc-direct/ libp2p-webrtc-star/ media/ mnt/ onion/ opt/ p2p/ proc/ root/ run/ sbin/ sctp/ srv/ sys/ tmp/ udt/ unix/ usr/ utp/ var/ vmlinuz@
https://github.com/multiformats/multiaddr/blob/master/protocols.csv

在你指责我误解了标准之前，我会提醒你，我是按照 unix 路径一直被解释的方式来解释它的。

显然，我不想把我的根目录弄得这么乱。因此，我将选择不安装这些路径。

就我而言，这不是我的选择，我想编写使用 IPFS 的软件，用户是否安装这些路径不是我的决定。但我仍然希望我的用户能够像打开本地计算机上的文件一样轻松地打开通过 IPFS 共享的文件。那么我该如何编写该代码呢？如果 ipfs 使用标准 url，我会简单地将任何以 ipfs:// 开头的内容转发到 ipfs，一切都会很简单。

但是当我的程序查看以/开头的字符串时，它会将其解释为某些机器上文件或目录的绝对路径，通常是运行代码的机器。如果它被告知访问以/开头的路径，那么它肯定会将其解释为本地计算机上文件或目录的绝对路径。如果我的机器上不存在/ipfs ，那么程序应该返回一个 file-not-found 错误。我想不出另一个例子，程序被告知要访问的绝对路径导致的地方不是本地机器上的文件或目录。所以对我来说，作为一个长期使用 linux 的用户/开发者，这是一种新的行为。

如果我的应用程序确实尝试添加对 multiaddr 的支持，那么事情会很快变得棘手。如果用户运行：

$tims-program-that-supports-normal-files-as-well-as-multiaddr /http/index.html
?

并且用户碰巧有一个 Web 服务器，它将其 html 文件存储在/http 。并非闻所未闻。我的程序应该将其解析为多地址还是本地文件？

我已经编写了一些基本支持在 python 中打开 URL 的代码。这样做很容易。但是我将如何更改我的代码，以便它明确地解析多地址路径和本地文件路径？

if filename.startswith( "http://" ) or filename.startswith( "https://" ): import urllib.request try: with urllib.request.urlopen(filename) as webgraph: self.json = webgraph.read().decode("utf-8") except urllib.error.URLError as e: raise OSError(str(e)) else: try: with open(filename) as fd: self.json = fd.read() except FileNotFoundError: pass

我真的不认为这是可能的。因此，我没有实现多地址支持，只支持普通 URL。起初这似乎很好，但 ipfs 的用户将不断地接触到 ipfs 对象的多地址地址，而我的程序宣传 IPFS 支持将声称这些路径不存在。所以无论我如何实施支持，我的程序都会被破坏。要么它对 ipfs 的支持将被破坏，要么它对标准 POSIX 文件系统的支持将被破坏。

有一些方法可以解决这个问题，可能。一种是完全放弃 multiaddr。另一种方法是更改 multiaddr 以使其至少将这些路径限制在单个子目录中。因此，与其写/ipfs/hash/blah不如写/webfs/ipfs/hash/blah 。 ls /会返回：

$ ls / bin/ dev/ home/ lib/ media/ opt/ root/ sbin/ sys/ usr/ vmlinuz@ boot/ etc/ initrd.img@ lib64/ mnt/ proc/ run/ srv/ tmp/ var/ webfs/

那将是我可以忍受的东西，甚至可能落后。但目前的情况是，我根本不知道实现 ipfs 支持的令人满意的方法。

让我举一个更具体的例子。想象一下，我正在编写一个将 Markdown 转换为 PDF 的程序。我希望能够支持包含来自 IPFS 的图像。所以用户写道：

阁楼.md
````

我在阁楼里发现的东西

An old box of rocks

一盒旧石头。

A can of oil for water-proofing leather

````

并运行

$ tims-md-to-pdf-with-ipfs-support attic.md > attic.pdf

我的程序应该如何解析这些图像路径？是否应该假设/ipfs文件系统已安装？我们已经同意用户不必强制挂载/ipfs 。程序是否应该将/ipfs/视为特殊前缀？这似乎很奇怪和破碎。程序是否应该只支持fs://并返回错误，在给定这些路径的情况下找不到文件？这似乎是合理的，但会使习惯于 multiaddr 标准的用户感到困惑。没有正确的出路！ :/ :(

为澄清而编辑

timthelion 于 2017-02-26

👍9

感谢您提供一些用例@timthelion。让人们提供真实世界的示例真是太好了，这样我们就可以确保协议适用于真实的人。

澄清“将所有内容安装在/”示例

正如@lidel指出的那样，人们目前正在设计地址方案，因此还没有文档。看起来@jbenet的文件系统挂载示例造成了混乱。这只是一个示例，旨在帮助人们思考fs:或dweb:地址方案背后的概念模型。他并不是建议我们强制每个人在他们的文件系统上实际挂载所有这些目录。相反，他建议我们应该能够_识别_内容，其行为就像内容安装在本地文件系统上一样，因为这将允许我们使用 unix/posix 工具与 web/dweb 内容进行交互。

当我们编写文档时，我们必须小心地说明这一点。感谢您标记它。

在回答您的“阁楼中的东西”示例时，我认为您的想法是您将在链接中使用fs:/ ，如下所示：

Stuff I found in my attic
----------------------------------

![An old box of rocks](fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV)

An old box of rocks.

![A can of oil for water-proofing leather](fs:/ipfs/QmUPC5xbVtu6NxMwFBtmWVjrVM3XffuPtSMLpmDFGfTaKG)

拥有简单的地址并统一架构

旁注：还有保持地址简单的问题。在此评论中，@nicola提出了一种聪明的方法来支持ipfs:/和ipns:/地址，而不会破坏fs: / dweb:地址方案。所涉及的协议设计体操（恕我直言）非常令人困惑，但最终它会让您在降价中拥有链接，例如ipfs:/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV ，同时还允许人们使用fs:/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV或只是/ipfs/QmdyWzsrBvSkPYPU1ScBpwzfCcegzbc6c2hkEBLLJ6VcPV在 unix/posix 上下文中。

绝对路径取决于上下文

关于绝对路径，您说：

如果它被告知访问以 / 开头的路径，那么它肯定会将其解释为本地计算机上文件或目录的绝对路径。

请记住，绝对路径相对于 _context_ 而不是相对于文件系统的根目录有很多先例。最常见的例子是 HTML 中的绝对路径，它相对于当前origin的根目录，而不是相对于服务器文件系统的根目录。如果我的代码在假设所有路径都是fs:或dweb:的上下文中运行，则该代码使用以/ipfs/开头的地址是完全有效的，并且有该代码有很多方法可以解析路径，而无需在文件系统上将 ipfs 安装在/ipfs处。

flyingzumwalt 于 2017-02-27

这些是我的 2 美分：

每个文件都在fs:/之下，就像每个域都在http:/之下。
我不会在文件系统上的/上挂载域名系统，就像我不会在/上挂载整个 IPFS 一样。在这两个系统中，参考点都是/相对于方案（ http:/ ， fs:/ ）。

我认为在您的大多数示例中，每个文件系统都在/上安装了 ipfs。所以有fs:/不会破坏 URI 格式。

nicola 于 2017-02-27

相反，他建议我们应该能够识别具有地址的内容，这些地址的行为就像内容安装在本地文件系统上一样，因为这将允许我们使用 unix/posix 工具与 web/dweb 内容进行交互。

“这将允许我们使用 unix/posix 工具与 web/dweb 内容进行交互。” 你能给我一个具体的例子，说明非fs:前缀语法将与 unix 工具一起使用吗？不知何故，我仍然没有得到它。

timthelion 于 2017-02-28

我自己试着想出一个例子，但我想不出任何符合 multiaddr 的/ipfs前缀语法的例子是有意义的。

我尝试为 bash 中的 diff 实用程序制作一个包装脚本，该实用程序使用 multiaddr 方案支持 ipfs：

````
蒂莫西@yoga ~/c/ipfs-multiaddr> cat multiaddr-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
如果 [[ $1 == /ipfs/* ]] ;
然后
file_getter="ipfs 猫 $1"
别的
file_getter="猫 $1"
菲
回声 $file_getter
}

文件1= get_multiaddr_or_normal_file_getter $1
文件2= get_multiaddr_or_normal_file_getter $2

差异 <($file1) <($file2)
````

它适用于普通文件和 ipfs 文件的幼稚情况：

````
蒂莫西@yoga ~/c/ipfs-multiaddr>
./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) 在第一天将你的第一个孩子献给上帝 Laurath
下一个偶数年的满月。
````

但是当我碰巧尝试使用它来操作我创建的/ipfs/目录中的真实现有文件时，我收到一个错误：

timothy@yoga ~/c/ipfs-multiaddr> su Password: root@yoga:/home/timothy/current/ipfs-multiaddr# mkdir /ipfs/ root@yoga:/home/timothy/current/ipfs-multiaddr# echo "foo">/ipfs/foo root@yoga:/home/timothy/current/ipfs-multiaddr# exit exit timothy@yoga ~/c/ipfs-multiaddr> ./multiaddr-diff ../subuser/COPYING.LGPL /ipfs/foo Error: selected encoding not supported ....

我不确定如何编辑该实用程序，以便它能够可靠地处理多地址和普通 unix 文件。

另一方面，创建一个仅支持 url 样式语法的 diff 包装器并不难：

````
蒂莫西@yoga ~/c/ipfs-multiaddr> cat url-syntax-diff

!/bin/bash

get_multiaddr_or_normal_file_getter(){
如果 [[ $1 == fs:* ]] ;
然后
前缀="fs:"
internal_path=${1#$prefix}
file_getter="ipfs 猫 $internal_path"
别的
file_getter="猫 $1"
菲
回声 $file_getter
}

文件1= get_multiaddr_or_normal_file_getter $1
文件2= get_multiaddr_or_normal_file_getter $2
回声 $file1
回声 $file2
差异 <($file1) <($file2)
````

它也同样有效，当哈希值已经是 1.5 个半字符长时，额外的 3 个字符肯定不会有太大的不同。

````
蒂莫西@yoga ~/c/ipfs-multiaddr>
./url-syntax-diff ../subuser/COPYING.LGPL fs:/ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
cat ../subuser/COPYING.LGPL
ipfs 猫 /ipfs/QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp
127a128,130

f) 在第一天将你的第一个孩子献给上帝 Laurath
下一个偶数年的满月。
蒂莫西@yoga ~/c/ipfs-multiaddr>
````

在奇怪的边缘情况下，它的表现令人钦佩，正如人们对精心打磨的 POSIX 实用程序所期望的那样。

````
蒂莫西@yoga ~/c/ipfs-multiaddr> echo "bar" >bar
蒂莫西@yoga ~/c/ipfs-multiaddr> ./url-syntax-diff bar /ipfs/foo
猫吧
猫 /ipfs/foo
1c1

<吧

富
````

timthelion 于 2017-02-28

❤2 😄1

由于关于 fs: 和 dweb: 的讨论似乎永无止境，我仍然需要对此 pr 的一些输入： https :

使用 ipfs：同时解决了很多问题，至少对我来说是这样。

pawal 于 2017-03-03

@pawal叹息，当我看到你的评论时，我的心沉了

平@jbenet

timthelion 于 2017-03-03

我也对您之前的帖子的回复感兴趣，因为它突出了我以前不知道的问题的观点。

//编辑：也就是说我还在关注这个问题，如果我有一个令人满意的答案，我会做出回应。

lamarpavel 于 2017-03-03

+1

使 'ipfs://' 工作 - 作为标准。请。

（所以我们所有的应用程序都可以假设它适用于所有平台，无处不在 -
任何地方，在名片上）

谢谢。

朱利安·史密斯
块货运™

jsmith-dev 于 2017-03-03

👍3

围绕ipfs: vs. fs: vs. dweb:的讨论是一个令人困惑的讨论，自从我参与这个项目之前就一直在进行。在 Web Browsers Sprint 中的 IPFS期间，我终于有时间了解它。我正在撰写对整个情况的解释，并概述了不同的选项和论点，我将在今天晚些时候作为 ipfs/specs 的 PR 提交。我将包括我所知道的讨论的示例和参考。希望这将提供一些清晰性，让我们沿着最务实的道路前进，而不会犯任何导致长期大问题的错误。

flyingzumwalt 于 2017-03-03

❤1 👍1

我已经初步尝试为这些讨论提供背景： https :

flyingzumwalt 于 2017-03-03

👍2

抱歉我的无知，但是我如何更新 PR？

timthelion 于 2017-03-04

@timthelion您可以像@jbenet一样在此处添加注释

lamarpavel 于 2017-03-04

@vasa-develop 因为您的评论实际上并没有解释软件如何改善这种情况，我认为它是垃圾邮件。

timthelion 于 2018-10-27

DID URI 怎么样？比如did:ipfs:QmSRrBvLXvYQRdQ3kZtJ5oJicKMcNQzC3CwH6bJDbEKWYp

去中心化标识符 (DID)

namedgraph 于 2018-11-02

DID 是人员的标识符。然而，在它们的核心，它们实际上是URN（我认为？）所以一个更好的问题是：“为什么不是 URN”？

确实，答案是，虽然URL为我们提供了浏览器兼容性，但路径为我们提供了文件系统兼容性（除其他外），但 URN 并没有真正给我们带来什么，除了一些标准机构的一些善意。

注意：我们实际上已经屈服于 URL 位置以获得浏览器兼容性。也就是说，IPFS 伴侣（浏览器插件）支持ipfs://...和ipns://... 。我们想使用dweb://ipfs/...等，但我们还需要适当的安全源支持（这意味着我们需要第一个组件中的哈希）。

但是，我们认为ipfs://...等价于/ipfs/...并在其他任何地方使用路径语法。

Stebalien 于 2018-11-02

@Stebalien您从哪里得到 DID 适合人们的想法？在 DID 规范中没有一次提到“人”。 URI 标识符可以根据定义识别任何资源。

你考虑什么并不重要；如果您不遵守现有标准，则无法期望现有基础设施的互操作性和支持。

namedgraph 于 2018-11-02

你从哪里知道 DID 是为人服务的？在 DID 规范中没有一次提到“人”。

DID 用于“数字身份”。

去中心化标识符 (DID) 是一种用于可验证的“自我主权”数字身份的新型标识符。

Stebalien 于 2018-11-02

所以？一切都可以有_身份_：人、动物、建筑物、组织、事物、想法、文档等。这就是 URI 的美妙之处。
你真的看过 DID 规范吗？我再说一遍，没有什么是特定于人的。

去中心化标识符 (DID): 一个全球唯一的标识符，不需要集中的注册机构，因为它是使用分布式账本技术或其他形式的去中心化网络注册的。 DID 的通用格式在本规范中定义。 DID 方法规范中定义了特定的 DID 方案。

namedgraph 于 2018-11-02

👍2

Ipfs: 为什么 ipfs 不使用真实的 URL？

最有用的评论

所有28条评论

我在阁楼里发现的东西

澄清“将所有内容安装在/”示例

拥有简单的地址并统一架构

绝对路径取决于上下文

!/bin/bash

!/bin/bash

<吧

相关问题