Clean up the UX of using a remote note

[andrasfuchs]

• OS: Windows 10
• Version of IPFS Desktop: 0.16.2

Describe the bug When I open the IPFS Desktop it shows my local node correctly even after I change the API port to 5001, 5005 or 5055. I also have a remote node running on my LAN (IP: 192.168.1.36) with the API port of 5005. I can access my remote node only if my local API port setting is the same as the remote's.

To Reproduce Steps to reproduce the behavior:

1. Go to 'Settings'
2. Change the API port to a random port in the IPFS Config section
3. Restart the local node.
4. Go to 'Settings'
5. Change the address to your remote node's address and API port ("http://192.168.1.36:5005" or "/ip4/192.168.1.36/tcp/5005" in my case)
6. Make sure that the random port you selected in step 2 doesn't match the API port number of your remote node
7. You will not be able to reach the node

Expected behavior I would expect to see my remote node when I enter its address in Settings and click on Submit.

Screenshots

Additional context I tested my remote node with Postman and accessing it with its LAN address and public address worked both fine. IPFS.io also returned my files without any problems, so it's definitely running correctly.

[lidel]

Thank you for reporting this.

In short, we do not support running ipfs-desktop against a remote node correctly, and the fact that you were able to change API port is a bug. Using a remote node in LAN is not something most of our GUI users will want to do, and it introduces issues such as mixed content warning in browsers, when using a LAN gateway without TLS – bad UX in general, not something we should endorse in GUI app.

How to solve UX issues

I believe we should hide the section that allows for changing the API address in ipfs-webui when running inside of Electron run by ipfs-desktop, as it only opens a surface for misconfiguration and detaching ipfs-webui from go-ipfs run by ipfs-desktop.

The proper way for running against a remote node would be checking existence of $IPFS_PATH/api and connecting to the addr there – this is what ipfs commands on the CLI already does.

In your case, it would be:

echo "/ip4/192.168.1.36/tcp/5005" > ~/.ipfs/api

TODO

Final thoughts on TODOs here:

• [x] MVP fix here is to hide API section from ipfs-webui when it runs inside fo ipfs-desktop window
  • done in https://github.com/ipfs/ipfs-webui/pull/1835
• [ ] ensure ipfs-desktop points ipfs-webui at addr from $IPFS_PATH/api
  • ipfs-webui checks for presence of a special key in window.localStorage, and uses value as API addr, if present
  • afaik ipfs-desktop is already smart enough to detect $IPFS_PATH/api exist when it starts, and use it instead of spawning own instance – perhaps it already sets the right API addr for webui – needs checking

[TinyTb]

backlog grooming: Closing due to inactivity on this low-priority issue.