LINUX.ORG.RU

IPFS 0.4.18

 , , ,


5

5

Состоялся релиз go-ipfs (эталонной реализации IPFS, написанной на языке Go) версии 0.4.18. Вероятно, это самый значительный релиз в недавней истории; на его подготовку ушло 3 месяца. Со времени предыдущей новости об IPFS на LOR прошло уже более четырёх лет.

IPFS (InterPlanetary File System) — это гипермедийный протокол и распределённая файловая система, созданная с использованием идей, реализованных в Git и BitTorrent, и нацеленная на то, чтобы заменить или дополнить существующий Web. IPFS похож на BitTorrent Swarm, ноды которого обмениваются объектами Git-репозитория. IPFS основан на идее адресации по содержимому — один и тот же блок данных всегда будет иметь один и тот же адрес, вне зависимости от его физического расположения. В отличие от BitTorrent, данные разбиваются на блоки по границе файла, таким образом один и тот же файл может быть переиспользован в разных каталогах без необходимости повторного выделения места на диске. В отличие от Freenet и Perfect Dark, ноды хранят только те данные, которые они явно запросили. IPFS способен интегрироваться с существующими системами разрешения имён — с классическим DNS в настоящее время, с Tor .onion, Namecoin .bit и возможно, некоторыми другими в будущем.

Особенности этого релиза:

Титульные особенности этого релиза — экспериментальная поддержка QUIC, новый алгоритм маршрутизации pubsub-сообщений, возможность подписывания pubsub-сообщений, а также переписанная команда ipfs p2p. Однако всё это лишь вершина айсберга.

QUIC

Прежде всего, со стороны сетевой подсистемы, в этом релизе представлена экспериментальная поддержка протокола QUIC. QUIC — это новый сетевой транспорт, основанный на UDP, который решает много давних проблем, связанных с применением TCP.

Для IPFS это означает (наконец-то):

  • Меньшее потребление системных ресурсов. TCP требует по файловому дескриптору на каждое соединение, в то время как QUIC (и большинство других основанных на UDP транспортов) могут разделять один файловый дескриптор между всеми соединениями. Это может позволить IPFS открывать соединения быстрее и поддерживать больше открытых соединений.
  • Ускоренное установление соединения. Когда аутентификация клиента активирована, QUIC выполняет трёхсторонее согласование подобно TCP. Однако, в отличие от TCP, этот способ согласования с самого начала обеспечивает полностью зашифрованное, аутентифицированное и мультиплексированное соединение. В теории (пока что ещё не на практике), это должно значительно снизить задержки при DHT-запросах.
  • Улучшенная работа на соединениях с потерями пакетов. При мультиплексировании некоторого числа запросов через единственное TCP-соединение, всего один потерянный пакет заставит всё соединение (и все передаваемые через него запросы) ожидать, пока этот пакет будет передан заново. Однако, в силу того, что QUIC осуществляет мультиплексирование внутри себя, потеря единичных пакетов затронет только соответствующий поток.
  • Улучшенное прохождение NAT. В двух словах: пробивание NAT значительно более простое и, во многих случаях, более надёжное с использованием UDP, нежели с TCP.

Однако всё ещё есть к чему стремиться. Хоть разработчики IPFS и поощряют пользователей попробовать его уже сейчас, развиваемый IETF протокол QUIC всё ещё находится в стадии активной разработки и будет меняться. Вы можете найти инструкции по его активации в IPFS здесь.

Pubsub

С точки зрения модели «pubsub», go-ipfs теперь поддерживает алгоритм маршрутизации «gossipsub» и подписывание сообщений.

Алгоритм маршрутизации «gossipsub» значительно более эффективен, чем текущий алгоритм «floodsub». И более того, он полностью обратно совместим — таким образом, вы можете активировать его и по-прежему взаимодействовать с нодами, которые используют алготирм «floodsub». Вы можете найти инструкции по активации «gossipsub» в go-ipfs здесь.

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

