AllWalletDevs #21

Transcript

I was thinking of starting like um like a rotating hot seat where we throw like um like we invite a wallet to speak about any subject they want and then we just go through all the wallets in the Discord um every month until we get back to the beginning I don't know if anybody would be interested in something like that but uh it's something I've been toying with yeah I think that would be cool yeah maybe we set that up great so um I guess let's get started thanks everybody for coming out to uh maze all wallet dev's call uh we have one formal item on the agenda and that is a presentation on 747 by Victor uh and with that I'll turn the floor over to

you okay uh can you hear me yep you sound good yes so hi everyone my name is Victor uh many of you uh are many familiar face um I'm I'm one of the EIP editor working with Sam Wilson and usually I've uh be more I'm more active on the ERC side he then uh it's good to meet you and uh today I think it's a combined uh conversation I think it's more fit for the wallet audience so I want to be here to uh present our implementation of EIP 747 which is the interface for watch uh for wallet underscore watch asset and we

think this is a very good and interesting uh standard and uh currently metam mass is what we can interact through our the app and we want to know if other Wallet app have implemented them so that we can also enable and but also for every wallet that haven't yet uh we like to show what it means to have VIP 747 from a d app side and then maybe Advocate uh for you to consider it implement than them on the weite and in addition to that we also have some thoughts on how it could be improved so with that let me ship over to a demo and I want to give credit to my teammate Sami Michelle Sami Al Michelle he's also here uh and uh he's

the main developer for this particular feature and then also many of the the major developer of our app app the namei uh tokenize internet domains into nfts so we have our nft defin we also have our erc20 of nfsc it's like a Starbucks credit where you can buy things on name five with this erc20 by default of course this is new assets it doesn't show up on uh on wallets that has allow listed approach so um sometimes our user have challenge uh seeing the our asset on their wallet so we consulted with people and then Dan Finley uh who's a good friend appoint us to this op option

then we implement this here so can you see my uh my screen I'm about to play a video recording by Sami yep okay so on the high level in our application there's a credit and then um there's this line says show assets on your on your wallet um once you click on it um you will be able to trigger this uh interface of uh wallet watch asset as you can see and metamask will pop up and these nfts will be uh suggested to add to it and also by the way we also add the erc20 which is name five Service Credit

Now with that once that is done if you go to metamask uh you can see our nft uh of course this is a very short demo um what we felt is that this is a great way to allow um user to choose which assets they trust right especially these days there's a lot of um fake assets fraud assets scammy assets uh so increasingly we're seeing while it's uh having a allow listed approach or nft Market has allow list approach where only a a list of trust a listed of a list of trusted tokens nfts and ERC 20s are shown to user and then others are ignored that's

great I think that's an important step towards um having a more building a more trustworthy environment for a blockchain user experience but it also creates a potential risk of centralization or War Garden phenomenon where your wallet vendor will be the guardian will be the one who determines which token you should trust right so many of the wallet in addition to this allow list approach also enables users to pick the main to pick tokens they want to add to to to the display list on their wallets so watch asset is a standard to allow this to be triggered uh by the app so if you

have not seen this I want to like bring the attention to the audience about uh EIP 747 um and I'll share the link to the group uh if you have not uh i' like to like you to see it uh and to consider uh if you it makes sense for your for your wallet to include them uh from what Sammy says this seems very obvious that this is this is a useful feature for the app and wallet so we urge everyone uh who is interested to look into this and consider uh whether you you can Implement them or you want to implement them in the in the EIP it's fin out it's done by it's proposed by by Dan Finley

and estan and uh co-author by gav who is an editor and I think the through our experience implementing it it's quite smooth uh therefore um I think it's a good standard in addition to that our suggestion of course uh is that if wallet can also consider pulling the metadata uh in in the middle uh meanwhile it would be a good improve Improvement to uh year EIP 747 on in in in in addition to that in our case like our whole nft is issued by us right if you trust one of the nft it's more likely that you also trust other nft so the approach in EIP

747 is you have to approve per token ID of nft which we think is a little bit over it would be nice if user can if there's a way to approve all tokens inside of one nft contracts so these are if possible some um some suggestions to improve them but yeah I think V set very well uh Al detection of malicious assets uh but there would be false positive there will be limitations it will be there will be U potential risk of centralization so yeah I'll open up the floor for any questions comments look forward to collaborate we we want more daab to implement this we want more wallet to implement

this uh I hope that answers uh Alex question about the recommendation two recommendations one is pull the metadata of nft so it shows the right name and the right uh right Prof profile picture of that nft uh on the other hand is that um we hope that nft can be added as a the entire collection rather than individual tokens yeah so on that first on that first one the the metadata I think um we definitely can do a better job of this unfortunately there's not um robust metadata standards um especially for ERC 1155 tokens and so it's not always um

you know there's not a standard place where you can go and get that um often it's you know the the name is is in some Json blob and you go get that and then but then the the the everything beyond that is is high is not standardized um and I believe there have been efforts somewhere in the ecosystem to to create more robust standards um because otherwise it's yeah it's very difficult to pull in the metadata uh obviously you can do it on a you know with lots of branching Logic for different standards um and then on the second recommendation um we could accept an

array of token IDs um which I think would be preferable to just just going across every like you a you you don't know where what the token ID standard is as well so you wouldn't actually even be able to sort of loop through any just arbitrary sets of numbers and be able to sort of like know uh which ones yeah or like which ones you should be attempting to add right um so I think the solution there would probably make more sense would be to accept an array of token IDs in that second one um yeah do do make

sense I see that um thank you very much Eric sorry go ahead uh I just wanted to ask I saw the comments by Shane on the chat uh basically going with an MIP like a different approach maybe like you can explain the considerations or like uh uh what's uh you know behind the scenes of that decision that would be interesting yeah well so the the miip is just yeah so okay so the I think at at basically at some point um 747 was was pretty stale and um I can't honestly remember the full

sort of decision um like process that we made but we kind of were like okay uh rather than dealing with the EIP that not doesn't seem like a lot of people are implementing um we're it will be much more streamlined if we if we do this in housee and all that MIP does is just add support for 720 or uh yeah uh 721 and and 1155 uh which were not previously codified in the EIP um I think we probably should go back and do that but part of the problem was someone had gone in the interview time um and added a few pieces that we were not so fond of uh one of which as

Von is highlighting in the chat is chain ID um which we um so so yeah like identifying wh on which chain this asset is you know lives um and you know theoretically hypothetically that sounds great right but we are um pursuing sort of like a more um generic approach to uh enveloping requests so that like any and all requests uh contain shade ID information rather than putting them on the the method itself um so that was one thing we didn't like and then there was some other standard of token uh I haven't pulled it up just right now but that they were trying to codify as well

that we weren't really familiar with and saw no evidence that was like a a really widely used token standard um and so it kind of got away from us um I think that was part of it as well uh so that was those are the reasons that we we basically decided okay we're just you know we see a lot of value in adding support for 721 and uh and uh 1155 uh but the the whole ordeal of having to sort of navigate the EIP process where there's already these sort of Divergent proposals that we don't really believe are are actually valuable or good um that was that was the basis for that decision so I ideally obviously this would be all live in the EIP and we

would all you know um but yeah that's that's kind of how I thought about it sure uh I like to respond quickly to uh Al was it Alex or Eric I think it was it was Alex who just um speak up and about explaining the uh the the decision that met class is moving on to use mip1 um totally understandable as an as an EIP editors I'm author turn editor and Sam uh since we are both in the room um it's it's a good time to us to reflect how we can make author easier and more trustworthy uh build the trust

for authors to use the IP process um what I would like to comment on this is that as a wearing a hat of a Founder rather than as an EIP editor like my day job is nam five founder uh we like to support a standard that Wallet app will be happy to adopt right like if of course metam mass is very well respected a lot of a huge market share so it has its influence in the space but we also want to see other wallets adopting it so if if it's an ERC like uh there's some expectation where discussion will be uh will be uh presented to the community there will be input placed for input

there will be a neutral discussion and and uh for what's going to be in the Pro in the um in in the uh design or not right um but when metamask make the decision on its own or when openc make the decision on its own um I don't know what other uh wallet will feel like do they have a voice in metamask MIP process uh if MI mam Mast disagree with that that suggestion does the wall does other thirdparty wallet feel that they'll be heard so ideally if all these can be done through metam Mas MIP or any uh

reputable um like standardizing body then we can see U much lower friction for wallet to adopt then and also it will be a network effect for the apps like namei to adopt them but when when it was wasn't the case it becomes much much less value for DF to adopt the the mamass individual approach because we know that it it's no different than having a web to uh SDK right you say hey here's what we publish as our SDK and you just go integrate with us and only us um so I just want to like put out our thoughts as a d Builder and urge the

community to have a way to come to consensus like we're totally fine whichever you want to put way you want to put the CH ID as long as everyone is doing the same uh we we can we can succeed as a whole industry it wouldn't happen without erc20 it wouldn't happen without a standard of everyone goes with ERT 721 uh and we hope that it will happen too um to to the to to the wallet as well and as an author turnp added uh my I have suffered the uh the the challenge of editing things as well so I can totally feel uh that we need to improve our process uh and I as an editor want to work with you if there's

