ADAMANT IPFS Node v0.1.0は、ADAMANTのセルフホスト型ファイル配信サービスの初のタグ付きリリースであり、公開コンテナイメージです。コンテンツアドレッシング、REST API、制御されたピアツーピア配信、ストレージポリシー、レプリケーション、修復、およびヘルスチェック機能を単一のNode.jsアプリケーションにパッケージ化しています。ADAMANT Messengerではすでにこのインフラストラクチャを添付ファイル用に使用しており、今回のリリースにより、他の開発者がより容易に評価、デプロイ、および適応できるようになりました。
アプリケーション所有のファイル
統合は、POST /api/file/upload を介したファイルのアップロードと、GET /api/file/:cid を介した取得という2つのアクションから始まります。返されるコンテンツ識別子（CID）はサーバーアドレスではなくコンテンツ自体から導出されるため、アプリケーションはどのマシンがファイルを配信すべきかを決定することなく、その識別子を受信者に渡すことができます。ノードはローカルコピーをストリーミングするか、それを保持すべき設定済みのピアからコンテンツを取得します。
これは、メッセンジャーの添付ファイル、不変のアプリケーションメディア、およびクライアントがすでにコンテンツ識別子を交換しているサービスに適しています。ADAMANT Messengerでは、クライアントが暗号化された添付ファイルをアップロードし、メッセージ内にそのCIDを保持し、受信者が自身のノードを通じてそれを取得します。暗号化はクライアントプロトコルの役割であり、ストレージサービスは受信したバイトデータを処理するだけです。
明示的な運用ルールを持つメッシュ
このノードは、Heliaとlibp2pを使用して直接構築されています。HTTP APIと並行して組み込みのIPFSスタックを実行し、TCPトランスポート、ピア接続用のNoise暗号化、およびYamuxストリーム多重化を使用します。
運用者はピアセットを設定します。ランデブーハッシュ（Rendezvous hashing）は各CIDの保持者をランク付けするため、同じメンバーシップを持つノードは同じ配置を導出します。経過時間ベースの階層により、デプロイメントはファイルの経過時間に応じてターゲットのコピー数を削減できます。再開可能な修復サイクルは、欠落しているコピーをチェックし、コンテンツが復旧可能な場合に意図した配置の復元を試みます。これにより、配置と修復がファイルを受信・配信するサービスと統合され、既知の相互設定されたノード群を基盤とする場合に、個別のピンオーケストレーションサービスが不要になります。
v0.1.0のライフサイクル：取り込み、決定論的配置、修復と取得、そしてストレージ制限とヘルスレポーティング。
有限のディスクには適切なポリシーが必要
ストレージ制御は取り込みパスの一部です。ディスク予約、集計リクエスト制限、ファイル制限、および同時転送の許可設定により、ノードは安全に受け入れられない作業を拒否できます。オプションのテンポラリアップロードはTTL後に期限切れにすることができ、ガベージコレクションはウォーターマークとライフサイクルレジストリを使用して対象データを再利用します。
確認済みのコンテンツは保護されます。確認済みファイルが利用可能な容量を占有している場合、許可制限が重要になります。ストレージが制限されているからといって、ポリシーで保持が必要とされているファイルを黙って削除することはありません。運用者は保持およびレプリケーションのポリシーを選択し、容量をプロビジョニングし、結果を監視します。ストレージの動作は、デプロイメントの容量が不足した場合の挙動を含め、検査および設定が可能です。
オープンな接続を超えた信頼性
今回のリリースには、微妙なメッシュ障害に対する修正が含まれています。アプリケーションのストリームが停止しても、TCP接続が維持されてしまうという問題です。以前のピアリングロジックでは、接続されたピアを認識し、停止したセッションをそのまま放置する可能性がありました。PR #40では生存確認（liveness checks）とリアクティブなセッションリカバリが追加されました。PR #42ではそのパスがさらに強化され、同時リカバリ操作が統合され、失敗したストリームは成功したpingによって拒否されることなくリセットをトリガーでき、配置は新しい接続で1回再試行できるようになりました。
ヘルスレポーティングも同じ原則に従います。GET /api/node/health は、開始中、準備完了、失効、または劣化といった状態を、永続化されたチェックポイントの高さおよびメンバーシップ情報とともに公開します。この高さは、必要なチェックに合格すると進み、失敗すると停止します。高さは同じメンバーシップバージョン内でのみ比較可能です。運用者はHTTP 200に頼るだけでなく、この状態を読み取る必要があります。オプションの修復バックログ猶予期間により、設定された回数の失敗した修復サイクルを許容できますが、バックログとサイクルの結果は監視用に可視化されたままとなります。デフォルトでは猶予は与えられません。
デスクトップおよびTorクライアントの統合
v0.1.0にはCORSの改善が含まれており、運用者はデスクトップの app://. オリジンや適切なonionオリジン（Tor Browserのリクエストが送信する不透明なnullオリジンを含む）を明示的に許可できます。アップロードおよび許可の失敗には、機械可読な安定したエラーコードが含まれるようになり、クライアントは文章を解析することなく、レート制限、同時実行制限、ストレージ不足、レプリケーションクォーラムの失敗、タイムアウトを区別できるようになりました。CORSはブラウザの互換性制御のままであり、デプロイメントには依然としてアプリケーションに適した認証および公開ポリシーが必要です。
デプロイメント
パブリックコンテナはlinux/amd64およびlinux/arm64で利用可能です：
docker pull ghcr.io/adamant-im/ipfs-node:0.1.0イメージは非特権ユーザーとして実行され、SBOMとビルドの出所証明（attestation）を備えています。設定は /app/config.json5 に個別にマウントされます。単一の /data ボリュームが、ブロックストア、データストア、ピアID、ピンセット、ライフサイクルレジストリ、修復カーソル、およびヘルスチェックポイントを保持し、コンテナの入れ替え時にも永続的な状態を維持します。リリースパイプラインは両方のアーキテクチャを再プルしてスモークテストを行い、起動、準備完了、アップロードとダウンロード、クリーンなシャットダウン、そして入れ替え時のコンテンツとピアIDの保持を確認します。
評価の際は、ネットワークに参加しない docker/config.example.json5 から始めてください。本番環境のテンプレートにはADAMANTのピアリストが含まれています。独自のデプロイメントでは、独自のピアとブラウザオリジンを定義する必要があります。HTTPサービスは、適切に設定されたHTTPSリバースプロキシの背後に配置してください。
アーキテクチャの境界
設定されたトポロジーは、パブリックDHTアナウンスやパブリックゲートウェイのルーティングを回避し、コンテンツルーティングメタデータの公開を低減します。これ自体がデプロイメントを匿名化したり機密性を確保したりするわけではありません。このサービスは保存されたファイルを暗号化せず、アップロードとダウンロードは設計上認証されません。機密性や認証されたアクセスを必要とするアプリケーションは、ストレージ層の上位でそれらの制御を提供する必要があります。
本リリースには、パブリックIPFSの相互運用性、IPNS、パブリックゲートウェイ、またはKubo互換のAPIは含まれていません。ここに保存されたコンテンツはパブリックネットワークにはアナウンスされず、パブリックピアのみが保持するコンテンツをこのノードを通じて取得することはできません。アップローダーによる署名付き削除、動的なピア探索、およびトラフィックアカウンティングは、今後の課題として残されています。
既知のピアセットとコンテンツアドレッシングされたアプリケーション配信において、これらの選択は焦点を絞った運用モデルを形成します。パブリックIPFSへの参加、動的なフリート、またはS3スタイルのIDおよびアクセス制御が必要な場合は、ストレージアーキテクチャを選択する前に比較ガイドを参照してください。