Межпланетная файловая система IPFS
InterPlanetary File System — это новая децентрализованная сеть обмена файлами. Также выполняет функцию сети доставки содержимого.
Отличие от других децентрализованных сетей в том что самостоятельной единицей передаваемой в сети является блок. Блок может содержать как часть файла так и ссылки на другие блоки. Из блоков выстраивается направленный ациклический граф из которого в дальнейшем собирается файл или каталог.
Такая система позволяет более гибко подойти к хранению и передаче данных в сети. Недостатком такого подхода является то что всё что загружается в сеть режется на блоки и складывается в отдельный каталог на вашем диске.(Исправлено: «больше нет необходимости копировать в сеть») Поиск по имени файла или каталога в IPFS отсутствует также как и в сети BitTorrent.
Мультихеш
Идентификатором в этой децентрализованной сети служит обёрнутый в мультихеш sha128 от блока. Мультихеш состоит из трёх частей: ID хеш функции, размер хеша в байтах, хеш. Для хранения ID и размера используется сейчас по одному байту но значения их не может быть больше или равно 128 до тех пор пока они не определятся с форматом unsigned-varint коими они обозначены. Мультихеш в ссылках представлен в кодировке Base58 bitcoin.
Мультихеш используется с заделом на будущее что-бы сеть имела возможность перейти на новые более стойкие хеш функции.
Теперь мультихеш входит в состав идентификатора контента.
Клиент
В рабочем состоянии для сети IPFS существует мультиплатформенный клиент написанный GO. Его можно как скачать так и скомпилировать самостоятельно.
Команда ipfs daemon запускает клиент который предоставляет web интерфейс. Войти на него можно по адресу по умолчанию http://127.0.0.1:5001/webui.
Выше я говорил что самостоятельной единицей в сети является блок. Если взять со страницы http://127.0.0.1:5001/webui#objects мультихеш блока файла и добавить к нему http://127.0.0.1:8080/ipfs/ то сеть отдаст часть файла или каталога соответствующую блоку с этим мультихешем.
Для прямой работы с raw блоками у ipfs также имеются команды:
При помощи ipfs block get [мультихеш] я выяснил чему соответствует мультихеш от тестового файла который я только что загрузил командой ipfs add [полный путь к файлу] используя RHash и Base58 online декодер. Файлы размером меньше 262158 байт хранятся в сети одним блоком. Формат этого блока я так и не выяснил по умолчанию это данные упакованные в Protocol Buffers.
Интересно что webui храниться в децентрализованной сети и часть кода самого клиента также храниться в ней. Код подгружается из сети автоматически перед компиляцией клиента. Зачем это сделано не знаю. Это немного затрудняет чтение исходников.
Эксперименты с IPFS и BitTorrent
Экспериментируя с IPFS WebSeed и qBittorent я заметил что локальный IPFS очень медленно отдаёт данные запрашиваемые в случайном порядке. Только когда я включил последовательное скачивание скорость возросла до 1МБ/c. И этом все блоки раздачи находятся в локальном хранилище. Также IPFS сильно грузит процессор.
Для BitTorrent’а IPFS клиент может послужить хорошим дедупликатором. Он сможет найти копии файлов по IPFS мультихешу каталога или файла. Для этого достаточно добавить его как WebSeed в торрент.
IPFS WebSeed
После этого полученные ссылки можно добавить в создаваемый торрент-файл или магнит.
WebTorrent и IPFS WebSeed
WebTorrent сможет работать только с локальным шлюзом IPFS и то только после настройки так как шлюз должен дать разрешение для WebTorrent использовать HTTP заголовок Range.
после чего сохранить и перезапустить IPFS
Межпланетная система имён
Сочетание бесплатного DNS, http://gateway.ipfs.io/ipns/[мультихеш публичного ключа] и IPFS клиента позволяет раздавать с домашнего сервера небольшой статичный сайт даже находясь за NAT.
Межпланетная файловая система и магнит
Сейчас IPFS не умеет работать с магнит-ссылкам и да и не описан URN который содержит в себе используемый в сети мультихеш.
Я предлагаю такой: urn:ipfs:[Base58 bitcoin encoded IPFS multihash]
В магнит ссылке он соответственно будет выглядеть так:
Написав небольшой скрипт можно научить работать IPFS с магнитами или другие децентрализованные клиенты использовать IPFS как WebSeed.
Я думаю использование магнит-ссылки позволит отвязаться от сайта ipfs.io с которым может произойти та же история что и с доменом shareaza. И более чётко обозначить IPFS мультихеш.
Немного не по теме
Я тут для магнитов нарисовал(написал на самом деле) логотип для безвозмездного использования. Хочу его представить чтоб он стал узнаваемым символом магнит-ссылки ну и использовался для её обозначения. Может тогда я смогу откатить отмену моей правки в статье по магнит-ссылкам и вернуть логотип в статью.
Цвета для магнита взяты из логотипов клиентов децентрализованных сетей. Я не дизайнер. Старался сделать рисунок простым и компактным. Вы можете свободно копировать его и изменять.
Источники
Продолжение
IPFS на сервере. Хостим сайты с ноутбука
Мне часто нужно опубликовать статическую страницу или сайт, демо с веб-формой или версткой. Заливать каждый раз куда-то вроде Jsfiddle не всегда удобно, да и редактировать статику в локалхосте куда быстрее и приятнее. Проблемы начинаются, когда мне нужно кому-то показать мою работу, или просто открыть ту же страницу с телефона. Приходится хостить все эти бесконечные рабочие варианты и зарисовки, для каждой заново заливать файлы, прикручивать vhost-ы.
С помощью IPFS можно хостить сайты в интернете прямо с ноутбука, все обновления локальных файлов будут сразу применяться в интернете, и их не нужно куда-то заливать. Когда ноутбук отключен от сети, сайт все равно будет доступен. IPFS это как Bittorrent, только для веба.
В статье мы развернем IPFS ноду на сервере и попробуем эту технологию на практике.
Что такое IPFS
IPFS — это большая децентрализованная p2p-сеть, которую используют как файлообменник, веб-архив или замену Bittorrent. Все крутые примеры использования IPFS в реальных проектах можно посмотреть в зале славы на официальном сайте awesome.ipfs.io.
Вкратце работает оно так: хранимые файлы получают свой мультихэш и разбиваются на блоки, которые разлетаются по всем заинтересованным нодам. На нодах синхронизируется DHT, при скачивании файла собираются блоки с разных (в теории — ближайших) нод. Причём для доступа к файлу или директории не нужно поднимать свою ноду, они все доступны из браузера, что приводит нас к народно любимой фиче: на IPFS можно бесплатно хостить сайты. Но только статику, обновлять любые данные чаще, чем раз в несколько минут неудобно из-за тех же хэшей, которые формируют ссылку и меняются при каждом изменении в файле (существует система постоянных имён IPNS, но она медленная). Впрочем, это не помешало чувакам из Orbitdb запилить базу данных на IPFS, но там свои нюансы. Более подробно почитать про устройство сети можно здесь.
Как будем хостить
Допустим, у меня есть нода, с которой я бесплатно раздаю статические сайты, сам же на них хожу и иногда привожу коллег посмотреть. Общий объем данных ограничен только размером моего диска, а скорость загрузки — домашним интернетом, что может быть лучше? Но есть ряд проблем. Во-первых, самой IPFS нужно довольно много интернета и солидный кусок процессора, и даже без трафика она всегда отбирает часть ресурсов на синхронизацию DHT. Во-вторых, я в основном работаю с ноутбука и все файлы держу на нём же, и потому же далеко не всегда у меня под рукой домашнее полугигабитное волокно. Кратковременные разрывы для IPFS не проблема, она держит кэш в DHT несколько часов, но стоит куда-то уехать на пару дней, и вот уже все твои проекты радостно высыпаются из сети. Можно запиннить (“запомнить”) файлы на десктопе, но это как минимум вдвое увеличит трафик, что тоже не комильфо. Что делать? Я попробовал поднять ноду на сервере, чтобы разгрузить ноут, но мне всё еще приходилось грузить файлы вручную, как на обычный хостинг. В итоге я покурил доки и API и написал простенькую утилиту для синхронизации моей локальной статики с сервером.
У IPFS есть две самостоятельные реализации: go-ipfs и js-ipfs. Мне ближе JS, поэтому я писал на нём. Я хотел чтобы утилита могла подхватывать папки с моими сайтами, и регулярно загружать их в сеть, пока я работаю. Серверная часть должна ловить хэши папок и пиннить их, чтобы файлы не потерялись.
Установка и запуск
У js-ipfs довольно подробный туториал с примерами, поэтому:
Нода запускается в несколько строк:
Конфиги и сиды для неё прописываются тут же, но для старта достаточно этого.
Пишем функционал
Дальше нужно передать ноде файлы и загрузить их в IPFS. Для этого используем node.add с параметром < recursive: true >для папок. Адрес можно передавать в аргументах при запуске, а сохранять по команде. Важно записать только последний хэш — он от корневой папки:
Вся папка успешно ушла в сеть. По ссылке откроется сайт, а саму папку можно проверить на вебморде IPFS:
Круто, но пока все файлы мы раздаем с локальной машины. Пора подключать серверную ноду! Берём экспериментальный pubsub, получаем топик из аргументов при запуске и пробуем доставить хэш сохранения:
Ура! Дело за малым — заставить сервер хранить все полученные хэши и пиннить их ( node.pin.add ), и научить клиент вырубать свою ноду, когда она не нужна ( node.stop ).
Так выглядит список загрузок на серверной ноде
Что в итоге?
Вообще с помощью IPFS можно делать и гораздо более интересные штуки. Я вот точно хочу довести до ума эту утилитку и написать новую, с гуи. А пока вот держите сайт, который мы писали и хостили всё это время:
Браузер Opera с поддержкой IPFS
Буквально несколько дней назад Opera Software выкатили первый браузер с нативной поддержкой IPFS. Пока, правда, только в мобильной версии для Android. Это значит, что он может напрямую обращаться в сеть IPFS без веб-шлюзов! Ждем когда поддержку добавят в десктопную версию.
Публикуем сайт в межпланетной файловой системе IPFS
В этой статье я расскажу как в ней запустить статичный сайт который будет доступен и напрямую и по IPNS. У сайта будет нормальное доменное имя благодаря использованию DNS. Доменное имя можно использовать для доступа к сайту напрямую, через глобальный и локальный шлюз.
Напомню: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я начал рассказ в статье «Межпланетная файловая система IPFS».
Имя домена может содержать только один тире подряд из за этой строки:
Она проверяет правильность имени домена. Ограничения на домен будут работать пока не примут Pull request «Use more comprehensive hostname regex pattern Fix».
Один сайт
В каталоге сайта должен быть минимальный набор:
Редактирование настроек доступно в веб интерфейсе http://127.0.0.1:5001/webui#config(он будет доступен после запуска клиента командой ipfs daemon ) либо в файле
После редактирования настроек клиент необходимо перезапустить.
Так мы откроем доступ к шлюзу из интернета.
Публикуем каталог с содержимым сайта
Последним будет нужный нам мультихеш корневого каталога
Привязываем мультихеш каталога к ID
Здесь в ответе первым идёт ID
Заходим в панель управления DNS добавляем запись TXT
Через некоторое время (когда произойдёт обновление DNS) контент станет доступен по адресу сайта и на шлюзе по адресу /ipns/
Если данные условия не подходят можно использовать мультихеш.
Так мы опубликовали один сайт.
Проверка
Проверить правильную работу домена можно командой:
Несколько сайтов
Бывает что нужно опубликовать несколько разных сайтов.
Добавляем в DNS TXT запись каждого каталога dnslink.
Альтернативные способы
Можно ссылаться на другой домен у которого задан dnslink.
В dnslink можно аналогично указать мультихеш на каталог или файл.
Это будут перманентные ссылки. Этот способ подойдёт для публикации редко изменяющегося содержимого. В данном случае сразу доступен мультихеш содержимого и оно сразу будет доступно если есть его копия в IPFS сети.
Соответственно в данном способе публикации при обновлении содержимого сайта нужно обновлять и DNS запись.
Локальный шлюз
Для того чтобы пользователи автоматически подключались к сайту через локальный шлюз я предлагаю добавить A DNS запись.
Это позволит пользователю подключить простой proxy.pac который загрузит сайт через локальный шлюз.
Глобальный шлюз
Можно использовать IPFS хостинг. Для этого надо добавить две записи в DNS.
Но не все DNS хостинги позволят задать CNAME корневому домену.
В данном случае наш IPFS клиент может работать с настройками по умолчанию. Как только кто то обратится к нашему сайту IPFS клиент на сервере gateway.ipfs.io скопирует от нас содержимое сайта и передаст через шлюз. Данный вариант удобен если ваш сервер за NAT. Но не забываем о том что у глобального шлюза тоже бывают перегрузки.
Заключение
Вот так просто мы делаем свой сайт доступным более современным способом. Теперь он доступен не только напрямую но также и в децентрализованной сети IPFS.
Почему Интернету нужен IPFS, пока ещё не поздно
IPFS не совсем ещё сделалась хорошо известной технологией, даже в Кремниевой долине многим она ещё не известна, однако вести о ней быстро расходятся из уст в уста в сообществе открытого исходного кода. И многие рады потенциальным возможностям IPFS в области улучшения передачи файлов и ускорения потокового вещания их по Интернету.
С моей личной точки зрения, однако же, IPFS в действительности гораздо важнее этих возможностей. IPFS избавляет сайты от необходимости использовать центральный сервер-первоисточник и поэтому, вероятно, это наш лучший шанс полностью переменить архитектуру Интернета прежде, чем она развалится от внутренних противоречий.
Как и почему это? Для ответа на этот вопрос придётся вдаваться в подробности.
Почему наша Всемирная Паутина медленна, непрочна и забывчива
IPFS является новым p2p-гипермедийным протоколом, цель которого — дополнять собою (или даже, может быть, заменить) протокол передачи гипертекста (HTTP), сейчас господствующий в WWW. Вот в чём проблема HTTP: сегодня, когда вы посещаете сайт, ваш браузер должен напрямую связываться с серверами, на которых этот сайт работает, даже когда серверы эти далеко, а процесс передачи требует немалой пропускной способности.
Провайдеры несут расходы, потому что между сетями заключены пиринговые соглашения, так что пересылка данных из сети в сеть стоит денег провайдеру и расходует пропускную способность канала. Хуже того, файл по HTTP скачивается всего лишь с одного компьютера вместо того, чтобы одновременно получать части файла с разных компьютеров.
Вот почему и вот в каком положении дел мы застряли: медленный и дорогостоящий Интернет, цена которого ещё возрастает в силу хищничества провайдеров «последней мили» (по меньшей мере, в США), и с ускоряющимся ростом запросов на соединение с мобильных устройств. Он не просто медленный и дорогостоящий, но и ненадёжный. Если хотя бы одно звено оборвётся по любой причине, то оборвётся и передача. (А когда или медиафайл грузятся долго, то, скорее всего, виною тому одно из межкомпьютерных соединений.)
Переделываем Интернет посредством IPFS
IPFS (InterPlanetary File System, то есть межпланетную файловую систему: это название — дань памяти идеям о «межгалактическом» Интернете) придумал Juan Benet, который подростком приехал в США из Мексики, в Стэнфорде получил степень по информатике, основал компанию, приобретённую «Yahoo!» в 2013 году, а в прошлом году при посредстве Y Combinator основал Лаборатории Протокола (Protocol Labs), которые сейчас занимаются проектом IPFS и скромно намерены переменить те протоколы, которые последние 20 лет были для нас повседневным явлением жизни.
IPFS — это P2P-распределённая файловая система, стремящаяся соединить все вычислительные устройства одной общей системою файлов; как таковая, она способна превзойти возможности HTTP в нескольких отношениях. Из них два (как сообщил мне Хуан в недавнем разговоре) являются ключевыми:
«Мы используем контентную адресацию, поэтому контент приобретает независимость от серверов первоисточника и может храниться отдельно и долговременно. Это значит, что контент может храниться и раздаваться очень недалеко от потребителя — быть может, даже компьютером из той же самой комнаты. Контентная адресация также позволяет и проверять данные, полученные от других (не доверенных) хостов вместо первоисточника. А когда контент попадает на устройство пользователя, его там можно кэшировать сколько угодно».
IPFS также устраняет некоторые проблемы безопасности, досаждающие нашему основанному на HTTP Интернету: основанная на контенте адресация (и последующая верификация) защищает основанные на IPFS сайты, распределённость IPFS делает невозможными. Помогая смягчить ущерб от закрытия сайтов их владельцами, IPFS также кэширует в себе важный для общества контент и может невозбранно сохранить его.
Главнейшим же из достоинств IPFS служит децентрализованная раздача контента, так что к контенту из Интернета можно обращаться в обстоятельствах нерегулярного доступа к Интернету и даже брать его из оффлайнового кэша. «Мы создаём сайты не имеющие центрального Они могут быть распределёнными подобно тому, как распределённою является HTTP просто не может добиться, так что IPFS послужит во благо сетей, не имеющих первоклассных взаимосвязей (например, в развивающихся странах или в сельской местности).
Появление альфа-версии IPFS в прошлом феврале ужé повлекло за собою множество экспериментов среди ранних восприёмников её (early adopters). Например, 8 сентября хостинг Neocities стал первым крупным сайтом, пользующимся IPFS для хранения контента, то есть последовавшим призыву Internet Archive о необходимости распределённого WWW. В настоящее время все мы претерпеваем непрестанную утрату всё новых и новых сайтов, год за годом покидаемых и закрываемых их создателями, и в этом нарастающем кризисе нашей коллективной интернетовской памяти для нас важен даже малый шаг в сторону перманентной Паутины.
А сайты, принадлежащие крупным корпорациям, последуют ли примеру Neocities, начнут ли внедрение ещё не полностью протестированного протокола — особенно когда даже простое упоминание P2P способно привести их в ужас? А вот тут я подхожу к последнему пункту статьи.
Почему IPFS весьма значим для будущего
Как я разъясняю в моей новой книге (публикация которой ещё впереди), мы быстро приближаемся к той точке, за которою стоимость доставки контента опередит полезность — и финансовую выгоду. Крупнейшие компании Интернета ужé изо всех сил стараются не отстать от нашего спроса на контент, целые армии инженеров заняты одной этой задачею и в Akamai, и в Google, и в Amazon.
Скоро их положение ухудшится. Благодаря быстрой продаже дешёвых смартфонов в ближайшее десятилетие в онлайн выйдут целые континенты новых потребителей. Интернет Вещей также обещает усугубить эту проблему, ведь биллионы устройств с их собственными запросами приналягут на быстро истощающиеся возможности наших каналов связи.
Нам ужé до крайности необходимо ограничение того эффекта, который я называю микросингулярностью: быстрое «вирусное» привлечение пристального внимания биллионов пользователей Интернета к одному и том же событию угрожает удушить собою всю систему. (Перебои в работе сети теоретически угрожают и жизни, когда микросингулярностью становится катастрофа, авария или другое явление того же рода.)
Улучшая связность, IPFS поможет Интернету становиться той системою, которою мы всегда стремились видеть его в наших идеализациях, но которой с нынешними протоколами стать он не мог: истинно способною соединить всех в мире (даже находящихся в оффлайне) перманентным, но постоянно развивающимся выражением того, кто мы такие и к чему мы стремимся.
Послесловие от переводчика
Хабрахабр — это даже не Кремниевая долина, так что и здесь, как можно предполагать, к началу октября 2015 года не все ещё читатели составили для себя достаточное представление об IPFS. Следовательно, окончив перевод статьи из TechCrunch, мне придётся также приложить к ней определённое разъясняющее послесловие; и прилагаю, облекая его в форму вопросов и ответов.
— Распределённая файловая система с контентной адресацией.
— В каком смысле система IPFS является распределённою?
— В смысле P2P-файлообмена. Скачав файл, пользователь становится его источником для других скачивающих.
— В каком смысле система IPFS является файловой системою?
— В прямом: если ваша операционная система является юниксоподобною, то при помощи FUSE можно подключиться к IPFS таким способом, чтобы видеть файлы IPFS по адресу у себя в файловой системе.
— В каком смысле система IPFS является контентно-адресуемою?
— Хэш файла зависит только от содержимого файла. Если файл имеет другое имя или лежит в другом подкаталоге, то это всё равно тот же файл. (Это выгодно отличается, например, от битторрентовского хэша BTIH, который изменяется в зависимости от названия и взаимного расположения файлов.) Если тот же самый файл раздаётся под другим именем или в составе другого подкаталога, раздачи автоматически объединятся, не потребуется удвоение усилий, траффика, пространства на диске.
— Есть ли в файловой системе IPFS подкаталоги?
— Есть; это списки имён (и хэшей) файлов и подкаталогов. Например, для открытия адреса сперва скачивается каталог (по его известному хэшу), затем по имени файла в каталоге выясняется тот хэш, при помощи которого IPFS будет качать файл. Каждое имя подкаталога добавляет один шаг к этому процессу.
— Как узлы IPFS знают, у каких из них есть желаемый файл?
— Используется DHT (наподобие Kademlia, но с большей устойчивостью Нет никакого центрального сервера, который можно было бы захватить, отключить, отнять имя (как захватывают и отключают например).
— Как сайт нынешней Всемирной Паутины может сослаться на файл, лежащий в распределённой файловой системе IPFS?
— Автор сайта ставит себе IPFS и кладёт файл в IPFS. Затем он записывает перед файла и получает, например, работает как гейт из IPFS в WWW, так что читатели, у которых поддержка IPFS не установлена, могут с этого сайта получить файл.
— А читатели, у которых поддержка IPFS установлена?
— А у них появляется личный гейт из IPFS. Остаётся только поставить такое дополнение для Firefox или расширение для Chrome, которое будет «127.0.0.1:8080» автоматически подставлять вместо «ipfs.io» в таких URLах.
— Каким образом IPFS спасает в случае нарушений в работе сети?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если сайт упадёт, читатель всё равно может получать файлы по известному адресу, только не из сайтового кэша IPFS, а из кэша у соседа. (И сосед не сможет подменить файл, потому что будет проверяться соответствие файла хэшу.)
— Каким образом IPFS помогает сайтам экономить траффик?
— Если иллюстрации (и другие файлы) с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда, даже если вдруг случится микросингулярность и на сайт очень быстро придёт биллион зрителей, всё равно бóльшая часть их будет по IPFS стучаться не на сайт, а в кэш своим соседям по биллиону, успевшим чуть раньше. Так что сайт не приляжет. (Конечно, для этого сперва среди зрителей должна распространиться мода на IPFS, а не то вместо сайта приляжет например.)
— Каким образом IPFS помогает сайтам в случае гибели диска?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет пропавшие картинки (и другие файлы) скачать по IPFS из кэшей читателей сайта в случае чего.
— Каким образом IPFS помогает читателям в случае государственной цензуры?
— Если иллюстрации и другие статические файлы с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно будет запрещённые иллюстрации (например, иллюстрации к ранобэ «精霊使いの剣舞») и другие запрещённые файлы получать по IPFS в обход блокировки (из кэшей читателей сайта, успевших получить файлы до вступления цензуры в силу).
___
* Нарочито «кавайная» запись фамилии Е.Б.Мизулиной; сатира на её роль в #антианиме.
— Каким образом IPFS помогает сайтам экономить дисковое пространство?
— Если иллюстрации с самого начала публиковать не по сайтовому адресу, а в IPFS, то тогда можно через некоторое разумное время стирать их из кэша IPFS, высвобождая пространство и надеясь на то, что иллюстрации продолжат быть доступными для читателей, которые просто будут в дальнейшем получать их из кэша IPFS друг у друга.
— То есть это реальная альтернатива для тех хостингов картинок и для имиджборд, которые сейчас действуют жёстко и после определённого времени просто стирают файлы невозвратно?
— Совершенно верно. (Я предлагал эту альтернативу на Иичане, например.)
— Есть ли прямо сейчас пример такого хостинга картинок, который складывает картинки в IPFS?
— Есть ли прямо сейчас пример такого хостинга произвольных файлов, который складывает их в IPFS?
— Означает ли контентная адресация, что в IPFS можно хранить только статический (неизменный) контент?
— В общем-то да. Впрочем, есть система имён IPNS для сайтов, позволяющая ставить каждому имени IPNS в соответствие свой хэш каталога IPFS, а затем по мере нужды изменять это соответствие. То есть выложить на такой сайт некоторое статическое содержимое, но новое.
— Может быть, придумать новую схему URLов для IPFS? Это позволит записывать их короче, чем длинноватый адрес перед хэшем.
— Две недели обсуждали и решили остановиться предшествующей такому пути в файловой системе, который начинается
— Почему не сделали две раздельные схемы «ipfs:» и «ipns:»?
— Для удобства пользователей юниксоподобных систем, которым теперь достаточно стереть чтобы получить путь. (А не то переправлять ещё возиться.)
— Будут ли адреса «fs:» поддерживаться в гипертекстовом Фидонете?
— Будут; для этого достаточно трёх строк на языке ECMAScript 6. Вот пример фидонетовской блогозаписи, сперва снабжённой иллюстрацией из IPFS, а затем транслированной по RSS в LiveJournal.
— Можно ли добавить поддержку открытия в редактор фидопочты
— Работает ли IPFS под Windows?
Нынешняя альфа-версия под Windows работает довольно скверно, но предыдущая вообще переставала запускаться, так что можно надеяться на дальнейшее улучшение положения дел в будущем, и надеюсь.
