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.

[bbondy]

Thanks for the insights and options above.

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.

Unfortunately the P3A data that we do have doesn't justify it given the ~0.1% of user base using the local node and ~0% using the gateway setting.

We're going to be moving ahead with this work.

[ZelnickB]

The reasoning behind removing the built-in IPFS node makes sense, but I don't understand why the ipfs:// scheme has been deprecated as well. Ideally, even without the IPFS Companion extension installed, when a user navigates to an ipfs:// URL, Brave should be able to return a response from a gateway configured in settings.

[autonome]

Basic ipfs:// redirecting to a gateway is more easily done these days via build-time configuration in Chromium.

However, supporting a feature in a browser is about 1000x more involved than just the technical implementation. Brave and Protocol Labs put many person-years of work into the various IPFS features, and it involved teams from design to security to docs to legal etc. Ongoing support and maintenance is not negligible. IPFS in particular needs a lot of user education to support safely, as its privacy and security model differs radically from HTTP. It is not a trivial feature. It requires significant user demand to justify what is a very large investment in time and resources.

Ultimately, making a better web for everyone requires a standards-based approach. There are ongoing efforts to get better custom protocol support in Chromium/Firefox/Webkit through WebExtensions using a manifest key for the protocol registration and ideally a ServiceWorker that handles requests. It has a long way to go, but is a more standards-oriented approach that will be more broadly supported. While it would require an extension, it would a big step towards normalizing non-HTTP protocol use on the web. If you'd like to follow along or participate, the tracking issue for IPFS ipfs/ipfs-companion#164 and the WECG issue for manifest-based protocol registration is w3c/webextensions#365.

[FiveEyeTea]

I had just gotten into using and hosting some stuff with IPFS and then Brave removed the feature, which really frustrated me. I get that not many people used it but surely there was a better way than to outright remove support for it? Like MicahZoltu said: considering the fact that we're seeing a massive attack on free speech and freedom of information in the world right now, removing the ease of use of IPFS within Brave isn't really great because people won't look for technology like this until after they're being censored.

I do understand that it's not a trivial matter for Brave to support it but it was easy to use within Brave (thus making it more likely to find a use among the average user). It was just relatively hidden. I didn't know it was there until I was doing a bit of a search through my settings. Instead of removing it, maybe Brave could have put a greater focus on it in marketing and explained why IPFS, like the whole of Web 3.0, is crucial to the future of a free internet. I haven't set up an IPFS client outside of Brave yet but from what I was reading, it sounds like it's significantly more complex than just toggling a setting in Brave and hosting some content.

At the end of the day, it's not a deal breaker (not by a long shot) but I'm also not going to pretend like it doesn't absolutely suck that it was removed.

[JWMatheo]

I understand but what a shame :/

[DeepDoge]

Brave could have just switched to a more lightweight implementation, similar to Opera.

Instead of running a whole node, having lots of IPFS features, like pinning, built-in extensions, lots of confusing settings.
Just have a single gateway URL setting. And use that to load ipfs:// content.

If someone wants to run a local node they can just download IPFS themselves and set it as the gateway.

Opera's implementation also gives the ipfs:// URI, when you typelocation.href in the console.
So arguably Opera's implementation is both simpler and better.

But it's Opera, not Brave, missing other amazing sides of Brave like Brave Sync Chain, being able to change the search engine, Brave Rewards, Brave Shield, etc.

[trmid]

I understand that there is little need for IPFS resolution to be enshrined into brave, but not being able to resolve IPFS URIs in net requests is a significant setback.

Protocol labs and the IPFS community have been making strides in getting native integrations available at a lower level. For example:

• IPFS with curl
• IPFS with chromium

The curl integration approach is extremely simple and looks for a system-defined IPFS gateway at the user level or in environment variables, allowing the system or user to dictate the need for IPFS resolution support. Checking for a user-defined gateway and then enabling chromium to resolve IPFS URIs via a predefined handler scheme seems like a simple approach to re-add IPFS resolution in a non-invasive way.

This solution would be similar to the suggestion from @DeepDoge , but would make the integration even simpler by not relying on a browser-defined variable and instead looking for standardized IPFS gateway system variable.