# Adoption Day — UX Unconference 🚀👩‍🚀 by Aqeel Mohammad | Devcon Bogotá

- Speakers: [Aqeel Mohammad](https://streameth.org/speakers/aqeel-mohammad)
- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2023-10-09
- Duration: 2:07:28
- Topics: Science & Technology
- Watch: https://streameth.org/watch/yt-ovf40FGJBOE
- YouTube: https://www.youtube.com/watch?v=ovf40FGJBOE

## Description

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.
https://archive.devcon.org/archive/watch/6/adoption-day-ux-unconference/

View schedule at: https://adoption.web3.design  🚀👩‍🚀

Open-source design unconference and working groups helping to drive improved User Experience and usability standards forward for the decentralized eco-system.

Enable cross pollination of fresh perspectives and emerging UX methodologies. Bringing together developers and designers in the ecosystem working at the various layers of the Web3 Tech Stack to share their unique solutions and encourage interoperability amongst various systems.

Speaker(s): Aqeel Mohammad
Skill level: Beginner
Track: UX & Design
Keywords: adoption

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon 6 was held in Bogotá, Colombia on Oct 11 - 14, 2022.
Devcon is organized and presented by the Ethereum Foundation, with the support of our sponsors. To find out more, please visit https://ethereum.foundation/

## Transcript

foreign [Music] so we're going to have a few individuals kind of doing lightning talks throughout the day we'll take a break at lunch and then we'll have more opportunities for like Fishbowl panels for people to come talk about designing for adoption designing for decentralization and so forth so personally I've been quite interested in looking at how we can start designing for adoption but not compromising when it comes to decentralization in the ecosystem which we think I think we do quite often um so it would be interesting to kind of get the feedback from individuals that are working on projects like status I know Rachel has been doing some stuff on ZK for public goods rahul's from Reddit uh so we have quite a few different interesting projects uh Rob will be talking about remix and if uh there's the ease of use for like web3 Technologies and developer resources is actually a risk factor uh we'll have some people from uh a lot of the the client teams also coming because that's the area where I kind of sit and work in and I'm quite interested to see what challenges they're kind of facing as far as adoption for people staking people running nodes and making sure that there is decentralization in the ecosystem being taken in account when we do create these resources for individuals additionally we have from optimism Calvin talking about risk Frameworks for L2 Bridges so that's a quite a huge space that we've kind of not really paid attention to at this point as these Layer Two start to come in what do ux around those things really look like and then we'll have a few more client uh teams kind of talk about the integration and standardization around ux and front ends for those things additionally we'll have a few opportunities for people to just kind of like Get on stage and Riff on anything that they kind of feel important to the ecosystem so hopefully as more people struggle in throughout the day we get to a little bit more of an energy of a collaborative nature so if there are certain Empty Chairs Etc kind of like cholesterol on certain tables for now so you guys have a little bit more of a integration and communication with the individuals that are sitting next to you so I'd say like congregate on the tables that are somewhat empty and then we can kind of scale from there as people come in uh I'd like to invite Rachel up to kind of just riff a little bit about ZK and design for public goods and we'll take it from there thank you my name is Rachel I'm at the ethereum foundation on the privacy and scaling Explorations team so our team started out with a bunch of developers who were creating like um cryptographic Primitives or like programmable cryptography a lot of zero knowledge protocols so um that would allow people to prove that something's true without revealing maybe their Identity or everything about themselves um and I came into the team after they had existed for several years I was the first designer on the team there are four of us now um but it's like the past two years have been really exploratory and experimental trying to figure out like how does design fit into uh this space um when I got there my team lead Barry White Hat had a bunch of project ideas in mind of like here are some Concepts for how we could apply some of these ZK protocols to Applications so there were like these proof of concept applications that he had like Visions for and like that's where we started so we were working on zkr Pros private wallet unirp social it's like an anonymous social media platform um and those were like the first experiments how do we put an interface to um this complex code so um what I've learned through talking to the developers that I work with is that um the type of code that they're writing I don't have any development background so I'm sorry if I butcher some of the language but like the type of code that they're writing is um uh strange for a traditional development background and like there's some reframing that has to happen and like a logic that has to change when they're writing the code so that's why like they refer to it as programmable cryptography how can you take this like abstract math and turn it into code that has like the function to execute certain things and then how do you create designs on top of that so um someone asked me I've been asked a lot this week like if you don't have any development experience you like have little knowledge about cryptography how are you designing for these projects and what it comes down to is like uh not being afraid to ask questions not being afraid to ask for clarity and what I've learned is that when I'm in these sessions with the developers that I work with um asking questions they've I've gotten feedback that for them it is also super clarifying for the work that they are doing so it's like design becomes more of this like facilitation of conversation role and the two places that we're primarily doing that are for our protocols um helping people understand the value of the ZK protocols like what they can do and what use cases you might apply them to and then also creating proof of concept applications that make use of those protocols so the reason we're focusing on those two areas is because our audience is other product Developers so I like to think of it as our audience being product teams so developers designers product owners writers anyone who wants to take a ZK protocol and turn it into a usable application so when I started uh I had this misconception that I was designing for end users of of products that would give people privacy and anonymity but the more I'm on the team the more I realize it's like we're doing research for other builders for other creatives because all of our work is open source everything we're making is a public good and should be for the community to use to work from and build off of so the real value of the proof of concept applications is not like this product that allows people to anonymously chat it's for example an anonymous chat application that shows other builders this is possible you can build this thing and here is just one example of how we've built it the other important thing um like going back to the protocol conversation the protocols are like um kind of like rules like this is these are the functions that you can execute um with this code so um at first like a lot of our protocols just had documentation online that was you know there for the Curious people to read and interpret and try to build with and what we're learning is that's not enough like protocols can also have websites I was super inspired by lens protocol because um their website you know has here's use cases for how you could use the protocol and here's people who are already using it um and that's what we need to do with all of the protocols that we're working on um we can't just expect people to take something Technical and [Music] um riff off of that so just a quick question around that why do you think it is in this ecosystem we're building technology that doesn't have a clear use case so and then you're pushing the use cases on individuals that might be able to use them so and also the other thing that you kind of mentioned was that you you guys currently at the the team don't have any end users but you're developing like these prototypes for these teams to kind of get an idea of how to utilize the technology so how do you make design decisions when you don't have a clear audience from the user perspective and then from Clear audience from the perspective of like these are the companies that might be benefiting from it so like how do you kind of navigate that challenge or back and forth I'll start with that question because I forget the first question so yeah audience that's a big question who is our who's our audience so we're really I when I started on the team I was like a little bit I'm working for a little bit and being like wait we're like we're assuming that people want this we're assuming needs um how do we even have proof that people want this type of technology and I was kind of like upset we're starting backwards this isn't how design works but I think that what I've learned is that it's it's okay to start where we are to start with someone who has an idea of this is how this code could be applied to an application like you need to start with someone who like understands that deeply and we just need to try it and make the proof of concept um test it internally test it with people in the ecosystem who are interested and we're getting insights from that and also as designers we're actually learning more about the protocols and how they work and I think that yeah it's like it's not what I learned how design the design process is supposed to work but it's working for us because we can see ourselves learning more and understanding the content more deeply and we're at a point now after only yeah a year and a half where more people on the team are starting to have ideas for like new projects that we could work on and new ways to apply the protocols and it's not coming from just a few people so I kind of think that like we have to be able to communicate the value in order to get to a point where we're having more conversations with people who are saying this is what I want to prove without exposing my identity for example it is a bit restrictive even then that like you're not still getting strong enough signal from these projects that would benefit from it is like their exact use cases and how the protocol might need to be adjusted according to that because it is kind of coming from like the backward approach of the protocol is being developed without having a clear use case so let's say status is developing a messaging protocol they have a clear use case as far as like how to implement that because they know what they want to build on the product side whereas you guys are building this like bottom layer without having clear context to that are there any learnings you guys have learned from like teams or feedback that you're getting from people that do want to implement some of this stuff yeah all the time like um I think that the community really challenges us I mean I've been sitting in on talks and going to our um Community Hub that we have downstairs the temporary Anonymous Zone and uh we're constantly getting questioned like wait so you're only able to do XYZ with this protocol like isn't that limiting and that makes us like um reflect on reflect on what we're doing and see where we can improve perfect thank you very much Rachel [Music] all right good morning everyone it's fun that we all are hungover together from Ravi and now we're here trying to design beautiful systems so that more of us can go to Rave and then come back and actually that's a good point how many of us are feel safe enough to be hungover and still use like a crypto wallet to do some weird transaction for example I probably wouldn't because I know I'll mess up a lot right over the last year I have had the pleasure of building and maintaining a crypto wallet that has been used by over 3 million users for now um at Reddit where I work and I prepared some notes about how I think wallets are today and what wallet could be tomorrow not should but good so today all the wallets kind of look the same right if you have a web wallet or mobile wallet whatever you get you ask you're asked to set a password and then you're told to like save your recovery key somewhere and then if it's a mobile wallet you're given an option to backup on your iCloud or keychain or whatever and if it's a web wallet we can just store it on local storage encrypted with your password kind of thing and all of us here know how many hacks that has caused and all the things that are potentially not so great about it right so like when I when I first thought that within the crypto space I actually think this password and stuff everyone kind of gets it like we all get it right the password is not the recovery phrase this is because you save your password doesn't mean you're kind of um safe like you still need a recovery phrase and if you forget your password it's okay if you have your recovery phrase unfortunately this Paradigm is flipped over from the web 2 model when the web 2 model the only thing you care about is the password as long as you have a password you're safe if you forget your password that's fine there are some ways to recover them or reset them in some way or the other right which is very interesting since like 1990s every web to security engineer will tell you don't write your password anywhere don't put it as posted notes on your laptop and here we are like 20 since 2014 we've been working in ethereum and what do we tell our users save your recovery phrase don't write it in one place write it with pen and paper write in five different places if you're like paranoid enough you should put in like bank account lockers fly halfway across the world just to recover your keys if you have like if you're like some kind of a Degen or whatever um which is completely completely completely different to what we do in web 2 right so it's kind of weird for us to s for us to expect web 2 users to do the same thing right and if you've been around in Defcon over the last three days or if you've been hanging around in the world of account obstruction you know that there are like three really hyped up eips like one is this 4337 which requires you took which enables you to have the smart contract wallet without any protocol changes you also have Argent that's building this smart contract wallet which is amazing because you don't now need to care about your private keys well you kind of do but you know there are ways to go about it right and then there are like these other older eips I'm forgetting the numbers I think it's 2918 or something um and some of them like kind of asked about protocol changes right my hot take here is 4337 no matter how hyped up it is it's actually not the best idea for multiple reasons one is it adds insane amounts of complexity um so if anyone has been like hanging around the fourth reasonable world what they do is you have a smart contract wallet and then you have this other private mempool other than the ethereum mempool that we all use know and love and get drugged on um so we have this private mempool you do your transactions you send to the private mempool then there are these bundlers who bundle all these transactions kind of like flashbots I'm oversimplifying a bit and then you take these transactions put it at the top of the block right um and we all have seen about these and that causes like insane amount of more censorship resistant issues um it will probably cause like a ton of other issues if not done properly and it's still like for a normal user now they have like two weird hexadecimal strings that they think about one is their actual account like their eeoa in in the technical sense and one is a smart contract wallet and now when they go on etherscan they don't want to check their actual address they have to check their smart contract address kind of thing so this is like a bit messed up instead of trying to simplify things we are adding another layer of complexity and stuff right and I've been thinking a lot about these things and the best thing is that there is no good answer which is which is why I love this space right because we need researchers and Academia and non-academia we need ux people we need like Engineers but we need all of them to come together and like work on ux together we don't just want like designers to do their thing and then Engineers to do their thing and then academics to do their own thing because then none of them actually think about things together right so uh one of the interesting things I've been thinking about is which sadly I don't think it's possible to act large scale today is things called multi-party competition anyone here is familiar with the idea by any chance yeah okay so for those who don't really quickly the idea is instead of So currently you have this private key and then this one private key does this execution on its own today the signing of the transaction and then sends it to the great mempool that we all know and love but in multi-party computation you have bunch of parties or people or clients that come together to do this transaction together so for example you can think about your private key being divided into three different parts and then every time you do a transaction you could do like a two of three of those private Keys coming together to do a transaction right and then the most interesting thing so I was talking with someone who works at web3 auth today earlier I think yesterday and the most interesting thing about this is like so one of the keys is stored in the laptop or like a recovery device that you kind of don't use it's kind of like a cold wallet then your second key is stored on your phone so it's a mobile wallet and then the third key is can be used by login with Google or log in with Facebook or something but they don't actually store that key in Google servers obviously so they have this other um they have this really interesting idea where they have something akin to a data availability Committee of sorts they have a committee that talks to these providers like Google and Facebook and Reddit and Twitter who then stored the private key there but you need like this oauth login token from Google to actually execute the transactions and stuff right um still quite better we have like now you have you can lose one of the keys and it's fine you could forget like your Google password or Facebook password and you could use normal login systems a normal reset password techniques and stuff right um and then you go like okay Rahul this is this is very cool um will this work today it does kind of work coinbase wallet has something similar but instead of divided into three parts they have two parts kind of thing but if you ever use it you realize it's a bit slower than normal wallets obviously because I mean you can imagine there are like three keys they come together you have like a bunch of like oauth systems coming in and then you have this really really interesting uh cryptographic algorithms that come together to do the signature and then you have to validate the signature and then combine it into a normal signature that ethereum or L1 or l2s can understand kind of thing um so maybe what what we really need are like two kinds of wallets right one is the kind of wallets used by people who are familiar with crypto and these are also the people funny enough these are also the people who at some point may have gotten hacked but they still love crypto somewhere they just still keep using it right so that's probably where we want to uh do these really fun techniques and then we want to try and do these really really simple things in for like the normal users who aren't encrypted yet but we all want them to be in crypto right and the idea of not instead of like having one app that does both of these things with like you know this Advanced option where people can do these crazy things you have two different apps they can both take two very different strategies and experiment with things much more quicker but yet those are my ruminations over the last few months on crypto wallets so we're curious as far as like from the Reddit perspective so most of the projects in the ecosystem don't really have a user base you guys are fortunate enough to have like millions of users that you are exposing to some of the Technologies what are some of the challenges or the issues that you guys have kind of identified as far as like do you even surface some of this stuff that it is a crypto wallet or do you abstract all that away or what's the framing that you guys are currently using so I'm not going to speak on behalf of Reddit but when I have noticed my like when I have noticed people use crypto wallets it's like number one um we are surrounded by these password systems every day so they don't actually get what this recovery phrase thing is um it's also weird because you can't expect them to understand private public key but I think by far my biggest takeaway is usually when we onboard people into new technologies we tell them what are the pros how beautiful it is how it's going to change your life whereas when you try to onboard people in crypto we kind of scared them we throw these really scary jargons like cryptography encryption private key don't give your keys uh you will get hacked you will lose everything right so we give them like a one hour essay on like what you need to be careful about and then we go like so yeah if you're kind of if you're still interested come into this crazy world that we all know and love called crypto kind of thing so maybe like have it a bit more easier rolling yeah thank you everyone so I think this kind of ties in quite perfectly from the next session that we're going to change around a little bit so John will go up around multi chain tokens and applications and WX challenges for wallets as far as like multi-chain Etc so John take it away thank you hello cool um all right before I start um could we have a quick show of hands of anybody here who's working on wallets or involved in wallets in any way wow wonderful awesome um is there anyone here who's working on Bridges wow awesome cool all right this talk is for you um so um yeah the multi-chain uh token send ux challenges uh that we're facing today I'm going to uh talk about the challenges a bit and then um hopefully we can have a discussion about uh possible solutions so we can ease this user pane um cool before I dive in let's think about what users really need in their kind of hierarchy of needs when it comes to transferring money um the most important thing of any money transfer mechanism not just crypto traditional money transfer mechanisms huala anything is reliability you know reliability is important you don't want your money to get lost if we don't get reliability right nothing really Else Matters and that includes security and then once we've got reliability nailed then there are three more points all kind of more or less on the same level which is cost speed and usability and users can be happy to trade some of these against each other you know pay a bit more for a transaction to go faster pay a bit less and a transaction go slower um but yeah reliability is absolutely the number one important thing there about when making a transfer um nobody cares about the detailed mechanics about how a transfer is made this has not been a user need people have not been saying oh I really want to get understand how swift Works how what's my banking system doing under the hood wow crypto can really expose the inner workings of Swift transactions I haven't heard that from anyone um and in today's multi-chain blockchain world um in yeah multi-chain blockchain world we require users to understand what L2 chains are now in building status I think about my mom my mom's over 70 years old she's a complete technophobe and I want to make something that she can use and she can tell her friends about and her friends can use and if I have to be explaining to her what an L2 chain is I've probably failed at that point um yeah we don't you know if I want to send money to someone on PayPal I just use their email address we don't want to require multiple information artifacts um yeah and asking people to perform manual routing actions is absolutely crazy but I'll dive into this so back in the good old days when we were just ethereum was new and we'd all moved from Bitcoin and it was just ethereum and single chain token transfers everything was easy this was a uh token transfer so um if Bob wanted to send a hundred if Alice wanted to send a hundred die to Bob um Bob Bob would uh send Alice his ethereum address or your last name um Alice would enter Bob's ethereum address select I enter 100 sign the transaction done that's really easy um I know the ux was a little bit rough back then when ethereum first came out but fundamentally this is an easy process this isn't any harder than using PayPal um but there was a problem um it didn't scale and if we want to bring uh crypto and especially in the for payments and token transfers the world we needed something that could do more than 50 transactions per second so that's been the last five years of work with l2s and you know now dank sharding and all the exciting things that are happening this gives us the scale but unfortunately it's had a side effect that it's broken the token transfer ux I think pretty comprehensively unfortunately um so this is what a simple token transfer looks like in today's multi-chain world contrast it to uh that um it's horrible but let's walk through it okay so let's say um Alice wants to send 100 die to Bob today at the conference and Alice has 125 die in total she's got 25 on ethereum mainnet 25 down optimism 25 down arbitrum 25 to 100K sync and 25 Diane scroll all on the same ethereum address however Bob's wallet only supports ethereum main net and optimism so what do they do so Alice says to Bob I would like to send you a hundred die and Bob says to Alice here is my address um and I use ethereum and optimism so this is our first fail both Alice and Bob need to know what L2 chains are as I said I don't want to have to explain this to my mom um so then Alice saves Bob's address and then Alice also tries to remember that Bob told her that he was only happy to receive funds on mainnet and optimism so if we think back to the kind of hierarchy of user needs reliability this we we're starting to make something that's very unreliable from a user perspective um yeah Alice needs to save multiple information artifacts in multiple places um and yeah and then later Alice will need to retrieve multiple information artifacts from multiple places again totally error-prone um then um Alice opens one of the many cross-change bridged apps and uses it to bridge 25 die from arbitrim to optimism so now Alice not only needs to know what else you chains are she needs to know what cross-chain bridged apps are okay and there's like 10 or 15 of them today um so and the prices a lot of these are balanceable so the prices are changing all the time and Alice isn't going to check 15 different bridged apps to find the best price and if she does check them by the time she's checked the ball the prices has changed um so anyway she opens one and she uh Bridges the 25 die from arbitrim to optimism now unfortunately that bridged app um didn't support ZK sync to optimism so now she needs to navigate to a second bridged app and Bridge 25 die from Z Keys Inc to optimism um but now remember um Alice also had 25 die on scroll now if Alice had no way of knowing this but it would have been cheaper for her to actually use a different bridged out and do the scroll to optimism transfer but the complexity here has just exploded so Alice has no way of finding the cheapest price and she just picks one and goes with it because she needs to get it done um yay Alice now has 25 ethereum mainnet and 75 on optimism and so Alice can go back to what she originally wanted to do which was um send 100 to Bob so she does one transaction on ethereum Main net to Bob's address of 25 die and another transaction on optimism to Bob's address of 75 die and finally after about 10 minutes of work Alice has managed to send a hundred die to Bob now I'm a blockchain geek I love this but even me and understand how this works I don't want to spend 10 or 15 minutes making a single transfer to someone you know and that's this is yeah we're we're so far beyond where we need to be for mainstream adoption of multi-chain here it's um yeah we've got something we need to fix yeah so let's reflect on it yeah all Alice wanted to do was said to send 100 die she had to navigate to and interact with two different Bridge steps she had to perform two different token send actions um all of what while not forgetting which chains Bob was happy to receive funds on and it's almost certain that Alice overpaid for this um in fact she yeah she did she definitely overpaid for it um it's error-prone you know you've got these different information artifacts you're navigating to these different places um you know heavily we're we're making it hard for the user and we're giving them a lot of scope to make errors um and now how do I sell this to someone I've been telling them all the wonderful things about crypto and then they go to make a transfer they run into this and they were like oh I'm never doing that again I'm going back to PayPal you know that's um this this this will turn people off and yeah it's needless needlessly costly and it requires far too higher level of uh blockchain knowledge really so we can fix it um that's the problem but um wallets we need to work together to fix this um so I'll jump to the conclusion and then I'll talk why this is the answer so to unlock fixing all of those problems I've talked about us wallets we need to agree on standards so that when one of our users gives another of users then address it also that address also signals which chains the other user is happy to receive funds on um luckily there's already a standard called eip3770 which pre-pends um uh change short name to the beginning of an address um based on lychee's database of change short names what we're doing at status is we're extending that so you can prepend multiple change short names and um yeah to be honest we're happy to do it in whatever way the consensus of of wallet Builders comes up with but I do think the most important thing is we need to agree a way for users to Signal which chains they're happy to receive funds on for a given address um now and there are other ways to do this so like ens in fact ens already basically supports doing this but not all users have ens addresses it costs money to create an EMS address their privacy implications so this is a fallback for people who don't have any NS address um but let's let's talk through with just this one simple thing very simple we can fix everything I just talked about so we can drop the ux tokens and complexity from this back down to this so with this new with with only adding an address format that signals which chains are users happy to receive funds on Alice can say to Bob I'd like you to send you a hundred die Bob will send his address to Alice Alice can enter Bob's address into the into her wallet and select the type of token and number of tokens to send an allies can perform a single action to authenticate a bundle of transactions and it's done in fact both neither Alice or Bob need to even know what else L2 chains are for this to work so let's let's unpack how this uh actually works under the covers um so Alice says to Bob I'd like to send you a hundred to die and Bob sends his address to Alice now with with this address format that adds the um change that the owner of the dress is happy to receive funds on Bob's wallet automatic yes so that Bob's wallet automatically encodes this into um Bob's address and Bob doesn't need to even know that his wallet is doing this potentially um and then when Alice enters Bob's address into her wallet um Alice's wallet reads which chains Bob's wallet can receive receive funds from the short name chain IDs that are prepended to Bob's ethereum address and now um Alice's wallet can do all the clever stuff so add the Alice's wallet we'll look at um the type of token Alice wants to send the number of token allies wants to send what the balance of that token is across all the chains that the wallet supports and has for that address um it will look at the chains um which uh Bob is happy to receive funds on that address it will look at 15 cross-chain bridges in real time and work out exactly which one is cheapest it will look at gas prices across all the various chains and basically it can entirely automate the routing this is an impossible problem actually for a human to solve this is the type of thing we invented computers for so let's use computers to do this um it's a quick note we're going to be short on time but I think some of these discussions are quite important so maybe we schedule like a follow-up conversation and a working group and kind of continue yeah yeah I was hoping we could have a discussion with the wallet folks about this um okay and then Alice performs a single action to authenticate what is actually a bundle of transactions um so with with one action in the uh UI a whole bunch of transactions are signed that perform all the bridging and all the send uh actions and then Bob's um wallet receives the tokens and if Bob's wallet has decided to display an aggregate view of balances across chains Bob just sees his uh received a hundred die now this is just optionally abstracting everything away from the user but obviously a user can like peel back the onion and dig in and you know manually tweak parameters when we've done some ad hoc testing of the designs we have for status that basically Implement all of this it's quite interesting existing blockchain users kind of go oh this is scary what are you doing but people who've never used blockchain before seem to be completely comfortable with it so I think once we release our product that does all of these things yeah existing blockchain users will take a while to get comfortable with this level of automation but I think for new user adoption it'll be great um yeah and now we have a token transfer experience that delivers usability we've got back that you know it's it's simple to use we have delivered to users the cost benefits of L2 chains with and without all the complexity of the current multi-chain token send um and yeah we've eliminated the two separate information artifacts that uses need to needed to hold we've made it possible for users to send transactions in the cheapest way that's available at that point of time um Etc so yeah these usability costs and reliability benefits are all needed um yeah if crypto token transfers are going to have have a chance of breaking into the mainstream um yeah from from earlier I sorry [Music] potentially um I've tried to keep this proposal as simple as possible um just because this is something we need to bring come to consensus on as wallet Builders and the simpler it is the better chance of it happening but yeah there's there's many ideas of ways it could be extended in the future and also with different address formats and things resolver services are a really good way to go but I think we need a base layer uh address standard as well yeah I think this topic requires a working group for sure so I'd want to be respectful of other other speakers time so if you guys do have more questions and you're gonna kind of acquire Less in the corner of this room we have the room for the whole day so you're more than welcome to kind of like brainstorm and work on this stuff and I think thank you John for really like picking up the Baton for this is it's an area that no one has really done any work in in some organized manner so thank you for putting this together and I really hope that people from the wallets that are here together take this opportunity to really collaborate and move some of this stuff forward thank you very much cool uh so next up we have Rob from the remix team and he's going to talk a little bit about developer infrastructure and sorry should we have a specific time for wallets to get together to have this system you guys are more than welcome to even have some like quiet conversations right now but I think after lunch around 12 30 you guys could probably get started and then the last like conversation we're probably gonna have is around like 110 which is some of the client teams so okay so let's let's discuss the 12 30. yeah let's all right thank you very much Rob you're up next yeah is ease of use an attack vector is remix too popular among beginners because uh beginners this is a talk about beginners probably or it's a talk about new pubs because remix kind of is a hub for noobs and a noobs are a good place to steal from and uh but this could be remix it could be uh you know MS-DOS or whatever uh and we recently got this email um telling people that we got a shutdown remix um because it's too easy to scam people there and we often get emails from people saying uh I lost my money from this I copied some code from a YouTube video and um lost my money can you get it help me get it back um so then it's a question of like are we responsible for that did we enable these scammers uh uh what else does he say that's funny well it's not really funny but uh but I beg you to close your site um so who's responsible and the choices are users because they're the idiots that got scammed well that's not really a great thing to say uh remix I don't really want to be responsible um or the scammers well they did it um but anyway it's a discussion that we need to kind of have um and in trying to slow down the process um do we need to add some friction now friction can come in a couple different forms uh could be um warnings we've added some warnings and remix and as the videos came out of telling people to use the this flashbot stuff and the scam videos uh we added some warnings in the home page uh we added some warnings there um you know people are still getting scammed so maybe they're not reading the warnings um and also when you deploy to mainnet you see this modal it's not about saying you know don't do this if you don't know the solidity code that you're deploying it's actually about more like um gas fees but anyway it slows people down um so uh it's a little bit harder to deploy to mainnet than to any test net um and from the remix docs uh you know it's like warning people not to deploy things they don't know I mean they have to dig through the docs to get this so maybe that's not such a useful warning but also like it's a warning with a little bit of humor where like uh um uh don't uh yeah don't use a get rich quick screen scheme uh and if you really really want to get rich um you know it's maybe humor is a way of getting the warnings to work a little bit uh and how many warnings are too many and when does it get depressing you know like like this you know that's a warning to depress people and if you come into remix every day and you see like scam stuff you know it's kind of disgusting or there's other kinds of warnings like uh harken stranger shun the danger if you plan to stay the same best come back from whence you came um it's from one of my favorite books uh Shrek um or we could try to use other kind of conceptual models for warnings you know like um you know not don't choke warnings for kids under three you know or not appropriate for uh gullible users but you know who defines what a gullible user is especially if you're trying to make your tool accessible to everybody uh and look like here's a another sort of example like a table saw is a kind of a beautiful object um but it's got some ugly parts that like uh finger protector also like the tube that takes out the um sawdust is a it's kind of ugly and the stop button is ugly but the rest is like very nice tool but you add some of these um like protection features and it makes the tool a little more cumbersome maybe a more useful maybe more you feel more safer to use it but um has some problems like if you extend this like the in a shop class in high school the teacher doesn't want to take responsibility for anyone getting hurt so they make it impossible for any of the students to use the tool because you have to go through all these steps to use the tool so but that's like too much friction and we want people to adopt the tool and to use it and to play with it but there are inherent risks so that was the idea of like obnoxious but funny warnings like um you know if that was on the home page of remix um maybe that would temper people but maybe it would be obnoxious itself um and how do we make it so it's not miserable um and or it could be like more like just news like have you seen that newspaper wrecked uh it's really I liked reading it I also like reading the club the crime blotter and then and then all the news local newspaper like what the local crimes are around me um you know it could be a scroll like a feed of wrecked and remix like that would be like kind of informative and you know just like in showing some of the inherent dangers um and what's another kind of friction that's not a warning you know I guess that's a kind of delay which is a little bit like that modal before we deploy to mainnet um so I don't really want to use too much friction because the whole idea is that you don't the guy's point was that in other tools like hard hat or truffle or anything there's a kind of setup and it gets it kind of that bar like stops a lot of people or fresh beginners from using the tools so with a tool that we want everyone to use that's inherently um has some could be dangerous qualities to it that people you can get scammed there and you know anyway um and is it our responsibility to teach all the users um some fiscal responsibility or um literacy um you know like in the US you have to be over 18 to sign a credit card but I don't know how you put that into remix but still there's certain kinds of thresholds that are used in other Financial systems but then you know the credit card companies are sending their credit cards to everybody and people are going to debt as a result who don't understand how to use it and even those who do understand how to use it go into debt too because uh I want to buy that thing um and why are people more gullible here than they are in the rest of their life the question that you know is another way to ask so maybe we can get better warnings or better ways of understanding what's going on um uh so you know maybe they're more gullible because they're afraid of missing out um or maybe they're more gullible just because it's it's a get rich quick scheme and they're trying to enter the space someone shows them how to do it um sort of but I mean I'm always afraid to deploy things to mainnet that I don't understand and even things I do understand so I'm surprised that people have the courage to um follow these schemes but they do um and this just was a thought that came up uh after the last talk that maybe users see everything as just so complicated uh they have to they want to understand it they want to play with it here's a little bit of code okay I'll try um but they don't understand the complexities of the whole system and so they're just trying stuff out and and they get screwed um so it's somehow to temper their play is I guess is the warning here um and then the other idea is maybe the scammers are just very charismatic and seductive and so um I don't know can we make warnings that are out out seduce the seducers uh the problem is um it's hard to do um so yeah I'm not sure how you out seduce the seducers here so I think we're back to trying to get some fun some literacy of web 3 to our users and uh anyway oh I I didn't get that that's it thank you just had a quick question do you think it is like as a remix is an educational tool it is your responsibility to worry about some of this stuff or you're already doing the service that you are providing which is provide this playground for individuals to learn and so forth do you think that's enough or do you take that burden on yourself at this point uh well we we want to uh we put warnings on the home page that was kind of new okay and um it's in yeah more than that I don't think so but um yeah I don't I don't think because it's a you know it's a tool and it makes sense all right thank you very much next up [Applause] okay thank you uh next up we have Sunil and the smart token Labs do you guys have any slides or are you gonna okay perfect so just for context uh smart token Labs did a great job of building the ticket adaptations for Devcon and also the nfts so if you guys haven't claimed on optimism arbitrum or polygon you can do that right now and then and mainnet will be hopefully Friday yeah tomorrow yeah yeah check out the application and then get yourself some Defcon nfts yes thank you Akil um so hey hey guys good day you know happy to be here and today I'm going to talk about attestations and the ux challenges that we faced um with attestations and really this is an appeal to all of you guys here the ux designers right to really bring this concept live into web3 and also help us with the adoption because we are doing it as a public good for everyone so before beginning jumping into it right jumping into the ux issues uh let me give you a brief on what addressations are so at the heart of it attestation is a cryptographic proof that is issued by Devcon saying that this ticket is assigned against your email so go to your inbox check out the Third email from Deva the Unicorn you have your Association email there so once you click that you go to this page that decodes this attestation so attestation even though it's actually photographic proof it's encoded as a URL and this is decoded and stored in your browser's local storage now local storage is considered as a secure Enclave where the proof cryptographic proof resides in a relatively Safe Way other browsers other browsers or other websites cannot access this in a direct fashion now once you have this proof you can do several interesting things now the first thing is that this is readily usable by smart contracts so you can initiate transactions on chain you can do things on chain so minting nfts right that is something that you can do on chain because you have this um cryptographic proof now the beauty of application is that it does not have to be limited to Onsen transactions you can use it off scene and also you can use it for in person in real life examples because you also can expose the signed ticket as a QR code now this is using the standard cryptographic methods and as long as you know devcon's public key anyone can literally decode it and verify this is signed by Defcon and it is a ticket attestation now this is the concept and we are doing ticket as a session because we believe that before we go into ticketing and before we jump into nfts as tickets you need to have a step before that where it is a ubiquitous technology because web3 is not just limited to on-san transactions and if you're using something like tickets where for events you know you should not restrict it to people who only have wallet or if you don't have all of the other solution is to have a custodial wallet but that sort of Beats the purpose right so we are building this piece of technology by lensing it on one of the most ubiquitous things that's there in Internet which is an email address and that's where you know we are linking this proof against and from there it is up to you you know it is up to everyone to use this attestation in a permissionless fashion to do whatever you want and that's the vision that's the idea that we are trying to do okay so that's a vision that's we are trying to do now the ux challenges the first one starts with the naming itself attestations before I explained attestations to you what did it mean to you you know hey you have a ticket at the station what does it mean to you so we had been having these conversations luckily you know for us you know maybe maybe not luckily for everyone but we had like you know three years to plan for this because of covet and we had been you know bouncing these ideas with people so the first feedback that I would always get is that now you know at a station it doesn't mean anything you know you should call it something else now what is that something else certificates proves and you know what what happened all these three years nfts happened and until that point of time nobody knew what nfts are and now everybody you know the kid night so knows what an nft is so we thought that okay maybe we'll stick with that Association because nothing there is nothing really that captures that idea around having a cryptographic proof that can do all these things that can be a core component of how web3 really connects to the real world so we then did that but still it's not understood just yet so the first challenge is naming it and you know how how to how how do we design it now the second one you know really uh comes into um you know again you know I would say that it's part of this first challenge is how we visualize it because nfts have a picture associated with it it has a standard metadata but at the same time attestation does not have a visualization to it now we went around uh this Challenge and we visualized it as a ticket in in the web page and now there are two different states that you can have you go to this web space using a magic link and you would have a ticket there and if not you would have a blank space saying that you don't have a ticket at a station now even testing it with users in Dev con you know if you click if you click your magic link you can see that you know that's that's visualization is the first one that comes up however it is not intuitive to say that you know this is the ticket and that is the ticket attestation that you have so we are still working on it so I think that you know there's a long way to go in order to identify you know how we can visualize this thing and the third thing is that you know even for attestations even when you have it you know loaded into your local storage there it's not complete yet because the proof essentially says that Defcon has issued this ticket against your email and you know that's in your local storage now in order to do any sort of on-sane interactions you have to have a second piece there which is what we call as email address session now email address session essentially says that your email is now tied against this wallet and there is a trust anger that signs it off so once you put both of these two these things together that is when you can you know really initiate blocks in transactions now the state of how the ticket is verified and where you can use it that is still something that we are trying to figure out what is the best way to communicate it to a user especially a user who is completely new to crypto and completely new to web3 so um you know that's the first challenge that we are you know working around and that's around you know naming you know definition and visualization the second Us ux Talent is that browser support okay now people use all different kind of browsers now but looking at the um devices that the group that are using associations today it seems that Chrome and Safari kind of you know encapsulates or you know has around 85 percentage of the users are using it however they are using it on mobile they're using it on desktop and in order to get some of the complex logic working around attestations it is best to be used on a desktop browser however when it comes to mobile browsers there are so many different channels there's so many different Hoops that the users have to go through in some browsers they would have to give the permissions in the some browsers they would have to open up a new tab and come back so it's really really hard and especially when you take it to the wallet browsers the dab browsers it doesn't work there at all so you know we have so many people coming in saying that you know they're using a smart contract wallet so smart you know smart contract browser and it doesn't work because the modern browsers have the capacity to um uh you know process and use attestations but most of these wallet browsers does not so how a user is navigated to the browser is also a challenge now the way we go around it is that you know we identify the device and we show a message that this is not a supported browser you sit in another browser but in not you know invariably people would still try to use it on a Dap browser and you would get it we're gonna battle so Nazi you know uh second floor and the last one is that in order to procure a email address session which I said that that's needed to prove the complete unbroken proof from Defcon to issuing the ticket to you and you having this wallet there is a OTP flow that you need to go through okay and we did that for devconnect you know devkinand was the first instance where we shared it share this ticket attestation with to everyone and ask them to meet tickets okay and for this user experience people had to clip through go to the page and then procure this email address station and from there the biggest friction Point happened because you know you would have to go to a new tab because of the restrictions are on iframes because of the restrictions about your cookies and you know all the cross origin issues you had to open up a new tab and then go to your email address get the OTP put that into the tab that was you know opened up you had to close it and then come back and then you would have a full attestation that's ready to be used for minting it was really really bad and you know getting all the redirect flows implemented was also hard you know we are still working on it but hey for Devcon we thought that this is a New Concept let's just take it away you know let's just make it so simple that you know people can still use it so in in the current US that you see right now you don't see this second portion of you know procuring email address sessions because we wanted to make it as easy as possible for anyone to adopt it now even then what we are seeing is that people are getting really confused okay and especially for the nft minting process we have made it so simple that all you have to do is to go to the ticket minting page connect to your wallet and click mint and after a while the nft would come through now we went in a little bit high on uh really good videos and Graphics around you know how to visualize it however on iPhones it doesn't work you know no surprises and people are you know confused around you know how this meeting process is happening and the interesting question is that have we made it too simple you don't have to sign a transaction in order to claim your nft and I'm seeing that you know people are getting confused okay I did not sign in some transaction I connected my wallet how is the nft getting minted for me so um then I'm uh then we are thinking right you know have we made it too simple is there any other you know feedback that we should give to the user to make it a bit more clear that you know this is how it works so anyway you know this is where we are today um you know really looking at uh you know getting the meaning processes out getting to get the feedback from the community now um again you know as I uh said earlier this is an open appeal to all the designers over here around you know thinking about how we could make this open Community sorry open source technology better how we can use it to connect it to the real world so you know that's what we are really looking for and I have you know I ask you to go check out your Digger data station uh web page try to use it to claim some of the permissionless perks that people are providing try to maintain nft and let us know if you have any feedback you know right on the bottom of the page there we have of telegram group so pop in uh you know get me grab me for a discussion you know always love that so you know with that appeal I wrap up my decision wrap up my speak and uh thank you so much for listening thank you guys thank you very much kind of sounds like you're damned if you do if you and damned if you don't so it's interesting to see that even making it easier confuses users at the end of the day but I'm really excited to have Kelvin come up and talk about the the risk factors around L2 Bridges and what kind of systems we can create around that so thank you very much you can get any slides or anything are you good no no slides um we're in this mode okay uh we should chat later because this optimism is building a an attestation system like a base layer attestation system smart talk what was yeah yeah yeah highly interested um base layer attestation thing okay so I'm going to need some like basic audience participation to prove a point um so you know like how you know raise your hand if you know what Roll-Ups are generally you know what layer twos are okay kind of every most people all right um optimistic roll ups right raise your hand if you know what an optimistic roll-up is do you know what a you know what a fraud proof is okay um and then raise your hand if you think that a fraud proof that the definition of a working fraud proof is that it it's a system that's significantly improves proves the security model of a roll-up of an optimistic roll-up over not having a fraud proof at all if you you know if this is what you believe a fraud proof is all right okay and then you know if I if I ask people let's say you had if I asked people which which blockchain which Roll-Ups today have fraud proofs have working fraud proofs can someone can I point at people which yeah yeah tell tell me tell me which which optimistic Roll-Ups have working fraud proofs which which uh Roll-Ups have which Roll-Ups have I have working fraud proofs which Roll-Ups have working fraud proofs okay interesting so this is actually more correct than I think the average person would get to [Music] um the answer is basically none the answer is essentially none um this is a very confusing thing that has been going on in the sort of Layer Two security ecosystem which is that we have no standardized language around how to communicate security of our systems I I said bridges in the thing but really I mean l2s in general um there's no language that we can use to say what are the real security properties of these different systems right and so people say oh you know we have you know maybe the only roll-up that has working fraud proofs is fuel V1 and no one uses it and it only really has half working fraud proofs because it has one implementation if that implementation has bugs who cares right so we're faced right now with two very very important problems in the in the roll up space the first one is that we need to keep Roll-Ups and we need to keep layer twos accountable right if we don't keep layer twos accountable if we don't have a standardized set of things that layer twos really need to prove to the world that they do um if we don't do that then security is going to come down to marketing right you can just convince users that you're more secure by saying these vague things that are not technically incorrect but no one can really prove you otherwise and like and if you try to argue about it you're going to start a big fight on Twitter like I do every other day and then this is what happens right security becomes about marketing instead of real security for users so this is problem number one right how do we come up with a framework of like this is a more technical problem of specific features that a roll-up or a layer 2 system needs to have to be considered secure and then the other side of this coin is that that system of um keeping things accountable doesn't matter unless we can communicate that to users in an effective way if you go to you know I love l2b but if you go to l2beat right now and you look at the risks it's illegible it doesn't make any sense this uh you know this can do this if that it's just it's impossible for the average user to actually look at that information and get anything meaningful out of it and I think the average user really needs something much simpler right maybe that looks like a score like a you know like like one of those JavaScript performance scores maybe it literally just comes down to a single number that says or you know a rating out of 100 whatever it is right something that just in in the simplest possible terms communicates it to a user what are the actual security properties of the thing you're about to interact with because if we don't people are going to get burnt and then they're going to go and they're going to complain about layer twos and they're going to never use another layer two again because they thought it was Secure because the marketing said it was Secure and um and really and then and then the people who were marketing it were saying well you know we never actually said it was Secure we said it we actually said it had a fraud proof but then uh but the the multi-sig is what got hacked and you know we just didn't it's just like all this it's really confusing it doesn't make any sense if we don't have a language to communicate this to users they're going to have no clue what the systems that they're using are actually capable of they're going to have no clue how safe their money actually is and if we don't fix this problem people are going to get hurt and then they're not going to want to use ethereum and it's going to hold back this roll-up Centric future for a long time so I guess later on when we start doing Workshop stuff the goal is basically sort of half and half right it's trying to come up with what are the key features of these L2 systems that we want to hold l2s accountable because we want to make the incentive to have real security not pretend security not just marketing we want it to be you know we want concrete things that if you're not doing these things the reality is you're not secure no matter how much you say you're secure so we want a list of concrete things and then on the other side we want a way to easily communicate that to users I don't know what that looks like I don't know where the right place is to put that information I think when we talk about this a big concern is you know if we put this on the applications by the time they're on the applications they've already taken that risk if we put it on the bridge by the time they're on the bridge you know maybe they're thinking about taking the risk but a lot of the people who come to our Bridge the user research that we've done by the time they're on the bridged app they've already basically committed to bridging so it's unclear where to put this information so that users know ahead of time before they even get into the ecosystem because once they're in you know oh now I found out that it's not as secure as I want but what I have to I have to withdraw now and spend more money to get out of the system it's just a headache so the goal is how do we make sure that users really know the security properties of the systems that we're using and where should that information live and what should that information look like so that's what we're interested at optimism basically you know how do we we just want to make sure that our users know what they're getting into before they're getting into it so I had a few questions one was like one of the issues is similar when you have staking providers is like who does that ranking and then is that ranking then also somewhat compromised by the organization that's doing it or who's financing them Etc like how do you create some sort of mechanism around what is secure what is insecure like right so you know the back end I guess of this is the is the app test there is on my mind is the is the risk framework right so it's the low level things and I think fundamentally this is just going to have to be an open thing I mean optimism is very interested in this for ourselves we want to keep ourselves accountable and so where we've been working on this internally just as like a checklist of things that we need to do to get to real security um and so I think an easy answer is we just put it out there start some type sort of organization which is like a you know some sort of uh Collective group of the bigger l2s and say these are the security properties that we're pitching if you have any ideas about security properties that don't you know that we're missing or a few things that you think these don't matter like explain to us why why does this matter why does this not matter and like I think at the end of the day it just has to be like a Consortium of people coming up with a standard that we can all measure ourselves against also another question came in from Grammy from Argent he wasn't able to attend but he was wondering how could he understand the trust differences between the role of flavor so his understanding was that ZK Roll-Ups can trust each other but optimistic rollups can't trust them or is that true or is the understanding flawed um I don't know what the word trust means in this case Okay um well okay you know here's another thing right it's like you you have so many different um axes along which you want to measure these things and like a critical one is is bug risk right like you can have a zika roll up the whole point of the proof system is to prove the correct execution of the client if the if the client has a bug in it the proof system might be perfect but all of a sudden the proof just proves that the bug ran correctly and now you can lose all your money and so like I think there's there's so many different angles that people have been you know it's so easy to get confused about okay is a ZK roll-up more secure than an optimistic roll-up does it matter if I only have one client or if I only have one proof do I need three different proofs and but like none the users don't care about any of this right how do you communicate that to users saying you know a system with one proof is less secure than a system with two proofs but if the set if the system with two proofs was built was has never been tested on chain before maybe it's less secure and so it's you know at the end of the day there's too much information to communicate to users how do you boil that down into this chain is like okay secure this chain is more secure than this other chain right makes sense and then beyond that I think what John was talking about just the user experience between bouncing and utilizing these chains in some time with cohesive manner is a big challenge too so I think maybe that group could get together and discuss some of these things together in some capacity and I think the smart token Labs have quite a bit of experience from alpha wallet et cetera as well so that that could be a good conglomerate of teams to get together so thank you very much and looking forward to those conversations later on in the evening uh so the next topics we're kind of jump into is uh I invited most of the client teams to come participate I think that's one of the biggest issues in the ecosystem right now is how do we get more people participating in the network itself and what are the ux issues and areas that we need to kind of focus on so we'll kind of skip over the attendee Fishbowl and just go straight to Cindy who's from chainsafe labs and working on lodestar and other projects there so thank you very much Cindy good you just got to turn it on but you can just hear this one hey guys this talk isn't going to be about lodestar it's not going to be about client adoption It's actually an end user talk so sorry for the disappointment but all good I think it's refreshing cool so my name is Cindy I work at chain Safe Systems we are a blockchain research and development firm we also make products that help end users out using web3 in their everyday cool so in 2020 and 2021 I worked on a project called chainsave files it's an encrypted file management platform kind of like pad or skiff the only difference is that we used we put the content directly on the ipfs and filecoin Network so I want to share some stories about what it was like to build on privacy for end users there's three challenges I mean three challenges three trade-offs and some solutions and tips that I can give you guys the first one is designing for different appetites for privacy in a single app is really hard we came up with features like exporting all your data off via CLI pinning on ipfs Via CLI and also a social recovery flow using web3 auth what seemed like a win for some of our users actually ended up creating a lot of friction for more novice users and the trade-off here was figuring out the information hierarchy like what do you show first what what should you hide what should you abstract away so we use the framework of asking ourselves questions about transparency to deal with this like if we add this feature would it diminish our users Trust if we if we didn't show this modal or if we didn't show this hash would it increase users trust and so we argued endlessly about where do we put the CID for the files that are stored on the filecoin ipfs network do we show that like right in the file browser do we abstract it away we decided to show it like right then and there it looked pretty ugly but it was a way to differentiate our product early on that we weren't trying to recreate like an off-brand Google Drive so those are some trade-offs that we faced when we were designing for different appetites for privacy some solutions that I I mean some recommendations and tips I would give you guys if you're dealing with a similar issue is uh craft for giving user flows meaning that you should expect error that's a clear choice you should also air or in my opinion you should err on the side of showing too much information but show skip buttons and make them dismissable for the folks that are used to it after a while of testing information architecture you're going to see what type of privacy or what type of user is going to emerge out of your app and is best for your specific use case a second challenge that we faced when we were designing um privacy and convenience and transparency is that profiling users and usage is challenging when we're collecting when data collection is limited and at times intentionally vague so in files you could log in with Google GitHub or an ethereum wallet but in our user surveys we would only make it mandatory to ask for one of those so we weren't sure like how many duplicate responses to the user feedback we were getting and on top of that it was sort of difficult to um link returning users from new users another project that this challenge arose was why we were building a dashboard to compare different ethereum consensus clients so we wanted to we wanted to inform the community but at the same time we want to protect the privacy of node operators we ended up limiting geographic information so you couldn't zoom in on the heat map all the way stuff like that and then emphasizing client stats and upgrade information that was a little easier than dealing with end users but it was because the community is a lot more responsive and easy to reach to summarize this point it's sometimes you do things that are ux sacrilege so you're working off of like a huge assumption you're filling in a lot of the blanks yourself or your sample sizes are just really small so the ways that we tried to deal with this is if our sample size is very small try to stay credible by keeping it one-on-one we would talk to a nons async on Discord and telegram not try too hard to focus on like uh you know sometimes people try really hard to get you in a calendly meeting we didn't push for that as much and that created great results for us all right so the last challenge that we faced um when building along this privacy and convenience axis is a bit more high level but albeit I think it's as important you know um raise your hand if you heard that famous quip where web one is like read-only web 2 was read write and web3 is read write own yeah like most to you right so if you're building for the ownership part of read write own I realize that there's this proliferation of choice and affordances that come when you build end user apps like that so in other words like having pseudo rights ownership and data sovereignty it augments the complexity of the interactions within the interfaces between um between the app and the users for example comparing Twitter and nft Marketplace when I go on Twitter I upload my content and then I wait for the dopamine but on an nft Marketplace I do that but I also list tokens I trade [Music] I de-list and migrate ideally or get royalties so that's just an example of how web 2 and web 3 user patterns are starkly different and we probably shouldn't be trying to force them to be the same my recommendation for working on challenges like this when there's greater complexity that is Created from this ownership module is a little counter-intuitive as a designer and a front-end Dev like when you experience a lot of information you want to clean it up and hide it away somewhere but I'd actually advise resisting the oversimplification of the UI it comes from this assumption that the best user experience is the least awareness of software as possible and this is a paradigm that I think that we need to leave behind at least a little bit because simplest Solutions aren't necessarily the most effective or the most efficient when ownership and sovereignty are highly valued by these end users if users own content funds an identity it requires knowing how important that is and how to Steward that which you know a lot of people are working on hence there's also a proliferation of insight generating apps for users today there's this really great essay by Lauren McCarthy she's the creator of p5.js which I love and she says that software is used by many but intelligible by the very few and one great thing from building in a community like this is that there are network effects for blockchain for blockchain technological literacy so as Builders and designers I don't think this means that we should expect that people using these platforms should be as technical as us who are building them but we also don't want to oversimplify to the point of disempowerment and learned helplessness what does it look like in practice make don't trust verify a user pattern and not just a name for a cultural movement so that means like showing people valuable information at helpful moments having humans answer questions having great docs let your uis have dense information but make them collapsible and within reach and yeah keep those routes open for people to verify information so yeah those are some stories that I learned from building um on decentralized apps for the past two years thank you very much good question um are there certain information that you saw from files Etc as far as like verifying not trusting that you think would be good patterns to follow in the rest of the ecosystem as well yeah so we showed things like the content identifiers so people can view the content on an ipfs Gateway which looked a bit scary for end users they didn't like it so what we ended up doing was putting it in an info menu item when you're looking at your files like imagine a Google drive there is an info section and then there's a technical info section um where we tease the CID but we also show the miners so you can see it on an Explorer users understand the value of that or just like okay it's there and I'm good enough at this point um our heat map showed that they would like click on the CID but they didn't click much on the miner and the other stats thank you very much thank you [Applause] next up we have yasik from Nimbus who's going to be talking about the ux that like clients enable and the opportunities there so thank you very much hello everyone from status has introduced um light clients I'd like to start with two little stories it's actually going to tie into to what Cindy was just talking about which is about how users um like to use systems but they don't necessarily understand the fine nuances of what they're doing when they're using them so I was learning about you know networking a few years back maybe 20 years back and it was these were really fun times because um we used to really trust the internet like we were very optimistic about things so we didn't really think about encryption or any of those things however uh tour was coming up as an anonymity solution right and if you were running a tour node you could actually look at all the traffic going through and most funny you could look at all people's passwords when they were logging into their bank accounts their email accounts or whatever they were doing because it was all unencrypted we were in this naive world where um not there were no bad guys right um the other story I'd like to tell is one of status uh where maybe four or five years ago we started trying to build an application that would connect to ethereum and download data and we used to run a guest node inside the status app um this is nuts like it consumed way too much bandwidth nobody wanted to use it their batteries were burning up and so on um so we started a little bit of infrastructure research and we've been going on at it for for a few years and there's really exciting news on this front now after the merge because we've finally gotten what's called an in-client light client protocol so how that works I'm gonna briefly say that um it works by selecting a committee that attests to the fact that a particular block is the most recent history that everybody's agreed to and they include that information in the previous block right so with fairly High certainty post merge now that we have validators that attest to blocks we have a protocol that with a single signature per 12 seconds which is about you know less than your Gmail app users we can actually verify the data that is coming from all third party providers like infuri like Alchemy like whoever else might be providing data to your app so um the way that works I'm not going to talk about it there's a great presentation by Eaton the guy that implemented it actually both in the ethereum specification and then in our client um but the cool part is that with these signatures we actually have the possibility to verify that the data that we're getting from providers is the data that everybody agreed on what does that mean well it means that suddenly um the way we used to operate in web 2 was that we would trust our provider of data we'll trust Google we would trust our bank we would trust whoever was there and why did we do that because we had a legal recourse to sue them if they did something wrong uh the systems that we're building today we're kind of like interacting with randos on the internet and Randall's out on the internet they might be like me like 20 years ago that was like just looking at the passwords and being very amused by the naivety of people using those systems and thinking that they were Anonymous and safe right as Torres was presented at the time um so um what that does is that it create a model in which data providers are no longer have to be trusted what does that protect against well many things inferior for example most of us know it alchemy most of us know it pocket Network most of us know it what we do is that we ask them for our balance we ask them for the state of our nft whatever we asked them to create a transaction on our behalf and submit it to the network and we hope that it's all kind of fine submitting a transaction we sign it so they cannot manipulate the transaction but they can manipulate the inputs to the transaction they can give us a false balance they can say that um the nft belongs to you when in fact somebody uh stole it on the way to you the one that sold it to you maybe right so with the lifetime protocol we can suddenly create user interfaces that can verify all the data that we get from all our providers and then we no longer have to trust them to provide correct data and what does this enable well on mobile phones wallets that verify data suddenly become feasible they use less bandwidth than you know anything else out there that you have ticking all the time um we can create smart contracts which understand that the consensus of another chain has landed at a particular block and therefore Bridges become more secure we can create is there a knowledge proof of all the past history of this consensus and with a single small verification similar to Mina we can again verify that everybody's agreed on a particular state so um if I was doing my experiment today on Tor I would notice that everybody uses https right everybody uses SSL everybody encrypts the traffic there are no more email providers that allow you to log in without a secure connection and I would argue that six months from now there will not be a single wallet out there that does not verify the stuff that you're getting from your data provider using the light client protocol and that's the world that I want to see so if anybody is working on wallets if anybody's working on any kind of tooling join me I'll be happy to explain the protocol we have libraries available that you can just include in your application that allow you to add this functionality like at minimum cost if you're a user we have a proxy so that you can run this little mini node in your like home setup it uses almost no bandwidth and what it does it sits between say metamask and and and you're inferior and when your metamask makes requests it verifies all those uh all that information that is getting from infuria using the like line protocol and it will block any data that is not valid according to the consensus that everybody's agreed upon so how does that change the role of inferior in that ecosystem at that point so are you still relying on inferior first so what we're relying on inferior for is that they become like a static data provider so they still analyze the chain they run they run the node for you and so on and when we ask for data they give you the balance for example and they give you a cryptographic proof of how they came to that conclusion that your balance is 5 8 or whatever it is right and with that proof we can compare it to La the latest State as we know it from the consensus protocol uh and then if the proof checks out we know that they are giving us correct data so they're still very valuable in that model right yeah they're still very valuable because this is basically the lowest bandwidth way to get data available today I'm saying today because we're also working on another project where the data itself where you can swap out um infuro for a decentralized range of servers that will be providing those data points but even in that solution you don't know if the data you would be getting from from the network would be true so you're talking about the same kind of validation are you talking about portal Network at this point that's the portal Network and we have a client called fluffy for it so this is like one step on a long journey uh the most important one arguably it's taken us four years to get here um there are many steps Beyond this but really um run the proxy if you're using a balance if you're using metamask or anything if you're developing a wallet or any kind of service that interacts with ethereum and uses like a third-party data provider check out our light client work so quick question from a user perspective how do you convince people that they now would benefit from running some of these services and as we know from past experiences that once people get into a habit of relying on third-party intermediaries it's really hard to convince them to now take on more responsibility so what do you think as a community like what kind of education or work we need to do for people to realize like this would be a good value add for everyone to be running on their own devices uh I think the the main message here is that they don't have to be running everything on their own devices like thanks to these thanks to the light client upgrade that is part of the ethereum merge protocol um we can provide something that is lightweight enough that the third party providers become just data stores like a hard drive basically um and the journey is the same Journey that we did from unencrypted internet to encrypted internet right now everybody expects a little icon that um you know their connection is safe and and the certificate is valid and blah blah blah I imagine that a wallet would want to show that it's validated um the data coming from the provider using a Lifeline solution like this in a similar fashion okay perfect right it's it's exactly the same journey and we have to educate people that don't do this it's unsafe like a hacker might hack infurah and even if inferior is good the data coming out of it is bad right all right thank you very much so next up we have James from prylabs now I guess arbitrum congratulations on the acquisition to talk about improving ethereum staking and adoption oh it's sorry um can he slides anything yeah I can just stand up you sit down if you wanted no issues all right hello everyone I'm James I work on the prism uh consensus client and uh recently I've completed my first year and then through this first year what an amazing year I I was able to participate in the Altair hard Fork the merge and also the company being acquired so now joining off chain so during the process of these hard forks I was able to interact with a lot of our users and notice there's some areas that could increase adoption in ethereum staking so today I'm just going to go over a couple of these areas that I have some opinion on and then shed some light in uh the staking infrastructure in general so the first opportunity I see is around service management and it's as as we're growing in this staking Community there's all these other tools that you can add in but connecting these and enabling these for our users might not necessarily be in the protocol specs so designing the consensus clients we follow these protocol specs defined by the ethereum foundation however there's plenty of other things that aren't defined in those specs and client teams have a lot of Lee leeway so one example is when I first started prism was the only client with a UI all other clients did not have UI capabilities and they did not have apis to allow management of their keys so myself and a handful of consensus devs got together and created the key manager API so standard which is not actually part of the protocol spec um and this enabled all client teams now to uh have their own UI because now there's a rest API in front of the validator client uh so that's just one example but as we continue to grow um now there's um plug-ins like web3 signer for remote signing if you don't want to include your validator keys in the validator itself and in the validator client itself then you can use this third-party tool called web3 signer and uh prism supports that I believe most of the client teams support that but that again is not part of the protocol spec um as as we continue to grow I'm sure all of you have heard of Mev and um all the different tools that are being created over there as we migrate to a full PBS we do need Community Support like what do we need to add as integration into the system um and also with withdrawals coming so uh there's a lot of different areas where um plug-ins can be attached to these clients and uh it's sort of not part of the protocol spec so we need some feedback from the community so with more and more services being built and pieced together there are a lot of opportunities to align the user experience even if it's not part of the protocol spec the next um topic that I wanted to talk about was improving the user Journey for entering test Nets I think that's an area that we could really improve as uh right now you need to get your Gorly eth through Discord or social media or like really sketchy sites or just connections with with certain people this makes institutional adoption very difficult um and uh at a company like JPMorgan or um these uh these Banks or uh even um like Google uh it's difficult to connect to these other social media apps in order to get the the test net eth that you need in order to participate and and so typically um at your traditional tech company you would go through your local develop the software on your local move to a Dev space move to a test space and then into production if you're working on staking or developing in the defy space and you want to run your own node it should work in a similar fashion I've heard people try to do a deposit contract and then just directly go into mainnet without any experience in staking at all so um it's really important to try to increase this adoption um uh so all in all this is a call to action to developers there are a lot of opportunities in this ecosystem um without knowing Premier knowledge on cryptography for Choice consensus knowledge of how the evm works so there's a lot of opportunities just in how these microservices or Services interact with each other and helping the community create better standards and result in a better user experience thank you very much thank you so I had a few questions touching on some of the points that you kind of raised the first one was around like the the the standardization work that you guys did for the key manager stuff what were the challenges there how did you guys actually get the community because I know on the back end we try to create a lot of Discord channels have those conversations then eventually you and Michael were able to kind of push it through what was that Journey like and how do you see that repeating in the future in like different areas that you're kind of highlighted now yeah that was that was pretty amazing um we were actually trying to push that through through the East Staker community um so uh consensus teams all core devs are very um are on a very tight schedule they want to get the protocols done so these things usually fall on the Wayside and actually um dap lion so I'm calling out load start uh Team uh was the first one to take initiative uh create that PR and ask the community whether or not we could include this so he actually went to the beacon API specs and created a PR took that initiative and got the ball rolling now the next step is people reviewed it they had comments on it um but it that wasn't enough to get all the client teams aligned together so that took um some more uh social engineering a lot of trying to reach out to one person connect to the next person and get everyone together so a lot of help from the East Staker Community to try to push this through we needed a UI for other um clients and and that really enabled uh tools like dap node or avado or these um uh staking tools for people that are not as technical um and uh really drove that forward yeah so I think the other question is now that the merges happened and maybe there's some more capacity available in these teams is this something that the client teams maybe other client teams can weigh in this as well as like is some of this becoming more of a priority for or resource allocation being put towards this or not really I'll take that as a no so like how do we how do we move those conversations forward I'd be curious to kind of hear from all the client teams and see like what does that look like who's responsible like how do you create a community and a forcing factor for some of this thinking to happen as a whole wow that's that's why I wanted to do the stock in the first place to try to get a call to action to developers as we um move from the merge to The Surge now um client teams will be even more focused on protocol level decisions so the next three things uh censorship resistance with uh Mev um scalability with eip4844 and withdrawals so client teams are pretty much very focused on that and the continuing development around Fork choice and protocol level design so it's very important that we get more feedback more develop developer interest in the user experience we don't want to leave people behind we want to increase adoption so that kind of like perfectly segues into Landscapes talk from that node where their challenges they're facing as far as like integrating some of these clients in the first place into their services and the front end that they've built out which is amazing as far as like just running these services in a preview terrific configure device or application as a stance you can just connect here if you wish and this is we were also supposed to have Adrian from lighthousecom but he might have to join because he has a session right now actually happening so perhaps we'll do a quick lighting plot from him after lunch if he is able to join but aside from that I'd be curious to get some of the the individuals working on the front end to have a discussion on like what we can do to move some of this stuff forward as well all right all right thank you James um I think this was a this is a great great summary of um uh of what we're doing as Community from the community side as integrators that we need to uh make the ux easier for for them for the users right so that node um very briefly we we help people run nodes we help people run validators or nodes or anything you want um by providing these free open source software that you can install in any machine and it'll turn it into well it's actually Linux and it's Docker based and any machine that you install is in it'll give you this set of tools to manage nodes uh in a like in a super easy way right so you would go here and you decide that you want to install like a pocket network node or a nimbus or whatever it is and dab node has been a really good solution lately for um for those who want to validate and uh and they maybe they don't have the technical knowledge right so we we are really in touch with the users that do not want to spend hours on devops we're just doing the calculations the other day and uh Geth rolled out 16 releases in the last 12 months prism was 20 releases in in the last 12 months um that's that's uh that's something that if you're a validator if you're a solo Staker and you want to test those as James was saying we need please do test those in testnet before um uh you would need a couple of hours for for each of these to test each of these uh new releases right that's 72 hours a year on testing on on testing and deploying um the the new versions of the nodes so there's there's a lot that that note does in the integration side that it just works it has auto updates um people don't do not have to worry about this at all because the way it works um uh all these packages are actually in an ethereum smart contract which is the repository that's the Aragon package manager um and the the contents the docker images are distributed through ipfs so ipf has that note has an ipfs node inside and it also has an ethereum node inside so you're actually never calling home you're using nodes in your machine um to to take the and to get the the content to download to know what the content is available and to get this content into your computer okay so um back to the story that James was saying um we're trying to make it super easy for for people to stake with no technical knowledge right and one of the problems that we had was that there was only one client with a UI which was prism um and we that Lion at that moment was already working on load sir but he was a he was already he was also working a dab node so actually I was I was very involved on uh on kicking kicking off this initiative of the key manager API because it's something that we needed for that note we needed the key manager API so people so we could have client diversity in dub note um right now do we have World well um I'm not gonna go on this story uh any longer we'll see the the UI later um there's still a lot of problems like dapno itself has is not free of its own problems and when you um when you try to validate with that node you'll find that you need to you need a lot of previous knowledge you know a lot of reading up but you need to know you need to know that you you don't what is a note a note has changed the definition of a node has changed now you need an execution layer and you need a consensus layer and you need both and then you need a validator client and then if you want to manage the keys you need which is what we do in in that note and you need this UI to to input and output the keys you will need a UI for this and how do you find those packages in here there's taku there's Lighthouse nurses but there's also Lighthouse there's numbers there's numbers there's take a pratter there's SSV product it's like it's it's chaotic it's like okay we need to guide the users better so that's what we are working on right now that's what we did which is so it looks like okay because it's it's not beautiful but it's very functional and it guides the user to do whatever it needs to do it says Hey choose an execution client and you can choose on this three hey choose a consensus client hey and it'll choose this one or these four um it's funny because uh top lion has been working on dabnode for most of his career and guess which consensus client is not in tab node lodestar lion get your together come on um then the web designer which maintains the keys and this is a really key ux Improvement that the fact that the keys are in the web designer because now you can thanks to the checkpoint seeing by the way really good work client implementers um things in the checkpoint thing you can just literally go here change this apply changes now we have switched the configuration to take one notes it will download taku and thanks to the checkpoint sync you'll be validating in like two minutes you'll be online and validating in two minutes there's literally no switch another thing is that you cannot it's another thing that we need to manage in the background for the user is the fact that you cannot have two consensus clients pointing at the same execution client so we take care of turning it off we took it we take care of all the these little edge cases and little things to make it super simple for the user um so now let's look at the keys why are the keys in the in the web designer the keys are in the web designer so when I change this I don't need to take the keys out of one package uh remove them change download the other put the keys in there and then start validating this is a recipe for disaster you if you forget that your keys were in the other client double signing slash not a good idea so the keys are in the web designer and what happened with the key manager API what's being used for is this this is so there's not a lot of front-end people in that note okay you can tell um and definitely no designers so please give us a hand this is open source we are officially maintaining this piece that everybody can use um but these key manager UI which uses the key manager API um it's really an open source that anybody can use it now if you guys want to make it more beautiful please do so we're trying to integrate some stuff right now um like uh that each validator key will have its own uh withdrawal withdrawal so few recipients sorry not withdrawal fee recipient because that's something that as we as we have seen in here you choose ads so in that note because of the way it works and because we try to not to make it super complicated um it it when you configure it uses pass the value of the few recipient address and that's all of the keys go there so this UI where you have the list of keys sorry I could have put some some fake Keys here wow but it doesn't have this it doesn't have this and why doesn't it have this because there's no standard there's no standard for changing this so right now if we want to do it we need to create any a specific implementation per each client using whatever system that each client has on how to change the validator so the prcbn for each validator key so this is one of the things that we are going to be pushing just like we push for the key manager API this is one of the things that we're going to push in standardization guys standardization is key I understand that the the consensus teams are super busy and the work that you're doing is  incredible um and wasting time on coordination might seem like yeah like a waste of time but then it will have to to be done later somebody you're just kicking the bucket right like it will have to be done um by somebody later on and there's literally nobody better than you to decide on a simple way of doing it so we're going to be pushing for this um uh in the next or in the next round we're gonna do something similar than what we did with the key manager UI intake manager API um but then there's going to be something else there's going to be another thing that needs to be integrated there's going to be another thing that makes it that makes life easier for the users so I would I would hope that initiatives like this get us all together in a room and see like hey what what problems are we having what problems are we having and one side one pro one what problem are we having super Downstream on the integration side what problems are we having up there on the coordination right what problems are we having at a design level process um and yeah I just want to thank Akil for for bringing us all together thank you very much [Applause] yeah so I think we've seen there's two opportunities for Clear working groups to happen one is the wallet one one is probably client team integration and standardization Adrian did have some ideas around standardization that he wanted to push as well so I think maybe even if he can't get it in person maybe I'll create a back Channel communication to just kick start some of this stuff but beyond that I think some people might want to have other conversations that are in the room that we might have not given too much priority towards so before we just go to off to lunch if anyone just wants to come up ask any questions or wants to just do like an open mic session about some other issues that they are very passionate about would love to kind of give you guys the opportunity because we were a bit behind schedule so I didn't give opportunities for people to ask questions from all the different speakers so if you do have any questions or any other things that you want to add this would be a great time and then aside from that I think we can go for lunch and then kind of break on into groups and maybe if Adrian comes back we give them another 10 minutes to propose this standardization stuff and kind of take it from there and if you guys have any other friends or other individuals that you think might be useful for those working groups please do invite them after lunch and then we can kind of kick off from there so thank you very much I think you had some questions yeah just take a mic yeah that'd be amazing so I think lunch starts at 12 30 we can come back in here at one half an hour should be sufficient enough and uh kind of get started from then thank you for hosting and thank you for um speaking everybody um I had a question about improving the accessibility of um staking very much along the lines of what James has been talking about um you know I think I could convince my mom to try and create a wallet like a metamask wallet um on Chrome um I don't think I could convince her to uh wrap her head around the complexities of uh you know what is a node what how do you define a node how do you think about it node she's not a very technical person she's capable of downloading an app and maybe creating a wallet um what I've been thinking about a lot is how close are we to getting to a point where somebody completely non-technical could in two steps you know download an app deposit Eve and run a node and then maybe under the hood whatever solution that is could just roll a dice choose a client choose elcl automatically maybe create or yeah I don't know I guess the main question is how do we get to a point where um where it's as simple as one two uh how far away are we from that I know standardization is a big part of that but maybe even without standardization it would be possible and some assumptions could be made that could be tested and then that testing could influence standardization sort of in a backwards backwards way so what are your thoughts on that I'm addressing it to you because you were talking about a lot of this stuff but anyone feel free to love to to take this um I would like to ask you the question why would you think your mother or someone that is not so technical would want to invest 32 either in the first place and stake or should be staking so are you thinking about it from a participation perspective and then is it is running a node more important than staking so I wanted to kind of create that distinction yeah I'm kind of bundling the run and node stake Ethans into a single bucket and thinking about how do we pull that activity along the technology adoption curve by making it so simple that you don't need to understand uh technical terminology but you do want to participate in decentralizing digital economy like you philosophically or maybe your values are aligned but your knowledge and your technical familiarity is the the limiting factor so assuming that you have values that align but not technical familiarity I feel like there's a lot of people in that group that are being prevented from from uh from participating makes sense yes I just want to clarify that's like usually a misconception within the ecosystem as well as like you can run a node without having to validate or I mean stake so like that education is missing in the ecosystem quite a bit as well and then like the complications around like staking and what is actually required for you to understand that like distributed validator Technologies are coming out where your mother can pull with all their friends Etc so like that might make it easier but from the front-end perspective you can probably touch a little bit on that and then I have a bit of context from what's being done on status what's been done on Lighthouse as far as like getting this stuff uh moving forward a little bit so I can probably touch a little bit on that as well awesome love to hear your thoughts thank you so yeah this there's um so this is this is a little bit what we're trying to do um and we're definitely not there but what do you have seen now where you have to choose all of this um well let me start from the beginning like the we can take an approach of like free open source software but that's not the approach that's gonna get us this Mass adoption right because then you need a Linux installation you need like this all this sort of stuff that it doesn't that will not make it happen that will just people will not do that so what we're doing as well um we're selling Hardware we're selling Hardware that comes pre-installed and you just plug and play you plug it to your router uh you turn it on either it's a hotspot and then you can connect and configure your VP your VPN and then you can go you can enter and access this machine which is effectively a server that lives in your kitchen but we didn't we didn't call it a server because that's scary we call it your dap node home and um and yeah you can access from wherever you want so these machine first of all the first hurdle is that that's a different mentality that's that's not a free open source mentality of like I'm gonna hack a node I'm like that changes it's like I buy this machine and I expect to have a return from it and here's the this links very well with what you were saying about you can run a node without validation but that's not going to happen that's not going to happen we've been written up note since 2017 we've been trying to get people to run nodes and we only got big download only got users non-technical users um when there was incentives to run this note when there was money on the line when there was a way of doing this so now we have this first step where people are have to buy something because they don't have the the the the experience of like of like how to install Linux whatever people have to buy something and then there's the incentives and they if they buy something what's their expectation there's an expectation of return and then then it just becomes easy on the implementation because what you have seen what I was showing on dab node is three call this this column like thing or you got to choose your execution client you got to choose your consensus line this we could have like an API that says that automatically chooses whatever combination is the least used so this is great for client diversity and you just press a button and everything and it tells you like okay this is put here your free recipient address and everything else is deployed for you and that would be like that would be extremely simple right um so in DAV node we're thinking about doing that and then having the advanced mode is like you choose yourself um but then there's like a set of constraints of like what we want to do in Davenport as well maybe somebody else like a competitor that's less um focused on under centralization because we don't want to be calling any apis like we what do you have on your machine is yours and you never go home there's no Telemetry um so so that's a different issue but whatever yeah it's uh it would be very simple to do something like that and it could be done like tomorrow yeah yeah so I think the other perspective is that the experiences are quite distinct and separated as far as like the utility of the network and the services people are using so the way that like status is looking at it is like if you're running your nodes for messaging or all these other services now you have a utility or a factor for not bunching in your ethereum clients there as well so now you have this like whole Vision or like this window into web3 that we were kind of like promised with the the miss browser where you have the ability to control all your web3 services and then it just makes a little bit more sense for users to say okay now I want to run without even having like monetary incentives to now start running services that they see like okay I'm running my ipfs node maybe I start running an ethereum node as well because I'll be secure and I'll have more utility around the services I'm using and now if I'm already bought into this whole like web3 Vision it just becomes a little bit easier and palatable to utilize but because you do have this like front-end layer for messaging you have all these wallets everything kind of built into that status infrastructure it just becomes a little bit easier to not just plug in an ethereum client there as well so I think there's two layers it's like do people comprehend their whole vision of web3 and how that comes together and then the other one is like how do you incentivize individuals to run that infrastructure structure without it being staking so like if you're looking at individuals in Bogota or looking at individuals in India or looking at individuals in Africa for them to actually run those nodes and then decentralize the ecosystem further and maybe there is some sort of like incentive mechanism that we can come up with where they're benefiting without having to put out their cash which is 33 there is too much for them even if they do like distributed validated technology if they're providing a service to the network perhaps there is some sort of incentivization that kind of is given to them at that point in the in the long term of like okay we decentralized the ecosystem not to just Europe and America at that point so I think there's a lot of thinking that needs to be done from like the protocol level or just from the community like funding mechanism perspective there as well so it was interesting to see like how we start thinking about these problems over the next few coming years now that the proof of stake ecosystem is kind of developing and it'd be exciting to kind of have thinkers like you guys come up with ideas and experiment and evangelize as well so thank you very much