AllWalletDevs #15

Transcript

there all right so welcome to all wallet devs number 15. um sorry I missed the last one uh today we're going to be talking about some updates from wallet test framework and we have a presentation about the injected wallet registry proposal um and then we'll have time for whatever else afterwards so first up is an update from wallet testing framework if you haven't been following along and if you haven't shame on you it's a testing framework for wallets designed to do n10 testing from the perspective of a Dap we have about 62 tests right now and we just finished our first round of trying it out with different wallets

um so I'm going to share those results and talk a little bit about them I want to make it very clear that this isn't like uh you know me criticizing your wallet it's equally likely that the test is broken um and similarly it's not me endorsing a wallet because I have no idea what I'm doing um so without further discussion let me show you what the results are yeah once I find the button there it is all right so uh this is a very manual process so we went through and tested uh these wallets here uh so we have Brave Tahoe frame encrypt coinbase metamask okx token pocket and a bunch of ones

that couldn't connect um yeah so on the top we have Bray wallet and uh taleho or Tahoe um I guess they changed their name um you guys passed every test we have so good job um again not really endorsing you it's just cool that we weren't even using you until a few weeks ago and everything passed uh we have been developing with frame and they have everything working except sign transaction um encrypt also has uh a really decent score but has some problems with not displaying enough information to fill in the the boxes that the tests require so that's in the notes so coinbase also did exceptionally well just a few

problems with hex prefixes missing so no zero X's um tiny tiny little bug metamask surprisingly just didn't work in a lot of places I haven't really looked into why but uh you know if anybody knows anybody from metamask that'd be willing to work with me on debugging let me know that goes for everybody um okx and token pocket both died in the same place so um somewhere around the get filter changes tests they just stopped responding to requests and I'm not sure if that's a problem with our tests or with the wallet but we're going to be looking into that um and then we have a bunch that didn't even connect and some of that's because I don't know what I'm doing and I think

orange x is a great example of that some of them we can't support because like sequence and exodus because they don't support custom RPC endpoints so uh yeah we can't test them and then bit keep failed because of a system error and they don't provide any more information than that so I have no idea what's going on there but look for look forward to more of these kind of reports as we build more tests and try more wallets um you can follow along at wtf.allwallet.dev and if you want to work with us to you know help improve your score or fix tests reach out to me I'm on Twitter here on Discord um I'd appreciate it

it's about it for me foreign so anybody have any questions about uh wallet test framework oh sure Shane I'll uh I'll reach out to you after what's your Discord username perfect thank you so much um I see somebody has their hand up feel free to just talk uh just uh Kyle from Brave um just want to say awesome work on this um I'm very surprised that we are passing all the tests um I figured we'd be one of the people

who were breaking some of the test of times because we're used to running into wallet compatibility issues um along the way so um very awesome work at this and I'm looking forward to using this kind of as a as a tool that we can grow with as a community together so that we can make sure that we're hitting compatibility and making needs here on dapps going forward so thanks for doing all the the hard leg work on this okay and you know thanks for building a wallet and and working with the process like it's it's been a pleasure working with you guys awesome yeah if I may um

of course yeah thank you so much for putting your time in uh it's really great to see this uh get started um I was wondering about uh running these tests in CI and if you guys have any tentative plans around uh you know facilitating these tests being run against various wallets various branches or yeah any kind of strategy for for running this automatically um yes we do actually so um the whole goal of this is to build an automated testing framework uh we don't want to have to be clicking on buttons all the time uh so if you'd like to you know meet with us and figure out the right way to

integrate this with your CI please let me know because I need to do that to get more funding so yeah hit me up on Discord and we can talk about it cool yeah I will do I'm definitely interested in doing that on on our side but ours are probably going to be a bit different because we would probably write these as browser tests or take a look at that which is like a great chromium specific thing um in order to to fit it in with our the way that ours work but um our our end goal is to see this um work very similar to how like the web platform tests work and I know you are

familiar with that Sam but I don't know if other people are um it's basically wpt.live um that's the example framework that pretty much all browsers use um and when you encounter something like can I use.com um that's basically pulling all that test information from there in order to figure out like which browsers are working and which ones aren't which features within browser so um my goal is to see that basically the same thing for the for the wallets and create what I like to call like a web 3 platform um so I'm hoping that we can kind of move in that direction because effectively what I see coming from this

is the ability for us to start iterating on new apis um with kind of an opt-in model where it's like some people may support them some may not um and then we can start to see like new apis coming about from this which allows for greater functionality within wallets hopefully higher level apis for things like signing um so that we can get some better ux's as well and kind of move in from there yeah I think um one of them the motivating like use cases for this framework is to um Define tests up front that then wallets can Implement um like later on as opposed to you know one

wallet doing it and everybody else having to copy them so hopefully we can be a little bit more you know integrated and interop better yeah definitely that that's kind of what I'm hoping for I'm glad we're aligned so um bumblefudge in the chat has asked for an overview of the architecture so I can give a very very brief um description of how it works and then if you want more information there's an architecture post on wtf.allwallet.dev and that goes into a little bit more depth but um yeah at its core it's kind of like there's a Dap

um and it connects using window.etherium in the completely normal and average way and uh it will run through a series of tests and those tests uh call wallet apis and then um the wallet does whatever it has to do and then they check it against the expected output so that's all normal it's a regular testing framework the kind of magic that this adds is there's this concept of glue so right now there's only one glue and that's the manual glue and so if you've ever been to uh actually I'll just show you I can share my screen um all right let's see if this works all right so this is wallow test

framework um hopefully you've seen it um see if my metamask is unlocked here it is so um right now the the tests are connected to my wallet um every time the wallet displays a message you have to tell the testing framework that something is going on so in this case we're adding an ethereum chain so this is where you input the information from your wallet so you copy over your chain name your network URL and the chain ID there we go and

um it's giving me so I don't know if you can see my metamask if not it's fine but uh so it gives me an instruction here so now it's saying your wallet should be showing an ad chain dialog approve this request okay I will approve this request and then you hit complete and now the tests start running and uh so this these instructions and these events panels here they're um the manual glue there's also a way to attach using websockets so you don't need to actually click buttons in the web page you can just send messages over over websockets and that's how I would imagine most of the automation would work um yeah this is the output from the test this is kind of what it looks like um

I wasn't really planning on giving a demo so I don't have a lot prepared here but yeah basically the architecture is uh while it pops up a message um then whatever's driving the tests has to click one of these buttons or send a websocket message and then the test will tell the driver um what to do with that wallet pop-up so if you're familiar with say um selenium or Webdriver tests it's going to be very similar to that kind of an architecture awesome thanks no problem does that kind of work with your web platform test um idea Kyle uh very similar um

the since most of what it's testing is API driven um the way that they do it is uh basically just firing them into API calls I'm not sure what the architecture is for WPT live but the effective output is the same so I don't really care much it doesn't have to be the same as like what's happening in WPT live okay as long as it does something similar that makes sense yeah the the whole goal that I see behind this um is uh basically so that rather than us having to copy each other's um implementations for interoperability we can instead copy the test framework

and just make sure that we're passing the test framework and then if we notice that there's still differences then that leads to us adding new tests and so over time this becomes kind of like the central point of interop rather than any particular wallet that's implemented some feature first foreign exactly what we're hoping for so if you're ever planning on adding a new uh API call come see us first and maybe we can help write some tests yes that would be awesome um on the topic of um sorry I'm forgetting my question

um it'll come back to me in a second so to put a link in the chat to um a blog post with a little bit more detail on our architecture and some very rough diagrams so if you want to share it around that's the place to do it or the thing to share um next up we have our presentation on eBay 6963 um assuming we're done with you know the wallet test framework so I'll hand it over to Kyle to to talk about that um I see Shane just asked a question um and my question actually just came back to me um Shane do you want to answer or ask that first

I can ask it as well um he said in chat is this a just environment or could it be uh so we use mocha uh it was the easiest to set up in the the system that we use so I guess a little bit more about the architecture there's like we use ganache and to implement a fake blockchain that the wallet connects to over websockets or over HTTP rather and uh so we run mocha and ganache in a in the browser instance and then uh or in the in the web page itself uh I looked at just as well mocha was just the one that seemed to be the easiest to set up and you mentioned Argent is not um uh you haven't figured out how to

connect it yet how do you envision like um account abstraction while it's connecting with us um so right now we support just window.otherium because that's like the lowest common denominator I think um but we do plan to add support for other connection methods as long as there's an e what is it 1153 or 63 whatever the the one that defines uh the interface provider we should be able to support it eventually but uh right now it's just window.etherium okay awesome uh does anybody know if uh like account abstraction wallets are following that uh I think it's eleven

nine three or five three or whatever Alfred said yeah sweet sounds like it in that case then I was like uh you mean by a kind of expression do you mean like safe and Urgent or do you mean like the next gen ones that are using the four or four like the new kind because I I know 1193 is good for all of the major smart contract wallets like already out now okay that's good to hear because um it was essentially both um because what I'm figuring is that our

next big interop problems that we'll face is like a wallet developers is going to be um what's happening with account abstraction how eoa wallets fit in with account extraction wallets and um do they line up properly because we've already seen that like for signing for example I think it's uh they need to I don't even know the Erp but it's like basically is signed um contract method in order to actually sign some of these things um so that's like the the first example where I noticed that there's like some interrupt um differences that would have to come into play so I'd love to include some

um 4337 style wallets in in our testing so if you know of any I think BLS wallet might be one of them um let me know and I'll add it to our our manual tests awesome I personally don't the only contact I've had was with people at Argent previously when I was at um uh wallet um uh wall conference hosted by wall connect yeah because I think so argentin gnosis are are two that exist today right um the salt wallet team is on the server

and they have I believe a a working Alpha I can reach out to her great oh yeah give them a try thank you seems like discussion may have slowed on that one yeah I think we're ready to move on okay um so I didn't actually create a presentation per se but I can do a demo um from uh EIP five six

what is it uh I'm not even remembering the six nine six nine six three okay um so I'll go ahead and share my screen um I've done some original testing on this inside of Brave nightly can everybody see that properly yes yes sweet okay um so in order to test this what I was doing just going to erp6963 and then see here I've got encrypting zerion it looks like they've all been able to get this working now

so um just creating a lot for this don't remember um 6963 is a multi-wallet discovery protocol so that you can have multiple installed wallets and choose between them yes I can jump over to the um actual EIP to kind of explain how it works a little bit after so I created that wallet um let me make sure I've got one here I am not eligible okay I need to reach out to those you're on folks about that um and then encrypt is working fine so effectively that's what we're trying to

um work around here is the ability to be able to connect multiple wallets at the same time and for the DAP to be able to distinguish between them so uh for example in this wallet here um that'll show it is connected now looks like the Gap might be in a weird State let me see if that might be yeah so this looks like this is a warning that would have popped up um based upon some changes that happened recently so um essentially this will be a perfect um uh Target for writing some tests and actually I'm I'm planning to work with Sam in order to get that done

um I just haven't gotten around to it yet basically I wouldn't um focus on the spec was the the original intention and then we can write some some tests once it's near in completion so we feel like the spec is getting to that point which is why we've asked people to start implementing uh within the group and that's kind of one of the things that we want to talk about is can we get um to you know maybe maybe five or ten within the next month or two it's actually a very simple thing to implement you're just using events uh where you wrap around your um uh what is it you wrap around your window down an ethereum injection uh with a few different objects and it makes it work pretty easy so

um not very complicated but as you can see I'm able to inject different addresses to the actual wallet itself or to the DAP itself from different wallets and it's able to to connect to them independently there's also some stuff that I've been working on internally at Brave about how we can go about doing a private mode so there is some definitions in there but this is kind of an idea I had when I was working on the spec and I just kind of dropped it in there so I'm not sure if other people have noticed how this would work yet in a backwards compatible way but effectively what you saw me do there is how I would kick this off is in this

very similar way um so the idea that I've been playing with for us is that for legacy dapps for example which I should be able to initiate I can initiate it on this one so this is a stable that I'm on right here you can see that it's Legacy so the idea behind this is in order to make this private mode this has already been injected into the actual wallet itself but what you can do is hit connect here and then I can select my wallet itself and then when I hit Plus and connect it'll automatically grant that permission so what this means here

is that at the point when the user interacts with the connectflow through the wallet that's when we can initiate injection is after they've selected the address which then means that we can actually prevent fingerprinting as well so um I'll likely do that internally for us but then I'll show kind of how it works so that other people can kind of copy that Paradigm in hopes that we can start to eliminate some fingerprinting issues that we have as well and add some privacy preserving features so that's kind of the demo of it um I will jump over to the actual EIP itself and drop a link here um to kind of walk through how this works so effectively what it is like I said is

