Native IPFS support in Brave #10220

bbondy · 2020-06-11T13:26:43Z

Overview

Before the work described in this issue, Brave supports IPFS through the installation of the IPFS Companion extension. A user can install this extension from the Chrome Web Store, or by toggling a switch in chrome://settings in the Extensions section.

Once IPFS Companion is installed, the user can go to IPFS Companion’s settings and make it use “External + chrome.sockets (experimental)”. This avoids the user needing to manually install a local daemon, and uses js-ipfs instead; however, js-ipfs is behind go-ipfs on several fronts. It would be ideal to use go-ipfs instead of js-ipfs.

Our objective is to seamlessly connect Brave users to the IPFS network, including allowing Brave users to easily use dApps that run on IPFS. This spec describes the handling and installation of the go-ipfs daemon via use of the Brave component update server. The functionality will feel built-in and not require the user to separately install a daemon for full IPFS support out of the box.

Targeted Platforms

Desktop (Windows, macOS, Linux)

Description

The work can be broken down into the following sections:

Native protocol support
IPFS onboarding experience
Installing and updating go-ipfs daemon component
IPFS keyed service and proxy configuration
Processes
Port numbers
Non top level navigations
Settings
Diagnostic page - brave://ipfs
HTTP gateway fallback
Interstitial page when there are no peers
Admin policy
The role of IPFS Companion and new chrome.ipfs API
Landing and shipping code behind a flag
Privacy-Preserving Product Analytics (P3A) (for those that have P3A on)
Guest windows, Tor windows, and incognito windows
Cache clearing (1.20.x and beyond)

Native protocol support

The following 2 protocols will be handled by Brave automatically:
ipfs:// and ipns://

When the user navigates to a URL such as:
ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html

If IPFS is not yet configured, the user will have the IPFS page loaded through the gateway https://dweb.link. The IPFS onboarding experience mentioned below will ask the user if they’d like to install the full node and serve it through a local gateway instead. The ipfs:// and ipns:// URLs in the URL bar will not be preserved unless a local node is used.

If the IPFS full node is installed, the content will be loaded through that node.

Other URL types which would activate this same UI are described here:
https://github.com/ipfs/in-web-browsers/blob/master/ADDRESSING.md

When a user requests via a base58 encoding:
ipfs://QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

It gets redirected to gateway path:
https://dweb.link/ipfs/QmbWqxBEKC3P8tqsKc98xmWNzrzDtRLMiMPL8wBuTGsMnR

And the gateway does the DNS-safe conversion and redirects to base32:
https://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi.ipfs.dweb.link/

The base32 conversion can be done directly as an optimization.

IPFS onboarding experience

An infobar will be displayed when the user navigates to a gateway URL with URL pattern */ipfs/* or */ipns/*:

If the user selects to “Enable IPFS” the go-ipfs component will be installed and the daemon will be used for all future requests. After installation, the infobar goes away and future URL loads will load through the local node.

If the user selects “Settings”, they will be redirected to chrome://settings and they will see the advanced settings available such as using a gateway.

Installing and updating go-ipfs daemon component

The go-ipfs daemon binary will be packaged into a crx file and installable via the component updater. There will be a different package per platform (Windows, macOS, and Linux x64) each with a different component extension ID.

Updates will occur as part of the normal component update flow in Brave described here: https://github.com/brave/brave-browser/wiki/Component-Extensions
If it is installed, you can see it installed here: brave://components/ Use find in page for IPFS.

When a new go-ipfs version is released, it doesn’t need to always be updated in Brave. We’ll start with having a process of Protocol Labs asking Brave to update. When Brave receives a request to update, we’ll run a Jenkins job which packages, signs, and publishes a new component. The binary will be pulled from Protocol Labs at https://dist.ipfs.io/go-ipfs.

ipfs.bravesoftware.com should be used so that if an antivirus wants to block IPFS, then it can do so without blocking Brave completely.

Code for brave-core-crx-packager can be found here: https://github.com/brave/brave-core-crx-packager/search?q=ipfs

IPFS keyed service and proxy configuration

A new Chromium keyed service and related code will be added inside of brave/components/ipfs/ to manage the go-ipfs daemon.

A SOCKS5 proxy is not needed, we instead map URL traffic to http://{cid}.ipfs.localhost:<port>
Default ports are changed as to not conflict with a previously installed go-ipfs node on a user's machine.

Processes

There are 3 processes that come into play:

Browser process
Utility: IPFS Service process (visible from Chromium task manager)
go-ipfs process (visible outside of Chromium)

All of the Brave code that is added is browser process level code.
Brave will also start the utility process which is sandboxed and who's sole purpose is to manage the go-ipfs process.

Both the Utility process and go-ipfs process will only be started when IPFS is being used. It will be lazily started.

Similar to how Tor is handled, there is handling for if go-ipfs crashes.

Port numbers

go-ipfs starts 3 different TCP listening sockets:

API port
Gateway port
Swarm port

Brave Nightly, Dev, Beta, and Release each use different port numbers for each of those 3 sockets. So they should all be able to be used at the same time. The ports used are also not default, so they shouldn't conflict with a user that already has go-ipfs installed manually.

Non top level navigations

Subresources are allowed to use the ipfs:// and ipns:// schemes, and the handling can be found here.

Subresources with the ipfs and ipns scheme can only be loaded from within a top level scheme that is also ipfs and ipns. So for example, an http page cannot load an ipfs scheme image. However an ipfs scheme can load http resources.

Settings

In addition to the toggle that already exists in brave://settings, we will have:

A drop down which allows the change how Brave resolves ipfs and ipns URLS. The user can select between Ask, Gateway, Local node, Disabled. The Local node option only shows up when it is installed.
A setting which will allow the user to select which gateway to use
A setting which allows the user to fallback to the public gateway when a local node cannot be accessed.
A setting which will allow the user to turn on automatic redirection of IPFS gateway resources to use the local node instead.

Diagnostic page - brave://ipfs

To help troubleshoot IPFS in Brave, and to see daemon status, a new Chromium WebUI page is added.

This page will show if the IPFS daemon is started, and allow a user to start / stop the IPFS daemon.
It will also show the API, gateway, and swarm addresses.

A user will be able to get at standard output from the go-ipfs daemon inside this page. (Not implemented yet)
The user will have the ability to pass environment variables the user specifies, so that things like log verbosity can be changed. (Not implemented yet)

This page will also get API info from the local API endpoint:
https://docs-beta.ipfs.io/reference/http/api/
In particular for example, the number of peers:
https://docs-beta.ipfs.io/reference/http/api/#api-v0-swarm-peers

HTTP gateway fallback

If the user chooses in chrome://settings to use a gateway instead of a local go-ipfs node, then all requests to ipfs:// and similar will be redirected to the configured IPFS gateway.

Interstitial page when there are no peers

If there are no peers but an IPFS or IPNS URL is accessed, an interstitial page (such as bad SSL certificate) will be displayed telling the user that the node doesn’t seem to be started or there are no connected peers. An option will be given on the page to use the default gateway fallback and to continue to do so automatically in the future when there are no peers.

Admin policy

A top level IPFS enabled setting will be added and tied to an admin policy to completely disable all IPFS detection and functionality.

Browser tests will be added to browser/policy/brave_policy_browsertest.cc

The role of IPFS Companion and new chrome.ipfs API

IPFS Companion will be compatible but not required to be installed. We’ll leave it to Protocol Labs to optionally enhance IPFS Companion but we’ll assist via adding APIs that would be helpful.

Installing IPFS Companion will be a separate action and will not be bundled with the installation of the go-ipfs binary. Users will continue to get updates from the Chrome Web Store and can continue to install IPFS Companion from chrome://settings.

The following new API have been exposed to IPFS Companion only:

// 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) => {})

Landing and shipping code behind a flag

In order to land code and not wait for the entire feature to be implemented, we’ll start by adding a flag in chrome://flags which will allow you to toggle on the experimental IPFS support.

Privacy-Preserving Product Analytics (P3A)

Pending review approval by the privacy team:

IPFS companion installed? i) No, ii) Yes
How many lifetime times are IPFS detection prompts shown without installing? i) 0 times, ii) 1, iii) 2-5 times, iv) 5+ times or more?
IPFS Gateway setting - Ask (0), Gateway (1), Local Node (2), Disabled (3)
How long did the IPFS daemon run? i) 0-5min, i) 5-60min, ii) 1h-24h, iii) 24h+?

Guest windows, Tor windows, and incognito windows

To avoid leaking IPs and other potential privacy issues, we've disable this feature in Tor windows.
Guest windows and Incognito windows also should not load IPFS and IPNS URIs on the local node since it would store content that is accessed.

Cache clearing (1.20.x and beyond)

When clearing cache in Brave, we automatically run ipfs repo gc.
Since this does not support time based deletions, we will clear the cache no matter which time interval is used.
Pinned items will be retained.

QA Plan

Settings:

Make sure each IPFS setting functions immediately on the next page load as the changes are made.
Check settings for how to resolve IPFS URIs
- Setting it to Gateway before installing should stop showing the infobar
- Setting it to disabled should not allow ipfs:// URIs to be loaded at all (being tracked in IPFS resolve type of disabled should disable #13472)
- After go-ipfs is installed, make sure Gatweay and local resolve correctly
- When a local node is configured, it should keep ipfs:// in the URL bar. When a gateway IPFS node is used, it should show the gateway address even if you try to load from an ipfs:// URI.
  - When clicking a link from an ipfs:// page, it should still show ipfs:// in the URL bar if it was linking to a relative

Basic checks:

Make sure navigating to an ipfs:// URL prompts for installing
Make sure navigating to an ipns:// URL prompts for installing
Make sure navigating to an https:// URL with /ipfs/[CID] prompts for installing only for the dweb.link IPFS gateway
Make sure navigating to an https:// URL with /ipns/[CID] prompts for installing only for the dweb.link IPFS gateway
Make sure Guest windows and Incognito windows cannot load IPFS URLs (Open blocking issue here IPFS and IPNS should not resolve in guest and incognito contexts #13463)
Make sure Tor windows do not load IPFS URLs
Make sure loading an ipfs:// URL works correctly after IPFS is installed
Make sure session restore works correctly with a tab left open with ipfs://
Should be able to use ipfs:// local node from every channel (Release, Beta, Nightly) at the same time. (They all use different ports)

WebUI page:

You can use chrome://ipfs to see the status of things
You can click to start and stop the node.
This page is only meant for support / debugging though. Things like not automatically updating without a reload and making the page more usable doesn't need to be posted.

Lazy loading:

Restarting the browser should not load the IPFS process in task manager
- But a navigation to an IPFS resource should start it.

Subresource testing:

You can test these by following these steps: subresources.txt
- ipfs page should allow other ipfs subresources to be loaded within it
- http page should not allow ipfs subresources within it
- fetch should work on an IPFS page

IPFS Companion:

Protocol Labs has a newer version that detects Brave and shows a panel about how to use the Brave node. I'm not sure if it is release yet. For our QA we should just make sure at least that having it installed doesn't cause any problems.

P3A:

I verified all of the P3A issues already, no need to test that.

API:

I verified the exposed APIs and Protocol Labs is using them already in IPFS Companion, no need to test that.

There are 3 issues that landed in past milestones, but they were originally marked as QA/No because the feature was disabled.

These should be tested according to the following test plans:

Admin policy test plan:
- Add IPFSEnabled policy to control IPFS feature brave-core#6966 (comment)
When there are no peers connected, should an interstitial page.
- Display IPFS interstitial page when failed to use local node brave-core#6782 (comment)
Different origins shouldn't be able to set cookies
- Separate origins and cookies for different IPFS CID brave-core#7046 (comment)

Here are some example gateway URLs:

An HTTPS default IPFS gateway URL
An HTTPS non-default IPFS gateway
An IPFS scheme URI ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html (not a link because github markdown doesn't allow ipfs://)
An IPNS URI: ipns://Qmc9xb2cgWKgz8rCBihag6fmvvEu7B7nbmYPxD6RcFXe1Z

Talking to the IPFS node:

Create a test.txt file with "hello" inside of it.

tamarin:1.0.2 bbondy$ echo hello > test.txt

Add that file to your IPFS node
Note: Check which API port in chrome://ipfs and adjust accordingly.

tamarin:1.0.2 bbondy$ ./go-ipfs_v0.6.0_darwin-amd64 --api=/ip4/127.0.0.1/tcp/45004 add test.txt
added QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN test.txt
6 B / 6 B > [=============================================================================================================================================] > 100.00%

You can now load this file in the browser, or from anywhere on IPFS by loading:

ipfs://QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN

It will be slower if you are loading from a different node.

You can find this binary inside your profile directory. The profile dir and component ID folder name differs depending on which platform you are on.

tamarin:1.0.2 bbondy$ pwd
/Users/bbondy/Library/Application Support/BraveSoftware/Brave-Browser-Beta/nljcddpbnaianmglkpkneakjaapinabi/1.0.2

You can publish an IPFS CID to IPNS using a command like this:

tamarin:1.0.2 bbondy$ ./go-ipfs_v0.6.0_darwin-amd64 --api=/ip4/127.0.0.1/tcp/45002 name publish /ipfs/QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN
Published to Qmc9xb2cgWKgz8rCBihag6fmvvEu7B7nbmYPxD6RcFXe1Z: /ipfs/QmZULkCELmmk5XNfCgTnCyFgAVxBRBXyDHGGMVoLFLiXEN

Then you can load it with ipns://Qmc9xb2cgWKgz8rCBihag6fmvvEu7B7nbmYPxD6RcFXe1Z

More go-ipfs command line info can be learnt here: https://docs.ipfs.io/reference/cli/

The text was updated successfully, but these errors were encountered:

experiencedft · 2020-10-31T13:20:36Z

What's the current status of this implementation? Can we expect native IPFS support and/or verification of IPFS hashes that appear in trusted gateways URLs any time soon?

On a sidenote, it would be great to pair this with native ENS domains support, in such a way that after searching for "website.eth" resolving to an IPFS hash, the address bar would keep displaying "website.eth" instead of the unreadable IPFS has.

bbondy · 2020-11-02T15:45:35Z

Most of this is implemented, you can test it out by enabling it here brave://flags/#brave-ipfs
We're tracking ENS support separately.

experiencedft · 2020-11-02T22:09:17Z

Thank you @bbondy I shall try this myself soon. Is this a full IPFS integration, just trusted gateway IPFS hash verification or both?

Also, could you point me to the issue where ENS support is discussed?

Thanks.

bbondy · 2020-11-04T16:47:05Z

@experiencedft you can set it to use a public gateway behind the scenes or a local gateway. In either case the CID will be verified against the content hash before the content is served.

The ENS issue is tracked here:
#11708

experiencedft · 2020-11-05T10:03:38Z

By local gateway, it is meant that IPFS must be installed separately right? My understanding of fully native IPFS integration on Brave would be that the browser itself would integrate an IPFS node. Is that the case?

Sorry about all the questions I'm just very excited about the potential of a decentralized and transparent transfer protocol and looking forward to it being seemless for non tech users.

ilyaigpetrov · 2020-11-05T10:10:28Z

@experiencedft, please, read the very first message of this thread:

When the user navigates to a URL such as:
ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html

If IPFS is not yet configured, the user will have the IPFS page loaded through the gateway https://dweb.link. The IPFS onboarding experience mentioned below will ask the user if they’d like to install the full node and serve it through a local gateway instead. The ipfs:// and ipns:// URLs in the URL bar will not be preserved unless a local node is used.

If the IPFS full node is installed, the content will be loaded through that node.

And also look at IPFS onboarding experience section of the first message in this thread, it has a screenshot. IPFS daemon will be installed and launched by Brave, no need to install it yourself.

experiencedft · 2020-11-05T10:32:27Z

Thank you @ilyaigpetrov. I understand that this is indeed a goal in the context of this issue as per the first message of this thread -- my inquiry was about the current state of the implementation seeing as bbondy said "most of it" was implemented without explaining precisely the extent, which obviously I understand considering the team has a lot on their plates. Sorry if this is obvious to others.

The best way to go would probably be to test it myself from that point and wait for further releases. Thanks everyone for the replies!

bbondy · 2020-11-05T22:03:57Z

No manual installs needed, but if you pick to use a local node it will silently setup a for Brave use only go-ipfs node, it's quite easy to use. Just enable it on brave://flags/#brave-ipfs and then visit an IPFS resource like:
ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html
More communication to come about it once it gets enabled by default on Nightly, and probably a blog post once it is on Release channel.

ilyaigpetrov · 2020-11-06T06:50:18Z

Please, fix #12015 before shipping native IPFS with the Release channel.
Thanks.

LaurenWags · 2021-01-12T20:15:14Z

Verification passed using builds below:

Brave	1.19.81 Chromium: 87.0.4280.141 (Official Build) dev (x86_64)
Revision	9f05d1d9ee7483a73e9fe91ddcb8274ebcec9d7f-refs/branch-heads/4280@{#2007}
OS	macOS Version 10.15.7 (Build 19H15)

Settings

Prior to install, confirmed no ipfs component exists on brave://components. After install, component is added:

Confirmed setting "Method to resolve IPFS resources" to "Gateway" prior to install did not show infobar when visiting a page such as ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html which resolved to https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html.

Confirmed setting "Method to resolve IPFS resources" to "Disabled" and visiting a ipfs:// URL such as ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html did not load the link via the gateway.

Additional testing of "Method to resolve IPFS resources" can be found under #12978 (comment)

Confirmed after IPFS is installed via infobar, I am able to visit both ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html (ipfs:// is preserved) and https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html (over gateway) without issue.

Confirmed when "Method to resolve IPFS resources" is "Local node" and I visit a URL with ipfs:// scheme, it is preserved. Additionally, clicking on links from this page preserves ipfs:// in URL bar.

Encountered logged issue #13171 while testing.

Basic Checks

Using clean profile, confirmed navigating to an ipfs:// URL prompts to install via infobar.

Using clean profile, confirmed navigating to an ipns:// URL prompts to install via infobar.

Using clean profile, confirmed navigating to an https:// URL with /ipfs/[CID] prompts to install on the dweb.link IPFS gateway

Using clean profile, confirmed navigating to an https:// URL with /ipns/[CID] prompts to install on the dweb.link IPFS gateway

Using clean profile, confirmed navigating to an https:// URL with /ipfs/[CID] on non default gateway does not prompt for install via infobar.

Confirmed Guest, Private, and Tor windows cannot load ipfs URLs. See additional testing notes listed under #12978 (comment).

Confirmed loading an ipfs:// URL works correctly after IPFS is installed

Confirmed loading an ipns:// URL works correctly after IPFS is installed

Confirmed session restore works correctly when a single tab is left open, active with an ipfs:// URL.

Confirmed session restore works correctly when a single tab is left open, in the background with an ipfs:// URL.

Confirmed session restore works correctly when a single tab is left open, active with an ipns:// URL.

Confirmed session restore works correctly when a single tab is left open, in the background with an ipns:// URL.

Encountered and logged #13519 - if you have multiple ipfs:// or ipns:// tabs open in background (not active) on relaunch, usually at least one of them will not connect. Refresh of the affected tab fixes this.

Confirmed able to use ipfs:// local node using Beta, Dev, Nightly channels simultaneously. Confirmed different ports used for each channel:

Nightly	Dev	Beta

WebUI page

Confirmed chrome://ipfs, about://ipfs resolve to brave://ipfs

Confirmed this page shows status.

Not installed	Installed	Node stopped	Node started

Lazy Loading

Confirmed restarting the browser does not load IPFS process in Task Manager or Activity Monitor:

Task Manager	Activity Monitor

Confirmed navigating to IPFS resource loads process in Task Manager and Activity Monitor:

Task Manager	Activity Monitor

IPFS Companion

Confirmed with ipfs installed (Method to resolve = local node) I was able to install IPFS Companion and visit ipfs:// URLs without issue.

Interstitial Page

Confirmed interstitial page:

Testing N/A for: P3A, API per #10220 (comment)

Subresource testing

Created test.html file per directions in txt file under Subresource testing.
Launched simple web server per instructions.
Launched Dev and loaded http://localhost:8080/test.html.
Confirmed items did not load:

Closed Brave.
Created a folder called "test" in Library/Application Support/BraveSoftware/Brave-Browser-Beta/nljcddpbnaianmglkpkneakjaapinabi/1.0.3 and moved the test.html file to this folder.
Launched Dev and installed IPFS via infobar.
Went back to terminal and entered the following commands:

lauren$ cd Library/Application\ Support/BraveSoftware/Brave-Browser-Dev/nljcddpbnaianmglkpkneakjaapinabi/1.0.3
lauren$ ./go-ipfs_v0.7.0_darwin-amd64 --api=/ip4/127.0.0.1/tcp/45003 add -r ./test
added QmZcCnvw52Xxmfi6s3En6qChja35ewEmrv8qtVTqKX1yAG test/test.html
added QmdunmQi4mUWc2sDUDGjKhNca9YnFUSVKEkrrGLDVZXaB4 test
 597 B / 597 B [=======================================================] 100.00%

Note - my component version, go-ipfs version, and port differ from the example and are reflected above.

Go back to Dev and load ipfs://QmZcCnvw52Xxmfi6s3En6qChja35ewEmrv8qtVTqKX1yAG

Confirmed that for "Method to resolve IPFS resources" = Local Node, the above page resolves:

Confirmed that for "Method to resolve IPFS resources" = Gateway, the above page resolves:

Brave	1.19.82 Chromium: 88.0.4324.79 (Official Build) dev (x86_64)
Revision	bd1e9353659b2491dac971226a973ca3b5684a14-refs/branch-heads/4324@{#1520}
OS	macOS Version 10.15.7 (Build 19H15)

Linked issue testing

Admin policy for IPFS Add IPFSEnabled policy to control IPFS feature brave-core#6966 (comment) - no manual testing for macOS, confirmed with Jocelyn
Create an interstitial page for when there are no IPFS peers Display IPFS interstitial page when failed to use local node brave-core#6782 (comment)

From Step 4, confirmed interstitial page shown (note, used different link and confirmed with Jocelyn this is ok).
From Step 5, confirmed expected info on brave://ipfs page.

Step 4	Step 5

Steps 7 & 8 could not be tested on 1.19.82 as they regressed (they do work on 1.19.81). Logged #13544 for this.

Separate origins and cookies for different IPFS CID Separate origins and cookies for different IPFS CID brave-core#7046 (comment)

From Step 4, confirmed daemon is launched on brave://ipfs.

From Step 5, confirmed origin on page as origin= http://bafkreifik2tbj5esf74sf2qwft2x3vuxaqmthwh3d2qx6abpcroirqpt7i.ipfs.localhost:48082.
From Step 6, confirmed document.cookie result.

Step 5	Step 6

From Step 7, confirmed document.cookie result on different page.

From Step 8, confirmed origin on page as origin: "http://en.wikipedia-on-ipfs.org.ipns.localhost:48082" from dev tools.
From Step 9, confirmed document.cookie result.

Step 8	Step 9

Talking to the IPFS node

Created test.txt file with some text in it:

lauren$ cd Library/Application\ Support/BraveSoftware/Brave-Browser-Dev/nljcddpbnaianmglkpkneakjaapinabi/1.0.3/
lauren$ echo heyallyoucoolcatsandkittens > test.txt

Added file to IPFS node:

lauren$ ./go-ipfs_v0.7.0_darwin-amd64 --api=/ip4/127.0.0.1/tcp/45003 add test.txt
added QmQb54jr5pCE3HXsp54kPRR7wCx8NfdJAxFGby3VjgFQYE test.txt
 28 B / 28 B [=========================================================] 100.00%

Loaded ipfs://QmQb54jr5pCE3HXsp54kPRR7wCx8NfdJAxFGby3VjgFQYE

Published IPFS CID to IPNS:

lauren$ ./go-ipfs_v0.7.0_darwin-amd64 --api=/ip4/127.0.0.1/tcp/45003 name publish /ipfs/QmQb54jr5pCE3HXsp54kPRR7wCx8NfdJAxFGby3VjgFQYE
Published to k51qzi5uqu5dgdsdwd2txphi4ptl7f9arqled71uuke9l0yfw7ul835kytawe3: /ipfs/QmQb54jr5pCE3HXsp54kPRR7wCx8NfdJAxFGby3VjgFQYE

Loaded ipns://k51qzi5uqu5dgdsdwd2txphi4ptl7f9arqled71uuke9l0yfw7ul835kytawe3/

Brave | 1.19.83 Chromium: 88.0.4324.79 (Official Build) (x86_64)
-- | --
Revision | bd1e9353659b2491dac971226a973ca3b5684a14-refs/branch-heads/4324@{#1520}
OS | macOS Version 10.15.7 (Build 19H15)

Confirmed able to use ipfs:// local node using Beta, Dev, Nightly channels simultaneously. Confirmed different ports used for each channel

Nightly	Dev	Beta	Release

Reduced checks done on macOS M1 laptop using build below:

Brave | 1.19.82 Chromium: 88.0.4324.79 (Official Build) dev (arm64)
-- | --
Revision | bd1e9353659b2491dac971226a973ca3b5684a14-refs/branch-heads/4324@{#1520}
OS | macOS Version 11.1 (Build 20C69)

Settings

Prior to install, confirmed no ipfs component exists on brave://components. After install, component is added:

Confirmed after IPFS is installed via infobar, I am able to visit both ipfs://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq/wiki/Vincent_van_Gogh.html (ipfs:// is preserved) and https://bafybeiemxf5abjwjbikoz4mc3a3dla6ual3jsgpdr4cjr3oz3evfyavhwq.ipfs.dweb.link/wiki/Vincent_van_Gogh.html (over gateway) without issue.

Confirmed when "Method to resolve IPFS resources" is "Local node" and I visit a URL with ipfs:// scheme, it is preserved. Additionally, clicking on links from this page preserves ipfs:// in URL bar.

Basic Checks

Using clean profile, confirmed navigating to an ipfs:// URL prompts to install via infobar.

Using clean profile, confirmed navigating to an ipns:// URL prompts to install via infobar.

Using clean profile, confirmed navigating to an https:// URL with /ipfs/[CID] prompts to install on the dweb.link IPFS gateway

Using clean profile, confirmed navigating to an https:// URL with /ipfs/[CID] on non default gateway does not prompt for install via infobar.

Confirmed loading an ipfs:// URL works correctly after IPFS is installed

Confirmed loading an ipns:// URL works correctly after IPFS is installed

Confirmed session restore works correctly when a single tab is left open, in the background with an ipfs:// URL.

Confirmed session restore works correctly when a single tab is left open, active with an ipfs:// URL.

WebUI

Confirmed chrome://ipfs, about://ipfs resolve to brave://ipfs

Node running	Node not running

Lazy Loading

Confirmed restarting the browser does not load IPFS process in Task Manager or Activity Monitor when IPFS is installed.

Confirmed navigating to IPFS resource loads process in Task Manager and Activity Monitor when IPFS is installed.

Verification passed on

Brave	1.19.83 Chromium: 88.0.4324.79 (Official Build) (64-bit)
Revision	bd1e9353659b2491dac971226a973ca3b5684a14-refs/branch-heads/4324@{#1520}
OS	Ubuntu 18.04 LTS

Brave	1.19.84 Chromium: 88.0.4324.87 (Official Build) (64-bit)
Revision	dd01ff8f58c65af81127ad5c105c79d5b571d8f3-refs/branch-heads/4324@{#1702}
OS	Ubuntu 18.04 LTS