Pinning should have a better UX for any time scale it takes to pin, and pinning intentions should be persisted between reboots
- Dominant language
- JavaScript
- Stars
- 6.6k
- Forks
- 903
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 5
Description
This is a feature request for IPFS Desktop as I currently see this problem;
Pinning something falls either under three different "time scales".
The first is that the file is already locally downloaded, and pinning is nothing more than verifying that the file exists, this usually takes under a second.
The second is that the file is not completely downloaded, or not downloaded at all, **but** that it is easily accessible over the network (i.e. DHT announcements are out, content is easily findable, and its relatively small, only a few MB or so), this'd take a few seconds, but nothing more.
The third is that the file is *not findable*, the file is either not announced, the peers aren't reachable, or otherwise the pinning process takes an extra amount of time to complete, usually for multiple GB of data.
The last two is what IPFS Desktop does not feel ready for, the pinning checkmark feels like it has a roundtrip time of exactly the amount of time it takes to press it, and nothing more.
For pins that take a second more, the pinning state should be communicated clearly to the user, and replaced with a 'pinned' icon when it is done.
For pins that are stalled or take an incredibly long amount of time, the request that the user wants to pin this file *should be persisted*, so that they can simply tell IPFS "hey, i care about this file, find it, no matter how long it takes", *that* is what i expect it to do, and i've had multiple times where after a restart, IPFS Desktop forgot i wanted to pin the file, even ones that were actively downloading.
---
I'm currently using ipfs-cluster, which has this behaviour, where `pin add` tells it to queue up the pin, and try pinning it later, retrying other pins in a round-robin fashion ad infinitum, until one of them succeeds pinning, leaving others to take the place in the queue.
It has a relative prioritisation system, where a new pin is more eligible for the active-pinning queue than older pins. This is relatively annoying as it takes the timeout phase (24h by default) for the new pin to start getting pinned, so IMO a "background" and "foreground" queue should be created for IPFS Desktop to achieve a better user experience.
---
Pinning this way (in the background, in a long-form) should also generate notifications when the pin is complete, so the user can be *somewhat* aware when such a thing is finally done.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.