来源: https://ipshipyard.com/blog/2026-the-end-of-ipfs-at-shipyard/
我们有一些艰难的消息要与 IPFS 和更广泛的点对点社区分享。
Protocol Labs 已通知我们，将不再续签对 Shipyard 的资助。我们非常感谢他们在过去两年多里给予的支持和信任，但对这一结果自然感到失望。因此，Shipyard 将逐步停止与 IPFS 相关的工程、维护和基础设施运营。我们所有与 IPFS 相关的工作将于 2026 年 9 月 30 日结束。
过去三年，我们很荣幸能够参与塑造现代 IPFS 生态系统，并为用户提供更具弹性和自主性的技术。我们将在未来几天发布一篇后续文章，详细介绍我们所做的这些意义深远的工作，以下是一些亮点：
- 通过 inbrowser.link 直接在浏览器中提供可验证的网站和下载内容。
- 重新设计 IPFS 网关基础设施，以处理大约 3 倍的流量，同时将运营和维护成本降低约 80%。
- 与传统的基于 libp2p 的托管相比，采用 HTTP 原生方式推进 IPFS，从而显著降低部署、开发和运营成本。
- 维护和改进 IPFS 生态系统每天依赖的许多核心实现、库和公共基础设施。
我们原本满怀热情地准备开启 IPFS 的下一个篇章：大幅简化的 HTTP 原生实现、弹性且可持续的内容路由、对大型原生 SHA-256 对象的支持、通过 Tor 和洋葱服务实现的匿名托管和检索，以及其他许多我们认为能够显著简化 IPFS 部署的理念。遗憾的是，我们无缘亲眼见证这些努力的实现。
其实际影响远不止于造船厂。其中包括：
- 由 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 生态系统处于最佳状态，以应对未来的任何挑战。
我们将持续提供服务至九月底，协助您完成过渡。如果您负责维护软件、运营基础设施，或依赖Shipyard之前负责的任何工作，请随时与我们联系。我们将尽一切合理努力解答疑问、提供相关信息，并尽力确保过渡尽可能顺利。
如果您对在 Shipyard 工作期间的经历有任何美好的回忆，或者您一直希望 IPFS 最终能够实现某个想法，我们都非常乐意倾听。Google表单
最后，我们要说声谢谢。
感谢所有贡献代码、审查拉取请求、提交问题、测试实验性功能、运行基础设施、参与标准讨论，或者仅仅是相信内容应该根据其本质而不是其所在位置来对待的人。
能够与这个社群共同发展，我深感荣幸。虽然IPFS在造船厂的这段篇章即将落下帷幕，但我们依然为我们共同取得的成就感到自豪，并希望我们所做的工作能够为未来的发展奠定坚实的基础。