AllWalletDevs #2

Transcript

first point on the agenda is continuing the extension registry discussion but we're probably going to delay that because corbin isn't here and he was probably the one most interested in that um so i'll bring up um my discussion of ep 5139 um it's something that came out of the url working group discussion that we've been having with on the eip side of things and the idea is that um there's kind of like a desire to deprecate the rpc endpoint that lets you add our arbitrary rpc providers to your wallet um because it's kind of bad form to just add any rpc provider it's insecure it has risks with it

so we decided to throw together an eip on um lists of rpc providers that are similar to uniswell's token rpc or token lists um so that's what this is i don't know if any of you have read it or have any opinions on it um if you haven't read it read it we can talk about it in the channel would anybody be opposed to implementing these kind of rpc provider lists and deprecating the rpc endpoint to add one yeah just interested to hear everybody's thoughts on that interesting okay so um just for a bit of

context i was there when we talked about initially writing this um i haven't seen it since so could you run me through like what the um final user experience kind of looks like with this sure so it would be a modification to the wallet ui uh so in the settings somewhere you would have a field where you can add a url to a list it might be on ens it might be on http and um that list is so are you familiar with adblock or or you block origin or any of those kind of extensions yep so work pretty much exactly like that you subscribe to a filter list or

you like in adblock and in in wallets you subscribe to an rpg provider list and the idea is that you'd have some kind of curator uh probably initially the wallet itself uh like would be the default and that curator would keep a list of supported rpc endpoints and so that would let you switch between networks like you know robster and garcia and um things like polygon and that's kind of the idea behind this so instead of letting people add random rpc endpoints they choose the list that has the rpc endpoints they want i hope that kind of answers your question

yeah sweet um i see a fair bit of other things and i see versioning and everything and i'm really interested like is there some some some magic happening here oh there's no no real magic there it's um kind of an extra like it's basically the utop token list just uh repurposed for rpc providers so the version gives you a kind of guideline for users to expect what will happen when a version number changes so like let's say uh the version number on the list that's published on on direct3dns uh increases a major version that might mean that they are removing uh let's say a test net and apps that use that test now will no longer work uh

whereas if you have like um a patch change so the last number that could be a bug fix or adding redundancy or or something along those lines so it gives you a lot of like it gives you like an indication of what might be changing to the end user cool uh one thing i'd like to point out that you know i didn't see when i was looking at it um for uniswap and compound anyone who really maintains a list there have been moments where other people maintain a forked version of that list and they don't update it at a regular schedule and it's led to exploits maybe there's a way that you know if you're going to fork that primary list

or you're going to use some version of it maybe you can subscribe to some email list like geth does this way you can know when there's a newly updated version or you know something that you have to roll into your your solution that'd be interesting so maybe like a a contact email i guess wouldn't really be wouldn't make sense but some kind of like um place you could subscribe for text updates that that'd be interesting or at least a piece of software that'll alert you yeah like like an rss feed would work as well yeah could that problem be solved instead by supporting some sort of list extension

mechanism so where you say um so instead of having to fork a list you can say i would like to extend this list and so my list is whatever's on list a plus or minus these items yeah that that's also a good idea yeah yeah i think there's actually like a jason diff format that we could use for that um i i can look into it i like where this is heading um i if i'm not mistaken you can have custom like profile pictures for lists correct uh yeah you can have a logo for the list and you can have um

i think you can have a logo for the ipc provider but yeah don't hold me to that cool so sam and chat raised a good point here which is um it makes it very difficult for users to add custom rpc providers um because you have to fork a list and then edit some json and put it in and i think that's part of the point of it is to make it difficult um and you know i think my guy brought up really good points i don't know if you want to bring them up again here about why it's bad to add rpc end points like but if you want to go ahead um it's early in the morning i don't remember

i remember i felt strongly yeah so so there's the like the the most mundane thing or at least harmful thing they could do is just watch you um and see what you're doing and uh keep track of your like signed messages and what dapps you're interacting with and you use that for like nefarious purposes maybe targeted marketing or even feeding it into some kind of a scammer pipeline and and more malicious things you could do is um delay updates to the chain or even send completely wrong information and if your wallet isn't um checking with multiple rpc providers then you'd have no way of knowing so um if you add a custom rpc provider from

say a random dap they could feed you fake information about the polygon or something along those lines and we're getting so these are red herring arguments all right why you described during bringing spell uh the core issue here is that rpc the rpc endpoint you connect to is your view and your communication channel into that blockchain and if someone adds a malicious one they can you know do bad things with that privileged position and so the idea is generally speaking users should be relatively careful about

what rpc endpoints they add and they should be getting them from a trusted source you should not be adding rpc endpoints that something i wrote on a bathroom wall for example would this not potentially reduce the possibility that new rpc providers you know become popular and it feels like it would tend to uh they're not sure what the exact word is but just like centralize yeah centralize and solidify the position of say infira one of the things i've been hoping to see is

more diversity in in rpc endpoints that users are using for you know say when they're not specifically using adapt that chooses zone and if you're just doing simple sends or whatever the default is like want more people to say use omnia or parked so to be clear i do think users should be able to add rpc endpoints but i am very um apprehensive about is daps adding endpoints on behalf of users it's like what i don't want to see is a button on adapter like just on a website somewhere that says click here to add our add polygon rpc endpoint to metamask or whatever like that's the thing that's

dangerous is having a user have the ability to add like for a simple example i have my own um ethereum client that i run and in everywhere i can i use it i do not use inferior i do not use quick node i use my own and i definitely think i mean that's that is the ideal way to use ethereum right that is the most censorship resistant way and we definitely want to support that what we want to be careful of is making it so dapps themselves can suggest rbc endpoints because that is a vector for scams and attacks would this list of rpc endpoints be in any way encouraging people to pick you know the not the top most popular one in order to encourage people to

say try a different one than in fiera or what have you um because otherwise like i'm not sure how users will learn that they can change their rpc provider if they can't see it in the dap um i think something that like might partially satisfy that is that um if this list gets refetched every once in a while then if like wherever it's getting re-fetched from is dynamic they could do something like order them by speed or order them by like availability or response time or something like that

right so the place where the rpc provider list is hosted doesn't just have to be plain static this is the list it could also be i don't know like a node.js instance or something um that can check the high speeds and then order them by speed and then send that out so the next time somebody requests a list of providers they would get them ordered by speed or like we need to find some way to to we don't need to but like it would be optimal if we could find a way to sort them somehow [Music] without allowing obviously spoofing of speed um so that users get varied rpc endpoints yet still you know the one with the least load

does that make any sense yeah i think so and that's part of what i tried to do roughly in in this the proposal so far which is uh you can specify multiple uh like entities as rpc providers so like if you're a pocket like whatever and each one of those can specify multiple urls and then the wallet can choose to query multiple independent entities and choose one url from each entity to query so they can do like quorum kind of querying we should probably i feel like there might be value in um having sort of priority system so like i

can imagine if i had a list of my own and in my personal list i include my personal ethereum node which i implicitly trust i may have a backup of infera and quick node and alchemy or whatever and um i would want to always use my node no matter what but if it's down then fall back to a quorum between the other three so i would have priority one set for my node and then priority two set for the other you know three or four um end points and then you know the wallet could then choose how to use that information but it would allow me to convey to the wallet hey this one is better please use this if it's available

and use these if it's not so i don't think the list format right now so i mean the list format right now does not support ordering it by priority but it does give the enough information to order it by a priority where so so like it's grouped into different rpc providers so you could say like infuriates priority for but you'd set that in the wallet ui uh as opposed to in the list itself i mean you you could set it in the list but obviously i have to change the spec for that right so i i it feels like so they hope what i'm imagining is that if someone adds an rpc list they

they don't have to then go and fiddle with things in the wallet and so the rpc list is presumably from a semi-trusted source at least that can make these social decisions and i don't want the user to have to then go and add the list and then say okay well now i need to supply the supplemental information that is not included in the list such as priorities all right so would you be satisfied with something like an integer for each provider if the integers are the same for multiple providers try all of them and get a majority vote and uh i think what i think it's a little more prescriptive than i would like just having a prayer an intro priority uh i think is enough and then it's up to the wallet to decide what to

do with that so someone else may just uh randomly choose one some may do a forum some may do if anyone disagrees that one like depending on your security level okay cool something else that could be possible is to create like a field within the wallet that's like prioritization and it you could prioritize based on speed just take the list whatever's fastest i'll use that because the list works in micah's case you could do custom you want to prioritize your node first followed by anything in this list ranked by speed but it gives you the option of you know selecting your ranking mechanism i do wonder if the

things that are most important to users about which rpc endpoint to select are not instead subjective or more complicated measures like uh are there privacy features on this like omni offers a a mixnet for their ingress and yeah it might not be the fastest and you know npr might be faster but i'm not so sure that it's obvious how i i guess maybe that's up to the curator as to how they order things um

yeah i think in my mind that's exactly the priority would be used for as well it's like i might put you know my note is number one and then something that has privacy features like a mix net that it routes things through as number two and then the number threes are just traditional centralized services and then it's up to the wall at that point decide what to do with that information but at least the user doesn't need to understand that the list provider as a woman needs to understand all those details doesn't this then just push the issue back one level and then users need to know who is a a reputable or trustworthy provider yes the the hope here though is that they only need

so if you imagine a future world where there's hundreds of l2s you need one reputable list provider rather than 100 reputable rpc endpoint providers and so for a user this becomes a much simpler problem of or even a wallet it's like it may be that the wallet will just come with a default list and now the wallets don't need to manually curate a 100 rpc endpoints they can manually create one list and then delegate their responsibility to some third party that is known to be good at creating these lists i do think this could be beneficial but i also am concerned

about how this might long term reduce the likelihood that users will use you know non you know top five rpc providers uh or mites you know whether they might switch away from inferior nothing in fear is bad but you know diversity it's centralized yeah so i think i'm kind of hoping that with this we'll end up with a few well-known lists that are more permissive than the default wallet ones um so like for example somebody might just grab all of the wallet lists merge them together and then you have one that just has all the rpc endpoints for all the wallets or you might have uh somebody who goes out and finds like the polygon the arbitrome the optimism

and they they just list all of the official rpc providers for all of the uh networks and adds those to a list so and then as that list curator finds more l2s they'll add them and then users get it for free which i think is better than what we have right now but i do weekly agree with rosenfier's or just justin's general concern that of stickiness um i don't think the lists necessarily solve the stickiness problem but i don't think they strictly make it worse either like the the only alternative that i think would remove stickiness is requiring it's kind of like we have now where we

require users to manually insert everyone but i think that is unsustainable from a ux perspective and we need something and i think token lists is the currently best option or that i've heard at least that makes it so user don't have to manually add every single rpc endpoint yet it's still somewhat flexible and allows users to make some amount of their own choice i'm certainly open to ideas that would remove that stickiness somehow but at the same time don't result in just a painful ux for users where they have to add every single rpc research and add every single rpc provider manually

i don't think the lists are categorically you know worse in in terms of you know the stickiness problem either because you know much like a like an etf in the stock market you can have like you know the s p 500 which everyone's going to use it's like the basic you know authorized endpoints then you can have your russell 2000 which is a whole bunch of other diverse endpoints that someone has checked and curated into a list and you can trust that provider to tell you hey this is a larger list but it's meant to increase diversity and people would definitely pick that up because you know some people don't even know how to get those endpoints or to find them themselves i do think that the idea of the of

having these lists is a good idea for sure no argument there uh i would wonder if we can decouple the idea of of kind of like restricting uh dapps or anything from suggesting changes from that idea because it's not itself a bad idea i'm just not so sure that it makes sense to couple those two things together sorry i think i missed which two things it it seems that there are two related ideas here one is

this this uh endpoint list uh format functionality the other is the idea that dapps should not be able to suggest rpc changes to users or am i misunderstanding that no i think that makes sense and i think you know if if dapps can't suggest oh rpc endpoints to users i think there needs to be a an additional way to get them to users somehow and you know i think lists is a pretty good way of doing it all right so i think discussion has

mostly died down on this topic i'll make a few changes and then i'll bring her back up at the next meeting and we can talk about it some more um unless somebody else has any other comments we can move something else i am currently starting a prototype of um something that will be able to sort based on speed and then return a list in whatever format you may end up settling on oh cool that'd be awesome we'll have also our first world demo site ready so should we suggest in the spec that the order in the list is the order or i guess we have the priority for that and then okay yeah okay so i'll add priority and maybe

the list extension thing and yeah okay i think if if you want to do list extension um you may want to switch from an array to an object so overrides are easy um okay yeah so i'll change it to like be keyed off of a domain or a name or something yeah like i don't know what the because it was a single domain may offer multiple rpc engines so enough domains right here yes some sort of key so that they can and maybe the key is just up to the list author like it can just be you know numbers or some arbitrary value letters

or some arbitrary value just so that when you do an extension of that list it's assumed that those keys are stable and so they can't be overwritten say i want to replace this one but otherwise use that list cool yeah keep that in mind all right so i think we have uh zk doof talking about the wallop plug fest and imp interoperability test event yeah so this is a um something that we were trying to get going earlier with the cat herders but the idea was to take a whole bunch of wallet devs and a whole bunch of dap developers and some middleware people as well you know and kind of stagger them so you

would go through a whole bunch of different daps or a whole bunch of different pieces of middleware and you would test interoperability with all of them in the attempt to find issues and to find bugs that you know you could you know debug on the fly or try and solve or either just put on your backlog the goal was to find what issues come up the most often and then see if those translate to potential new eips or or just general changes that need to be implemented since we have a whole lot of wallet devs here i figured you know you guys might be interested in that maybe i was wrong

jake from bls wallet here um we'd definitely be interested in doing that we haven't gone through the process but we have some uh like backlog issues to try out our prototype extension with a bunch of different light d apps so doing that in a more um structured environment would probably be pretty good for us great yeah that'd be great um i'd pretty much just be looking for anyone who is interested at the moment and then seeing if we can extend this current group and reach out to some dap developers who wants to try and break a wallet you know see where the flaws are and the flaws could be on the dap side as well in terms of their implementation so i think it is a pretty win-win situation for everyone involved

and if it's done at some you know regular interval maybe once a quarter people can at least see you know the updates and make sure that their adapts and their wallets are working better yeah i think i would definitely be interested in this too this is alex from tallywallet and it's something that we try to do quarterly with our community but it never ends up happening so i think a good idea to just like do it ourselves and like you said with uh dab authors and whatnot great yeah i'll put something into the chat later just saying hey who's interested and see if i can start getting a list together cool that kind of ties into one of the

other ideas we were talking about on the last call um where we do you guys remember the web acid tests the website you could go on that would just test your browser yeah yeah that's a really good idea yeah because i feel like we could probably get a like we're all front endish developers except me so um we could probably make a test site that you can go on with your wallet and just click a button and it'll tell you how compliant your wallet is and maybe we can use that to i don't know i don't want to say shame people into doing better but i know there are some wallets that are less compatible than others um may it might be a useful tool for for everybody else too so

you like that sorry i feel like that sort of thing is more useful if you actually have a specification to uh target we would you sort of right we have the eth api spec i mean sort of i mean that spec is build very ill-defined yeah yeah so maybe maybe the test become the new spec i don't know but uh it's an idea worth pursuing yeah i think it's a good idea in general yeah another thing i could see is maybe as we do these test events you know

before there's an eip proposal or anything or maybe if the issues are pretty small like just common implementation issues those can easily be pulled into you know the the shame test site where it goes okay this is a common implementation mistake this is a common browser configuration mistake we don't need to necessarily put that into an eip but here you go here's how you test it yes that's a really good point about it being difficult to detect detect some features and characteristics um and i think even pointing a wallet at a alternate chain might be difficult um so it might be difficult to do tests

of like you know sending transactions and whether a signed transaction broadcasts it or not um but i think that i don't think those are instrumental problems all right so um i guess we'll try to get that scheduled at some point get some app developers on um in the meantime i think uh we have someone from ethereum.org here to talk about the progress on updating their page yeah hey

do you mind guys mind if i share my screen really quick is that okay yeah please do all right one sec here uh can you see my screen okay i can yeah yep cool um so yeah just wanted to i guess mentioned we're working on updating our find wallet page on ethereum.org so currently this is kind of what or this is what the page looks like today so it's not really the best user experience when it comes to looking for features that wallets have it's also pretty out of date there's been i think it's been a few years since this page has been

um touched so i mean there's been a number of features nfts being an example that have like come to the ecosystem that haven't been represented on our website yet um as well as our kind of like user experience for selecting a wallet is a little bit overwhelming we list 40 wallets on ethereum.org and they're kind of randomized order and users don't really have the best time uh finding a wallet for their needs so we've been working on an updated version here of the page um and so this is just kind of dummy data so if when your wallet is on here and these features aren't right just it's just dummy data right now so um

basically what we're looking to do with this page is come up with some user personas that will fit kind of users in the ethereum ecosystem as well as a more in-depth feature filter so people who have specific needs or features that they're looking for can find a wallet that supports it they can toggle them and then find the wallets that that support these features just making it a little bit easier for users to come find a wallet and then as well we tried to add some better compare features so in the top here we're looking to make it so that users can you know select a couple

uh features that are important to them and then um be able to compare just in kind of a list uh finding wallets that support the features that they're looking for and being able to find like the best wallet for their use case um so i guess with that part of what we wanted to kind of bring up since uh plenty of people working on wallets here obviously is we're kind of we're looking for uh data to be submitted on wallets so that we can list them and have accurate information so that um i mean like when we put this live if a wallet hasn't submitted updated

information they'll still be shown but likely when users are going to filter on features that they want to have in a wallet if we don't have that updated up-to-date information they'll likely be filtered out even if they shouldn't be just because we won't have updated data so we created a new wallet listing template um i can share it in general if that's fine with you guys but um basically just looking to get anyone uh working on a wallet to submit updated information for their wallets so we can accurately show your wallet projects on ethereum.org mainly the rundown if there's any

feedback as well on our like the direction we're going this is currently the open pull request for this feature or this page i guess rather so any feedback would also be really appreciated on what we're doing here i have two totally unrelated questions one what is your guys's curation process like imagine i'm a scammer and i create a wallet and then submit it how do you avoid listing my wallet um yeah so right now so in order to be shown on ethereum.org you have to first fill out this issue template

and then the team uh there's about 10 of us so a few of us will talk about a wallet being listed and if it's kind of like met the criteria that we've set out here um in terms of like fulfilling that so if a wallet let's say is just like a scam fork uh we should be able to look and like oh does it have an active development team um when did the project go live like there should be some things that we notice when someone submits a wallet that should hopefully stand out um but we'll also try and talk to um people in the community as well to make sure that we're not you know listing a scam wallet or anything like that but

i think so far this has been enough for us to just be able to get like a gut check on if this wallet or a wallet that's applying to be listed uh is a scam or not for the most part and the other question do you happen to have analytic data for the current website on what features users are searching for when they're looking for wallets um not at the moment but we are adding some so we use matomo on ethereum.org to uh gather this stuff so we're going to be adding botomo events onto um you know when users are clicking these different features so we should be able to get an idea of what users are

selecting when it comes to features uh the idea would be like we could track down the matomo events that someone clicked before selecting a wallet and we should be able to get an idea and the idea behind some of that as well is we should be able to use that to come back to our user profiles and like reassess as time goes on so we can hopefully build out better user profiles as well the one thing i'm very curious about is the there's a wallet one wallet feature that is a feature for the wallet author and i'm not it's not clear to me that it is actually a feature users want kind of like advertising right like

you know google puts ads but that is not something that the users want in their search is what google wants to search and that is buying crypto and swapping crypto with their wallet um i've always been curious if that is added to well it's because users actually want those features in their wallet or because it's what makes wallets funny and so i'd be curious if users are actually looking for that or if that's just something that you know all that as a revenue generating scheme yeah that's i don't necessarily have the answers to that but i can definitely once we start collecting some of that data i can share it with you if you'd be interested yeah i'm very interested and that one in particular again it's essentially swap features and buy and sell features

are the equivalent of ads for the revenue model for wallets as somebody who's used the swap feature when i'm feeling really lazy i i think they're slightly more useful to users than ads but yeah i think i agree with your sentiment like i've never used to use it at all i always you know use a purpose-built thing for those features like if i'm going to buy crypto i go to a site that specializes in my crypto not something that added it as a add-on oh yeah like i can't even buy krypto using the in-wallet ones none of them work in canada so right yep feel that one love the love the new site and would

definitely be interested in seeing analytics as well cool um yeah so we have a designer on our team who's uh kind of in charge of i guess curating our analytics when it comes to this so i'll pass a message on to him that you guys would be interested in seeing this so he can share it as well cool thanks if you uh if you know offhand like how many people use the ethereum site to find a wallet so our fine wallet page is about 5.5 of our monthly traffic um and we get i believe the last time i checked we get roughly between one and two million

views a month um i mean depending on the state of the market so obviously probably this month it'll be quite low but earth lower but uh yeah roughly five to six percent of our traffic is on this page so not insignificant that's that's cool i think a lot of people are going to be interested in that that data yeah it's a pretty big uh both the wallet page in general where you can like learn about wallets and then the find wallet page the combined they account for about 11 of our page views so wallets are definitely like a big uh a big part of our traffic on ethereum.org all right i i like what it looks like um

however when looking at the uh sort properties right it's a pretty nice list i was wondering if there is or if you have thought about adding uh whether or not a wallet supports wallet connect as a feature that is one of our features that we uh have while connect is okay and whether or not uh and specifically which ones probably uh of the url specifications the wallet implements so the specification for scanning url to uh invoke a transaction for reviewing a transaction for etcetera etcetera etcetera so 681 831 2400 etc um

don't have i don't think we have anything for that at the moment but okay could you sorry what were those numbers again it is 681 681 okay uh 831. two four zero zero twenty four hundred okay and fifty ninety four fifty [Music] okay i'll take a look at those um yeah definitely looking to yeah make sure we have a good amount or good features for users to be able to use so that's currently a topic that's like close to my heart because i've been messing around with urls and url eips

and proposing url eips and uh contributing back to the libraries that are used by the wallets so voila awesome written down to check out is there a list of vips that specifically relate to wallet functionality and is would it be beneficial to denote that in the wallet finder that might be too technical for the audience of a wallet finder but i don't know that seems like a good way to identify features that users might want to search for

yeah i think sorry god as you can see that does feel um too technical for for users to me yeah i think that was our our assumption for the most part right now is that most users are going to be pretty new to the space when they're coming and finding a wallet and um well i'm sure a more advanced user would benefit from having that on the page i don't know that that's necessarily most of the traffic we get but stuff is something that um i'll write down to think about or bring up with people thinking about things on the road map wallet connect v2 uh adoption might be a

bit of a bumpy ride so maybe some way of breaking out all connect b1 versus v2 in the next few months yeah we were talking about that i think we're waiting until it was out of beta to cross that bridge awesome cool so that sounds like the end of uh scheduled discussion i don't know if there's anything you guys want to talk about but we can just end it here if you want or hang out and chat did you want to talk about um whatever it was you asked me if i was

still interested in talking about guinness call oh the extension registry stuff yeah we can chat about that a little bit uh so at the during the last meeting we were discussing um different ways for wallets to communicate with the pages um like apps and uh so the current standard way of doing it with window.ethereum isn't really great uh and it's um difficult for say like wallet connect or um web3 model to support new wallets because they have to add custom code for each new wallet that comes along so um corbin of sequence wallet um was brainstorming some ways of hijacking windowed ethereum so that it

could support multiple wallets um and i think mike and i also proposed alternate ways of doing communication between uh web like web extensions and web pages um mine uses a uh custom scheme handler so like you know how male 2 is like male 2 colon is a scheme you can actually register them so like web.evm or web3 something along those lines and you can click on it and open a post message to the extension and i think micah has a similar kind of implementation you don't have to remember what my complaints with your scheme solution were to go

no no i don't but uh just check it out yeah so there's something about it that made me a little uncomfortable and i i like it and i want to to like it but there was something that was weird about it yeah yeah are we talking about the web3 one or which one uh so so i i this is unrelated to any of the existing url standards okay yeah so it's just literally the url is just i think mine is evm web plus evm colon slash slash and that's the whole url and uh you you open that in an iframe and uh the extension can handle it and

you can post message to the extension through that and the benefits of this are you don't need any custom permissions so right now every wallet needs like full permissions on every page to inject a script with this scheme like handler you don't need any permissions at all which is kind of nice yeah yeah that's fine and what what is the with the scheme handler um does that prompt once for a web page if you if you don't check the box for remember this do you get one prompt for the entire life of that page or like what's the life's time so you would get one so yeah so i guess another advantage of it is that it uses the browser's built-in um ui for

choosing a handler so like if you had five extensions installed you'd get to pick but the downside is you don't get to control how it saves it so yeah so for firefox at least the option is permanently saved forever or don't save and don't save would be like as long as the iframe is open it wouldn't prompt again so you do get you do get a channel that survives the life of that page yeah exactly yeah and why do you need an iframe for this uh because you need to be able to post message to it so uh like if you you could just directly navigate to the page like in a new tab

or something but that'd be kind of weird so the iframe you just hide it uh so that you can post message to that page what do you mean that page so i'm imagining adapt i want to connect to a wallet why can't i just do web3 plus cvm colon slash slash details that i want to send uh i mean so then it would prompt every time you um open one of those everything i see so the the full link is what triggers the the re-prompt so if you use no each request triggers the reprompt oh i see okay so you're using this as a one-time round trip to open a communication channel

yes not for actual data passing exactly i mean you could you could absolutely encode so kind of what i was thinking down the road from this is we want to move away from uh webex well i mean i want to move away from web extensions as wallets and um you can actually have an external program handle the links as well so you could put the the let's say the wallet connect information into the url so that cliche that is pretty cool yeah then like you know like your desktop app could become directly your wallet as opposed to through metamask or through something else yeah exactly would have to play around with it i've never done any of this stuff before like i said earlier i'm not a front-end developer but i think this sounds like

it might possibly be doable so yeah this sounds surprisingly like this is doable i'm just questioning why we aren't doing this already it's new things stickies defaults are sticky and they're difficult to get away from like i've been trying to convince the world with a complete and utter failure because the most likely shout into the wind to move away from the injection thing for like three years now but it is difficult to get people to change and support for registering custom protocol handlers is

uh relatively new i think chrome kind of pushed it through so that they could handle email links um but now it's supported in like edge opera brave chrome firefox so hypothetically if you wanted to have a desktop wallet that you connected to um how would that look like would sure so i believe the way wallet connect works right now is that it encodes a url into the uh qr code and that url contains the information so you'd have to bounce through a third-party service i wish we could uh yeah i think i'm getting that as i'm not a i'm not a fan of the wallet connects like i'm a fan of the wallet

connect in theory but i'm not a fan of in practice because you end up um having to route through some centralized third party and that third party then has you know power to sensor or power to lie et cetera so there are some neat tricks with this so you can actually so in that url you could encode a like if you are local on the same machine um but i mean you wouldn't even need to encode anything special it's just when you configure a webrtc connection um you can configure it with or without stun and turn and ice servers if you can figure it without any of those things it doesn't require a third party server so if you are in an app and you are

something a one-time you basically one shot send a message right over to the other thing the the web page can't host a service that your wallet can talk to yes it can you need information how webrtc with a data stream connection so what normally happens is there is a third party server in this case the wallet connect central server where one client say your web browser goes to advertise that it is looking for a connection from user xyz um and then it makes a qr code that goes to the wallet connect page logs in as user xyz or and etc so the moment somebody opens that url in their

