Go-ipfs: feature request: time limit (timeout) for pinned files and directories

[Mithgol]

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 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.”

   

[ghost]

Could you add that to this notes issue instead? https://github.com/ipfs/notes/issues/49

Just trying to not spread the same discussions over N issues ;)

[Mithgol]

Copied the suggestion to a comment in that issue.

This issue can now be closed.

[Mithgol]

…until someone decides to reopen and actually implement it.

[Mithgol]

On the other hand, that was not a good idea. No one is going to answer a feature request if it looks closed.

Reopening.

[insanity54]

I'm messing around with creating some software that helps manage a fleet of IPFS nodes. Shipped with the software is some YAML that has a bunch of suggested IPFS multihashes to pin. Static websites with useful information, funny pictures, interesting audio clips, and unique video. There's a chance that some of the multihashes no longer exist on the network, so the command ipfs pin add -r xxxxxxxxx(...) may try to pin for a long time, blocking other commands from running.

I have a concern about terminology here. To me, the flag --timeout would signal to ipfs that it should stop trying to pin content if unsuccessful at doing so after a time has elapsed. --ttl or --time-to-live seems to me the more appropriate term to use for content you want to be unpinned after a time has elapsed.

_EDIT_

I just found out that there is already a --timeout option. I think it's undocumented and not definitely going to stay in it's current form. https://github.com/ipfs/go-ipfs/issues/1711#issuecomment-140639076

[whyrusleeping]

For the record, every ipfs command respects a --timeout flag. (feature added july 20th, 2015).
It doesnt show up in any documentation for some reason, we should probably fix that...

[Mithgol]

😲

Okay, then let the final name for the feature that I've proposed be somewhat different (--agelimit=…, for example).

[RichardLitt]

timeout docs in this issue: https://github.com/ipfs/go-ipfs/issues/2583

[whyrusleeping]

related: https://github.com/ipfs/notes/issues/49