ipfs-desktop
ipfs-desktop copied to clipboard
ipfs
Pinning should have a better UX for any time scale it takes to pin, and pinning intentions should be persisted between reboots
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.
Thanks for submitting this detailed issue @ShadowJonathan appreciate the effort. IPFS-Desktop is a fancy electron wrapper around kubo, shipping with it's own UI and ipfs instance it can control.
I would like to synthesize this request into asks and then discuss with kubo owners on how we can deliver a more cohesive experience.
Ask 1: [Feat] Fix pinning status representation
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.
From https://github.com/ipfs/ipfs-desktop/issues/2386
However, a user would still like to see a progress bar on the pin, to know when it has stalled, how much has been downloaded, and how far "along" it is.
That's fair, we might be able to leverage the progress arg to show a much better representation of pin status. Or a progress bar like depiction.
Ask 2: [Bug] Fix persistence of pins across restarts.
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
after a restart, IPFS Desktop forgot i wanted to pin the file, even ones that were actively downloading.
This sounds like a bug, we should not be doing this, since we control the instance we should either persist this to the app storage or leverage the ls call to populate the pinned files.
Ask 3a: [Feat] Implement a queuing system to pin files.
IMO a "background" and "foreground" queue should be created for IPFS Desktop to achieve a better user experience.
I feel this will be better handled by kubo instead of ipfs-desktop. Kubo can take care of prioritizing once the pin has been added, we can figure out how ipfs-desktop can poll or receive notifications for pin completed event.
Ask 3b: [Feat] Implement notification system once pinning completes
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.
This can be handled once 3a is implemented.
Please let me know if these sound like a fair summary of your asks.
CC: @SgtPooki
Thank you for taking the time to look at this issue.
FWIW, I do have a background in developing for/with ipfs, trying to push forward the py-ipfs and py-libp2p libraries before those failed, and gaining knowledge on how IPFS works in-depth to better tune my "infinistore" (S3-backed IPFS node), so in that regard I know I'm fully asking for features that require changes in kubo. However, instead of filing those issues there, I want to file them here with a user story, so it's clear and understandable where the derivative feature requests come from, and I can take advantage of y'all prioritising the issues appropriately.
For Ask 1, I know that fetching --progress will probably be a step forward, but i want to make it clear that only doing that wouldn't satisfy my feature request completely, that's why I made https://github.com/ipfs/ipfs-desktop/issues/2386 to make that request much clearer; for a progress bar to exist, there must be a degree of "this amount of work still needs to be done" alongside the "this amount of work is already done", else I believe it adds little value in telling a user how far along something is, and how far it still needs to go.
I also want to emphasise that Ask 1 is more a request for a comprehensive queued pin overview, than it really is about the progress bar, like i described in https://github.com/ipfs/ipfs-desktop/issues/2386. I wish to bring this point across, and that #2386 can then be its own request that's implemented alongside it.
For Ask 2, this is generally less an observation of how I've seen ipfs-desktop behave (though I have had experiences upon occasions where it suggested this), but how I've seen kubo itself behave wrt pins.
Pins in kubo exist for as long as the pin request/CLI call exists, if either is cancelled, the pinning effort is abandoned. (I can observe this by simply watching the wantlist that is active at any time, and observing it dropping once i ctrl+c the pin CLI, or restart an ipfs-cluster instance.)
Thus the ask is also more along the lines of "Make sure that there exists a mechanism somewhere (either in kubo or ipfs-desktop) that remembers the pins the user wishes to queue up", and together with Ask 1 (Representing it somewhere in the UI), give better confidence towards the users as to what is currently being fetched, how far along it is, and how much it definitely knows it still needs to fetch.
Ask 3a is indeed a feature request that requires a derivative issue in kubo, ditto for 3b.
Both would enhance the user experience, and even ipfs-cluster could take advantage of it (as currently it takes care of queueing itself, and even though it knows of a prioritisation system, it does not add prioritised pins to the "queue" until some other pins have rotated out after the timeout).