-
Notifications
You must be signed in to change notification settings - Fork 325
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
feat: import files to MFS #810
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is awesome, thank you @colinfruit!
Apologies for not getting to this sooner.
Big 👍, but before we merge this, some things to address:
-
Please change labels and variable names from "upload" to "import"
(eg. "import to IPFS",/ipfs-companion-imports/
directory on MFS, etc).
Context: We generally avoid the 'upload' word, because it suggests data is pushed to some external machine, but thats not how IPFS works, andipfs add
may be renamed toipfs import
in the future (see RFC: unite the files APIs ipfs-inactive/interface-js-ipfs-core#552). -
Would it be possible to expose the name of default directory for uploads as an editable setting on Preferences screen? Its ok to add it to "Experiments" section for now, as we may change it in the future.
-
I am bit worried what happens to
/ipfs-companion-imports/
when user uploads 10th, 100th file. To illustrate, I've shared multiple files over times, and today I shareddeath-button.jpg
. After it got imported, Companion opened/ipfs-companion-imports/
and the file is lost in the noise.
(see screenshot)
Potential solution is to shard per timestamp (/ipfs-companion-imports/2019-11-11_184500
) to keep this in check. Perhaps we could make the default/ipfs-companion-imports/%Y-%m-%d_%H%M%S/
and replace timestamp on the fly, enabling people to define their own destinations, eg. if they want to shard per day instead of per second?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two more things:
add-on/src/popup/quick-upload.js
Outdated
} | ||
let result | ||
state.progress = `Uploading ${streams.length} files...` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to self: it looks like we are losing import progress report, but it never worked correctly over HTTP API (https://github.com/ipfs/js-ipfs-http-client/issues/842), so its ok to drop it for now.
add-on/src/lib/ipfs-companion.js
Outdated
get openWebUiAtDirectory () { | ||
return openWebUiAtDirectory | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ugh, another realization: we can't open webui if embedded js-ipfs is used in non-Brave browser.
We need to check if getState().ipfsNodeType === 'embedded'
and open resource at public gateway instead (Brave uses embedded:chromesockets
, so it won't match and open WebUI)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we could make this even more useful:
What if we add toggle "Open imported files in WebUI"?
Enabled by default, but when disabled it would open at Gateway (restoring old behavior).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good. It would be great to find a way of opening the WebUI when using embedded nodes in a subsequent issue. Has this been looked at before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Embedded node is unable to open port to provide HTTP API, so the only option I see is to open WebUI from third party server, eg. https://webui.ipfs.io and make it use API of embedded node from Companion via window.ipfs
. At the moment we don't support window.ipfs
in WebUI because it is sandboxed, and WebUI requires full read-write access to MFS and config.
Details in: #514
Thanks, @lidel!
Makes sense. I changed all the user-facing labels this PR introduces from "upload" to "import". I did not change the variable names, because it feels inconsistent with the existing code. References to
Sure. Also, I removed it from the upload screen, because it seemed redundant. On the other hand, it provides useful functionality there as well. What do you think?
I'm looking into the best way to handle user-generated date symbols ( |
Thank you @colinfruit! I am travelling this week, but will review this as soon I have some uninterrupted time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colinfruit Apologies for slowness on my end. Good news is that after 32h travel I am finally back :-)
This PR is great, we are nearly there: small cosmetic asks below and inline.
-
Let's add "File Import" section to Options page and move related settings there
(This can be a separate PR if you want to ship this sooner) -
Please change newly added labels, variables and keys in this PR to use "import" instead of "upload" (mainly
uploadDir
→importDir
). To keep this PR small I created Language: replace "upload" with "import" #817 for the rest.- FYI I've added you as a Collaborator, so you no longer need to work from your fork, you can close this original repo and create feature branches in it (it makes easier to work on PRs together)
Can't wait for pushing this over the finish line ❤️
<input | ||
id="uploadDir" | ||
type="text" | ||
pattern="^\/(.*)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trailing slash may be missing. To avoid bugs caused by that, either require it to end with /
(easy, fix below) or programmatically add it if missing (harder)
pattern="^\/(.*)" | |
pattern="^\/(.+)\/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this before import happens in quick-upload.js
, to account for the potential case of someone forgetting the trailing slash on the import page. It handles both cases, and prevents the user from having to guess that a trailing slash is necessary. https://github.com/ipfs-shipyard/ipfs-companion/pull/810/files#diff-9984375a8301f7832fa0da0a5aafd803R75
Sounds good, one thing we need is to handle
Sure. |
add-on/src/popup/quick-upload.js
Outdated
// unless and embedded node is in use (no access to web UI) | ||
// in which case, open resource. | ||
if (state.ipfsNodeType === 'embedded' || !state.openViaWebUI) { | ||
await ipfsCompanion.uploadResultHandler({ result, openRootInNewTab: true }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not working as expected for me tonight, when importing multiple files without using the webUI, the context menu simply hangs. Maybe it's some weirdness with my connection; I'll take a look at this tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same issue this morning, importing multiple files and opening them in a context menu hangs. However, it is reproducible on current master, so I won't deal with it in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the issue you described is due to slow content discovery by the gateway at https://ipfs.io/ipfs/
.
Embedded node in Firefox/Chrome can't run own gateway, so we use public one instead.
Potential fix would be to update preloadAtPublicGateway
and apart from existing HTTP HEAD request to user-specified public gateway, do additional recursive preload via HTTP GET request to one of preload nodes:
https://node0.preload.ipfs.io/api/v0/refs?arg={CID}&r=true
https://node1.preload.ipfs.io/api/v0/refs?arg={CID}&r=true
In case of "quick-upload" screen, the CID should be of the wrapping directory.
This should not block this PR, let's track this in #546
add-on/src/popup/quick-upload.js
Outdated
@@ -134,6 +134,8 @@ function file2buffer (file) { | |||
|
|||
function formatImportDirectory (path) { | |||
path = path.replace(/\/$|$/, '/') | |||
path = path.replace(/(\/)\/+/g, '$1') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this just because it makes a nicer user experience. Files will appear in the Web UI with multiple slashes (only on auto-open, from import page), despite being stored without them, if multiple slashes are not removed on format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Do you mind adding unit tests for formatImportDirectory
, so we don't break this during future refactors?
For now it can be test/functional/lib/quick-upload.test.js
(similar to existing test/functional/lib/ipfs-path.test.js
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add-on/src/popup/quick-upload.js
Outdated
// unless and embedded node is in use (no access to web UI) | ||
// in which case, open resource. | ||
if (state.ipfsNodeType === 'embedded' || !state.openViaWebUI) { | ||
await ipfsCompanion.uploadResultHandler({ result, openRootInNewTab: true }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the issue you described is due to slow content discovery by the gateway at https://ipfs.io/ipfs/
.
Embedded node in Firefox/Chrome can't run own gateway, so we use public one instead.
Potential fix would be to update preloadAtPublicGateway
and apart from existing HTTP HEAD request to user-specified public gateway, do additional recursive preload via HTTP GET request to one of preload nodes:
https://node0.preload.ipfs.io/api/v0/refs?arg={CID}&r=true
https://node1.preload.ipfs.io/api/v0/refs?arg={CID}&r=true
In case of "quick-upload" screen, the CID should be of the wrapping directory.
This should not block this PR, let's track this in #546
add-on/src/lib/ipfs-companion.js
Outdated
get openWebUiAtDirectory () { | ||
return openWebUiAtDirectory | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Embedded node is unable to open port to provide HTTP API, so the only option I see is to open WebUI from third party server, eg. https://webui.ipfs.io and make it use API of embedded node from Companion via window.ipfs
. At the moment we don't support window.ipfs
in WebUI because it is sandboxed, and WebUI requires full read-write access to MFS and config.
Details in: #514
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@colinfruit Thanks! The UX of this is looking pretty nice ❤️ 👍
I believe we could go extra mile and switch everything to MFS, namely close #635 in this PR as well.
If you right click on image there will be context menu option to Add to IPFS
.
The code responsible for that is in add-on/src/lib/ipfs-companion.js#onAddFromContext
– do you think you could make it work the same as sharing screen?
- copy to MFS instead of pinning
- opening in WebUI instead of gateway
- rename labels from
Add to IPFS
toImport to IPFS
- perhaps we should only keep the one that remembers the filename? CID-as-filename does not make much sense in MFS context, and CID can be copied via context menu anyway
- respect global File Import preferences
Thoughts?
…ipfs-companion This has been done using adding them to IPFS first (ipfs.add) first and then using the ipfs files copy api (ipfs.files.cp) to move the files into the desired directory. Please enter the commit message for your changes. Lines starting
Co-Authored-By: Marcin Rataj <lidel@lidel.org>
remove references to MFS and redundant 'import' messages Co-Authored-By: Marcin Rataj <lidel@lidel.org>
Co-Authored-By: Marcin Rataj <lidel@lidel.org>
Co-Authored-By: Marcin Rataj <lidel@lidel.org>
This commit required abstracting the ipfs import functionality into a separate file to avoid a circular dependency between quick-upload and ipfs-companion, and continue to enable testing functionality.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you @colinfruit!
Is there anything you want to add to this PR, or is it ok to merge & release to beta?
@lidel, fine to merge this. Thanks! |
This PR changes the upload target from
ipfs add
to MFS. Currently, it uses the default directoryipfs-companion-uploads
with the user option to change this on the upload page. On successful upload, it will open the Web UI, at the directory used for the upload.closes #415 and closes #635