-
Notifications
You must be signed in to change notification settings - Fork 324
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pinning service integration: Augment "Pin IPFS Resource" functionality #888
Comments
@lidel and @rafaelramalho19 -- AFAIK, there are two scenarios in which a Companion user might invoke third-party pinning. Both only occur if the user has "Auto upload" enabled for one or more pinning services.
This seems logical enough that it doesn't need any modification or explanation, but want to run that past you both to make sure (a) that I haven't omitted any possible scenarios (b) it doesn't feel logical/obvious to you. Thanks! |
|
@lidel Sounds good. Let's keep this on hold until we know a bit more about the issues involved in (1). |
@lidel - Revisiting your earlier question for a status check:
|
Coming up with good "pinning UI" in Companion will be difficult because exposing user to the concept of a "pin" itself is feels too technical IMO. Perhaps a better user experience would be if we replace "Pin IPFS Resource" with "Import to my IPFS node" which... copies reference to the current CID to MFS, and then opens Files in WebUI in a new tab (just like wealready do when user does quick upload or import via context menu). This approach means we don't need any new UI in Companion, and lean more on WebUI, which is our general direction anyway. Note that import to MFS effectively "pins" content that is already in node's cache (as long it is in MFS, it won't be garbage-collected), but is much easier for user to reason about:
@jessicaschilling how does this sound? |
Refining the idea from my previous comment:
|
@lidel - sounds excellent, totally agree. I'm going to repurpose this issue from discussion to requirements now that we have those. This should wrap up pinning-related Companion work, at least for initial release 😊 |
Two thoughts below on i18n keys stashed from #937 but not implemented to save on contributor translation burden. Let's use this (or similar) wording: "assets" is a little clearer than "resources".
|
Small concern regarding low level pins:
What if we don't do low level local pinning in Companion, but delegate that decision to Web UI?
|
@lidel I think this might actually be a slightly different problem from the perspective of the end user. Unless you know pretty deeply how pinning works, the default user mindset is likely to be something like this:
Could we give the user the option to "pin this page" (which would, if I understand correctly, take the user to the Files screen + modal to decide if they want to MFS-pin just the local cache to their node or a pinning service) versus some more nuclear "pin entire site" option (which would have to come with warnings: you're pinning 80gb)? In either case, agree we shouldn't be doing low-level pinning from Companion anyway, because your pins "disappear" and can never be seen from our file system for the ordinary user. |
Continuing forward, notes from call today. @lidel - please amend/comment if I've got anything incorrect or you have additional thoughts.
NOTE: this does result in low-level pinning being removed from Companion's overall functionality. Are we OK with this? (Suggesting yes, because "I don't understand why my repo is 100GB and GC doesn't change that" is a common new-user complaint and is likely largely triggered by accidental massive low-level pinning. PLUS it removes the need to explain "real pin/low-level pin" vs "pseudo-pin/MFS import" - something fairly nuanced - to early-stage who may not need to understand this.) |
I agree:
Devil is in the details:
|
This sounds good. Additionally, "capture this web page" is a known feature request, so definitely worth the effort 😊
Makes sense. What about I'd advise against silently overwriting, since one use case might be archival saves in (for example) a censorship situation where changes over time are important to document.
|
This changes the way IPFS content is kept around. Instead of using low level pins we copy the item to MFS, unifying experience to match recent changes in ipfs-webui v2.12 and ipfs-desktop v0.15.0 This also removed page-action, because it was Firefox-specific feature and made maintenance and testing more difficult (now we have same UX in all browsers). Closes #742 Closes #888 Closes ipfs/ipfs-gui#91
This changes the way IPFS content is kept around. Instead of using low level pins we copy the item to MFS, unifying experience to match recent changes in ipfs-webui v2.12: https://github.com/ipfs/ipfs-webui/releases/v2.12.0 and ipfs-desktop v0.15.0: https://github.com/ipfs/ipfs-desktop/releases/tag/v0.15.0 This also removed page-action, because it was Firefox-specific feature and made maintenance and testing more difficult (now we have same UX in all browsers). Closes #742 Closes #888 Closes ipfs/ipfs-gui#91 Co-authored-by: Jessica Schilling <jessica@protocol.ai>
Note: This issue is part of a larger pinning service integration epic undertaken spring/summer 2020.
The need
Augment functionality of existing "Pin IPFS Resource" toggle to support the use of third-party pinning services:
Context
Advantages of this approach are:
Original note from PRD:
The text was updated successfully, but these errors were encountered: