 My name's Jared. I've been an active community member in Ethereum since like 2014. My background is actually in software distribution. Here I'm today to talk to you about integrating Ethereum into our daily lives using status of Ethereum Lite client developed for Android and iOS. But before I do, I kind of want to talk about my personal motivations and why I believe in Ethereum. See, in recent history, you can see many cases of economic collapse, institutional failures, and large populations of people who have no access to dependable legal technologies. And of course, these are complex problems. But I believe they stem from our inability for us to adapt socially fast enough. But what if we could create digital spaces in where we can experiment with new ideas, new economic models, new policies, and new ways of socially organizing, social systems as operational closures in which we have unprecedented access to the entire economy's history, down to the very transaction level and the social contracts that bind them? What if we can then use this data to discover something new and then deploy it globally within 30 seconds or less for anyone to use voluntarily? That's the kind of world that I want to live in. But none of that's really possible until we start getting Ethereum into the hands of people. Show of hands, who has a smartphone with them right now? There's more than that. Now, keep your hand up if you don't have your laptop with you right now. So smartphones are now the new personal computer. In 2014, they'd overtaken desktops in users. And now, we're seeing that more time is being spent on them than on desktops. Armed with this information, we decided to bring Ethereum to Android and iOS last year with a higher end goal of recreating the missed DAP browser experience on mobile devices. But as we were developing, I started looking at my own behaviors and how I was using my own smartphone. And I realized I wasn't really browsing the web except for when I was at restaurants or I was at home sitting down with Wi-Fi. And to be honest, the web is a little tedious. So they got me wondering, how are other people using their smartphones? It turns out that we are social creatures and we love instant messaging and social networks. In fact, compared to browsers, instant messengers have three times the amount of monthly active users and a third of all time spent on smartphones is actually inside an instant messenger. It seems to me if we want to create the biggest surface area possible for accessibility, this is a really good candidate. But then I started to wonder, what would Ethereum look like as an instant messenger? How can we keep its generality? How can we maintain decentralization? And what would a DAP ecosystem look like in the context of chat? How we humanize the protocol, turning addresses into faces? Under the hood, status actually runs a full implementation of Go Ethereum with the LiteClient and Whisper protocols enabled. On top of Whisper, we build our instant messenger and we actually do our own key management and transaction management. To DAPs, it all looks pretty much the same. They still have access to Web 3 and a local JS on RPC server. And we also introduce a new kind of extensibility to DAPs, which is more integrated with chat and can render with a subset of React Native. And I'll get into those in a moment. So when you first run status, you meet your first autonomous entity, Console. Console is there really to help you with onboarding, to educate you on how to use the basic features of status. It is also there to set up your first account. So here you can see our request message and it's asking us to tap on it. So let's do that. Here the request is asking us to set up a password, so let's type it in and to confirm. Now our message is sent and status has generated a master key based on and given us our passphrase. We also have the passphrase in multiple languages, including Mandarin. With this master key, we derive two child keys, a main account and a sub-account route. With the main account, we actually do something a little interesting and something you're not really supposed to do with Wisper. We actually inject the key pair directly into Wisper. This gives us an interesting property and not only you can transact with that public key, but you can also chat with it. This becomes your handle in status. Of course, there is a trade-off with address hash security, so we'll probably end up doing some automated management with any funds that are in that into a sub-account. In status, dApps are first-class citizens. That means they look and feel just like your friends. At the top here, we have our default DAP wallet. Let's tap on it and have a look. Wallet is an HTML and JavaScript DAP just like what you'd find in Mist or MetaMask. And pretty much all of those would work the same within status. This is actually rendered with a special built-in command that turns the text input field into something like an address bar and it renders a web view in the suggestions area. I'll talk about that in a minute. Underneath the suggestions area, we have a chat history. And this can be used for a per-dap transaction log and can even be used as a support channel if the DAP developer wants to talk to you. Chat dApps integrate with status a little more closely using a chat API. They can create new commands and new message types. Here we have an example with example dApp. And here they've sent us a request message just like console did. And we'll get to that in a moment. But in the bottom left next to type, there is a command list icon. You'll notice it has a little blue dot on it indicating that there is a pending request somewhere within the chat history. So when you want commands, you can either start typing directly here with an exclamation mark or you can type on the command list icon. Once here, the suggestions area is populated with all our commands and requests that are available within the context. Here we have one pending request and two commands. Now we can either start typing in the command that we want and filtering down the search or we can tap directly on it. So now we've typed in send and we're on our first parameter. A command is instantiated using status.command. It has passed an object with multiple properties. The most noteworthy are the parameters and three handlers, preview, handler, and validator. Now we are on our first parameter, too. And you can see that it is the type contact and the default value is the first participant within the chat context. We can either type in the name or we can just press tap on the example dApp. Every time we interact with the parameter, the validator function is called. And it can either inform status to move on to the next parameter or it can return a subset of React native to render some custom user interface within the suggestions area. So we'll do that. Now we're on the second parameter from. And this is using context self as the default value, which is us. So we'll just do that. And here is the third one amount. The code is emitted because I couldn't fit it on screen. But notice how the type is number. So it changes the keyboard. And in this case, the validator has returned some custom user interface, which is a slider in this case. Now we've filled out all our parameters. We can hit Send. Once this has happened, the message actually goes into a staging area. The preview handler is called. And the preview handler defines on what the chat message is going to look like. Now when we press Send, after the user has reviewed it, we're going to call the commands handler function. And this is where the meat of the command actually happens. In our case, we're going to end up calling web3 send transaction. Let's see what happens. Uh-oh, state change. Any send transaction request is intercepted by status and is put into a transaction queue for the user to review. It is represented visually by a list of horizontal scrolling cards. The user can either confirm or deny the transactions and remember certain types. Now I want to talk about requests and responses. They allow us to daisy chain commands and even pre-fill parameters to friends to fill out commands as well. They allow us to have more rich interactions and more meaningful conversations. You can imagine in the future, we're going to have multiple dApps being used in modular fashion, and they can be daisy chained together. In this case, example dApp would have ran a command where is, which would have made a status request for our response. And the target is the first parameter. So we tapped on that message that was pending, the request message. And notice how in the suggestions area, the header has changed, indicating what type of request it is, who it was by, and when. It's given us one parameter, which is our address. And now it's in the staging error like before. Responses have the same object structure as commands. They are just instantiated with status.response. So let's send that. In status, dApps can be added into group chats. This causes a mild dilemma in that with dApps, the codes are executed on each participant's device. That means we need to enable permissions for each command for everyone to use it within the chat context. This is as simple as going to the dApps profile and tapping on the commands. Another core feature of status is called discover, and allows you to advertise your goods and services, find dApps, and other participants by hashtags. So let's make ourselves discoverable. Change my name, and I'll add in status. When my status has hashtags in it, it is published to a public topic, and all my friends who are monitoring me, they can see this. On the discover screen at the top, we have a series of cards which demonstrate the most popular tags in the information you have available. Below it, we have a live stream of recent statuses coming in. This information is disseminated using a package, which is created from a list of statuses from your friends and also an aggregate of packages that you've received from your other friends. It's wedded by a number of factors, whether online, how recent the status is, if you've seen it amongst multiple peers, and if you've actually opened a chat history with it. There's a couple of other extensions to the chat API, such as a QR generator and scanning and contact menu creation, which I won't go into. We're also multi-account ready, so for shared devices and other dapped developers with multiple accounts, or just to log out of the app. Everything I've described today, we are feature complete. It's a bit rough around the edges, but it's all there. We are now moving into a testing phase, and we should hopefully have a binary by the end of the year. We are open source as of today. We're under MPL2, and that's our technology stack. So if you're a ClosureScript developer, I would love to chat with you. There's a developer guide that just guides you through a whole process. It's pretty painless. Also, stay tuned. We're working on a GitHub issue bounty bots where you can assign bounties to GitHub issues, and then they can be paid out to contributors on successful pull requests. The current implementation is a little naive, so yeah, probably give us a month or two on that one. And thank you so much. I hope everyone's using status by Defcon 3.