ZKPodcast: IPFS 0.5 with Molly Mackinlay from Protocol Labs

Transcript

[Music] welcome to zero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me Anna and me Fredrik so this week we're chatting with Molly McKinley from protocol labs she's the ipfs project lead and today we're gonna be talking about the IP FS 0.5 release so welcome to the show Molly thanks for having me so we did an episode with Juan Bonet from protocol

labs back in I think November and in that interview we did but I think we used about like a third of the interview to talk about IP FS and to set the groundwork of like what this is and how how it's been used up to now but the idea with this interview is to sort of say it like ok from that interview and maybe even a little bit before that entry what's been happening with IP FS so I think to start off it would be really great to hear a little bit about you Molly and how you arrived at protocol labs and how you started working on this project absolutely and yeah so I'm Molly I'm the FS project lead my kind of long-term background I had a background in

human-computer interaction studied CS and then went to Google and was a product manager at Google for 5 years and while I was working there I got really excited about building tools for teachers and students I was on the Google classroom team and spent a lot of time in schools thinking about you know collaboration within the classroom and the work that people were doing back and forth realized that the way that internet was functioning the the way that the centralized model forced everyone to ship updates between teachers and students off to some distant cloud infrastructure in order to turn in assignments and do collaboration was like really broken and we kept having to do all of this weird stuff in our mobile apps to try and get around

that and really at the end of the day there just wasn't a solution we you know tried a lot of caching but you just couldn't collaborate most schools have really terrible infrastructure and Wi-Fi so that was kind of my aha moment and when I started really participating just really 1% time in the idea of s community and that ramped up over over the next couple of years and I've now been working on the IPS project for about a year and a half full time and then that ipfs project lead for about a year and so kind of my kickstart Mo was like the web should work offline first we should have this local collaboration and the efficiency of not having us an intermediary or middleman or someone else that's you know siphoning your traffic and then shipping it back out to people was kind of what

what got me excited initially but there's a ton of other use cases that you know I continue finding new ones for it's like oh that's you know the content ownership story where this actually is really relevant from an educational background perspective as well but this question of who owns the content on the network you kind of ended up in this classic struggle where the central app or entity would end up owning all of the data created by students and teachers which was just this weird model which didn't make any sense like the app would shut down or stop offering a feature and suddenly teachers and students would lose their instructional data or not be able to access it anymore they would and they'd have to completely change their instructional model and so that kind of being variable holden to some central

service provider was a kind of nonsensical thing that grown in the internet in in kind of the centralized application model that was I was excited about hub kind of coming to ipfs and changing that's so interesting that you came from this like educational or communication is sort of like that it was more for it was from a practical use case that you saw the problem that the internet had and then sort of delve in totally jazzed about it so like and I said we had gone on to talk about ipfs protocol labs in general with the goals of the company are and things like that and I think we've actually covered ipfs in various ways through many episodes

because it is a thing that pops up every once in a while but I think before we dig into the update and more specifics let's do a general introduction again for those who haven't heard the content what is IP if as you know what is it for what what does it do totally IVFs is a peer-to-peer protocol and network it relies kind of baking this core concept of content addressing into the web when you look out into the network the idea is instead of relying on central location addressing which addresses content by where it's located the network or whose hosts what domain has instead dress addresses content by what it is it's hash or fingerprint and that allows you to load

data from any peer in the network that's offering it which means that when the network has a fault or hits divided or you're just you happen to be offline you can fetch content from anyone else in your subdivision of the network who has it it also offers a lot of security benefits where you can truly identify what the content is instead of relying on some central party to serve what you know whatever they want to you from the the URL that you're accessing and so we have this large distributed network now of hundreds of thousands of nodes that are constantly sharing data with each other coordinating peer-to-peer anyone can join the network and a ton of applications are built on top of that distributed file system yeah it's yeah

it's a distributed file system that's content addressable so in essence it means that instead of going to google.com to get their website I try to you know I wouldn't enter in but somehow I get the hash of what the google.com website is I enter that hash in and whoever happens to have that can serve it to me and and I think a confusion point that I see a lot with IP FS is that everyone will have this content but that's not true like it's at the base it might still be Google serving you that content but if my neighbor went to google.com and got that content first and then the default option is that they

cache it and we host it but even if that wasn't the default option they chose to cache and we host then I would just have to go to like my buildings switch to go to my neighbor and then get the content I wouldn't have to go to Google exactly and it's also I'm a classic 10,000 tabs person and so I'm very frequently reloading content that I actually already have opened somewhere or I just closed five minutes ago and so it's that that case as well where you may likely already have at least large portions of the content that you're trying to get from somewhere on the internet whether it's a lot of sites using similar Java script or whether you're updating a package manager and only a few things have changed by content addressing

everything you can very easily identify what content is new and only fetch the data that you don't already have and so when you're fetching over ipfs bit swap which is our transfer algorithm we'll be like great I already have all of these blocks I don't have to ask anyone for it and then the new blocks that you you need to get in order to update your package or load in the remaining bits of your website and can get from anyone and that could be you know another computer in your same room where you know you frequently have this thing where you're trying to transfer content between two computers the fastest way I can find to send a picture between my Android phone and my iOS phone is like sending myself an email or syncing it to some sort of centralized photo sharing app we're just

insane and so just just that model where you can very directly move content between the devices not just that you home but are within kind of connectivity of you just it seems like the way the internet should work yeah I have my favorite ipfs story even though it's it's not necessarily super ipfs specific but is someone setting up an IP FS server and routing all NPM traffic through that so it was like in an office someone set up and Pam server and it saved them like tens or hundreds of gigs of download per day because every time you do NPM install it fetches every single package even if you already haven't Ori oh my god that's crazy

even if someone else in the office is already run npm install so though i mean that that's a nice use case you could do the same thing with like a lion cache server or something but it's more fun with IP offense totally and it gets even worse the larger your packages get right so like imagine that your your instead you know downloading a lot to move onto images or something like crazy yeah yeah so in the last episode we did actually speak pretty much in depth about lib p2p I'm not sure if it makes sense to mention it here but maybe maybe we can we definitely can like that's our that's the networking stack we use so the the two most related projects to to ipfs that we actually joked that ipfs is a trench coat wrapped around I peel the

lid p2p and then kind of our our UNIX FS data model for files like IVFs is pretty much nothing it's just packaging these things together such that we make a full file system but the IP LD is kind of how how we construct the data if you will the the model for C IDs and things like that and then Lapita p is the peer to peer network component of things that kind of has the DHT has the pub sub layer has has how you address peers in the network and actually a lot of the improvements that we've made most recently are like on that intersection of ipfs and the p2p and then the kind of remainder is you know transfer algorithms and stuff like that okay so I it's it's interesting this like your

background in education and this work about like students and professors sharing do you feel like ipfs reflects better what the vision that you had for what you would want and I kind of and I want to lead in a little bit with this if we mentioned this last time in our conversation with one about potentially doing like collaborative work on top of IP FS this idea of like sharing things and I'm wondering yeah I think we talked about it really briefly I know it's not a particular IP FS project but maybe we can talk a little bit about that yeah so there was a project back in 2018 called peer base that was something we were working on in was like the dynamic data and capabilities group so there was a

working group that was about how we could bring CRT T's into ipfs especially there was kind of a misconception of like oh you can't do anything dynamic if you have static patches underneath if you have a static these how could you make anything that you know updates quickly which I think is much less of a misconception now which is great we said we had a we had a group who was looking at that they built this this library kind of like trying to be a firebase on top of IP FS to just make building apps and tooling to make that a lot easier and so they worked on that for a while and we actually spun up a pretty pretty decent you know markdown collaborative markdown editor that worked fully peer-to-peer called pure bait you know pure pad that's what it

was and that group was you know pushing things forward but at the end of the day we realized a number of groups out in the ecosystem we're actually also very interested in this problem and we're taking it further than we could so textile started building a lot of their tooling around threads and now buckets which are kind of doing the same thing but better than what we had initially been experimenting with so again like append-only CRT T log and there's a number of other groups doing the dynamic app database work so orbit and three box are other examples of groups that are kind of pushing that space forward faster than we could so we we focused more on the core of the protocol making sure that everyone could rely on a really stable

core that was performant and made all of those dynamic use cases possible and what about that that education idea like did you do you see reflected in this what you know what you had originally envisioned yeah I mean I think there's more far more than I'd originally envisioned I was at the very top of the of the problem and hadn't looked all the way deep into kind of the challenges of of unspooling things there is actually a group that I found like six months into working on my PFS that was using IP FS for the the use case I was talking about where teachers teachers and students they shouldn't have to have a third party that's owning their data so they were doing it for like data ownership for teachers and students so that you

could maintain like you know in a peer-to-peer model both parties can have ownership of the data and host the data and make sure that no other organization can take it away from them or go offline or something like that I think there was a group in Australia or something like this that had started up a project like that it was like oh how I never thought at using IBM s4 that youth taste that's amazing yeah the the collaborative side of things I haven't seen this applied to the educational world in particular but I think the fabric that's being built like the way the Internet is working I'm seeing that play out in a couple of other industries I think probably hasn't made it to education yet just because the UX requirements in a classroom where

I say you have 30 students and a teacher that's just trying to keep things under control like the u.s. requirements therefore it being like really easy to use and just very simple are really high and we're still working to get to that point in the web 3 space right now but I think there's a number of other tools in in the ipfs ecosystem that are kind of approaching that from a collaborative kind of data updating nature an example I'd call out that is kind of like the messaging side of things or there's a group called birdie that's working on kind of offline first messaging over Bluetooth so you can just kind of have two devices next to each other an Android and an iOS and that's hard like getting the two of those to communicate over Bluetooth with all of the complexity of mobile stacks and api's is

