Should bitswap be removed; how to search for locally stored data.

[shannonwells]

Description

In debugging the root cause of #4138, which was partially blocking re-implementing retrieve-piece, it was discovered that our PorcelainAPI.DAGCat function (still?) will go to bitswap and retrieve data from a connected peer that has it, sidestepping retrieval market entirely.

After discussing this issue with @acruikshank, he suggested that since storage and retrieval deals are now over datatransfer->graphsync and not bitswap, that exposing this API represents a security risk, since a client can obtain data for free from any connected node that has the data in its blockstore, so long as client knows the payload CID. Additionally, he suggested that it might be ok even to take out bitswap entirely.

In short there needs to be a decision made about how a client should search and retrieve data that is stored locally, and whether bitswap is still needed in go-filecoin at all.

how a client should search and retrieve data that is stored locally

We could: 1) Remove DAGCat from porcelainAPI 2) Force any type of local DAG get to search only blockstore and never fall back to bitswap 3) other suggestions?

[hannahhoward]

Note: the traditional way to find things w/o Bitswap is to just use a blockstore directly, as opposed to the BlockService which talks to bitswap.

If you want to continue to use the BlockService but not have it call out to bitswap, you can use an offline exchange. https://github.com/ipfs/go-ipfs-exchange-offline

Essentially this replicates the bitswap interface for use by the block service but does nothing.

[anorth]

This is legacy. We don't want bitswap in the node sourcing deal data at all, though we'll retain it for the chain. Removing bitswap was roughly waiting for market module integration to provide an alternative