Identyfikatory treści (CID)

Unikalny odcisk palca, który otrzymuje każdy plik IPFS.

Czym jest CID?

Identyfikator treści (CID) to samoopisowa etykieta, która jednoznacznie identyfikuje dane na IPFS. Pochodzi z kryptograficznego hasha zawartości pliku, w połączeniu z metadanymi o algorytmie hashowania i formacie kodowania.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

CID-y zaczynające się od bafy (lub bafk dla małej, jednoblokowej treści) używają CIDv1, nowoczesnego samoopisowego formatu. Starsze CID-y zaczynające się od Qm używają CIDv0 (SHA-256 zakodowany w base58) — nadal ważne, nadal rozwiązywalne, ale już nie domyślne wyjście dla nowej treści.

Kluczowe właściwości

• Deterministyczny — Ten sam plik zawsze tworzy ten sam CID. Prześlij ten sam obraz dwa razy i otrzymasz ten sam identyfikator.
• Unikalny — Nawet zmiana jednego bajtu tworzy zupełnie inny CID. To czyni CID odpornymi na manipulację.
• Samoweryfikujący — Każdy, kto otrzyma plik, może ponownie obliczyć hash i potwierdzić, że pasuje do żądanego CID.
• Niezmienny — CID zawsze wskazuje na tę samą treść. Nie możesz zmienić, na co CID rozwiązuje.

CID w IPFS.NINJA

Każdy przesłany plik zwraca CID w odpowiedzi API. Użyj go do:

• Dostępu do pliku przez bramkę: ipfs.ninja/ipfs/<CID>
• Pobrania metadanych pliku: GET /file/<CID>
• Odwołania do treści on-chain (NFT, smart kontrakty)
• Udostępniania komukolwiek — mogą zweryfikować, że treść się zgadza

CIDv0 vs CIDv1

Właściwość	CIDv0	CIDv1
Prefiks	Qm...	bafy... (dag-pb, katalogi i pliki wieloblokowe), bafk... (raw, mała jednoblokowa treść), oraz inne w zależności od kodeka
Funkcja hashująca	Tylko SHA-256	Wiele (SHA-256, Blake2b, itp.)
Kodowanie	Base58 (mieszana wielkość liter)	Multibase — domyślnie base32 (małe litery, bezpieczne dla DNS)
Samoopisowy	Nie	Tak (zawiera codec + info o hashu)
Chunker	Starszy domyślny 256 KiB	1 MiB zgodnie z IPIP-0499
Kodowanie liści	Opakowane w dag-pb	Surowe bajty (raw-leaves=true)

Co emituje IPFS.NINJA

Przesłania i przypięcia wykonane po 2026-07-13 zwracają domyślnie CIDv1: kodowanie base32 CIDv1, fragmenty 1 MiB, surowe liście (raw leaves) — profil IPIP-0499 unixfs-v1-2025. Praktyczne konsekwencje:

• Małe pliki (≤ 1 MiB) wracają jako bafk... (raw, jednoblokowy CIDv1)
• Większe pliki i katalogi wracają jako bafy... (dag-pb CIDv1)
• Plik przesłany przez nas otrzymuje ten sam CID, jaki obliczyłoby dowolne nowoczesne narzędzie (Helia, najnowsze Kubo, ipfs-car) z tych samych bajtów

Kompatybilność wsteczna

Starsze CID-y Qm... z wcześniejszych przesłań pozostają w pełni rozwiązywalne — bramka, POST /pin, GET /file/:cid, resolvery IPNS i każdy inny endpoint akceptują oba formaty bezterminowo. Jeśli masz CID Qm... z wcześniejszego przesłania, nic z tego, co zbudowałeś, nie przestaje działać.