Команды

В части новых инструментов, в этом релизе представлены новая подкоманда ipfs cid, предназначенная для обработки идентификаторов содержимого (Content ID, CID), полностью переписанная команда ipfs p2p, потоковое разрешение имён, а также завершённая поддерджка inline-блоков.

Новая команда ipfs cid позволяет пользователям изучать новые CID и конвертировать их в различные форматы разных версий. Например:

# Вывести метаданные CID (с префиксом)
$ ipfs cid format -f %P QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
cidv0-protobuf-sha2-256-32

# Получить хэш sha256 в шестнадцетиричном формате из CID
$ ipfs cid format -b base16 -f '0x%D' QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
0x46d44814b9c5af141c3aaab7c05dc5e844ead5f91f12858b021eba45768b4c0e

# Сконвертировать CID v0 формата base58 в CID v1 формата base32
$ ipfs cid base32 QmT78zSuBmuS4z925WZfrqQ1qHaJ56DQaTfyMUF7F8ff5o
bafybeicg2rebjoofv4kbyovkw7af3rpiitvnl6i7ckcywaq6xjcxnc2mby


Переработанная команда ipfs p2p позволяет перенаправлять TCP-потоки через две IPFS-ноды от одного хоста к другому. Это такой ssh -L, только для IPFS. Вы можете найти документацию здесь.

Она всё ещё носит экспериментальный статус, но разработчики не ожидают особенно многих несовместимых изменений на этой стадии (весьма вероятно, что она будет стабилизирована в следующем релизе). Краткий обзор внесённых несовместимых изменений:

  • IPFS не прекращает прослушивание локальных (перенаправленных) соединений после открытия единичного соединения.
  • Вывод команды ipfs p2p stream ls теперь содержит более полезную информацию. Первый выводимый адрес — это всегда адрес инициатора соединения.
  • Команда ipfs p2p listener ls переименована в ipfs p2p ls
  • Команда ipfs p2p listener close переименована в ipfs p2p close.
  • Имена протоколов предваряются префиксом /x/, и теперь просто передаются libp2p в качестве имени обработчика. Предыдущие версии делали это незаметно для пользователя и с префиксом /p2p/. Теперь есть флаг --allow-custom-protocol, который позволяет использовать любое имя обработчика из libp2p.
  • Команды ipfs p2p listener open и ipfs p2p stream dial переименованы:
    • ipfs p2p listener open p2p-test /ip4/127.0.0.1/tcp/10101 теперь становится ipfs p2p listen /x/p2p-test /ip4/127.0.0.1/tcp/10101
    • ipfs p2p stream dial $NODE_A_PEERID p2p-test /ip4/127.0.0.1/tcp/10102 теперь ipfs p2p forward /x/p2p-test /ip4/127.0.0.1/tcp/10102 /ipfs/$NODE_A_PEERID.

Текст новости слишком объёмный, продолжение в последующих сообщениях...

>>> Официальный сайт

>>> Каталог приложений, созданных на основе IPFS

>>> Дополнение для интеграции IPFS в веб-браузеры

>>> Подробности и полный список изменений

anonymous

Проверено: Shaman007 ()

Команды (продолжение)

Теперь появился новый флаг для ipfs name resolve--stream. Когда эта команда запущена с этим флагом, она начинает возвращать результаты сразу же, как только они обнаружены в DHT и других механизмах маршрутизации. Это позволяет некоторым приложениям начинать заранее получать/отображать данные во то время, когда обнаружение всё ещё выполняется. Обратите внимание, что эта команда скорее всего вернёт много устаревших записей до того, как найдёт и отобразит актуальную. Однако она всегда отображает действительные записи (хоть и немного просроченные).

И наконец, в предыдущем релизе в go-ipfs была добавлена поддержка извлечения блоков, встроенных внутрь CID. А в этом релизе была добавлена поддержка создания таких CID. Вы можете запустить ipfs add с флагом --inline, чтобы встроить блоки, размер которых меньше или равен 32 байтам, внутрь CID вместо записи отдельного блока. Это должно значительно снизить размер файловых деревьев со многими пустыми директориями и маленькими файлами.

