of libp2p. This allows graphsync to be tested without the actual network
of libp2p. This allows graphsync to be tested without the actual network
3.`ipldBridge` is an IPLD abstraction provided to Graphsync on top of go-ipld-prime. This makes the graphsync library testable in isolation
3.`ipldBridge` is an IPLD abstraction provided to Graphsync on top of go-ipld-prime. This makes the graphsync library testable in isolation
4.`loader` is used to load blocks from content ids from the local block store. It's used when RESPONDING to requests from other clients. It should conform to the IPLD loader interface: https://github.com/ipld/go-ipld-prime/blob/master/linking.go
4.`loader` is used to load blocks from content ids from the local block store. It's used when RESPONDING to requests from other clients. It should conform to the IPLD loader interface: https://github.com/ipld/go-ipld-prime/blob/master/linking.go
5.`storer` is used to store incoming blocks to the local block store. It's used when REQUESTING a graphsync query, to store blocks locally once they are validated as part of the correct response. It should conform to the IPLD storer interface: https://github.com/ipld/go-ipld-prime/blob/master/linking.go
### Write A Loader From The Stuff You Know
### Write A Loader An IPFS BlockStore
Coming from a pre-`go-ipld-prime` world, you probably expect a link loading function signature to look like this:
If you are using a traditional go-ipfs-blockstore, your link loading function looks like this:
`go-ipld-prime` intentionally keeps its interfaces as abstract as possible to limit dependencies on other ipfs/filecoin specific packages. An IPLD Link is an abstraction for a CID, and IPLD expects io.Reader's rather than an actual block. IPLD provides a `cidLink` package for working with Links that use CIDs as the underlying data, and it's safe to assume that's the type in use if your code deals only with CIDs. Anyway, a conversion would look something like this:
`go-ipld-prime` intentionally keeps its interfaces as abstract as possible to limit dependencies on other ipfs/filecoin specific packages. An IPLD Link is an abstraction for a CID, and IPLD expects io.Reader's rather than an actual block. IPLD provides a `cidLink` package for working with Links that use CIDs as the underlying data, and it's safe to assume that's the type in use if your code deals only with CIDs. A conversion would look something like this:
in `go-ipld-prime`, the signature for a link storer is a bit different:
1.`ctx` is the context for this request. To cancel an in progress request, cancel the context.
2.`p` is the peer you will send this request to
3.`rootedSelector` is the a go-ipld-prime node the specifies a rooted selector
### Building a path selector
A rooted selector is a `go-ipld-prime` node that follows the spec outlined here: https://github.com/ipld/specs/blob/master/block-layer/selectors/selectors.md
`go-ipld-prime`provides a series of builder interfaces for building this kind of structured data into a node. If your library simply wants to make a selector from CID and a path, represented by an array of strings, you could construct the node as follows:
`go-ipld-prime`stores in two parts to support streaming -- the storer is called and returns an IO.Writer and a function to commit changes when finished. Here's how you can write a storer from a traditional block storing signature.
1.`ctx` is the context for this request. To cancel an in progress request, cancel the context.
2.`p` is the peer you will send this request to
3.`link` is an IPLD Link, i.e. a CID (cidLink.Link{Cid})
4.`selector` is an IPLD selector node. Recommend using selector builders from go-ipld-prime to construct these
### Response Type
### Response Type
```golang
```golang
...
@@ -185,25 +195,12 @@ type ResponseProgress struct {
...
@@ -185,25 +195,12 @@ type ResponseProgress struct {
The above provides both immediate and relevant metadata for matching nodes in a traversal, and is very similar to the information provided by a local IPLD selector traversal in `go-ipld-prime`
The above provides both immediate and relevant metadata for matching nodes in a traversal, and is very similar to the information provided by a local IPLD selector traversal in `go-ipld-prime`
## Compatibility: Block Requests
While the above is extremely useful if your library already uses `go-ipld-prime`, if your library uses an older version of go ipld libraries, working with these types of `go-ipld-prime` data may prove challenging.
To support these clients, Graphsync provides a compatibility version of the above function that returns just blocks that were traversed:
