Closed hannahhoward closed 4 years ago
While graphsync is great for chain syncing, I don't think it has so much to offer here. FWIW I don't think bitswap is a great way of transmitting data that, in a common case, will be a large opaque blob held by exactly one peer and intended for transmission to exactly one other peer. Using unixfs etc adds a bunch of conceptual overhead, the value of which I am far from convinced.
In general we intend Filecoin to be fairly agnostic about data transfer protocol, so in my opinion we should leave the current "easiest thing to implement" in place for now until we have more real-world usage information to motivate something better.
This will be delegated to the data transfer module (which will use graphsync)
Description
Right now, when a miner is going to store some data, it asks for the data by fetching a dag through bitswap.
Right now there's a comment above it that reads: // TODO: this is not a great way to do this. At least use a session (https://github.com/filecoin-project/go-filecoin/blob/master/protocol/storage/miner.go#L427)
Indeed, Bitswap is not great at fetching DAGs, and I wonder if Graphsync would be better.
Acceptance criteria
Risks + pitfalls
Graphsync is a point to point request, at least for the moment, so it's not entirely clear who to ask for the data. Probably the client? Though a) the client's peer id is a bit tough to track down and b) theoretically the client might not even have the data themselves or it might be faster to get from somewhere else?
Is this even worth it? Once the data is gotten is has to get sealed (I think) and that takes a long time so maybe the time to get it isn't all that large.
Maybe we should just make a session like it says...
Where to begin