anonymous ()
Ответ на: Команды (продолжение) от anonymous

IPNS, Web-интерфейс, производительность

IPNS

Теперь вы можете публиковать и разрешать пути в пространствах имён, отличных от /ipns и /ipfs с использованием IPNS. Проще говоря, IPNS теперь может использоваться совместно с IPLD-путями (начинающимися с /ipld).

Web-интерфейс

Наконец-то, этот релиз включает симпатичный обновлённый web-интерфейс. Вы можете увидеть его, установив go-ipfs и открыв в браузере http://localhost:5001/webui.

Производительность

Этот релиз включает в себя некоторые значительные усовершенствования производительности, как по части использования системных ресурсов, так и по скорости. Этот раздел описывает некоторые технические детали, так что вы можете пропустить её, если вы просто интересуетесь прекрасными новыми возможностями.

Использование ресурсов

В этом релизе разработчики IPFS (a) исправили медленную утечку памяти в libp2p и (б) значительно снизили выделение памяти. Вместе они должны улучшить как потребление памяти, так и использование процессора.

Структуры данных

Для снижения нагрузки были изменены две наиболее частоиспользуемых структуры данных: CID и мультиадреса.

В первую очередь, кодировка CID теперь хранится как строка, а не декодируется в структурах (за указателями). В дополнение к большей компактности, тип Cid теперь является действительным ключом map, таким образом больше не приходится кодировать CID каждый раз при использовании его в map или set. Было выявлено, что обращения к памяти при вставке CID внутрь map или set под большой нагрузкой являлись значительным источником дополнительного выделения памяти вообще. Таким образом, это изменение должно снизить потребление памяти.

Во вторую очередь, было изменено много функций парсинга/обработки/форматирования мультиадресов, чтобы для них выделялось меньше ресурсов. Многие задачи, связанные с DHT, включают обработку мультиадресов — следовательно, это должно снизить нагрузку на процессор при интенсивном использовании DHT.

Потоки и Yamux

Потоки всегда были источником раздражения в том, что касалось использования памяти. Это было частично исправлено с представлением менеджера соединений, сохраняющим максимальное число соединений на разумном уровне, но они всё ещё остаются заметным потребителем памяти.

Этот релиз испытал два усовершенствования в этой части:

  1. . Утечка памяти в Identify была исправлена. Она вызывала медленную утечку соединений (блокировку памяти, используемую потоками соединений).
  2. Yamux-потоки теперь используют в своей основе буферный пул — автоматически сокращающийся буфер чтения. Раньше этот буфер чтения мог разрастаться до его максимального размера (в несколько мегабайт) и при том никогда не сжимался, но теперь эти буферы могут сжиматься при их опустошении.

Производительность Bitswap

Bitswap теперь упаковывает несколько маленьких блоков в одно сообщение благодаря ipfs/go-bitswap#5. Хоть это и не поможет с передачей крупных файлов (с крупными блоками), это должно помочь с передачей многих маленьких файлов.

anonymous ()
Ответ на: IPNS, Web-интерфейс, производительность от anonymous

Рефакторинг и прочее

Этот релиз испытал ещё один рефакторинг библиотеки команд, двигающейся по пятам за CoreAPI, и первым шагом была надёжная поддержка CID в формате base32.

Библиотека команд

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

CoreAPI

CoreAPI — это новый способ взаимодействия с IPFS из языка Go. Хоть он всё ещё незавершён, многие вещи, которые можно сделать через CLI или HTTP интерфейсы, теперь могут быть сделаны и через новый API.

В настоящее время существует только одна реализация, включённая в go-ipfs, но есть планы однажды перевести на неё http-api. Разработчики IPFS также присматриваются к созданию RPC-интерфейса с использованием этого API, что может способствовать улучшению производительности в некоторых случаях.

