Providing CIDs #1055
|
I had a question about how to properly advertise content on ipfs after importing a car file into helia. The use case a is server that pins the latest version of some DAG (updated with IPNS). After the car file is imported it seems like helia.routing.provide is the next step and likely for every CID in the DAG. Then unproviding all the cids that are in the disjoint set of the previous version if there was one. This shape is seems similar to pinning the new root and unpinning the old root of the updated DAG. Would appreciate any advice here Edit: looking further it seems only the root may need to be provided |
Replies: 1 comment
|
Historically IPFS implementations would provide every CID in a DAG. This has the potential downside of creating many entries in the re-provide queue which can then take a long time to process. From a practical perspective it's usually enough to just provide the root CID, since after downloading the block for that, you retain the connection to the peer that had it, and they probably have the rest of the DAG as well. An exception may be if the DAG is incredibly large in which case you may wish to fragment it and distribute it across multiple nodes but then you're into IPFS Cluster territory. |
Historically IPFS implementations would provide every CID in a DAG. This has the potential downside of creating many entries in the re-provide queue which can then take a long time to process.
From a practical perspective it's usually enough to just provide the root CID, since after downloading the block for that, you retain the connection to the peer that had it, and they probably have the rest of the DAG as well.
An exception may be if the DAG is incredibly large in which case you may wish to fragment it and distribute it across multiple nodes but then you're into IPFS Cluster territory.