IPFS-команда Shipyard сворачивает работу: финансирование от Protocol Labs прекращено

Грустно видеть, как это уходит, будучи мейнтейнером несколько лет назад.

Для тех, кому интересно, есть более устойчивые варианты (с жизнеспособным, сфокусированным бизнесом, поддерживающим проект) для p2p, а именно Iroh - https://www.iroh.computer/ , который был создан бывшими разработчиками IPFS и Protocol Labs (у меня нет отношений с командой, кроме того, что я работал с ними в свое время).

К сожалению, Protocol Labs сейчас занимается... ну, чем-то там, кроме, видимо, поддержки проектов, на которые получил VC/крипто-финансирование.

Это действительно прискорбно. Когда Cloudflare отказался от IPFS, можно было сказать, что этот следующий шаг уже был на подходе. Возможно, я предвзят, но я думаю, что когда IPFS решил потратить так много времени на «IPNS», чтобы поддерживать нестатические веб-приложения годы назад, то, что они придумали, не соответствовало потребностям. И без веб-приложений на IPFS дела никуда не шли.

Около года назад я написал IPFS-boot, который позволяет обслуживать веб-приложения на IPFS, обеспечивая также путь обновления и не нарушая хеширование контента:

https://github.com/rhodey/IPFS-boot

Но теперь, если вы хотите обслуживать безопасное веб-приложение и не использовать IPFS, я считаю, что единственный вариант — сказать пользователям установить Tailscale и размещать веб-приложение самостоятельно, а затем установить Tailscale на все устройства.

> Если у вас есть любимое воспоминание о работе с Shipyard или идея, которую вы всегда надеялись, что IPFS когда-нибудь достигнет, мы будем рады услышать ее. Google Form

Одна важная вещь, которую я хотел бы, чтобы IPFS или подобная децентрализованная веб-технология достигла, — это избавление от необходимости заполнять форму Google, чтобы рассказать людям из Shipyard, что я думаю об их поддержке IPFS.

Серьезно, меня раздражает, когда люди, которые якобы заботятся о децентрализованных или конфиденциальных технологиях, используют централизованный сервис, размещенный гигантской технологической компанией, для выполнения задачи, потому что это удобно (если у вас уже есть там аккаунт), и даже не пытаются сделать доступной децентрализованную версию. Было бы лучше, если бы они просто пригласили людей отправить им электронное письмо.

Я пытался создать несколько некриптовалютных децентрализованных приложений. Убийственной проблемой была надежная доставка в браузере. https://inbrowser.link/ был огромным скачком в полезности, но пришел слишком поздно; ipfs.js просто никогда не работал последовательно. В конце концов, единственный способ получить хороший пользовательский опыт для ваших пользователей заключался в том, чтобы вы предоставляли IPFS через HTTP-шлюз для всего контента, но тогда какой смысл — это просто децентрализационный театр.

Помню, в 2015 году концепция IPFS поразила меня; это такой запоминающийся момент, когда действительно казалось, что кто-то разработал что-то значительно отличающееся от текущих мейнстримных парадигм.

Но в итоге кажется, что это все еще был случай крутой технологии, ищущей применение, а не решения реальной проблемы.

Kubo, Helia, Boxo, Rainbow, IPFS Desktop, IPFS Companion, Someguy, Service Worker Gateway, IPFS Check, libp2p, ipfs.io, dweb.link, check.ipfs.network, delegated-ipfs.dev, Wikipedia-on-IPFS.

Это немного похоже на AWS или Azure для распространения файлов: так много всего, так запутанно. Кроме того, судя по всему, Protocol Labs владеет несколькими из этих вещей, несмотря на то, что не управляет ими?

По иронии судьбы, кажется довольно хрупкой установкой.

Тем не менее, очень грустные новости.

Есть ли у IPFS реальные пользователи? Я помню, когда они собрали 270 миллионов, и куча людей там сказочно разбогатела.

Я не могу сказать, что IPFS была плохой идеей. Взгляните на GitHub: это массивное хранилище с адресацией по содержимому, с улыбкой на лице. Были очень горячие P2P-продукты, например Tailscale. Protocol Labs был на пике во время/после ICO, но в долгосрочной перспективе (1) они не сосредоточились на какой-то конкретной аудитории и (2) производительность сети была не очень хорошей. Лично я считаю, что их ставка на DHT была неверной (я работал в этой области задолго до IPFS, кстати). Ладно, задним умом все сильны.