Deprecate local node support and ipfs:// scheme

[bbondy]

Brave's IPFS local node support has a cost to Brave in terms of support and maintenance, distribution of binaries, and node updates. For each Kubo node update we need to sometimes change things in code, get it QA'd and get release management to release it.

It is nice to support things, but we do need to also acknowledge that doing so takes away from other things we could be doing. P3A data is showing we have 0.1% local node and 0% gateway setting. 99.9% of people are on an Ask setting which means they’ve never used IPFS.

It also opens up a larger attack surface because there's more code and things running on a users's machine for those that opt into it. 

This issue is to track deprecating and removing the local node support.

Related, we've also had issues in the past with dnslink, so we should consider if we need that too #13609

We do use local node support for NFT pinning. So that would be 1 feature that would need to be removed.
I think that we should allow users to install an old version of the browser and still have access to the profile data to get at anything they used to have pinned. I.e. don't clear out the local node data. I think we should have an FAQ in community.brave.com about how to clear out that data manually.

The setting for "IPFS Companion" should probably also be removed. Users can get this extension from the Chrome extension store already, so we don't need in-browser UI to get it.

We would like to retain decentralized DNS handling via still having an interstitial page that redirects users to a gateway https:// directly. It would not retain the name in the URL bar. For now having 2 interstitial pages, one for Infura as we already do and 1 for enabling the public gateway is good enough. The 2nd interstitial would have the local node option removed.

Posting this for greater community feedback and visibility.

Other tasks we need to do:

• This work will need updates on our website about it
• We should do a community.brave.com post about it
• We should update past blog posts
• We should update the admin policy documentation if the admin policy is no longer used. If it is still used, maybe because maybe the decentralized dns, we can leave that in place.
• FAQ in community.brave.com about how to clear out profile data manually.
• Close out most IPFS related issues in brave/brave-browser and add the label closed/invalid

[bsclifton]

cc: @John-LittleBearLabs - curious what you think. I know we talked about IPFS in person at BlinkOn 18 a bit

[John-LittleBearLabs]

I know that I like your UI for dealing with this stuff - it's the main reason Brave is my main browser. But obviously I'm a special (read: not representative) case and I'm sure you know your users as a whole better than I.

Grabbing a Kubo node and running it locally for the user sounded clunky when I first heard it, but it is a pretty feature-complete approach and kinda does what I want it to. It also achieves the level of privacy I want (doesn't send all my IPFS traffic to a given third-party gateway), though I appreciate your UI gives me an appropriate explainer in case I had a higher threshold. And it short-circuits content I already have, which matters for me more than most people.

But if you were planning on supporting IPFS internally in some way, that might be an equal or better approach for an IPFS user. I believe @autonome has spoken to some Brave folks about something like that.

[autonome]

The native node feature provides a couple of unique capabilities for Brave's users - independent hosting/publishing, and truly p2p content access.

The self-hosting/-publishing flows are not easily accessible to end-users with the native node support as-is, except through the NFT archiving feature. There's a lot of opportunity there, but would take significant investment in either enabling new onboarding flows as built-in browser features or API extensibility (eg fetch() POST to local node like Agregore does) to superpower web apps and dapps. All of that takes significant resources of all kinds, from design to sec eng to release to ongoing maintenance - the whole browser feature lifecycle, or web platform feature lifecycle. Both are a major long-term commitment.

The benefits of local node content client are many: data resilience, egress cost mitigation for publishers, local network applications, and more. But without flagship applications driving users to enable the local node, those benefits are not gained.

In the absence of the local node feature, there are certainly options that have far less resource cost and still provide opportunities for Brave to differentiate and provide IPFS paths for users and developers who need them.

We worked with Igalia to add custom protocol redirect support to Chromium and that shipped in 2022 - just a build flag and a pref for a default gateway. No code changes, just build config. There are trade-offs in relying on a single HTTP gateway, but allowing it to be user-configurable in the pref can at least give them the choice, and at very little ongoing cost for Brave.

The multi-gateway verifiable client work that @John-LittleBearLabs is building is another option where Brave could get better IPFS client support without shouldering as much cost, so is worth evaluating if there's interest, and as that feature matures. The goal in that work is landing it in Chromium, which would mean again a build flag. Making that happen requires clear support from vendors like Brave in standards conversations like in this proposal for IPFS at the W3C WICG.

IPFS certainly has a chicken+egg problem wrt to browser support and deployed native addresses and content. Brave needs to balance their estimation of IPFS being that differentiator for them in acquiring users vs the cost of maintaining the native node feature. The IPFS ecosystem needs to be growing and succeeding to a level where it drives usage and developer interest such that it makes Brave's resource expenditure worthwhile.