matheus23
commented
3 years ago Was just thinking about this again. Note to myself: (or @agentofuser now?)
Of course there are concurrency concerns: What if we're adding pins while the data root update is in progress? We would lose those pins if we remove everything after a data root update.
Instead, we should walk the DAG we just uploaded (we have its root CID) and look for all CIDs that we stored locally and remove pins to any of them (e.g. looking at ipfs.refs(...)).
There's just one problem: We shouldn't walk the whole DAG we just uploaded, because we only have that replicated partially locally in browser nodes (no need to fetch the entire private/public file system when we only want to make changes to one file and can just re-link all the parent directories).
I haven't been able to find out whether we can use js-ipfs to query only what we've replicated locally :/
icidasset
Summary
Improve pin management. The root idea: Your computer is just a cache for the internet.
Problem
Pinning everything the client touches causes it to store lots of information forever, even if it doesn't need to.
Impact
The browser will ask the user "do you really want this website to use that much storage?".
Solution
There is no point for the client to be storing all of the CIDs forever. Why do we pin things at all? We should just rely on the IPFS local CID cache to work.
Of course, if you're working offline and creating data without having them uploaded yet, you don't want to have your stuff garbage-collected suddenly. Solution for that: Pin everything we add, until a successful data root update came through. Them we unpin everything and let the local cache do its job.