[meta] decoupling from ipfs-webui

Just writing down some thoughts and concerns, needs more analysis, probably can be split into 2-3 phases.

Right now ipfs-desktop is tightly coupled with ipfs-webui:

1. ships with a bundled version of ipfs-webui
2. opens bundled webui in Electron’s webview
3. injects own settings into Settings screen of ipfs-webui

I believe it comes at significant maintenance cost and user confustion:

• requires ipfs-webui to support Electron “browser” and things such as drag&drop broke in Electron before (#1287)
• every time new setting is added, ipfs-desktop release is blocked by ipfs-webui, and same for bugfixes (eg. https://github.com/ipfs-shipyard/ipfs-desktop/issues/1290)
• running Electron webview in the background wastes CPU and memory (not as much since it is now “paused” by switching to a blank subpage - https://github.com/ipfs-shipyard/ipfs-desktop/pull/1198 - but still wasteful)
• when user opens webui from commandline or via browser extension they see the same ipfs-webui, but when they go to Settings ipfs-desktop options are not there (they are there only if webui is opened via ipfs-desktop menubar)

I suspect we could consider:

• remove Desktop-specific items from Settings screen in webui, and put them in menubar submenu instead
• opening webui from http://127.0.0.1:8080/webui instead of webui://- pseudoprotocol
  • ensure offline use case works: if we stop bundling webui with ipfs-desktop and open webui in a web browser, then we need to ensure the proper CID is already in the repo
    • we have prior art of doing just that in Brave: ipfs-companion is bundling TAR archive for webui CID and during the startup in Brave checks if it is present in the repo, in not, it imports data from the TAR. Code in precache.js . This ensures webui is always present, and fast, even if initial load happened in “airplane mode”.
• opening in real web browser instead of Electron

[Gozala]

My general sentiment is electron window wrapper just hides ugly url, and I would much rather try to address that core problem instead of hiding it with dedicated window.

Here is where I wish and hope we can end up one day:

• webui.ipfs.io (or some other address) is a canonical place to access your IPFS node.
• webui.ipfs.io uses service worker so that it continues to work after first load even if
  • Domain got blocked.
  • Even if user is offline.
• webui.ipfs.io detects if ipfs-desktop isn’t running (by pinging localhost) and offers you to install it to enhance experience.
  • It communicates really clearly what the benefits are for user personally and network overall
• webui.ipfs.io isn’t special, you can deploy same page on other domain and it will function just the same.
  • In fact it is deployed across all IPFS nodes that have domain name
  • Local IPFS node can discover more deployments from peers it connects to.
• webui.ipfs.io (and other deployments) can overcome CORS restrictions imposed by HTTP API by requesting a permission via HTTP request. IPFS desktop grants or denies permission by consulting user via system prompt.
• Other deployments of webui.ipfs.io could ask ipfs-desktop to be a default UI so that:
  • I could make webui.gozala.io be my default instead.
  • I could switch to beta or nightly channels of webui’s or even stick to some pinned CID version.
• IPFS Desktop can pass communication address to webui.* (via #hash link or such) so that non-standard port or hosts would work as well.
  • IPFS Desktop can detect when opening a webui has failed (because no callback has occured) and provides troubleshooting system UI.
    • If for whatever reason webui.alt.io is no longer accessible troubleshooting UI can offer to try different alternatives (form the list e.g. https://webui.ipfs.io, https://webui.pinata.cloud/, https://webui.ipfs.io.ipns.localhost:8080` etc) and helps user report the problem in some ways. (in fact troubleshooting could probably be automated by loading diff options in hidden browser window etc…)

That way we can have deliver experience that is:

1. Most familiar from the conventional web. Almost like dropbox.
2. In browsers that don’t support IPFS natively experience is enhanced via IPFS Desktop (e.g. in brave we may not even offer installing IPFS desktop, and on mobile we may look for some alternative way e.g. delagate to desktop ??)
3. It is resilient to censorship because there can be many deployments that troubleshooting process can help you discover.
4. It works offline because service workers rock!
5. If all fails we do still have a localhost based fallback assuming IPFS desktop is there.
6. We and the wider community are enabled to experiment with alternative UIs and empower user with choice.

[lidel]

For the record, we successfully decoupled codebases 🥳

• Desktop settings were removed from WebUI and are now in tray icon’s menu (https://github.com/ipfs-shipyard/ipfs-desktop/pull/1640, https://github.com/ipfs-shipyard/ipfs-webui/pull/1628)
• Also removed special-casing for folder import Electron (https://github.com/ipfs-shipyard/ipfs-webui/pull/1628), regular Web API is used now.

---

Remaining question:

is this level opf decoupling enough, or do we want ditch Electron’s BrowserWindow and start opening webui in real web browser instead of Electron window?

Analysis below. Would appreciate your thoughts @rafaelramalho19 @jessicaschilling @Gozala TLDR at the end 😉

---

I thought the main challenge with opening webui in regular browser is Origin isolation, but the longer I think about it, the more UX issues I see. Below is my brain dump with 💚 upsides, 💔 downsides, 🛑 deal-breakers, and 🔧 additional work.

If we use WebUI version bundled with go-ipfs (:5001/webui)

• 💚 This removes the need for testing webui in Desktop, as this version is already tested before go-ipfs release
• 💚 does not require localhost subdomain for security isolation
  • it will work on every platform without the need for installing IPFS Companion or manually setting HTTP proxy
• 💔 the URL in address bar will be fugly
• 💔 we are unable to ship new webui without waiting for new go-ipfs

If we use different version…

• 💚 This gives us the same control over webui version as we have right now
• 💔 requires localhost subdomain for security isolation
  • 🛑 subdomains on localhost are not supported on some platforms and require IPFS Companion or manually setting HTTP proxy (https://github.com/ipfs/go-ipfs/issues/7527). we expect this to get better (there are ongoing issues/discussions for better localhost support in Firefox and Safari), but ETA is unknown.
• 🔧 Desktop needs to safelist specific origin by setting proper CORS headers in go-ipfs’ config
• 🔧 Desktop needs a way of passing API port address to WebUI via #hash (API port could be different than :5001)
• …specified by CID (<cid>.ipfs.localhost:8080)
  • 💔 the URL in address bar will be fugly
  • 💚 works in offline environment, no dependency on DNS
• …specified by DNSLink (webui.ipfs.io.ipns.localhost:8080)
  • 💚 the URL in address bar looks okay-ish (starts with webui.ipfs..)
  • 🛑 breaks in offline environment or when ipfs.io is censored at DNS level

---

TLDR I think we should keep bundling webui and opening in Electron for now, as it is the least painful option right now.

Opening in regular browser will break for some users if we do it by default, unless we stick with version behind /webui on API port, which in turn forbids us from shipping new webui independently of go-ipfs, slowing down our release cycle.

What we could do is to introduce opt-in experiment that “opens the latest webui (DNSLink) in default browser”.