AllWalletDevs #12
AllWalletDevs · May 2023 · 30:12
Call 12 of AllWalletDevs, held in May 2023. Wallet developers meet to coordinate on the Ethereum standards and protocol changes that affect their products.
Topics
From AllWalletDevs, hosted by ECH Institute.
Transcript
foreign so I'm going to kick off wallet devs number 12. I guess that means this has been a year of doing that this which is pretty impressive um thanks everybody who's come out to these I really appreciate it um yeah so I'm just going to jump into a demo of wallet test framework um Nikki and I have been building this for um a couple weeks now and uh yeah we'll just just want to show you where we're at so let's see if this works window all right is that uh is that working yes
perfect okay so as you can probably tell neither of us are front-end developers so if anybody wants to come along and make this look like you know a real application that might be nice but it works so um this is kind of the uh the layout of the the testing application on the left we have the test results that uses mocha um in the middle we have a section to input events uh that your wallet is displayed and then on the right we have instructions for the user to follow to you know interact with prompts in the wallet uh so this is called the manual glue and the idea is that down the road uh each wallet can Implement their own automated glue so you don't have to type this
stuff manually uh but for now it's manual so right now we have a um add a 3M chain request so you click the add ethereum chain request button and uh you fill it out so this is four five nine five zero it is named this and we have this RPC URL and if anybody has any questions feel free to jump in while I'm doing this why are you copying from that little pop-up window so this is my metamask so I'm taking what it's showing me and I'm telling the test framework what the wallet is asking
I see and that's the idea here is this is your um it will verify that's what it expected exactly and then now it's giving me an instruction here what to do with this pop-up it's saying uh you know approve this request okay I can do that and of course during the demo it doesn't work I did this literally two minutes ago yeah let's let's try this again ah it might be just that it took too long on this but uh three nine four there so
um no idea what happened there definitely something to look into but on the left we have our results um so this is actually going through and running uh against mocha in the background or sorry against uh ganache in the background and uh yeah the requests are proxied from metamask or from the DAP this page into metamask through a back-end server that's running on Heroku right now and then back into this webpage back into this web page so there's no surface-side component really no um well at least no no heavy processing on the server you can run this as part of say a GitHub build there's an npm package that you can follow along with and we release updates every two weeks on wtf.allwallet dev dot or all wallet.dev
and the links in the testing Channel if anybody's curious so that's about it on uh wallet test framework any uh any questions yeah go for it so let's start with uh Bumble fudge if you have your hand up there sorry mistake I was just clapping no questions okay cool yeah so uh I'm wondering when you're making those calls which I are you comparing them against some outputs that you expect and you have some kind of documentation that what is what you are like expecting please is I think for some of those
costs the different ethereum nodes are producing bit different outputs and I was wondering what is the correct one so we are testing against ganache so whatever ganache outputs is considered the correct output but if there's ever any ambiguity so far we've tested uh frame wallet and metamask and so far they handle ganache fairly well uh but if there's ever ever any ambiguity we'll we'll bring it up in the channel to figure out what the correct thing is I would do much is written right away so I'm going to modify those requests but if there's a modern node they would reply differently Okay so
would you I guess the the option there would be to specify a different um test change or run against well really if you not know what kind of block you're going to produce then you can check all the kind of the fields that they should match to that block and then no matter what what node you are connected it should always check against those but the problem is that there's no standard on what those requests should produce so can you maybe have to come up with request and kind of Define what is the standard since that doesn't exist um yeah we can definitely look into that uh right now I think we're just looking for uh some kind of a test suite and we
aren't experts in you know node RPC or in how wallets are supposed to handle these things so we're just going with the one implementation but if if there is a comprehensive dog like Doc or spec on this stuff or somebody writes one we will absolutely follow it I think at the moment the standard is what metamask is doing and every everyone is just coping that foreign oh sorry I was gonna I was just gonna say that I I if if your question is about the like ethereum execution API like what the node should return for each um
uh function I I think that the place to look like that there is a group uh in ethereum land working on this and it's the the open RPC guys and I think there are a few little discrepancies like uh different maximum values or one returns a float one returns an integer those little things like I if that's what you're asking about I would say um maybe uh figure out who those people are I only have one name and I'd have to look it up I don't know I can't remember off the top of my head but um it but it sounds like maybe you're talking about a different discrepancy or or standard execution
RPC request if you make RPS he requests to different notes they are returning a bit differently and then when you're making also some of the wallet calls they also kind of even wanted to be a bit differently and some documentations also say about some things but then that must behave differently for example yeah I think I think metamask is trying to align over time I don't know what the like road map is I haven't heard like a firm commitment like next major version or anything like that but I think that the the metamask team is already talking to the execution API open RPC people about little discrepancies between like how it's written in the EIP and how metamask handles the wallet namespace
functions but the node functions I think there's no one else to coordinate with like the the the the go team and and the different node teams are already pretty closely you know aware of these discrepancies and working on them as far as I know I can't speak for work I'm not doing but do you know if there's documentation like how they should be or is that they're just trying to kind of really without documentation oh no uh sorry the I shared the link in the jitsi chat to oh wait no that's the playground but um I'll try to find it on GitHub somewhere there's the there's a giant um you know it's like a
sorry uh I I bet I'll leave for two months I don't remember any proper names or technical terms um they there's like a like a Swagger dock for the execution apis um you know are you talking about the execution apis Repository yeah I think it's either there or in the repo elsewhere that serves the link that generates the houses the link I shared but one or the other I think the execution apis do have a pretty precise specified expectation for each note yeah that's the one so keep in mind yeah keep in mind with that one it is under development and at
the moment it is just a copy of what guest does it is not actually a standard that is followed right basically just it's a starting point for a specification but I'm not an actual specification yet so I guess to to specifically answer your question uh from earlier uh if someone gives us an authoritative spec that we can verify against we will use that go on does this tool require that you connect to ganache on the back end or can you use any RPC provider like Netherlands
running on mainnet uh so because of the way that the tests work where you know you have to generate a block on demand or or those kind of things it won't run on maintenance um and it does use the like back-end RPC that ganache supports for like minor block now or um you know transfer funds from this account to that account um so that that is um using the gadash back end but any any API provider that supports that additional back uh like RPC endpoints will work yeah Victor that's kind of yeah exactly
um yeah uh whoever just raised their hand I can't see your name um yeah really cool demo Sam I'm wondering if there are any tests for um that are in interactive tests or if they're if you're planning on doing interactive tests as well oh yeah it's just we haven't written them yet so yeah so we just finished the glue uh about two weeks ago so now we can actually you know pop up dialogues and stuff um so now we can start writing interactive tasks tests like let's say sign message or um send transaction cool great work thanks all right so if um
there aren't any other comments or questions on wallet test framework um I'd like to mention Eep 6963 um that's the Pedro's proposal for a new wallet Discovery mechanism if Pedro is here and they'd like to talk about it um please do if not uh links in the Discord and you can follow along there all right I don't see Pedro uh I know that this is a hard time for him in his time zone if he's back home
um but uh yeah I have worked with him on it a little bit so I I could maybe uh answer a few very easy questions on his behalf laughs can you give a short overview of how it works or I mean I can do that too if you want uh your your overview would probably be better aforementioned uh month into leave don't remember anything yeah so um instead of injecting window.otherium into every page um this uses uh an event style interface um on the window object to inform the
application that wallets exist um it still requires injecting into the page but it does support multiple wallet providers so that's definitely an improvement that's about all I know about it so definitely take a look at uh eip6963 if you're curious yeah I would I would maybe add that the the main problem this solves is um different while it's overwriting or race conditioning for the windowed out ethereum like it the the sort of lack of a namespace to allow multiple to coexist
I think was the driver um and there's a a couple other there's like a a an older not much older a few months uh older EIP by the second author listed I don't know how to pronounce this as his or her name but I think it's kasala himachandra um there's a I can't remember the number outside my head but I'll look it up and put it in the chat uh yeah exactly from encrypt um so this and that are similar so yeah exactly thanks everyone um so uh that um
had a few little differences and there's been a big group chat for a few months hashing them out and I think uh kasala wanted to co-author this one because they have a lot in common and it's sort of a let's propose both and see what the market prefers kind of thing um so yeah that's um Maybe useful context for people just hearing about it now I'll I'll get some links going here great thanks so much
um I think that's a great uh segue into the next topic here which is um shadow um or draft pre-draft EIP 7039 which is using a custom scheme handlers to accomplish the exact same thing as 6963 um Link in the agenda um I've been talking about this for a while uh if you aren't aware of the upsides and downsides of this proposal um let me know now but it's very very similar just uses a slightly different method to connect to to wallets um yeah so if you want to read that one and take a look at it I'd appreciate it thanks what's the EIP number again of yours uh
this is I just put it up earlier today so it's pull request 7039 thanks yeah and and it uses um register protocol Handler API uh so the same thing that lets websites handle mail to links and they manager that is um it uses the browser's native UI for choosing between wallets um it leaks very little information if you uh don't approve a connection you can't even tell a wallet is installed and web extensions there's no additional permissions required Beyond um well there are just no additional permissions required
can you remind me Sam why I don't like this yes um on Chrome it's uh it only so like there's no easy UI that one doesn't bother me home users can have one wallet I'm fine with that something else though you didn't like the the webrtc stuff but that's all removed now it's just post message now [Music] um I thought there was I thought we couldn't figure out a way to make it actually initiate the full connection right right so now it just uses post message the like the the so it doesn't
work with desktop we figured this out so if a desktop app hosts a page on localhost um so like the the app has a button you click on and then it opens a page in in your browser you can click a button there to register a protocol Handler that uses the native application okay and uh for mobile extension in the extension yeah it's it just you can register them as an extension so sorry but if let's say you just install extension you don't have a local app you can't host anything at localhost you can't serve files in fact um you can use a Content page I forget it's it's in one of the options in the
Manifest and uh you're allowed registering that as a protocol Handler oh interesting I see yep and then for mobile how would that work in theory it wouldn't yeah so a mobile wallet could you like you you could go to let's say you know um my wallet.com click a button and it would register my wallet.com as a Handler and then proxy to your mobile wallet but yeah it's not exactly smooth okay maybe I maybe I don't hate it High Praise yeah thought process and um like some of the advantages that
um that it might have over 69 63. so wallets no longer have to inject like any content scripts into the page they require no permission to to view or modify Pages which I think is a huge Plus for me um on scene browsers it supports multiple wallets at the same time um and on last scene wallets like Chrome um it's not hard to implement a dialog that lets you choose between the two handlers so that I think has an equally likely chance it's externally connectable and it's a whole other story but suffice it to say it's not impossible to get this feature into Chrome pretty easily um and yeah it works fairly well for
um mobile and desktop wallets as well thanks and once used to verify once you have that see a scheme Handler cause you to open a page once you have that page open you can do bi-directional communication with that page is that correct yes so in the discussion thread for that uh yep exactly so you do like iframe dot content window dot post message to communicate in yeah and so it was right now yeah who's right
in the standard for it uh like for the protocol or this this whole thing yeah yeah me okay I support this uh but by by the scheme do you you mean like the the syntax of the Uris that would start with I don't know a theory of colon slash slash is that what exactly yep so you'd make an iframe it would look like iframe SRC equals like something like that or anything
sir could you say again did you build prototype for those wallets that can utilize this yes I remember someone's got a very loud keyboard in my life that's me sorry sorry I remember why I don't like this because we have decided on what the scheme name is and we'll be stuck here for three or four years at least let's go with Bitcoin that's already approved let's just use that surely that will reduce contention
it's equally bad for everyone Wise Choice but yeah we like we can choose anything I don't care um web3 is technically registered as a Ina scheme that we could use we could also go and register ethereum I don't care I remember somebody objected to ethereum because this also works for optimism and other chains so I just went with evm but yeah it's really just bike shedding all right so if there's nothing else to talk about on that and I'm sorry
prototypes sure I will link them one second and and they are like very bare prototypes um they just show that you can yeah just proof of Concepts yep I think no perfect thanks I've learned a lot of uh typescript in JavaScript since then so forgive how
absolutely terrible they are they look like just JavaScript where's the typescript oh I didn't say I wrote them in typescript I've just learned typescript since then this way you apologizing for how terrible they are yes exactly yeah all right so um anything else on this otherwise if not I will hand it over to Victor to talk about all ERC devs you might be muted Victor there you go
okay yeah I was waiting if someone want to speak about other things but yeah thank you uh thanks Sam for the opportunity just want to quickly share uh there's a new initiative that we're trying to bring up uh which is called ERC deaf uh this is a web play of all core deaf or a lot of deaf uh thanks for all the um uh predecessors and um we want to bring this period where um they lack the a place for ERC authors and developers to come together and discuss and hence this is a way to do it of course you can do forums but uh having a synchronized way you can be
more efficient we just run yesterday and we're trying to have one session and uh it was great to ERC authors come and share and then other people give feedback and and what's particularly relevant to this um group I think is that most wallets are meant to be used for assigning content uh transactions and interact with small contracts so um if you want to give get to know what's latest updates and ERC authoring and drafts um come and learn about it and we definitely appreciate your feedback and comments and Technical reviews uh from your perspective as audit as well at
deaf so um come here I will share the link and wish to have to see you here as well um thanks for the opportunity to bring this before you and uh speaking as an EIP editor I very much appreciate somebody trying to coordinate the all those cats that need hurting yeah and wish that becomes a way to even boost the effort uh that you're putting forward for uh for the work group or rings of peer reviews perfect so links in the chat you can
also find it in the Discord and I think you also wanted to talk about ERC 5269 yeah I was I heard someone uh proposing uh uh yeah ERC eips that helped detecting wallets um I am also I think it would be your interest to see um this efforts trying to have a modernized uh a better way to detect an erc's uh before that you probably know that there's EIP 155 but as we learned that that is very limited so I'm trying to put up a new standard which is called erc5269 trying to detect and discover ercs by emitting proper events and then
make new assumptions for example in EIP 165 sorry in the ip165 you basically will learn that this is the inter the functions that it dispose we anticipate in the future with the uh design pattern of proxy design pattern of diamonds you will see a small contract exposing different functionalities to different wallets to different accounts and uh that's why we uh take that into account and in in the in the detection we actually expose a a parameter to specify which color is calling and then it will return
um EIP status um of that particular EIP and then we also allow major EIP identifier and minor EIP identifier where major at the API identifier will be the numbers to make it easier to identify and then the minor ones will actually be you can include different functionalities for eips um so I'm happy to um have uh share more in all ERC devs and if you're interested and learn about this um please come over and uh and um yeah thank you and your feedback is greatly appreciated I know this is trying to be a draft right now it is still a review status right now trying to take it slow and hopefully make it finalized in a good state
thank you so this is for ERC 165 right yeah sort of yeah competing yeah or trying to be a better version cool I can see that being pretty useful especially for things like openc or whatever try to discover stuff about nfts um yeah that's awesome yeah thanks all right uh so I think that is the last scheduled item we have um so now we have time for any demos if
wallets want to show off any cool new features they've been working on um and if we don't have any of that just some general discussion cool well then uh I guess we're officially done for today thanks everybody for coming out we'll see you all next month awesome thank you