WebUI Integration

[hacdias]

Dear fellows of @ipfs-shipyard/gui!

I was taking a look at how to integrate this with WebUI. The initial idea was to provide a link to share.ipfs.io/add/QmHash1/QmHash2 with the hashes of the files to add.

Issues I found and other problems worth mentioning:

• It only supports ony hash on /add url.
• It breaks when going to share.ipfs.io/add without any hash.
• share.ipfs.io won't be able to connect via API if the user doesn't explicitly allow that URL
• If using window.ipfs it can be slower because it will use public API instead of user's node.
• We can't grant that when moving from WebUI ---> Share APP will use the same IPFS instance since WebUI allows us to change the instance it is connected to.

I'll work on the first issues. The other ones need more thought. Thoughts?

[fsdiogo]

The initial idea was to provide a link to share.ipfs.io/add/QmHash1/QmHash2 with the hashes of the files to add.

That was the initial idea but then it evolved to provide only one hash with all the files, that can be generated using the makeHashFromFiles function from the WebUI.

It breaks when going to share.ipfs.io/add without any hash.

We should just redirect to share.ipfs.io if there is no hash. About that, routing has a lot of problems. It expects to have an # for hash based routing, if someone goes to share.ipfs.io/QmdU2gMs6UwgbPVwiALmzCiRci8eeeRTphQ4QmSmfzETP6 to supposedly download files, it redirects to share.ipfs.io/QmdU2gMs6UwgbPVwiALmzCiRci8eeeRTphQ4QmSmfzETP6# ignoring the hash and going to the upload page. The same happens with the other pages.

If using window.ipfs it can be slower because it will use public API instead of user's node.

Yes, and sometimes it's so slow that it ends up being unusable. I was going to open an issue about that, but I'll expose that here. If you go to a share files download page, the request that list the files takes ages. Is there any way of solving that? Note that as it's the download page we don't want to force the user to have a daemon running.

[hacdias]

That was the initial idea but then it evolved to provide only one hash with all the files, that can be generated using the makeHashFromFiles function from the WebUI.

Awesome! 😄

About that, routing has a lot of problems. It expects to have an # for hash based routing, if someone goes to...

Will take a look at routing after #26 then! 😄

If using window.ipfs it can be slower because it will use public API instead of user's node.

See #26!

[hacdias]

if someone goes to share.ipfs.io/QmdU2gMs6UwgbPVwiALmzCiRci8eeeRTphQ4QmSmfzETP6 to supposedly download files, it redirects to share.ipfs.io/QmdU2gMs6UwgbPVwiALmzCiRci8eeeRTphQ4QmSmfzETP6#

I believe this is something that should be handled on the server side because this app is an SPA so it should work from any page at all. The server should make those redirects.

[olizilla]

Redirects mean custom server config, and it's no longer just a case of loading the app from ipfs.

I think we should focus on making the app work well with hash routing. I don't love it, but that's just a deveoper url aesthetic issue, I don't think it's something that end users care about. If a user handcrafts an invalid URL, things won't work.

There is an argument that ipfs should work towards a great dev experience for hosting static sites and single page apps... we could lobby for supporting things like "if a directory has a 404.html in it, then redirect sites to that, if it has a 200.html, then redirect all sub paths to that like https://surge.sh/help/adding-a-200-page-for-client-side-routing

We could start that discussion by making an ipfs gateway proxy that does those things and figure out the edge cases, and see what people think.

In the meantime we have just have to use hash routing as we don't get any fancy redirects from ipfs hosted sites.

[lidel]

Yes, and sometimes it's so slow that it ends up being unusable. I was going to open an issue about that, but I'll expose that here. If you go to a share files download page, the request that list the files takes ages. Is there any way of solving that?

Some ideas:

• I think by default ipfs ls is fetching children as well to determine which ones are directories etc.
  • In go-ipfs you can pass --resolve-type=false to speed it up, but not sure if it is supported in js-ipfs and js-ipfs-api, if it is missing you could look into adding it.
  • Alternative is to use lower-level APIs and create progressive load experience, eg. ipfs.dag.get and inspect links of returned DAGNode instead, use that to render initial list of items (with plain icons) and then fetch details for each in async manner, or something like that. The important part is to render the list of file names as soon as possible.