AllWalletDevs #4

Transcript

okay perfect so uh Welcome to our wallet dose number four we have a few things on the agenda today um the first you know official item is uh the URI URL working group updates um so if anybody here wants to talk about what they've been working on or what the URI URL working group is even doing um go for it I was just gonna say sorry was that like sorry I have to server mute you your mic is horribly horribly broken incur with uh Sam James your mic is incredibly broken right now if you go

into Discord settings under um voice and video you can do some local tests and see if you can figure it out I think you might sound okay now yeah yeah um okay no that was just on my side sorry the uh yeah sorry so was this section just for General demos or specific to you were saying UI ux something oh this is for uh so there's a separate working group that's um being hosted by the cat herders on Uris and urls uh so we have a couple different proposals that are being discussed there um so if you've ever seen like the ethereum colon uh pay Dash URLs or um

anything along those lines that that's kind of coming out of that working group uh so the the most basic one is just simply like an eth colon uh than a prefix and then a payload um and that's kind of like the the family of URI URLs and this is something that uh we're thinking of bringing into the all-wallet devs call instead of keep it keeping it separately um so I mean obviously wallets are going to have it so this this isn't really my working group I'm just going to try and give a summary on it so uh yeah so uh we want to bring it into the all wall of devs called just to uh because wallets are the ones that are probably going to be implementing a lot of these URL handlers and there are quite a few different proposals on

um what types of URLs to support so one of them is like transaction receipts one of them is you know just simply sending money um so the eips are in the agenda if you guys want to take a look at them um and I think uh key here is also working on 4804 uh so if you want to give a summary on on that particular scheme uh please do um sure absolutely um so I think a lot of people may not uh have uh some background I actually I think some of them already have but maybe a lot of them you may not have their backgrounds so probably I can have a quick go through what what I'm going uh let me see um

what the uh EIP or a04 is going to do um so I need to wait uh I'm trying to share my screen but uh looks like this this uh this uh security privacy I have to enable so I'm sorry I have to restart this score to enable so probably the bad one sure we can we can probably move this to uh actually uh James is your screen sharing working we should probably check that too I started with in my screen sharing working yeah because you wanted to give a demo right oh yeah well actually um actually handing over to Blake who's prepared it so we've got from our team we've got John Jake and Blake from the

BLS wallet team I just want to make sure your screen sharing is working before we get to uh that section yeah yeah I'm not sharing my screen so yeah Blake if if you want to do a quick test with yours and then we can yeah data from there okay I'm back um so let me share my screen can you see uh yeah um so I have a present this to the previous URL where I working group and so um this is basically how the motivation basically we see there's a great Trend that a lot of nfts they are uploading their web content on top blockchain uh for example one example we saw is a server broker uh

which they said they have upload all the media data uh the SVG layers on Google blockchain so that the narrative is that they will never lose the media files um so because it's stored on on top of blockchain and so I took a look at their contract and see how they are able to achieve that and so this is the exam of their contract and there's a token URI so see how they are able to retrieve those content from for example ethereum as they said and which from their children URI I see the image field which is still using ipfs which we know that ipfs may ah discard data if nobody hosts

it so and then a further take a look at how they might do it and then they have actually have meta metadata contract which basically uh stores all the layers they have store and then uh they can for example random uh any token ID and starting from their offset that is from zero and then they will run in all the layers one by one and then um so given the next offset so I can curve the next part and then so this just continues then I can retrieve all the uh SVG components that they upload on on Hardware object so I think this is

really interesting application uh when we realize uh there's uh such kind of like using um students midnights as their storage layer to upload some the file valuable uh objects another example I found is called ad blocker I recently um found they have also said that they have they're basically are ft that upload some code that is able to randomly generate uh some pictures according to their code so this is an example uh so they create a lot of a lot of basically different empty images by just using different

random C but the same code um so they claim that they can they're able to uh basically um replay all these things these pictures on top of ethereum however actually we also double checked your contract um so I I uh um and they are still also using uh their centralized servers which which is other block uh Slash um some token ID something to random um those objects even though I can find their JavaScript on the uh on the e0 minutes so the core motivation of erc404 is basically to be able to directly query a smart contract and is able to