like immensely difficult they have a great article about like the spelunking it took to get these things to talk to each other but I think that's that's one we're kind of from a mobile perspective you're offline in like a conference setting where the Wi-Fi has gone out and there's no no internet no cell connection and you can just have two phones speaking back to Eve and forth to each other over bluetooth using IP FS and Lapita P that was like oh wow it's happening the the thing things are lining up and getting into place for this to actually work that would be amazing at festivals which if I don't know if we ever get to go to those again but I know I know uh Pierre who writes rust Lapita PE he actually wrote a

Bluetooth transport layer for us loop EP as well awesome experimental I don't know if he got it to work across devices that was a CEO was just Android yeah but it's it's curious I mean we did it as this sort of thought experiment of like what what a you know how do block chains work if the internet goes down trying to build World War three proof software is hard but that's all we're trying to do but anyway I let's let's move into the main topic I think of this of this episode which is this point fiber release it's curious to me just to hear a little bit about the

history of how we got to this 0.5 because ipfs has been around for many years I don't know you even know how long like 10 years something like that 2015 so ok five years yeah a long time and it's still not 1.0 but it's but it I still at the same time I get the sense that development has sped up that things are sort of happening again it was not really doing anything for a long time probably like my assumption was because for collapse is basically happy with where it's at but it does feel like it's bed up and you know what what are some

of the reasons behind that yeah so I definitely definitely agree with the feeling that that we're speeding up as as a team in community definitely seen a lot of energy and the ecosystem a lot of new groups coming in and pushing things forward and as a team we've also we we feel ourselves that we've sped up from a development velocity perspective like the working groups pushing ipfs forward are awesome and executing really effectively I'd say the the biggest differentiator in kind of how we achieved that is thinking through the things that make us more effective and allow us to target changes that feel really large and

really beneficial to people and for this it was actually kind of turning away from ipfs itself and then building what what we're calling test ground which is a new set of testing libraries and and tools for simulating large distributed networks and then improving and iterating on them which has allowed us as a team to like really iterate much faster and prototype when we have you know hundred thousand node Network can be pretty difficult to you know in your brain picture what an improvement or change to the network would do like will it actually work if you know we remove this timeout here if we start putting records in this place versus where we did before is that actually kind of function and so instead

of guess and check which was kind of what you have to do if you don't have any way of stimulating things where you can like reason about it on paper and then hope that you got it right we built a full distributed testing environment so that we can simulate things like Network latency jitter multiple versions and the network nodes that are undeniable all of these things about how the IPS network is in reality and use that to make a ton of improvements to the protocol itself and so that helped us kind of with the same team ramped up from a development velocity perspective we also spent some time thinking about like previously when you think about the teams that are working on ipfs and lib p2p and other things we were pretty

separate where we reach kind of focusing on the chunk of users and and applications that were adopting each protocol and for this one we we actually took the IP FS and Limpy to be teams and have them sit much more closely together and and collaborate because all of these challenges are the things that are making Lim p2p better for everyone and so it's a faster feedback loop between people who are using the p2p in the wild and the team that's innovating and improving on it and so I'd say like back in beginning of 2019 there was definitely like who the DHT it's not scaling to the the new users we're seeing an IP FS network we we need to like go in and make a number of improvements and it wasn't until we were able to build up this tooling and really

set the teams more closely together that we could make really fast progress on landing like pretty major changes to how the DHT was kind of formed and oriented and so I'd say that was the difference there I love the way protocol labs like you'll build out tools that then become like things and themselves like that you could almost my release into the wild it sounds like test ground is very specific to ipfs not at all actually you would say no okay so would be bigger so that there's definitely a way to build something like test ground that would be very purpose-built there was like we can test the DHT and that's it nothing else but that's not how we like to build things we think of

things as more modular more kind of multi-purpose and we also knew that we would have a lot of other use cases where distributed testing infrastructure would be the thing that would help us execute and so you know we had it in the back of our mind that we're gonna want to test a lot of other things than just the DHT we actually did immediately the first thing that we tested wasn't actually the DHT at all it was bit swap it was the the transfer algorithm that we use in ipfs and so good thing we didn't build something that was like very highly tuned for that use case because we wouldn't it wouldn't have been as reusable and so you know we're using different parts of test ground so using less of the network jitter and more of the you know many nodes kind of peering with each other and sending data

back and forth but actually yeah even since then the lib p2p team has been using test ground to do hardening for gossips up and so they for at least another I think version 1.1 of gossip sub which has a lot of improvements that were made using test ground and running these kind of large attack simulations and making sure that Lib PP was resilient to all of those sorts of attacks I think they'd source from like the theorem 2 team that's using the p2p file coin that's who's sitting with p2p and a couple of other groups of like these are the sorts of things we need to be resilient to so that was again very multi-purpose much more modular like you could even use it without the p2p I think it's definitely not ipfs specific and I think maybe even more general than

lib p2p but the long term vision which i think is still always out there but crazy idea going forward is to actually think about not having any like a single entity you have to spin up test ground or run tests on regularly but actually think about each node in the network as kind of our participant in test ground that's running test cases which would allow you to do a lot of them kind of more exactly yeah future direction to continue exploring there that'd be super useful yeah would be cool okay you're using the acronym DHT what is a DHT idea she is a distributed hash table it's how all of the nodes in the IPS network

