IPFS里程碑：IPFS集成进Brave浏览器
source link: https://learnblockchain.cn/article/2040
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
IPFS集成进Brave浏览器, 可在浏览器直接支持ipfs:// ipns:// 内容的访问，本文描述背后的开发历程和实现原理。
原文由 Mitch Wagner 于 2021-01-21 发表。
编者注：在 1 月 19 日，IPFS 和 Brave 浏览器官宣了 Brave 浏览器原生继承了 IPFS协议，参见https://blog.ipfs.io/2021-01-19-ipfs-in-brave/，本文描述背后的开发历程和实现原理。
从 1.19.86版本 开始，Brave浏览器已经正式增加了 (IPFS) 的支持! 这是多年努力的结果，将这两个项目结合起来。 在本篇文章中，我们将讨论这次合作的实现过程，并从背后看看我们是如何完成这次整合的。
合作
Brave和IPFS都与其他项目和供应商有着长期的成功合作关系。 Brav e现在内置加密货币钱包，利用Tor的隐私模式，以及一个高度集成的VPN选项。 同时，IPFS还与微软（开发 去中心化身份栈 ）、Netflix（实验 通过IPFS获取Docker镜像 ）、NixOS（去中心化 源代码和构建产品 ）等名家合作。
IPFS和Brave之间的这种整合本身就是长期实验合作的产物，合作始于 2017 ，当时Brave UI还是基于Muon(Electron的一个分叉)开发的。 事实上，这个实验进行了 概念实现证明 ，明确了在Brave地址栏中解析IPFS URIs。
然而，在取得实验初步成功后不久，Brave就改用Chromium作为引擎。 虽然这在短期内是IPFS整合的一个挫折，但早期工作为最近合并这两个项目的努力奠定了基础。 这次切换也让Brave全面兼容Chromium浏览器扩展（插件），让用户可以充分利用 IPFS Companion扩展 ，同时我们也开发了原生解决方案。
在之后的两年里，Brave和IPFS背后的团队一直在继续共同致力于在浏览器内实现IPFS的全面兼容。 并制定了 新计划 ，来自两个团队和 更广泛的社区 的贡献者开始规划实现这个愿景。 在这期间，征服了浏览器源代码使得团队能够更紧密地将IPFS Companion扩展集成到Brave中：Chrome套接字API（通常不会暴露在Chrome应用中）使得在扩展中 嵌入具有真正TCP传输的js-ipfs节点 成为可能，并且 Brave更改了他们的设置菜单，包含了一个 可一键安装 的IPFS Companion。
在Brave设置菜单中一键安装IPFS Companion 。
最终，汇集了包括 Chrome套接字API 在内的各种因素，产生了获取完整的IPFS节点 推送 ，这一些都都在Brave内运行，并得到完全管理。 又经过半年的努力，我们终于实现了这一长远的目标!
架构
集成的一个关键目标是使用户尽可能无缝地使用IPFS，同时也尊重和保留他们对浏览器的控制。 当用户第一次在地址栏中输入 ipfs:// 或 ipns:// URI时，Brave会发出提示，询问用户是否愿意使用 公共IPFS网关 (默认情况下，Brave使用 "https://dweb.link"，但用户可以配置)或通过自己的本地IPFS节点(由Brave管理)。 通过IPFS Companion扩展的接口也可以启动Brave管理的本地节点。
通过支持多种配置，并在部署本地节点之前征求用户同意，Brave确保了它的行为符合浏览器作为用户代理的最初理念和愿景，存在是为用户服务，而不是相反。 选择信任谁，是否在自己的电脑上运行点对点软件，这些选择权仍然完全掌握在用户手中。 运行你自己的节点，或者将完整性验证委托给你信任的网关。
本地节点实施
如果用户希望Brave代表他们运行一个本地节点，他们只需要点击一个按钮。 一旦Brave获得权限，就会为用户的平台下载最新版本的 go-ipfs （目前最成熟的IPFS实现）。 然后Brave 将负责管理 IPFS，在后台运行go-ipfs守护进程。
Brave和go-ipfs完美地结合在一起：go-ipfs为IPFS提供HTTP互操作性，而Brave本身就是一个HTTP门户。 这就在两者之间建立了一个天然的接口，弥补了两者功能集之间的差距，大大简化了整合。 这两个项目在主要的桌面环境（Windows、macOS、Linux）都是可用的，所以让Brave作为go-ipfs的包装器，是一个无论在哪个平台都能是很好的解决方案。
在幕后，Brave将所有的IPFS数据，包括文件库，都存储在用户的Brave配置文件中。 它将在go-ipfs可用时获取更新，并在必要时迁移底层IPFS仓库。 清除浏览器缓存也会启动IPFS垃圾收集，清除任何没有 pinned 或保存在 MFS 的资源。
综上所述，这意味着在Brave内部运行节点而不是手动运行节点几乎没有任何妥协：用户可以获得目前最好的IPFS实现，以及自动更新。 尽管如此，依旧为Brave运行的节点所采取的步骤进行隔离，确保那些也希望手动运行节点的用户能够在不发生任何碰撞的情况下运行节点。
未来计划
这一整合标志着IPFS的一个重要里程碑，并为进一步实验，去改善网络浏览器与网络交互的体验奠定了基础。
特别是，在浏览器的地址栏中拥有原生的URI解决方案，开启了许多不同的研究问题。 新的概念，比如IPFS提供的内容完整性保证，应该如何向用户传达？ 我们如何向广大用户解释点对点网络的原理？ 也许最重要的是，我们如何将非传统URI意识带给用户，并帮助他们适应非 "http" 的世界？
事实上，这种研究 已经在进行 ，特别是在 移动领域 ，由于去年在 Opera for Android浏览器 中引入了IPFS。 然而，仍有大量的工作要做。 通过与Brave的整合，IPFS网络将其覆盖范围扩大到数百万潜在的参与者--来自各种背景的人。 需要新的界面和隐喻，让所有这些用户的交互变得简单、直观、易懂。
IPFS与Brave的合作也为浏览器生态系统的变革提供了进一步的动力。 这包括增加浏览器能够识别的URI和网络协议(IANA标准机构最近批准了一些URI方案，包括 ipfs和ipns )以及推动在浏览器本身引入这些协议在本地处理，而不是将该功能委托给单独的应用程序或第三方网关。
总之，此次整合为IPFS开启了全新的篇章，代表着向主流社区接受 内容寻址 网络迈出了重要的一步。 通过合作和研究，IPFS正变得越来越容易获得和使用，将分布式网络的覆盖面扩大到前所未有的程度。
https://blog.ipfs.io/2021-01-21-how-we-put-ipfs-in-brave/
原文由 Mitch Wagner 于 2021-01-21 发表。
编者注：在 1 月 19 日，IPFS 和 Brave 浏览器官宣了 Brave 浏览器原生继承了 IPFS协议，参见https://blog.ipfs.io/2021-01-19-ipfs-in-brave/，本文描述背后的开发历程和实现原理。
从 1.19.86版本 开始，Brave浏览器已经正式增加了 (IPFS) 的支持! 这是多年努力的结果，将这两个项目结合起来。 在本篇文章中，我们将讨论这次合作的实现过程，并从背后看看我们是如何完成这次整合的。
合作
Brave和IPFS都与其他项目和供应商有着长期的成功合作关系。 Brav e现在内置加密货币钱包，利用Tor的隐私模式，以及一个高度集成的VPN选项。 同时，IPFS还与微软（开发 去中心化身份栈 ）、Netflix（实验 通过IPFS获取Docker镜像 ）、NixOS（去中心化 源代码和构建产品 ）等名家合作。
IPFS和Brave之间的这种整合本身就是长期实验合作的产物，合作始于 2017 ，当时Brave UI还是基于Muon(Electron的一个分叉)开发的。 事实上，这个实验进行了 概念实现证明 ，明确了在Brave地址栏中解析IPFS URIs。
然而，在取得实验初步成功后不久，Brave就改用Chromium作为引擎。 虽然这在短期内是IPFS整合的一个挫折，但早期工作为最近合并这两个项目的努力奠定了基础。 这次切换也让Brave全面兼容Chromium浏览器扩展（插件），让用户可以充分利用 IPFS Companion扩展 ，同时我们也开发了原生解决方案。
在之后的两年里，Brave和IPFS背后的团队一直在继续共同致力于在浏览器内实现IPFS的全面兼容。 并制定了 新计划 ，来自两个团队和 更广泛的社区 的贡献者开始规划实现这个愿景。 在这期间，征服了浏览器源代码使得团队能够更紧密地将IPFS Companion扩展集成到Brave中：Chrome套接字API（通常不会暴露在Chrome应用中）使得在扩展中 嵌入具有真正TCP传输的js-ipfs节点 成为可能，并且 Brave更改了他们的设置菜单，包含了一个 可一键安装 的IPFS Companion。
在Brave设置菜单中一键安装IPFS Companion 。
最终，汇集了包括 Chrome套接字API 在内的各种因素，产生了获取完整的IPFS节点 推送 ，这一些都都在Brave内运行，并得到完全管理。 又经过半年的努力，我们终于实现了这一长远的目标!
架构
集成的一个关键目标是使用户尽可能无缝地使用IPFS，同时也尊重和保留他们对浏览器的控制。 当用户第一次在地址栏中输入 ipfs:// 或 ipns:// URI时，Brave会发出提示，询问用户是否愿意使用 公共IPFS网关 (默认情况下，Brave使用 " https://dweb.link"，但用户可以配置)或通过自己的本地IPFS节点(由Brave管理 )。 通过IPFS Companion扩展的接口也可以启动Brave管理的本地节点。
通过支持多种配置，并在部署本地节点之前征求用户同意，Brave确保了它的行为符合浏览器作为用户代理的最初理念和愿景，存在是为用户服务，而不是相反。 选择信任谁，是否在自己的电脑上运行点对点软件，这些选择权仍然完全掌握在用户手中。 运行你自己的节点，或者将完整性验证委托给你信任的网关。
本地节点实施
如果用户希望Brave代表他们运行一个本地节点，他们只需要点击一个按钮。 一旦Brave获得权限，就会为用户的平台下载最新版本的 go-ipfs （目前最成熟的IPFS实现）。 然后Brave 将负责管理 IPFS，在后台运行go-ipfs守护进程。
Brave和go-ipfs完美地结合在一起：go-ipfs为IPFS提供HTTP互操作性，而Brave本身就是一个HTTP门户。 这就在两者之间建立了一个天然的接口，弥补了两者功能集之间的差距，大大简化了整合。 这两个项目在主要的桌面环境（Windows、macOS、Linux）都是可用的，所以让Brave作为go-ipfs的包装器，是一个无论在哪个平台都能是很好的解决方案。
在幕后，Brave将所有的IPFS数据，包括文件库，都存储在用户的Brave配置文件中。 它将在go-ipfs可用时获取更新，并在必要时迁移底层IPFS仓库。 清除浏览器缓存也会启动IPFS垃圾收集，清除任何没有 pinned 或保存在 MFS 的资源。
综上所述，这意味着在Brave内部运行节点而不是手动运行节点几乎没有任何妥协：用户可以获得目前最好的IPFS实现，以及自动更新。 尽管如此，依旧为Brave运行的节点所采取的步骤进行隔离，确保那些也希望手动运行节点的用户能够在不发生任何碰撞的情况下运行节点。
未来计划
这一整合标志着IPFS的一个重要里程碑，并为进一步实验，去改善网络浏览器与网络交互的体验奠定了基础。
特别是，在浏览器的地址栏中拥有原生的URI解决方案，开启了许多不同的研究问题。 新的概念，比如IPFS提供的内容完整性保证，应该如何向用户传达？ 我们如何向广大用户解释点对点网络的原理？ 也许最重要的是，我们如何将非传统URI意识带给用户，并帮助他们适应非 "http" 的世界？
事实上，这种研究 已经在进行 ，特别是在 移动领域 ，由于去年在 Opera for Android浏览器 中引入了IPFS。 然而，仍有大量的工作要做。 通过与Brave的整合，IPFS网络将其覆盖范围扩大到数百万潜在的参与者--来自各种背景的人。 需要新的界面和隐喻，让所有这些用户的交互变得简单、直观、易懂。
IPFS与Brave的合作也为浏览器生态系统的变革提供了进一步的动力。 这包括增加浏览器能够识别的URI和网络协议(IANA标准机构最近批准了一些URI方案，包括 ipfs和ipns )以及推动在浏览器本身引入这些协议在本地处理，而不是将该功能委托给单独的应用程序或第三方网关。
总之，此次整合为IPFS开启了全新的篇章，代表着向主流社区接受 内容寻址 网络迈出了重要的一步。 通过合作和研究，IPFS正变得越来越容易获得和使用，将分布式网络的覆盖面扩大到前所未有的程度。
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。
- 发表于 2分钟前
- 阅读 ( 5 )
- 学分 ( 0 )
- 分类：IPFS
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK