There should be no friction for an app to connect to a locally running IPFS node. It's useful to be able to connect to an IPFS node running on another machine. Companion supports this now, as it used to require an external IPFS node to run, but cannot install one as it is packaged and distributed as a WebExtension.
We should consider not bundling WebUI with go-ipfs (See: #4) as it causes people to open up their api port to the public internet, which is a significant security issue. Rethinking WebUI as an IPFS dashboard / explorer / workbench app (like say a database explorer app) that can configured to connect to any IPFS node, local or remote, and have it display stats and a file browser #9 and IPLD explorer #11 would be really interesting.
I strongly agree with this one. We could have one domain always pointing to the latest version of WebUI which wouldn't depend on the go-ipfs version/release.
There should be no friction for an app to connect to a locally running IPFS node. It's useful to be able to connect to an IPFS node running on another machine. Companion supports this now, as it used to require an external IPFS node to run, but cannot install one as it is packaged and distributed as a WebExtension.
We should consider not bundling WebUI with go-ipfs (See: #4) as it causes people to open up their api port to the public internet, which is a significant security issue. Rethinking WebUI as an IPFS dashboard / explorer / workbench app (like say a database explorer app) that can configured to connect to any IPFS node, local or remote, and have it display stats and a file browser #9 and IPLD explorer #11 would be really interesting.
The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#control-which-ipfs-node-you-connect-to