提升 BiglyBT 对 IPFS 友好的处理方式：更好地处理作为 Webseeds 使用的 IPFS URL 2024-05-18 作者 C3P00 在当今数字内容共享的时代，文件的分布和传输方式正在快速演变。BitTorrent 和 IPFS（InterPlanetary File System）是两个强大的工具，分别在文件共享和分布式存储领域占据重要地位。然而，这两个工具之间的互操作性尚有提升空间。最近，有用户在 GitHub 上提出了一项建议，旨在改进 BiglyBT 客户端对 IPFS URL 作为 Webseeds 的处理方式，从而使其更加 IPFS 友好。这一提议不仅有助于提升文件传输效率，还能进一步推动去中心化网络的发展。 现状与问题 当前，当 BiglyBT 遇到一个公共 IPFS 网关 URL 作为 Webseed 时，它会尝试连接到该网关。然而，通过公共网关下载托管在 IPFS 上的文件，特别是大文件，效率往往不高。用户 hollownights 提出，BiglyBT 应该在检测到公共 IPFS 网关 URL 作为 Webseed 时，自动将其重写为由本地主机提供的路径格式 URL，或者如果检测到使用“ipfs:”协议的原生 IPFS URL，则将其重写为子域网关 URL。 具体而言，URL 的重写方式如下： 公共网关 URL：https://gateway-host.tld/ipfs/{cid} → http://localhost:8080/ipfs/{cid} 原生 IPFS URL：ipfs://{cidv1} → http://{cidv1}.ipfs.localhost:8080 重写后，BiglyBT 将发起请求并等待 HTTP 206（或200）响应。如果收到响应，则继续连接；如果未收到响应，则放弃本地主机 URL，回退到公共网关 URL 或直接丢弃原生 URL。 提议的改进 hollownights 还提出，这种行为可以通过与 IPFS 软件进行通信（通过命令行或 API）进一步优化，但目前以保持简单为目标。此更改结合自动将下载的文件/文件夹导入本地 IPFS 节点的选项（#2823），将显著提高去中心化 Web 协议（IPFS）与去中心化“文件协议”（BitTorrent）之间的互操作性。 此外，parg 对此提出了一些疑问：谁会使用这些 IPFS Webseeds？如果这些 Webseeds 被添加到公开发布的种子文件中，那么大多数用户不会运行本地 IPFS 节点。如果这些 Webseeds 仅限于 IPFS 社区，为什么还要使用种子文件？ hollownights 解释道，这种方法不仅仅是为了增加种子，还可以帮助像互联网档案馆这样的网站更好地将 Web 协议和 BitTorrent 结合起来。他进一步指出，如果 BitTorrent 客户端能够与本地 IPFS 节点通信，将更容易在 IPFS 网络中填充文件和节点，解决（或至少减轻）Web 问题。 实际应用 虽然 parg 认为公众大规模安装和维护 IPFS 节点的可能性不大，但 hollownights 强调这项改进主要面向已经托管种子盒和 IPFS 节点的用户。这些用户通常会发布大量文件，并希望在不同网络之间分发这些文件，同时节省带宽。对于网站而言，这意味着可以使用 IPFS 分发网站上的文件，同时通过种子文件利用用户的带宽。如果用户托管 IPFS 节点，那么这种方式将更加高效；如果没有，一切将如常进行。 通过这些改进，BiglyBT 将更好地支持 IPFS，从而推动去中心化网络的发展。这不仅有助于提高文件传输效率，还能让更多用户受益于去中心化技术的优势。 https://github.com/BiglySoftware/BiglyBT/issues/2822
在当今数字内容共享的时代，文件的分布和传输方式正在快速演变。BitTorrent 和 IPFS（InterPlanetary File System）是两个强大的工具，分别在文件共享和分布式存储领域占据重要地位。然而，这两个工具之间的互操作性尚有提升空间。最近，有用户在 GitHub 上提出了一项建议，旨在改进 BiglyBT 客户端对 IPFS URL 作为 Webseeds 的处理方式，从而使其更加 IPFS 友好。这一提议不仅有助于提升文件传输效率，还能进一步推动去中心化网络的发展。
现状与问题
当前，当 BiglyBT 遇到一个公共 IPFS 网关 URL 作为 Webseed 时，它会尝试连接到该网关。然而，通过公共网关下载托管在 IPFS 上的文件，特别是大文件，效率往往不高。用户 hollownights 提出，BiglyBT 应该在检测到公共 IPFS 网关 URL 作为 Webseed 时，自动将其重写为由本地主机提供的路径格式 URL，或者如果检测到使用“ipfs:”协议的原生 IPFS URL，则将其重写为子域网关 URL。
具体而言，URL 的重写方式如下：
重写后，BiglyBT 将发起请求并等待 HTTP 206（或200）响应。如果收到响应，则继续连接；如果未收到响应，则放弃本地主机 URL，回退到公共网关 URL 或直接丢弃原生 URL。
提议的改进
hollownights 还提出，这种行为可以通过与 IPFS 软件进行通信（通过命令行或 API）进一步优化，但目前以保持简单为目标。此更改结合自动将下载的文件/文件夹导入本地 IPFS 节点的选项（#2823），将显著提高去中心化 Web 协议（IPFS）与去中心化“文件协议”（BitTorrent）之间的互操作性。
此外，parg 对此提出了一些疑问：谁会使用这些 IPFS Webseeds？如果这些 Webseeds 被添加到公开发布的种子文件中，那么大多数用户不会运行本地 IPFS 节点。如果这些 Webseeds 仅限于 IPFS 社区，为什么还要使用种子文件？
hollownights 解释道，这种方法不仅仅是为了增加种子，还可以帮助像互联网档案馆这样的网站更好地将 Web 协议和 BitTorrent 结合起来。他进一步指出，如果 BitTorrent 客户端能够与本地 IPFS 节点通信，将更容易在 IPFS 网络中填充文件和节点，解决（或至少减轻）Web 问题。
实际应用
虽然 parg 认为公众大规模安装和维护 IPFS 节点的可能性不大，但 hollownights 强调这项改进主要面向已经托管种子盒和 IPFS 节点的用户。这些用户通常会发布大量文件，并希望在不同网络之间分发这些文件，同时节省带宽。对于网站而言，这意味着可以使用 IPFS 分发网站上的文件，同时通过种子文件利用用户的带宽。如果用户托管 IPFS 节点，那么这种方式将更加高效；如果没有，一切将如常进行。
通过这些改进，BiglyBT 将更好地支持 IPFS，从而推动去中心化网络的发展。这不仅有助于提高文件传输效率，还能让更多用户受益于去中心化技术的优势。