I’ve put a little more thought into this after reading up a bit on IPLD. I think there’s a couple options that might be available for giving a speed boost as an intermediary in a file transfer.
The first and simplest version could be setting up multiple peers on a single server. By sharing access to a common data folder, peers could seed different parts of the MerkleDAG in parallel using the built-in IPFS algorithms.
The second option would require more coordination but could allow multiple machines to seed in parallel with minimal duplication of data. It would involve chopping up the MerkleDAG into roughly equal branches of data using IPLD selectors (eg
root/to/branch/a/*). Those branches could then be spread across servers each operating as an individual peer.
The third option is the original idea with extra language to clarify. As I understand it, all the data in the MerkleDAG is held in the leaf nodes with each leaf having its own unique CID. That means the leaf CIDs could be requested directly as root nodes before final reassembly using the full MerkleDAG for integrity.
A fourth option would be like a combination of two and three. Instead of a potentially complex algorithm for generating IPLD glob selectors (eg
root/path/to/branch/a/*), it would use a lazy approach to generate a list of selectors down to each leaf (eg
Now, it’s important to note, this does hinge on Boris’ question about whether there’s any performance advantage to multiple peers.
My impression of IPFS is that the more widely available a file is, the more effective it becomes. That’s the torrent style aspect of things.
Also, options 2, 3, and 4 might require more code execution on the requestor side. Instead of sending the original file’s root CID, the requestor would get a manifest including the root plus a list of leaf node CIDs or IPLD selector paths plus a list of peer IDs to configure the swarm. The manifest would then be used to set up a burst of asynchronous IPLD get requests.
Assuming there’s merit to any of these approaches, there’s an opportunity to monetize using a pay-per-peer model. Depending on the server architecture, it might even be possible to offer speed control on both the sender and receiver side, perhaps even mid-download…
Am I still missing something here?