Вы можете наблюдать за изменениями в #4498.

Пути IPLD

Представлен новый тип пути, который обозначает различие между путями IPLD и IPFS (unixfs). С этого момента пути с префиксом /ipld/ будут всегда использовать обход ссылок IPLD, а те, что с /ipfs/, будут использовать (уже существующую) unixfs-подобную систему нахождения пути.

Обратите внимание, что это только начальная поддержка, и скорее всего найдутся некоторые баги в том, как пути обрабатываются внутренне, так что рассматривайте эту особенность как экспериментальную на данный момент.

anonymous ()
Ответ на: Рефакторинг и прочее от anonymous

Миграция на CIDv1 и Base32 (последняя часть)

В настоящий момент, IPFS обычно используется в браузерах при помощи открытия адресов вида https://адрес_шлюза/ipfs/CID/.... В таком подходе есть два значительных недостатка:

  1. С позиции браузерной безопасности, все IPFS-«сайты» происходят из одного и того же Origin (того самого шлюза).
  2. С поциции пользовательского опыта, это не выглядит таким уж «нативным» (даже если шлюз — это локальная IPFS-нода).

Для исправления проблемы с безопасностью, разработчики IPFS намереваются изменить указывающие на IPFS-шлюз ссылки вида https://ipfs.io/ipfs/CID на https://CID.ipfs.dweb.link. Таким образом, CID будут частью Origin, что позволит каждому IPFS-вебсайту получить отдельный security origin.

Для исправления проблемы с пользовательским опытом, разработчики IPFS трудятся над добавлением поддержки адресов вида ipfs://CID/... в веб-браузеры при помощи браузерного аддона IPFS Companion и некоторых новых, экспериментальных API от Mozilla. Этот подход обладает таким же эффектом, как и помещение CID в URL, но также помогает адресу выглядеть нативно.

К несчастью, Origins обязаны быть регистронезависимыми. В настоящий момент большинство из находящхся в употреблении CID — это CIDv0 (те, которые начинаются на Qm), которые всегда закодированы в base58, из-за чего они являются регистрозависимыми.

К счастью, CIDv1 (самый свежий формат CID) поддерживают произвольные базовые алфавиты благодаря применению стандарта multibase. К несчастью, IPFS всегда обрабатывает эквивалентные CIDv0 и CIDv1 как различные. Это означает, что файлы, добавленные с использованием CIDv0 (опция по умолчанию) не могут быть найдены с использованием эквивалентного CIDv1.

В этом релизе зафиксирован значительный прогресс в направлении разрешения этой проблемы при помощи представления двух особенностей:

  1. Упомянутая ранее команда ipfs cid base32, предназначенная для конвертации CID в регистронезависимую кодировку, которая необходима для доменных имён. Эта команда конвертирует произвольный CID в формат версии 1 и кодирует его с применением base32.
  2. Грубое временное решение, позволяющее локально обращаться к блокам, ассоциированным с CIDv0 с использованием эквивалентного CIDv1 (или наоборот). Это решение однажды будет заменено на индексированное по мультихэшу хранилище блоков, которому будет безразлична как версия CID, так и тип содержимого.
anonymous ()

Абсолютно нужно. Хорошая новость, отличный релиз.

commagray ★★★★★ ()

а можно её под закон яровой адаптировать?

Thero ★★★★★ ()

Это получается как торренты, только без трекера?

goingUp ★★★★★ ()

На самом деле, идея очень торт. Но пока не все ещё - осознают это.

th3m3 ★★★★★ ()
Ответ на: комментарий от th3m3

Да торт идей вон полно вокруг. Главное, чтоб была ещё торт реализация, а с этим везде проблема.

yvv ★★☆ ()
Ответ на: комментарий от th3m3

Да, только я так и не придумал как использовать эту штуку пока нет поддержки в браузерах. В смысле как использовать чтобы от неё была реальная выгода, а не просто чтобы было.
Помнится были разговоры что гугель подумывает впилить её в хром и ютуб, но видимо не срослось