um we're passing some properties in and this is basically just metadata about your provider um and there's details about what they actually do and stuff like that and this was where a lot of the discussion actually landed was to be able to discuss um these different properties how they should work what sort of trust model they should have what are the security security guarantees and things of that nature and then you take that metadata and you supply it with the actual provider itself and then you pass it over an event and that's effectively implementing eip6963 so the whole point of this is basically to prevent us from having to

um basically prototype pollute window.otherium to try and compete for it so that we can all actually get all of our wallets working together and kind of improve that user experience for the user um so that's the high level explanation of it that privacy aspect I mentioned um is kind of highlighted down in here but there's no like specific details on how that works we could even write that as a secondary extension spec potentially in terms of like the ux that would come with it but that feels very implementation specific so I'm happy to just engage with people separately on that as well um is there anything else worth mentioning

um I don't believe so we're currently in peer review state so yeah if you guys have the ability to be able to get this on your backyard as an Implement and then let me know um the plan is to make a push here in the next month or two uh to basically start promoting this and then taking this steps and saying hey this is the better way that you guys should should be approaching this going forward so that's all I've got on the topic um any questions so I guess what are you looking for from the wallets that are on this call today um biggest thing is just being able to

get adoption for it um it is an opt-in feature so we design it in a Backward Compatible way um that would be the key thing because the more wallets that we can get adopting this the easier it's going to be for us to be able to approach the apps all together and say hey you guys should implement this because there's a integration point that has to happen between both of us um so if we've got enough wallets supporting this then it makes it much easier for us to be able to go to the dapps and say Hey you know that cool Library you're using like web3 modal just upgrade the version and you'll be able to pick this feature up real quick sweet that's awesome to hear

um I'm not sure how to pronounce your name I think it's kiosks can you explain that a little bit further uh yeah sure I I'm just wondering if we should just implement it right now uh it looks great but it's been stale for a few months and still in the review stage if I remember well yeah and yeah I'm just worried about injecting more data into every Page's browser load you know uh if it's worth it or not I gotcha um yeah so uh that's kind of the the whole goal behind the privacy

mode aspect of this is that this um because of the event to a model it's actually possible for us to do this without injecting any data first you can do this by basically adding an event and then or adding an event Lister first because the page fires an event as well um and then effectively what you can do from that is to be able to respond first so because this creates this event Loop you don't actually have to inject first you can just choose to add the event Lister and then only respond when the page responds to it that would break backwards compatibility but that's kind of where that backwards compatibility

backwards compatible Legacy private mode comes into play which is to start changing some of the things that we're already doing today um but people don't necessarily have to do that if that makes sense does that answer your question okay so we should go we should go for it right yes um essentially at this point my um impression of the spec um having worked on the spec is that um we're looking for implementer feedback we we intend to basically take this uh to finalize state by the end of the year um we're looking for that feedback during the review state so that we can

make sure that any sort of things that we missed when we were writing the spec which is very natural to happen make them into the spec before we finalize it so the idea behind this is if we can get people implementing around review in the Final Call State we can figure out any sort of things we missed make changes coordinate those changes together and once we've coordinated and decided yes this is correct we can finalize the spec and just say this is what it is now that's what you should open it okay thanks yep thanks for the question that's a great question because for people who weren't following the spec um yeah it may be confusing kind of what state it's at and where it's going

especially with so many erps that kind of get left in stale States so kind of on a general note about eips um like review would be a good time to start trying to implement eips and then maybe having like preview releases but it's definitely not ready for production and then last call and final would be like your release candidate and then your like production release would be around the final time yep that's just for general eibs not just not not for this one in particular sorry I didn't mean it up there um to tie this back to the test framework

discussion that we had um this is where we as a wallet Development Group can actually say any wallet related eips um have to have tests written before we go to Final Call that would be ideal State that's how actually w3c does it as well and they placed additional requirements with say at least two browsers must Implement and pass the tests or all the normative required tests before the spec itself can be moved to finalize State I don't think we'll jump to that right away but I'm curious to hear your opinion on that Sam I think that a lot of the discussions around eips are going to be a lot easier

shortly um we're trying to work on a better governance system and I've shared it with I think at least one of you probably Kyle um yeah so anyways um just wait a bit we're going to sort some stuff out and then we'll be able to do things like that if we want to have like a wallet working group for eips um that'll probably be possible in the next month or so I think this uh testability requirement is uh that Kyle mentioned from w3c

