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.