MrClon ★★★★★ ()
Ответ на: комментарий от goingUp

Не совсем. Ну то есть, ключевые отличия IPFS от BitTorrent не только в том, что IPFS вполне хорошо обходится без трекера [=аннонсера]. Для BitTorrent, как хорошо известно, минимальной универсальной единицей файлообмена является раздача. Содержимое раздачи разбивается на блоки одинакового размера. И если в двух разных раздачах содержатся одинаковые файлы или даже блоки — пиры с этих двух раздач никак не смогут взаимодействовать друг с другом. В IPFS же (a) граница файла является границей блока данных, то есть при стандартном использовании не может возникнуть такой ситуации, что один цельный и неделимый блок содержит в себе части двух или более файлов, и (б) блоки и файлы могут быть многократно переиспользованы в других файлах и «раздачах» (впрочем, применительно к IPFS будет правильнее называть их «директориями»).

Проще говоря, если в IPFS сначала скачать «раздачу» (то есть директорию) A с файлами X и Y, а потом директорию B с файлами X, Y и Z — докачивать придётся только те блоки, из которых состоит файл Z. Остальные будут прозрачно извлечены из локального кэша. Ну или если скачивать одну из этих директорий с той ноды, в кэше которой нет ни X, ни Y, ни Z — она сможет получать файлы X и Y со всех нод, у которых в кэше есть директория A или B. Как-то так.

anonymous ()
Ответ на: комментарий от th3m3

идея очень торт. Но пока не все ещё - осознают это.

я не осознаю. Объясни, пожалуйста, в чём тортовость идеи, и вообще в чём идея?

Einstok_Fair ★★ ()
Ответ на: комментарий от Einstok_Fair

КЯП, основная тортовость идеи в том, чтобы адресовать файлы по контенту, а не по ip адресу. Посмотри вводные видео, они там всё хорошо разъясняют. Типа, хочешь ты прочитать третий томик Пушкина, ты кричишь в сеть, «а у кого есть третийтомик Пушкина?», и тебе кидают, на лови, и тебе пофигу где он физически находится. Это вместо того, чтоб идти в библиотеку, и просить, «а подайте мне третий томик Пушкина с полки номер X, ряд Y».

yvv ★★☆ ()
Ответ на: комментарий от yvv

В ретрошаре тоже файлы по хешу идентифицируются, в чём разница?

Einstok_Fair ★★ ()
Ответ на: комментарий от Einstok_Fair

Я понятия не имею, в чём разница. Эта идея, вроде бы как, задолго до IPFS мусолилась, но как-то воз и ныне там. Очередная попытканепытка?

yvv ★★☆ ()
Ответ на: комментарий от MrClon

Нативной поддержки в браузерах пока что нет, но в Firefox или Chromium можно установить аддон IPFS Companion, о котором написано в новости (да, да, не все осилили, можно понять), который умеет перенаправлять IPFS-ссылки различного типа на локальную ноду и не только.

Ну а что касается видеохостингов, использующих IPFS, то таких уже существует как минимум два: DTube и BitTube. Правда, у первого регистрация намертво завязана на Steemit, в котором в свою очередь ещё надо умудриться зарегистрироваться, а у второго какие-то странности с WebUI... но по крайней мере вторые странности выглядят более разрешимыми, чем первые.

anonymous ()
Ответ на: комментарий от anonymous

Я пытался на DTube смотреть видики, но ни одного ниасилил. Ну очень всё медленно. И контент в основном - полное говно.

yvv ★★☆ ()
Ответ на: комментарий от Einstok_Fair

В том, что Retroshare задумана как сеть F2F, а IPFS — как глобальная файлообменная сеть. Нет необходимости персонально доверять кому бы то ни было, если мы берём книгу в публичной библиотеке, раздачу с торрент-трекера или директорию из IPFS.