wallet the wallet essentially like goes to wallet connect says hey i'm supposed to be xyz where's the connect me with the client right and then the wallet connect server does and keep in mind this happens for discord voice channels as well right the reason we're all connected now is because there's one discord server that said ta-da connect um even though they've done some sketchy after that that's how it was originally made um now they're routing everything through centralized servers but that's besides the point essentially using the wall connect server to be able to establish a connection between the two but if you could encode the entirety of what you would normally

be sending to that wallet connect server saying hey this is my session starting request message then the qr code will get a lot more complicated but hypothetically speaking you wouldn't use windows server anymore so um to be even more specific um the centralized server is required to bypass uh nat um as well yes yeah so you don't actually need it at all to do a direct connection if there's no firewall and if you're on the same machine there's not going to be a firewall see i think the piece that i'm missing i did not realize that your server could accept your browser could accept an incoming connection yeah i know it's ridiculous right yeah i think it's new to me yeah but it's all there like okay

um yeah i'm i'm i'm very warm on the using the scheme handler thing like i i very much like the idea i'm still a little concerned about like the implementation details and whether we can make this ux actually work and end and and i would like to see a i know you had like a demo i'm i'm worried that there's going to be some rough edges you know just beyond the prototype uh it will basically be just wallet connect but then like more native right yes you need wallet connect but also have a like a post message option so like when you click the link it would generate the wallet connect url and um register a handler for post messages

and then open the iframe and then whatever happens after it opens the iframe be it receiving a post message or receiving a webrtc connection it proceeds from there this may be just me being slow and not not a front-end dev full-time um i still don't understand why you need a wi-frame like why is it okay okay so yeah just you know saying hey here's my rtc server like why does it need my frame i mean yeah i guess you don't if you just wrote everything over webrtc yeah isn't that what we would presumably be wanting to do um i think a lot of wallets today use post message to communicate so i just

followed that but yeah we could just use webrtc for everything and with post messages the idea that yes i still see the need for an iframe even if you're using post message like why didn't i just post message to the window what window like your uh window dot post message or whatever like to the global space and why do you need to post why do you have to post a message to an iframe because the iframe will when opened in quotation marks the browser will go oh shoot this is a custom scheme and

instead of opening an actual site inside of the browser you know the way an iframe normally would do that it will pop out to your extension or pop out to your wallet desktop software you have open or pop out to the native app on your phone right and the only way the only way to get the browser to prompt where do you want to open mail to is by having the mail to in an iframe like i know this is not having mail in an iframe yes it or or a link if you just have a message but then they have to click it well that and they click it and it replaces the current they've replaced the current page too as opposed to just loading it yeah well let me just do the demo of this

i think sam has a demo uh i'm just trying to understand the implementation details like what i'm not getting is so when i see a mail to link right i click it and it prompts me what would you like to use for sending mail and i say you know proton or gmail or whatever and then it just takes me over to my already open gmail or proton tab like there's no iframe involved here yet i have successfully communicated between two apps that are isolated from each other or if i'm using you know desktop mail app it'll open in the desktop mail app i guess frame here but this flow works i don't understand why even though because there's no communication back to the the originating page right so you click the mail to link and the extension gets that request

and instead of actually doing anything with it like http wise it just switches tabs and starts a new email right so the i think you said it did say something crucial there because with starts a new email that means that like an email to link actually triggers an action and has somehow conveyed data the email address in this case to the open window so if you have a ethereum evm whatever schema prefix and then after that the pairing details for webrtc then it would go to your wallet the wallet would get the pairing details show you a loading sign a loading spinner connect using webrtc to the browser and as soon as it's connected go connected

connection established whatever would you like to connect with xyz right yep so you can send your your webrtc i lost the words stun whatever stun ice request something like that whatever that was called um in the url or sorry uri um and that way we're sending it to the desktop application right so you you said yes all that makes sense and i still don't see that where the iframe comes in like something anymore yeah you don't need the iframe if you just use webrtc you just need the iframe to do a post message but we don't even need the iphone

anymore that's kind of cool so if if you're talking to a a desktop app how would it post a message back without webrtc it wouldn't so uh like i said okay so i think the thing i'm missing is i'm imagining this as being a generalized thing that works for both desktop and extensions exactly the same i think you're describing if you want an extension specifically than having an iframe to talk to is useful yeah so i hadn't really considered the thought of just using webrtc even for web extensions um which is entirely doable like when i don't yeah we should just do that there's no need for an iframe if um yeah like if you're just using webrtc for everything

i'm still doing using the need for knife frame for the other one but we can drop it because you should choose what works for everything yeah i think i think you're probably right there pretty good and then your extension will just talk to your page using webrtc and then the security vector has been even more restricted right uh the attack surface because now they're only sending messages through webrtc which is a very limited system uh as opposed to through whatever the hell the browser's post window post message window.postmessage thing does right which might be different for browsers it might be doing x or y or z it's different from browsers oh for sure they uh for a simple example um chrome encodes everything via json so

you have to you're limited to json types whereas firefox encodes via their internal memory management so you can ship more complex javascript objects which include things like bigints as an example [Music] and that's not specified anymore i see i like this um [Music] i think i think sam you at least for now convince me i i think we should when i say we i mean someone else take your demo to the next level and see if we can find any rough edges with it like the the demo is definitely a good start that kind of proves out the idea i just like to see that you know

can we do the more complicated things that we need to do yeah i think the big sticking points are webrtc because that's a huge problem in and of itself um and getting so let's say you have a a desktop wallet and an extension installed does the browser show both would be another important one to explore um there's a few but i'll do you one even better we can completely wipe wallet connect out because if this link we have now right becomes a qr code then i can scan that qr code from my phone my phone is on the same local network in this hypothetical situation not uh behind any firewalls etc or