basically download this my contrast data and be able to render those data directly on top of the uh browser or any other tools um so here is um let me just quickly go to the the this this one so this is kind of like a similar HTTP schemer but it's using control battery which we register at Ina and it will tell us which contract you want to call it can be ens or the 20 bias counter hacks and then corresponding Channel ID and then the master right method ID and corresponding parameters and and there's a way how to

process these parameters in different types defined in the standard um so for setup worker perspective we basically create a contract ah that um is a scam that is at this location and this country actually is very straightforward it just tells which token ID that one to render and just repeatedly call the sort of broadcast contract and then to obtain corresponding offset and then call next time until the office of becomes zero and concatenate all the bytes so that we can obtain the final SVG or ft files uh by this by this method and then with the

standard defined so we are able to render it so this is the website web Suite schema scheme which we have the CNS register uh as the this address and then we call this method and provide the parameter of this file is the token number so I have a browser here is a buy box that enables this feature so is through our Gateway that influenced by us so it just applied the the rest of field then it will automatically look up the corresponding address and call the contract with the corresponding method and now we are able to directly render this contract uh

using the the URL so this is the the main motivation of that what the VIP for a04 is doing so right now eip4804 is in the review stage and Sam also gave a lot of suggestions comments on how to be able to be for example work with existing standard and also some uh for example how we are able to parse those um those query Parts uh employee and also argument parts so that we are avoid confusion at the same time will be as close as HTTP so right now we are looking for one or more reviewers to

help to reveal the standard so that you can be able to be more production ready and there are also a couple of community members actually they are here he's asking me whether the stability of this standard so that they're able to incorporate those links for example directly into their token UI so that they don't need to worry about you using ffs or other third party uh centralized servers to store that store that store UI so that you can retrieve all the data permanent on top of if you're on blockchain so this is the automation status and I'm happy to answer any

questions so what are you looking for from wallet developers are you looking for a review um yes and definitely if there's a for example quality developers or or some maybe other for example supports that is able to render to apply this standard and is far more welcome yeah so is this something you'd like to see implemented in wallets so like if you type a web3 URL in the browser the wallet would render the content for you or yeah that that's that's one One Direction down here yeah

any other questions cool so thanks a lot for giving us an update on that and uh yeah definitely looking forward to seeing where it goes now I think BLS wallet wanted to demo some new features and I think that'd be kind of cool so I'll turn it over to them yeah thanks yes I was just saying we've got a team here and um Blake's uh and John have recently started with us um but yeah the goal would be less what it is to yeah uh provide a module that other wallets can integrate um to um basically get

um transactions on layer 2 cheaper than they already are by doing signature compression um and yeah which were just the size of the roller we've got a client module that we've um integrated into a prototype wallet which is just called quill and that's what uh Blake will be demonstrating so he'll be using coil and just showing some of the features um that the smart contracts provide so as well as the low cost we've got um multi-action user operations so we we're using the same terminology as four three three seven but we're not yet compliant with 4337 as it's still moving around and um yeah so Blake if you're ready I can hand it over to you foreign yeah thanks James I'll go ahead and

share my screen excuse me I actually uh went ahead and created a video of this so I didn't have to worry about a live demo um so I will go ahead and start the video and if anybody has any issues hearing uh let me know and I'll get that fixed I hear nothing Sam yeah I'm not hearing anything yet we'll take

I actually don't know how to get a video to or how to get um Discord to pick up the sound of the video oh once you're a screen sharing it was an option let me try again I guess I mean you already screwed yeah you might have to end it and reopen it with different options it's definitely possible I can tell you that yeah just to filler in the meantime um yeah we've been reaching out to a few

