星际船坞更新报告
今年早些时候，我们推出了星际船坞，作为领导libp2p开源开发和最流行IPFS实现、工具和基础设施的维护者的演进。在我们的介绍中，我们分享了我们的路线图和愿景，其中一个关键部分是让IPFS在Web上工作。在这篇博客文章中，我们将分享自那时以来我们取得的所有进展以及我们为未来计划的内容。
Web上的IPFS
自IPFS存在以来，一个关键目标就是让在Web上使用IPFS成为可能。也就是说，在Web上实现弹性、去中心化和经过验证的数据检索。但是IPFS在Web上工作意味着什么？
弹性：即使某些提供者离线，浏览器中仍可检索数据。 去中心化：您可以从浏览器连接到其他对等节点进行内容路由和检索，同时免受审查和破坏网络的阻塞点的影响。 已验证：您在本地验证数据，确保完整性而不假设信任（即无需信任）。
数据指的是任何可以由CID寻址的内容：文件、目录、Web应用/dapp、视频等。
虽然Web平台拥有最广泛的影响力，但由于平台的固有约束和浏览器之间的差异，它也是让IPFS工作最具挑战性的平台。
像ipfs.io这样的网关是一把双刃剑，因为它们使IPFS内容可被Web访问，但也突显了IPFS在Web上的挑战。公共网关最初被设想为在网络引导阶段的临时支撑，直到更去中心化和弹性的解决方案到位，但它们却 entrenched 成为在Web上访问IPFS内容的默认方式，损害了IPFS的原则。
在星际船坞，我们一直在正面应对这一挑战，通过libp2p和IPFS堆栈中的多个项目，使Web上的IPFS成为现实：
- Verified Fetch
- Service Worker Gateway
- 新浏览器传输协议
- 使用libp2p.direct的AutoTLS
- 基于HTTP的IPFS
- 浏览器开发者工具
- 委托路由HTTP API
- Bitswap改进
- libp2p改进
让我们更详细地看看这些项目。
Verified Fetch
Verified Fetch是一个TypeScript库，用于我们今年早些时候发布的IPFS内容的验证检索，并构建在Helia之上。我们设计它的目的是使按CID检索IPFS内容像大多数开发人员已经熟悉的Fetch API一样简单。我们专注于通过简单的API获得无缝的开发者体验，同时抽象掉IPFS的所有复杂性：内容路由、传输和验证。
Verified Fetch非常适合在Web应用或dapp中异步加载内容寻址的静态资源或子资源，例如图像、视频或JSON。
从开发者体验的角度来看，Verified Fetch遵循以下模式：
- 将CID作为输入
- 返回一个Response对象
这个基础的API表面虽然简单，但支持广泛的检索用例，同时抽象掉了数据类型、内容路由、传输和验证的复杂性。此外，返回Response对象允许与浏览器的缓存机制轻松集成，并在Service Worker中使用。
Verified Fetch非常适合异步加载内容寻址的静态资源或"子资源"，例如图像、视频甚至IPLD编码的数据。
安装Verified Fetch
但是，从IPFS加载完整的dapp或网站呢？与静态资源不同，Web应用和网站需要一种将标准URL解析到其相应内容寻址资源的方法。这就是Service Worker Gateway的用武之地，它构建在Verified Fetch之上。
Service Worker Gateway
Service Worker Gateway是一个在浏览器中运行的Web原生IPFS网关。它在Service Worker中实现了IPFS网关规范，并直接从网络上的提供者获取IPFS内容，并在本地进行验证。
在之前的博客文章中，我们研究了Web发布如何与IPFS配合工作。这可以总结为：
- Web应用是静态的，即只是构成应用的HTML、JS、CSS、图像等文件和目录。这通常是前端框架或静态站点生成器的构建输出。
- Web应用的构建输出使用UnixFS进行编码，并由代表应用根的CID进行寻址（见下图）。
- 有IPFS节点（即提供者）拥有该CID的块。
使用Service Worker Gateway的去中心化前端
Service Worker Gateway为去中心化Web发布释放了新的可能性：
- 去中心化：通过点对点检索。
- 无需信任：通过本地验证，移除对任何给定网关或提供者的隐式信任。
- 离线使用：访问过的页面被缓存在Cache API中，为每个静态Web应用启用离线支持。
尝试Service Worker Gateway
例如，IPFS博客是静态生成的，每个版本都有不同的CID。在Fleek的帮助下，每个构建都使用UnixFS编码，获得一个CID并提供给IPFS网络。DNSLink记录也会更新到最新的发布CID。
现在，您可以使用Service Worker Gateway在blog-ipfs-tech.ipns.inbrowser.link加载博客，而不是使用受信任的网关，例如https://blog-ipfs-tech.ipns.dweb.link/。
注意：Service Worker Gateway存在一个固有的权衡：它需要预先获取和安装Service Worker的成本，该Service Worker会获取和验证数据。这就是为什么首次加载可能比使用受信任的网关慢。
关于可组合性的说明
Service Worker Gateway依赖于Verified Fetch，而Verified Fetch依赖于Helia，Helia又依赖于js-libp2p。
Service Worker Gateway：新内容
当我们开始这个项目时，我们专注于把基础做对：
- 带有自定义网关和委托路由配置的Service Worker生命周期管理。
- 根据子域名网关规范进行子域名源隔离。
- 测试基础设施以确保符合规范。
- 基本错误处理并回退到受信任的网关。
- 资源的正确缓存。
- Verified Fetch库和Service Worker Gateway之间的职责划分，以确保它们都有用而不重复功能。
- 从递归网关和HTTP网关提供者进行HTTP检索。
注意：递归网关和HTTP网关提供者之间存在细微差别。递归网关，如ipfs.io和trustless-gateway.link，当内容在本地不可用时，会从提供者那里按CID获取内容。 另一方面，HTTP网关提供者是通过IPNI发现的IPFS HTTP网关，它们只返回它们拥有的CID的块。
在过去的几个月里，我们一直在提高可靠性和用户体验。最重要的是，我们添加了在底层使用js-libp2p的直接点对点检索支持。这意味着Service Worker Gateway现在可以利用更广泛的提供者对等节点，这些节点启用了WebTransport或Secure WebSocket。这引出了下一个主题：浏览器传输协议，它们在实现Web上的IPFS和libp2p方面起着至关重要的作用。
浏览器传输协议
浏览器传输协议（协议）是Web的基础，也是Web上IPFS的致命弱点。如果您无法与其他对等节点通信，您就做不了多少事情。
浏览器使用多种传输协议通过互联网进行通信，每种协议都有其自身的优缺点。
假设Web应用处于安全上下文中，即通过HTTPS提供服务，就像大多数现代Web应用一样，以下传输协议可用：
- HTTPS：通过TLS的请求/响应HTTP。
- Secure WebSocket：通过WebSocket的安全双向流通信。
- WebRTC：最初为浏览器到浏览器的实时通信而设计，例如用于视频、音频和数据流。
- WebTransport：基于QUIC的WebSocket替代方案。
下表总结了每种传输协议的能力：
| 双向流 | 需要TLS证书和域名 | 广泛支持 | 可在Service Worker中使用 | 浏览器到浏览器 | |
|---|---|---|---|---|---|
| HTTPS | ❌ | ✅ | ✅ | ✅ | ❌ |
| Secure WebSocket | ✅ | ✅ | ✅ | ✅ | ❌ |
| WebRTC | ✅ | ❌ | ✅ | ❌ | ✅ |
| WebTransport | ✅ | ❌ | ❌ | ✅ | ❌ |
注意：虽然技术上可以通过HTTPS进行流式传输，但浏览器在请求完全发送之前不允许读取响应。更多细节请参见此问题。
HTTPS和Secure WebSockets
HTTP在浏览器和IPFS实现中得到广泛支持。也许最常见的是IPFS HTTP网关，这是一个具有HTTP语义的通用检索API，广泛用于IPFS实现、工具和基础设施。
请求/响应 vs 双向流式传输
像HTTP这样的请求/响应协议不太适合像Bitswap这样的流式协议。WebSocket（以及WebRTC和WebTransport）是双向流式协议，非常适合基于libp2p的协议，如Bitswap。
此外，WebSocket在所有现代浏览器中都得到支持，并且与Service Worker兼容。
HTTP和WebSocket的TLS证书
事情变得有点棘手的是HTTP和WebSocket的TLS，即HTTPS和Secure WebSocket，这是安全上下文和Service Worker所要求的。
HTTPS和Secure WebSocket需要CA签名的TLS证书和域名，而IPFS网络中的大多数对等节点默认没有这些。为了解决这个问题，我们一直在进行一个项目，为所有可公开拨号的IPFS节点自动颁发通配符Let’s Encrypt TLS证书。更多内容请参见下面的AutoTLS部分。
WebRTC
WebRTC是一种浏览器到浏览器的通信协议，例如用于视频、音频和数据流。在IPFS和libp2p的背景下，有两种WebRTC实现：
- WebRTC：用于浏览器到浏览器的通信。
- WebRTC-Direct：用于浏览器到服务器的通信，不需要受信任的TLS证书。
去年，libp2p中用于浏览器到浏览器通信的WebRTC规范获得批准，并包括一个利用电路继电器的去中心化SDP交换机制。
我们编写了一份详尽的指南来帮助您入门，并在IPFS Camp上举办了一个研讨会。它也被Universal Connectivity和IPFS Share使用，以展示浏览器到浏览器通信的可能性。
我们还看到生态系统蓬勃发展，有像Topology、OrbitDB和Canvas这样的项目，它们依赖js-libp2p和WebRTC作为其浏览器到浏览器通信的基础。
还值得注意的是，WebRTC是唯一具有NAT打孔机制的浏览器传输协议，这是通过网络地址转换器（NAT）在两个对等节点之间建立直接连接的过程。这是在像IPFS这样的去中心化网络中建立两个对等节点之间直接连接的关键部分。
WebRTC-Direct
WebRTC-Direct被设计为一种传输协议，允许浏览器到服务器的通信，而不需要域名和CA签名的TLS证书。
WebRTC-direct在go-libp2p v0.36.1中稳定，并在Kubo 0.30.0中默认启用。这是一个巨大的里程碑，因为这意味着浏览器可以拨号启用WebRTC-direct的公开可达的IPFS节点，而无需TLS证书或域名。
因此，我们建议升级到最新版本的Kubo以利用这一点。
浏览器中WebRTC的限制
浏览器中的WebRTC有两个注意事项：
- WebRTC在Service Worker中不可用。
- Chrome将每个窗口的WebRTC连接数限制为500，之后将阻止建立新连接。
WebTransport
两年前，IPFS和libp2p项目对WebTransport的承诺下了赌注，但这条路一直崎岖不平。WebTransport是一种有前途的协议，特别是对于libp2p和IPFS，因为它允许双向流式通信，具有许多相对于WebSocket的现代改进，而不需要CA签名的证书和域名。
这是一个改变游戏规则的因素，因为IPFS网络中的大多数对等节点没有域名。
然而，WebTransport规范仍处于草案阶段，浏览器实现存在许多错误和问题，我们一直在与浏览器供应商合作解决这些问题。因此，一旦互操作性目标发生变化，浏览器兼容性就会中断。
虽然我们仍然相信WebTransport的长期承诺，但我们已经重新调整了我们的即时优先事项，转向WebRTC-Direct（现已可用）和Secure WebSocket（参见下面的AutoTLS）。
尽管如此，我们继续与浏览器供应商和标准机构合作，使WebTransport达到稳定和可互操作的状态。
使用libp2p.direct的AutoTLS
AutoTLS是一项新功能，显著改善了浏览器（Helia, Service Worker）连接到Kubo节点的方式。
如上所述，Secure WebSocket是唯一在Service Worker中可靠工作的流式传输协议，但需要TLS证书和域名。为了克服这一点，Shipyard团队一直在进行一个项目，为可公开拨号的Kubo节点自动颁发通配符TLS证书。
这样，节点可以使用Secure WebSocket libp2p传输，而无需注册域名。我们称此服务为AutoTLS，它由libp2p.direct域名提供支持。
AutoTLS使公开可达的Kubo节点（即可从公共互联网拨号的节点）能够获得一个与其PeerID对应的通配符TLS证书，格式为*.
AutoTLS的工作原理
在底层，libp2p.direct背后的基础设施有两个角色：
- 一个ACME DNS-01挑战代理，用于获取*.[PeerID].libp2p.direct的通配符TLS证书。为此，它对请求证书的PeerID进行身份验证，验证其网络可达性，并在_acme-challenge.
.libp2p.direct设置ACME挑战的TXT DNS记录。 - *.libp2p.direct的权威DNS服务器。值得注意的是，它解析到的IP地址被编码在DNS名称中，例如1-2-3-4.
.libp2p.direct解析到IP地址为1.1.1.1的A记录。这使得DNS服务器保持无状态且操作简单，同时确保即使Kubo节点的IP地址发生变化，也无需协调即可解析。
注意：AutoTLS不是Let’s Encrypt或其他TLS证书颁发机构的替代品。它是一个补充服务，用于为您的Kubo节点的唯一PeerID获取TLS证书，而无需您自己的域名。
AutoTLS作为一项公共服务提供，由星际船坞运营，并在Kubo 0.32.1中以选择加入的方式提供。我们还在js-libp2p中添加了对AutoTLS的支持，这将允许JavaScript生态系统也能享受到AutoTLS的好处。
AutoTLS在Kubo v0.32.1或IPFS Desktop v0.40.0（包含Kubo）中可用。我们鼓励您尝试并分享您的反馈。
下载IPFS Desktop
基于HTTP的IPFS
贯穿本博客文章中许多项目的一个主题是使用HTTP作为互操作性的蓝图。这是由以下原因驱动的：
- HTTP在Web生态系统中无处不在，并且被开发人员所熟知。
- HTTP在所有现代浏览器中都得到支持，并且与Service Worker兼容。
- HTTP具有强大的缓存原语，在基础设施提供商和开源基础设施中广泛采用，为灵活的缓存打开了大门，这与内容寻址数据的不可变性质非常匹配。
更多关于此的内容，请参见IPFS Camp的最新演讲：
浏览器开发者工具
随着新的浏览器传输协议的推出，我们还开发了许多开发者工具，以使调试依赖libp2p和IPFS的Web应用变得更加容易。
历史上，在浏览器中调试IPFS和libp2p意味着启用日志记录，然后在日志中进行grep搜索。我们现在发布了一个浏览器扩展，允许您检查libp2p节点并直接从浏览器开发者工具与之交互。
那么它是如何工作的呢？浏览器扩展与您添加到js-libp2p节点的指标实现配对。然后，扩展通过RPC从节点获取指标，并在浏览器开发者工具中显示它们。这依赖于js-libp2p暴露的相同指标接口，该接口也可用于通过Prometheus监控js-libp2p（在Node.js中）。
在IPFS Camp的这次演讲中了解更多关于浏览器扩展的信息：
委托路由HTTP API
委托内容路由HTTP API允许IPFS节点使用HTTP API将内容和对等路由卸载到另一个进程/服务器。此外，它还允许使用不同的路由系统进行组合和实验。
自2022年规范批准以来，它受到了积极的接受，并逐渐在生态系统中实施和集成：
- IPFS基金会提供了一个公共委托路由端点，由someguy支持，URL为https://delegated-ipfs.dev/routing/v1，由星际船坞运营。
- cid.contact网络索引器暴露了一个兼容的/routing/v1/providers端点，用于查找CID的提供者。
- Helia同时拥有委托路由HTTP API的客户端和服务器实现。
- 客户端在Helia中默认配置了公共委托路由端点。
- js-libp2p也通过Helia客户端支持委托路由HTTP API。
- Boxo SDK附带了一个委托路由HTTP API的客户端和服务器实现，被Kubo使用。
- Kubo既使用委托路由HTTP API查询IPNI。此外，自Kubo v0.23起，您可以暴露一个委托路由端点。
委托路由HTTP API如何帮助Web上的IPFS？
分布式哈希表是IPFS的默认路由系统，用于在网络中查找对等节点和CID的提供者。然而，遍历DHT需要与网络中大约log₂(N)个对等节点建立连接，其中N是对等节点的总数。对于像IPFS这样的网络，这可能意味着仅为了找到一个提供者就需要建立与数十个对等节点的连接。
委托路由HTTP API通过显著减少直接从提供者对等节点获取内容寻址数据所需的网络连接数，来赋能像Web浏览器这样的资源受限客户端。换句话说，您可以通过使用HTTP API将路由卸载到另一个进程/服务器来将连接数减少到1，例如使用位于https://delegated-ipfs.dev/routing/v1的公共物品端点。
引入提供者和对等记录的过滤
在许多情况下，委托路由HTTP API返回的大多数结果对客户端不可操作，因为客户端不支持网络传输协议（例如TCP）或传输协议（例如GraphSync）。
IPIP-484引入了对提供者和对等记录的过滤，允许更高效的路由。
对于浏览器，IPIP-484减少了API返回的不可操作结果的开销。对于Kubo来说，这意味着建立连接到仅支持GraphSync的对等节点的负载更少。此外，它通过查询参数中的过滤器使手动调试更加容易。
IPIP-484已经在Boxo SDK、someguy、Helia、Kubo和Rainbow中实现。
Bitswap改进
Bitswap是IPFS网络中最普遍的数据传输协议。我们代表IPFS基金会运营公共IPFS网关的经验使我们有机会大规模测量和优化Bitswap。
基于来自公共IPFS网关的跟踪和指标，我们已识别并发布了许多对Boxo中Bitswap的Go实现的性能改进，该实现被Kubo和Rainbow使用。
Libp2p改进
Libp2p是上述大多数项目的依赖项，并且是整个IPFS堆栈的基石。除了前面提到的传输协议工作之外，我们还在进行许多libp2p的改进和规范制定，以支持上述项目。
查看js-libp2p路线图了解更多细节。
AutoNAT v2
AutoNAT v2是AutoNAT协议的新版本，为节点提供更精确的可达性信息。它在确定节点的可达性方面提供了更高的粒度，例如，AutoNAT v2允许我们确定所有(ipv4/ipv6, tcp/udp)组合的可达性。
AutoNAT v2在go-libp2p中实现，并在Kubo v0.30.0中开始向公共群组推出。
虽然与Web上的IPFS没有直接关系，但AutoNAT v2改进了非浏览器IPFS节点的网络层，这是IPFS网络基础设施的关键部分。
NAT打孔
在go-libp2p中实施了许多NAT打孔的修复和改进，这应有助于提高位于NAT后面的IPFS节点的连接性。
注意：浏览器中的NAT打孔与QUIC和TCP中的NAT打孔不同。浏览器使用带有STUN服务器的ICE进行WebRTC NAT穿越，而非浏览器libp2p对等节点使用Circuit Relay v2和DCUtR。
js-libp2p Amino DHT引导程序
js-libp2p Amino DHT引导程序是一个新的Amino DHT引导程序，类似于go-libp2p和rust-libp2p中的引导程序，但在js-libp2p中实现。除了拥有另一个作为公共物品的引导程序的明显好处外，它还允许我们通过高流量对js-libp2p进行压力测试。
通过使用Prometheus进行监控，我们能够发现并解决几个js-libp2p包中的许多错误。
该引导程序支持TCP和Secure WebSocket，可以在/dnsaddr/va1.bootstrap.libp2p.io/p2p/12D3KooWKnDdG3iXw9eTFijk3EWSunZcFi54Zka4wmtqtt6rPxc8连接。
基于HTTP的libp2p
基于HTTP的libp2p定义了libp2p对等节点如何通过HTTP使用和暴露libp2p协议。这样做的好处是允许更多种类的节点参与libp2p网络，此外还提供了更多的互操作性机会。
例如，AutoTLS服务的后端暴露了一个API，该API使用基于HTTP的libp2p来验证HTTP请求中的libp2p Peer ID。
在IPFS Camp的这次演讲中了解更多信息：
WebSocket单次加密
历史上，libp2p中的Secure WebSocket涉及双重加密：
首先，使用与主机名绑定的CA签名TLS证书保护Secure WebSocket连接。 然后，在libp2p层上，使用Noise再次对连接进行身份验证和加密，以通过对libp2p Peer ID进行身份验证来防止MITM攻击。
虽然Noise对于Peer ID身份验证是必要的，但它对于加密并不是严格需要的。鉴于双重加密在资源消耗方面显然不是最优的，我们一直在进行一项优化，以引入明确选择将加密委托给TLS。
在撰写本文时，WebSocket API中的限制阻止了此功能的实现。如果获得批准并实施，此优化应减少每个Secure WebSocket连接的计算开销，这在打开许多连接时可能会累积。
下一步是什么？
在我们标记这一里程碑的同时，我们也在展望下一阶段的工作。在接下来的几个月里，我们将在以下几个领域集中精力：
- AutoTLS基础设施的生产化及其在Kubo和其他IPFS实现中的集成
- Boxo/Kubo中的HTTP检索
- 更多示例、文档和指南
- Service Worker Gateway中改进的错误处理
- 将Service Worker Gateway集成到IPFS Companion中
支持我们的工作
星际船坞是一个由经验丰富的全职维护者组成的小团队。如果您使用IPFS和libp2p，请考虑支持我们的工作。
总结
上述所有项目要么已经完成，要么接近完成。这是在libp2p和IPFS堆栈以及标准机构和浏览器供应商之间艰苦合作的结果。
在Web上实现弹性、去中心化和经过验证的IPFS检索终于成为现实。
这项工作的广度和影响力只有通过IPFS和libp2p项目的开源性质才成为可能。但这也强调了资助星际船坞团队的重要性，以便我们能够继续在整个生态系统中引导这些努力。
🍎 我们很高兴看到这些项目取得成果，并迫不及待地想看到IPFS社区在它们之上构建什么。