А чтобы обмениваться файлами с теми, кому мы доверяем (или с теми, кому доверяют те, кому мы доверяем), нужны, ну... те, кому мы доверяем, не так ли?

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

anonymous ()
Ответ на: комментарий от anonymous

но в Firefox или Chromium можно установить аддон

Осталось похачить всех посетителей моего сайта и установить им этот аддон, а за одно и локальную ноду (:
Я ведь не просто так сделал оговорку про «использовать чтобы от неё была реальная выгода, а не просто чтобы было»

MrClon ★★★★★ ()
Ответ на: комментарий от anonymous

глобальная файлообменная сеть

Интернет тоже задумывали как глобальную обменную сеть.
Я просто не понимаю, какие такие преимущества убедят простых людей использовать IPFS (это ведь надо устанавливать и настраивать, а главное УЧИТЬСЯ, что сложно и противно)

Einstok_Fair ★★ ()
Последнее исправление: Einstok_Fair (всего исправлений: 1)
Ответ на: комментарий от yvv

А вот здесь как раз схожесть с BitTorrent самая прямая: чем больше нод на раздаче, тем быстрее она скачивается. Ну и ещё может быть, что скорость была слишком медленной из-за особенностей TCP, которые как раз пытаются обойти в этом релизе с введением экспериментального QUIC-транспорта.

А если говорить о, кхм, качестве видео... Есть смутное подозрение, что у BitTube с этим как минимум в долгосрочной перспективе будет лучше. По меньшей мере благодаря открытой регистрации.

anonymous ()
Ответ на: комментарий от MrClon

Всех и сразу вовсе необязательно! IPFS предусматривает возможность плавного перехода. И лучше, ну... всё-таки переводить добровольно :3

Если сайт полностью статический (то есть не требует никаких серверных скриптов в реальном времени), то можно сделать так, чтобы с помощью одного и того же DNS-адреса этот сайт мог загружаться как через IPFS (у тех, кто установит локальную ноду и аддон), так и через HTTP (у всех остальных). Для этого можно поэкспериментировать с DNSLink, взяв за отправную точку вот этот пример. Если же сайт динамический, то экспериментировать можно с раздачей через IPFS статических ресурсов — например стилей, скриптов и картинок. Установившие ноду и аддон опять же смогут загружать их через неё, а все остальные — как и раньше, через HTTP. И чем больше будет пользователей с локальной нодой, тем более надёжным будет персональный распределённый CDN у такого сайта.

anonymous ()
Ответ на: комментарий от yvv

Только для того чтоб попросить файл тебе нужен файл...

demrnd ()
Ответ на: комментарий от Einstok_Fair

Задумывали, задумывали, да не вызадумали. В блоге Neocities (хостинга статических сайтов, добавившего поддержку IPFS) об этом в том числе упомянуто.

Я просто не понимаю, какие такие преимущества убедят простых людей использовать BitTorrent (это ведь надо устанавливать и настраивать, а главное УЧИТЬСЯ, что сложно и противно)... https://ipfs.io/ipfs/QmQZz5C7zRsEUF8tmUutmtCYxqwhsELdx6AownbF3kxWgq/unbelieva...

anonymous ()
Ответ на: комментарий от vasya_pupkin

На Rust пока ничего не видно, но что-то такое намечается на C! https://github.com/Agorise/c-ipfs

P.S. При постинге на LOR очень забавно решать тот вариант капчи Google, в котором нужно выбрать все картинки, на которых изображены велосипеды.

anonymous ()

созданная с использованием идей, реализованных в Git и BitTorrent

Ещё бы и эффективного delta checksum из rsync!

gag ★★★★★ ()
Ответ на: комментарий от anonymous

И чем больше будет пользователей с локальной нодой…

Да да да, это всё я знаю. Вот только чтобы начать получать хотя бы теоретический профит нужно чтобы пользователей с локальной нодой среди посетителей сайта было хотя бы два. Одного я могу обеспечить, но откуда возьмётся второй?
Пока в популяции пользователей интернета не будет хоть сколько-то заметного процента пользователей с локальными IPFS-нодами профита от него не будет.
Надеяться приходится либо на браузеры, либо на какие-нибудь провайдерские гейты (но это будет по сути просто CDN). При чём в случае браузеров достаточно поддержки от какого-то одного более-менее крупного игрока

Кстати о гейтах и CDN. Публичные гейты это по сути тот-же бесплатный CDN в плане проблем с безопасностью: это MitM который ты сам прикручиваешь к своему сайту. Он может шпионить за пользователями, может модифицировать передаваемые ресурсы (например подсовывая в js какую-нибудь ересь, если ты вдруг зачем то решишь раздавать js через ipfs)

MrClon ★★★★★ ()
Ответ на: комментарий от anonymous

А можно не решать капчу постоянно, а решить её один раз и зарегистрироваться...

hobbit ★★★★★ ()
Ответ на: комментарий от MrClon

например подсовывая в js какую-нибудь ересь, если ты вдруг зачем то решишь раздавать js через ipfs

Так ведь тогда хэш не сойдётся. Или клиент его не проверяет?

monk ★★★★★ ()
Ответ на: комментарий от monk

Какой клиент? Тот который браузер не поддерживающий IPFS и использующий публичный гейт не отличающийся для него от CDNа? Да, не проверяет. Почём ему знать что некоторая часть урла является хэшем?
Современные браузеры поддерживают атрибут integrity у скриптов и стилей, он вроде как решает проблему модификации этих ресурсов CDNом. Но IPFS тут ни причём

MrClon ★★★★★ ()

Вижу бессерверный протокол — лорчую.

dimgel ()

Я вот так и не понял. Оно умеет расшаривать каталог? То есть можно ли оттуда скачать расшаренную директорию сразу по одной ссылке, как это можно посредством торрентов?

Deleted ()

Когда с потребляющими уйму энергии датацентрами с облачными сервисами начнут бороться как сейчас с угольными ТЭЦ, вот тогда, видимо, и взлетит, хотя и сейчас многие проекты используют.

poshat ★★ ()
Ответ на: комментарий от Deleted

Умеет. Более того, можно расшарить какую-нибудь JS-программу и она будет работать (например, Riot.im).

commagray ★★★★★ ()
Ответ на: комментарий от commagray

Умеет.

А есть где-то подробности как этим пользоваться и как это работает? Я про расшарить/скачать директорию. А то везде про шаринг файлов. И можно ли из расшаренной директории скачать выборочно поддиректории или файлы.

Deleted ()
Ответ на: комментарий от Deleted

подробности как этим пользоваться

[commagray@Canterlot ~]$ ipfs add -r testing/
added QmRm17bVtmavKYMddDw4UCP2tLCk65MsPmibb2ixE6wjAQ testing/1/1871486.jpeg
added QmXnu6xpdWKHAFWcDCZdqUfbTSczPKSb6PJzy8NxGZAGEJ testing/2/1885177.jpeg
added QmemrXXqU2EzGvgJ4uz45znjWM9SgTb26Y2hWbYRqM4VR6 testing/3/1885180.png
added QmdYb7inPxiUz68T9cpavCz3RtdG35SCrfhs7xnHDuo8PA testing/1
added QmQuHys88NRXHy5XKsMpL5kywYyQFtYuG9ZgZaxFBp1P6h testing/2
added QmcoZ9M3CybDPLum9MybRVcav8j3KeQMtLrdyJUr7i95R1 testing/3
added QmPF9ZcR55sJJsEoS4ee1ffjYgk3C2sXibJBBi6f2QwFVR testing
 1.54 MiB / 1.54 MiB [===========================================================================]  99.99%
[commagray@Canterlot ~]$ ipfs ls QmPF9ZcR55sJJsEoS4ee1ffjYgk3C2sXibJBBi6f2QwFVR
QmdYb7inPxiUz68T9cpavCz3RtdG35SCrfhs7xnHDuo8PA 163111  1/
QmQuHys88NRXHy5XKsMpL5kywYyQFtYuG9ZgZaxFBp1P6h 98060   2/
QmcoZ9M3CybDPLum9MybRVcav8j3KeQMtLrdyJUr7i95R1 1357969 3/

И можно ли из расшаренной директории скачать выборочно поддиректории или файлы.

https://ipfs.mle.party/ipfs/QmPF9ZcR55sJJsEoS4ee1ffjYgk3C2sXibJBBi6f2QwFVR

commagray ★★★★★ ()
Ответ на: комментарий от MrClon

Вполне может оказаться, что посетители с локальной нодой уже есть, только о них никто не знает. А даже если их пока ещё нет... Разве это так уж и невозможно — объявить посетителям о возможной будущей поддержке IPFS? Впрочем, здесь уже многое зависит от характера связи между автором и посетителями.

Кстати говоря, в IPFS Companion встроена нода js-ipfs, на которую можно переключиться при отсутствии обычной локальной. Она заметно уступает полноценной локальной ноде, но для экспериментов и поверхностного ознакомления её возможностей должно быть достаточно. Даже с одним только аддоном можно оценить то, каким будет IPFS в браузере — без необходимости сразу же устанавливать что-либо ещё. Ведь установить сначала аддон заметно проще, чем сразу и аддон, и локальную ноду, не так ли?

И на публичные гейты опираться совершенно необязательно — вместо них можно (и даже желательно) использовать собственный. Или даже не использовать. Достаточно того, чтобы раздаваемые статические материалы были доступны по адресу вида https://адрес_сайта.tld/ipfs/CID/script.js. Причём можно как реверс-проксировать запросы на https://адрес_сайта.tld/ipfs/* на гейт настоящей IPFS-ноды, так и вручную положить по соответствующему пути эти материалы. Главное, чтобы путь совпадал с действительным CID этих материалов.

И если попробовать открыть такой сайт с установленным аддоном — все запросы к путям, которые соответствуют действительным IPFS-мультиадресам (то есть начинаются на /ipfs/CID/) будут перенаправлены на локальную ноду со всеми вытекающими преимуществами. Ну а для посетителей без ноды ничего не изменится — кроме некоторых относительных путей.

anonymous ()
Ответ на: комментарий от monk

Там речь шла о том, что если добавить к своему сайту поддержку IPFS при помощи публичного шлюза (что возможно, но для чего-то за пределами примеров и экспериментов не слишком желательно), то для обычных посетителей (тех, у которых нет своей ноды) это будет означать примерно то же самое, что и раздача статики через централизованный CDN с теоретически возможными последствиями вроде описанных. У посетителей с локальной нодой эта самая нода конечно же будет проверять хэши. Но смысл ведь в том, чтобы на время переходного периода сохранить и доступ по HTTP в (почти) неизменном виде — для тех, кто ещё не присоединились к IPFS. А не опираться на серверные мощности третьей стороны.

anonymous ()
Ответ на: комментарий от commagray

Абсолютно нужно.

А я очень-очень хочу, но до сих пор так и не могу вытащить IPFS в продакшн. Оно самопроизвольно и непредсказуемо вдруг начинает страшно жрать процессор и память даже на полупустых репозиториях (на десятки/сотни мегабайт). Может месяц нормально пахать, а потом БАЦ — LA=300+, сожрано несколько гигов оперативки, CPU=300..400..500%

При чём всё это повторяется уже года полтора, на разных (очень разных) машинах в ассортименте (штук 6-7 серверов с IPFS стоит) и, естественно, разных версиях IPFS.

Вот, последний раз уже на 0.4.18 позавчера было.

KRoN73 ★★★★★ ()
Ответ на: комментарий от hobbit

И стать ещё одним очередным регистрантом? Вот ещё!

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.