Advanced Pinning

[eminence]

Ideas for neat things you can do with more advanced pinning controls:

• Pin with an automatic timeout. The item you pin will be automatically unpinned after a user-specified timeout period
• Pin if the number of providers is less than a user-specified threshold (maybe automatically?)
• Unpin automatically if the number of providers is more than a user-specified threshold
• Your ideas below!

[Mithgol]

(moved copied a suggestion from ipfs/kubo#1718 to keep the related ideas together)

Two additions are suggested:

• a flag --timeout=... for the command ipfs pin add (for example, ipfs pin add -r someDir --timeout=3y5mo2w8d13h23mi05s sets the timeout that consists of 3 years, 5 months, 2 weeks, 8 days, 13 hours, 23 minutes and five seconds);
• an additional command (such as ipfs pin purge) that acts like ipfs pin rm but only for items with expired timeouts.

Pros:

• A web site that decides to erase some old content would be able instead to decide to hold that content pinned for a week in IPFS (by running ipfs pin add -r oldContent --timeout=1w and then adding ipfs pin purge to its crontab) after deletion; that site wound also need to change (immediately) all internal hyperlinks to IPFS URLs where they were previously leading to that deleted content. Such action would allow some interested readers to hold copies in their local IPFS instances. The site then purges the content and gets the necessary storage space available on host, but that old content continues to be available in IPFS.
• Alternatively, a web site may decide that some content (images and video, for example) is to be stored in IPFS from the very beginning (but set some timeout for hosting those files pinned in the site's own IPFS local storage). Afterwards the content continues to be available in IPFS as long as the readers actually need it (in their IPFS caches or even pinned by them).

Cons:

• If a clock goes wrong on a system, then some media becomes purged prematurely.

Stretch goals:

• An additional command to reset or change the timeout of a known pinned file.
• A social button that indicates how many IPFS-hosting readers support the global availability of some published material by pinning it themselves before or after its timeout on its initial hosting. “45 likes, 37 retweets, 24 IPFS pins.”

   

[eminence]

Another use-case, but I'm quite sure what the solution looks like:

If you have a directory that you would like to keep updated, a common way to do this is simply keep re-running ipfs add -r my_directory. This is pretty handy because it will automatically recursively pin everything for you. But then the next step is to un-pin the previous version of the directory. So how do you keep track of what the previous hash was?

My only thought at the moment is that the yet-to-be-designed hash tagging system (where you can locally assign a user-friendly name to an arbitrary hash) could be used in some way

[ghost]

If you have a directory that you would like to keep updated

You'd use IPNS -- once IPNS is complete you can pin IPNS records and they'll be kept up-to-date

[eminence]

Sorry, I"m not sure I follow. What might the workflow look like with a complete IPNS system?

[whyrusleeping]

once IPNS is complete you can pin IPNS records and they'll be kept up-to-date

Still figuring out how thats going to work, its tricky.

[ion1]

If a clock goes wrong on a system, then some media becomes purged prematurely.

One could do it based on cumulative ipfs daemon runtime instead of wall-clock time. In this case, the daemon would need to periodically add the difference between the current CLOCK_MONOTONIC time and the previously found time to a counter on disk.