If 2 nodes upload exactly the same doc at the same time, what happens?

Hi IPFS community!

I am completely new to IPFS and there are still a lot of technical aspects I cannot grasp, so I hope someone here could help me with some of them.

Here is the situation: 2 nodes on the network are going to generate an IPFS address for exactly the same document (its hash should be the same for both the computers), what happens then with their IPFS links? Are they going to be magically the same (making the file initially available at 2 nodes, which would be an awesome feature)? Or they will be different?

Thx in advance for your answers :slight_smile:

1 Like

Yes they’re going to be the same, available from both nodes.

1 Like

Yes, as lgierth said, they’ll get the same hash and resolve to the same content.

When people mention that IPFS is content-addressed rather than location-addressed, this is exactly what this means. If two files have the same content (no matter where in the world the files are) they will end up with the same hash representing them. But if you change even one byte, the hash will be different.

That is indeed one of the awesome features of content-addressing :slight_smile:

3 Likes

Thanks for your answer!
I just couldn’t believe it would be that easy :stuck_out_tongue:

What’s interesting too is this exchange I had with a web dev friend, and he was very skeptical about the tremendous data replication it would generate for a network.

“Ok bandwidth doesn’t increase as quickly as memory, but we have many reasons to think that bandwidth doesn’t increase because of the huge investments already made in optic fiber during the dotcom bubble and some engineers are saying Moore’s Law is no longer true. So creating that much data replication might not solve the unsustainability problem of the web.”

What do you think about that ?

For one thing there’s also a kind of “de-replication” with IPFS, because data sets (incl. websites) sometimes contain copies of the same files, and a node will only store these once. So there’s already a vast amount of data replication on the web, and IPFS can help in this respect. Large data sets can shrink immensely with this approach.

But I’ve had thoughts similar to your friend’s about the IPFS: one of the explicit goals of the IPFS is to create a web that archives itself. However, to have archival permanence, current content and all previous stages of that content need to be stored on a lot of nodes, not just on the originating node, so it will essentially be (in macOS terms) a global distributed Time Machine volume. This will gobble up an insane amount of storage over time, even with “de-replication”.

Every millisecond, stuff will be added to the IPFS, chat logs, emails, websites, scientific data sets, TV live streams, warez, photos etc., encrypted, unencrypted, as raw data, with filenames etc.

A possible solution lies within IPFS itself, indirectly. Currently, a content provider needs lots of server space, either his own, or rented somewhere. With IPFS, a user who accesses the content, will cache it on his local node (maybe even pin it), which reduces the provider’s need for big server solutions, so with IPFS, capacity previously used for “legacy storage” will be freed, which can in turn be used to strengthen the IPFS in general, used for archives etc., and also to earn some filecoin. Server space providers like Amazon and others will probably be the ones who will profit the most from this development, because they already have the necessary infrastructure. So the IPFS is (in my view) not really a disruptive technology like cryptocurrency, but an organic ®evolution. The players just need to get a taste of it, and then the thing will probably take off. :slight_smile:

2 Likes