IPFS And Metadata Immutability

What are the different techniques that can be applied to Mint at scale, and what are some of the recommendations that we have that are useful techniques based on our

experience to assist with doing this. The first lesson is IPFS and Metadata Immutability.

Immutability is a really important property when it comes to NFTs. It's something that is talked about a lot and there are a number of different

techniques and capabilities that can be used to exhibit this property. A key thing to talk about is IPFS or the InterPlanetary File System.

IPFS is a peer to peer decentralised storage network.

And the way that it works is it allows you to store immutable content addressable storage. So what does that mean? Well, immutable basically means it can't be modified.

Once the data has been entered into IPFS, you guarantee that that data cannot be tampered.

And then content addressable storage is the way that IPFS implements immutability. The basic idea is that the content of the data that you store determines

the ID that looks up that content. Thus, if some data was "tampered with" and modified,

it would actually have a different ID. So as long as you have one of these what's called a content ID, which is the mechanism that's used to address content, then you can guarantee that if IPFS

has that data still, that it will return the exact same data that was originally entered that resulted in that ID.

Now content can either be a single file of pretty much any file type, or it can actually be an archive with multiple files within it.

Now similar to the way that you would reference a web page using the http:// or https:// protocol.

IPFS has a protocol defined of ipfs://. So often you might see an IPFS URL expressed as

ipfs:// and then the content ID. So here's an example of a real IPFS URL for a

single text file that has the text "HelloWorld" in it. Now, a key thing to point out is that you can't go into a web browser

and type in ipfs:// and then this content ID, or any other content tied for that matter, because web browsers, at least at this point in time, don't understand IPFS natively.

Now, in order to create a bridge from the IPFS protocol to the let's call it Web 2 world that we all know and

understand and are used to, there are things called IPFS gateways that essentially expose IPFS functionality over HTTPS.

There's a whole heap of different gateways out here. Here's a couple of examples. ipfs.io and cloudflare-ipfs.com.

But there is hundreds of others. Now, it's worth pointing out that sometimes when you request a file in IPFS,

the file will not get returned because that gateway didn't have the content and it either timed out or wasn't able to find that content in

other nodes in the network. Now, to give you an example of how this content ID works, let's look at this example here.

These two content IDs both correspond to a single text file with some simple text in it. The first content ID corresponds to a text file with the text: "HelloWorld".

The second content ID corresponds to the text: "HelloWorld!".

Those two values are very, very similar. But as you can see, the content ID for IPFS are quite different between them and this has content addressable storage at work.

The content in the data that you are storing literally determines the ID that you use to look up that data.

And that's how immutability is guaranteed. If you have an IPFS URL, then assuming the IPFS network is able to retrieve that data, you can guarantee that the data it retrieves is the

exact same data as it was when it was first entered into the network.

Now talking about IPFS leads on nicely to a discussion about metadata mutability. Broadly speaking, if you want to represent metadata on ImmutableX, you've got

two broad options. One would be to use IPFS or something like it, and the second one would be to use a traditional "Web 2 API".

And this might be something like a link to, say, AWS S3 Storage or Google Drive or any URL that you decide.

From an IPFS perspective, it's worth pointing out that because IPFS is immutable, once a file is uploaded to IPFS,

it cannot be modified. It also can't be deleted. But it is possible for that data to disappear because IPFS

as a protocol doesn't guarantee permanence. Now there is a concept called pinning, and what this means is that you can pay an

IPFS provider to pin a piece of content such that it is always made available to the IPFS network.

The interesting thing about IPFS is because it's a decentralised protocol. You can pin any content that you care about.

So an individual NFT owner potentially could pin the metadata for their NFT. And separate to that, the collection owner of an entire

collection of NFTs could potentially pin the metadata for all of the NFTs in that collection. Now, if we look at a Web 2 API, the difference here is that it's really easy

to modify or delete metadata because you can be in full control over what is returned. So this gives you a great deal of flexibility,

but it does mean that there's a vulnerability for unauthorized changes or deletions because the Web 2 API does not give you any

guarantee of immutability or permanence. So it's worth keeping these pros and cons in mind when designing your metadata strategy and how much you and maybe your users

and community care about immutability for the metadata of your NFTs.