coordinate with each other in order to route content we actually had a had an episode with dominic tar from skewer scuttlebutt and we talked a bunch about networking and DHT specifically and both problems that they solve and problems that they introduced might be worth listening to we'll add that in the show notes I'm curious to hear more about how if one one it's used test ground like how do you actually integrate is it that you you know define your program in a docker image and test ground and launches docker images or do you have to like integrate with something or use some library yeah so there's a couple of different test runners and so there's a local test Runner which uses docker and

there's a cait test runner and I think also docker swarm so there's a couple of different ways nice thing about that is it lets you start up locally using test ground and kind of doing fast development on your own computer and then going out to the cloud and spinning up much larger clusters being able to you know scale this up to I think the the largest that we'd got for ith T tests was 2,000 individual nodes simulating like all of the realistic network configuration that we needed but I think the gossip sub-team got that even larger I don't know how many thousands but you know maybe to two to four thousand no it's something along those lines and to the kind of scale there and the things that it lets you simulate as real live large-scale networks where you have all of these

nodes that that kind of follow you write a test plan of you know great here's what the network's configuration looks like these are the the kind of sets of behaviors that I want nodes to do and this is kind of the parameters for the network so you can set things like great I want 50% of the nodes to be running this version of IP of s and the other 50% to be running a different version so you can test interoperability you can make half of the nodes under both so they won't actually respond to requests which was really important we've seen a ton of nodes join the ipfs DHT and that's great but then if they are participating as DHT servers that's not so great because they start being like you know awesome I'll join the DHT I'll be useful and then people try and

dial them and ask them where to go in the network to find content and they don't respond to you because you can't actually dial them and so this let us do a lot of those like test cases that we could run over and over and over again fine-tuning those parameters what do you write the test planning I assume it's and go because everything we do is go and that that's the the lingua franca of the team we also had the gossip sub team who was pushing this forward it did an integration with test ground and Jupiter notebooks and so they I think they wrote like a Python connector and then from within Jupiter notebooks they could do the set of configurations of parameters which meant they could tune them really quickly and then automatically push the output of

test ground into visualizations so you could have you know the graphs that we're showing what latency looked like or how many nodes would join their network nice you mentioned before bit swap let's define what that is cuz this is new right this is like coming with the release as far as I understand so bit swap itself has been around for for a while it's our know our data transfer algorithm was really bad its new in that like a ton of improvements went into it we've added a new message type so previously kind of the main white bit swap works is you're trying to download a file there's a large distributed network of nodes that could potentially give it to you and you'll

shout out to the DHT hey like I want this route CID so the root node of the entire Merkle dag that makes up the file and some nodes might throw that file at you which you know or that the the block that relates to that route cid which is great and you'll add all of those folks to a session you'll get a lot of those hopefully route blocks relating to that and that's maybe not so great because now you've gotten the same piece of content many times and that takes bandwidth from everyone to give it to you but now you have a set of nodes and you'll you're able to resolve that routes the ID to like the next set of blocks that you want to get and you'll ask those nodes for that content first if none of those nodes have the next layer of

blocks that you need you'll go back to the DHT ask them move or the blocks that you're missing hopefully folks from the dh2 will throw that those blocks at you and kind of continue from there the downside with all this is you'd get a lot of duplicate blocks because the way to ask for you know hey do you have this was like give it to me there wasn't a delineation between how those messages were structured and so now we've added a new message type which allows you to kind of identify whether someone has or doesn't have a block before they give it to you simple change makes a really big difference in terms of kind of throughput and how quickly we can scale to many different Cedars and folks that are kind of trying to to get a file from many people and you can be

much more intelligent about who you're asking for data and what you just said I can think of it maybe two ways and I want to I want you to tell me which way is correct on one side is it is it making it easier to fill in the blanks because you do less requests you only request for the pieces that you need or is it you only really make the request to those who have it which of those two is it it's more of the second one okay where again like you can check who has the data ahead of time before asking them to send it to you and then you can choose one person to send you the data who actually has it and who that you you know you don't have to ask many people that same request and then risk getting it many times or risk none of them

having it and then having to ask a much wider network cool I guess it comes up the trade-off of making more requests like you'd increase latency but it doesn't feel like it matters much in this context right it's more messages but the messages are much smaller so at the end of the day even though to being much much better and much faster and kind of the additional you can choose whether or not you want to use this nice to type you can start directly at you know hey give me this block if you have it Adams you can tune it a little bit yourself as well talking about the improvement I mean I think let's try to work through them and see what there is in this release of improvements the bit swap is one thing you mentioned all this testing and iteration on the DHT and

we've actually talked about this topic on the show before about how d cheese have many problems and I I also know for a fact that it was kind of funny when we started using the PHP when the two teams start using we please be it was a lot of occasions that we accidentally merged DHT and so so like the I know for a fact that the ipfs DHT is incredibly polluted because we contributed to polluting it yeah let's walk through those improvements maybe we start at the DHT yeah so definitely one of the the challenges with with IPS DHT

