Допустим, пользователь сохранил документальный фильм в медиатеке. Через месяц название, обложка и описание на месте, но воспроизведение не начинается. Для пользователя материал сломан; для разработчика запись каталога может быть исправна, а настоящая проблема — отключившийся источник файла.
Такой сбой показывает три разных вопроса: можно ли найти контент, верны ли полученные данные и можно ли получить их сейчас? Объединение всего в статус «опубликовано» заставляет интерфейс обещать больше, чем способна обеспечить система.
Каталог описывает контент, а файлам нужны источники
Названия, авторы, каналы, теги и связи версий образуют каталог. Публичная документация GUN описывает графовые данные и синхронизацию состояния между узлами в реальном времени. Подобные инструменты помогают приложениям организовывать и синхронизировать связи. Описание GUN
Доставка файлов ставит другие вопросы: кто хранит полную копию, какие узлы доступны, удаётся ли соединиться и получить недостающие части? Запись в каталоге сама по себе не обеспечивает ни одного из этих условий.
Мы рекомендуем показывать состояние каталога отдельно от возможности получения файла. Пользователь может сохранить запись заранее, но страница должна сообщать, проверялась ли доступность недавно. «Последнее успешное получение» и «источник доступен сейчас» требуют разных формулировок: исторический результат не является текущей гарантией.
Это помогает и при диагностике. Если каталог синхронизируется, а файл недоступен, сначала проверяйте хранение и передачу. Если файл получен, но версия неверная, проверяйте соответствие записи идентификатору контента. Эти проблемы требуют разных исправлений.
Адресация по содержимому решает задачу идентификации
IPFS использует CID для идентификации контента. CID содержит сведения о хешировании и кодировании; это не просто обычная строка SHA-256 произвольного файла. Организация данных тоже может влиять на итоговый идентификатор. Адресация в IPFS
В медиакаталоге полезно явно связывать отображаемую информацию с определённой версией файла. Изменение описания может затрагивать только каталог. При новом монтаже видео сохраняйте связь старой и новой версий, чтобы закладки, комментарии и результаты проверки относились к нужному материалу.
Успешная проверка повышает уверенность в целостности данных, но сама не устанавливает автора, действительность лицензии или пригодность контента для пользователя. Не превращайте один вид проверки в универсальный значок «доверено». Показывайте доказательства именно заявленного свойства.
Долговременное хранение требует постоянной организации
Документация IPFS разделяет адресацию по содержимому и долговременное хранение и описывает сохранение данных, включая pinning. Даже хранящему контент узлу нужны подходящий режим доступности и обслуживание. Долговременное хранение IPFS
Поэтому публикация должна включать реальный план хранения: кто поддерживает полные копии, как долго, кто продолжит работу после окончания услуги и как передать ответственность при уходе сопровождающего. Запись об успешной загрузке не отвечает на вопросы через несколько месяцев.
Как минимум проверьте общие зависимости копий. Два адреса могут вести к одному аккаунту, устройству или поставщику. Несколько источников в записи не гарантируют, что остальные переживут отказ одного.
Для редко востребованного контента бюджеты хранения и кеширования популярных материалов можно разделить. Кеш подстраивается под спрос, а долговременное хранение требует ответственного. «Сейчас никто не смотрит» не означает «больше не стоит хранить».
Проверки доступности должны получать реальные данные
Этот порядок может стать отправной точкой; частоту определяйте по объёму контента и целям сервиса:
- Прочитайте из каталога версию файла, идентификатор и возможные источники.
- Установите соединение и получите реальные данные, не ограничиваясь успешным ответом API каталога.
- Проверьте данные по правилам протокола. Выборка подтверждает только проверенные части, а не весь файл.
- Запишите время, успешный источник, причину ошибки и объём проверки.
- При сокращении источников или постоянных ошибках добавьте копии либо явно покажите состояние пользователю.
Выделите проверкам собственный бюджет трафика. Одновременное полное скачивание большой коллекции может сделать систему проверки главным потребителем ресурсов. Лёгкие пробы, проверки воспроизведения и периодическое полное восстановление можно распределять по уровням, явно указывая, что подтверждает каждый.
Тайм-аут, недостаток прав, отзыв публикации и ошибка целостности — не одно и то же «файл потерян». Различия помогают выбрать повтор, запрос доступа, исправление копии или соблюдение решения автора об отзыве.
Покажите пользователю следующий шаг
Бесконечный индикатор загрузки почти не помогает действовать. Лучше объяснить этап: поиск источников, соединение, временная недоступность или отклонение данных, не прошедших проверку.
Если просмотр не начинается, пользователь должен понимать, стоит ли повторять попытку, есть ли другой источник и можно ли оставить закладку. Форма сообщения об ошибке может включать идентификатор контента и категорию сбоя, не заставляя пользователя пересказывать все действия.
В публичной архитектуре AlphaBiz упомянуты GUN и WebTorrent. Поэтому разделение каталога и передачи медиа актуально для проектирования. Предложенные здесь методы предназначены для оценки и не означают, что конкретная стратегия мониторинга или копирования уже реализована. Описание AlphaBiz
Начните с восстановления одного материала: отключите исходный источник и попробуйте вернуть доступ через сохранённый каталог и копии. Такой результат убедительнее красивой записи, которая всегда видна. Поделитесь устройством проверок и их охватом в AlphaBiz Discussions.