 Good morning everyone, Everton Fraga. I'm here to talk about MIST project. Alex van der Sende couldn't be here. He's about to have a baby, so maybe next time. Well, we're here to talk about MIST project. First of all, let me go back here. Okay, why MIST? What's the vision of the project? It is to host the Web3, Web3 projects, the land of the decentralized applications, where you could access websites that live, actually no central server, using peer-to-peer technologies such as Swarm, and having the blockchain as the back-end. Let's browse through the past versions. At the first DevCon, there were no MIST. That's why people would execute transactions that execute smart contract methods, only in command-line tools. It was really developer-oriented and no graphic interface. So you had to be a command-line guru. Therefore, no dApps. By the time of DevCon 1, we had Ethereum Wallet, which was the foundation of the dApp space. It was the first one we built. It was more like an advanced tool for specialists. You had to click around and get to know all the applications. It posed as a dynamic interface for contracts. Through a auto-generated, based on the ABI of the contracts, you could have executing contracts with all the parameters. It was like a Boolean, and you end, and then you would execute methods. Well, it did its job, but for the general use, there were some features missing, of course, such as that would require you to have Ether, for instance. Then by the time of the DevCon 2, we had released the MIST beta, which was more like a Firefox or Netscape navigator as the beginning of the Internet, focused on the enthusiast user. It presented the full power of the web for smart contracts. So you would, from your JavaScript application, from your website, you would trigger transactions, and then MIST would handle it. Here you can see a confirmation window about the execution of a method in a contract. We have these parameters that could be parsed via an ABI directory built by Piper. So, yes, that led to many other things. So you could create your own Congress contract and then build an interface out of it. But, you know, as the blockchain started to grow in size, it was becoming less and less practical for the users to have the whole blockchain synced. So, yeah, this is one thing that we would talk later. Throughout this time, the ecosystem has grown like crazy. Throughout these three years, we have been downloaded many, many times as well. So, I'm here proud to share with you that Ethereum Wallet and MIST combined had been downloaded more than 2.6 million times. So, that shows a bit of the size of the trouble we have, actually, because we are the most user forefront of Ethereum projects. And then we have to deal with all those sort of problems that came as well. Well, in order to solve that and organize all the project, we did a MIST summit in Rio where we get to have the whole team and we talked about lots and lots of things. So, it was sort of a whole week thinking and working. So, here's some proof of workshops for you. We used all those different clothing, so it was really a whole week. Yeah, and that was our team at that time. So, yeah, we came up with really lots and lots of experiments. You know, there's only some interface-wise experiments. So, let's get to the deliberate features this year. First and foremost, our main, main concern is security because, well, we have a browser that handles private keys. So, it gets, you know, it's not so simple as would be a simple website that doesn't handle anything related to money, for instance. Well, let's put a ribbon on this because it's so important. So, we've made an extensive audit by Q53, which is a really, really cool German company. Those guys are really skilled and they managed to find 22 issues with varying severity levels. So, it has some critical ones, high, medium and low. All of those were fixed by us. As soon as they reached us, we were ready to fix. And we increased our test suite, so no regressions here. And also, we had some really important Ethereum boundary program submissions. And here, I'd like to thank Juno and Newho Kinn. Really, you know. Thank you. And we had also some other exciting features such as the swarm integration in beta version. So, a user now is allowed to click on file, upload to swarm, then choose a file, upload it to this swarm instance that's running locally in his machine. Then the file is in the swarm space. The swarm will compute the hash out of it and communicate with other swarm instances, copying the files over them. Well, that's actually the seed of the Web 3, right? You could upload a website, then access like this, pasting the same hash in your browser. But, well, here's one thing. Swarm comes with ENS integration, so you could have this. That's one of my favorite features. And speaking of ENS integration, we also did some of them in the wallet. So, well, of course, you're able to transfer Ether to a certain address, ethionfoundation.eth, for instance, or add a custom token, just putting the symbol of the token, then it will search on a previously made list and get all the details. Then, after these three years, as I told you, the sync was sort of a problem for the users. We got many, many people saying, my balance is 2.0. I'm syncing here for hours, and I can't still see my stuff. So, we have now integrated, missed with the like client, still in beta version, but we are aiming to reduce the syncing times by an order of magnitude and is still using the version 1 of the protocol. The version 2 is about to come, maybe right after the dive-con, so keep posted on Goetheum, team, and missed. We have also built in Remix IDE, so we've seen Hudson-Jameson, we'll see Yann's talk right after mine, actually. And now we have the possibility for a developer to write code, run on the main app or on the test nets, and that's quite powerful. The developer is also able to debug transactions to see exactly what steps that transaction made and what were the states of the variables. So, we also did a really easy way for the developer user, which is Solo Network. It will make use of the Goetheum DAV flag, so you can have your own private Goetheum blockchain. So, this is not actually a simulation, it's the real deal. You run an empty blockchain from scratch in your machine, and you can manage mining from the interface. So, that is a missed aiming for a larger adoption of developers. We also had, by the end of last year, Windows installers, so people got happier. And now some planning features. Account management is one of those really, really important ones. Which would leverage the power of standalone transaction signer, enabling remote node management, and easy to switch between nodes. Here's the deal. If we want to use Infuda, for instance, for any reason, we would sign those transactions from within the signer. All those account keys would be held at the same directory, and we could even switch between nodes. It could be Goetheum, PyEthereum, or any other. Having all those keys managed by mist couldn't be even harder at wallet. So, this account management would lead to having those multiple Ethereum clients. So, you could use your own favorite node, having native support to Ethereum clients. It's actually a JSON manifest, which we already did. So, it only has a gap for now. All those accounts would be managed by mist. So, if you switch nodes, you would still see all the same accounts. So, we're under, actually, a major effector being led by Mark, who's there, maybe. Yeah, Mark, show yourself. He's not here. Hi. Oh, here. Yes. Mark is our new addition. He's a Redux book author, a really skilled developer. So, he has fixed internal state issues for now, which is mainly the foundation for major features to come. We're also thinking about having a sync jumpstart, which is something really awesome, in order to fix that zero-balance issues. So, you would start connected to a remote node. So, you would see all your balances, all your stuff, like real-time. Then you'd have a background sync. So, that would progress, progress, progress. When it comes to the right point, you would switch over. So, you would switch to likeline or full node over choice. There is also this important news for the DAP developers that we're planning to isolate local storage between networks. So, you would have different scopes to work with. So, the DAP developer wouldn't be worried anymore about having mainnet storage and testnet storage. And, you know, also transaction specter, which is something, you know, it's timing for us to have. We would show pending and past, no more per-dap setup, because as taking the wallet as an example, it really handles all its transactions and past and history. So, that wouldn't be necessary anymore. All with ABI lookup. So, you would see once that methods are on the directory search, that would be so evident. And you would see perfectly the transaction details. And speaking of the Ethereum wallet, it's time for a change. So, back then, it was one of the most ideal ways for you to kickstart on your Solidity project. But now we have some powerful tools like Remix. And maybe we don't need some features that we had in the past. So, now we see the idea of starting as a Solidity development is having, well, in Remix itself. So, we're planning to deprecate some features in order to have more simplicity. And we're planning to have a new wallet contract. There are some other audited and solid work around. So, we're planning to, in the near future, to change that. Well, this is about developers as well. So, we plan to have very integration with Remix, improving private net integrations, kickstart some puppet magic. And, of course, we're totally open to suggestions. So, you can, guys, reach me out before lunch, or maybe something. Speaking of the ecosystem we're trying to build here, I think it makes a lot of sense if we could have some depth trust meter. Because there is a fundamental question about this. Should DApps have access to HTTP? If DApps could be run from Swarm, could be loaded from Swarm, does that make sense, even sense, to have access to HTTP? We all know the web now is full of trackers from our clients. And those trackers feed the multi-billion markets taking advantage out of our online habits. And once DApps are hosted in Swarm, users will be able to decide whether or not a certain DApp would have HTTP access. And although the blockchain has already proven itself secure, of course, social engineering and trickery are important problems to deal with. And we'd like to invest some time into anti-fishing mechanisms, and using some sort of reputation system or blacklist subscriptions that users will be able to easily manage. So yes, here at DevCon 3, I present to you this summary. We've got hardened security, smarter GAT updates, we're no longer having to release missed versions for each GAT update, ENS integrations, Swarm Beta, Deli Client, Remix integration. So there's a key takeaway, which is missed is a full browser that makes you run a full node. It can be also a light node, but the thing is, you should, for the good of the ecosystem, run your own node. Well, this is our current team, and we also have many endorsers of contributors, so I'd like to clap a little bit for them. Those guys helped us with translation, with many bug fixes, and lots of suggestions around. And there's one more thing. Remember that I told you about the workshop back in June? We're working together for that whole week, and discussed about many, many things. And Victor Maia kick-started a new track within the team, so I invite him to stage to talk about his new project. Victor. So hello, everyone. Now we are going to show you something new. So, are you ready? I think everyone here dreams about a centralized web. A word of abundance where there are no companies, where nobody owns anything, that are just public debt and those that are easily forkable, resilient, and free. Can you imagine that word? Well, of course you can. A film is that thing, but for back-end services. So what about the front-end? What about using the face? Well, it has been two years since our launch, that most debt are still just centralized companies with tokens. They are hosted on central computer. They use centralized APIs. So where is the decentralized web? Why it's not happening? Let's talk about mist. Whoops. This is our code. As you know, it's not in a great state right now. Mist is a little bit slow. It has some bugs. Of course you are working to prove it, and we believe you can make it much, much better now with Mark on your team. But even if mist itself was perfect, even if that thing was flawless, will that be enough? Well, what about those? Browses like mist depend on a huge web stack. There are millions of lines of code that we do not control. And you already had two major vulnerabilities because of those things. So the point is, how can we prove those things to be secure? Well, we can't. And that's a serious problem for a browser that deals with real money, don't you think? So, and even if that was not the case, if those things were perfect, what about those things above? Well, let's talk about JavaScript. Okay, sorry. I think I have some problem with this controller. So would you use that code on your app? No, really, think about it. Is it safe to use that thing on your app? Well, of course it is. It's just a pure function. It's as simple as it gets. There's nothing potential unsafe about it. So what about this one? Would you use that thing on your app? Well, of course you would not. I hope you would not. You don't know what Square.js does. It could do anything, for example. This is a valid implementation. It's correct. But there is something extra there. It also alters the Global Web 3 object. So, like, this is not cool. This is the kind of bullshit you can do in JavaScript. So, by the way, this is not only about private keys. Hacking the global scope of a app can cause it to, for example, show me the need for track user actions, mine cryptocurrencies on your computer. So here's a lesson. You should never import JS code. You did not read. It's not safe. But... Oh, my God. I think... Let me just try something. Okay, I'll just use the arrows. But we know that devs read all their imports. Like, this is not a real problem because devs are doing all that audit work by themselves, right? So, let me show you something. This is a list of Web 3.js dependencies. Each one of those lines is an independent package with a lot of files, perhaps hundreds of lines of code. This is the first, this is the second, the third. All those are Web 2.js dependencies. And my question is, have you devs around here read all of them? Any of them could be hiding something like this anywhere. So, the point I'm trying to make is, for that and many other reasons that I don't have the time to explain, the Web, as we know it, was not made and it's not ready for crypto. So, what, it needs not another web browser, but a brand new thing made from scratch for that centralized Web. We need an answer to the question. How would the web look like if it came after a film? And to answer that question, we started the Moon project. Thank you so much. So, this is not another web browser, but an actual decentralized app engine that is lightweight and performant. It uses a scripting language with safe modularity so people can share code without needing to audit everything. That language is kind of like JavaScript, but without the bad things. It's more enough to be formally proven secure. And if those words sound a little bit scary, that just means a computer, not a human, can verify that the whole thing does not have a single vulnerability. And that's kind of a big deal. So, in short, oh my God, sorry. So, in short, this is what it has and this is where we're building. By the way, I'd love to elaborate on how those things are possible, but sadly, I don't have the time for that right now. So, sorry, there to be for another day. And finally, some of you may be thinking, but I like the web. The web has so many things, are you just like throwing the whole web away? Of course not, I'm not that insane. Everything is web compatible. So, web apps also work inside a browser and MoonLang can be compiled to JavaScript. In fact, you could even use MoonLang as just a safe module system for JavaScript. So, for example, here I import MoonLang in normal JavaScript code. Then I use MoonLang to import some library from IPFS or Swarm. And then I use that library inside normal JavaScript. So, you don't actually need to use MoonLang to benefit from it. And it also works on other languages. So, you can think of it as kind of like a safe code in sharing tool, not an actual language. You don't need to use it. So, demo time. This is a video of the Moon browser. It's the web version of the Moon engine. This is a 100 kilobyte HTML file. So, yes, it's really small. You can use it kind of like my terrolet, but with dApps. So, let's open a dApp by pasting its IPFS hash. As you can see, this dApp is very simple. There is a title, there is an image, and there's the black number. It's connected to Ethereum. So, let's see how its codes look like. One of the cool things about Moon is that you can always recover readable code from its bytecode. So, it's not actually plain text as we do on the web. So, we have a readable code from the bytecode. Above that, we have imports with our just IPFS hash. That's good because with that, you can make sure that those imports will never change. There, we have the main component with some things like its name, its local state, and a title. There is a fetch function. It gets data from Ethereum. Since Moon's a pure language, we need to use something called monets to do that. But you don't need to worry about that because that's very hidden. And finally, we have the handle function. It's kind of like React. So, I guess some of you may be familiar with that already. So, let's change some things. Here, we replace Moon by DevCon on the body. We also do that on the title. And now, I want you to pay attention to the hash bar, to the title above that. As you can see, not only the title, but the hash itself has changed. That means that new depth is already published on IPFS. Or, in other words, we just hard forked that depth. That's kind of cool, don't you think? Of course, it's a very simple depth. So, let's open something more useful. This is a token wallet. There's some... It's written on this account. So, let's submit it to it. As you can see, the confirmation window is a little bit ugly, but the transaction was signed and sent. So, let's select the previous account and see the code. Okay. So, one of the cool things about Moon is that it has a component-based architecture. So, you can get inside any component that is inside any depth. So, for example, here, we access a subcomponent of the wallet depth. And we can also go all the way down to the most basic functions. See how everything is hash-addressed. So, one of the cool things about Moon True is that, for example, if an application used that same function, or an equivalent function, it will download the same thing. So, there's a lot of sharing and very good usage of IPFS resource. So, okay, let's go back to the wallet. As you can see, our reader has arrived, so that's kind of cool. And for the last thing, let's open again the token table. Now, there's a question. This is a component from the wallet's depth. How hard would it be to use that component inside the HelloDefCon depth that we just made? Well, let's see. So, we copy that hash, and we go back to the HelloDef conduct. We import it by using that hash. Oh, sorry. I actually go back, so because I want to show some things, and I press the arrow on the wrong timing. So, again, here I import the token table. I replace the shoot component by the token table that I just imported. I remove the moon image, so it's the same place as the moon image would be. And we click above there. It's forked. And as you can see, that component is now working inside the HelloDefCon depth. And doing that kind of thing is always safe. So we can always take a component from some other depth and put it in your depth. And because moon is pure and made to be secure, you can always do that without worrying about it. In short, a depth engine that can be formally proven secure. A scripting language where sharing code is always safe. A truly forkable app. That's the moon project. If you want to try it, we have a live demo at that URL. Thank you. By the way, just a smaller point I would like to make, that whole thing is actually decentralized. The code is downloaded from IPFS. So you can just try it, do something I don't like and there's not anything that me or anyone else in the world could do about it. Because moon depths are actually publicly forkable, decentralized, resilient and free. Exactly like smart contracts are. As I think that depth should be. That's it.