что такое имя хоста шлюза который используется для преобразования адресов ipfs ipns
Межпланетная файловая система — Переключаем свой сайт на localhost (локальный шлюз IPFS)
Мало смысла в IPFS, если использовать его только как бесплатный хостинг для сайта в сети интернет. Поэтому мы научимся здесь загружать наш сайт через локальный IPFS шлюз пользователя.
Пользователю это даст быстрый доступ к его локальной копии нашего сайта.
Напомню: InterPlanetary File System — это новая децентрализованная сеть обмена файлами (HTTP-сервер, Content Delivery Network). О ней я начал рассказ в статье «Межпланетная файловая система IPFS».
Переключаем наш сайт
У нашего сайта на данный момент уже есть как минимум 3 DNS записи:
Добавим к ним ещё 3:
[CID контента] — Это идентификатор контента (CID) раньше назывался мультихеш. Его мы получаем публикуя сайт командой ipfs add в сети IPFS.
Скрипты и стили
В HTML тегах script и link появились поля integrity и crossorigin. Они отвечают за проверку хеша до запуска скрипта или применения стилей. Их мы и используем для определения рабочего шлюза у посетителя сайта.
Расположить их лучше в конце страницы, чтобы они не задерживали загрузку и отображение.
Варианты адресов, которые нам надо проверить:
http://l.[наш домен]:8080
8080 это стандартный порт на котором по умолчанию запускается IPFS.
Если всё настроено правильно, то с http-версии сайта браузер загрузит скрипт или стиль.
https://l.[наш домен]:8443
8443 это порт на который пользователь может настроить stunnel.
Данный вариант нам понадобится, если запрос идёт с HTTPS сайта и наш домен добавлен в локальный сертификат.
http://127.0.0.1:8080/ipns/[наш домен]
Этот вариант на случай, если мы не задали l домен для нашего сайта и запрос идёт с http.
https://127.0.0.1:8443/ipns/[наш домен]
Этот вариант на случай запроса с https. Этот вариант сработает, если не задан l домен или не добавлен в локальный сертификат.
Аналогичным образом мы можем проверить порты 80 для http и 443 для https.
Проверяем локальный шлюз и переключаемся на него скриптом
Добавив этот скрипт к странице вашего сайта вы автоматически переключите посетителя на его локальный IPFS шлюз.
В пару ему идет скрипт:
redirect_call.js (sha384-dActyNwOxNY9fpUWleNW9Nuy3Suv8Dx3F2Tbj1QTZWUslB1h23+xUPillTDxprx7)
Integrity этого скрипта можно посчитать командой:
У меня соответственно результат этой команды:
Если у вас результат другой, замените это значение в скрипте выше на своё.
Теперь пользователь будет автоматически перенаправлен на подходящий локальный адрес шлюза с сохранением остальных параметров адреса.
Определяем рабочий шлюз при помощи CSS
Создадим CSS файл который будет маяком работы шлюза.
Скрываем элементы страницы, которые будут показаны только при доступности локального шлюза.
Добавляем CSS маяк в конце страницы
Этот элемент будет отображаться если загрузиться «httpl.css»
Теперь даже если у пользователя отключены скрипты, он сможет перейти на шлюз самостоятельно по ссылке. Аналогично можно проверить и остальные варианты адреса шлюза.
Локализуем глобальный шлюз или сайты в 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 (InterPlanerary File System). Пришла пора рассказать о ней подробнее, поскольку это одна из наиболее перспективных распределённых технологий.
Что такое IPFS?
IPFS – это глобальное хранилище неизменяемой информации. Работает как временный кэш, но также возможно использование специальных сервисов (платных или волонтёрских), гарантирующих сохранность информации.
Какие проблемы решает IPFS?
IPFS должен заменить некоторые функции HTTP (и HTTPS) из-за проблем этого протокола:
Устройство IPFS
За более подробной информацией обратитесь к whitepaper и к документации.
ВНИМАНИЕ! IPFS является полностью публичной сетью. Любой помещённый в неё файл доступен каждому участнику сети. Для ограничения доступа используйте шифрование. Также возможно создание приватной сети на основе IPFS. Более подробно читайте в документации.
Фиксация содержимого
IPFS по умолчанию не даёт никаких гарантий того, что файлы будут храниться в сети. Как уже было сказано, узлы хранят только те файлы, которые используют.
Для сохранения файлов существует механизм закрепления (pinning). Есть несколько сценариев его использования:
Для надёжности следует использовать все способы и закреплять файлы на нескольких узлах. Чем больше узлов хранит файл, тем меньше вероятность того, что он пропадёт, если узел будет закрыт.
Шлюзы
Для доступа к файлам, размещённым в IPFS, требуется установка специального программного обеспечения. Расширение для веб-браузеров IPFS Companion делает опыт взаимодействия в веб-браузере со страницами из IPFS неотличимым от взаимодействия с обычными веб-страницами. IPFS Desktop позволяет рядовому пользователю легко использовать IPFS. Для администраторов серверов или для продвинутых пользователей возможна установка с помощью ipfs-update, из бинарных репозиториев или путём компиляции из исходного кода.
Необходимость установки программного обеспечения, даже если она не вызывает больших трудностей, сильно ограничивает потенциал IPFS. Для решения этой проблемы были придуманы шлюзы (gateways) – обычные веб-сайты, которые отдают содержимое из IPFS.
У такого способа разрешения имён есть два недостатка. Во-первых, если файл является веб-страницей, то ссылки на ней должны быть относительными. Во-вторых, если файл является веб-страницей, содержащей интерактивное одностраничное веб-приложение, то это угроза безопасности, поскольку приложение работает на том же домене, что и другие, посторонние приложения.
Поэтому существует ещё способ разрешения имён через поддомен. Ссылка на наш файл в этом случае будет иметь вид https://bafybeifoottvirj3crpx66qdsey7lxlp6qwk57wl37xygjqymeobwixy5e.ipfs.dweb.link/concepts/ipfs-gateway/, где ipfs.dweb.link – это шлюз, который поддерживает такой способ разрешения имён. В общем случае URL выглядит так:
Список шлюзов имеется по ссылке https://ipfs.github.io/public-gateway-checker/. Необходимо понимать, что использование сторонних шлюзов нивелирует преимущества IPFS. Одной из проблем сторонних шлюзов является то, что они без труда могут осуществить атаку MitM (man-in-the-middle), то есть подменить содержимое, однако это решается использованием собственного шлюза, поэтому вы вполне можете использовать IPFS для размещения серьёзных веб-сайтов и веб-приложений, не создавая неудобств для пользователей.
Поскольку IPFS использует адресацию на основе содержимого, малейшее изменение полностью меняет адрес. Для того, чтобы иметь постоянную ссылку на меняющееся содержимое, поверх IPFS построена система IPNS (InterPlanetary Name System). Эта система очень простая. С использованием приватного ключа узел сообщает сети, что он хочет опубликовать по адресу, связанному с этим ключом, определённый CID. Эта привязка остаётся действительной некоторый промежуток времени, обычно сутки. Чтобы адрес оставался актуальным, требуется периодически повторно осуществлять эту операцию, что можно автоматизировать, например, с помощью Cron.
К сожалению, этот процесс нельзя делегировать стороннему сервису, как это возможно в случае простого хранения файлов, не передавая ему свой приватный ключ. Однако, это позволяет раздавать веб-сайт, например, с постоянно включенного домашнего компьютера, даже если он находится за NAT. Система IPNS ещё развивается. Возможно, в будущем это ограничение будет устранено.
DNSLink
IPNS использует в качестве идентификатора CID. Это очень длинная и ничего не значащая для человека строка, её неудобно произносить вслух и вводить вручную. Благодаря DNSLink можно привязать содержимое IPFS к традиционному доменному имени. Например, веб-сайт https://Causa-Arcana.com работает через DNSLink. При этом пользователи, у которых стоит программное обеспечение IPFS, получают содержимое из этой сети, а остальные пользователи получают содержимое через шлюз.
Для привязки CID к доменному имени необходимо создать две записи в DNS:
Здесь cloudflare-ipfs.com – это адрес шлюза, который поддерживает DNSLink.
Преимуществом DNSLink перед IPNS, помимо более удобного имени веб-сайта и отсутствия необходимости иметь сервер для постоянного повторения процесса публикации, является отсутствие в ссылке доменного имени конкретного шлюза. Если шлюз перестал работать или заблокировал ваш веб-сайт, то достаточно выбрать другой шлюз и вписать его в запись DNS типа CNAME. В то же время, этот способ подразумевает привязку к традиционной системе доменных имён, которая является централизованной, в ней возможны цензура и изъятие домена.
Виды CID
Существует два вида идентификаторов содержимого:
Хотя CIDv0 всё ещё является стандартным для содержимого, помещаемого в IPFS, он плохо подходит для поддоменов, поскольку использует и заглавные, и строчные буквы, в то время как доменные имена не чувствительны к регистру.
Один и тот же идентификатор CIDv1 может использовать различные кодировки:
Именно CIDv1 с кодировкой Base36 используется для поддоменов.
Для преобразования между различными видами CID существует сервис https://cid.ipfs.io.
Публикуем веб-сайт в IPFS
Вам потребуются операционная система на основе GNU/Linux, навыки работы в командной строке и программное обеспечение IPFS.
Создаём веб-сайт
Для начала создадим простой веб-сайт, состоящий из двух страниц. Создайте пустую директорию в вашем домашнем каталоге и перейдите в неё:
Также создайте директорию для второй страницы сайта. Это нужно для демонстрации работы относительных ссылок:
Помещаем веб-сайт в IPFS
# Address IPFS on the Web
How to link to content on IPFS.
Browsers that support IPFS can redirect these requests to your local IPFS node, while those that don’t can fetch the resource from the ipfs.io gateway.
You can swap out ipfs.io for your own http-to-ipfs gateway, but you are then obliged to keep that gateway running forever. If your gateway goes down, users with IPFS aware tools will still be able to fetch the content from the IPFS network as long as any node still hosts it, but for those without, the link will be broken. Don’t do that.
# Dweb addressing in brief
# HTTP gateways
Gateways are provided strictly for convenience: in other words, they help tools that speak HTTP but do not speak distributed protocols (such as IPFS) to communicate. They are the first stage of the upgrade path for the web. More information about IPFS Gateways.
# Centralization
HTTP gateways have worked well since 2015, but they come with a significant set of limitations related both to the centralized nature of HTTP and some of HTTP’s semantics. Location-based addressing of a gateway depends on both DNS and HTTPS/TLS, which relies on a trust in certificate authorities
(opens new window) (PKI). In the long term, these issues should be mitigated by use of opportunistic protocol upgrade schemes.
# Protocol upgrade
Tools and browser extensions should detect IPFS content paths and resolve them directly over IPFS protocol. They should use HTTP gateway only as a fallback when no native implementation is available in order to ensure a smooth, backward-compatible transition.
Use relative or absolute URLs that include content-addressed paths. This will take advantage of content addressing today while ensuring backward compatibility with the legacy web.
For example, a website can load static assets from content-addressed paths:
Browsers that support IPFS will recognize the /ipfs/ content path and load the related asset over IPFS instead of HTTP.
User agents without IPFS support still get the correct data from the original HTTP server.
# Path gateway
In the most basic scheme, a URL path used for content addressing is effectively a resource name without a canonical location. The HTTP server provides the location part, which makes it possible for browsers to interpret an IPFS content path as relative to the current server and just work without a need for any conversion:
When in doubt, use subdomain gateway instead (see below).
# Subdomain gateway
(opens new window) is needed, CIDv1 in case-insensitive encoding such as Base32 or Base36 should be used in the subdomain:
# Native support in go-ipfs 0.5+
(opens new window) provides native support for subdomain gateways on hostnames defined in the Gateway.PublicGateways
Learn more about daemon configuration for hosting a public gateway:
(opens new window) with ready to use one-liners for most common use cases
Due to these limitations, the use of short, case-insensitive CIDv1 in a subdomain context is advised.
Base32 is the safe default; the less-popular Base36 can be used for longer ED25519 libp2p keys.
See the next section to learn how to convert an existing CIDv0 to a DNS-safe representation.
# CID conversion for subdomains
If you have content identified by an older CIDv0, there are easy ways to safely represent it as CIDv1 for use in subdomains and other case-insensitive contexts.
# Automatic — leverage the gateway in go-ipfs
TL;DR: Using a subdomain gateway as a drop-in replacement for a path one removes the need for manual CID conversion.
Request for a content path sent to the gateway domain will return an HTTP 301 redirect to a correct subdomain version, taking care of any necessary encoding conversion if needed:
The gateway takes care of converting the CID to case-insensitive encoding.
The multihash in CIDv1 is the same as in the original CIDv0.
# Manual — use cid.ipfs.io or the command line
One can also do the conversion manually.
To convert a CID to Base32 (RFC4648
# DNSLink gateway
The gateway provided by the IPFS daemon understands the Host header present in HTTP requests, and will check if DNSLink exists for a specified domain name
For a more complete DNSLink guide, including tutorials, usage examples and FAQs, check out dnslink.io
# Native URLs
Subdomain convention can be replaced with a native handler. The IPFS URL protocol scheme follows the same requirement of case-insensitive CIDv1 in Base32 as subdomains:
An IPFS URL does not retain the original path, but instead requires a conversion step to/from URI representation:
The first element after the double slash is an opaque identifier representing the content root. It is interpreted as an authority component used for origin calculation, which provides necessary isolation between security contexts of different content trees.
Native URI require CID to be case-insensitive. Use of CIDv1 in Base32 is advised.
# Further resources
# Technical specification for implementers
The best and most up-to-date source of truth about IPFS addressing can be found in the IPFS in-web-browsers repo
# Background on address scheme discussions
Discussions around IPFS addressing have been going on since @jbenet
# IPFS Companion
(opens new window) is a browser extension that simplifies access to IPFS resources.
It provides support for native URLs and will automatically redirect IPFS gateway requests to your local daemon so that you are not relying on, or trusting, remote gateways.
# Shared dweb namespace
This concept isn’t yet built, but may be explored and experimented with in the future. The distributed web community is exploring the idea of a shared dweb namespace to remove the complexity of addressing IPFS and other content-addressed protocols. Currently investigated approaches include: