IPFS: выпуск и адресация по содержимому

Учебная библиотека выпускает материалы курса 17 из Markdown. На обычном сайте адрес /course/17/ может завтра отдавать исправленный текст. Иногда читателю нужно убедиться, что он получил именно объявленный выпуск, даже если файлы передал другой сервер. IPFS предлагает адресацию по содержимому, которую рассмотрим отдельно от хранения и авторства.

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

Версия существует до адреса

Назовём первый выпуск course-17-edition-1. Он содержит страницу, стили, изображения и манифест. Издатель определяет точные файлы, которые входят в него. Если исправлена опечатка, это уже другой набор байтов, даже когда смысл текста почти тот же.

Для обычного URL место и содержание часто связаны организационно: домен ведёт к серверу, а сервер выбирает файл. Контроль URL сам по себе позволяет заменить ответ. При адресации по содержимому идентификатор задаёт, какие данные ожидаются, а получение может происходить из разных мест.

имя курса ─────→ выбранный выпуск
выпуск ────────→ конкретное содержание
содержание ────→ один или несколько хранителей

Первая стрелка изменяема по редакционной политике. Вторая должна сохранять точные байты объявленного выпуска. Третья относится к доступности. Такое разделение позволяет переместить копии, не меняя сам объект выпуска.

Что узнает читатель

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

В библиотеке доверенный издатель объявляет выпуск через подписанный манифест либо запись CourseCatalog. Реестр содержит согласованный отпечаток, а приложение получает файл и проверяет его. IPFS помогает найти и идентифицировать объект, но сам не объявляет, что его создала наша редакция.

Авторство, целостность и доступность являются разными свойствами. Правильный CID может указывать на файл, которого сейчас никто доступный не хранит. Хорошо работающий HTTP-сервер может выдавать данные без собственной проверки CID. Подписанный документ может быть подлинным, но устаревшим для текущей страницы курса.

Собственная структура выпуска

Подготовим каталог:

course-17-edition-1/
  index.html
  assets/site.css
  lessons/01-introduction.html
  release.json

Это структура нашего примера, пока без вычисленных CID. Она помогает заранее увидеть зависимости. Если index.html обращается к стилю на изменяемом внешнем URL, его вид может поменяться без изменения самого HTML. Поэтому «неизменный файл» и «неизменный визуальный выпуск» не всегда совпадают.

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

Название edition-1 удобно человеку, но не является криптографическим идентификатором. Два издателя могут дать разным материалам одинаковое название. Приложение сохраняет одновременно читательское имя версии и точное обязательство относительно содержания.

Исправления без перезаписи

Во втором выпуске редакция исправляет абзац и добавляет урок. Старый набор продолжает существовать как прежний объект, а новый получает свой идентификатор. Страница «текущая версия» может переключиться на второй выпуск по отдельной политике.

Для читателя старой ссылки важно, что она не начинает неожиданно отдавать другой набор под тем же идентификатором содержания. Однако хранитель может прекратить отдавать старые данные. Неизменность идентичности не является обязательством хранить файл вечно. Это потребует pinning, собственных архивов и операционного договора.

Откат указателя также не удаляет новый выпуск из чужих копий. Если материалы уже распространились, редакция может перестать рекомендовать их, но не гарантирует физическое исчезновение всех экземпляров. Для чувствительной информации такое свойство нужно учитывать до публикации.

Куда подходит IPFS

Для библиотеки полезны опубликованные учебные выпуски, проверяемые архивы и перенос между хранителями. Для персональных данных читателя нужна другая модель доступа и, при распространении контейнера, шифрование. Случайно опубликованный открытый файл не станет закрытым оттого, что его CID перестали показывать в меню.

Использование IPFS не требует, чтобы весь основной сайт переехал на другой способ выдачи. Можно сохранить привычные URL ProfessorWeb и добавить проверяемые выпуски как отдельный маршрут. Доменное имя и серверные функции продолжают обслуживать поиск, личные кабинеты и оплату.

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

Три разных неполадки одного выпуска

Представим три обращения читателя к первой редакции. В первом редакция правильно объявила манифест, но единственный хранитель выключен. Клиент знает ожидаемые данные, однако получить их не может. Сообщение «выпуск временно недоступен» соответствует этому состоянию. Подменять его сообщением «файл повреждён» нельзя: для такого вывода приложение должно увидеть и исследовать ответ. Уже эта разница влияет на кнопку повторного получения и обращение к другой копии.

Во втором обращении сервер быстро отдаёт полный учебник и собственный CID. Но этот идентификатор не связан с объявлением библиотеки. Данные могут быть внутренне согласованными, не являясь нашим выпуском. Поэтому доступность здесь высокая, а доверенная принадлежность не установлена. Приложение не должно автоматически считать первый доступный ответ «самой свежей редакцией». Скорость сервера не создаёт полномочий издателя.

В третьем случае читатель открыл сохранённую ссылку первой редакции после выхода второй. Проверка первой проходит, файлы доступны, но текущая страница рекомендует другую версию. Это нормальный архивный маршрут, если пользователь выбрал его сознательно. Интерфейс может показать «редакция 1; есть редакция 2», оставив текст первой неизменным. Автоматическая замена лишила бы читателя возможности воспроизвести старый пример.

Для досье библиотеки запишем результат каждого обращения отдельными полями: объявление установлено, байты получены, целостность подтверждена, редакция выбрана. Одно итоговое слово «работает» слишком грубо для этих случаев. В будущем журнал может содержать время наблюдения и источник выдачи, но они относятся к получению, а не меняют сами материалы. Эта модель станет основой разделов о хранителях, реестре и обновлениях. Она также позволяет сохранить привычную страницу курса: доменный URL выбирает маршрут, а конкретный выпуск отвечает за точность воспроизводимого содержимого.

Досье первого шага

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

Основы изложены в документации адресации IPFS и объяснении файловых структур. В следующих уроках разберём CID и UnixFS. Уже сейчас можно отделить три вопроса: какой выпуск объявлен, какие байты ожидаются и кто способен их выдать.

Оглавление серии