Problem with window.ipfs and Files/Settings

Something that we should address before shipping the first iteration:

Background

When WebUI is bundled with IPFS Companion it detects and uses original API object available in WebExtension context, but if WebUI is loaded over HTTP it tries to use window.ipfs injected by IPFS Companion.

Problem

The problem with window.ipfs in current form is a limited subset of IPFS API and sensitive things like access to ipfs.config.* is blocked and access to ipfs.files.* is sandboxed.

Current UX is problematic. window.ipfs not only disables the Settings screen, but the sandboxing make it look like Files screen is broken.

User will be really confused if ipfs files ls shows files in the terminal, but WebUI claims it is empty.

Solution

• Files screen should not log entire stacktrace in code below (quick fix: String(error)): https://github.com/ipfs-shipyard/ipfs-webui/blob/a67135c0a5041ed5c7a6d5216e9b664cb5336726/src/bundles/config.js#L64
• There should be a note at the top of Files screen informing user that listed files come from “window.ipfs sandbox at /path/to/sandbox/root”. It may be a good UX to display faded-out breadcrumbs prefixing root with the path of sandbox root.

Thoughts?

[hacdias]

@lidel gotcha and it makes sense. We need to have it embedded to make sure it works on private networks and in places where ipfs.io might be blocked, as well as when there is some DNS error.

[lidel]

To remove user confusion we should change API provider in web extension context from:

to: