 This is the UX breakout room and it's all about like, you know, how do we do blockchain easier and better? I think I will go quickly through the slides because it's not that complicated. I guess most people will get the problem, definitely. So we have obviously... I will start with two statements. Statement one is, I think 2019 is the year of Web3 UX. I mean, that's kind of mostly the questions we had so far in the last few months. How can we make this Web3 easier and better? And a lot of actually solutions already tried out, but it doesn't really unify in a very common thing people use to make it better. The other thing is, I guess, that's my assumption, is that next year, actually we will see the first applications that will be used by the mainstream where blockchain might not be even in the forefront and will not be about blockchain. It will be about some cool app or some cool thing to do. And by the way, I'll use blockchain to some degree. The big problems we have with blockchain UX or the Web3 UX is maybe actually I should start shortly about my background. Everybody knows my background here? Okay, who does not? Okay. So quickly, so I actually been part of the theme foundation since 2015. I joined in January 2015, have built the Miss Browser. The New York people have not heard about that, but back in the day it was the first December app browser. We kind of coined that term the app. The Ethereum wallet was one application within the Miss Browser, and I have worked on Web3.js, kind of like the JavaScript library, I guess most of you use. That is the library, kind of like, you know, we define like the first way of how you interact with smart contracts and on-chain. And I guess Web3.js is one of the first tools that made like building on blockchain rather easy and more fun to do, I hope. So my kind of like bigger work besides like being in the Web3 team since a long time actually was the 1.0 build, which was recently developed, released. So I have kind of like, you know, came up with this API to make it the way how it is. And I hope it's intuitive. Say yes, it is intuitive. Or better than before. It's an improvement, let's say it's an improvement. So the big problem actually also, okay, there is also an ESC20, which I proposed in 2015. That's kind of like what the non-tech people know. And also something which I will be speaking today, which is ESC75. So big problems for on-chain is obviously that this is probably one of the biggest ones. You want to do a cool app which uses blockchain. And the first thing people encounter is gas. And especially even if you come from the blockchain or Bitcoin community, non-etherium, you're totally puzzled what that even means. Is gas an extra token? And now with the gas token, actually people think it's a token. So what is gas? And most of the people don't know why they now need something called Ether just to do something in a blockchain-based app. And the other big problem is everything is stored on keys today. So the way of how we interact with the blockchain is we generate a private key or we have a private key and some water and this one signs a transaction and we send it to the network. The problem with this is we are dealing here with the lowest level component of how you can interact with a blockchain and we store all our assets and our things on that lowest level tool or access point. By doing that, we run in a few problems. You have to back them up. You have to actually ask your user to create a very secure backup which in today's terms means writing down words on paper people don't have so we force them to make screenshots and store it in iCloud which is the worst form of safety just in case we have a bit more security. The problem is you make people go through hurdles and complications at a time where they don't even care or know if they ever want to use the app in the first place. So you end up with basically a lot of drops out in this point of time. So only the tough one who really wants to invest or do something in this app will go through this lengthy process. And you end up with many apps, many backup keys and you somehow have to manage them. Don't lose them. Guess what? Maybe in case we have some value in the future on that and it actually happened a lot of times. Think of crypto-kitties. Who had thought that this would be worth anything until it did. So years of 7 to 5 kind of initially was in 2017 or something. The idea, okay, how can we make basically an on-chain account or back then I called it on-chain identity until the whole identity community like backslashed on me. Oh my God, you kind of call it that identity. And basically to actually unify this whole thing of like how I manage better my account on-chain and how could I have an account which can receive actually information and this led to the years of 7 to 5 proposal which was in 2017, October actually and another thing called 734. It was rather complex, but I think what it did was for the first time showing of how can I make a smart phone based account with some sort of key management logic and some sort of claims that can attach to this account. And it kind of showed the full picture of how can this look like in smart network language. It spurred on the kind of like activated the whole discussion around identity, blockchain and so on. Even though there were predecessors like U-Port and others who did that before me, I kind of like proposed this out of the feeling of, you know, I had the urge to do it. Like I had also the urge to propose ESC20 in a more public place rather than this wiki page which we had before. And, you know, it kind of like was the right timing at the time and it stirred this discussion. So out of this came, you know, people say, oh great, there's an identity standard, we should all use it and the origin product power guys launched the alliance around it and then we had a telecom channel and a lot of people joined this alliance and kind of everybody like cuddled around this standard. But not really developed further or actually started to use it. So one thing is having a standard. The other thing is having an alliance for a standard but the actually important thing is having people use it, you know, and make sense of it. There are also problems, especially with the earlier version of 705 is that it's very complex and it is very specific also in how you do key management and how you do certain things. So that kind of led a little bit to, I would say, a stifled progress or speed of adopting it. So we had some discussions with people there and we came up with ESC 705. Actually Taylor came to me and said, hey, here I have some ideas and let's talk about it. And that kind of led to ESC 7 version 5 version 2. And the interesting thing about this is it completely made it simple. And I think, you know, if one thing is key to success for a standard, it is simplicity. So ESC 20 was kind of the reason why it was simple to use and ESC 20 and ESC 75 version 2, in my opinion, is also key of why it could be very successful because it's so simple. So in the fact of what does it does, you know, it's like, okay, this is a smart contract which has an owner and there's some key value store in there and there's a generic execute function. So it's actually not a lot of things. ESC 25 is actually important because that allows you to do a lot of things on the blockchain. So in its core essence, what is ESC 7 to 5 and not forget, there is more to standardize on top of that. So it's not all in one gold solution. But it is a very key piece because it is the core piece of an on-chain account. So basically, we store everything currently on keys. If we replace this by a smart counter-based account, we can add a few proper keys which we didn't have before. And one is obviously, I can use my account from different places which is exactly right now the problem. So we all end up having metamask, maybe having some ledger, maybe having some other five apps. And what happens, we all use different accounts in all of them, have different amounts of ether or assets in all of them and some we don't even know anymore that we have and we tend to basically not use our on-chain accounts often. You basically have one account per app, which can be useful but can be very hard to manage, especially when it comes around dealing with different types of games or wanting to access your account in different places. So the smart counter-based account basically allows you to manage it because it has its owner address. So owner means that there is one address that can control this account and this one address could obviously be a simple key. It could be a very simple private key which could be even the first one you generate in your application. So think of application starts, it generates a key under the hood. This key does not need to be safe because it is a throw away key. You just use initially and the moment you get more value to it you can make it more secure. So you could even think of taking this key and sending it via email as a backup process so that in case you lose the app or the phone in the next few days you can easily re-ascensate your previous account. I mean, if we think about it, we use email today for resetting our password all the time, right? That's our security measure we have. So email is zero if you have access to emails you have access to everybody's accounts. The email is the username and the way to reset the password. That's already a funny thing. So that's the security measure we have so why not sending a private key or some kind of generated link or so directly to the email. The moment you get actually value on your account or you use it more often for something then you can actually attach a multi-sig and have that multi-sig being the controller of the account. And that multi-sig could be ignore safe. It could be a complex permission contract that allows certain parties to do certain things through the 7-to-5 account and others not. So think of like you are a company and the 7-to-5 is your company's official address. If you have a permission contract where the intern can actually talk through the official address but only can talk to certain accounts or certain smart contracts and call only certain functions you can have your intern use the official account without any kind of security loss or it could be just a simple multi-sig. On top of this, this allows also social recovery schemes and whatever else because whatever we come up with better ways of managing keys we can attach to the same existing account or to multiple of those. The important thing also is we can have meta-transactions. We can use the gas station network or other relay services within those key manager accounts and suddenly completely hide the fact that there is a fee to be paid. The future of blockchain should be the way of how the Web2 works today meaning the application developers or the company who does it should build the... that should pay for the usage at least to some degree until there's a way to recoup the payment. I mean, today nobody is paying for servers of applications and still we just download and use them all the time. It should be the same with Web3. The relay transaction service is actually the key piece to make it easy but this allows a lot more things so this in the first instance creates a managing account so now I not only have one key but I have a key or an account that I can manage in all kind of ways and you know we can invent a lot of new things of how we manage those but I can also attach information to it and that's what this key value store is for so the key value store is buy32 and buys as value. This means we can come up with all kind of things that we allow to be attached to such an account and this can be completely random things links to reputation systems or whatever so you could simply attach an avatar to this account to make it somewhat cool and identifiable or a company's logo or whatever but you can also link to all kind of other off-chain more identifiable data that you don't want to reveal on chain but it somehow should be referenced and linked to this public identity or this public account you have here and whatever you come up with you know batches, reputation systems link tokens whatever I mean you can just on this address have a lot of NFT sitting or batches whatever but you can also link to an extra reputation system sitting in another smart contract that allows a lot of flexibility and because there's so many more things we don't know what is coming having a key value store really allows for all kind of new things we don't need to think about everything right now and having to find these five things on an on-chain account it's an open-ended system so that actually creates a manageable verifiable account so using this as the default and the beauty here is you can start out with a key in your application the moment somebody purchases something or doesn't actually somehow creates value or money spent you can on the fly just create an account for him where this key is the owner the beauty is that now this person could actually take this account and take it into another application so we all start to use the same default account standard you can take your account across all of these different applications and it's a lot more manageable and it's a lot more easy to interact with on-chain things so that can be rather cheap to deploy I mean Ether Transactions 21,000 gas, 32,000 for deploying a library that can be as cheap as it can get and it's basically it could be a long-lasting manageable account and because it's a smart contract a smart contract can talk to other smart contracts that's the big, big magic thing which I guess a lot of people outside of Ethereum have not fully understood why Ethereum is awesome and the EVM in fact is because of that fact that you can talk to other smart contracts that kind of makes your connection account the actor on chain this means for other systems outside it's the same like before if a key is talking to you or a smart contract you don't care in fact here you can even check the smart contract read some information you need maybe some verification or maybe some attached claims you somehow need and do something with them so message standard you don't necessarily need to be your person this could be one account you use you can have 50 if you want to I guess we end up with just a few but you can use them for different personas you don't necessarily need to upload your picture and then go to the government and put a proof on your on-chain account just to prove that this is your account and then show everybody what you do but one of the biggest pieces in our society is actually transparency and on Facebook and all of these platforms because we want to express ourselves so that expression needs a identity you can actually or an account you can actually take around which you curate take care that whatever is on there is what you really want to put out there and 75 can be there also for companies also for organizations technically speaking if the foundation should have an on-chain account and not the Ethereum multi-sig from 3 years ago being in the official address which we all look at so it's your on-chain account and it should be your gateway to the decentralized world and if you want to do identity then you'd rather look into off-chain solutions like verifiable claims double 3c does great work on that and there's a lot of projects like 3box and ident3 which are working on making these kind of real-world identities work which are not necessarily on the blockchain or only have like slight pieces on the blockchain so what we have done is this the EC725 alliance obviously there's the official or current implementation of the 725 version 2 as well there's always the issue where we discussed currently the main thing we are doing and there's more on the screen so the standard scenario I'm working on this project Luxo so this is a blockchain for the new credit economies how we call it or for the lifestyle space one important thing here is this is a crowd of people who does not know tech nor want to understand blockchain but they might want to create tokens or own things physically and digital so you need to make it easy for them to interact with the blockchain so we are developing and iterating on standard scenarios means like different standards like 725, like digital certificates and others we are kind of like trying things out you know how this could work in a whole flow together how it can own token there's a new standard we proposed which is the lowest one it's actually a universal receiver standard that probably is a whole discussion itself but we have in very short we have this problem of many tokens implementing different type of receiver functions so 777 has token received USC 223 has also something with token fallback function or whatever they call it so everybody has different function names if I want to have a generic account like in 725 I run into the problem that I have to implement at least like 5 different functions to receive different type of tokens or NFTs if we use a universal receiver basically one common function name that has a type and some data you pass with it you can you are able to receive everything even future assets because you could upgrade either this part that receives stuff or just let your interface deal with whatever you received so the universal receiver is a very incremental piece in an on-chain account for example and that's something we propose in our standards repository but Luxo Standards Process LSP so that's very much like the EIP repository just that it's oh no, my statement oh, your password sorry so the only difference is that it's the blockchain around this lifestyle arena so we can discuss in a more calm space and it's not already so totally busy but for competing standards we are in the standards war everybody has the better standards and we don't talk anymore about more complex interaction models and the thing about the standard scenario and also the LSPs we promote here is that we think not only about the individual standards but how this works in concert how can I make sure that I can easily read a portfolio of a given address how tokens interact with identities how identities can receive for example different tokens including future ones so there's a lot of things we should think more about how stuff works together and not just everybody comes up with their standard and now we have one little more building block but five of them and then they all don't work together and accounts reading tokens for example is super complicated totally hacky so we want to have compatibility means we need standards that kind of fit together that's already a question here it's just the idea for ERC7 to verify that we get real-world applications of it and we post it as a pound and it seems like people solve the technical problem to like help in the real world thing and the other thing I'm asking about what about doing the library I don't know how it's going to be actually an easy injection in the smart contract in a way like in California when you use this technology you are going to have a certification and you have a certified email certificate like food certification verification verification maybe one of us can start working on it to have a decentralized certification as you get more level of security so what is the example of accessing your on-chain account so it's being automatic I just put this interface in this contract and I used the library so it's implemented as a signal so basically libraries for smart contracts I mean open-cephaline is kind of like the biggest library for standardized smart contracts we have I don't really understand the question is this something like an open-source I mean open-cephaline is kind of open-source but you're talking about like how can other people contribute with different pieces or how do you have a how are we going to have like verification like doing email verification using one line of code like I want my ERC725 to have email verification so I just like add it like we are going to add a little bit of verification okay so if you want kind of like attention information like this it obviously belongs into the set data the key value store if you want to have email verification you always have to think about this is your on-chain account so you have to teach your user of what they should and shouldn't do for example through interfaces we know that for something in Instagram it's pretty public so people are not posting their private naked pictures so here we have to treat it the same you're posting it on-chain so it could or potentially be read by people so also making sure that what you put like that this is a public persona you're creating here versus maybe a private persona if you want to verify your email address then I guess there's a service which should verify that um and you could simply attach a signed message into one of the key value store which says okay we checked the email and that's yeah that's what you would do I mean either this or there's some kind of like registry which does verification some of your service could have an extra smart contact with just verification and then in the key value store you simply link to that registry so the beauty of this key value store is it can contain data on its own but it could be also simply referencing other places to go look and if we standardize these processes we exactly know what to do now and as each key value store we define can be very different we can come up with a lot of cool things to build on top of an on-chain account that's the beauty of it yeah there's a question so before you're talking about using 734 to access a controller contract with some proxy contracts for this presentation you're more saying okay we could use like say noses sake but I guess my question would be what would be the advantage of using 725 instead of just having noses sake be both the proxy and controller contracts would be still on chain because you can upgrade your key management but you could also upgrade the noses sake I mean you can build it that it's all this could be itself you could make an up I mean actually Hatryan from soon a wallet build exactly a 725 upgradeable contract where you basically have one address which contains key value store and owner and then additional management keys systems you can build it as well on the end your wallet only needs or your interface only needs to know that's the address that's the owner either it's the same address and then it has to look at what standard this is you know what kind of key manager thing it is so you can deal with that as well and then you can interact with this account in a symbols form it's just a key you know what you have in your wallet but yeah could be in the same account I think keeping it separate makes a lot of sense because what I see is happening is you have and I know the time is up I'm just to keep it short this permanent account 725 is probably something we want to keep for a while and use it in maybe some games or whatever else so it's a permanent thing we want to be secure the key manager is maybe something we can upgrade over time so having this in a separate smart contract keeps the risk lower for example the universal receiver contract the contract which knows how to deal with stuff to receive should also be a separate module because I assume people will upgrade that very frequently and if you all pack it in one account suddenly all of this code can write into the same slots potentially overriding all of the important stuff you have in there so keeping this in separate addresses which cannot really do things on the other side makes it more safe I assume there will be a future where people go to the website and say hey download this new universal receiver because now it's called and then you just go ahead and upgrade your account with this and if this would be the same account you could maybe just move your assets around or overwrite your storage values like this it's the worst thing you can do is notify your interface wrong with a wrong lock or something like this good I think that's it time's up thank you so much