WEBVTT 00:00.000 --> 00:09.880 So I'm going to go ahead and introduce now to you, Moshli, thank you for coming here today. 00:09.880 --> 00:16.400 She has an incredible background, she is the director, the director of the IPFS Foundation 00:16.400 --> 00:20.360 and the inventor of Google Forms, and she's going to be going ahead and giving a discussion 00:20.360 --> 00:25.280 today on the practical talk, a practical talk sharing the lessons of the IPFS ecosystem 00:25.280 --> 00:30.360 on decentralizing the web, via native and browser support, and new cryptographic standards. 00:30.360 --> 00:41.200 So let's go ahead and give a warm round of applause for Moshli, everyone. 00:41.200 --> 00:46.040 Thank you, Kevin. 00:46.040 --> 00:47.040 Hi, everyone. 00:47.040 --> 00:51.240 I'm Michelle Lee, Moshli, my friends and foes. 00:51.240 --> 00:55.680 With the IPFS Foundation, we're a nonprofit that fosters a more resilient and user-owned 00:55.680 --> 00:56.680 internet. 00:56.680 --> 01:02.320 Today, specifically, I want to share our adventures with IPFS and web browsers, our favorite 01:02.320 --> 01:04.640 portal to the internet. 01:04.640 --> 01:08.360 Raise your hand if you use a web browser this morning. 01:08.360 --> 01:11.920 I know it's pretty early, who knows. 01:11.920 --> 01:17.920 Keep your hand up if you've written an application for a web browser. 01:17.960 --> 01:19.360 Put your hand up, keep your hand up. 01:19.360 --> 01:25.160 If you've tried to make a web browser do things, it's not really supposed to do. 01:25.160 --> 01:26.560 That's a lot of hands. 01:26.560 --> 01:28.480 It's a lot of hands in the room. 01:28.480 --> 01:34.880 And now, keep your hand up if you've written or contributed to a web browser. 01:34.880 --> 01:36.520 Hello, hello. 01:36.520 --> 01:38.880 All right, awesome. 01:38.880 --> 01:44.280 So the IPFS project started 10 years ago with two simple and at the time, pretty weird 01:44.280 --> 01:47.360 ideas, content addressing all the way down. 01:47.360 --> 01:51.880 So every piece of data is hashed, and that hash becomes its identifier. 01:51.880 --> 01:56.680 And once that data can verify itself, it doesn't need to come from a trusted server or 01:56.680 --> 01:57.680 source. 01:57.680 --> 02:02.200 And that's how you build open networks, shaped by users, not by platforms. 02:02.200 --> 02:06.680 And so today, we have a family of protocols and tools to store verify and share data 02:06.680 --> 02:08.880 across distributed networks. 02:08.880 --> 02:13.840 And they're the building blocks of what we hope will be a better web. 02:13.840 --> 02:20.080 We have a lot of different specs, libraries, and tools, but generally come to IPFS to solve 02:20.080 --> 02:22.120 one of three problems. 02:22.120 --> 02:26.800 One and maybe the most well known here is you want to publish on a public network, resilient 02:26.800 --> 02:29.560 to censorship, or outages. 02:29.560 --> 02:34.480 So if something happens, you can get the same content, proven by its content identifier, 02:34.480 --> 02:37.840 from any other node in the network. 02:37.840 --> 02:43.720 And this is actually about 67% of the usage. 02:43.720 --> 02:45.200 You want to spin up your own networks. 02:45.200 --> 02:49.840 So these users range from scientists, sharing data sets across universities, to several 02:49.840 --> 02:54.440 engineering projects, using IoT sensors, to monitor where and care on bridges. 02:54.440 --> 02:59.840 And there's like a whole universe of things that people are using these open decentralized 02:59.840 --> 03:01.920 peer-to-peer networks for. 03:01.920 --> 03:05.880 And they're fascinating, and most of us never know about them, because they're in the 03:05.880 --> 03:09.000 dark forest, or kind of off of the main network. 03:09.000 --> 03:13.280 But there's a lot of tooling that's coming online for that as well, especially from the Python 03:13.280 --> 03:16.720 and Geospatial Data Communities. 03:16.720 --> 03:21.040 The third is you just want content addressing, and you want it to play nice with your 03:21.040 --> 03:23.400 own network design. 03:23.400 --> 03:31.000 So I'll start with the first one, and in 10 years, people have used IPFS, use those three 03:31.000 --> 03:35.560 capabilities to do a bunch of pretty awesome things. 03:35.560 --> 03:41.440 Now the web is, I would say, more open, more censorship-resistant. 03:41.440 --> 03:44.000 We've made the web more efficient together. 03:44.000 --> 03:48.640 We've made the web more credible, more trustworthy through CID verification. 03:48.640 --> 03:53.360 And you could also say we've made the web more fun, when you can customize and control 03:53.360 --> 03:58.880 your own experiences on social networks, maybe it's a better experience, who knows. 03:58.880 --> 04:03.760 And all of this is happening through a heavily consolidating browser landscape. 04:03.760 --> 04:07.760 This graph is from 2012 to 2024. 04:07.760 --> 04:10.760 Can anyone guess who the blue one is? 04:10.760 --> 04:16.760 Chrome. 04:16.760 --> 04:17.760 Yeah. 04:17.760 --> 04:18.760 Yep. 04:18.760 --> 04:20.760 Chrome. 04:20.760 --> 04:23.760 And so, yeah, browser is a fun place. 04:23.760 --> 04:30.360 So by design, and here's where browsers come in, by design, each IPFS node talks to 04:30.360 --> 04:34.200 other nodes to find and fetch content by their CIDs. 04:34.200 --> 04:38.920 In practice, most web users, most laptop users aren't running a node. 04:38.920 --> 04:44.320 And here's something I always like to keep in mind when making products or software. 04:44.320 --> 04:51.800 The average desktop user has 50 to 100 apps installed, but only 7 to 10 of them see daily 04:51.800 --> 04:52.800 use. 04:52.800 --> 04:54.480 That's for most consumers. 04:54.480 --> 04:56.120 And so that's where people really live. 04:56.120 --> 05:00.600 Those are the ones that are up to date, like past all their security upgrades. 05:00.600 --> 05:02.200 There's a really long telebacks. 05:02.200 --> 05:06.560 And so when you build an app that is not a web browser, you really have to fight to get 05:06.560 --> 05:08.360 into that top 7 or 10. 05:08.360 --> 05:12.000 This effect is even more exaggerated on the mobile platform. 05:12.000 --> 05:15.960 So on your home screen, think of the apps that are in your dock or the ones that you 05:15.960 --> 05:17.480 use most often. 05:17.480 --> 05:24.840 You might have 50, 60, 100 apps installed, but it's about 4 to 8 that people are using most 05:24.840 --> 05:25.840 of the time. 05:26.400 --> 05:31.680 If you want to do something custom, if you want to build your own app, you either make 05:31.680 --> 05:37.800 it into that top echelon, or you use an app or a portal that everyone has installed. 05:37.800 --> 05:44.880 And so that's where browsers have really played a fantastic role since the dawn of the 05:44.880 --> 05:47.440 web. 05:47.440 --> 05:49.640 And let's talk about extensions for a second. 05:49.640 --> 05:53.560 Extensions are a really great way to extend capabilities, but again, most people don't 05:53.560 --> 05:54.560 find them. 05:54.560 --> 05:55.880 They don't install them. 05:55.880 --> 06:03.800 IPFS companion, which is our extension for Chrome and other browsers, has about 50,000 users. 06:03.800 --> 06:08.520 Many of them are really active, but still that is just a small slice compared to the 06:08.520 --> 06:13.680 number of people who are trying to access our content through a regular web browser. 06:13.680 --> 06:19.800 So in 2018, we introduced gateways, which are computers that speak both HTTP and IPFS. 06:19.800 --> 06:26.920 So ideally, they would all support the IPFS protocol, but in practice, we've created a band 06:26.920 --> 06:32.440 data essentially, and unfortunately, many web apps have started hard coding these gateway 06:32.440 --> 06:33.440 URLs. 06:33.440 --> 06:39.760 So this was creating this decentralization effect, two billion files that it's peak, all 06:39.760 --> 06:42.400 surf through one to four gateways. 06:42.400 --> 06:46.680 And so we needed another approach, actually, we needed a lot more approaches. 06:46.680 --> 06:51.680 So we kind of set out on this journey to make browsers more peer-peer. 06:51.680 --> 06:57.960 Dietrich Gayala here is, you can blame him for getting this started, blame slash thank. 06:57.960 --> 07:01.440 The first one is, hey, what's build new browsers? 07:01.440 --> 07:04.680 Let's build modern browsers that embrace the decentralized web. 07:04.680 --> 07:09.400 I can't spell the centralize, so I'm just using web three, but words, words. 07:09.400 --> 07:14.840 It's really hard to get people to switch browsers, so like I said, that kind of like 07:14.840 --> 07:22.320 app, a gemity effect, really makes it hard for new browsers to grow. 07:22.320 --> 07:28.280 The second approach is add IPFS and other decentralized protocols to really popular browsers. 07:28.280 --> 07:32.400 But browsers are very cautious, progress is pretty slow. 07:32.400 --> 07:37.560 You have patterns like issues getting responded to after a year. 07:37.560 --> 07:40.760 We tried a lot of different paths towards this. 07:40.760 --> 07:45.880 We forked Chromium, we forked Electron, we kind of built it in, built a lot of proofs of 07:45.880 --> 07:47.880 concept. 07:47.880 --> 07:54.840 Progress here is pretty darn slow, but it does work. 07:54.840 --> 08:00.600 So over time, I think the one we can be most proud of is getting ED25509 supported in all 08:00.600 --> 08:03.000 major browsers last summer. 08:03.000 --> 08:07.720 It's a huge thanks to the Egalia team who made this happen, especially happy for Nendez. 08:07.720 --> 08:11.800 I know it's right there, please talk to him as well. 08:11.800 --> 08:16.920 This was a three year effort, and it doesn't fit into your quarterly planning, it doesn't 08:16.920 --> 08:21.000 even fit into your annual planning, and you can't predict it because it's based on what 08:21.000 --> 08:22.480 the browser vendors think. 08:22.480 --> 08:27.400 We can't count on that, we need other paths in parallel. 08:27.400 --> 08:33.960 Before we move on though, I'm writing high on the CDD25509 thing, and I think we can get 08:33.960 --> 08:34.960 more. 08:34.960 --> 08:36.160 I know we can get more. 08:36.160 --> 08:37.160 It's going to take some time. 08:37.160 --> 08:44.680 So we put out a call on the IPFS discussion forum for community input on what we work on 08:44.680 --> 08:46.840 together with Egalia next. 08:46.840 --> 08:51.840 If you like streaming hashing in the web crypto API, if you want web kit to fix local 08:51.840 --> 08:58.680 host bugs, if you want more support for remote attested TLS, please put your needs and use 08:58.680 --> 09:00.240 cases in this forum thread. 09:00.240 --> 09:04.720 We'll take that to help shape our priorities, and then we'll bug you again to comment 09:04.720 --> 09:12.800 on the issues and PRs in the browser engines, and over time, and like if I were taking 09:12.800 --> 09:17.960 bets, maybe like optimistically, like three is a two year effort, it might be longer, 09:17.960 --> 09:21.440 but I would love to be right there. 09:21.440 --> 09:25.040 These kinds of things can over time really make it into the browsers. 09:25.040 --> 09:29.960 So all right, that's slow, let's keep going, what else can we do? 09:29.960 --> 09:34.680 The next one is new use of old browser capabilities, and this one's pretty fun. 09:34.680 --> 09:43.400 We have a team, the Kubo team took advantage of service workers, which are an existing 09:43.400 --> 09:53.000 feature of all web browsers, and use that to create local support for direct retrieval, 09:53.000 --> 09:55.800 direct verified retrieval of IPFS data. 09:55.800 --> 10:00.000 So this is done in the Helia slash verified fetch library. 10:00.000 --> 10:04.080 It has some constraints on it currently, and we need to improve its performance, but this 10:04.080 --> 10:11.800 does work, and it's a way to use a service worker to get peer to peer connections right 10:11.800 --> 10:18.040 from any browser to the IPFS network through the native protocol. 10:18.040 --> 10:20.200 So I'm pretty excited about this. 10:20.200 --> 10:24.680 It's basically, we've created the proof of concept. 10:24.680 --> 10:29.880 It's available at Helia slash verified fetch, if you'd like to experiment with it, it's 10:29.880 --> 10:30.880 ready for you. 10:30.920 --> 10:32.360 I'm pretty excited about this one. 10:32.360 --> 10:36.360 We do have some work to do before we start shifting more traffic to it. 10:36.360 --> 10:38.120 That's going to be happening throughout this year. 10:38.120 --> 10:43.280 So we'll start experiments, do a lot of measurements. 10:43.280 --> 10:50.400 Towards the end of the year, you can sort of expect some stick and carrot patterns to 10:50.400 --> 10:53.520 push more traffic to this direct model. 10:53.520 --> 10:56.720 We'd really like to spread the load so that the public network can be a true peer to peer 10:56.720 --> 11:01.880 commons and take a lot of the pressure and traffic and dependency off these centralized 11:01.880 --> 11:03.520 gateways. 11:03.520 --> 11:10.240 The fourth approach is just don't, don't try to make browsers do things that they don't 11:10.240 --> 11:14.480 want to do, and that's one that works for some projects and not for others. 11:14.480 --> 11:20.920 So in this approach, servers are acceptable if your data's content addressed and you 11:20.920 --> 11:24.760 can't just decentralize who controls the servers. 11:24.760 --> 11:29.920 In 2024 and early 25, we're noticing a lot of community driven mini libraries for parts 11:29.920 --> 11:33.640 of the IPFS stack, CID, C-Boards, etc. 11:33.640 --> 11:37.240 A lot of this coming from the app prototype community. 11:37.240 --> 11:43.880 There was so much activity in fact that you sort of made us write a lighter weight IPFS family. 11:43.880 --> 11:45.480 Speck called Dazzle. 11:45.480 --> 11:51.680 Robin will be talking about that at 315 today in the decentralized comms dev room. 11:51.680 --> 11:57.720 So we have a suite of specs, performance tests, websites, etc. 11:57.720 --> 12:02.320 And so the idea there is these are building blocks that you can use if you're not ready 12:02.320 --> 12:08.080 to decentralize your entire stack or application or network or system. 12:08.080 --> 12:14.000 This is one meaningful step towards decentralize more open self-certifying networks. 12:14.040 --> 12:17.120 So we've got four approaches. 12:17.120 --> 12:21.400 They range from chaotic good to chaotic neutral. 12:21.400 --> 12:23.400 Actually, they're not all chaotic. 12:23.400 --> 12:30.600 Probably the actual changing the browser is one, probably lawful, lawful good. 12:30.600 --> 12:36.560 But we've only been able to do this with a ton of collaborators. 12:36.560 --> 12:42.920 And I hope you all will be some of them, whether it's just sharing use cases or joining 12:42.960 --> 12:50.800 forces to make it clear to browsers that we are more than just an isolated instance or 12:50.800 --> 12:51.800 isolated team. 12:51.800 --> 12:57.520 We all want the same things, which is to have browsers continue to be this magical, fantastic 12:57.520 --> 13:02.520 gateway to the whole world, but also keep up with modern needs. 13:02.520 --> 13:07.280 So yeah, the hills are alive. 13:07.280 --> 13:10.400 I hope we can all sort of out them together. 13:10.400 --> 13:16.960 And I wanted to thank everyone who's ever contributed to IPFS or these efforts, million 13:16.960 --> 13:22.280 people, some of whom are named here, some of whom I couldn't fit on the slide. 13:22.280 --> 13:28.400 If anyone wants to talk about this more, I'll be here for the morning and can reach me 13:28.400 --> 13:34.720 at these places, email, internet, et cetera. 13:34.720 --> 13:48.800 And with that, I think we have a few minutes for questions or comments. 13:48.800 --> 13:49.800 Yeah. 13:49.800 --> 13:50.800 All right, actually. 13:50.800 --> 13:58.240 If you would like to talk about this, that would be great. 13:58.240 --> 14:02.480 So that way everyone watching this stream can go ahead and check it out. 14:02.520 --> 14:05.320 Here we go. 14:05.320 --> 14:08.320 Yeah, I'll come to you. 14:08.320 --> 14:12.320 First of all, I'm honored to have the decentralized special. 14:12.320 --> 14:17.800 When you're trying to contribute IPFS into the browsers, you said that they're very cautious 14:17.800 --> 14:19.360 and slow. 14:19.360 --> 14:25.280 Is there anything specific you can say in terms of what technical pushback or what concerns, 14:25.280 --> 14:31.600 what terrible thing is going to happen in browser land if they were to accept your contribution? 14:31.600 --> 14:43.480 I think they're slow for good reason, they are a huge vector for people doing trying 14:43.480 --> 14:48.080 to do all sorts of great things and terrible things on the web. 14:48.080 --> 14:53.800 The way browsers are archstructured, most of these newer capabilities would be feature flags 14:53.800 --> 14:55.800 or enable capabilities. 14:55.800 --> 14:59.640 A lot of these browsers don't even have those controls built in. 14:59.640 --> 15:08.160 So it's a multi-step process, like first, get them to support configurations or build 15:08.160 --> 15:14.440 variants or things like that and then make the case for your specific technology to be accepted. 15:14.440 --> 15:21.200 So there's probably different stories for different heroes, journeys for each of the different 15:21.200 --> 15:28.440 capacities we want to see in there, but I don't think it's unreasonable, but it 15:28.440 --> 15:31.720 is tedious. 15:31.720 --> 15:40.600 Manual or do you want to add anything to that? 15:40.600 --> 15:42.600 One of the challenges is even talking. 15:42.600 --> 15:48.960 Some of these concepts are so foreign to how the HTTP security model is designed today 15:48.960 --> 15:54.960 that even talking about something like a cryptographically variable address and data as 15:54.960 --> 15:57.560 a security model is really challenging. 15:57.560 --> 16:06.320 When we proposed IPFS at the WICG, just proposed to talk about it there and did not get 16:06.320 --> 16:09.520 approval to have the conversation. 16:09.520 --> 16:14.560 And so there's this technical challenges and cultural challenges, but also an insularity 16:14.560 --> 16:18.760 to how the web itself has its success as cemented. 16:18.760 --> 16:23.240 It's thinking about HTTP and the role it has in browsers, it makes it challenging to even 16:23.240 --> 16:27.520 bring up new concepts, like cryptographically variable as a 16:27.520 --> 16:33.200 an origin or authority concept. 16:33.200 --> 16:41.600 I think certificates just got widely known and accepted, so yeah, things take a while. 16:41.600 --> 16:51.600 All right, any other questions? 16:51.600 --> 16:53.760 Hi, first of all, great talk. 16:53.840 --> 17:00.640 My question is, what kind of work has your organization done relating to displacing 17:00.640 --> 17:05.520 reliance and say the domain name system or certificate authorities for TLS? 17:05.520 --> 17:09.600 When I try to do, I work in the peer-to-peer space that it's hard to do peer-to-peer stuff 17:09.600 --> 17:14.000 in the browser because of things that rely on centralized authorities like this. 17:14.000 --> 17:19.000 So I'm just curious what your vision or long-term thinking is on that subject. 17:19.960 --> 17:26.680 Again, I think because we're working in a very dynamic and shifting ecosystem, we haven't 17:26.680 --> 17:29.960 designated, like, hey, this is our one path to success. 17:29.960 --> 17:34.360 There's a couple of things that our community has done, or our organization, and our 17:34.360 --> 17:36.360 collaborators have done. 17:36.360 --> 17:40.240 One is actually just to start issuing certs, our cells have like automatic service issues 17:40.240 --> 17:41.240 certs. 17:41.240 --> 17:47.880 The other is that a number of groups are creating basically capabilities based tools to bundle 17:47.960 --> 17:51.560 tokens, off tokens, alongside content. 17:51.560 --> 17:56.200 You can probably the one that I see the most of, but there are many others out there. 17:59.640 --> 18:01.560 All right, we have time for one last question. 18:02.280 --> 18:04.120 So who wants to hold the spatula? 18:08.520 --> 18:09.240 Okay. 18:10.840 --> 18:14.200 All right, let's go and do one more warm round of applause for Moshley, everyone. 18:14.200 --> 18:15.160 Thank you very much.