 from Montreal, Canada. I'm the author of Embark as well as some other projects, more recently Transaction Relay. You might know me and read it as Iliumcraft. So today I'm going to talk about Embark too. And so Embark was the first framework for Ethereum DApps. And to give some background on some of the features. So it's compatible with any build pipeline. You can use it with Grunt or Meteor or whatever pipeline you're used to. Embark too will come with its own pipeline for convenience purposes for development, but you will still be able to use it with any pipeline. You can test your contracts using JavaScript. It also keeps track of the contracts that have already been deployed. And it's smart about it. So you can even refactor a contract. And so long as you don't change something that affects the external of the contract, you want to deploy again. So you can refactor, say, an internal variable. You can change the name. It will not redeploy because you haven't really changed anything. But if you change, say, a public variable, then it will redeploy because there's a code change. You can also manage different changes with it. You can deploy to a development chain. You can go to the production chain. And you can also use both Solidity and Serpents. You can use either of them, or you can even use both of them at the same time. So another thing that Embark is pretty good at is dealing with multiple contracts that are dependent on each other. So to give some example of this, so let's say that you have three contracts and they each depend on each other. So in this case, you need a token to be deployed first and then deploy the DAO. And once that's deployed, you need to deploy the liquid democracy. So in that case, you can specify in a configuration file that on the DAO you say, okay, dollar sign token. And that will tell Embark that, okay, this contract is dependent on the token. And I need first to deploy the token and then pass the address to the DAO. And you can have a galaxy of, or a NAT, if you want to call it, of contracts each depend on each other. And Embark will determine what is the right order to deploy the contracts. You can also have contract instances. So this is a case that you have a sort of factory kind of contract that has all the main functionality. But then you have an argument that specifies a particular change. So in this example, let's say you have a packed token contract. But now you want to deploy two contracts, which is a USD token and a Euro token. So in that case, you can specify instance of packed token. So he knows what is the parent contract. And then you see here in the arguments, you have request oracle USD.json. So imagine you're calling oracle like oracleize. And so the two differences in the argument is what will make the contracts be different. And also if you are using, you can also interact with the existing contracts. So let's say you're interacting with the DGS contract. Then you can specify the address. And Embark will just use that address. And it's also a support for deployment commands that there are executors once the contract is deployed. So in this case, I have an account manager. I want to manage my gold tokens. And on deployed, then I transfer for myself a thousand tokens to the recently deployed contract. Now Embark, so as a new set of goals, the goal in Embark one was to provide good deployment tools for this kind of complex contracts. Now Embark two will focus a bit more on the client side and focus more in integrations with storage layers such as swarm and communication layer such as whisper. And as well as providing easier ways to distribute applications. So Embark two is actually done from scratch. By default it comes with this dashboard. You can actually override this if you don't want to, if you want the old lock. I just found that the lock could be very confusing if you're dealing with a lot of contracts because it was hard to know exactly what was the status of different contracts. So I did this dashboard. So it tells, for example, there's this section that says, okay, the particular contracts you can see. Have they been deployed? Where are they? Was there an error? What is there? Or is still deploying? There's another section that you have the current chain that you're using. In this case, the development chain. What Embark is doing right now and available services. So let's say if your app was using IPFS and IPFS was unavailable, it would show up right here. And it finally also comes with a console. So you can use that console to interact with existing contracts or to tell Embark to do something like redeploy another contract or add another account, et cetera. Embark two also introduces a client-side library which is called Embark.js. So that library is meant to aid developers interacting with contracts. It makes things a bit more simpler and also provides APIs to abstract interaction with those layers such as storage and communication. So you can easily switch the technology if you need to because different technologies generally have different trade-offs. And your app might have different needs depending on what you want to do. So the library introduces promises which is long overdue. It also introduces name parameters. So you can still pass a list of arguments if you want to, but you can also specify the name of the argument. Another thing it does also is it actually automatically calculates the gas cost and puts that in the call because it sometimes happens if you're working in a method and it changes. So it becomes very complex and it just stops working because it didn't have enough gas. So Embark tries to take care of this. So it doesn't happen. It also tends to do some automatic type conversion. So if you have a big int, it will just do a two-number. If you have, say, an x that was supposed to be a string, it will also convert it to a string. This is also configurable because you might have different use cases, of course. And it also does the same thing with struct. Usually if you call a struct, it will return you a list of the parameters. And if you change the order, it will also affect that order. So now it just converts automatically to an hash. So you can just convert it by, say, you can refer to it as .author instead of position zero to get the outer. And it also supports client-side deployment. So you can develop a contract on Embark just like you do now. But you can make it available on the client side. So you can dynamically deploy contracts. There are certain types of applications that require that sort of functionality or very dynamic dApps. Example of this, if you wanted to do a fun dApp, create your own token, you would use this sort of functionality. So you would have a form, the user would put the name of the token, some parameters like the supply. And then that's the command that pretty much would run on the client side. Now for the communication layer. So Embark tries now to app, tries to provide an abstraction on that layer. And you can see here an example that, okay, put Embark .js messages, send message. You send that on a certain channel, with certain data, and then you listen on that topic. So that's useful to make dApps communicate with each other. If you're familiar with Whisper, you can see this is actually pretty similar to the Whisper API. And so the reason that you would use this is because this way you can focus on behavior and not on the implementation details. Especially because if you want to try out with different technologies, the implementation would be different. And this way you just worry about the behavior, you don't need to worry about the actual details underneath. So if you change your technology, you don't need to change your calls all over again. So it has a provider functionality and you can just choose the provider that you want. So Embark 2 will support these three providers, which is Whisper, a contract for the messages kind of replicates this kind of channel functionality. And also it will support Telash. Now, regarding for storage, it does a similar type of abstraction. So you can just say, okay, I want to save text and then I get a particular identifier. It's usually an hash in case of IPFS, for example. And then when you pass a dash, you will get back the data that you requested. And it also abstracts the functionality to upload files. So for example, in this example, if you have this HTML input, you can just pass it to DOM element and it will just take care of taking the file, doing what it needs and it will upload the file. It's pretty useful because different technologies actually have slightly different ways that actually deal with the files and upload them. So if you just use this, you don't need to worry about all those details. And then again, you can just do get URL hash and you get the URL that will point to the content of that file. So this is pretty useful for, you know, if you want to upload cat pictures or profile pics or so on. And just like before, you can also choose a provider. You can choose a configuration. Default for now will be IPFS. Most of course, that's what I was actually working on. But the default will there be a swarm. And so there's actually five providers supported. The first three are swarm, IPFS and storage contract. And again, there's different trade-offs to this. You might actually want to store something on the blockchain, which in this case will use a pre-deployed contract to do that. It's very expensive, but dark use cases that might actually be worth it. There will also be support for MadeSafe and Storgy. So regarding now, that distribution. So embark, right now there's two ways you can distribute your DAP would embark. One is that you do embark build and it will create a directory that has all your DAP all the needed files and it can just copy paste it and put it on your web server, for instance. Or you can also do embark deploy IPFS. And this command where it does it, it deploys your contracts if they are not already deployed, builds your app and uploads your DAP to IPFS. And then it shows you, okay, it will be available in this URL or this URL. In that case, it's a gateway. So that's why we support it. So embark one and embark two will support Swarmer PFS, MadeSafe and Storgy as the centralized storage for distribution. So finally, the other way that embark will also support that distribution will be as a desktop app. So it will have a command that will automatically create a full desktop app with the DAP for Windows Linux and Mac. It will also include the binaries that are necessary depending on the configuration that you choose. So in this case, if you distribute the app this way and your app uses IPFS, you don't need to worry if your customer or user has IPFS because if it doesn't, then the app will use the binary that comes included with it. All right, then. And that's it. More information, you can find it in GitHub. If you are passionate about DAP development, please join us at our GitHub channel. I thank you very much for your time. Thank you, Yuri.