-
Notifications
You must be signed in to change notification settings - Fork 31
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: enable dir listing #47
Conversation
I'm giving this one a second thought, instead of blocking the download of individual folders, why not use the public gateway to download them too? Is there any downside? |
In my last commit I've added the ability to download individual folders, as per my previous comment. As @olizilla pointed out in IRC, the go/js HTTP API supports archiving files so we'll use the local daemon when possible. Only when using a fallback |
Unless we can figure out a way to make the "download all" multi-click trick work in FF we may want to to tigger a download of the root cid from the url hash, so there is just a single item to download, that contains all the things, regardless of the structure. |
To be honest I think that should be the way to go anyway! The multi-click trick was just because I didn't know the HTTP API supported archiving files (my bad), but as it does it's best to use that don't you think?
EDIT: I'll do this in this PR. |
@fsdiogo go for it! |
Current status:
|
Minor UX optimisation, If there is only one thing, The download all button should say "download" and should just download the actual thing, rather than a *.tar.gz. We should think of a human friendly name for the downloaded tar where there is more than one thing... Also when expanded the directory is Perhaps when we create it should double wrap, so we can have a named directory like |
👍 for downloading original unwrapped file if we download all from a share that has single item. 🤔 I have mixed feeling about removing CID from
|
@lidel I here you. My main counter is I don't think the downloaded folder name is the right place to educate the users about CIDs, as it's outside out our realm, and we can't offer any support or guidance. It just looks like IPFS has dumped windows registry keys or UUIDs into my downloads folder. I think we can iterate on this though and find a decent
For a new user, I think the most useful thing is to associate it with the service that caused it to be there... I'll have a think about the CID folder name stuff. We can leave that as is for now and revisit once we've got share.ipfs.io battle ready. |
I'm not completely sold to that idea. OK with changing |
About the CIDs, I think @lidel made some pretty good points there for us not "inceptioning" around the wrapping of content.
I like this. On it. |
I think this is ready to go. I'd like to merge this ASAP so share.ipfs.io gets updated with the last changes. (PR #44 didn't get built because of the CI not passing, that has been fixed in this one.) |
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 like shared-via-ipfs-<7cidchars>.tar.gz
and the idea of it associating downloaded archive with the service.
As for concerns about always downloading .tar.gz
, I agree it may not be intuitive enough to have icon for direct download. Created #49 with additional way to address that need.
This is a first step towards the integration of Share Files in Web UI.
Share app is now able to list a mix of files and/or directories:
Things of note: