IPFS в браузере
Браузер не имеет тех же сетевых возможностей, что серверный процесс. При встраивании IPFS в страницу библиотеки нужно отдельно выбирать способ получения, локальное хранение и границу доверия. В уроке сравним прямой клиентский маршрут и HTTP-выдачу, не обещая, что любой опубликованный выпуск автоматически станет доступным офлайн.
Клиент и сайт не запускаются, зависимости не устанавливаются. Профиль API Helia 7 используется как исследованная отправная точка. Полная браузерная конфигурация и её совместимость пока не проверены исполнением.
Ограничения среды
Браузер ограничивает доступные транспорты, origin, память и постоянное хранилище. Обычный серверный адрес участника может быть недоступен напрямую. Поэтому клиент использует поддерживаемые соединения или посредников, которые предоставляют совместимый маршрут.
Для пользователя это различие может быть невидимо: одна кнопка открывает урок. Для архитектуры оно существенно. Если получение зависит от внешнего HTTP-источника, его недоступность и журналирование входят в модель библиотеки. Наличие Helia в коде не устраняет эту зависимость автоматически.
Не передаём браузеру токен административного pinning API ради удобного добавления. Клиентский код и запросы доступны пользователю. Публичное чтение и управление хранителем требуют разных полномочий. Секрет поставщика остаётся на серверном маршруте либо используется иной ограниченный механизм с явным договором.
Проверенный клиентский маршрут
Клиент может получать блоки и проверять их связи по ожидаемым CID. После восстановления файла он сравнивает точные байты манифеста с объявленным SHA-256 и проверяет схему. Это даёт предметную проверку содержания, если исходное объявление получено доверенно.
Однако реализация проверки выполняется внутри самой страницы. Если исходный код страницы уже подменён, он может нарисовать «проверено» без честной операции. Поэтому защита начального приложения и канала объявления остаётся частью модели. Проверка данных не является универсальным решением загрузки доверенного проверяющего кода.
доверенное приложение + доверенное объявление
↓
полученные блоки → проверка → файл → допустимая схемаСхема показывает предпосылки. Нельзя опустить верхнюю строку и обещать полное устранение доверия только потому, что в нижней операции используется хеширование.
HTTP-выдача
Простой маршрут открывает URL шлюза. Сервер преобразует запрос к содержимому в обычный HTTP-ответ. Браузер умеет показать HTML без специального IPFS-клиента. Такой вариант удобен для чтения, но обычно браузер не выполняет самостоятельную полную проверку DAG только из-за присутствия CID в пути.
Можно дополнительно получить манифест и сверить его байты в доверенном приложении. Можно выбрать trustless-выдачу блоков и собственную проверку. Это разные профили. В интерфейсе слова «получено через шлюз» и «проверено клиентом» должны иметь разные основания.
Для активного HTML важен origin. Разные выпуски на одном path-шлюзе могут оказаться в одном origin, тогда как поддоменная выдача меняет изоляцию. Подробности появятся в следующей группе уроков. Сейчас фиксируем, что обычное отображение открытого документа включает браузерные правила исполнения.
Локальная копия
Если клиент хочет офлайн-чтение, он должен получить весь объявленный состав, сохранить данные и подтвердить завершение. Просмотр первой страницы не означает наличие следующих уроков, изображений и стилей. Частичный кэш отмечается как частичный.
Браузерное постоянное хранилище подчиняется квотам и может очищаться. Пользователь должен видеть возможность экспортировать архив или повторно получить выпуск. Нельзя обещать вечное хранение на устройстве, которое приложение не контролирует.
Для небольшого выпуска можно хранить манифест и перечень готовых файлов. Для большого набора важны потоковая обработка и ограничения параллелизма. Если один урок не получен, интерфейс показывает его конкретное состояние, а не общую ложную надпись «весь курс сохранён».
Отмена и смена выпуска
Пользователь может выбрать вторую редакцию, пока запрос первой ещё идёт. Результаты должны связываться с конкретным идентификатором выпуска. Поздний ответ первой версии не переписывает карточку второй. Это обычная задача управления асинхронным состоянием, которая сохраняется и в Web3.
При отмене запроса уже сохранённые проверенные блоки могут оставаться в локальном хранилище по выбранной политике. Но стадия целого выпуска не становится завершённой. Перезапуск восстановления начинает с известной описи и подтверждённых частей, а не повторяет слепо все загрузки.
Ошибка сетевого получения не означает неверный отпечаток. Отдельные причины помогают пользователю выбрать повтор, другой источник или сообщение редакции. Автоматический переход к изменяемому файлу основного сайта без обозначения версии разрушит договор выпуска.
Поздний ответ после смены редакции
Посетитель открывает первую редакцию, затем сразу выбирает вторую. Первый запрос остаётся в работе, а ответ приходит позднее. Если обработчик просто запишет результат в текущий экран, заголовок второй редакции может оказаться рядом с текстом первой. Криптографическая проверка первой вполне могла пройти: ошибка заключается в привязке результата к пользовательскому выбору. Поэтому операция имеет собственную идентичность, ожидаемый корень и снимок выбранной редакции.
В приложении удобно хранить поколение текущего запроса. После переключения оно меняется; обработчик завершённой операции сверяет своё поколение и цель перед обновлением интерфейса. Отмена транспортного запроса помогает уменьшить лишнюю работу, но сама по себе не гарантирует, что никакой поздний обработчик больше не сработает. Решение о показе результата остаётся прикладным правилом. Это схема поведения нашего читателя, а не встроенное обещание одного IPFS-модуля.
Уже проверенные блоки прежнего выпуска можно оставить в предусмотренном хранилище. Их корректность не зависит от того, какой экран сейчас открыт. Однако они не заполняют статус «вторая редакция сохранена». Состав локальных данных связывается с описью соответствующего выпуска, а интерфейс показывает готовность именно выбранной цели. Общий счётчик загруженных байтов не различает эти случаи.
Похожие ограничения действуют при отображении. Проверенный текст манифеста безопаснее сначала обработать как данные и показать контролируемыми элементами интерфейса. Передача произвольного активного HTML в контекст личного кабинета требует отдельной политики изоляции. Совпадение CID не делает скрипт безвредным и не даёт ему права читать данные пользователя. В результате браузерный маршрут включает не только получение и проверку, но и правильную привязку результата к экрану, хранению и допустимому способу отображения.
Подготовленный профиль
Досье браузера перечисляет способ получения, начальный доверенный код, хранение, пределы размера и правило проверки. Все недостающие измерения и проверки совместимости остаются явно непроведёнными. В этой работе мы пишем исходники и объяснения, а не создаём работающую сеть.
Модульность текущего API описана в миграции Helia 7, а модели выдачи — в документации шлюзов. После урока браузерный маршрут имеет честные границы: он может проверять полученное содержание при известных предпосылках, но не обещает доступность и постоянное хранение одной кнопкой.