From what I understand how IPFS works, adding files on IPFS works like this:
- We put a file to IPFS on computer A, it computes [hash]
- We enter
ipfs://[hash]on computer B - Computer B starts the search on DHT where [hash] is located, this takes a while
- When it does, it connects to the peer containing the [hash] and starts to download it (assuming it’s a single chunk file)
OK, but the thing is that when we first enter the IPFS address on the first other computer, i.e. computer B in this case, it takes 10-20 min for smaller files to several hours for bigger files to be quickly available to computer B, because of the slow DHT search. After that, it is quickly available to computer C, D, …
This I think is unacceptable for quickly sharing files with someone or dynamic applications.
Instead, a more rational way for this would be to optionally add to the URI a hint where the file is available, i.e. which peer is the originator. This would hasten the download while the file isn’t popular yet.
For example instead of ipfs://[hash]/ we could have ipfs://[hash]?peer=1.2.3.4/4001 or something similar. Which would mean that the peer 1.2.3.4:4001 has the [hash]. That way IPFS could do a DHT search + automatically add the 1.2.3.4 peer as having the [hash] and thereby speed up the whole process of initially puting files on IPFS.
What do you think?
Am I misunderstanding how IPFS works?
Is this a bad idea?
I bounced the idea on #ipfs@freenode and the ones that responded seemed to like it.