So I'm going to go ahead and introduce now to you, Moshli, thank you for coming here today.
She has an incredible background, she is the director, the director of the IPFS Foundation
and the inventor of Google Forms, and she's going to be going ahead and giving a discussion
today on the practical talk, a practical talk sharing the lessons of the IPFS ecosystem
on decentralizing the web, via native and browser support, and new cryptographic standards.
So let's go ahead and give a warm round of applause for Moshli, everyone.
Thank you, Kevin.
Hi, everyone.
I'm Michelle Lee, Moshli, my friends and foes.
With the IPFS Foundation, we're a nonprofit that fosters a more resilient and user-owned
internet.
Today, specifically, I want to share our adventures with IPFS and web browsers, our favorite
portal to the internet.
Raise your hand if you use a web browser this morning.
I know it's pretty early, who knows.
Keep your hand up if you've written an application for a web browser.
Put your hand up, keep your hand up.
If you've tried to make a web browser do things, it's not really supposed to do.
That's a lot of hands.
It's a lot of hands in the room.
And now, keep your hand up if you've written or contributed to a web browser.
Hello, hello.
All right, awesome.
So the IPFS project started 10 years ago with two simple and at the time, pretty weird
ideas, content addressing all the way down.
So every piece of data is hashed, and that hash becomes its identifier.
And once that data can verify itself, it doesn't need to come from a trusted server or
source.
And that's how you build open networks, shaped by users, not by platforms.
And so today, we have a family of protocols and tools to store verify and share data
across distributed networks.
And they're the building blocks of what we hope will be a better web.
We have a lot of different specs, libraries, and tools, but generally come to IPFS to solve
one of three problems.
One and maybe the most well known here is you want to publish on a public network, resilient
to censorship, or outages.
So if something happens, you can get the same content, proven by its content identifier,
from any other node in the network.
And this is actually about 67% of the usage.
You want to spin up your own networks.
So these users range from scientists, sharing data sets across universities, to several
engineering projects, using IoT sensors, to monitor where and care on bridges.
And there's like a whole universe of things that people are using these open decentralized
peer-to-peer networks for.
And they're fascinating, and most of us never know about them, because they're in the
dark forest, or kind of off of the main network.
But there's a lot of tooling that's coming online for that as well, especially from the Python
and Geospatial Data Communities.
The third is you just want content addressing, and you want it to play nice with your
own network design.
So I'll start with the first one, and in 10 years, people have used IPFS, use those three
capabilities to do a bunch of pretty awesome things.
Now the web is, I would say, more open, more censorship-resistant.
We've made the web more efficient together.
We've made the web more credible, more trustworthy through CID verification.
And you could also say we've made the web more fun, when you can customize and control
your own experiences on social networks, maybe it's a better experience, who knows.
And all of this is happening through a heavily consolidating browser landscape.
This graph is from 2012 to 2024.
Can anyone guess who the blue one is?
Chrome.
Yeah.
Yep.
Chrome.
And so, yeah, browser is a fun place.
So by design, and here's where browsers come in, by design, each IPFS node talks to
other nodes to find and fetch content by their CIDs.
In practice, most web users, most laptop users aren't running a node.
And here's something I always like to keep in mind when making products or software.
The average desktop user has 50 to 100 apps installed, but only 7 to 10 of them see daily
use.
That's for most consumers.
And so that's where people really live.
Those are the ones that are up to date, like past all their security upgrades.
There's a really long telebacks.
And so when you build an app that is not a web browser, you really have to fight to get
into that top 7 or 10.
This effect is even more exaggerated on the mobile platform.
So on your home screen, think of the apps that are in your dock or the ones that you
use most often.
You might have 50, 60, 100 apps installed, but it's about 4 to 8 that people are using most
of the time.
If you want to do something custom, if you want to build your own app, you either make
it into that top echelon, or you use an app or a portal that everyone has installed.
And so that's where browsers have really played a fantastic role since the dawn of the
web.
And let's talk about extensions for a second.
Extensions are a really great way to extend capabilities, but again, most people don't
find them.
They don't install them.
IPFS companion, which is our extension for Chrome and other browsers, has about 50,000 users.
Many of them are really active, but still that is just a small slice compared to the
number of people who are trying to access our content through a regular web browser.
So in 2018, we introduced gateways, which are computers that speak both HTTP and IPFS.
So ideally, they would all support the IPFS protocol, but in practice, we've created a band
data essentially, and unfortunately, many web apps have started hard coding these gateway
URLs.
So this was creating this decentralization effect, two billion files that it's peak, all
surf through one to four gateways.
And so we needed another approach, actually, we needed a lot more approaches.
So we kind of set out on this journey to make browsers more peer-peer.
Dietrich Gayala here is, you can blame him for getting this started, blame slash thank.
The first one is, hey, what's build new browsers?
Let's build modern browsers that embrace the decentralized web.
I can't spell the centralize, so I'm just using web three, but words, words.
It's really hard to get people to switch browsers, so like I said, that kind of like
app, a gemity effect, really makes it hard for new browsers to grow.
The second approach is add IPFS and other decentralized protocols to really popular browsers.
But browsers are very cautious, progress is pretty slow.
You have patterns like issues getting responded to after a year.
We tried a lot of different paths towards this.
We forked Chromium, we forked Electron, we kind of built it in, built a lot of proofs of
concept.
Progress here is pretty darn slow, but it does work.
So over time, I think the one we can be most proud of is getting ED25509 supported in all
major browsers last summer.
It's a huge thanks to the Egalia team who made this happen, especially happy for Nendez.
I know it's right there, please talk to him as well.
This was a three year effort, and it doesn't fit into your quarterly planning, it doesn't
even fit into your annual planning, and you can't predict it because it's based on what
the browser vendors think.
We can't count on that, we need other paths in parallel.
Before we move on though, I'm writing high on the CDD25509 thing, and I think we can get
more.
I know we can get more.
It's going to take some time.
So we put out a call on the IPFS discussion forum for community input on what we work on
together with Egalia next.
If you like streaming hashing in the web crypto API, if you want web kit to fix local
host bugs, if you want more support for remote attested TLS, please put your needs and use
cases in this forum thread.
We'll take that to help shape our priorities, and then we'll bug you again to comment
on the issues and PRs in the browser engines, and over time, and like if I were taking
bets, maybe like optimistically, like three is a two year effort, it might be longer,
but I would love to be right there.
These kinds of things can over time really make it into the browsers.
So all right, that's slow, let's keep going, what else can we do?
The next one is new use of old browser capabilities, and this one's pretty fun.
We have a team, the Kubo team took advantage of service workers, which are an existing
feature of all web browsers, and use that to create local support for direct retrieval,
direct verified retrieval of IPFS data.
So this is done in the Helia slash verified fetch library.
It has some constraints on it currently, and we need to improve its performance, but this
does work, and it's a way to use a service worker to get peer to peer connections right
from any browser to the IPFS network through the native protocol.
So I'm pretty excited about this.
It's basically, we've created the proof of concept.
It's available at Helia slash verified fetch, if you'd like to experiment with it, it's
ready for you.
I'm pretty excited about this one.
We do have some work to do before we start shifting more traffic to it.
That's going to be happening throughout this year.
So we'll start experiments, do a lot of measurements.
Towards the end of the year, you can sort of expect some stick and carrot patterns to
push more traffic to this direct model.
We'd really like to spread the load so that the public network can be a true peer to peer
commons and take a lot of the pressure and traffic and dependency off these centralized
gateways.
The fourth approach is just don't, don't try to make browsers do things that they don't
want to do, and that's one that works for some projects and not for others.
So in this approach, servers are acceptable if your data's content addressed and you
can't just decentralize who controls the servers.
In 2024 and early 25, we're noticing a lot of community driven mini libraries for parts
of the IPFS stack, CID, C-Boards, etc.
A lot of this coming from the app prototype community.
There was so much activity in fact that you sort of made us write a lighter weight IPFS family.
Speck called Dazzle.
Robin will be talking about that at 315 today in the decentralized comms dev room.
So we have a suite of specs, performance tests, websites, etc.
And so the idea there is these are building blocks that you can use if you're not ready
to decentralize your entire stack or application or network or system.
This is one meaningful step towards decentralize more open self-certifying networks.
So we've got four approaches.
They range from chaotic good to chaotic neutral.
Actually, they're not all chaotic.
Probably the actual changing the browser is one, probably lawful, lawful good.
But we've only been able to do this with a ton of collaborators.
And I hope you all will be some of them, whether it's just sharing use cases or joining
forces to make it clear to browsers that we are more than just an isolated instance or
isolated team.
We all want the same things, which is to have browsers continue to be this magical, fantastic
gateway to the whole world, but also keep up with modern needs.
So yeah, the hills are alive.
I hope we can all sort of out them together.
And I wanted to thank everyone who's ever contributed to IPFS or these efforts, million
people, some of whom are named here, some of whom I couldn't fit on the slide.
If anyone wants to talk about this more, I'll be here for the morning and can reach me
at these places, email, internet, et cetera.
And with that, I think we have a few minutes for questions or comments.
Yeah.
All right, actually.
If you would like to talk about this, that would be great.
So that way everyone watching this stream can go ahead and check it out.
Here we go.
Yeah, I'll come to you.
First of all, I'm honored to have the decentralized special.
When you're trying to contribute IPFS into the browsers, you said that they're very cautious
and slow.
Is there anything specific you can say in terms of what technical pushback or what concerns,
what terrible thing is going to happen in browser land if they were to accept your contribution?
I think they're slow for good reason, they are a huge vector for people doing trying
to do all sorts of great things and terrible things on the web.
The way browsers are archstructured, most of these newer capabilities would be feature flags
or enable capabilities.
A lot of these browsers don't even have those controls built in.
So it's a multi-step process, like first, get them to support configurations or build
variants or things like that and then make the case for your specific technology to be accepted.
So there's probably different stories for different heroes, journeys for each of the different
capacities we want to see in there, but I don't think it's unreasonable, but it
is tedious.
Manual or do you want to add anything to that?
One of the challenges is even talking.
Some of these concepts are so foreign to how the HTTP security model is designed today
that even talking about something like a cryptographically variable address and data as
a security model is really challenging.
When we proposed IPFS at the WICG, just proposed to talk about it there and did not get
approval to have the conversation.
And so there's this technical challenges and cultural challenges, but also an insularity
to how the web itself has its success as cemented.
It's thinking about HTTP and the role it has in browsers, it makes it challenging to even
bring up new concepts, like cryptographically variable as a
an origin or authority concept.
I think certificates just got widely known and accepted, so yeah, things take a while.
All right, any other questions?
Hi, first of all, great talk.
My question is, what kind of work has your organization done relating to displacing
reliance and say the domain name system or certificate authorities for TLS?
When I try to do, I work in the peer-to-peer space that it's hard to do peer-to-peer stuff
in the browser because of things that rely on centralized authorities like this.
So I'm just curious what your vision or long-term thinking is on that subject.
Again, I think because we're working in a very dynamic and shifting ecosystem, we haven't
designated, like, hey, this is our one path to success.
There's a couple of things that our community has done, or our organization, and our
collaborators have done.
One is actually just to start issuing certs, our cells have like automatic service issues
certs.
The other is that a number of groups are creating basically capabilities based tools to bundle
tokens, off tokens, alongside content.
You can probably the one that I see the most of, but there are many others out there.
All right, we have time for one last question.
So who wants to hold the spatula?
Okay.
All right, let's go and do one more warm round of applause for Moshley, everyone.
Thank you very much.