ADAMANT IPFS Node v0.1.0 — это первый релиз с тегом и опубликованный образ контейнера для самохостируемого сервиса доставки файлов ADAMANT. Он объединяет в одном приложении Node.js функции адресации контента, REST API, контролируемую одноранговую (P2P) доставку, политики хранения, репликацию, восстановление и проверку состояния. ADAMANT Messenger уже использует эту инфраструктуру для вложений; данный релиз упрощает другим разработчикам задачу оценки, развертывания и адаптации этого решения.
Файлы, принадлежащие приложению
Интеграция начинается с двух действий: загрузка файла через POST /api/file/upload и его получение через GET /api/file/:cid. Идентификатор контента (CID) формируется на основе самого содержимого, а не адреса сервера, поэтому приложение может передать этот идентификатор получателю, не задумываясь о том, какая именно машина должна предоставить файл. Узел может транслировать локальную копию или извлекать контент из настроенных узлов-партнеров, которые должны его хранить.
Это решение подходит для вложений в мессенджерах, неизменяемых медиафайлов приложений и сервисов, клиенты которых уже обмениваются идентификаторами контента. В ADAMANT Messenger клиент загружает зашифрованное вложение, передает его CID в сообщении, а получатель забирает файл через свой узел. Шифрование относится к протоколу клиента; сервис хранения обрабатывает только полученные байты.
Сеть с четкими правилами работы
Узел построен непосредственно на базе Helia и libp2p. Он запускает встроенный стек IPFS параллельно с HTTP API, используя транспорт TCP, шифрование Noise для соединений между узлами и мультиплексирование потоков Yamux.
Операторы настраивают набор узлов. Хеширование Rendezvous ранжирует владельцев для каждого CID, поэтому узлы с одинаковым составом участников приходят к одинаковому размещению данных. Уровни на основе возраста позволяют развертыванию сокращать целевое количество копий по мере «старения» файла. Цикл восстановления с возможностью возобновления проверяет наличие отсутствующих копий и пытается восстановить целевое размещение, пока контент остается доступным для восстановления. Это сочетает размещение и восстановление с сервисом, который принимает и доставляет файлы, устраняя необходимость в отдельном сервисе оркестрации пинов при построении системы на основе известного, взаимно настроенного набора узлов.
Жизненный цикл v0.1.0 вкратце: прием, детерминированное размещение, восстановление и извлечение, с постоянным контролем лимитов хранения и отчетностью о состоянии.
Ограниченные диски требуют реальной политики
Средства управления хранилищем являются частью пути приема данных. Резервы дискового пространства, совокупные лимиты запросов, ограничения на количество файлов и допуск одновременных передач помогают узлу отклонять работу, которую он не может безопасно выполнить. Дополнительные временные загрузки могут истекать по TTL; сборка мусора использует водяные знаки и реестр жизненного цикла для освобождения подходящих данных.
Подтвержденный контент остается защищенным. Когда подтвержденные файлы занимают доступную емкость, лимиты допуска имеют значение: ограниченное хранилище не означает молчаливое удаление файлов, которые, согласно политике, должны оставаться сохранными. Операторы выбирают политику хранения и репликации, выделяют емкость и контролируют результаты. Поведение хранилища можно проверять и настраивать, включая действия системы при нехватке места.
Надежность за пределами открытого соединения
Релиз включает исправления для скрытой ошибки сети: TCP-соединение может оставаться активным, в то время как потоки приложения перестают работать. Предыдущая логика пиринга могла видеть подключенный узел и оставлять зависшую сессию без внимания. PR #40 добавляет проверки активности и реактивное восстановление сессий. PR #42 еще больше укрепляет этот путь: операции параллельного восстановления объединяются, неудачные потоки могут инициировать сброс без блокировки успешным пингом, а размещение может повториться один раз при новом соединении.
Отчетность о состоянии следует тому же принципу. GET /api/node/health раскрывает состояния «запуск», «готов», «устарел» или «деградировал», а также сохраненную высоту контрольной точки и информацию о членстве. Высота увеличивается, когда проходят необходимые проверки, и замирает при их провале; высоты сравнимы только в рамках одной версии членства. Операторам следует считывать это состояние, а не полагаться только на HTTP 200. Опциональный льготный период для очереди восстановления позволяет игнорировать заданное количество неудачных циклов восстановления, при этом очередь и результаты циклов остаются видимыми для мониторинга. По умолчанию льготный период отсутствует.
Интеграция с настольными клиентами и Tor
Версия v0.1.0 включает работу с CORS, позволяющую операторам явно разрешать источник app://. настольного приложения и соответствующие onion-источники, включая непрозрачный null-источник, который отправляют некоторые запросы Tor Browser. Ошибки загрузки и допуска теперь включают стабильные машиночитаемые коды, позволяющие клиентам различать ограничение скорости, лимиты параллелизма, нехватку места, сбои кворума репликации и тайм-ауты без анализа текстовых сообщений. CORS остается инструментом контроля совместимости браузеров; развертывания по-прежнему требуют политики авторизации и доступа, соответствующей их приложению.
Развертывание
Публичный контейнер доступен для linux/amd64 и linux/arm64:
docker pull ghcr.io/adamant-im/ipfs-node:0.1.0Образ запускается от имени непривилегированного пользователя и содержит SBOM и аттестацию происхождения сборки. Конфигурация монтируется отдельно в /app/config.json5. Единый том /data содержит хранилище блоков, хранилище данных, идентификатор узла, набор пинов, реестр жизненного цикла, курсор восстановления и контрольную точку состояния, сохраняя постоянное состояние при замене контейнера. Конвейер релиза повторно извлекает и тестирует оба типа архитектуры, проверяя запуск, готовность, загрузку и выгрузку, корректное завершение работы, а также сохранение контента и идентификатора узла при замене.
Для оценки начните с docker/config.example.json5, который не присоединяется ни к одной сети. Шаблон для продакшена содержит список узлов ADAMANT; ваше собственное развертывание должно определять свои узлы и источники браузера. Держите HTTP-сервис за правильно настроенным обратным прокси-сервером HTTPS.
Архитектурные границы
Настроенная топология позволяет избежать публичных объявлений DHT и маршрутизации через публичные шлюзы, снижая публичное раскрытие метаданных маршрутизации контента. Само по себе это не делает развертывание анонимным или конфиденциальным. Сервис не шифрует сохраненные файлы; загрузки и выгрузки по дизайну не требуют аутентификации. Приложения, требующие конфиденциальности или аутентифицированного доступа, должны обеспечивать эти элементы контроля поверх уровня хранения.
В этом релизе нет публичной совместимости с IPFS, IPNS, публичными шлюзами или API, совместимым с Kubo. Контент, хранящийся здесь, не анонсируется в публичной сети, и контент, удерживаемый только публичными узлами, не может быть получен через этот узел. Удаление, подписанное загрузчиком, динамическое обнаружение узлов и учет трафика остаются в работе.
Для известного набора узлов и доставки контента с адресацией по содержимому этот выбор формирует сфокусированную операционную модель. Для участия в публичной сети IPFS, работы с динамическим парком узлов или использования контроля доступа в стиле S3, ознакомьтесь с руководством по сравнению перед выбором архитектуры хранения.