is you know a ton of entire level nodes a ton of folks sitting in the network who weren't being good participants in routing traffic and so one of the the big fixes there is to have nodes identify for themselves am i dial can I be a good participant in the network and use that to configure whether or not they're going to serve and kind of be a router for DHT requests or if they're just going to you know consume the DHT that others are running but decide hey like maybe I'm a browser node maybe I'm a mobile node maybe I'm behind a home firewall network and other people can't reach me I'm not going to be a participant in the public DHT and actually as a part of that nodes now run

to th T's they run the one that's like the public network where they may be a client because maybe they're behind a home home Wi-Fi firewall and they also run a local one it means that if you have like a home network you can still like find other nodes and connect to them really easily if you're offline and do routing behind that network so you might be a kind of more live participant behind the firewall versus being a client to the public network DHT and so that's one of the areas there was also just a ton of improvement to kind of the the logic of how we did routing so you want to get better nodes in the in the network that are helping route the content but then you also want to do you know better dials better logic about

when to stop and terminate you know how to quickly get to the end of your query so again kind of in a distributed hash table you know kind of arranged in the network and you're trying to find the set of peers who have the records associated with the content you're looking for and you know as you're as you're finding those peers you want to make sure that you're you know asking the right people and getting to them as quickly as possible and so we improved made improvements there just in kind of efficiency to get there and luckily at the same time this also meant that we ended up making fewer dials by a lot which makes things way faster and also reduces the the bandwidth usage for every node participating in the DHD and

so those are a number of the the changes that we made there where did that like was that a sort of engineering task of just sit sit down figure out where things are going or was it here's a new piece of research on how to do routing in a DHT or here's a new discovery algorithm or like where does the improvement really come from yeah I definitely we did have kind of a you know we spend a lot of time with a foot in engineering world a foot in the research world this wasn't new research that we were kind of synthesizing and adding it was more going back to brass tacks and you know taking the existing DHT logic the network that we had and the research and kind of comparing and contrasting really great you know here's

the here's the implementation we have how does that line up with existing code emiliya all right what improvements in iterations do we need to make on top of that given that we have this very large network with many nodes not being diable how are we gonna respond to that what improvements are we gonna add and from there it was really kind of once once we did that research census analyzed our existing networks and got the testing set up so we're able to get some baseline results about things like how many notes were dialable and and things along those lines then it was kind of it was iteration of landing changes seeing how they performed in in our test cases and iterating and so it was mostly an engineering problem more than it was

like a research problem I'd say like prioritization was where the research were really helped it was like great which of these changes is going to have the most measurable improvement to performance to the metrics we care about which mostly was how quickly can you find the content that you're looking for in the network that that was kind of also where research really helped you know kind of at the last minute I think we switched from making sync DHT queries to async DHT queries and that had a very large noticeable improvement and so those are the sort of things were like looking at the the ecosystem the existing research and just picking and choosing the exact improvements that we're going to to make the network better talking about improvements are there any other major

improvements that we should be aware of I'd say like the two probably top headline improvements are the set of DHT improvements so that's faster finding faster providing of content that really flows in there are a number of things people are excited about Frye pns which is our naming system so how you do mutable links in IP FS which are getting a ton faster but that's actually mostly based on all of the DHT improvements IP NS was just a very heavy consumer of the DHT because you're trying to get many different copies of a record to make sure that you have the latest one which meant you were doing a lot of DHT requests and making the DHT faster and updating some of the logic there around

IP n s kind of how quickly it would string back results to you that's made IP NS both um gets and puts a lot faster and that was very slow and people were very unhappy about it so we're glad to make that less painful for for folks who are using IP NS that's kind of an important thing to mention in our tests and so we've been using test ground very heavily throughout for for all of these features and improvements but test ground tests for IP NS are just like astronomically kind of off the charts when we were doing kind of our 1k tests where we have 1,000 nodes running the old DHT trying to do like a normal test plan of like updating IP NS records and

fetching updated content versus our new phone v release in the same test case we see something like a 30 to 40 X improvement in speed of like actually being able to do those gets inputs and so that's kind of the order of magnitude we're talking about here in terms of making things better that again it's a test case and so that's with like a fully upgraded network with kind of not ideal conditions because we do model a lot of things around latency but pretty it stimulated and so that's probably another thing to mention even though it's not one of the the top level features that people are most excited about which I'd say are the DHT and transfer speed so you're working with Netflix tell us a little bit about how that that happened how that came to be

and like exactly what you're doing with Netflix absolutely we actually got connected with Edgar Lee who works at Netflix back at ipfs camp last June and he was really excited about a container deployment problem his team had where they have this kind of distributed build process and they were running into issues where they were hitting the API as kind of a bottleneck over and over again it was it was adding a lot of latency to taking all of their kind of developer build process and putting it in the cloud and so he found ipfs started hacking on stuff and came to idea vest camp with a really cool demo and benchmark of what if I took this build process and put it

