Content Identifiers (CIDs)

Der einzigartige Fingerabdruck, den jede IPFS-Datei erhält.

Was ist ein CID?

Ein Content Identifier (CID) ist ein selbstbeschreibendes Label, das ein Datenstück auf IPFS eindeutig identifiziert. Er wird aus dem kryptographischen Hash des Dateiinhalts abgeleitet, kombiniert mit Metadaten über den verwendeten Hash-Algorithmus und das Kodierungsformat.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

CIDs, die mit bafy beginnen (oder bafk für kleine Einzelblock-Inhalte), verwenden CIDv1, das moderne selbstbeschreibende Format. Ältere CIDs, die mit Qm beginnen, verwenden CIDv0 (base58-kodierter SHA-256) — weiterhin gültig, weiterhin auflösbar, aber nicht mehr die Standardausgabe für neue Inhalte.

Schlüsseleigenschaften

• Deterministisch — Dieselbe Datei erzeugt immer denselben CID. Laden Sie dasselbe Bild zweimal hoch und Sie erhalten denselben Identifier.
• Einzigartig — Selbst eine Änderung von einem Byte erzeugt einen völlig anderen CID. Das macht CIDs manipulationssicher.
• Selbstverifizierend — Jeder, der eine Datei empfängt, kann den Hash neu berechnen und bestätigen, dass er mit dem angeforderten CID übereinstimmt.
• Unveränderlich — Ein CID verweist immer auf denselben Inhalt. Sie können nicht ändern, worauf ein CID auflöst.

CIDs bei IPFS.NINJA

Jede hochgeladene Datei gibt einen CID in der API-Antwort zurück. Verwenden Sie ihn, um:

• Auf die Datei über das Gateway zuzugreifen: ipfs.ninja/ipfs/<CID>
• Datei-Metadaten abzurufen: GET /file/<CID>
• Inhalte on-chain zu referenzieren (NFTs, Smart Contracts)
• Mit anderen zu teilen — sie können überprüfen, ob der Inhalt übereinstimmt

CIDv0 vs CIDv1

Eigenschaft	CIDv0	CIDv1
Präfix	Qm...	bafy... (dag-pb, Verzeichnisse & Multi-Chunk-Dateien), bafk... (raw, kleine Einzelblock-Inhalte), sowie weitere je nach Codec
Hash-Funktion	Nur SHA-256	Mehrere (SHA-256, Blake2b usw.)
Kodierung	Base58 (gemischte Groß-/Kleinschreibung)	Multibase — standardmäßig base32 (Kleinbuchstaben, DNS-sicher)
Selbstbeschreibend	Nein	Ja (enthält Codec- + Hash-Informationen)
Chunker	256 KiB alter Standard	1 MiB gemäß IPIP-0499
Leaf-Kodierung	In dag-pb eingebettet	Rohe Bytes (raw-leaves=true)

Was IPFS.NINJA ausgibt

Uploads und Pins, die nach dem 13.07.2026 vorgenommen werden, geben standardmäßig CIDv1 zurück: CIDv1-base32-Kodierung, 1-MiB-Chunks, Raw Leaves — das IPIP-0499 unixfs-v1-2025-Profil. Praktische Auswirkungen:

• Kleine Dateien (≤ 1 MiB) kommen als bafk... zurück (raw Einzelblock-CIDv1)
• Größere Dateien und Verzeichnisse kommen als bafy... zurück (dag-pb-CIDv1)
• Eine bei uns hochgeladene Datei erhält denselben CID, den jedes moderne Tool (Helia, aktuelles Kubo, ipfs-car) für dieselben Bytes berechnen würde

Abwärtskompatibilität

Ältere Qm...-CIDs aus früheren Uploads bleiben vollständig auflösbar — das Gateway, POST /pin, GET /file/:cid, IPNS-Resolver und jeder andere Endpunkt akzeptieren beide Formate unbegrenzt weiter. Wenn Sie einen Qm...-CID aus einem früheren Upload haben, hört nichts, was Sie gebaut haben, auf zu funktionieren.