ハクソク

世界を動かす技術を、日本語で。

IPFSメンテイナーの活動終了

2026年8月25日原文(ipshipyard.com)

概要

  • Protocol Labs による Shipyardの資金提供終了 の発表
  • IPFS関連業務 の終了と 最終日 は2026年9月30日
  • 主要プロジェクトやインフラの 維持体制の変化
  • 移行支援 や質問対応は9月末まで継続
  • コミュニティへの 感謝と今後への期待

ShipyardのIPFSプロジェクト終了のお知らせ

  • Protocol Labs が Shipyardへの資金提供を更新しない 決定
  • 2年以上の協力関係 に感謝しつつも、 失望感 を表明
  • これにより、 ShipyardはIPFS関連のエンジニアリング・保守・インフラ運用 を終了
  • 最終営業日 は 2026年9月30日
  • 過去3年間 でIPFSエコシステムの発展に貢献した実績
    • inbrowser.link による検証可能なウェブサイト・ダウンロードの提供
    • IPFSゲートウェイインフラの再設計 によるトラフィック処理能力3倍・運用コスト80%削減
    • HTTPネイティブなIPFSアプローチ の推進で導入・開発・運用の簡素化
    • コア実装・ライブラリ・公共インフラの保守・改善
  • 今後実現したかった構想
    • HTTPネイティブ実装 のさらなる簡素化
    • 持続可能なコンテンツルーティング
    • 大規模SHA-256オブジェクト対応
    • Torやonionサービスによる匿名ホスティング・取得
  • これらの実現は困難 となったことを報告

今後の影響と体制変更

  • Shipyardが保守していたプロジェクト の専任メンテナ不在
    • Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check など
  • go-libp2pやjs-libp2pなど上流プロジェクトへの貢献停止
  • IPFS仕様策定・標準化・エコシステム調整活動の終了
  • 現在運用中のパブリックインフラ の運用停止
    • ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, IPFSブートストラップノード, Wikipedia-on-IPFS等のクラスタインフラ
    • インフラ・ドメインの今後はProtocol Labsが決定

今後のサポートと連絡先

  • 今後数週間でIPFSエコシステムの円滑な移行を支援
  • 2026年9月末まで移行サポート・質問対応 を継続
  • Shipyardの成果物やインフラを利用している方 は早めの連絡を推奨
  • 質問・相談・移行サポート の実施

コミュニティへの感謝

  • コード貢献・レビュー・課題報告・実験的機能のテスト・インフラ運用・標準化議論参加者 への感謝
  • 「内容に基づくアドレス指定」という理念 を信じてくれた全ての方への謝意
  • Shipyardと共に築いたIPFSの歩み に誇り
  • 今後の発展と新たなチャプターへの期待

お問い合わせ・思い出共有

  • Shipyardとの思い出やIPFSへの期待 があれば Google Form での共有を歓迎

Hackerたちの意見

ちょっと悲しいな、数年前にメンテナーやってたから。気になる人のために言っとくけど、p2pの代替案としてもっと持続可能な選択肢があるよ。具体的にはIroh - https://www.iroh.computer/ で、これは元IPFSやProtocol Labsの開発者たちが作ったものなんだ。チームとは昔一緒に働いたことがあるだけで、特に関係はないけどね。残念ながら、Protocol Labsは今…うーん、よくわからないことをやってるみたいで、どうやらVCや暗号資金を得たプロジェクトをサポートしてるだけみたい。

└

Irohは好きだけど、私の理解が正しければ、IPFSとはちょっと違う動き方をするんだよね。

└

PLは最近何をしてるの？ウェブサイトをチェックしたけど、全然わからなかった。

└

Irohを使ってるのは誰？

└

Irohは、IPFSよりもL7スコープのTailscaleに近い気がする。いいものだけど、あんまり関係ないね。

└

本物の活動のための完全無料のファイル共有サービス（例えば、GitHubやGoogle Drive）はたくさんあるけど、不正な活動は一つの製品から別の製品へと移っていくみたい。3年後には、StripeがOpenRouterを閉鎖するって話を聞くことになるかもね。

└

IPFSから生まれた一番のものは、ATプロトコルで使われているDASLかもしれないね。https://dasl.ing/

これは本当に残念だね。CloudflareがIPFSを切った時、次のステップはすでに進んでたと言えるかも。バイアスがかかってるかもしれないけど、IPFSが数年前に非静的なウェブアプリをサポートするために「IPNS」に多くの時間をかけた時、出てきたものはニーズに合ってなかったと思う。IPFS上にウェブアプリがなければ、何も進まなかったしね。約1年前に、IPFS上でウェブアプリを提供できるIPFS-bootを作ったんだ。更新パスも提供しつつ、コンテンツハッシュを壊さずにね。: https://github.com/rhodey/IPFS-boot でも今、もし安全なウェブアプリを提供したいなら、IPFSを使わない選択肢は、ユーザーにTailscaleをインストールさせて、自分でウェブアプリをホストさせることだけだと思う。そして、すべてのデバイスにTailscaleをインストールさせる必要があるし。

└

これ、IPv4とIPv6、そして採用にすごく似てると思う。コンテンツアドレス指定されないURLアドレッシングは、ほとんどのユースケースに対して「十分良い」って感じだし、BitTorrentはコンテンツを耐久的に、ある程度コンテンツアドレス指定された形で提供するのに「十分良い」よね（ファイルハッシュ、マグネットトレント、不変トレント）。IPFSのURLって必要なのかな？どうもそうは思えない、問題を探してる解決策みたいだ。IPFSゲートウェイは常に悪用や著作権請求のターゲットになるだろうし。もしリソースを安全に参照したいなら、https://developer.mozilla.org/en-US/docs/Web/Security/Defens... が利用可能で、広くサポートされてるよ。

└

IPNSはちょっとダサい感じがするのは同意だな。でも、代替のネーミングシステムも使えるよ（システムの名前解決が理解できればね）。例えば、これがIPFSコンテンツのためにpkarrアドレスを使ってる：http://www.chriswarbo.net/blog/2026-05-08-pkdnslink.html 「アップデートパス」については、GNSがそれをサポートしてるけど、実際に試してみることができなかった。GNUNetのブートストラップができないからさ :-(

└

Tailscaleって何のために必要なの？ 編集：ああ、何人かがダウンボートしたけど、誰も答えてないね。ウェブアプリを安全にするためにTailscaleを使う理由は何？

└

いや、BraveがネイティブのIPFSサポートを外した時はショックだったよ。https://github.com/brave/brave-browser/issues/37735

Hacker Newsで議論の続きを見る