a way to bring um the upgraded version of mip1 back to the EIP process uh if everyone like that or I'm all totally supportive of going with like CH agnostic or other standardizing body yeah yeah yeah absolutely um yeah I mean I think um we we'd be happy to to work uh for sure uh we're we're obviously we support all of the the the ideals that you just you know laid out and uh you know certainly want to uh work with the standards bodies and and and ideally have everything be truly yeah like ecosystem standardized and so um yeah

why don't we kind of sidebar that take this off off this call and we can maybe try to work together to to sort of at least uh submit some of our our our thinking and and and how we would like the you know 747 to get back on track in our view um back towards what we think is like the the appropriate implementation um or or standard rather and uh we can uh yeah uh Victor I don't know if there's like a great okay I see you're connecting your caly okay sweet I'll uh I'll set something up um if I can follow up with just another question uh is there somewhere a list of deps that support either or the standards either one of the

standards um is that something that's been tracked like do you know how much ecosystem support it has in different apps things like that we have some internal metrics um but we don't I identify the daps uh at the moment um and obviously our it's all opt-in metrics and so um no but I think what's an even more interesting question to me is also like which which other wallets support it if any um obviously like if no other wallet support it it's very easy to change the standard um and I I haven't actually personally come

across any other wallets supporting it or using this so now that was kind of the point of Victor's talk um but yeah but there there are a fair number of daps that that use it do we know which like Frameworks support it like ethers web 3 VM I've definitely seen it in VM yeah VM has like a a watch asset like sort of baked into it I don't know if I've seen it on the other ones I don't know that any other ones have adopted it um and then I don't know kind of the how broad the wallet support is for for that

particular method but we definitely encourage other wallet developers to consider that yeah I I definitely think you know this is something that's been floating in our something we that metamask did a while ago and then obviously there was there's just kind of like General ecosystem momentum around more like um Auto detection and stuff but like obviously this is like something we want to be a bigger part of how people uh for all the reasons Victor outlined um but following up in terms of getting support through the libraries and sdks and stuff um I think yeah it's something we should

we should return back to yeah I want to resurface a suggestion I made with s with Samson um I really love what uh Sam has driven the test suit of wallets and uh I want to point you uh to this relevant somewhat relevant thing where in mazilla they publish the support of certain language features across different like different browsers wouldn't it be nice that we have a table a big sheet uh of like whichever wallet have pass certain uh feature have implemented certain features of Standards through wall test suits and then that would be a a way for

people to track what features has been adopted what standard has been adopted a great use of test suit but also um it's a competition for free market of of wallets app uh to kind of rush to support more standards and that's a that's a way to call for standardization and AD options I think it's a it's a reasonable suggestion but the the question is who decides which standards are part of that uh uh framework right that's like where sort of the power lies in that situation is who decided 747 needs to be on that web page and not mp1 needs to be on that

page right like that's a decision that needs to be made yeah uh that's that's a that's a huge uh import hly important issue and I'm trying to kind of create um our ERC DS as a way and bring people who have Smart contract design for smart contract standards and I know that Sam has been proposing a working group approach so there will be governance issues governance structure setting up Sam do you want to respond um as far as the working group go it's kind of just stalled on me being distracted by a million other things but um on the wall framework side we can easily write a test or EIP authors can

write tests for their eips and then uh we can just use that as the the litness test for whether or not we should put it in the table has somebody bothered to write a test for it or not to begin with yeah to begin with it could be like Whoever has the capability and interest and strong enough motivation to write a test but down the row should this become more and more important and has been a guiding nor stars for many other web apps then it there needs to be a way to figure out the proper governance and people can agree and can debate and and and can form a consensus of which show up in the table yeah that makes

sense yeah and I I guess it's very likely that people on this call going to be on that committee or work group that I [Music] think other than that I have nothing else to say giving back to the host Sam yeah that was the only formal thing to talk about today um we can keep chatting if you guys want we can end it here um yeah and if anybody has oh I guess we can talk a little about 772 uh I should probably mention that so um EIP 7702 if you aren't aware is a uh kind of a successor to EIP

374 um the major difference is that 7702 has a transaction type that temporarily deploys code at the account of an EA where 3074 would only execute code in the context of an EA uh this this 7702 is new structure kind of gives it a lot more flexibility and makes it more compatible with 4337 which is really important for a lot of smart contract wallets uh and in fact you can use a lot of the same infrastructure uh and this came out you know just before the uh 3074 breakout call so not a lot of people have time to think about it or or have seen it yet so I just wanted to raise it here if you

care about 3074 or executing code for eoas please take a look at 7702 um and reach out to me with any concerns you might have um that's about it on [Music] that great so yeah take a look um we can chat now if you guys want I'll hang out for a few minutes if not give you back half an hour and we'll see you in a month [Music] thanks cool thank you

[Music]