on top of IP FS and so we got to talking my PFS camp and kind of into the the next like a couple of weeks of like ooh this is really interesting yes it seems like there's a lot of improvement here but like we think we don't think this is hitting the theoretical limit we think that IP bus can actually be a lot faster than docker hub because we're you know like a a little bit faster at that point but it wasn't we think like highlighting the the true benefit of going peer-to-peer and so we actually started a collaboration with them and kind of Edgar and another engineer on our team started working on actually optimizing and tuning bit swap for this sort of distributed container image challenge where you have many many nodes that are trying to seed content from many nodes

that have the content because great you have the same container image you want it spread across an entire cluster really quickly and so Edgar built up a set of testing tooling called p2p lab which we were using before we actually got test ground off the ground to benchmark and intestine improve bit swap unfortunately this didn't have any sort of like real latency or anything like that all we could do was just optimize optimize optimize which is what we did and that's what kind of helped kick us into the the improvements you see now as part of this release and we actually we made a whole ton of improvements there and got to I think like 2x faster back in like the October time frame what as we were working on this collaboration

and then we were able to get another 40 percent improvement just with like additional bug fixes additional test ground tests that we were able to run and so that's like you know it just kind of keeps on giving every improvement we make to it is pushing forward and Edgar reran the set of benchmarks against the previous version of the tests we've made and the most recent one and saw like a significant improvement there as well so it's super super exciting and and crazy how the stars aligned there it was very much like folks coming and finding ipfs as a tool to solve a problem and then figuring out how to you know continue integrating it in and working with us as we work to make it better to make those improvements and and actually land it in

a way that could be usable by everybody it's always very much like hand in hand and and super exciting right like again the thing that helps here is truly having the benchmarks that show great if you use docker hub it's gonna take four seconds if you use ipfs it's gonna take like 1.7 seconds which one am I gonna choose if I want my engineers to spend less time waiting for builds to compile like clearly I'm gonna use the one that's 1.7 seconds and so that's like the sort of use case when you're working with like larger enterprises are folks that are kind of in the web to model and not leaning into I want it to be decentralized because clearly showing that that value add and that use case is kind of what tips a needle the exact problem that they used you for just to

be clear because like when I first heard about this I had the impression that like Netflix was somehow like using IP FS storage for others and tell me exactly it's not storing the videos and distributing the videos this has four this is on the developer side and this is you know as a as a developer you want to you know compile Netflix calm like what the code for it anyone make some changes to it instead of compiling it locally on your local device you want to use kind of a cluster on your local cloud where you can spin up kind of like a docker image and boom run your test and then BOOM spin down the docker image and get the test case back to you but you have many engineers doing that all at the

same time all using the same sort of docker image great how do you make that really fast and really scalable instead of hitting a centralized docker hub API you can have each node within the cluster send the data needed to spin up a new image I think it's an interesting so it reminds me of that example I gave before of like running this to remove NPM install times exactly but there's an interesting other aspect to this which is it I'm surprised that Netflix goes to darker hub at all because if you look I saw talked ones by the build system manager at Facebook and they have like 2,000 3,000 build machines something

like this and they all run in parallel right there or they have one mono repo and they're compiling and building a billion things and testing a billion test cases and everything it's incredibly hard and they use cluster FS to district have a distributed file system across all these machines so there's like one deployment of like the image of things that should be done the job sort of that gets distributed across these thousands of machines in multiple different regions etc and they've had to in yeah they've had to like invent this whole system because like at their scale they just it wouldn't be possible for

them to like have two thousand machines reach out to docker hub and try to download it just wouldn't work right so with IP FS as the middleman instead of like re-engineering your whole system you can sort of go with your your traditional system the thing that you would have at a small scale the thing that you got used to when you built your product and then you could kind of use the same workflow in the same pattern as you scale you just introduced something like IP FS in the middle and now you don't really have to re-engineer your whole workflow you can just and to do the same thing but it's still faster yeah so so Netflix uses titus which is their container management platform and they they built Titus and

and use that to kind of power all of their their their builds as well and that's also in the benchmarks as well and octopus is also faster than kind of their purpose built built Titus and I'm not certain how it works under the hood but the the challenge there around getting they do have like a docker image container distribution challenge yeah and it obviously like anything is going to be faster than reaching out over the Internet because if you're in a in a server farm you have like 40 gig links between machines that you can easily saturate probably like with with good nvme storage and so it's like yeah it's a whole different ballgame than trying

to reach out over the Internet absolutely so that's an amazing use case and congratulations on kind of having that that partnership happened I don't know if it's a partnership or a customer but like it's cool that that happened what I think moving on what else is in the release that might be interesting maybe in the in a realm of UX or tooling or something like that yeah so one of the one of the things in this release is support for dot eath links and so something that's been growing a ton in the ecosystem we've been seeing like a lot of attraction and adoption for is kind of these decentralized domain names so kind of ens and unstoppable domains and a couple other examples where and

