Over the years IPFS has had one particularly difficult challenge: dynamic content. One of the main reasons to use IPFS is its immutability and content addressability, but there are the occasional moments when an app needs dynamic content. IPNS (InterPlanetary Name Service) has been the go-to method for dynamic and mutable content on IPFS, as it uses a name system to resolve and point to new CIDs. While it is native to the IPFS network, it has also been known to be slow and hard to work with. IPFS also isn’t onchain and lacks the identity credentials you gain with blockchain. This is why we built IPCM: InterPlanetary CID Mapping. In a previous post, we gave some of the basics of how it works as an alternative to IPNS, but in this post we’ll go into some of the core differences between IPCM and IPNS, and how IPCM wins in every case.

Credentials

When it comes to credentials and who is allowed to update a CID mapping, IPNS uses its own native key-pair system that is generated from the IPFS node instance. The downside of this approach is it requires running an IPFS node in the first place and it detaches the mapping reference from a user’s onchain identity. IPCM on the other hand uses blockchain credentials and identity mechanisms to control the state and ownership of the smart contract.

This is a popular approach in blockchains - thanks to protocols like ENS - which tie onchain actions and contracts to an onchain identity. By using the OpenZeppelin Ownable standard, IPCM can easily lock down and protect functions like updateMapping as well as transfer ownership of the contract to another identity.

Version History

In a system where changes are being made, it is critical to track the history of those changes and when they happened. It’s one of the reasons blockchains exists: to create an immutable ledger. When you update CID mappings on IPNS, there is nothing that’s part of the protocol to track the updates in order to create a version history. In order to have a version history on IPNS, you would need to run a server and database to track the changes (and hopefully not miss any), and even then it’s not immutable or has the ability to be audited.

IPCM uses smart contract events that emit logs which are recorded on the blockchain it’s deployed to. By doing this, the events can easily be indexed at anytime to create a robust, timestamped and cryptographically secured version history of the CID mappings for that contract. Even events like transferring the contract to a new owner are emitted and can be indexed!

Speed

One of the biggest problems with IPNS is the speed. When a CID mapping update is made, IPNS has to publish those changes with transports like the DHT or PubSub which takes time to propagate across the IPFS network. Since IPCM doesn’t rely on any IPFS native peer-to-peer publishing, it can provide the latest CID of the content which can be fetched immediately. The only limitation to IPCM is the blockchain it’s deployed to, and with the advancements of L2 chains like Base, an update and retrieval of the state can be done very quickly with little to no cost.

Wider Support

In order for IPNS to work, it requires specific IPFS infrastructure, which can be more of a hassle to maintain and make efficient. IPCM on the other hand is a lightweight contract that can be deployed to any EVM chain with ease and little to no maintenance. By using standard libraries like Viem with a public RPC, users can get an API like experience to update and read the CID state of the contract.

import { account, publicClient, walletClient } from "./config";
import { abi } from "./ipcm_abi";

// Updating the mapping
const { request } = await publicClient.simulateContract({
  account,
  address: "0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2",
  abi: abi,
  functionName: "updateMapping", // Function to Update
  args: ["bafkreigfakpjywuxaq57zhnnma6ntvs6u5p6eurgdl5kfkjvuhg6sztmda"], // IPFS CID args
});
await walletClient.writeContract(request);

// Reading the mapping
const data = await publicClient.readContract({
  address: "0xFBA3912Ca04dd458c843e2EE08967fC04f3579c2",
  abi: abi,
  functionName: "getMapping",
});

Wrapping Up

While IPCM is relatively new, we’re already seeing adoption and usage in multiple areas, including websites hosted on IPFS. We’re also doing some research and development for custom ENS resolver contracts so a user’s ENS contentHash can be dynamic and point to their IPCM contract. If you’re curious yourself, be sure to check out the GitHub repo and sign up for a free Pinata account to upload some content. We can see so many possibilities for IPCM and we’re just getting started.

Happy Pinning!