#DappCon22 : Day 1 - Immanentizing The Web(3) Platform - Dietrich Ayala

Transcript

in monetizing the web 3 platform yeah hard work right using ipfs browser Integrations to turn the biggest ship so I'll open it up for the Trish I I really I had no idea that we were going to be on an actual ship on a boat when I made this title up uh but it is fortuitous now will the slides work let's try maybe I can't turn the ship I turned the ship too fast there yes so I work at protocol Labs my name is citric I work on ipfs related things uh

for over a decade before joining protocol Labs I worked at Mozilla so I shipped my first feature in Firefox 2 2006 uh it was a feature to restore all your tabs and things where the browser crashed because it crashed a lot it was super fun and I got to spend over a decade learning about how the web is made learning about how browsers are made and then when I wanted to change how the web is made doing this work at protocolabs equipped me very well for understanding the lay of the land who the people who the organizations were how change is made protocol Labs takes a very long view of this type of change which makes it a good home for doing this kind of work if you have not heard of critical Labs you may have heard some of the projects

we work on ipfs theater planetary file system which I'll talk mostly about today lib P2P a transport agnostic peer-to-peer toolkit many Technologies not just ipfs are made with lipidippy and filecoin which is for archiving data and files for the very long term for Humanity uh ipfest is what I work on primarily ipfs is a content and address to P2P file distribution system so this means that instead of like the regular web where you would address something by its location like the server name the domain name path to a file on ipfs you address things by the identity of the contents by basically like the hash generated for the most part simplified from the bits that comprise the file so

if you have a photo and you change one pixel in that photo the two files are now that one files now too two different addresses for the same file you may be familiar with ipfest if you've ever worked with nfts this audience I'm sure you're probably very familiar with these things but worth covering quickly these are some of the people that I work with on the browsers and platforms team we're a very small group that work on integrating ipfs into places that it is not typically um so working on browsers but also a number of other places so we have folks that work on uh this guy smiling up in the really big in the front actually has been working on trying to get ipfs into ffmpeg and curl which has been a very interesting journey and super hard and really challenging but working with open

source toolkits and libraries to be able to get ipfs integrated into all these places where it normally might not be um some of the groups that we work with here everything from browser Integrations to privacy oriented Messengers to operating systems and things like that um this is a very old copy of the file wow it has some of these lives though hey did you uh well I'll I'll just take it and see how it goes I don't remember what slides were in here from two weeks ago but we'll find out one of the challenges with ipfs integration in browsers is that in web 2 is a very particular architecture this architecture has grown to be you know billions of people using the web

architecture platform Every Day to a very small number of entities that actually make decisions around how this platform is designed HTTP JavaScript CSS the Dom everything up and down the web platform stack is uh I wouldn't say centralized but it's the product of a very small group of people especially when you think about the implementations and the vendors that are doing it for four billion people using this platform that are fairly small number of people are involved in actually making decisions about for a browser market share very very particular domination of one particular web rendering engine which is Blink a webkit a second but pretty far behind and then any other webinaring engine very very

far behind that when we think about the developers that we're actually trying to change the minds of that we actually need to address the needs of over 20 million developers maybe 30 actually by this point and web3 still further as well but we're getting there um so for this team and our approach to changing this web to turning this really big ship we have a thesis which is basically that actually integrating ipfest into the web platform itself ends up being the only way that we have an unfair advantage and actually have some leverage against very very large organizations that are making decisions about these Technologies the ubiquity of the web means that if we can change the web itself we don't have to convince all

of these hundreds of millions and even millions of people to change their behavior as much because those web rendering engines actually get shipped out to those operating systems and platforms that we would otherwise want to change if we can create enough just enough of a wedge of integration and implementation inside things like like the web platform itself those then get propagated and percolated out to all the places that web rendering engines actually get deployed so every operating system whether it's mobile whether it's desktop and we believe that these things will mutually reinforce each other and we can actually accelerate the integration of these Technologies but it's complicated there's a lot of organizations and places where decisions are made around the adoption of these Technologies some of these places are like the w3c the ietf where technology

decisions are made in groups of people that are pretty focused over very long periods of time to be able to make this change there are some myths around these things that they can be they can be slow they can be bureaucratic is true to some extent but also with the right leverage the right approach you can actually make technology change pretty quickly so one of those myths is that on web3 we don't actually need to do any of this and we could just build our technology it will be so amazing that the other billions of people will actually just change their behavior and use our stuff immediately which is obviously not the case it's very very long period of change to be able to change the web itself and to be able to change the technology decision-making behavior of developers let alone the actual companies that are

shipping things and user Behavior as well so oftentimes the people that are in these decision-making fora like the w3c are the same people that we want to be able to make decisions in our favor at chromium and in Gecko and in webkit and all these other places so they end up being the same parties ultimately in the end so it's in our Behavior it's in our best interest to be able to participate in those decision making for us this is a view of how long it took for a CSS grid to be first implemented in uh Internet Explorer oddly enough and eventually adopted across all of the major browser rendering engines it takes a really long time to make change in these places and this isn't even

something like a security model or privacy Paradigm this is for layout on the web which everybody known has been broken for a very long time it's very difficult to deal with but eventually we have CS grid CSS grid things are a little bit better now but even for something as uncontroversial as laying things out on a page the pace of change can be really small however one of the things that we learned when CSS grid was ultimately adopted was that when a coordinated group of people with a shared interests actually we get together and decide to implement something and coordinate that release in a short period of time you can actually rapidly accelerate the adoption of that technology and you can look at sites like can I use.com to be able to see what different versions of What

rendering engines support which Technologies and we look at these as a way to be able to understand how much of that technology has been shipped and whether developers can actually choose it and in the case of developer and of says that's good developers and designers they can't use CSS grid if it is not in the places where they need to deploy their applications to and we have the same challenge when we're shipping web3 Technologies it's really hard to get adoption when you have to use centralized on-ramps to be able to get to decentralized systems and networks and that's one of the reasons why we work on changing the browser platforms itself slowly getting adoption and integration so another one of the challenges is that when we talk about things that seem

pretty normal in a room like this and at a conference like this this is what we sound like in places like the w3c and if you followed along with like the did core adoption like there's a lot of hostility and skepticism and a lot of friction in getting anything related to decentralized technologies that are not http in I actually agreed to and turned into a standard at these standards bodies so it can be really challenging one example is that we wanted to add the safe listing basically like there's an API in the web called register protocol Handler and you can tell the browser hey with this JavaScript API I want you to do something like call this JavaScript or whatever when you encounter the ipfs

colon slash protocol we wanted to change that register protocol Handler across all browsers to be able to accept ipfs but we actually added this is the newer one initially we came out with like Bitcoin ethereum SSB dot ipfs ipns like we just added a bunch of stuff that said hey can you just whitelist these protocols um and we went through this process where we you know talked to the different rendering engines and some are Immortal you have to go file bugs for each one we actually partnered with a company called egalia that has commit privileges across Gecko webkit and blink and we worked with them well they wouldn't register the protocols unless they would actually registered those schemes or registered with Yana so we had to go to iaana register those

schemes that took another couple of months we had to go to all these different distributed projects like we actually went to the scuttlebut people and said hey mind if we do this and they're like we have no leader I guess so or not up to you we went to the DAC community and they were like yeah sure do it we eventually got those white listed allow listed and then we put them at the what WG we finally go back to Mozilla who'd actually added these schemes and then removed them again and they said well we're only going to add ones that have been standardized which leaves us in a weird place because we can't add anything that hasn't been standardized but we can't Implement anything in our browser so we end up in a situation where I'm not sure

that we're getting the whole story here because there's a lot of skepticism around these Technologies generally um but there are a lot of Leave it to say there's a lot of barriers involved and in order to be able to cross that cosm and get these Technologies implemented into these places we've kind of moved along we want these people to be on our side like I said before we want to have a relationship we need credibility we need to get our Technologies into these channels deployed out to end users so we don't have to keep jumping through all these centralized tubes um so we did join the w3c as protocol Labs we participate there we participate in the ietf for a couple of our Technologies as well we have folks that are working on things like HTTP 3 and then a couple of different other organizations that we participate in we

need to be able to do this in order to be able to make these uh at least build some credibility there but at the same time standards are not they often are written after the fact of implementation in order to be able to get to the point where those standards are adopted you need to have some adoption already you need to get to the point where there are multiple interoperable implementations of your technology so this is kind of a map of how far we've gotten at this point um we're about to get to ipfs well more reasonable ipfs handling native and chromium and I'll talk about that in a sec but as you can tell from this there's a lot of work to be done uh it's very very challenging to be able to get any ground gains in the implementation of these things Opera was first they