I'm instead of relying on DNS groups are are trying to use kind of decentralized alternatives and so we've added support for four ENS and actually did a collaboration back with in I think it was like the June July timeframe where we work to spin up a set of bridging infrastructures which is what resulted in the whole you know dot e dot link URL which enables you to load a dot e link without any sort of in a special extension or a special web browser or anything along those lines and I think those sort of UX at chapters or ways that everyone can get access to stuff that's happening in the web three world without having to

intentionally opt-in it really helps increase the set of folks who get excited about things and so this this also comes at a time when it's just gotten a lot easier to put your website on the D Web and so we've seen this this group called fleek come into the space and they've built effectively a net low-five for ipfs and do you have sites and that just makes it really easy for people to kind of take that first leap of like okay I have my personal website like in a github repo somewhere can i deploy that to ipfs and just really easily get up and running and so I think the the sorts of things we're seeing now in the ecosystem are just how important those tools are how critical it is for

folks who are taking their first steps into this space and and trying it out to get up get up and running and build confidence and for everyone who's consuming those things you don't want a site that only works in like one small context you want something that's more broad and so just trying to extend the accessibility of things happening in space and stuff you know the reason we built the ipfs gateway was so that you don't have to go full into i'm only going to browse web three or I'm only gonna browse IP of us it allows you to get rid of the chicken and egg problem of like which you know ipfs has to be like the only thing being used before it becomes the default now it's just really easy for everyone to kind of from HTTP

takács get access to IP by sites so like many people I think wouldn't even know they're using IP FS under the hood but a site that they're browsing or kind of an application they love or anything like that can you use IP FS through the Gateway and you'll just never know as an end user that that benefits there so going back to your kind of your DNS work I'm now curious like I don't actually understand how ipfs and a DNS system works together at all like how does that work like what are they like those are those are like URL names their names and who the naming thing what like why is there relationship there yeah I definitely I'm not the right person to explain about

how all of en s works but I can talk to you about the the specific project we did together so ENS if you're iam name service allows you to kind of register you know Molly eath or whatever it is yes decentralized we have identifiers I think they commit them to Tyrion blockchain and the the integration we did was for the dot link TLD so you could do you think and that would that allows you they run a domain name server so a DNS name server that allows you to look up any dot eath website when you append dot link dot LAN and that kind of does that bridging process for you it

makes it pretty seamless for this to go back and forth it also has an integration with ipfs gateway so that when you configure your dot eath address you can be like great and the content behind this don't eat the dress is you know this ipfs hash which is my distributed website and so it fetches that and loads it from the gateway and that makes it very seamless to like load the page and like boom you're on someone's personal static site I see I see like the this whole gateway the whole bridging discussion is super interesting to me because if we take the the link example your central like you have a single point of failure in whoever owns link so you resent relized everything and it's the same thing with

gateways and it's the same thing with something like in fura and madam asked in the etherium world and it's unfortunate to see that you know we only have a couple hundred a couple thousand people who actually used the decentralized platform for real and everyone else is going to the centralized service provider so it's effectively still a centralized system but at the same time i know that we're not actually going to succeed in building a web 3 unless we build a bridge to web 2 world to let people cross over so it's this really tricky kind of half evil trade-off that we're centralizing everything but we kind of have to to

bring people over I'd call it like it's an intermediate federated step on the upgrade path right so like lots of people run gateways which is awesome and means that like you know not any like CloudFlare runs an IP FS gateway there's like a ton of others in Fuhrer rooms one pinata rooms one there's there's a number of others and so you know again you do and if this frequently comes in very useful we're like oh man you know some there's been a bad deploy for like five minutes we you know suddenly X thing is down in the middle of a demo and you're like great awesome I just changed it to the cloud Flik gateway and everything works fine and so you do have that redundancy there as well but I'd say having an upgrade path is is really important like you you can't you know

build for the the future and not create ways for people to get there with you and so kind of we see this as as part of of that journey realistically like if you're building your personal website or you're building kind of a front like user facing application where you're spending all of your time on the UX and thinking about how to do it really nicely thinking about how to like it you know push embed I give us into that site or you know great now it has to be a desktop application in order to be embedding a node that just doesn't it doesn't make sense that that constrains the problem and constrains people's creativity in a way that just doesn't work the right solution the the real direction that upgrade path is heading is having ipfs embedded in your browser

having it embedded in the tools that you use having embed in your OS and that's like that's where we aim so that the Gateway wouldn't even be used if you already have a local node running and so that's actually we're making more progress towards that vision than I expected so I may be more on the optimistic side that like we're gonna be able to get rid of these centralized stopgaps sooner than then we kind of thought we would have to opera just released UNF default support for IP FS and Android kind of the continued browser upgrade path like next up is you know embedded go ipfs node on desktop and so those are like the things that are coming a lot sooner than we thought they would like that we thought you know

pretty much half the web had to be on ipfs before you'd really be able to convince web browsers that you know now is the time time to add in default IP FS support and so that's actually I'm pretty optimistic about the upgrade path there we also we're doing a chunk of work to add D web protocols to chromium which is kind of extending the work that Firefox was doing like a couple of years ago adding like ipfs and dat and D web and a number of other protocols Firefox and kind of working with a galleon folks on on the chromium side to like make that available which then browsers can very easily toggle on and make accessible and so like there's I think there's a chunk of stuff happening there as part of the upgrade path that we're gonna get there