precedent makes a lot of sense for the interfaces well it's the wallets have to be I mean um I think ideally any EIP about like a wallet interface should already have a test in the CI of the wallets that want to support it uh what it gets to final because otherwise it's just like kind of a precarious under tested thing but um I do think that if interface requirements specifically wallet interfaces

wanted to sort of like have their own version of this process it doesn't have to be imposed by EIP it could just be like all wallet devs wants to set the precedent of like submitting gherkin tests with your interface EIP as you know like it doesn't have to be a requirement for us to do it anyways and just like even plain language English descriptions of what you would test could be enough to help people review it you know oops yeah that makes sense yep no like we can

be completely separate from the eip's process as well like it's it's however you want to organize right yeah one of the things that I think we're going to need to figure out with the core devs is when they expose new RPC calls for the nodes how do we go about exposing that and making sure that works within the wallets um but that's something we can kind of figure out along the way yeah that's that's definitely an interesting point like especially with like get proof and um get Max priority for you for gas it's like recent examples I think so yeah

yeah um luckily it seems like um they're open to these types of things um in the discussions I was having with Dan on these types of stuff so um they want to stay connected um their biggest thing is they're just getting slowed down um and and I completely understand where they're coming from with that cool so on a similar note um I put a link to um my sort of competing proposal for this um in the agenda it's a much longer timeline as in nobody's even started implementing it this is EIP 7039

um just throwing it out there take a look at it comment on it tell me why it won't work um yeah thanks I see there's a lot of topic happening in the chat about reversity National week move that to just discussion um invoice yeah please do I think we're done pretty much talking about everything else so yeah um I haven't read through it can somebody summarize it thank you

I I was just looking through the um the EAP and the only thing that kind of stuck out at first was the rdns field um and I so I guess I was just kind of raising a point of like I'd intuitively imagine that to be like say URI with the um you know non-reversed one though I understand you know uh pardon me for not knowing uh your proper name I'll call you Bumble um I raise a point there uh around uh the usefulness of having It reversed and in a large set

um though um yeah just wondering they're like um if that's like a set in stone thing um if there's any alternate you know preferences or if anyone else has kind of raised anything around that yeah I'm happy to I'm happy to give some backstory because it's been going back and forth for a long time with the the wallets that have reviewed it so far um there was um the initial like I think one of the initial proposals was just to have an arbitrary string with no constraints or

implied functionalities um I was actually an advocate of rdns just by analogy to manifests because in um just centralized like I think that given the decentralized nature of the development here you want people to be able to declare themselves and sort of like vendor their own vendor the namespace of possible strings um and reverse DNS is used for manifest for that reason sort of like a top level domain is something that most commercial or non-commercial organizations get early and stick to

um and if uh all future versions can be sort of subdomains of that then it creates this sort of like self-sorting self-organizing namespace it's sort of like an ietf tradition that comes from Java or whatever but um to your point about using normal URLs or some other URI scheme or having constraints that make rdns more functional the pr I linked in the chat is one of the um uh active reviewing wallet developers proposal to make it more explicit both the rationale for it and what you can

assume about it and what you can't um so I I do think like um I think it should be a DNS under the control of the maker of the wallet um even if everyone's and on even if it's a non-profit like I I want to leave open the design space for wallets that are not products in the commercial Capital sense but I do think it's um uh left open for future eips to extend this to have a HTTP based verification method like you could use a key record on DNS or a did well known or some other way to

put key material at a URL so that people could use an rdns that is associated with the key that signs the packages and package managers or App Stores um or some other sort of bi-directional verification but I think it also the the consensus was that while that would make sense as an extension spec some people would rather just use them as arbitrary strings and on both sides while the sides on dev sides it might not make sense to sort of like make the onus of verification or reason to not support this the standard um since it's sort of like urgent to get um just more secure basic connection

while the depth connection um sorry that was kind of a brain dump instead of an answer uh if if uh you have follow-up questions or anyone else has questions I could maybe be more useful yeah I know that's great it makes a lot of sense um uh something I kind of take away from that is uh their uh the intended use of that is is primarily around uh future desire to verify potentially not in all cases of course as you mentioned

some people won't actually have the domain that they put there um but but generally that uh like it's not trying to replace the value of like uuid there right like uid is right the ultimate identifier of a given wallet right and and I think there was originally two different identifiers one for the wallet instance and one for the wallet code base so like one would be for like this is a metamask wallet and one would be like this is the specific build of metamask on this device um so if you generate that uuid at build time or at installation then you have a