behind like the 20v lands i have um and my phone the rainbow app or the metamask app can simply go oh shoot this is an ethereum evm url i should webrtc to this address and then it reads the webrtc request from the url which hopefully you know doesn't make the qr code like super duper tiny and precise um and then my phone is now connected to my browser instance i look forward to paginated qr codes actually there are animated qr codes and they work okay so before before we go anywhere further um i think the only thing we would need to change about wallet

connect is the way it connects because it doesn't no no no i mean yes that that would satisfy micro but even without satisfying mica all we would need to do is add a web plus to the beginning of wallet connect urls and then yeah it would just just work because because of the browsers have a list of schemes that are allowed to be registered as custom handlers so i think just adding web plus is all you need so if you wanted to do this what you subscribed with your mobile wallet which is not on the same machine essentially you would need a desktop app or a web app that handles yes you need something that registers

the handler locally right so yes one can imagine gmail gmail registers the mail too right and so it's just a web app that i opened i don't need to register anything on my computer because if okay so so if i'm using a desktop app then the desktop app registers web plus as its schema and then any web plus urls that i click note the word click will automatically open up pop out the window of my desktop app however if a web app chooses to display that url as a qr code and a button i can click the button to open my

desktop app and if i scan the qr code on my phone it will open the app on my phone yeah you see that um yes that works for the button for opening the desktop app as another device remotely so the the thing that i just sent in is i it would be nicer if we adapts only to have one thing which was you know a web3 link and then right rather than having to display either a qr code or have a clickable link you just have one thing user clicks it and then it's up to the wallet to somehow get registered as the handler for that

on the user machine so one can imagine you know having like when the user installs mobile app tell them hey on your desktop go to this page and click enter as the web3 handler button or whatever and so that way when the user clicks the link it will just open a new tab which will then just and that tabs job that apps job is just to show you the qr code and the reason for this is just i want to be careful of putting too much onus on the adapt developers to support multiple mechanisms for communicating with the user and maybe that's the best ux and that isn't what we doing but it'd be nice if there's just one thing that that had to do not to that's fair but how would you make

mobile apps work then with the like the current wallet connect system for example lets me scan something with my phone to to log in so i don't even have to have my private key touch the computer ever right uh so if you're referring to like signing with ethereum then i think that is a separate problem i mean it's still connecting the wall yeah same thing so and i think that would be the same right so you just you you click the link and the link would just be a web three equals life slash or whatever and then again you have a handler app set up on the local host and all that handler app does if you're using a mobile wallet is display a qr code like it just

turns that into the qr code or if you've got a desktop app then it actually you know opens the actual app or the right i think i think what sam is saying meridian is saying in chat is that this is what coinbase does like they just their extension is just a qr code presenter and so it can turn a web three colon slash link into a qr code essentially right but then you'd need an extra extension to be able to use a different device

you can you can register a handler with any like any website can register itself as a handler i believe which is how gmail works right like gmail registers itself as the mail to handle so anytime you click mail tooling right then i'd have to visit the rainbow page and give them permission before i can use my rainbow app yes yeah yes one one time or more of what we have now correct one time per host you would the user would need to register their wallet on that host and say hey when someone tries to talk to a wallet make make sure i'm available and i'm not arguing this is definitely the way to go um it's just i think that we have we should be considering

the the ux difference like versus making it really really easy for daps to support everything out of the box without needing to have like two different mechanisms and i'm not it's not obvious to me which one matters more here i mean theoretically you could make a qr code detector in your extension and find it so that you don't even need to click anything but that that's a little ridiculous i think that requires everybody have an extension it's like either the way adap initiates a connection is by presenting a qr code which doesn't work with desktop apps or the way adap initiates a connection is with a scheme handler query

or we expect adapts to do both and i'm just a little hesitant to expect that apps to do both i think expecting the apps to do one and then have that one then turn into two under the hood is preferable but i do agree that that is a ux hit and so i don't know i i think just having two like right now we have the oh by the way we're past this time so if anybody wants to hop off don't feel obligated to stick around but um yeah so i i don't think having wallets

show or adapt show two options is really that bad right like so the worry i have is that a new dap is going to pick the easier one for them and do that first and then at some point in the future if they're successful enough they'll add the other um and so the you know if the scheme handler is the easier one to implement you know every dapps can implement that first and that means any wallets is support the scheme method will work you know out of the box with those steps and things that require the qr method won't work whereas if we have a single one that the dapps have to implement then every app works with every wallet out of the box regardless of whether

it's you know a mobile wallet or a desktop one so i think then the coinbase method is probably the best where if you have a like a external program handler or or like a camera or a phone then you have to click on the link and then the extension knows to display the qr code i think that's yeah but that that requires installing an extension you don't need extension because remember uh mail two links are handled by okay that's true you just need to go to a web page on your computer like in that browser and click a button that will register the handler like that's that is the the ux pain is that a user who is wanting to

use a mobile wallet will need to one time per browser per computer go to a web page and click a button yeah i mean that that's reasonable i guess yeah i i i recognize that is it is a non-zero step for users and maybe not worth it i'm just i'm really worried about like we already see this right where a lot of dapps will only support metamask initially and they don't add other well it supports until later because you know if you have to pick one thing to add you add metamask and for when you're building mvp you pick one thing you don't add support for 10 things right out of the box have you seen rainbow kid already rainbow what rainbow kit does it require

using webpack or or npm um it requires using npm yeah then it's a non-starter for a lot of people so rainbow kit is a react library so it requires you to use react as well yes that's already a react app [Music] um right now if you check it out they released it like a week or two ago i think [Music] the entire ui out of the box and it's customizable yeah i believe web 3 react does this is trying to solve the same problem and maybe it's better uh but this one yeah

