Future IPFS<>Filecoin interop ideas

[whyrusleeping]

As the Filecoin network evolves, we want to make the interop between ipfs and filecoin more seamless. The ultimate vision is to make it even more persistent, decentralized, and resilient by allowing the same interface to leverage both or Filecoin for storage.

An ipfs user could add funds to their Filecoin wallet, enable ‘paid retrieval’ and use ipfs just like they normally would to request data. When an ipfs node requests some data, they do a search for its providers. The returned provider list contains ipfs providers, and Filecoin providers. The node asks the ipfs providers for the data, and if they get it, great! If they don’t get it, they can ask the Filecoin providers for the data, adding a payment to the request to smooth things along. All of the content they need to access would simply be available - whether it comes from ipfs nodes, or from Filecoin retrieval miners, the experience is just the same.

Reaching this eventual state will require a number of iterations and progressive interop improvements, but is worth exploring to define where we are heading.

Variations

One potentially useful variation on this flow would be for users who add content to the network to have the ability to ‘pre-pay’ for future requesters of the data. The two modes of this (both of which are useful) are one, the file is ‘free’ for retrieval by some set of parties selected by the content owner, and two, the file is ‘free’ for retrieval by anyone who requests it.

The first variation could be achieved by having the payer give out unique links to each person they want to be able to access the file for free. These unique links would contain a token of some sort (likely a compact payment channel voucher) that allows the retrieval miner to claim funds in exchange for serving the file.

The second variation is harder to do trustlessly, but is really the desired workflow for people who want to use Filecoin to host things like their website - where you put money in, and know that your content is being hosted reliably for all requesters. In the meantime, we can use miner reputation systems, auditing systems, and signed activity statements to build trust that retrieval miners are serving content correctly.

Requirements

These flows require a lot of work under the hood to make everything ‘seamless’.

• Graphsync needs to be implemented, and have support for payments (the ‘extra’ field is expected to be used here)
• Provider records need to be able to signify that the content is available from a filecoin retrieval miner for some amount of money
• ipfs clients need to be able to make payment channels to retrieval miners
  • Alternatively, payment channel networks may be used for more efficient payments at the cost of increased latency and extra communication complexity to negotiate multi-hop payments
• Retrieval miners need a way to map between data in sectors and ipfs hash addressed content (ref specs issue #136 )
• Retrieval miners need to be able to announce content on the ipfs network (hard because content routing is hard)
• Retrieval payments should be verifiable in some way, to eliminate abuse vectors.
• ipfs nodes should have a plugin that allows them to have filecoin payment channel functionality, for creating payments for including in bitswap messages.
  • Will also need access to a filecoin wallet, either integrated or via some api

All of these requirements require further exploration and problem solving, but this the direction we are planning on moving towards for our ideal ipfs and Filecoin integration. It will take time to reach this goal, so to support interop between ipfs and Filecoin in the short term, we will implement an interface to smooth interactions between the two networks - described more at #143 .

[melroy89]

Just saying: I do not know if people really want to pay digital money (in any form) in order to receive data (like a site)... I don't.