Detect and manage embedded go-ipfs in Brave

[lidel]

This supersedes embedded js-ipfs (#716)

Brave Nightly will ship embedded go-ipfs soon and will expose some API endpoints for ipfs-companion to facilitate end-to-end integration. Custom WebExtension APIs will enable ipfs-companion to:

• read user preference on how to load IPFS resources (public gw, local gw, embedded one, disabled)
• read $IPFS_PATH/config of embedded go-ipfs node managed by Brave
• start/stop the node

We should at the very minimum:

• add embedded go-ipfs to the list, if user enabled it in brave
• on initial run, use embedded node as a fallback
  • detect when embedded go-ipfs running, and save it as the default instead of 5001/8080 one
  • this should be fallback, we dont want to break Brave users who already use ipfs-companion+ipfs-desktop

TBD:

• start (and stop?) embedded node when user switches Node Type in Companion's Preferences
• hide/migrate embedded js-ipfs to embedded go-ipfs

Details

Excerpt from brave/brave-browser#10220:

// Checks if a feature flag is enabled
chrome.ipfs.getIPFSEnabled((enabled: boolean) => {})

// Obtains a string representation of the resolve method
// method is one of the following strings:
// "ask" uses a gateway but also prompts them to install a local node
// "gateway" uses a gateway but also prompts them to install a local node
// "local" uses a gateway but also prompts them to install a local node
// "disabled" uses a gateway but also prompts them to install a local node
// Throws an error if IPFS feature flag is not enabled
chrome.ipfs.getResolveMethodType((method: string) => {})

// Launches a daemon
// Throws an error if IPFS feature flag is not enabled
// Throws an error if a local node is not installed
chrome.ipfs.launch((success: boolean) => {})

// Shutsdown a daemon
// Throws an error if IPFS feature flag is not enabled
// Throws an error if a local node is not installed
chrome.ipfs.shutdown((success: boolean) => {})

// Obtains the config contents of the local IPFS node
// Throws an error if IPFS feature flag is not enabled
// Throws an error if a local node is not installed
chrome.ipfs.getConfig((success: boolean, config: string) => {})

// Checks if the local node is installed
chrome.ipfs.getExecutableAvailable((available: boolean) => {})

chrome.ipfs.* behavior in Brave Nightly @ v1.20.36

• getIPFSEnabled is enabled by default in Nightly, but we should check it as a formality
• getResolveMethodType is the actual hint of user's preference
  • ask is the default on an empty profile
  • local – after "Enable IPFS" is clicked and go-ipfs daemon got installed
• launch
  • the weird one. returns false but also triggers install in the background, when claled later (after install is done) it starts node and returns true, but does not change resolveMethodType (it is still ask)
    • filled chrome.ipfs: launch|shutdown should control getResolveMethodType brave/brave-browser#13237 to clarify if it is a feature or a bug
• shutdown always returns true (even if node was already off)
• getExecutableAvailableget returns true after install

References

• Native IPFS support in Brave: Native IPFS support in Brave brave/brave-browser#10220

[lidel]

Quick mockup + temperature check on leveraging Brave colors (https://brave.com/brave-branding-assets/) to indicate when Node is controlled by the browser itself:

Is there a more subtle way?

[jessicaschilling]

How about a tiny Brave lion to the left of the box(es) in question? Otherwise the color looks a bit like an error state.

Plus if we wanted to be really fancy the lion could be orange or purple, depending on if regular or nightly Brave.

Would add a hover state for the icon, too: "Managed by Brave".

[lidel]

@jessicaschilling I was playing with various versions and ended up with the lion inside the input (background-image) on the right – feels the least intrusive and does not require any special-casing in existing layout:

border →	no border →	muted background to indicate read-only

Final version on the right.

Thoughts? Should we keep the orange border, or is the lion enough?

[jessicaschilling]

Muted background is great - and no need to keep the orange border.
I might move the lion to the left, though - parses better on wide screens, and is in line with the "icon indicator + value" convention in the browser URI bar.