wallets over time um we've just had the contractor audited we've got some fixes to put in and then yeah once we're in mainnet we will just sort of go back uh hit up the wallet so we're interested and and reach out to some more um layer twos as well because we have to deploy the contracts on um well we're going to be deploying them to optimism and arbitrim first and then yeah other layer twos that have approached us as well for their own um chains so this works by having like a like a smart contract wallet kind of thing that holds people's funds and then use BLS signatures to compress them together or yeah so the um yeah basically you've got a verification contract that is basically a wallet Factory and that will

create these wallets those wallets trust the Gateway which is why we had those that code audited um to um call function generically call functions through the wallet and so that Gateway will check a bundle of user operations each user operation is signed by a BLS key held in the client wallet and the aggregator which eventually will be integrated into l2s yeah Aggregates the signatures together and then that bundle is simple too oh you're gonna get the feedback yeah so that bundle's sent to the um uh verification Gateway contract which then performs each user operation uh via each wallet

um that one key feature as well which I don't think is in the demo is that adapt can sponsor transactions so um it's basically gasless transactions without Sorry by actually coming from the wallet address as well which I think with if I'm not mistaken there um the the GSN way of doing it I think is via signed messages and so the address isn't necessarily the wallet um for how it currently works but maybe for it's different for 4337 but um yeah if like uh yeah like if you're ready did you want to try again yeah yeah I think so I can try one more time just without my headphones on and

the sound coming through my laptop uh turns out I have to install additional software to be able to record the audio so yeah hopefully this works um and if not I might need to try to install a software real quick a quick demo of the browser extension that we're working on hey everyone my name is Blake um I'm with the BLS law team don't forget to start your stream questions group within yeah sorry I'm a mess the audio sounded great though all right hopefully it works this time

hey everyone my name is Blake um I'm with the BLS law team of the privacy and scaling Explorations group within the ethereum foundation I'm here to give a quick demo of the browser extension that we were working on that we call quill uh yeah I'll go ahead and sign right in I already have loaded up the onboarding screen for the extension wallet and I'm going to go ahead and complete creating my account it's a first step I need to set a password next up we have the ability to set a nickname so I'm just going to call this voice wallet and then finally you have the ability to

view your secret phrase review it and then confirm it it is worth noting that this is an extension that is really just meant for demonstration purposes and not meant to be used with Mania mainnet which is why we have made it easy for everyone and just displayed the words that you need to input oh I'll go ahead and confirm the secret phrase and as you can see this brings me to a page here with a smart contract wallet that was generated um I have the ability to add multiple smart contract wallets um within the quill extension and then

on the right side of the screen we have a few tabs that are related to the selected wallet um right now I just have this transactions tab selected uh which will eventually show the list of transactions that have been executed um the first thing I want to demonstrate while within the quill extension is just sending ether from one wallet to another um so I'm going to do that and send some ether from wallet 0 to wallet one but I need to fund it first so I'm going to go over to metamask and send some ether to wallet zero 700 confirm that

great nice so you can see wall zero has updated with 100 ether and I'm going to go through the process of sending that to wallet one so I'll go ahead and click Send select ether is the asset and wallet one then I will send 10 either this this brings up a um transaction request modal that I can go ahead and confirm the transaction [Music] and right here we're just displaying the status of the transaction we're waiting confirmation and it should update nice now you can see it's confirms wallet zero has 90

ether in it and wallet one has 10 ether so a little bit of the functionality within the quill extension um next up I do want to demonstrate a simple application that integrates the quilix the quill wallet um so I'll take us over to this other tab where we have this um demo application that interacts with an erc20 contracts on the left here we have a component that is linked up to your wallet um basically you could mint 10 tokens and approve them and then on the right we have the component that is linked up to a spender contract that has the ability to call transfer from

um and transfer the tokens from your wallet over to the spender smart contract wallet um so yeah to demonstrate it I'll go ahead and connect and as you can see here is the address that I generated in the quill extension and the remaining 90 each that I have in that wallet I'm going to go ahead and mince 10 tokens take a few seconds once that's done I will approve it all right second last step I will pull

it using the spender contracts turn red finally you can see that it has updated the number of tokens in the spender component finally I wanted to demonstrate this bundle up button at the bottom this is what we're most proud of because most wallets have the functionality to do what I just demonstrated how mints prove and pull tokens but what's unique about our wallet is that we have the ability to um bundle up a group of transactions and

send them as one request so by clicking this button it'll first uh do this mint then approve then pull all part as all as one of one transaction so do this it's different here is that you could see instead of just having one transaction request um we actually have three we have the mints and approve and another approved so I'll go ahead and confirm all of those you can wait for that's complete great you can see that I did all three of those as one and incremented the

spender from 90 to 100. and we go back to the quill extension we could see all the transactions now showing up related to wallet zero um and we have this nice new modal that was implemented that we can click here and see the actual actions that were um included in each of the transactions so you could see the mints approved um and the contract interaction here close that and the last thing that I wanted to show everybody is the actual code that we use to group those transactions together um this right here is uh the bundle up function that gets called when you click

the button at the bottom of the screen um pretty straightforward you can see the three different transactions the mint approve and pull transaction here they're all just using the erc20 object to connect the signer and then populate the transaction but instead of doing each of those individually we are actually sending them using window.etherium.request and the send transaction method and then we pass all three of the transactions in an array um as part of the params of a key um it is important to note that this isn't the typical spec for each send transaction excuse me our custom RPC Handler actually intercepts the send transaction

function and overwrites it with a function that understands the multiple transactions that are passed in aspiram's um key of the object that is sent um and then yeah last up we're just waiting on the get transaction receipt to show on the updated information to the user all right great yeah I think this is all I wanted to show for today and if you have any questions please don't hesitate to reach out thank you everyone nice yeah that is it Worthy why did you go with each Sun transaction

instead of creating a new method like you send transactions plural yeah that's a um it's a good question um I'm actually relatively new to the team I'm not sure if anyone else in the call uh would be able to jump in for that one yeah Jake um were you talking with kotok uh about that I think you might more across that section considered um just like a separate um RPC um I think for I don't actually remember the exact Sun why but since that is an array and normally the sentreen's eye uses the first argument inside of that logical extend to add additional

transactions [Music] um we could use a custom method we need to do that um really um with the way the wall is working now good work like just a general transaction or if you wanted to pass more exactly that um is that generally more like a custom method from the RP plug that I think I got your question you're cutting in and out a lot um So when you say you send it as an array you're saying that um each of those transactions is a different parameter in the Json RPC requests like in the params array each

one separately it's not an array inside of an array uh correct just gonna be I think the normal spec and sorry if I'm kind of is basically just remember through the spec for that yeah I think it's normally one item Ray and that's the normal Lux and transaction format so that window is here um but we basically so we actually look at on that first parameter um and we'll also include those if they're valid uh related transactions okay so a separate question then I think that's probably fine um

I'm a little bit concerned just so depending on the whoever's on the other end are implementing the other end of that when you deserialize the transaction this realization becomes much more complicated if you have to just realize that Union versus the serializing just a single known shape this isn't insurmountable and I think a lot of things already have mechanisms for dealing with this but it does add complexity so it's like in mud uh second question though is Json and RPC I believe the ethereum Json RPC supports batching at the Json RPC level layer and so I'm wondering why you chose to go this route instead of just doing a Json RPC batch

yeah the the difference there is um uh because we are aggregating the signatures like we need to get all the transactions as one um bundle yeah and so that's a different um yeah that's sort of why we're doing it that way yeah you get smaller in one place rather than three places make sense so good yeah it's one logical request as opposed to three logical requests in one HTTP request yep yep I gotta say that was a really slick looking demo by the way uh Jake yeah nothing Spike if you understand correctly actually the

demo doesn't show the real flow the real flow is how to get multiple transactions probably sent by different users into a single bundle and the instant bundle up to bundle them not the client application in the UI there are other ways Cloud applications and multiple application a batch of requests yeah I know that that I think on the example dap there the term bundle up um maybe isn't ideal um so bundles are yeah definitely multiple wallets signing user operations and sending it to an aggregator or an L2 that supports aggregation and they'll bundle multiple different wallets as user operations together in that demo that's just a the multi-actions within a user operation

