feat: Specify IPFS node on the network instead of running localy

[IngwiePhoenix]

Is your feature request related to a problem? Please describe.
I couldn't find it in the app itself, so I thought I'd take it here.

I run an IPFS node on the network which is also always reachable through VPN. Since this also has the most storage available, I would love to just use IPFS Desktop as a client, rather than an individual node.

Is there a good way to do that? If not, this is my feature request. :)

Describe the solution you'd like
Aside from selecting a custom IPFS binary, also allow selecting if a local or remote node should be used.

Describe alternatives you've considered
Allow to set a config option to do this instead.

Additional context
None I could think of, sorry.

Tasks

Preview Give feedback

1. Create a config option to decouple kubo install/startup
2. Create config option to accept IPFS node URL and validate all APIs are serviceable.
3. Perfrom capability check and serve requests using remote IPFS node.
4. [Maybe] Better Error Handling Around ipfsd-ctl #2546
5. [Optional Enhancement] Pairing mode for desktop with remote IPFS node.
6. [Optional Enhancement] Support multiple instances of IPFS node in tabbed/dropdown mode.
7. [Optional Enhancement] Onboarding flow for users to select how they want IPFS node to be configured.

[whizzzkid]

Thanks for submitting this issue @IngwiePhoenix, did you try using the standalone webui? you can find it here: https://webui.ipfs.io, you can set the API address in the settings: https://webui.ipfs.io/#/settings.

Your node also ships with webui which can be reached here: <host>:<port>/webui. If you've looked at these and it does not serve your purpose, can you please elaborate on what particular desktop feature would you be most interested in?

Thanks!

[IngwiePhoenix]

Hello @whizzkid !

I do use the WebUI to see the settings and adjust the configuration, and for that it is very helpful. However, I really like the convenience of having context menu entries in Windows Explorer to quickly add files to my IPFS node, which I can then use to share files with my friends. The only alternative I have found so far is using ShareX and creating a custom integration that would POST the file to the API endpoint (/add I believe it was? I haven't set it up, I just know it works in theory).

Since I move between my Desktop, Laptop and my Phone a lot, my idea was to use a central IPFS node as the main "gateway" or "service" to share my files with. It is super convenient, after all.

For now, I have just uploaded files via the WebUI manually for the time being. But in the future, I would like to be able to just use the context menu entry instead to do so.

Thanks!

[whizzkid]

You probably meant @whizzzkid :)

[whizzzkid]

Thanks @IngwiePhoenix for the quick revert, and apologies to whizzkid for unnecessary noise.

Looks like there has been some effort in the past and got shut down:

• Add IPFS implementation selector to settings page #714
• Support for js-ipfs #601

But most of that work was to replace the implementation between go-ipfs (now kubo) and js-ipfs (now helia). The feature request may not be as simple as it looks, as right now ipfs-desktop assumes that there exists a deamon it ships with and can hence just pass the requests to the daemon.

The longer term vision eventually is shaping to ship binaries like the daemon and experiments like punchr on user requests, i.e. ship a light weight ipfs-desktop and onboard the user with either their own node or pull one for them and run it in the background but that's far. In the meantime to support this, we can explore the possibility of turning off daemon and instead request the path to the node.

• Implement UI to turn Daemon off and Instead provide path for self-hosted node.
• Remove API calls (if-any) to the daemon and migrate those to RPC.
• Eventually drop daemon and pull it if needed.

I'd also let @lidel and @SgtPooki to chime in on this.

[IngwiePhoenix]

You probably meant @whizzzkid :)

damnit, derp! XD Sorry for the out of nowhere ping! ^^;

[IngwiePhoenix]

In the meantime to support this, we can explore the possibility of turning off daemon and instead request the path to the node.

Those suggestions sound very much like what I am looking for! :)

One question, just so I got things sorted in my head: When you say API, you mean the one running on $ip:5001, yes? Then, where exactly is the RPC mounted at?

Thank you for your insight!

[whizzzkid]

@IngwiePhoenix yep, that's the RPC api. kubo does not secure/authenticate that endpoint and it's pretty much up to the host to decide how the requests get secured. IIRC there are some efforts underway on kubo to clamp down access to this API, but still no guidance on that.

[IngwiePhoenix]

I see! Well, this shouldn't be a big problem for me; I have a good UFW setup :) Never seen that RPC before though, going to have to look into that!

[SgtPooki]

If you set your gateway api url (your single ipfs node endpoint) in settings, it should try to use that one and not boot up kubo behind the scenes.

E.g. i can run different versions of kubo manually in my terminal (RC and others) and put the url to that one in the settings to use that instead of starting up the kubo version bundled with desktop

[SgtPooki]

received a request via slack today from user asking how to use a centralized node on their network as well.

Is there a way to get IPFS Desktop to talk to a kubo node running on another host instead of run one locally? I'm assuming it runs a local node and then talks to the API endpoint for all of it's UI data. Can I tell it to skip running a local node and instead connect to the API of a node I'm running in my basement data center?

[whizzzkid]

@SgtPooki I added a tasklist to the parent comment Can you validate and if yes, I can create sub issues for those and we can prioritize this in the future.

[BigLep]

General thought: can SSH tunneling be used for this? It would prevent needing to write extra code and keep the security property of not exposing one's Kubo RPC endpoint publicly beyond localhost.

[whizzzkid]

@BigLep I believe this ask is only limited to RPC api exposed responsibly within the local area network, and not exposed to the public internet.

On a different note, I think this should be a feature in kubo which verifies if rpc api is accessible via the public internet and if it is, it should not boot unless a very specific flag is passed.

[BigLep]

I adjusted my message to discuss the security property of not "exposing the Kubo RPC endpoint beyond localhost".

Realistically unless there is a lot of demand here, I don't imagine this feature would get picked up by a core maintainer, especially if there is a way for a user to unblock themselves with an SSH tunnel (which is why I wanted to confirm that an SSH tunnel would meet the need here).