initially had ipfs scheme handling and they redirected to a Gateway they did that across all their browsers Firefox I worked on that for a long time not really a lot of interest so far in this they actually safe listed the ipfs protocol just for handlers and then removed it so there's still really a lot of work to go there and they're one of the biggest objectors to the did spec specification um at the w3c they objected to the group even being chartered four years ago so there's really a lot of uh Softail battle there uh Apple slow going it's gonna be a long slog there's no incentive for them to change or adopt any of this we're gonna have to probably wait until we have much larger adoption in many other places to be able to have the environmental pressure required

Brave has been fantastic uh I know some of those folks because they're also from Mozilla we got a full ipfs node early last year um and you can flip that on a brave and a bunch of new features are coming soon around things like automatically archiving your nfts that you have to be able to make sure that not only that you can use Brave to be able to store and archive data and publish to ipfest to be able to keep not just yours but any nft is safe that you browse which is kind of interesting we're going to see a lot of new stuff there as well um chromium is definitely the most challenging so they've actually been reviewing our patches pretty quickly we get good turnarounds we've been focusing not on ipfs specific things but on interoperability and compatibility

across browsers so we fixed a bunch of things around the Local Host security model so if you want to be able to have your browser talk to a local ipfs node or a local node of any kind or a local you know like client of some kind you need to be able to communicate from a web page to localhost and there was a lot of compatibility issues around that specific security model about how browsers actually implement it so we gained some ground there and we got a bunch of patches landed one of the bigger challenges when you think about Native integration of something like ipfs or anything not HTTP at all in a browser is that up and down that browser security stack and implementation and rendering engine all the way out to Graphics pipeline how to permissions checks data storage everything is pretty HTTP Centric everything is oriented

around the security model of http and how it operates so we've had a project going with the Galia to refactor the chromium code base over this last probably year year and a half to be able to actually support non-hdb protocols more readily it doesn't go all the way up and down the network stack it doesn't go all the way up to every little nook and cranny of the rendering engine but it goes a lot farther than it did before this is one of the key things that is not ipfs specific necessarily but it helps this entire space when anyone wants to add something to chromium the you know open source code base that Chrome and brave and Opera and Edge all built on not just ipfast so we think this is going to be pretty impactful we're going to announce the the most

recent changes around scheme handling probably in the next couple of weeks in conjunction with the Galia this should be make it like really a lot easier for brave for Edge for Opera to add things without having to add a bunch of custom codes chromium and we're not getting necessarily explicit signals from chrome saying that we would do this or they would Implement anything like this but what we are getting is really a lot of appreciation and cooperation from the chromium Community around these types of refactorings so there's definitely interest and awareness in this work and understanding of why it matters um ibfs companion is a browser extension that's available all over the place now one of the challenges with extensions is if you haven't heard of it there's a thing called manifest V3 it's a new

format of browser extension that is radically reducing the surface area of what extensions can do and it's problematic in a couple of ways I think initially we thought that browser extensions might be a route to be able to get non-hp protocol support inside browsers however with manifest V3 and really reducing what you can actually do inside of a browser extension it's become ever more important now to invest in non-hp protocol support inside the rendering engines themselves because you can't do nearly as much with manifest V3 basically every other browser vendor is also adopting this even though they don't have to Mozilla adopts manifest V3 but does have like a super set of apis that it adds it allows you to do other

things like ad blocking a little bit more Network functionality but really all browser vendors are kind of locking down extension space because for them it's a ux issue it's you know one of the biggest battles I fought when I was at Mozilla was the fact that browser extensions make browsers very very slow in browsers you have to be very powerful about the code you land lots of code that I landed got backed out because it made the browser slower and I wasn't able to land it and merge that code until I didn't reduce things like browser startup time for example but browser extensions are have the ability to really slow down browsers so it's complicated in that regard they're also a security problem so browsers do or browser extensions can do all kinds of things they have elevated privileges that a web page can't so they exist

outside of the web Sam box and therefore are a threats and one of the big changes in manifest V3 is that it really moves a lot of this code to be treated more like a regular web page which reduces what you can do with it but also as a trade-off for safety and your user experience from the vendor's point of view but from the things that we want to do like change the nature of the web itself it's very problematic um so what's next a couple different things we're going to see deeper browser integration uh or protocol support and integration we have this initial code in chromium that allows us to more easily register non-hdb protocols and schemes but one of the next things we're going to do is actually do a native integration so instead of just having ipfest colon slash and chromium be able

to redirect to a ipfs Gateway somewhere we're actually going to have rust ipfs in there as a native implementation sitting inside the chromium Network stack this is probably going to be a longer project but it's going to be pretty interesting one thing we're seeing is a bunch of different I guess Boutique browsers pop up so things like puma and bloop and well all kinds of like not really web 3 oriented ones but lots of lots of people experimenting with browsers as a business model as an alternative to kind of like the main State browsers that you've all heard of that's really interesting we're also experimenting with new architectural approach as to how ipfs can be implemented right now it does require

you know a whole bunch of listening sockets for be able to have a P2P connection however for something like mobile that's not really reasonable we need a implementation of ipfs that is along that centralization decentralization Spectrum at least less centralized and maybe that looks like racing a bunch of HTTP gateways to see which one responds first maybe it means using local OS mobile network Stacks in a more concerted way that aligns with mobile connectivity models that telcos have today but it can't look like opening up 700 TCP connections on a mobile phone so a lot of experimentation with that we are hiring if you are interested in doing work around standards implementation rendering engines definitely find me and talk to

me these people in the face of this enemy Frenemy situation are still smiling for the most part but I think the look on our face oftentimes in these negotiations end up like this it's long slow difficult work to be able to change the direction of the entire ship itself but it's super interesting and we've made some gains and hopefully the entire space of crypto blockchain and web3 will be able to benefit from that thanks [Applause] I think we have times for two or three questions Maybe Sarah raise hand or just so y'all no

it is a right hand yes hello thanks great presentation I just have a unrelated question when is the protocol Labs week in Portugal yes I I think it's the ipfs camp is ipf October 28th through 30th and then falcoin Lisbon is right after that and then there's also a lib P2P day that I think is October 30th okay thanks so basically that whole week at the end of October awesome thanks yep there's another question right there um I just my question concerns that I used to work on Swarm which is

also a decentralized file storage and we were this short of giving up and saying we're just going to launch our own browser you know like the the Swarm Browser Bundle um and the problem with us is we didn't just want to talk to swarm nodes we also needed to talk to ethereum nodes and now would be gnosis chain and a whole bunch of other things so where in your work how much of this is ipfs IPS specific and how much could be used to open up browsers for a whole you know much wider range of peer-to-peer sources of data and info yeah that's a that's a fantastic question and I think grounded you know like I I come from years and years working in web 2 and only recently in this last few years I've been focused on ipfast and really after kind of hitting that wall also of being like

even being in browser world I couldn't change browser world and really had to step back from that and one of the approaches that is that we've grounded our work in is thinking about non-http first how do we get to the point where and really yeah I guess at a higher level strategy uh try to change that world slowly while also implementing in parallel with things like Brave so with like I said before a standard isn't like a group of people build that standard and then follow along everybody implements but more like some success is gained by folks that are shooting forward so we take advantage of vendors like Brave that are really interested in pushing on the limits of what the web can do in adding some of these features

and hopefully using that as a leader to be able to open up the credibility and the reality making it seem more real in the nature of those conversations with other vendors but even all of that still grounded in a not not just ipfs but in places like chromium really focusing on not HTTP and then slowly adding showing what we can do with ipfs in that space that we open up of non-hdp protocol place so but our dream has been a browser that could only talk Bzz completely not be allowed to open any https connection because that makes it impossible to put tracking code in any text right Vision right and that's something that from look thinking about your users if

you yeah but but you know tilting at those windmills are what lead to reverberations all the way back as people say okay well maybe we can't go all the way but we can do a little bit and then a little bit and a little bit so like I always encourage like some of these you know alt browsers and boutique browsers that we're seeing I encourage them actually to take that route like if you're going to do that experiment go all the way prove that concept show what it is possible especially with a community of users that may have dire critical need of that use case like the I cannot be tracked is a valid use case and there are some people that are absolutely willing actually have to make that trade-off in what they choose and use so you kind of got to have both

all right thank you very much Diedrich thanks everybody [Applause]