and so that's a single transaction sorry a single user operation with multiple actions and that's something like a ux benefit for dapps um so yeah there's two different things there one is the debundling of different user operations from different wallets to save transaction cost and the other is the ux gain of multiple actions within a single user operation but yeah good good distinction to point out and still the UI mixes too because there is both the spender and the other one and they're bundled together even though they're supposed to be different signers aren't they uh no in that example like the user flow without that would be you go to uh an exchange and you have to you know approve the DAP all of your X token

whatever it is and then after you've approved adapt that token then you can do a swap and then you trust the DAP to to do your other actions and you're signing those other transactions so you're signing an approval a blanket approve all of your token which is not a great practice and then doing an interaction like moving a token um or if daps want to be um more secure but then worse ux would be before every interaction you need to approve that amount and then do that amount uh you know say a swap or something this was just to show that example that if that dap does need to approve an amount and then move that amount it can do it atomically as one so either both will succeed where it approves n tokens and then moves in tokens

um yeah foreign it's any like when a user want to use this is any like cost estimate how this wallet creation will be charged compared to a normal volume fixed number if I want to use pis wallet yeah yeah so so um yeah this was uh started on this before like some yeah a little moment before 4357 was written about um but yes our V2 will hope to make more in line with 43q7 um and the goal of the original project was about reducing transaction costs so it

was focused on L2 deployment only not not necessarily L1 whereas I think 4337 is more about um yeah focusing on the more generic signing mechanism whereas ours was to say specifically use BLS to save transaction costs on evm roll-ups but uh yeah we may come to some Middle Ground where we can b4337 compliant in the next version thank you does your wallet support uh the daps sending three separate transactions but the user choosing to batch them it's like these are just doesn't sign

individually they just wait until all three have been clicked then they sign uh I I don't know if that's in our prototype yes but the client module does um permit that yeah yeah so yeah the idea is the client module will have um all the functionality and yeah there can be local bundling um uh yeah well yeah I guess you could do it either way like either you put three uh actions within one Atomic user operation or you could have three individual um user operations that are sent um but sorry no I think sorry your question was more so around does the can the user of the of their own interactions take

three separate transactions and then choose to sign them as one action as one user operation is it correct yeah yeah um prototype yet yeah like I'm using adapt and I'm gonna go do three or four different things for example ens maybe I want to you know edit the owner and at the same time I want to update an ipfs hash or something there's no need for me to do those as two separate operations I can just do them you know there's no no reason that I need to send them separately I can send them as one and there are some cases where you very kind of specifically want these two things to occur very close to each other not always but it comes up this would be nice if as a user you can just say hey I'm going to do three things I want to

sign once at the end yeah in the um in the web through World Discord we've created a separate channel for design and we had a kind of a good review of the ux to say look what what might wallets want in the future multi-chain multi-action blah blah and one of the things was something like an outbox where you could potentially queue up a few um we haven't implemented everything in this design it was more of a you know what what could wallets look like and then the Prototype is just more so to show the integration of the client but uh yeah an outbox concept was um was designed but we haven't implemented that um at least I don't think we have uh handshake interview correctly I don't think we've gotten that far yet we had it on the card so then we maybe pushed

it back yeah there's also some um like usually when the Diaz call into like like a constants response at some point like it approach the Trinity up there can be patients would like oh that the apps all those up um and trying those so we have this little bit but with there um the other thing that's important to note is that transaction we're getting actually through our aggregates it's actually look at the bundle used and then it will hopefully returns like transaction hash that is a

in other cases you the L2 transaction any bundles from many and so there's digital proxy we have to do to pass that through um so so there's some more complications tracking all that stuff from a court perspective with that as well at checkout I'm not sure if anyone was about that sorry Jake I think your microphone's quiet uh patchy at the moment we've got some of that but unfortunately we get half your words and so if you speak densely it's very hard to follow if you repeat everything twice then we

