我们有一些困难的消息要与 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 和 onion 服务提供假名托管和检索，以及我们认为会使 IPFS 更易于采用的许多其他想法。不幸的是，我们将没有机会亲自完成这些努力。实际影响远不止于 Shipyard。除其他事项外：Shipyard 维护的项目将不再拥有负责新功能、Bug 修复、发布或长期管理的专职维护者。这些项目包括：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 最终能实现的想法，我们很乐意倾听。最后，我们想说声谢谢。感谢所有贡献代码、审查拉取请求、提出问题、测试实验性功能、运营基础设施、参与标准讨论，或仅仅相信内容应该依据其本身而不是其存放位置来进行寻址的所有人：谢谢你。与这个社区一起建立是一种荣幸。尽管 Shipyard 的 IPFS 这一章节即将结束，我们仍为我们一起取得的成就感到自豪，并希望我们所做的工作能够为未来的一切提供坚实的基础。