IPFS: A Decade in Browsers

Hello everyone. Thank you so much for coming today and thank you to the organizers of this fantastic event. There's lots we could say about IPFS. It's 10 years old, so basically middle-aged in Web3 terms. But today I want to share our adventures in IPFS and web browsers.

So please raise your hand if you used a web browser this week. All right. Keep your hand up if you've written an application for a web browser. And now put your hand up or keep your hand up if you've tried to make a web browser do things it's not really supposed to do. I see a lot of hands still up.

And now put your hand up if you've written a web browser or contributed to a web browser. All right. This is going to be fun. Let me figure out the clicker. Thank you.

Thank you. All right. Before we start, my name is Michelle Lee, or Mosh online, and I'm with the IPFS Foundation. We are an independent organization formed after 10 years of Protocol Labs incubation, and we act as a connective tissue for the project and community. We're a deliberately lean organization.

We contribute to protocol stewardship. We drive real-world adoption and feedback loops, and we integrate with web standards like IETF, W3C, and more. I'm here with my colleagues Robin Bergeon and Bumblefudge. So IPFS launched in 2015, and a lot has happened since then. I think in that 10 years, it's fair to say we've made the web and computing more open, more efficient, more credible, and also more fun.

And all of this took place through a heavily consolidating browser landscape. So this chart is of 2012 to 2024, and you can kind of guess who the blue on this chart is, right? And so we're trying to make peer-to-peer happen right as the browsers are consolidating and expanding their footprints. This has been a fun adventure. And so IPFS implementations have also evolved along with the web landscape.

So in 2015, Go IPFS and JS IPFS, the goal is feature parity across the languages. So literally we had a table with check marks. Did this match that one, and did that one match this one? In 2022, the implementation fund was created to support new clients. And in 23, we made some pretty major changes within the project to encourage more client diversity.

So Go IPFS was renamed Kubo, this is a simple rename to free up the namespace of what was officially a Go client. And JS IPFS went through a much more major change that became Helia, or it was deprecated in favor of Helia, which was a brand new browser-first implementation that is the foundation of some really cool stuff we're going to get to see today. In 2024, we saw a rise in mini-libraries, and community members from AppPro and other communities started writing a lot of modular IPLD tools, and in response, IPFS Foundation created Dazzle, which is a streamlined IPLD and CID spec meant to work really well with any networking stack or protocol, including HTTP, and we've built on that project again through Razzle, which is for retrieval, Mazzle for metadata, the puns write themselves, you can check it out at dazzle.ing. But I want to go back to these community-driven mini-libraries, because everywhere in these library descriptions, the words you see are fast and tiny, tiny and fast, tiny and small, don't be a full client, so we really start to see that users are taking modularization into their own hands, writing their own tools.

And this is helping us see that devs are using IPFS for, you know, in three groups for three different reasons. You might come because you want content addressing, you want building blocks for content to, you know, to content address the whole internet. We're continuing to build on that, there's a whole list of projects in that focus area, and the goal is to make everything small, fast, extremely performant, and interoperable. The second one, which maybe this room is most familiar with, is the public network. So a peer-to-peer public network for everyone, it is now at five billion files, that's a lot, and today we're going to talk a little bit about how that's going to transition in the next few years.

So all those efforts in the middle column are contributing to keeping that public network healthy and running today. The third bucket of IPFS users are coming because they want to build private or permissioned So we have users ranging from scientists sharing datasets across a few research universities to a Korean civil engineering firm that's using IPFS to make a local network of monitoring devices for bridge wear and care. So to me, this is like a really fascinating kind of below the surface of the water iceberg of IPFS users, and we're going to explore that more later this year. But today, I want to focus on the public network, because I think that's maybe the one that's most familiar to this audience, and the one that's going through a lot of really cool changes. So by design, your IPFS node talks to other nodes using the IPFS protocol to find, fetch, and then verify content by CID.

In practice, most web users aren't running a node, and so they have to install something. And it's really hard to get users to install something. Eighty-seven percent of Chrome extensions have less than a thousand installs. And so you can imagine, like, this is a really big mountain to climb, and I think our early work with IPFS Companion was great to bring early users on board and make IPFS really clear and usable for those folks. But that's not going to be enough to reach the whole web.

And so in 2018, we introduced gateways, which are computers that speak both HTTP and IPFS. And this is meant as sort of a Band-Aid measure, right? Until we could get browsers to support peer-to-peer IPFS, other protocols, we're going to use a gateway that can speak both protocols and kind of translate requests from one to another. So how that worked out was, you know, the tough way is how we want applications to be addressing each other, with IPFS colon double slash, and to use the full IPFS protocol. What happened in reality is, because most users didn't have IPFS clients installed, web app dev started to hard-code gateway URLs, like IPFS.

io and put the CID afterwards. So you still get the benefit of the content addressing, but none of the verification and the resilience, because if IPFS.io goes down, then, you know, you're kind of stuck. And what this led to was, like, every single line of T got hard-coded for gateway. That's not quite true.

But this, you know, this happened in parallel. And so we basically created this re-centralization, where two billion files at their peak were in the gateway, in one to four gateways. And we created this, you know, very convenient band-aid for the community that, you know, then became our challenge to inherit. All right, so how do we get out of a situation like this? Let's make browsers more peer-to-peer.

Let's bring browsers into the age of Web3. The first approach is a new browser that embraces Web3. And Beaker was one of the early ones supporting the DAP protocol. Brave supported IPFS for a long time. But it's actually really hard to get people to switch browsers.

And if you remember my chart from earlier, that blue slice is going to get bigger and bigger. But I think there's some help coming, but not in the immediate future. So let's try approach number two, which is, hey, let's add IPFS handlers to existing browsers, right? If browsers are open source, we can submit a patch and get it merged. Browsers are probably one of the most complex classes of open source projects.

They have a huge surface of vulnerability, and so reviews are extremely stringent for good reason. So they're cautious, and progress is slow. You know, we have examples like issues getting a response one year later. And so in the meantime, we've done projects in collaboration with groups to make an electron fork that supports IPFS. That's a cool one if you want to build some web apps, some electron apps that use the protocol directly.

It's also a Chromium fork. And we have had some successes. We've been investing in this since 2019, sponsoring work to bring browsers, you know, more in line with Web3. And so sometimes that's specifically IPFS protocol handlers. But in this case, we've got ED25519 coming to Chrome soon, I hope, very soon.

And then next, we're going to focus on streaming hashing. So this is exciting because we're finally starting to see movement after many years of blood, sweat, and tears by a lot of people. But we also need another path in parallel because we can't just wait for browsers to catch up. Like, everyone in this room and millions of people around the world are ready for the next step for the web. And so this is how we started down the path of approach number three, which is new uses of old browser capabilities.

So remember when we said, like, who's trying to make browsers do stuff that maybe wasn't expected? Service workers are part of most major web browsers. They're a scriptable network proxy that can manage network requests. So, hey, scripting, fun. So instead of this HTTP IPFS gateway, we instead now have the Helia verified fetch library that can, you know, act within a service worker to facilitate direct verified retrieval, locally verified of content address data.

Daniel Norman is going to give a really cool, thorough, you know, deep dive demo into this at 2.30. I think it's in Cinema 7. So if you like this, go to that. It's really fun.

And so what this enables is that app devs can add drop-in service workers to your app right now. It's live on GitHub. Check it out. You can probably find the link in our blog or tweet me and I'll get it back to you. And we are really excited to see what you all build with these capabilities.

And this also means that starting later this year, we're going to run experiments on the gateways to add service workers that push more traffic to P2P. So it'll be sampled. Maybe, you know, it'll take a progressive shape. And we are going to publish progress monitoring and metrics as we go along. We are aiming to keep the network alive and healthy and usable for everyone, but start to bend its arc more towards a true peer-to-peer network.

And in one to two years, you can expect some rate limiting on gateways, because we want to, you know, reposition the gateway as, you know, less of an interim shortcut and make it a true public common. So we're really excited about the, you know, verified fetch and service worker approach because it's allowing us to make this transition that's hopefully going to be faster and better and more resilient for everyone. There's also some great work with auto TLS certificates that are going to be in that workshop from Daniel. So please check that out. Where does that leave us?

All right. So I think, like, we are so excited. I think this really opens new chapters for IPFS and application development. I also think that browsers are under existential threat right now. So we have agents.

We have more interactive applications. We have chat-based interactions. I really think that, you know, as much as we have to acknowledge the hegemony of, you know, three major browsers today, I really think we are going to start to see some sea change in how users and people connect to each other, connect to networks in the next few years. Some of it driven by AI, but others just driven by other community and networking needs. So we are going to design for the browsers we have today, and we're also going to be looking at the future.

And I think this more modular approach, this local verification, will put us in a really good position to do that, and it will be great tools for the developer community. I want to end with three design principles. Because, like I said, you know, our mission at the IPFS Foundation is to take us from, hey, it really works in, you know, a lot of these fantastic case studies, to it's seamless and invisible, and it's upgrading the whole Internet. So here are some things to consider, you know, based on what we've learned over the years. The first is that drop-in replacements help smooth the path for both users and devs.

So if you replace one layer at a time, that gives developers and users the option to choose what they want to swap out and when. If you commit to reinventing the entire stack at once, I think that, you know, there are a lot of, there are some opportunities where that can really be powerful, but in many, many cases, the large majority of users are not ready for that. So think about, you know, swapping S3 endpoints for dedicated ones, for decentralized ones, upgrading CDNs to peer networks, you know, intercepting calls. So really think about how little app logic you can change as you swap out some of these components. The second is easy defaults with clear upgrade paths.

