Ability to pin content for different periods of time per website

Ecosystem
1

With current versions of IPFS, files are (to my knowledge) persisted in two different states: Pinned and unpinned. Pinned files are permanently stored in your local IPFS cache, whereas unpinned files are only kept for a limited amount of time then deleted from your local IPFS cache. I would love to see this system expanded to offer more flexibility and customization, namely the ability to choose the pin period based on how much you frequent or enjoy a given site. Here’s how I imagine the system working:

When visiting IPFS websites in your browser, the interface (IPFS Companion, etc) gives you the possibility to rate the site on your local IPFS instance, by using new console commands that would be implemented for this purpose (eg: “ipfs rate”). It can be one value ranging between 0 and 1, where 0 means “no interest in storing” while 1 means “full interest in storing”. The option can be changed at any time, and for newly visited sites the value resorts to a sensible default (eg: 0.5). Here are some examples of customization:

  • If the site is one you dislike or distrust but still choose to visit for any reason, you can rate it 0. In this case IPFS will never cache the files or seed them (known as leeching in torrent terms), they are deleted once the page has finished loading.
  • If the site is one you aren’t particularly interested in, you can rate it 0.25. In this case, based on the duration settings, IPFS will only persist files from this site for a day.
  • If the site is one you’re indifferent about, you can rate it 0.5. In this case, based on the duration settings, IPFS will only persist files from this site for a week.
  • If the site is one you are particularly interested in, you can rate it 0.75. In this case, based on the duration settings, IPFS will only persist files from this site for a month.
  • If the site is one you really enjoy and wish to support, you can rate it 1. In this case IPFS will permanently cache all files coming from this site and never delete them automatically.

What is your opinion of a preferential pinning system, in which the user can specify sites they favor or disfavor in order to pin them for longer or shorter periods of time? Is such a feature planned? Would you use it? Do you believe it would be useful for the IPFS ecosystem as a whole? Personally I think it would give users more control over their drive space and bandwidth, allowing everyone to allocate their computer’s resources to sites they wish to support the most.

1 Like
2

What is a “site” in this context? A domain name pointing to an /ipfs/ hash? A domain name pointing to an /ipns/ address? A domain name pointing to a conventional web server that happens to load some elements over IPFS? I think all of these would need to be handled differently.

I have a couple of initial concerns with this idea (as I understand it)

  1. the time limits for the different settings seem arbitrary
  2. I don’t know how the IPFS daemon is supposed to know which “site” the gateway (or plugin) is requesting hashes on behalf of since it might load content not contained “underneath” the main site directory/hash
  3. I don’t want to be prompted to rate a site every time I open a page (it sounds like your suggestion might have a default setting, though)
  4. Using a 0 to 1 scale in 0.25 increments as discrete settings seems unintuitive

I do like the idea of setting time limits for pinned content. There’s an open issue for this feature here:

2 Likes
3

Those are good points. First of all identifying the site: I imagine this feature would only work when a file is served from an IPNS domain, otherwise you don’t have a definite source to relate the file to. Simply matching parts of the URL (notably the IPNS name) should be able to do the trick then.

Using a rating value is just the quickest implementation that came to mind to best emphasize the suggestion. If I think about it, it would be more correct to simply support pin date overrides in the form “url_pattern pin_duration” (where url_pattern is something like “http://ipns_name*”).

Lastly I don’t suggest prompting the user to rate each site they visit, that would be very annoying. The ability to customize the pin date is something you’d only use if and when you want, similarly to bookmarking a page. If you choose not to do it, the default pin duration is used.

4

This feature makes sense for a static site generator (e.g. HUGO). For example, an expiration date could be included in page metadata ; after compiling the site, a script module for the SSG could issue commands to ipfs per each file.

1 Like