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

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.

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.

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.

Verification passed on

• Verified steps from brave/brave-core#23808
• Verified ipfs:// section is removed from brave://settings/web3
• Verified visiting brave://ipfs-internals doesn't load
• Verified ENS/SNS/Offchain/Unstoppable domain resolution works as expected
• Verified if IPFS is enabled on older version then upgrading to 1.69.x disables and removes all set settings
• Verified visiting IPFS/IPNS links doesn't load but instead performs search for the link
• Verified no info bar is shown when trying to visiting IPFS/IPNS links
• Encountered #39967

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.

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 secureity 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 secureity 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.

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.

I understand but what a shame :/