ADAMANT IPFS Node v0.1.0

Dies ist das erste getaggte Release des ADAMANT IPFS Node und das erste veröffentlichte Container-Image. Es handelt sich um einen selbst gehosteten IPFS-Speicherknoten für die Bereitstellung von Anwendungsdateien mit begrenzter Festplattennutzung, deterministischer Replikation, Reparaturfunktionen, Integritätsprüfungen und einer REST-API. Der Dienst basiert eigenständig auf Node.js und Helia und ist kein Wrapper für Kubo.

Ausführung

docker volume create ipfs-node-data

docker run -d \
  --name ipfs-node \
  --restart unless-stopped \
  --stop-timeout 20 \
  -v ipfs-node-data:/data \
  -v "$PWD/config.json5:/app/config.json5:ro" \
  -p 127.0.0.1:4000:4000 \
  -p 4001:4001 \
  ghcr.io/adamant-im/ipfs-node:0.1.0

Das Image enthält keine Konfiguration; binden Sie eine unter /app/config.json5 ein. Da HOME auf /data gesetzt ist, speichert ein einziges /data-Volume den Blockstore, den Datastore, die libp2p-Peer-Identität, das Pin-Set, die Lifecycle-Registrierung, den Reparatur-Cursor sowie die Integritätsprüfungen. Die Datei docker/config.example.json5 im Repository dient als eigenständiger Ausgangspunkt, der keinem Netzwerk beitritt. Das Image wurde für linux/amd64 und linux/arm64 erstellt, läuft als nicht privilegierter Benutzer und wird mit einem SBOM sowie einer Herkunftsbescheinigung (Provenance Attestation) bereitgestellt.

Funktionsumfang

Der Knoten ermöglicht den REST-Upload von Multipart-Dateien sowie den inhaltsadressierten Download per CID. Er unterhält ein kontrolliertes Peer-Mesh über TCP mit Noise und Yamux und registriert ausschließlich die Protokolle identify und ping. Der Speicherlebenszyklus wird durch Festplattenreservierungen, aggregierte Anfragelimits, temporäre Uploads mit TTL sowie eine wasserzeichengesteuerte Garbage Collection begrenzt. Die Platzierung erfolgt deterministisch mittels Rendezvous-Hashing, wobei die Kopienanzahl mit zunehmendem Alter einer Datei abnimmt. Die knotenübergreifende Replikation und ein fortsetzbarer Reparaturzyklus arbeiten über ein libp2p-Protokoll, das durch den Handshake authentifiziert wird. Netzwerkbewusste Integritätsprüfungen führen eine monotone Höhe und eine explizite Mitgliedschaftsepoche mit sich. Für gleichzeitige Uploads und Downloads gelten Endpunkt-spezifische Ratenbegrenzungen und eine Zugangskontrolle.

Einschränkungen

Es gibt kein DHT, kein IPNS, kein öffentliches Gateway und keine Kubo-API. Hier gespeicherte Inhalte werden nicht im öffentlichen IPFS-Netzwerk angekündigt, und Inhalte, die nur im öffentlichen Netzwerk existieren, können nicht über diesen Knoten abgerufen werden. Eine kontrollierte Peer-Topologie reduziert die öffentliche Sichtbarkeit von Content-Routing-Metadaten, macht eine Bereitstellung jedoch nicht von sich aus privat, anonym, vertrauenslos oder zensursicher. Upload und Download sind konzeptionsbedingt nicht authentifiziert; die einzige Anmeldeinformation ist ein administrativer Schlüssel. Die Implementierung von Uploader-signierter Löschung (#27), Peer-Discovery (#28), Traffic-Accounting (#29), einem absoluten Datenverzeichnis (#30) sowie der Interoperabilität mit dem öffentlichen Netzwerk (#31) ist noch in Arbeit.