If you have been in the blockchain and crypto space, then there is a chance you've heard of IPFS and how it's used for offchain storage. In many ways, it's a perfect pairing: content on IPFS gets a hash that can be verified, it works as an address, and referencing it on blockchain provides a cryptographic-powered time stamp with identity built in. It's one of the reasons we built IPCM to solve the problem of dynamic onchain data. However, with all of its benefits, there are some quirks with using IPFS, and one of them is its public network.

IPFS is a peer-to-peer public network, which means that if you have an IPFS node, then you can fetch the content yourself without any interference. This is great for content you want to be public, but what about the content that needs to be private? A great example would be artists that want to sell a high quality version of their artwork through an NFT. The NFT metadata is public, so if there's a link to the high quality image, then it's also publicly accessible. Over the years, there have been several proposed solutions.

Traditional File Storage

One of the most popular approaches to solving private offchain storage is by simply using a traditional file storage provider like AWS S3. While it does provide security of the content and prevents unauthorized parties from accessing it, these providers also put the end user at risk. IPFS is being used for NFTs to help ensure content authenticity, because with something like S3, the owner of the bucket could change the file contents while keeping the name of the file the same, or just deleting the content outright. What is the point of creating digital assets if they cannot be verified? This is still an issue today, as many NFT and blockchain projects still use traditional file storage providers inside of smart contracts.

Encrypted Files on IPFS

To combat the issue of content authenticity and availability, another popular approach is encrypting the data before uploading it to IPFS. This is one we've actually done before in one of our tutorials, and it does have the benefits of being publicly available, verifiable, and only accessible to the authorized party… Sorta. The biggest issue with encryption on IPFS is that encryption is always changing; ciphers and hashes are constantly being broken as technology advances. Using encryption on IPFS content these days is riskier than ever as we approach the cusp of quantum computing, because content on IPFS can persist as long as it's pinned. If you have bad actors who are patient enough, it could mean having all of your "private" files being accessed as time goes on. What else is on the table?

Private IPFS

To truly solve the problem of private offchain storage, we need Private IPFS. It might sound like an oxymoron since IPFS is known for being a public peer-to-peer network, but it really isn't. If we break IPFS down into its core components and functionality, we get the following:

• Peer-to-peer connections with other nodes
• Content Addressing with CIDs
• Immutability

In a private IPFS model, we don't have to lose any of these, but one of the most important pieces is maintaining content addressing with CIDs. This is how we are able to reference a file on blockchain so it can be verified and assured as immutable, the only difference is we have the ability to open access to it based on the right conditions. Instead of broadcasting the private file to the IPFS network, we simply keep it enclosed within the IPFS node and grant access through the node's gateway or similar infrastructure. This satisfies true privacy without sacrificing the core tenants of IPFS.

This is why Pinata spent the last quarter of 2024 building and perfecting our Private IPFS API, allowing you to upload files, get a CID back, and only allow access based on your mechanism of choice. We've even used it to create the concept of private NFTs where only the owner of the NFT can access the content, and that’s only the beginning.

Happy Pinning!