Thanks for the reply! This request hooks PR looks like exactly what we need. Is GraphSync ready for production?
go-filecoin uses graphsync for syncing the chain so it should be.
However, unlike bitswap, it can’t currently:
- Figuring out which peers have content. You need to tell it to fetch a specific selector from a specific peer.
- Split requests between multiple peers. It will download everything from that single peer.
Topper Bowers via libp2p email@example.com writes:
And thanks for the tip on ACL. We were planning to implement by storing ACL in a separate storage and once any ACL is applied to a block then any of the ACLs applied to a block would have to pass in order for the node to send the block over. We have a pretty cool situation where the ACL will always get shared before the block, so there isn’t a race there.
Just be careful. There are a few variants:
- If Malory can trick Alice into downloading some content attached to an
- Alice won’t share this content with anyone else, even if Alice later sees other ACLs pointing to the content.
- Alice will have to re-download the content for every ACL.
- If Eve can trick Alice into downloading an ACL and then downloading the attached content from a different peer, Eve can steal the content. This won’t work if Alice makes sure to download from the peer that originally supplied the ACL.
Possibly secure solutions include:
- Just re-downloading the content once per ACL.
- Encrypting the content with a shared-keys stored in parent object (i.e., encryption + ACLs).
- Inserting some random salt into file metadata then:
- Disabling bitswap so we don’t ask for files by hash.
- Always ask for files relative to an ACL.
- Make sure the party sending the ACL is included in the ACL (so we can trust the links).
- Somehow create authenticated links from blocks back up the merkledag to ACLs.
- This could be as simple as including a secret in every object and putting it next to every link to that object. This effectively creates a public and a private link to the object.
- If confirmation attacks are acceptable, objects can be hashed twice: once by themselves for the CID, once with some well-known string to prove knowledge of the data (call this
CAP). Then, links to objects would include both hashes.
- This second hash could also be used to download objects independent of ACLs through bitswap. Instead of asking for
CID, one would ask for
(CID, hash(my peer id || your peer id || nonce || CAP)).