I think, you know, one regret we might have as a project, in hindsight, is how long we continue to double down on the gateway strategy. But now we have the tools and the software and the components available to transition out of that phase. The last, and this is something that I would love to see permeate Web3, performance is a feature. Our tools need to make apps faster and better by default, not slower. More devs will use Web3 if it's good and if it's right.

A lot of people might come for those benefits, and then they'll get the ethos for free. So every pixel, every 10 milliseconds matters. And I think as we move towards more local-first architectures, more peer-to-peer in the browser, a lot of possibilities can come true. I'm really excited to see what our community can build with these building blocks. And I wanted to thank, first of all, all of the IPFS contributors over the years.

I think there are more than 4,000 of you. Raise your hand if you've ever contributed to IPFS, filed an issue, posted a complaint in the forum. Thank you. Thank you for helping take us to where we are today. And thank you in advance for continuing to invest and share and helping us grow.

And then to the many individuals and groups that have put in the work specifically for what I've shared here today. Thank you. Thank you, Michelle. We have a bunch of questions we can answer and plenty of time. I'll start with the most upvoted one.

Do you think browsers will ever allow opening direct connections to other peers, or will only WebSocket transports be supported for web clients? It depends on what you mean by browser. You can do whatever you want. I don't know, but I've only seen browsers be careful. So I wouldn't bet on it, but maybe it'll happen.

Yeah. Next one. Who are the biggest portion of IPFS users, you would say? We're working on better instrumentation now. It really depends on what you mean by IPFS.

Like I said, 10 years old, like 236 repositories, lots of different specs, like a whole family of things. I think one of the biggest communities using IPFS components is BlueSky and the app proto community. They're at 36 million users right now, and I think they're a great demonstration of what can happen when you build a protocol and a product in parallel. So they brought, you know, 36 million users all have decentralized IDs, and most of them didn't even have to think about it. Firefox has a very archaic code base.

How likely it is for them to implement a completely new protocol like IPFS? IPFS itself contains a lot of underrated stuff to serving websites too. I think that, you know, we've taken a pretty incremental approach. So in Chrome, I believe we were able to add support for opt-in handlers, and you could compile with opt-in handlers. So it's very incremental.

I think it would be a big leap to go all the way to like full default IPFS support, but it's more likely that it can, you know, something that enables users to then turn it on is possible. What happens with IPVM? Is it still alive? IPVM, it turns out, fantastic idea and needs a few more components to keep going on its progress. So I would stay tuned on that project in a few months.

And in the meantime, check out all the research that's happening in the Ink and Switch collaborative. HTTPS supports both IP and DNS names. Should IPFS support CIDs and ENS names? It does. It does.

What's your expectation in terms of performance for the browser feature compared to today, and how do you plan to track performance? Do you mean performance in terms of fetching content or verifying it? Let me see. Let me try to interpret. Or would someone like to expand on what they mean by browser performance?

Yeah, I'll repeat that for the stream. Daniel's demo at 2.30 will show off one way in which local verified fetch is going to make things faster in the browser. Do you think Filecoin will replace IPFS, or is the idea that both live together? These are complementary projects, and we anticipate that the Filecoin data will be retrievable through the IPFS protocol, but they're kind of overlapping networks.

Brave deprecated IPFS support due to little use. How do you communicate the best way to support IPFS into the future to users? I think that feeds into what I said earlier. It's very hard to get users to install something, right? And so as much as we were hoping that IPFS node support in Brave would be mutually beneficial, it turns out that it's, again, very hard to get users to download things.

And so the strategy that we're investing more of our time and resources in now is to bring peer-to-peer service workers, bring peer-to-peer connectivity without the user having to take an explicit step. So will it be just service workers and full IPFS nodes, and is that enough? So will it be just service workers and full IPFS nodes, and is that enough? The network is already a little bit more nuanced than I was able to share today, so I think there will be a lot of different ways that the nodes can connect. I guess the last one, unless there's another that comes in.

Is there a long-term strategy for content discoverability in regards to DHC scalability issues, recent IPNI outages? All right, let me talk short-term and long-term. The short-term is already underway. The IPNI indexers recently suffered some service degradation, and we have been investing in getting those back up and running and also expanding the resources so that system can run as designed. I think even the authors of that system have said, hey, there are some improvements that should be made in the design, and so that's also the next phase that's going to happen in the second half of this year is figuring out how we upgrade essentially the texture, the tiers of IPFS nodes and content routing so that these outages and disruptions don't happen in the future.

Any thoughts on verifiable contents and binary distribution? Yes, do them. Very clear. Okay, I guess that wraps up the session. Thank you, Michel, for the amazing talk and the Q&A session.