might get it I'll just I'll rejoin but yeah um yeah there's some complications to stacking although um from what we've looked at okay yeah thanks for the time now don't know if there's any more questions but we can carry on awesome uh thanks a ton for putting that together and that's really exciting to see it coming together now what are we going to see this on mainnet yeah no good question we have the um

yeah the audit back um and I'm just going through the issues one by one so yeah I don't want to give an S to it but yeah um so yeah what would be the point to mean that uh where are we now August let's say after the merge how's that sounds good um no that's awesome I'm really excited about it um and I think Matt will be happy too when he gets his batch transaction endpoint so yeah um starting with arbitrim but yeah that's where we got cool um so if nobody else has anything they'd like to demo then um I guess we can go back to talking about the extension registry and other

topics that aren't necessarily on the agenda what was the extension registry again uh that's the the name of the thing that we're called like the URL scheme and all of those discussions are in the extension registry category a broad catch-all for wallet things well specifically for how dapps communicate with extensions and other wallets so yeah so where we leave off we were talking about um chaining wallets together yeah just some mechanism to make it so the people that are implementing signing

tools don't have to also be the people who are implementing visualization tools and analytic tools and protection tools so my thought on that is it really seems like all of those so if we imagine like a line between the uh application and the wallet right all of the chaining and connection stuff is on one side the wallet side whereas um like you know and the DAP needs to know nothing about it and doesn't care about it so I really don't think the URL connection scheme needs to care at all about how the chaining is implemented because that's completely different like that's opaque to the dab so

sure so so the adapt when it connects to something would maybe let's say connect with the well with the scheme right so while it go on slash slash whatever here's my here's how to get a hold of me opens up a server whatever that means and then something receives that and connects um you're saying that that something then I see what you're saying I think the thing that they keep swapping back up into my head is I I I feel like we shouldn't be leaking to any of these participants that the other participants exist even so like

as an example you can imagine um there's some very popular wallet out there that currently does signing and it also does some other things it has some other features right like maybe it offers user swaps right in the wallet if some intermediate thing shows up in between the DAP and that wallet and that wallet knows it they may start taking action to like I don't know make it so that things don't work as well or whatever like to discourage users from using that other thing because the other thing may be stealing their their lunch so to speak by offering users a better swap in their tool and this is kind of a pathological end game but I'm worried about going down that path where we are is the

general privacy problem right where if you leak information someone will figure out a way to make money off the information leak and that way of making money may not be in the best interest of the user whereas if we can keep that information hidden somehow then um people can't leverage it now the reason I bring this up in response to your questions because it is not clear to me how we can avoid that sort of data leaking without having with that decision be made somewhere in that initial interaction where the user is choosing their wallet like when that user gets that wallet prompt and they need to select their wallets like whatever that means I feel like that is the right time to make that choice and have the user you

know organize things or configure things or whatever that makes sense yeah it does it's just I think a lot of the stuff has to be cooperative anyways right like if I'm using you know wallet a and I'm signing something and with a key that isn't in wallet a wallet a needs to know to forward that request like it all seems very cooperative um go ahead it's more specifically answer your question why not just have like a router wallet that all it does is glue all the pieces together and then you handle all requests with that wallet maybe that's the answer um can you provide a little more color on like what specific privacy issues you see with okay we're talking about a

theoretical Fox swap feature and uh an imaginary wallet and you're saying that potentially there could be something in between sort of their integrated application layer and then the core key management and signing what yeah so the general idea here is that when a user wants to interact with ethereum there's the DAP that they're interacting with right and then there is some tool that maybe offers some protection from scams like it'll tell it'll if you try to send a transaction to a known scammer address it will pop up and say hey don't do this is a very bad idea maybe there's another tool that is again in that flow that does really good visualizations and so when it sees you trying to do a

transaction it can display that or present it in a way that really makes sense to the user and then there's the tool that does the actual sign-in right the idea here is is that we don't necessarily want the people who are really good at Key Management to also be the ones that need to build a visualizer and need to build scan protection like those are three very different tasks we want to be able to delegate them to teams that are good at those individual tasks and ideally products and have a product competition that doesn't bundle them all together so you don't you shouldn't have to choose the wallet that does all three of those things good enough you'd ideally choose three wallets one that each does their respective thing very very well and so if we we have this kind of these multiple