you want to try it out so what's react is what uniswap uses and it's a drop in react to control the firmware correctly that just deals with connections i believe um if you check out the app i put in the chat uh it's what i built with a hackathon what is it last week at ethbrug um but we're using uh rainbow kit so in the top right corner there's a connect wallet button i've decided to go for no rounded corners and all that stuff and then it automatically has rainbow which is in reality just wallet connect with a rainbow emoji coinbase metamask and wallet connect so all of those four um

work out of the box in any app that has you know the decency to run today if that makes sense yes so this is i believe this is exactly the same uh solving the same problem as well through react um i think this is a good idea and like providing dapps with an sdk that's just drop in um for the framework i think is good um and so so i so so yes i am a fan of this in general and my my only question is is if we can solve this problem without requiring a user to um use a you know yes ui plug for their thing that'd be nice right um again i'm not married to this and i could probably convince that the

ux is not worth it but i guess what i'm thinking in my head is if we can make it so by default everything works with the scheme handler one way or another so then the minimum viable app will input the scheme handler alternatively if you want to natively within your app support the scheme handler and qr code so the user doesn't have to you know go through that extra hop then you can and that's a better user experience for your users and absolutely encourage and we can have things like web3 react or lag me or rainbow kit yeah as as kind of like add-ons but they're not required to have your your dap work with everything so like if everything supports the web3 scheme handler in some way or another

then that's kind of like the the lowest common denominator and then we can do better and i think that's great we should and adapt should try to do this better but it's not required to work with wallet i think we're mostly on the same page here it sounds like i like it and i i very much appreciate the fact that you very that you're very uh insistent consistent whatever um on i don't speak english um and i might be slightly under influence um

[Music] but you're insistent consistent whatever on the whole um making sure it is still fully decentralized and still privacy preserving and that somebody in their off-grid hut in the middle of nowhere could run it without having to talk to a wallet connect server right yeah that's that is i did not realize that that is possible um yeah so i'm a big fan now of all this like like i'm gonna have to digest some of this information um but yes i'm a huge fan of getting rid of those central servers especially i really like the idea of if your cell phone's on the same lan as your computer you should not need to go to a stunt

server yeah um like you should be able to just like i i really want mobile because mobile devices tend to have far better um better what ui ux kind of thing just like like they have tpms built into every mobile device these days and the sandboxing of apps on your mobile devices far better than on your desktop yes and so the the attack surface against stealing your private keys on from mobile are very different than stealing private keys from a desktop and so i want mobile wallets to work because i think they're a nice step between hardware wallets and desktop wallets

um but i've just i have never gotten into them because of the need for that middleman and so if we go to that that'd be amazing second that okay so who's gonna go build all this who's gonna go build all this that's a good one um i'm currently doing some updates on a variety of my sites uh i'm waiting for rpc list.xyz which i bought and built the site for and

deployed uh to actually properly start functioning i'm having some stupid dns issue but the rest of the thing works um [Music] sorry i'm trying to triple task here but it's not really like you know i'm still me um yeah i definitely can't take on another project um yeah that's it's going to be a bit of work i sadly don't have any time in the next like week or two um i think perhaps perhaps a good question is how do we transition from the world we are living in today to this hypothetical world where we have scheme handlers

as a mechanism for dabs connect talking to wallets um i mean that's some kind of demo working and verify that we can actually make it happen sure but like even if you even if you do all that like there's the chicken and the egg problem right how do you get that [Music] every wallet to implement this and then as well as implementing the old way and then encouraged apps to use the new mechanism yeah both of these are very hard

um i think you could come up with something like all new rpc endpoints are only supported on the like new connection method so old apps aren't don't break and new dapps that want to use the fancier stuff would have to use the new connection method that means every dap is now going to have to support both old and new muslims [Music] yeah which seems uh unlikely to ever come to pass now can we is there some mechanism by which we could create a browser extension whose only job is to envelope and

things into this webrtc mechanism so it would be what extension injects into the page and it takes all the legacy json rpc stuff and converts it into so it would do stuff it would have some other thing so provide a default provider that um uses webrtc on the back end yeah that'd be that'd be doable yeah so then wallets would stop supporting the old way of doing it and then yeah yeah you have to so so wallace was up supporting the old way but if you've got a legacy dap users can still access it by installing this um you know like inhalation yes

shim or polyfill yeah yeah yeah exactly like polyfills could work polyfill wallet very good polly for a while but we've got a name for it already we're basically done we're basically done we just got to actually make sure that we build the entirety of i mean the name is the name is the hard part everybody the name is so can we actually just take wallet connect change the like i know nothing about the libraries or their implementation can we just change the url to web plus wc and then try it basically yeah i mean they already do a similar thing but then with wallet connect wallet connect colon or whatever the hell it is i don't know

[Music] let's have a look um edge server dot io [Music] log out log in rainbow yeah so that that's what i mean uh sam can we just take your weird uri put web plus in front of it and then yeah try that yeah this is cool on my iphone if i scan any of the wallet connect urls it automatically says camera wants to open rainbow and then i press open and then it just does the rest of the magic it's ridiculous how well wallet connect works but it is also ridiculous that it manages to get this big while still being partially centralized it works for me sam being centralized is the easiest way to

get big yeah decentralizes the hard way [Music] but it is the better way okay well my brain is full i to some time to commit all this to long-term neural pathways sounds good so i can think harder on it all right my camera is still stuck in this one i love that i'm not here you're a ghost i'm i'm totally not here hi um [Music]

i am a ghost all right so uh yeah no worries it's funny yeah well thanks for coming out guys uh zk if you can send me a link when you have the recording um up somewhere i'll write some meeting notes and everything so yeah awesome cool sounds good we'll do thanks guys talk to you all in about a month maybe at a different time all right oh are any of you coming to ethanyc [Music] i

yeah all right talk to you guys later all right take care