In traditional cloud storage (Location Addressing), you ask for a file by its location (e.g., /us-east-1/my-bucket/file.jpg). You have to trust that the server at that location returns the correct file and that it hasn't been tampered with or corrupted.
Filebase, built on IPFS, uses Content Addressing. This shifts the paradigm from "trusting the location" to "trusting the math." When you store data with us, you are guaranteed that every byte you retrieve is exactly what you uploaded.
The Power of the CID
At the heart of this system is the Content Identifier (CID). A CID is not just a random ID; it is a cryptographic hash of the content itself.
- Fingerprint: The CID is generated by running the file's data through a hashing algorithm (like SHA-256).
- Unique: No two different files can produce the same CID (collision is statistically impossible).
- Deterministic: The same content will always produce the same CID, regardless of who uploads it or when.
// The CID is a fingerprint of the data
// If you change one byte, the CID changes completely.
Original: "Hello World"
CID: QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u
Modified: "Hello Worlds"
CID: QmZ4tDuvesekSs4CKKC32J16aprRFgbu86697nF2z9y1gGImmutability & Versioning
Because the address is derived from the content, data on IPFS is immutable by default. You cannot "edit" a file in place.
If you update a file (e.g., fix a typo in a text file), the new content produces a new CID. This creates a built-in, tamper-proof version history.
Filebase handles this complexity for you. When you "overwrite" a file in a Filebase bucket, we update the pointer to the new CID, but the old data remains accessible via its original CID if needed (until unpinned).
Verification: Don't Trust, Verify
The biggest advantage of this architecture is trustless verification. You don't need to take our word that a file is intact. You can verify it yourself.
When you download a file via its CID, your client can hash the incoming bytes. If the resulting hash matches the CID you requested, you have mathematical proof that the file is 100% authentic and uncorrupted.
# Verify a file's integrity locally using IPFS CLI
ipfs add -n --cid-version 1 my-file.png
# Output should match the CID provided by Filebase
# added bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi my-file.pngMultihash & Future Proofing
IPFS uses a format called Multihash. A CID starts with a prefix that tells the system which hashing algorithm was used (e.g., sha2-256).
This makes the system future-proof. If SHA-256 is ever compromised in the future, the network can switch to a stronger algorithm (like SHA-3 or BLAKE3) without breaking existing links or requiring a platform-wide migration.
Why This Matters
For developers and enterprises, this provides critical guarantees:
- Supply Chain Security: Verify that build artifacts and dependencies haven't been altered.
- NFT Metadata: Ensure digital assets are permanent and unchangeable.
- Legal & Archival: Prove that a document exists in a specific state at a specific time.