ИИтог

Protocol Labs не продлит финансирование Shipyard, IPFS остаётся без сопровождения

инфраструктураРедакция ИИтогHacker News🔥69Рейтинг ИИтог69Влияние50Новизна35Релевантность65Неожиданность65Участники55Достоверность85
Protocol Labs не продлит финансирование Shipyard, IPFS остаётся без сопровождения

Shipyard, организация, которая вела инженерную, эксплуатационную и инфраструктурную работу по IPFS, объявила в своём блоге о полном сворачивании этой работы. Причина, решение компании Protocol Labs, поддерживавшей и финансировавшей Shipyard последние два с лишним года, не продлевать это финансирование. Последний день работы Shipyard над IPFS, 30 сентября 2026 года.

По собственному описанию Shipyard, за последние три года она помогала формировать современную экосистему IPFS и делать эту технологию более устойчивой и не зависящей от посредников для пользователей. Среди конкретных результатов: пересборка инфраструктуры IPFS-шлюзов, которая стала выдерживать примерно втрое больше трафика при снижении расходов на эксплуатацию и поддержку примерно на 80%; запуск inbrowser.link, сервиса для проверяемых сайтов и загрузок прямо в браузере; продвижение HTTP-совместимых реализаций IPFS, упрощающих развёртывание, разработку и эксплуатацию по сравнению с традиционным хостингом на основе протокола libp2p; поддержка основных библиотек, реализаций и публичной инфраструктуры, на которые экосистема IPFS полагается каждый день. У команды оставались и незавершённые планы, ещё более простые HTTP-совместимые реализации, более устойчивая и экономичная маршрутизация контента, нативная поддержка крупных объектов с хешем SHA-256, псевдонимный доступ через Tor и onion-сервисы, но, по словам 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, bootstrap-узлы IPFS и совместную кластерную инфраструктуру, например, для проекта Wikipedia-on-IPFS. Дальнейшую судьбу этих доменов и инфраструктуры определит Protocol Labs как их владелец.

Shipyard обещает оставаться на связи до конца сентября 2026 года, чтобы помочь сопровождающим и операторам инфраструктуры с переходом, и говорит, что её цель на ближайшие недели, оставить экосистему IPFS в наилучшем возможном состоянии для того, что будет дальше. При этом пост не объясняет, почему именно Protocol Labs решила не продлевать финансирование, не называет ни одной денежной суммы, ни объёма прежнего финансирования, ни каких-либо потерь, и не указывает ни одного преемника: ни для перечисленных программных проектов, ни для публичной инфраструктуры.

Ключевые факты

  • Protocol Labs не продлит финансирование Shipyard, организации, которая больше двух лет вела инженерную и инфраструктурную работу по IPFS; последний день Shipyard над IPFS, 30 сентября 2026 года.
  • Без закреплённых сопровождающих остаются проекты Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check и другие; прекращается и вклад Shipyard в апстрим-проекты go-libp2p и js-libp2p.
  • Shipyard перестанет управлять публичной инфраструктурой, ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, bootstrap-узлами и кластерами вроде Wikipedia-on-IPFS; их дальнейшую судьбу решит владелец доменов Protocol Labs.
  • За три года работы над экосистемой IPFS Shipyard пересобрала инфраструктуру шлюзов, увеличив пропускную способность примерно втрое и снизив расходы на эксплуатацию и поддержку примерно на 80%.
  • Shipyard обещает оставаться на связи до конца сентября 2026 года, чтобы помочь с переходом, но причину отказа Protocol Labs в финансировании и преемника для проектов источник не называет.

Почему это важно

IPFS, протокол для децентрализованного хранения и обмена файлами, где данные адресуются по их содержимому, а не по расположению на конкретном сервере. Проекты вроде Kubo, Helia, Boxo и Rainbow, а также публичная инфраструктура, ipfs.io, dweb.link, bootstrap-узлы, это то, на чём держится значительная часть децентрализованных и архивных сервисов, включая такие проекты, как Wikipedia-on-IPFS. Последние три года именно Shipyard одновременно разрабатывала это программное обеспечение и эксплуатировала эту инфраструктуру. Когда основной спонсор уходит, а другая команда сопровождения не названа, критичная для экосистемы инфраструктура остаётся без штатной поддержки уже с 30 сентября 2026 года, а что будет с этими проектами дальше, пока не определено.

Кому это важно

В первую очередь, командам и продуктам, которые используют Kubo, Helia, Boxo, Rainbow или другие перечисленные Shipyard проекты, а также тем, кто полагается на публичные шлюзы ipfs.io и dweb.link как на часть своей инфраструктуры, хостинга файлов, децентрализованных сайтов и архивных инициатив. Также, участникам разработки апстрим-проектов go-libp2p и js-libp2p, в которые Shipyard больше не будет вносить вклад. И самой Protocol Labs: как владелец доменов и инфраструктуры, которую эксплуатировала Shipyard, компания теперь должна сама решить, что делать со шлюзами, bootstrap-узлами и кластерами вроде Wikipedia-on-IPFS.

Как это применить

Если продукт или инфраструктура зависят от Kubo, Helia, Boxo, Rainbow, Service Worker Gateway или других проектов из списка Shipyard, стоит заранее оценить, насколько критичны для вас обновления и исправления в этих библиотеках, и составить план на случай, если после 30 сентября 2026 года новых релизов не будет. Если инфраструктура опирается на публичные шлюзы ipfs.io и dweb.link или на bootstrap-узлы, которые сейчас эксплуатирует Shipyard, имеет смысл присмотреться к альтернативам (собственный шлюз, другой публичный оператор) на случай перебоев после передачи инфраструктуры Protocol Labs. Shipyard прямо пишет, что готова отвечать на вопросы и помогать с переходом до конца сентября 2026 года, обратиться к ней стоит заранее, а не ждать отключения.

Можно ли доверять

Источник, официальный блог самой Shipyard, то есть основные факты (кто, что и когда) исходят от первого лица и, скорее всего, точны: организация сама объявляет об остановке собственной работы, ей незачем преувеличивать масштаб проблемы. При этом пост не объясняет, почему именно Protocol Labs решила не продлевать финансирование, не приводит ни одной денежной суммы, ни объёма прежнего финансирования, ни каких-либо потерь, и не называет ни одного преемника ни для перечисленных программных проектов, ни для публичной инфраструктуры. Эти пробелы стоит держать в уме до появления независимых подтверждений или отдельного заявления самой Protocol Labs.

Риски и подводные камни

Главный риск, перерыв в сопровождении критичной инфраструктуры: если Protocol Labs не найдёт новую команду или оператора до 30 сентября 2026 года или вскоре после этой даты, публичные шлюзы ipfs.io и dweb.link и bootstrap-узлы могут начать деградировать или отключаться, а проекты вроде Kubo и Helia, копить неисправленные ошибки и уязвимости без штатных сопровождающих. Второй риск, системный: этот случай показывает, что даже инфраструктура, в теории независимая от единой точки отказа, на практике может держаться на финансировании одной компании, и его прекращение способно застать экосистему так же врасплох, как отключение сервера застало бы клиентов централизованного провайдера.