Ipfs-desktop: [meta] decoupling from ipfs-webui

[lidel]

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

[jessicaschilling]

Is there any reason for the Electron standalone app to exist other than the fact that it comes as part of a convenient package that also installs the daemon and CLI tools?

[lidel]

I believe _raison d'être_ is to

• provide mechanism for updating desktop users to the latest go-ipfs
• provide GUI for starting/stopping IPFS node and opening specific webui screens:

• we also hope to provide OS-specific integrations in the future: #679

[jessicaschilling]

Right. All of which could stand on their own and send the user to webUI as needed ...

[hacdias]

Hey y'all!

remove Desktop-specific items from Settings screen in webui, and put them in menubar submenu instead

Personally, I agree. Most of the options (if not all), are just checkboxes and Electron's menus have support for check-boxes type of things.

Also, by removing Web UI screen, we would simplify the code a lot and just need to open Web UI on user's default browser.

opening in real web browser instead of Electron

I also agree with this. It simplifies a ton of things. There are a few things that'd need to be changed in order for all of this to work, but it would be quite simple.

---

However, I want to mention that this was discussed before (although I can't find any issue about it). I remember we keeping the Electron's window for browser support purposes, i.e., since we ensured that Web UI worked on Electron, anyone could use it.

But I have to say that most modern browsers work well (Firefox, Chrome and Chromium-based browsers). Electron introduces changes to Chromium that often break things.

If this gets decided to be as a to-do thing, I can allocate a bit of time to do this myself on the ipfs-desktop side.

[jessicaschilling]

Linking here to a lengthy round of design discussion that involved talking through what functionality should be included where:
https://github.com/ipfs/ipfs-gui/issues/12
Not suggesting anything in here be acted upon yet, just referencing it here for when the time comes.

[jessicaschilling]

Also, looks like we had a version of a similar discussion a while back:
https://github.com/ipfs/ipfs-gui/issues/41
Linking to it here to facilitate discussion, and for historical context.

[lidel]

Added a quick note from my end: ensure webui works in offline mode

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 ipfs-companion checks if the CID is present in the repo. If not, it imports data from the TAR. Code in precache.js . This ensures webui is always present and fast, even if initial load happens in "airplane mode".

[hacdias]

(Love the idea @lidel!)

[jessicaschilling]

Update: We're doing initial user surveying in https://forms.gle/c6gHP1pVtwtRpzdP7 about how folks feel about the decoupling idea in general. The survey will go out in the 12 May 2020 edition of the weekly IPFS newsletter, and I'll follow up with a link to it in the forums once the newsletter goes out. Will link to artifacts/summaries/etc in this meta-issue rather than opening an issue exclusively for the survey. Watch this space ...

[jessicaschilling]

Survey analysis here: https://docs.google.com/document/d/1V5sDSxMqhhplpcB8u8CffiGWHUvw-t4p_sn5vigdR90/edit#heading=h.9bdsxkml3rtd

TL;dr: While justification may exist for decoupling the standalone Web UI and re-envisioning Desktop as a tray/menubar tool (backed by daemon launch at launch), we have bigger opportunities for improvement right now.

[lidel]

For the record, we successfully decoupled codebases :partying_face:

• 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 :green_heart: upsides, :broken_heart: downsides, :stop_sign: deal-breakers, and :wrench: additional work.

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

• :green_heart: This removes the need for testing webui in Desktop, as this version is already tested before go-ipfs release
• :green_heart: 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
  
  
• :broken_heart: the URL in address bar will be fugly
• :broken_heart: we are unable to ship new webui without waiting for new go-ipfs

If we use different version..

• :green_heart: This gives us the same control over webui version as we have right now
• :broken_heart: requires localhost subdomain for security isolation
  
  
  
  • :stop_sign: 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.
  
  
• :wrench: Desktop needs to safelist specific origin by setting proper CORS headers in go-ipfs' config
• :wrench: 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)
  
  
  
  • :broken_heart: the URL in address bar will be fugly
  
  
  • :green_heart: works in offline environment, no dependency on DNS
  
  
• ..specified by DNSLink (webui.ipfs.io.ipns.localhost:8080)
  
  
  
  • :green_heart: the URL in address bar looks okay-ish (starts with webui.ipfs..)
  
  
  • :stop_sign: 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".

[rafaelramalho19]

💚 This removes the need for testing webui in Desktop, as this version is already tested before go-ipfs release

💭 Not quite true, it could still impact something "taskbar related" and still needs tests in desktop, but for the most part I agree with that.

💭 I really don't like losing control of the release cycle and waiting for go-ipfs to ship the version, I think it will lead to go-ipfs being overwhelmed with our work.

❤️ Personally, I like your last option specified by DNSLink (webui.ipfs.io.ipns.localhost:8080) and if ipfs.io is blocked at DNS level, I guess that's alright, since that's the user option to do so?

❓ Do you have any alternative solutions of taskbar frameworks or should we stick with electron?

[lidel]

if ipfs.io is blocked at DNS level, I guess that's alright, since that's the user option to do so?

Not always. Users in specific countries may have ipfs.io blocked at DNS level against their will, which will produce error page.
However, in those cases, :wrench: we _could_ detect lack of subdomain support and/or lack of DNSLink and use :5001/webui as a fallback.

Do you have any alternative solutions of taskbar frameworks or should we stick with electron?

Nothing comes to mind, need additional research. Mind that removal of Electron is a nuclear option at this point: it means we need to design new build and release pipeline and create contingency for migrating users to the new system.

[jessicaschilling]

Agree with @rafaelramalho19's 💭 bubbles above, but might prefer the solution to use a different version specified by CID. The address bar URL might be awful, but in our world of CIDs we're consistently throwing users long ugly strings. The DNS/offline benefits seem more important than beauty in this case.

That said, agree with your TLDR, @lidel: also remember that the surveys we did earlier indicated far less of a user-driven demand to decouple.

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

You mean _instead_ of the Electron window? This could be cool, and if we were able to track how many folks did this without being too intrusive, that gives us more concrete evidence for any next steps.

[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.