GeezerVison is showing github.com — Deprecate local node support and ipfs:// scheme · Issue #37735 · brave/brave-browser
Deprecate local node support and ipfs:// scheme #37735DescriptionBrave'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
Reacted by thesmartwon and Nick Sweeting Reacted by Preetham, Gabe, Vyachean, Ross, Alberto Monterroso, Lukáš Lukáč, Michael Vorburger, Ryan Shahine, Diegolden, Ricardo and 13 more Reacted by andrewslock, epremuz, Gonçalo Pestana, Lukáš Lukáč, Ryan Shahine, Giuseppe Bertone, Diegolden, Akhilesh Thite, Seth Horsley, Giuseppe Romagnuolo and 3 more Activitybsclifton commented on Apr 25, 2024 cc: @John-LittleBearLabs - curious what you think. I know we talked about IPFS in person at BlinkOn 18 a bit John-LittleBearLabs commented on Apr 25, 2024 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 commented on Apr 26, 2024 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. Reacted by Marcin Rataj, Akhilesh Thite, Alan Smithee, Ilya Kreymer, Miroslav Bajtoš, Guillaume Michel, Tim Shamilov, Bora M. Alper, Mat Kelly, Lukáš Lukáč and 3 more changed the title [-]Consider deprecating local node support for IPFS[/-] [+]Consider deprecating local node support and ipfs:// scheme[/+] on Apr 26, 2024entlaabstudio commented on Aug 29, 2024 Hello, friends.
It makes me very sad. I think the IPFS network should be supported. For many reasons. It may be inconvenient and I think many people just don't know that such technology is needed on the internet. I think freedom has more advantages than disadvantages. On the other hand, I understand the developers, but the Brave browser was just an amazing way to use local IPFS. I don't think NFT is what should primarily pull IPFS up. IPFS simply leads to more decentralization and less censorship of the internet. Less dependence on centralized platforms and less censorship of the internet. I understand that this has its own thirteenth chamber, but as I wrote: I think the benefits still outweigh the unbenefits. What kind of internet we make is what kind of internet we will have. The internet is simply a mirror of society. That goes for IPFS as well.
Personally, I intend to keep using this technology and I believe that one day it will live up to the meaning that comes from its name. Thanks for IPFS! Thanks also to the Brave browser developers for their support so far for IPFS. Here is an example of another use of IPFS other than just for sharing data for NFT. Enjoy my music within the IPFS player:
ipfs://bafybeiewkxwysf4jlnhbxs7pd4junvkrrais76qm3qgkpn3en4b2lcqxwm/index.htm Reacted by Marcin Rataj, Kaydax and Sriram lidel commented on Aug 29, 2024 Reacted by Technotramp, Sriram and Vincent Långström bbondy commented on Aug 29, 2024 MicahZoltu commented on Sep 2, 2024 I know this is already completed/closed and unlikely to change, but I wanted to drop a comment in hopes that it may guide future decision making of this kind.
We are seeing censorship increase around the world lately as governments try to prevent their populations from seeing content the government doesn't want them to see, and we are seeing more and more scrubbing of sites off the internet by authoritarian governments that don't believe certain types of information should be available to anyone. IPFS provides a path towards a more censorship resistant internet than we have today.
The problem is, most people won't look for tools like this until after they realize they are being censored. If the tech stack isn't available for them when that happens they will remain censored and may not look again, assuming that we live in a world where state censorship is an unbeatable phenomena. Browsers having censorship resistance tools built into them before people need them means that when the time comes and people need the tool, it is there waiting for them.
This somewhat echos what @entlaabstudio mentioned above in that we should be building the internet we want (censorship resistant) rather than targeting what people currently use (censorable services). In other words, we should build towards the future use cases that we can see coming (those 0.1% of people), rather than building towards the current use cases (the 99.9% of people). Reacted by Marcin Rataj, tree, Jacob | tenshi_NET and Technotramp ZelnickB commented on Sep 2, 2024 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. Reacted by Yarrow, Ricardo , Rudolf Olah, LeDechaine, Joebugg, lumin0x1 and Guillaume Michel autonome commented on Sep 3, 2024 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. Reacted by Chris Waring, Marcin Rataj, Brian R. Bondy, Mat Kelly, Kyle Den Hartog, JWMatheo, Chawye Hsu, Haris Razis and Rudolf Olah tenshi-net commented on Sep 4, 2024 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. Reacted by Technotramp, Shiba, Joebugg and Giuseppe Romagnuolo JWMatheo commented on Sep 4, 2024 I understand but what a shame :/ nomadshiba commented on Oct 7, 2024 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. Reacted by Joebugg and Joey Mezzacappa trmid commented on Dec 15, 2024 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:
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. akhileshthite commented on Apr 14, 2025 Reacted by dzmitry-lahoda
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|