tools in the chain between the Dapper question to do something and you finally eventually sign it and that last tool may be like a hardware wallet or something I don't know um we need a way for them to to communicate between each other so you need to be able to pass the transaction first to the first one like the scammed Checker and then pass it to the visualizer and then pass it to the signer and ideally you want to do that in a way that doesn't leak privacy of the user like in in a way that the none of the pieces involved know exactly what the other piece is involve so the scam detector doesn't know that you're using metamask or um rainbow wallet or something else like they just know I'm detecting scams and I pass it along and the visualizer doesn't know that you're using the scan detector

and they don't know that you're using metamask and they do because they just pass it along so I I think one issue there even if you're pushing for standards for modularity that all wallets can you know use these things maybe something like almost like snaps uh the the problem is I think more externalities uh in that you know why do we see software wallets bundling and features well it's differentiation and it's a way to monetize wallet development in particular with metamask and swaps um that's basically as far as I understand like carrying consensus right now and I had no idea it was going to resonate in that sort of way so there's

clearly a financial incentive for like wallets and again obviously I'm biased but I look at like what Ledger does with Ledger live they almost want to be like a curated crypto experience like AOL versus you know direct access to the internet and I get why that appeals to some end users but I think you have to separate out technical standards and like what are the incentives for wallet teams to do all these things monolithically so that makes it a tricky issue I know it's not really constructive but I see visas into related problems so I think that you what you said it makes sense and it's a very valid point I think that

the incentives aren't there and this is part of why I think that the Privacy is is important because what I worry about is if you know wallets are incentivized to provide that One-Stop shop because that One-Stop Shopkins include uh add-on services like upsells right like exactly this is exactly what metamask does is they have a wallet and they upsell it if users are able to get that upsell feature from somewhere else in in the that's better right they're not going to use the upsell feature and so this is why I'm concerned that if we leak the fact that users are doing this chaining to metamask hypothetically then metamask will you know be forced to take actions to prevent that or stop that or

whatever and so whatever we come up with I think if we what we want to maximize users ability to have this choice of modularity it needs to be done in a way that the individual tools can't know what other tools the user is using and the individual tools can't prevent the user from using other tools so like it needs to be designed such that the user or the wallet um doesn't need to get we don't need to get buy-in from the wallets like either the wallet works with the we do any biofin adapts because adapts will need to communicate this new mechanism but we wouldn't need buy-in from the wallets um because the walls you don't need to work with adapts if that makes sense so I think if we're going to be talking about this from like wallets are the

adversary and I know it's kind of a weird position to take but we are the adversary um if we're taking that position then I think chaining is the wrong um like visualization or analog for it because chaining is very permissive each wallet would be able to control which data is passed on to the next wallet I think what you'd want to do is think about it from like an orchestrator or like a router point of view or you have something that sits atop all of the routers and passes requests like first it passes the request to the the scam the the scam detector and then then it receives a response from the scam detector decides what to do and then then goes to the visualizer and gets the response decides what to do what to do

and so it goes back and forth to this orchestrator that sits on top of all of the of the wallets that way there's no cooperation from the wall that's required yes so I can definitely see an orchestrator potentially being the solution here um I'm going to contend a little bit that that's required um I think that the only so we know that the signer has to be at the end of the chain all right I don't think it makes sense for the signers to not be at the end of the chain um let me move this argument there where the signer is not actually at the end of the chain but if we assume the sign is at the end of the chain and everything else is not a signer so there are things that happen after signing right like I remember there being like uh services that will send a

transaction like publish it at a certain time for you so that would happen after signing how can you separate visualization from signing because if the visualization visualizer can decide what I see before I sign how can you protect what the visualizer does what do you mean so like the visualizer is malicious and shows you the wrong transaction contents let's say oh sure so like the user does need to semi-trust each of the these tools they don't need to trust the they need to trust the signing tool the most because that's one has a private Keys the other tools they do need like if