sooner than we think cool yeah that brings us to a really nice point in the interview by the way cuz like I feel like we can go 1.0 now if we want to definitely did thrashing us into the road to idea so this is this is ipfs version 0.5 so what is version 1 and like when is version 1 I have been joking a bit that ipfs ODOT 5 means we're halfway there so - hold on everybody five years but no I think the the funny thing there is actually you know the first half of you know dot 5 is

been building up a ton of features and by the way we're you know about five OH dot six is scheduled for like six weeks from now so we're gonna be updating our versions much more frequently but when you you know you think about the the last five years since the alpha and if it's been it's been building all of this technology and tooling and if up from scratch and I think the next chunk of work less than half but but the next piece that's needed before we can really put a 1 dot o-- label on here and feel good about it is is solidifying condensing in on kind of like a kernel of idea fast like what makes it go we've seen a lot of groups kind of actually be experimenting with different subcomponents of the go ipfs implementation where great like these

are all part of the IP bus protocol but they're they're different kind of condensations of what's really necessary in order to have like a Minimum Viable i PFS node operating on the network and to kind of really call this implementation one dot oh we want to get down to something where it's it's small it's stable and it has future-proof interfaces and so kind of the the next chunk of work there is like yeah like a little bit of an interface refactor carving out the the core kernel of ipfs and pushing that forward as like great like this is this is a solid core that then you can have lots of plugins or experiments or other things that like touch into this but this central part of

it is very stable and so that's kind of the the kind of next next piece I think and actually relates pretty decently to the sort of work that would need to happen to have ipfs kind of if you imagine great I want a go ipfs node embedded in my browser you're gonna have to be thinking about like modulation minification or you know condensing things down making sure it kind of uses like very reasonable low amounts of CPU and bandwidth by default you know all of those useful components and and from a timing perspective that's a little bit more open there I'd probably say sometime 2021 is kind of what we're aiming for so not another five years of

cool is there I mean do you work at all with rust we know that there's a live p2p rust improve implementation but like that parodies worked on but is there is there anything else with rust in ipfs there is great question on it yeah there's actually a new rust ipfs that the folks at equilibrium labs who also work on orbit DB have started up a couple months ago and it's awesome it's making really amazing progress and the rust community in general like you know the folks at parity Pier jumping in and helping work on this and there's some folks other folks in the ipfs community who are using IP FS on with IOT devices that are very excited for kind of a rust implementation which they can kind of I

think they have Android Android devices deployed in a mostly offline warehouse setting factory setting and so great as soon as as soon as like the core is there they're gonna jump on it and be be using rust PFS and so it's amazing just to see these implementations spring up from the community I think the p2p at this point has seven different language implementations across a lot of the different groups who are working in the 8th to eco system and anyhow getting to build on top of the shoulders of all of those amazing people who have have got Limpy to be there again IP fest as a trench coat around IPL deal it p2p and UNIX FS so half of its there if you've already got live p2p in your language

and we love seeing what groups come in and just start that up it's really amazing and and I think like makes the community stronger I'm trying to picture what would it actually mean to have a like would it be a rust client a rust ipfs client like how does that like how do you have the two implementations of this particular it's it's a protocol so it's twice implemented but do they they must speak to each other yeah so we already have a ASI PFS and go ipfs so luckily that means all of the inter up testing already exists you can lean on that to do kind of conformance testing for a new implementation which is what the the rust team has been doing and so we do have two full implementations from the ground up the reason that we ended up building the one in JavaScript was so

that we could run it in the browser and that was the the use case that was designed for us you actually can ipfs companion does allow you to toggle on an embedded JSI PFS node so you can do that in brave today you can go and kind of one-click enable a companion and then have an embedded JavaScript node running in your browser so that's super cool but yeah the big thing you needed kind of to implement all of the the ipfs commands and then building that on top of ruslan p2p which already existed and there's actually been a ton of work that happened already on rust IP LD as well by Volker on the IP LD team so there were there were a lot of pieces and just bringing them all together and packaging up nice I guess good luck with the next steps and the next releases it sounds

like you still have a lot of work ahead of you but you know Congrats on getting this far and on this release Thanks it's been it's been an awesome ride and we're so only 50% of our way there towards our content routing goals from a time perspective I think we're we'll see where the network gets as soon as folks more folks have upgraded because as more people upgrade to 0.5 the more pronounced the performance improvements will be so we're still we're still waiting to get some final final numbers on what the metrics are gonna look like but we have you know another three months focusing specifically on content routing and making things better and have some really exciting stuff planned for the 0.6 and deer at 0.7 releases so it's gonna be an exciting couple of months

cool thank you very much for being on the show it was great catching up on all things ipfs and digging into some of these improvements thank you so much traveling and to our listeners thanks for listening thanks for listening [Music]