 This talk is aimed primarily at application developers, and I would like to give a quick overview of the architectural considerations behind developing decentralized applications for Ethereum on top of SMORE. So what's wrong with the Web 2 model? Well, yesterday we have already heard that the Web is kind of broken, so it has these problems that you have a centralized trust management based on certification authorities. You cannot really trust content delivery networks. And so there's this other problem that scaling is, so it's buying more power from data centers by the person who provides the application, whereas demand is just users pounding it. And they're all sorts of like elastic solutions, but none of the, so they're ugly. They're just a hairy solution to providing more computing power as you have more clients, even though there's this natural thing that every client who comes, they come with a computer that could just be used. So it would be really natural to scale computing power by using the actual computers that the users come with. And the problem, however, is that so trustless computing, it comes with overhead costs that are not going to go away. So for example, if you are trying to host a number of movies, it will be always cheaper to do that in a data center than to do it on a trustless network, so there's always going to be an overhead, and somebody will have to pay for it, and you need to keep that in mind, but we're working really hard to reduce that overhead to a acceptable level so that the other overheads that centralized solutions come with, like the profits of unrelated people, they will be comparable or maybe even lower. So how do we get from Web 2 to Web 3? First of all, you may want to dispose with the notion of clients and servers. So for now, Ethereum ecosystem, that ecosystem is still very reminiscent of the old ways, so we have the nodes, and we have the clients, and we have these things like MetaMask, and it looks like we're running a client server network, but really it's a peer-to-peer network. So as you could see from today's presentations, we're really moving in the direction that there's going to be some kind of Ethereum node everywhere. Most of them will be light and very light nodes, but still we're going to have a network where there are many, many nodes, and you typically don't connect to high-powered nodes for your needs, you have your own node. So the backends that we're going to have, they're all general purpose, they're distributed, and basically the ones that you need to rely on are the three listed on the slides, so you're going to have a content address storage, which will be some, so in this case it's Swarm, IPFS is hopefully, so hopefully we're going to make Swarm IPFS compliant, and the addressing mechanism and the access mechanism will be compatible or even the same, so what I'm going to tell here applies directly to IPFS as well as it applies to Swarm, hopefully it will be the same thing. There's the blockchain-based consensus, so wherever you need global consistency, you consult the blockchain and you will have a synchronous messaging, so that's the things that you can think of as a backend, but you will not have specific databases that you need to query and so on, which has this funny property that particular business logic, the business logic of your application will mostly run on the clients, which is either web applications written in JavaScript or native mobile applications. So you will have to actually consider that much of your business logic is going to be run on the client, it doesn't mean that the API will be such that you will have to do the index traversal yourself, but in reality it is the client that is going to traverse the index for you, so you will not send queries across the network, you will actually traverse the indices as you access them from the content address storage, and you only send the query to the API and it will be executed locally. So here's an example of how the web API works with Swarm. So the URLs begin with the root hash of a collection. A collection is basically a collection of objects. Objects are binary files with a MIME type, so for example it can be a PNG image. So it looks very much like a directory, but it really isn't. So for example the second example is a map tile, where that long code is the hierarchical tile code for map slides, so in a single directory you will have thousands or hundreds of thousands or even millions of files if you think about it as files, but you really shouldn't. So it's really a database. And whenever you access something like this map tile, you're actually doing the index traversal locally, which is of course fast because it's done efficiently, but it's still done locally. And the property of the API is that if you change anything in the collection, it also happens fast, but it changes the root hash. So any put or delete method will result in a different hash, and it will return to you the new hash. And of course, if you want to have some global state that is consistent across all the users, then you can register these root hashes on the blockchain. For example, in hierarchical name registry contracts. So in the last example, you see an image which is registered in an album, a photo album that is actually Joe's personal photo album. The user experience is going to be very familiar to web users. That's what we're aiming at. So interactive, responsive, intuitive and so on, however, identity management will also be done on the browser side so you don't have to implement your own identity management with each app. You get it ready. And you're going to have legal and financial interactions. So it's no longer a click-through contract. It's something that actually has consequences. So it comes with all those things that are also listed on the slide. So now I will show you a few examples. Some of them are already implemented and downloadable from our source repositories. Some of them are pure vaporware. But all of them have these basic properties. So the current root hash is registered on blockchain so that every user can check on the blockchain which is the current version of the app and that's where they proceed from. So we have done away with the problem of security inherent in HTTPS that you need to trust something else on the blockchain. Most static and dynamic data are stored in a content address storage. And global state changes are registered on the blockchain. So it's usually global state changes are simply changes in a hash. You don't store a lot of state data in the blockchain because that's expensive. However, you still need to get those changes to the blockchain eventually so that there's a global consistency. And I have already talked about the other things. So whenever you have some local data, local state, like what the user is working with, you keep it locally. You don't submit it anywhere. You can back it up if you want to. So the first example is a distributed photo album. This is already existing. It can be, you know, you can download it. You can look at the source. You can learn from it. You can take parts of it. It's completely open source. So both the data and the web app are hosted in a swarm and they are hosted in the same collection. That's very important. So you don't have a separate root hash for the data and the app. It is the app and the data together that have the same root hash. So you can register a photo album's particular state, which means the photos in it and the ordering in which they are presented. Long-term incentives of swarm will make sure that it's not garbage collected. That's actually not implemented yet. Short-term incentives will have the publishing costs down, which means that if your photo album for some reason becomes hugely popular and half the web wants to see it, it will not be a problem for you. And it will not be a problem for your users either because the performance is guaranteed, performance is improving together with popularity. The easy part is that there's no concurrent editing and no comments or ratings, so we have stifled a few difficult problems of that development in this particular example. However, it's still worth looking behind the scenes. So one thing that is happening here is that the blurred backgrounds and the thumbnails, they get generated on the client side during upload, which is fine for a photo album. But let's say you want to move on and you want to do something distributed like, so you want to do something like YouTube in a distributed fashion. In that case, you need to transcode huge video files or you want to transform projections for immersive panoramas and things like that, which are computationally expensive. So all that stuff, can you do that in a mobile phone? Well, you can, but you probably don't want to. So in that case, you need to do delegated computations in which case you submit the data and the specification and the reward. And you want, eventually, to have a result of that computation and the proof that it is correct. So there's going to be other talks in this session, which will delve into that, what I would really like to highlight, that there are two ways to go about it. Either you specify in an imperative fashion in a special blockchain, in a special virtual machine what computations you want performed, or you just make declarations about the result. You don't care how people actually compute that. You simply verify that it's correct. And then you need to arbitrate it on the blockchain. Please talk to me after the presentation. I don't have enough time to explain arbitration here, but I think it's really crucial and the really interesting part of it. The second example is something like Dropbox, distributed Dropbox. There's a huge demand for that kind of stuff. It has a web app and a locally synchronized folder. The first one is already in the works. It's, I mean, it's already usable. It's just not feature complete. Again, here you have concurrent changes, but they're not typical when you're syncing between two devices of yours or between a few users. And also there's going to be a separate talk about implementing something like GitHub in this distributed fashion. So the third example, which would be a distributed social network, and the fourth example, a map or an encyclopedia with no official truth. So these things, they are pure vaporware now, although I'm aware of some teams that are working on projects like this. So maybe we will see something like this in the not very distant future. So there are also ways of doing things like this in a distributed fashion. Moreover, doing it in a distributed fashion in a content address storage actually opens up possibilities which are plain impossible to do in the Web 2.0 way. So thank you for your time. And if you will have questions, I will be ready to answer them after the session. Thank you, Daniel.