 All right, thanks, everyone. It's great to be here again this year. Sorry for the change in the schedule. I'm pretty sick, and so I might cough during this presentation, so I apologize ahead of time if that happens. It's great to be here at DevCon 2. It's fantastic to see that our communities have remained very close together, that we continue to grow together, that every day there's new exciting projects using IPFS, or Ethereum, or both. This year, we have three presentations for you. Today, I will talk about IPFS and give some ecosystem news. David will present on LiveP2P and DevP2P. Samly will talk about distributed applications and orbit. And we also have two others in our team, Jeremy, who works in Go IPFS, and Jesse, who works on Filecoin. Find us during the breaks, and we can answer any questions you might have about how IPFS works, how you can use it, and how we can help you out. There's little time this year. So I can't give as long of an intro into IPFS as I normally do. And so these talks can give you the in-depth perspective into what IPFS is, how it works, and all that kind of stuff. I'll give a super short intro instead. And that is that the content, how we move content and how we address content in the internet today has a lot of problems. There are problems of inefficiency, bad security models, dependence on massive centralized systems, reliance on the backbone, censorship, and more. IPFS, the Interplanetary File System, is a new paradigm for moving around data and addressing content on the internet. It is a distributed, decentralized, peer-to-peer, versioned, cryptographic-secure, verifiable file system. It's a lot of work there. IPFS is making the web faster, safer, and more open. IPFS addresses all content by cryptographic hash, which decentralizes and shifts the power dynamics of the web. Content can be linked to and retrieved without appealing to specific intermediaries. You don't have to rely on huge centralized silos anymore. You can link content together. And whoever has the content can serve it to anybody else. This might be a laptop right next to you. It might be somebody else on the planet. You don't have to wait until one web server dies out. IPFS also empowers blockchains to record, timestamp, and address massive amounts of data off-chain. This preserves the security guarantees because it is just hash linking. It can also be used to build blockchains themselves, but that is a much longer story. Maybe someday I will give a talk on that. The technical intro is that IPFS is a protocol stack. It's a set of implementations and a project to build a Merkle graph-based web. Content is addressed and linked together using cryptographic hashing, which gives IPFS the same fantastic immutability and authentication properties that Ethereum, Bitcoin, Git, BitTorrent, and all these other systems have. Beyond that, IPFS is a data model that allows these data structures to be linked together, making all of them more powerful as they are addressed from one to another. Imagine being able to link from an Ethereum transaction directly into a Git commit. IPFS is a protocol stack. It has a data model, as I described, and the nodes connect using a peer-to-peer network stack that we call LIPP2P. This is a very modular library, and David will talk more about it later today. IPFS is also self-describing. It is a future-proof protocol. It is built on UNIX principles, and it's highly modular. All of its components from transports, connectivity protocols, content representation formats, file chunkers, file layouts, all of these things are pluggable, extensible, and replaceable. IPFS is an ambitious project. It has lots of capabilities and features, and many more are coming. But it is also pragmatic. We build in units of future completeness so that people can use it to solve big problems today. I have a number of ecosystem news for you today. The first is that IPFS has two implementations now, one in Go and one in JavaScript. Over the last year, since last DEFCON, we shipped the O4 series of Go IPFS. That brought tons of new features, bug fixes, and so on. It is steaming ahead with a large, ambitious roadmap, and though it's not at 1.0 yet, it is far more stable than you tried before, and lots of people are having a great time with it. In fact, yesterday we released O4-3, so we encourage all of you to update if you're using IPFS. And thank you to all of you who contributed. I know there's a lot of people that will be watching this that have contributed to this release. The important thing about JS IPFS is that before, with just the Go implementation, people had a hesitation of adopting a new protocol for the web before browsers had changed to adopt it. How could you build a website on a new protocol if people would have to install something or an extension or something like that? So we decided to build a full IPFS implementation in JavaScript and make it run entirely on the browser. This is a huge undertaking, and it is very powerful. It means that web application developers can start building on IPFS without having to rely on any browser change or any installation. And so you can have a full distributed, decentralized web application today with stock browsers. Another major bit of news is that dynamic content is finally here with IPFS. Previously, people had remarked that while IPFS is great for static content, they couldn't see how to build dynamic real-time web applications. The decentralized and distributed architecture just fogged things up. So we decided to take some time this year to implement the pieces needed on top of IPFS to build these kinds of applications. This means a low latency PubSub protocol and a set of libraries for storing and retrieving data that is designed to converge. This means CRDTs. So we set the challenge of taking these distributed data model. There we go. No, I was having trouble changing it. And we set a great challenge for this. We wanted to build a distributed peer-to-peer chat client capable of working in a local area network without having to connect to the backbone. And that's orbit. You'll hear about it later today. Another bit of news is that many of our sub-projects have graduated into their own full-fledged efforts. One of them is multi-formats. This is a self-describing set of protocols that are verifiable, avoid data lock-in, and so on. You may be familiar with multi-hash. This allows you to multiplex many different kinds of hash functions. Multi-atter, multi-key, there's a bunch of others. These are headed for standardization at the IETF, and lots of other groups are already depending on them. So we decided to create its own organization for that. Another of these projects is libP2P, a modular peer-to-peer library. Again, David will describe more. The last one is IPLD, a thin waste format for representing Merkle chain data structures. IPLD is the secret sauce of IPFS. It makes the Merkle forest possible. It makes it possible for you to link from one data structure to another. What's really interesting for the Ethereum community on this is that soon, not yet, but soon, we will have the ability to natively address Ethereum blocks in IPFS. That means you can take Ethereum hashes and address a block, look into transactions, and look into the entire state tree in IPFS native paths without having to run an Ethereum node or an Ethereum Lite client. This is great. This is great for Ethereum because it extends the reach to all other applications that run IPFS. You can hand web applications a reference and they can look it up within IPFS. It's also great for archiving because a lot of tools for archival are being constructed around the IPFS ecosystem. A last bit of news here is that the IPFS project has been doing a lot of work on package management. IPFS started its life as a data set package manager, so it is naturally very useful for this. The community has been putting package managers like apt, pacman, nix, npm, pipi, and so on on IPFS. There's really good proofs of concept, but none of them are quite usable yet for production. So more work remains to be done. We'll be working on that over the coming months. What has happened, though, is that we are able to build new package managers from the scratch directly on IPFS, and we have our own GX that we use for Go. So with GX, we can package manage Go packages with hashes, and so now you can know that the code is not gonna change underneath you. It's an important improvement. There are other package managers built on top of IPFS. Spore and DApple are two that come to mind. DApple is a package manager for Ethereum DApps. Cool, so I wanted to talk a little bit about some of the users that are using IPFS and Ethereum together. Take a sip of water. This is Uport, a decentralized identity service. It is built on top of IPFS and Ethereum. This is Akasha, a decentralized social network. It is built on Ethereum and IPFS. This is Digix, an asset exchange. It is built with Ethereum and IPFS. This is Infora, an infrastructure system for scaling Ethereum nodes and IPFS nodes. Again, Ethereum and IPFS. This is Ujjam Music, again using IPFS and Ethereum. This is Aries Industries, who is building a smart contracts platform, again using Ethereum and IPFS. This is Block Fright, a chain of provenance solution for storage containers that is using, you guessed it, Ethereum and IPFS. The gist of this is that, oh, and this is Balance 3, a smart contract-powered triple entry accounting system. I love that phrase. The gist of this is that all of these applications are leveraging our technologies combined. They're better together. We are creating a lot of value individually, but when you put these platforms together, magic happens, and all of these applications are testament to that. We see more happening every day, and we expect that more will come. So we invite the entire Ethereum community to collaborate more tightly in all these things, and let us know how we can help, how we can help support some of your use cases. If you're building on IPFS and Ethereum, we'd love to hear you out and see how we can help. The last thing, I wanna switch gears for a moment and address one of the longest-standing problems in the IPFS ecosystem, and that's news on Filecoin. So the main problem our Ethereum users have had is that IPFS does not, on its own, cost data to be backed up by the network. This is by design, as backing data up in the long term is an expensive operation that needs to be compensated or incentivized with some sort of value. As you may know, we separated that layer of behavior into its own protocol called Filecoin, a cryptocurrency file storage network. There are a lot of reasons for this. One of them is that if you use IPFS just as a browser and you had to store other people's data, that wouldn't be as good as if you can just use it natively, right? A lot of peer-to-peer systems failed because they tried to force the system to do both at the same time. So at the beginning, our intention was to build just enough of IPFS to build Filecoin. And so we raced to build IPFS, we shipped it out, and we were considering shifting our gears to Filecoin. But three things changed our minds. The first was that there was close to no market for distributed data storage around that time. This was like mid-2015. Ethereum and IPFS were both young projects. Decentralized apps were just beginning, and pretty much the cloud satisfied everyone's needs still. Second, we knew that sophisticated data storage needs would require blockchain smart contracts because many applications require a lot more looking into who is storing the data and why. The third thing that happened is that we had a sudden and intense adoption of IPFS much greater than we expected. This surprised us. Thousand of users came wanting new features and bug fixes. Hundreds of developers showed up, started helping us out in the code. They needed review, they needed direction, and so on. So we decided to double down on IPFS and push Filecoin to a later date. Now, IPFS has been developed. The EVM has been battle tested and proven. And now is the time for Filecoin. The markets of decentralized data storage is emerging. So unlike, you can think of Filecoin as Amazon S3 meets Ethereum powered by IPFS. And unlike other alternatives, Filecoin is a blockchain protocol designed to do for storage what Bitcoin did for hashing. This is a hash rate of Bitcoin. It's an absurd amount of power. This is like ExaHashes now, I believe it's a ridiculous amount of computational power. The world's top 500 supercomputers put together were left in the dust in like 2013 somewhere way before the knee of the curve. And then we have this explosion. Every time I look at this graph, I'm just astonished by the degree of power dedicated to this. Nowadays, I think it's using more power than many small nations. So imagine if you could create a network with that kind of incentive structure for data storage. You could summon this amount of disks to show up in the network. Exabytes of storage added to the network. You know, over what? Two years of massive growth and six years, I guess, of proving it out. That is what it's going to make distributed, decentralized storage platforms capable of competing with the cloud. Because at the end of the day, you don't want to store your data in someone's laptop, you want to store it in mines like this. And something resembling the data centers of today. You want to use laptops for fast efficient delivery, but ultimately you want serious operations. The competition between distributed storage networks is kind of interesting because the reality is that we should be competing with the cloud. The cloud is where everyone is storing their data. We should be working together to defeat that. So at its most basic, Filecoin looks like this. Miners rent their hard drives and earn Filecoin for it. They can then exchange that for dollars, Bitcoin, Ether, Yuan, whatever. Users, which could be people or applications or contracts, would then buy Filecoin and spend it to hire the network to store data. The first version of the Filecoin paper I published in 2014 describes the protocol with a core mining function, which uses a consensus-building proof, either a proof of work or potentially a proof of stake, and then a proof of retruability. It also talks about a secondary market. And that secondary market, not too much on the paper, is very important because you can use it to do low-latency delivery using payment channels or state channels, like the Lightning Network. So you can imagine this chain continuing to mine a lot of nodes have a lot of storage and they can do state channels. The cool thing, though, is that now we can add a proper contract engine on Filecoin. IPFS has had a lot of improvements, but the thing that is going to set these storage networks apart from the cloud is things like this. Being able to do, like, bonding and collateral as Victor from Swarm described, being able to do reputation thresholds, being able to do identity, selecting based on the identity of the people that are storing, being able to do geopolitical bounds when you are forced to store certain data within a certain nation. All of these things can be represented as contracts when you have a large network like this. And this is pretty important for making any of these platforms capable of working. So over the last couple of years, there's been an enormous amount of exploration in this. Swarm is doing awesome work on this direction. So is SIA. This is another decentralized distributed storage platform. And there's a bunch of others in this space as well. We've done some work as well and there's been two years since 2014 of great academic research into proofs of returability with new schemes coming out and a lot of research into how to do smart contracts in a much safer way. We feel a lot more comfortable trying to do data contracts today than we were two years ago. So the design space for Filecoin is an interesting one. We evaluated a lot of systems and we thought about how to do this construction. We could potentially build it on top of Bitcoin. We could potentially build it on top of Ethereum and so on. And consistently, across all the vectors we measured, Ethereum demonstrated greater technology and a much more effective development community. We have some requirements that Ethereum doesn't yet meet. For example, we need a really fast volume and speed of transactions, you know, a gig of transactions per second. That would be insane. We want to get there eventually. We also need disconnected operation. This means being able to operate in a distributed network where you're disconnected from the backbone. So if your city gets disconnected from the rest of the world, your applications shouldn't stop. Imagine if you go somewhere traveling and then you lose connectivity to the backbone and then it works. That's just untenable. So we are building Filecoin in the direction of being able to work in this direction. So these two things are not showstoppers, though, because the Ethereum community is also very interested in this. There's a lot of work being directed towards sharding and these efforts, and we think that we can solve these problems together. So I'm excited to announce that we've chosen the EVM as our contract engine. Beyond this, we had two options. Either we fork Ethereum and build our own network, and this means working together on a number of problems and code bases and generally sharing strategies, but basically building two different networks. And the benefit of that is we are not blocked on scalability and so on, and we can proceed in that direction. Or the alternative is we virtualize Filecoin on top of the Ethereum blockchain. This means working together directly on critical problems and code bases. It means not having to build a large proof of work network to secure the Filecoin network. It means enabling Filecoin to serve Ethereum contracts natively, directly in the Ethereum blockchain. Hopefully, Ethereum could adopt the sharding and disconnected operation functionality we need, or we'll have to eventually migrate off the network to be able to satisfy those constraints. But fortunately, that's not a decision we have to make for a year, at least, potentially more. An important deciding factor for us in this was that the Ethereum community has been through tremendous challenges this year. We've watched kind of from the sidelines of a different community, yes, lots of things happen. And I want to remark that unlike other communities, Ethereum has demonstrated a very effective improvement and problem-solving ethos. You are not afraid to come together and solve problems. In the history of computing, nobody has gotten everything right from the beginning. And so the teams that are effective, the groups that change the world, are those that are able to course correct and reinvent technology. They ultimately went out. So we are excited to announce that we are building Filecoin as a virtual chain directly on top of Ethereum. And it will be accessible natively to contracts in the Ethereum network. The third thing I'll announce is that we are planning a Filecoin sale at some point in the coming months. Stay tuned. That's it from me. See you at the other talks today. Thanks a lot. Thank you, Juan.