uuid for each individual wallet out there in the world but if you wanted to know that that was you know like a an official release of metamask or like you know actually came from a metamask binary the verification would be useful because then you could sort of like have some two-way verification between that uuid marked individual wallet and like which version of metamask it's claiming to be um and the so in a sense there's like the the identification of the wallet for sort of local purposes and then there's the like is metamask flag that this is replacing in the basic window.etherium

model um so like it it's sort of like to be backwards compatible and to be self-attested the way is metamask is uh you want to allow people to make an unverifiable or unverified Claim about what kind of software it's running and in those subset of use cases where it matters that it's actually an official build or you know an original unmodified binary or whatever then you would have the verification extension option so Kyle you braced your hand there yeah I was just going to add a little bit of flavor to that um in the sense of like one of the key things that the DAP developers

um and the DAP Library developers that have been involved in this um uh development inspect so far have brought up is that they want the ability to be able to create um ux's on the the DAP page that load very quickly so for example they can cache the images um in a way that would allow them to basically be able to load it before the actual wallet initiates its injection um or like basically fires its event and so there's some different like rehydration schemes and a few other features that they've mentioned that this would allow them to do to be able

to maintain persistence between a wallet that basically changes perversion or changes per session effectively is kind of the idea so that's what this identifier is really about is being able to replace that and and formalize effectively that is metamask that is brave wallet that is coinbase wallet convention that we kind of all just picked up but never actually wrote down and that was kind of what they had said is hey we want that actually written down this seems like a good place for it can you put it in and originally I was very much against this because the identifier wasn't verified it could be tampered with

but eventually I think their arguments were pretty sound in terms of kind of the benefits that come from this we just have to be careful with it very similar to user agent strings if you put too much information in those huge user agent strings in a browser you can actually cause a lot of compatibility issues so um that's kind of where a lot of the bike shedding on this uh topic went was how much information what do we do how do we secure it that type of stuff so this is a great question actually foreign how many wallet developers are not in

that telegram Channel can you guys like raise your hand or type it in China the eip6963 task force uh thank you I'm not okay I figured that might be the case um I see a lot of people popping up um go ahead and speak could you post a link to that Channel please yes I will do that and if that doesn't work um I will drop my handle in the old wallet doves and I can invite people

directly as well but let me see if I can get a link uh the link was on the extension extension registry channel was shared by Pedro awesome thank you got it thank you so for reference this is just kind of where a lot of the discussion has happened um because Pedro was the lead instigator and being able to get a bunch of people into the conversation um going forward uh personally I wasn't

a big fan of using telegram um I'd love to be able to move discussions like we had about rzns directly onto GitHub and have it during an issue but that's something that we can kind of figure out going going forward and stuff like that about how do we actually want to engage do we want Discord do we want telegram these types of things because having well developers who aren't aware of these conversations isn't really good all right well thanks for um coming out

and talking about it giving us an update I really appreciate it um yeah if um we want we can just hang out and talk some more uh feel free to take off I think this is the end of the official uh meeting yeah go for it Kyle uh I just wanted to take a second to promote something that's happening at um eth um devconnect in Istanbul um so this is an ethereum Foundation sponsored event um this is uh wallet uncon we're currently looking for um uh proposals effectively for people to bring forth to this unconference so I

don't know if you guys have been done conferences before but we tried to highlight it here um we'd love to get a lot of wallet developers there so that we can start to have more discussions about um you know things that we want to build together how we want to improve the world ecosystem how we want to improve wallet ux and stuff so uh if you guys are in or around Istanbul at that time it would be amazing to have you guys come um reach out to me or bumblefudge who are both helping to organize this and we're currently in Communications with the ethereum foundation who's actually helping to fund this basically one day event yeah it's it's a it's officially part of

devconnect in the sense that like it's taking place in a room that was booked in a bundle without like I don't know official side events official events I'm not sure what the distinction is but I I'd mention that we're doing 10-minute lightning talks in the morning and 20 and half hour open workshops so um we can't plan for all the workshops in advance but we can plan a few to sort of like seed the the schedule with a few fixed proposals in defense um but yeah definitely lightning talks particularly if people want to demo interface eips or or design patterns or

anything that that wants a lot of horizontal review from other wallets those are be the ideal lightning lightning talks I'm definitely looking forward to it thanks a lot for the chat it was great

yeah thanks for coming out yes take care everybody bye everyone thank you see you thank you bye