Protocol Labs将不再续签Shipyard的资助，导致Shipyard将于2026年9月30日停止IPFS相关工程、维护和基础设施运营。团队在过去三年中帮助塑造了现代IPFS生态系统，包括提升网关流量处理能力、降低成本并推动HTTP原生方案。

标题：IPFS在Shipyard的终结

来源：https://ipshipyard.com/blog/2026-the-end-of-ipfs-at-shipyard/

发布时间：2026-08-24

我们怀着沉重的心情向IPFS及更广泛的点对点社区宣布一个艰难的消息。

Protocol Labs已通知我们，将不再续签对Shipyard的资助。尽管我们感激过去两年多来他们给予的支持与信任，但对这一结果自然感到失望。因此，Shipyard将逐步停止与IPFS相关的工程、维护和基础设施运营。我们IPFS相关工作的最后一天将是2026年9月30日。

过去三年里，我们有幸参与塑造现代IPFS生态系统，帮助用户获得更具韧性和自主权的技术。我们将在后续文章中详细介绍已完成的重要工作，但一些亮点包括：

• 通过inbrowser.link在浏览器中直接提供可验证的网站和下载。
• 重新设计IPFS网关基础设施，处理约3倍的流量，同时将运营和维护成本降低约80%。
• 推进基于HTTP的IPFS方法，与传统基于libp2p的托管相比，大幅简化部署、开发和运营成本。
• 维护和改进IPFS生态系统日常依赖的许多核心实现、库和公共基础设施。

我们曾期待为IPFS开启新篇章：大幅简化的HTTP原生实现、韧性和可持续的内容路由、对大型原生SHA-256对象的支持、通过Tor和洋葱服务进行匿名托管和检索，以及许多我们认为能让IPFS更易采用的想法。遗憾的是，我们无法亲自完成这些努力。

实际影响远不止Shipyard本身。其中包括：

• 由Shipyard维护的项目将不再有专门的维护者负责新功能、错误修复、发布或长期管理。这些项目包括：Kubo、Helia、Boxo、Rainbow、IPFS Desktop、IPFS Companion、Someguy、Service Worker Gateway、IPFS Check等。
• Shipyard对上游项目（如go-libp2p和js-libp2p）的贡献将停止。
• 我们在IPFS规范、标准和更广泛生态系统协调方面的工作将终止。
• Shipyard将停止运营其目前管理的公共基础设施，包括ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev、IPFS引导节点、协作集群基础设施（如Wikipedia-on-IPFS）及相关服务。Protocol Labs作为相关域名和基础设施的所有者，将决定它们的未来。

我们未来几周的目标是让IPFS生态系统为接下来的发展做好最佳准备。

我们将一直工作到9月底，以协助过渡。如果您维护软件、运营基础设施或依赖Shipyard负责的任何工作，请随时联系我们。我们将尽最大努力回答问题、提供背景信息，并帮助实现尽可能平稳的过渡。

如果您有与Shipyard合作的美好回忆，或一直希望IPFS最终实现的想法，我们很乐意倾听。请通过Google表单分享。

最后，我们想说声谢谢。

感谢所有贡献代码、审查拉取请求、提交问题、测试实验功能、运营基础设施、参与标准讨论，或仅仅相信内容应基于其本质而非存储位置的人。

能与这个社区共同建设是我们的荣幸。虽然IPFS在Shipyard的这一章即将结束，但我们为共同取得的成就感到自豪，并希望我们的工作能为未来奠定坚实基础。

没有有效评论