they're malicious those other tools are you know give them bad data that is very possible and there's nothing that prevents that yeah it's the whole Hue carp attack Vector where you know if you're relying on your tool to to verify in a general competing environment you know precisely what you're signing um yeah there's that degree of trust involved no matter what and I think having these these modular components can help a lot with that because a particular paranoid user may actually install you know three different visualizers and so they would verify that each visualizer shows them the same thing in their own you know UI or whatever and so that way by the time it gets to the signer you know if any

one of their tools is compromised then that's not a problem whereas if someone has to compromise all of their tools and that's a much harder attack for an attacker like you can if you can take over metamask update for example you can force an update on all the users and now metamask is compromised all those whose machine machines that just download the med Mass update but now you need to compromise metamask keys and you need to compromise like four other visualizing tools Keys that's now all of a sudden much harder and something from a security standpoint having you know allowing all these tools in there really helps you protect users significantly again because they can verify verify verify over and over and over again so same way ideally users are you know when they're using metamask you check metamask to see does the

transaction look right and then you double check it again when it gets to your Ledger now we of course we know no one actually does that but you know at least in theory that is possible one thing and I know I'm just kind of throwing spaghetti at the wall here but I liked something you said there where it could almost be something with this system that uh verifies the provenance of like the data source for each plug-in like this and actually you know would advise you to to uh rely on like multiple data sources to to bet the uh the signing request I mean that that adds like a another layer to it but that provides better security guarantees yeah I think if we went with Sam's uh

router thing we could maybe achieve something like that where the router could say hey we noticed you only have one visualization tool installed we generally recommend you install you know at least two from different sources here's some recommendations just to kind of incur help encourage users to you know follow better security practices and that router tool wouldn't have to actually implement this visualization stuff at all it would just have to tell users hey it's in a position where it can notice that the user doesn't have two visualizers in the chain so that might be nice I think in either case though that's all on the wallet side of the DAP

wallet divide and I don't think that really affects how you launch the wallet or how you connect to it yeah I think if we do the router thing I think you are largely correct and I'm I'm starting to come around just the more I think about it I think the having a single router that is your wallet from the point of view is adapt and when you get the pop-up the router wallet is what's selected I think it's not unreasonable and one can imagine a future where the browser functions as the router right so that's that's the piece that the browser actually builds and integrates whereas the individual modules that the router uses is something that users can add and remove stuff from

yeah I was just thinking that as you were saying it and we could call it an extension registry well done Sam well done yeah I'll chew on the the router thing I generally like the idea and um it allows us I I have I do like the um the scheme selector that Sam's been typing about and so this would allow us to keep this game selector and not break anything and it simplifies integration with depths because the apps don't need to worry about anything a sort of complex modularity system they just are

like hey I need a transaction to be sign of set someone figure out how to do that and that thing is that router yeah I think I'm more I like it cool um 5139 I forgot to mention uh in the agenda um if anybody's had a time to look at it let me know there's the implementation now with the typescript uh documentation um so yeah I guess we have a you know a working implementation of it for for now 1539 is a 404.

sorry 51 30 51 39 is a 404. you said 15 39. yeah 51.39 that's the um RPC provider list um proposal I leave for a day and there's external links external links the uh Json schema it's the HTTP vehicle schema I'm giving a hard time oh yeah that one is not optional unfortunately oh and summer don't forget that that's not external

oh you clever dog well done okay you win the scoring round Sam so on the web 3 well uh repository there or organization on GitHub there is uh an implementation of this that can um merge lists and do all the fanciness that is specified um I don't know how wallets do like uh libraries like would you grab a common implementation for this for all wallets would you all implement it yourselves so I'm curious about that why does this list include the chain ID

I haven't read it all so maybe this isn't the rationale we can feel free to tell me to go there oh uh it includes the chain ID so that um you can pick a set of providers for any particular train ID and either query them all or query them in a list and make sure you're getting multiple providers for the same yeah cool well if nobody else has any other comments I guess that's it for today thanks for coming out thanks again thanks so thanks that was great