Improve Kubo - Companion Docs

[whizzzkid]

Checklist

• I am reporting a documentation issue in this repo, not https://docs.ipfs.tech.
• I have searched on the issue tracker for my issue.

Location

No response

Description

A few interesting points came up: https://www.reddit.com/r/ipfs/comments/145inx4/just_tried_ipfs_a_few_thoughts/

I believe we should cover possible scenarios and setup guides to make pairing companion with kubo easy.

1. cover different setup types.
2. cover a few possible scenarios.
3. issues around CORS issue.

relates to:

• Fix Companion docs #1207 Relavant info can be added along with this.
• Figure out HTTP RPC API access with Manifest V3 #1036 if we can automate pairing and introduce profiles which allows for configuring multiple instances that can possibly resolve a bunch of these issues.

[lidel]

I'm moving this back to ipfs-companion, as it does not seem to be actionable from the perspective of Kubo repository
(imo Kubo repo should not have documentation related to companion, just like we don't have anything about ipfs-desktop, ipfsd-ctl, ipfs-cluster or any other project that uses Kubo – such docs belong to repo of respective project)

---

As for configuring Companion to work with non-localhost node, my suggestion is to be conservative:

• Companion is a GUI application that should "just work"
• We should NOT ask people to set CORS headers for ipfs-companion to function correctly
  • Setting CORS to safelist RPC port access is hard for a reason: this is a power user feature that comes with security risk, VERY easy to give admin access to RPC port to every website on the internet.
    • Kubo has no access control mechanism beyond CORS atm, and until some way of guarding it like API Tokens kubo#1532 is resolved, using RPC outside a controlled environment of localhost is considered a power user feature, aka "use at your own risk".

👉 By looking at the reddit post, it sounds like what IPFS Companion could do, is to have more meaningful error message when non-localhost RPC or Gateway is used. It should explain security (CORS giving admin access to RPC API) and/or interop ramifications (non-localhost cleartext http:// gateway causing mixed-content errors IF subresources are redirected).

[..] shows ipfs not running even though I am using a kubo rpc install on the local network. #

This sounds like a bug?

• in Chromium, this should be handled by either safe listing extension ID (already done in fix: allow ipfs-companion browser extension to access RPC API kubo#8690),
• in Firefox the code for adjusting the Origin HTTP header takes care of it, already in ipfs-companion/../ipfs-request.js#L227-L260

[crotel]

How about add virtual network for API isolation. like through zerotier-like intranet for using api remotely, while local computer at same network, then put the other ports public if one-self wanted, which like gateway, swarm etc,.?
maybe this way should link the cluster together in more safe way?