IPFS 维护者逐步停止

# Shipyard 项目中的 IPFS 时代终结 来源：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% 的运营维护成本 - 推进原生 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 等 - 对 go-libp2p 和 js-libp2p 等上游项目的贡献将完全停止 - IPFS 规范制定、标准推广及生态系统协调工作将全面终止 - Shipyard 将停止运营当前管理的所有公共基础设施，包括 ipfs.io、dweb.link、check.ipfs.network、delegated-ipfs.dev、IPFS 引导节点、维基百科 IPFS 协作集群等协作基础设施及相关服务。作为相关域名及基础设施的所有者，Protocol Labs 将决定其未来发展方向 未来数周内，我们将全力确保 IPFS 生态系统为后续发展奠定最佳基础。 在九月底前，我们将持续提供过渡支持。如果您负责软件维护、基础设施运营或依赖 Shipyard 的任何工作成果，请随时与我们联系。我们将尽最大努力解答疑问、提供背景信息，并协助实现平稳过渡。 如果您与 Shipyard 合作过程中有难忘回忆，或曾对 IPFS 抱有美好期许，我们期待倾听您的声音。Google 表单（https://docs.google.com/forms/d/e/1FAIpQLSdWSMRqULaZuScUrOOKpXY2me42y0bVfWpXZWluX-R98NmtEQ/viewform） 最后，请允许我们致以诚挚谢意。 感谢所有贡献代码、审阅提交、提交问题、测试实验功能、运营基础设施、参与标准讨论，或单纯坚信“内容寻址应基于内容本质而非存储位置”这一理念的伙伴们。 能与这个社区共同建设是莫大的荣幸。虽然 Shipyard 与 IPFS 的这段篇章即将落幕，但我们为共同取得的成就深感自豪，并期望这些工作能为未来的征程奠定坚实基础。