Wallet Standards Working Group Meeting – October 21, 2022

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:10

   hi everybody my name is Ori and I'm a technical program manager from Pagoda and I want to welcome all of you to our first wallet standards working group meeting which we're very excited to kick off so just on the agenda today first we will do a quick overview on developer governance which includes our net process and working groups next we'll do some brief introductions as we have a

2. 0:34

   few panelists joining us today then we will get into the main discussion injected wallet API and then we'll open it up to q a lastly we will talk about next steps and how you can get involved in developer governance and if at any point you have questions feel free to drop them in the Q a button on the screen and we'll either answer them if they're relevant or we'll wait till the end

3. 0:58

   so just to go over developer governance over the last few months we've been engaging with the community over this idea of developer governance which is really about the decentralizing nearest development and empowering anyone in the community to contribute to and to participate in influencing the future of the ecosystem and we've been bucketing developer governance into three stages ideas

4. 1:23

   voting and implementation and I just wanted to quickly highlight them to help contextualize our meeting today and there's also a talk which I'm happy to link to uh that we that I gave at near con that goes into more detail if you if you want to learn even more so let's start with the the ideas so we've introduced a near enhancement proposal next as a way to enable anyone in the community to submit proposals for improving the the protocol or standards and it's been super exciting to see net

5. 1:54

   submissions come in from the community and we hope to see even more from Community groups to and individual contributors and as we've been getting more NEP submissions we we wanted to make sure that we have a way to actually move them forward to review them make decisions and determine the next steps so that they're not just sitting indefinitely so that is where the working groups and the voting stage comes in and the working groups really

6. 2:19

   is a way to help operationalize the review of the naps and the idea is to have multiple working groups each focusing on a different ecosystem need and to have subject matter experts in each group who can help create focus and enable us to move faster so we've already kicked off some working groups previously the protocol working group and the contract standards and today as I mentioned we're kicking off the wallet standards one and putting these groups

7. 2:43

   into practice is a gradual approach it's going to require iteration flexibility as we learn what works what doesn't but as in the future we hope to introduce more groups and to empower the community to to run them so just to make sure everyone is clear on the rules that are involved there are four key ones we have author moderator reviewer and approver the author is the person who writes The Proposal the nap the moderator is the person who

8. 3:08

   facilitates the process and helps make sure that maps are moving forward the reviewer the subject matter experts is the person who ensures the technical viability of the net kind of reviews that and then the approver the working group member the one are the ones who make the decision and the process itself as outlined in nep001 looks like this basically there are three stages draft review and voting and

9. 3:34

   two outcomes approved and rejected and all the roles that I just mentioned help move the net through this stages and towards the outcome and a lot of this happens asynchronously on the nip itself if you go to the nap you will see many comments that relate to this process but really when we get to the voting stage we have a working group meeting like the one today where we come to discuss the nap and formalize the decision for voting and that's exactly what's

10. 3:59

    happening now we're here to execute this process look at a proposal that was in the review stage then we want to move to the to the voting and so yeah our goal is to have the the champion the author present it to to everybody and then go into the voting decision so before we jump in I do want to come back to introductions and and kind of give a little bit of an overview of everyone

11. 4:21

    that's here so let's start with the working group members and I'd like to hand it over to Cameron hey everybody how's it going um my name is Cameron Dennis I have been working at near foundation for the last two years or so uh primarily onboarding a lot of infrastructure projects helping uh run the Grant Program essentially whatever needs to get done was pretty much my job um now I'm spinning out of near Foundation to start something new called The Banyan Collective to build that more bottom-up approach to ecosystem growth

12. 4:53

    primarily in the United States so what this means is we run these Builder groups so if you're like a wallet Builder you can connect with all the other wallet Builders to identify what naps are missing um because we do not we do need that necessary line of communication between the ecosystem and the standards bodies so um uniting these groups every every two weeks or so um so we have a wallet

13. 5:16

    onboarding and payments group subgroup custody and recovery subgroup and mobile Integrations so if you're a wallet Builder an nft Builder dial Builder uh come get in touch with me I'm happy to connect you with other builders in the space to identify missing standards we also organize a ton of meetups hackathons essentially anything that people need in order to succeed if you need audits let me know if you need a VC

14. 5:39

    referral let me know if you need legal incorporation support let me know essentially this like network of support for Builders and Founders and in your ecosystem so uh thanks for having me hey everybody um I'm Daryl Collins uh I was hired to originally to work on the near wallet actually uh wallet.near.org wallet worked on that for about a year and uh these days I'm broadening scope a little

15. 6:04

    bit across the entire JavaScript ecosystem uh so I was involved in the JavaScript SDK design and implementation um and we're in the midst of taking over and kind of transforming the near API of GIS ecosystem into a more modern and uh consistent API hi guys Osman um also working on the wallet for the last year I worked on wallet migration as well and um now also working on apigs

16. 6:35

    separating that into a different one into mono repos and stuff awesome thank you all all right next we're gonna do a quick introduction of the moderators in the process so hey Max oh hey everyone uh so max um I'm VP of engineer at pagora which used to be near Inc I'm also pretty much the person responsible for near uh developer ecosystem growth um so a lot of strategies come in from

17. 7:06

    me and a couple of other people and in this group I'm just one of the people who organized this whole format so I'm not doing much here besides just moderating hey folks I'm Vlad AKA for all and you can see me in many of the posts all around the system I joined here originally nearing um quite early on and been involved with many of the developer tooling and I delighted to see that nap process is getting on the next step on the next level of bringing the ecosystem

18. 7:45

    aligned and yeah my role here would be just moderating the uh and helping the wall Center's working group uh so you'll see me involved as a moderator on the on the naps but don't expect me to comment deeply because I Rely a lot on the on this Power Team uh that we assemble here and ordering cool hi I already introduced myself but yeah I just wanted to highlight that I'm also playing a moderator role in the process and in standing these meetings so yeah please

19. 8:16

    say hi and hope to see you in more more meetings and on the nips themselves cool so now we're going to hand it over to the author and this is sort of an interesting case because there was an original author for NEP 370 which was Lewis and then we had you know there's this concept of a champion which is anyone can take over a nap and this is sort of what happened in this case uh

20. 8:40

    which is Daryl so Daryl back to you serving as the the new champion of this snap awesome awesome um so uh I've already introduced myself uh clearly I can talk a little bit about uh Lewis uh and why this was replaced as context um Lewis is working as a contractor and he got a new role so while he did a great job on getting the NEP built to this point uh there was a few changes that needed to be made and it was made in a fork so essentially I've taken it over so that we could maintain it in the main repo uh but the Genesis of this uh definitely the credit

21. 9:11

    goes to Lewis for doing the majority of the hard work and getting all of the text on the page uh we just kind of tweaked it according to indeed silent collapse uh we tweaked it according to our our uh feedback that we had gotten from you guys in the community um and at this point it's ready to really get rolled cool so I guess let's step into a little bit of an explanation about what this is uh you know what what is the injected

22. 9:34

    wallet API and why is it important um so there's there's two major things that we kind of boil down to at a very high level that are critical for this uh this NEP one is that we're going to be defining a set of interfaces that are consistent uh for all wallets that can be interacted with directly from the d-app context uh using direct JavaScript calls like there's no bridging involved

23. 9:57

    there's no messaging protocols there's no browser redirects this is a spec that is specifically designed to help us with interfacing with basically extension wallets those are the ones that we generally have access to Via direct JavaScript calls that are installed into the browser and this will be a consistent API right now um if you haven't worked in the wallet selector code base at all you wouldn't

24. 10:20

    realize but there's a fair amount of compatibility glue that exists inside of the wallet selectors plug-ins for each wallet that kind of provides a compatibility layer and we're looking to consistent normalize that so that everybody can use consistent apis uh it'll simplify new wallets coming in uh this is going to facilitate a long-term goal in the wallet selector of allowing us to make these wallet configurations fully declarative without any kind of

25. 10:45

    moving parts or code so that we can have the list of wallets be dynamic so that the app developers don't need to um ship an update to wallet selector in order to show new wallets so this is kind of the building blocks of a a large piece of work moving forward and also is going to get some immediate benefits for everybody who's implementing into wallet selector or building new wallets there's

26. 11:08

    also one of the critical things about mep408 is that it adds a new concept of when you connect to a wallet you can return more than one account and this is something that we had some discussion about in the NEP uh pull requests uh it's it's a little bit different than the current wallet implementation for near your wallet or nine year wallet and not all wallets will have to support

27. 11:31

    this functionality they can just return one uh account if they'd like to but the goal with allowing this uh concept of more than one account to be connected via a wallet is to synchronize everything with the wallet connect standard um the bridge wallet standard has already been merged which allows people to use wallet connect to link their wallets and we wanted to make it consistent so that regardless as to whether or not you're connecting to an

28. 11:56

    extension based wallet or using a bridge-based wallet that the API was was similar that you would get the same kind of data type back from either one an array of accounts instead of just uh you know a single element and you don't have to do any type checking to work with it so at a high level these are the two things that were kind of critical for the the 408 requirements and um we've uh we at this point have gone through some

29. 12:20

    feedback on the uh on the pull request so we've made some iterations there are actually some really good suggestions made from the community that we incorporated in the last week or so um so we've got some we we definitely want these to be a collaborative process and I really have to give props to everybody from the community Who provided some feedback and some context on this stuff uh because it's better than it would have been without you guys

30. 12:43

    so thanks for for jumping in um okay so let's talk a little bit about the um the other benefits that we've got as a result of this um I've mentioned that we standardized the apis that people are going to use for extension wallets and the main things that are important about this as everybody uh would be aware if you've done any work inside the near ecosystem are the concept of signing into a d app which

31. 13:07

    uses limited access Keys uh signing transactions so standard use case for any wallet please sign a transaction um and then we added uh at Community feedback we've added the ability to detect Network support on a wallet as part of this NEP so a method that will allow you to query a wallet and say do you support this wallet this uh Network can I switch to test net uh will there be any accounts or will this Wallet not even function on test net for example if that's the case

32. 13:36

    um that's the the basic apis that we've got here um the one other thing that we've uh added to this that was also brought about due to community feedback was the ability to compose partial transactions uh when you're requesting from the wallet so in particular we've allowed the account ID to be an optional parameter which actually aligns with the way that your wallet has always worked in your wallet you can provide an

33. 14:00

    account ID but actually when you land in the wallet we'd like to choose a different account ID if you want to and it gets signed by whatever account the the near wallet allows allows the user to choose so this allows uh open-ended cases allowing the this API to to create basically a partially composed transaction that doesn't have an account associated with it allows for this basic use case of I'd like a donate button I don't want somebody to log in I'm not

34. 14:26

    running a d app they don't need a function call access key but I do want somebody to be able to donate using their wallet by clicking on this button and in those cases we don't know what account somebody's going to use there's no reason to add a very a thick layer of near API JS and a wallet selector and a connect concept these are going to go into web 2 apps usually where they just want to link so that's part of the spec

35. 14:49

    you can compose transactions through this that don't have an account Associated and then the wallet will do the where the rest it'll recompose the actions that were given and add the the account that's chosen by the user um one other thing that we added was uh events uh like a concept of event emission because this is a injected wallet standard where we have direct access via JavaScript to the running

36. 15:12

    code of the wallet we can hook we have we can add hooks onto it and call functions on events we defined a basic event spec there's only one event right now which is accounts changed uh this synchronizes with the wallet connects uh specification which has a similar event that is emitted across the wallet connect bridge when you choose uh in in a wallet connect enabled wallet to change which accounts are exposed to a

37. 15:36

    certain d-app so we've added that event now there's only one uh this is uh Forward Thinking there could be any number of events in the future if anybody has any ideas around more events we should add those to the NEP in the future but that's the basic scaffolding that uh 408 adds and the benefits that we're going to get out of them um all right so next up we have uh basically just a kind of an overview I

38. 16:00

    wanted to just make sure that everybody understood uh you know how we settled on this functionality uh and how the journey that we took to get here so there was some good feedback and discussions um both on the original pull request 370 which Lewis had created uh and also then on 408 you guys followed up after we moved it into a new pull request where I could add some functionality um so I just wanted to kind of call those out and point out what we had

39. 16:24

    changed and and the whys for these things um the the concerns that you you guys have brought up in the community were well well founded and they definitely led to some improvements here um so one of the the first thing here was that uh there was an inversion of control here decided on where the initial implementation of this WEP was that uh or NEP was that the network selection would actually be driven uh in an inverted way the wallet the the wallet would choose which network was selected to but actually

40. 16:56

    the D app also has a concept of awareness of which network it works on and it was very awkward to have to synchronize these two things there was no way for a d app to signal to a wallet which network that it was using directly so we've added a network ID parameter to the connect API which allows the app to connect to a wallet and request a specific network will will function when

41. 17:20

    it connects and this also standardizes um or it it creates a consistent uh deterministic interface that somebody can use to connect to that Network so one of the benefits of having this come through as a connect method is I could connect to the wallet twice in theory or I could connect to two different Wallets on two different networks this opens the door to some cool things like a split screen where you can see the results of

42. 17:45

    your test net on your main net accounts next to each other interact with both deploy to both those types of use cases and it simplifies the understanding for the developer now when a developer calls connect and they pass in a network ID they can be confident that what they're getting from the wallet is an instance that will work with that Network somebody can't switch the network in the in the wallet UI and break the D apps interaction with that Network

43. 18:09

    um second major thing was that uh we from the very beginning modeled this as two different calls for connecting to a wallet which kind of diverges from the way that the redirect based wallet worked uh with the near wallet the redirect based wallet for near wallet when you connected a wallet to to a d-app it had an implicit behavior that it would always sign you in by creating one of those limited access keys and this is not always ideal this is not something that with an injected wallet even makes sense in all cases and it

44. 18:42

    wasn't very forward thinking because one of the important things that we're looking to implement in the near future here is the ability to verify account ownership without actually creating a limited access key on the near account that's signing into a d-app so imagine a case where you want to run a forum you want people to log in with their near accounts as an identity but you don't actually want to pollute their account

45. 19:04

    with a full a limited access key that they're never going to actually use on chain um this this concept this new concept of verifying account ownership may happen instead of the sign in option where you actually actually sign in using a limited access key so by separating the connect action and the signing actions we've future proofed the API so that when we add verify ownership you can follow a different path you can choose to connect to a wallet first and then either verify ownership or sign in and

46. 19:36

    this also has a benefit of simplifying the error failure modes of the of the different methods so when I call connect to a wallet the only things that can fail are connecting to the wallet and getting a list of accounts a transaction on the blockchain cannot fail because there is no transaction for connecting to a wallet whereas signing in there's a transaction so the failure modes of that could be any number of reasons why the transaction might fail so we're trying

47. 19:59

    to keep these things separately uh separate so that developers can have an easier time of uh integrating with these apis um the third thing is the um the lack of ability to actually detect whether or not a particular network ID was supported by a wallet the original NEP just didn't facilitate this at all it assumed that everybody every wallet would support all networks uh it alluded to this earlier actually in the discussion um we've added a supports Network method to the spec that wallets should

48. 20:30

    Implement you give it a network ID the wallet returns with a Boolean true or false should this should this be uh connected to can this be connected to Via this wallet and we've made this an async API it returns a promise just in case somebody on the wallet side needs to run a little bit of async code before they decide whether or not they support that network uh so trying to make sure that we don't have to break that in the future uh for any reasons such as let me

49. 20:54

    do a network request before I decide whether or not that Network supported um all right um we already spoke about the connect method returning an array of accounts after connecting and I talked earlier about this uh the reason the main reasoning for this is to normalize the apis so that the bridge standard connecting to a bridge wallet and connecting to uh an injected wallet will

50. 21:17

    work the same way at a high level you'll get the same kind of uh of data type back from your connect calls regardless as to whether or not you're connecting through the bridge or via an injected wallet I anticipate that we we may do some if we can get these close enough these two specs that we actually could pull some of this definition up into a third NEP that's shared by both of these if we can keep these interfaces as close

51. 21:41

    together as possible then it's going to make it easier for everybody who's implementing these uh in their wallets um so the the main goal here with the connect returning an array of counts is to make sure that you we do support the ability to connect to more than one account at the API level there's not a requirement that every wallet make uh wallet Builder go out and build an interface that lets you select any number of accounts you can still have

52. 22:05

    your connect uh UI in your wallet only allow the user to select a single account the important thing is just that programmatically we're returning that account in an array so the data type is normalized and consistent um and the last thing that I wanted to bring up there was some discussion about this this is ongoing discussion actually which is where does a key pair live for sign-in requests and to give some

53. 22:30

    context here um the the idea around a sign-in request is that a limited access a function call access key is generated that allows the D app to directly interact with the blockchain so they own the private key and public key they can immediately sign a transaction from the D app using that key submit it directly to the RPC nodes get the result of that transaction and then carry on without a wallet being interacted with at all and this was really important especially historically

54. 23:02

    when any kind of wallet interactions required a redirect a wallet redirect out of your app by allowing a key pair to exist in the d-app context we facilitate interrupt Interruption free usage so like if you're playing a game for example where when you buy new equipment uh it has to be written to the blockchain estate uh when you click on I want this this equipment associated with my character that transaction that updates the state Could Happen entirely in the bot in the background you wouldn't have to have the wallet pop-up

55. 23:33

    or a ledger prompt on your machine going oh let me approve this transaction with a ledger 16 times because I just moved 16 pieces of equipment uh you know it's definitely not a scalable uh solution so the idea around these key pairs uh for limited access function call Access Keys existing in the d-app context is specifically to facilitate these kind of interruption-free uh uh interactions now

56. 23:58

    some wallets have chosen uh another route so they've actually made the sign in request keep that key locally inside of the wallet storage so instead of exposing the the full access key or the the private key of this limited access key to the d-app they've actually held it and they've kept it away from the d-apps awareness and there's this is something that we generally would uh recommend against because it goes against the basic concept of being able to submit transactions directly

57. 24:32

    from the D app however if a wallet does implement this type of interaction we have added to this NEP that we recommend that interactions using that limited access key are confirmation free or at least limited confirmation because the whole idea around this limited access key is that it shouldn't interrupt the user's interaction with the with the blockchain so in a perfect world these Keys should

58. 24:57

    just exist in the D app this is how it works normally is the d-app actually generates this key and then they request that the key is added by the wallet and they own that key so they can keep using it um but if uh if a wallet does keep these limited access Keys internally there is a nice benefit which is you go to your wallet and the key is there even if you added it maybe on another machine depending on how your wallet is built

59. 25:22

    it's possible that that key might be available for more in more cases uh you know we don't know how you're building a wallet whether or not you persist these to an external service um so this is something that we've we've added specific documentation that recommends that these keys are owned by the d-app so the D app can submit things however we've added guidance for a case where if you choose to own these keys in the wallet side of things

60. 25:46

    please make sure that you don't interrupt the user's experience because if you require if you apply require a confirmation for every transaction that comes through then essentially we've kind of um eliminated the benefit of this limited access key uh the whole purpose of it is to reduce the amount of blockers that users encounter while they're interacting with the D app that uses transactions on chain um yep so that's about it from the uh

61. 26:15

    the high level so uh any I suppose I believe at this point then we were looking for uh Oreo takeover and yeah thank you so much Daryl for for that comprehensive uh summary and and really also thank you to everyone that has voiced their their concern and thoughts uh you know obviously it is evident that that you have taken the time to really look through them and everyone and that's great so before we move on to the next uh voting stage I do want to just offer up uh to the other working group

62. 26:47

    members to Osman and Cameron to maybe present any like your opinion about the the snap and if there's any other concern that that maybe was not mentioned uh yeah Cameron do you want to go first yeah um to me this is pretty straightforward uh there's a lot more wallets building uh an injective ball standard is is really just almost a prerequisite to help ensure the security across every injected wallet on here um and it just seems like a pretty important like beginning piece of this

63. 27:18

    growing ecosystem so um also I mean it tremendously helps I use many wallets uh I would benefit from this directly I've been prompted many times to open up accounts or log into accounts with wallets that uh if I'm already logged into account uh it's it's just not a clear user experience so hopefully this will streamline that and um it also just kind of aligns with the general onboarding experience for ethereum users

64. 27:44

    um with you know that being prompted and especially with many different types of Wallets on your uh being browser based as well um it just seems to be a pretty pretty straightforward uh you know thing for the ecosystem so yeah it's a it's an approval and by me I've talked to a lot of wallet builders on near this will make their lives much easier get them to focus on the things that actually make

65. 28:07

    them different from one another um and yeah I mean I I haven't really seen many many big issues with this proposal so um it's it's an overwhelming yes for me awesome thanks Cameron what about you Osman um yeah um I think we had like a lot of discussion on the pr itself um there was some stuff with the interface as well that was really good about like signing transactions and stuff So like um like uh not constru not

66. 28:40

    having the dabs have to construct the whole transaction on their side and instead just providing like a list of actions or an optional signer ID was also a really like partially constructing the transaction yes they're all covered so yeah I think it's like a big yes for me like it's very useful for adopts to be able to easily um interact with uh root wallets very cool okay well I think that leads

67. 29:05

    us pretty smoothly into the voting stage uh you know we need two-thirds majority uh to move forward and I already heard this verbally uh that that we're living in that case but I'd like maybe uh an official working group member to maybe present the decision just so that we have that so maybe Daryl do you wanna yeah um so my vote also would be uh to definitely merge this as everybody can

68. 29:29

    probably tell since I took this over and kind of shepherded it the last uh The Last Mile so to speak um so we've got a yes from Austin and we've all studied yes from Cameron uh this is definitely going to improve things uh and give some clarity for folks that are building you know a lot of folks that are building the wallet sadly are looking at existing other wallets and trying to kind of uh stumble their way through how these apis should work so I think having a centralized

69. 29:53

    document for this you know this is one of these cases where centralization is really helpful I know one place to go to find out how all of this stuff should work so at this point we've got kind of a quorum here everybody is everybody is happy to get this merged I think this one's going to go into approved yes awesome cool well yeah we will definitely uh formalize the decision on the net itself right after this meeting and we'll also post uh share it out in you know our social channels and the

70. 30:23

    developer governance website just so that others can learn about it but yeah that's pretty exciting so I think also just to talk about next steps and implementation considerations I do want to move over to to the next slide over here and yeah Daryl were you going to speak to this one as well yep absolutely okay so so until this week uh the implementation for this was relatively

71. 30:46

    uh done actually there was already kind of code inside wallet selector that would Implement these apis um but now that we've added a couple of things um there's definitely some implementation to be done wallet selector currently is kind of this the the entry point for all the app development in the near ecosystem because of the fact that it connects to any number of wallets um so we're going to go and add uh top level accessors for the new features

72. 31:12

    like is supported Network for example should have a method that is passed through via the wallet selector interface that returns that result for the wallet that's currently connected those types of things and we have uh Sprint planning on Monday morning so uh right now it's Friday uh just for anybody who's watching this later so we're talking about three days from now uh we have a Sprint planning where I think that we're going to have resources who can step into wallet selector and

73. 31:36

    add those accessors so that if anybody does implement these apis the new ones that we just decided on earlier this week wallet selector will expose those upstream and if a wallet has not implemented those apis we'll decide on some uh what that behavior should be and wallet selector should throw an error just return false uh we'll we'll put that up in a PR and uh I will actually Loop the folks in who had added some comments on the pull requests for 408

74. 32:01

    and for 370 so that we can just make sure that everybody agrees on on the behaviors there inside the wallet selector since that's kind of the the gateway to the wallets of the ecosystem right now we want to make sure that everybody agrees about how those cases should end should be handled for a wallet that hasn't implemented that part of the uh the NP and just like a quick comment here that in terms of the implementation pretty

75. 32:24

    much anyone can volunteer to uh or like propose to implement some the agreed proposal either for free or you know even propose some kind of compensation that you expect to receive this is generally applied to not just even this work group but any work group oh that's a great call out that's super awesome any anybody want to do this work we'll see I think uh Cameron is connected with a lot of the uh the wallet standards Community groups and so I we could

76. 33:01

    definitely uh follow up with them as well uh after so yep and then now that this is merged also um we I'll do some reaching out uh for anybody who's already got a wallet so now that we have a standard API for this such as like request uh sorry side and send transaction or sign transaction these names of these methods have been uh normalized I know that uh some of the existing wallet code that we use in wallet selector has shims to call

77. 33:30

    different methods on wallets so there will also be simple requests coming from wallet Builders to conform to this API that will update their plugins there's a plug-in for each wallet essentially uh in the wallet selector so those are also PR's that we'll need to land these are kind of community PR's from the wallet Builders themselves once you got if you have any methods that don't exactly match up I think I saw in one of the wallet plugins there was a method called request sign transaction instead of just

78. 33:56

    sign transaction so this is an obvious one where now that there's an NEP that wallet Builder will update their wallet so the name of this method is find transaction instead of request sign transaction and then they will need to open a PR to wallet selector that then updates our usage inside of that plugin and this is actually really important because as I alluded to earlier on our long-term goals here is to have Dynamic wallet the list of wallets that you can choose from to be dynamic without

79. 34:21

    forcing the app authors to constantly update the wallet selector package and by conforming to these apis you are future proofing your wallet so that when we move to Dynamic wallet selection it will still show up it can still be interacted with because you've conformed of these apis so uh if if I have any advice for anybody who's a wallet Builder here it's definitely don't let this one fall behind or you might be

80. 34:44

    surprised when we go to migrate to Dynamic wallet selection we have hey now we can show up to you know 60 wallets or something like that dynamically without the d-app author having to publish out new code we don't want your wallet to be left behind and you right now have all the context for what needs to happen so the the minimal amount of effort is to do it while it's fresh in your mind you're not looking at reviewing all this

81. 35:07

    stuff like three months down the road or whenever we get to this uh this Dynamic wallet selection awesomeness cool I see a bunch of Thumbs Up and some uh fire emojis uh in the background so that's great yeah I guess I'd like to move on to q a open it up uh if anyone has any thoughts questions I'd like to add I'll give everyone a minute or so and then we can move on to the next step is that a question shot anything in the

82. 35:41

    works for wallet connector yeah awesome so yeah actually shot if you take a look in the wallet selector code base uh the wallet selector package actually has support for wallet connect uh at the API level so there's even a proof of concept for wallet connect uh POC was actually built by the same fellow who opened this PR uh the original PR for this uh NEP 370 and there actually is a bridge standard uh that was already published in the NEP repo that uh was actually built for that

83. 36:13

    purpose uh to Define compatibility with wallet connect and apis that follow the wallet connect standard uh so you can see that standard in the neps I'll just put a link uh actually it's in it's in standards in the Naps repo I'll put a link in the chat right now that just goes to that wallet uh documentation here's the actual Bridge wallet uh this was brought about before we had these working groups so if you have any yeah if you have any uh feedback on this

84. 36:43

    standard feel free to bring these up uh you know uh there's nothing is set in stone I don't think that anybody has fully implemented a wallet connect compatible wallet yet I don't think there's one live yet um so by all means if you want to use wallet connect try it uh Implement uh go forth and build and if you have any problems just let us know uh the wallet selector code base is where the plug-in

85. 37:08

    uh all exists and that is of course right here I'll put that in the chat as well um and you can see right inside of that um directory that I linked to you there's a wallet connect folder that has the wallet connect proof of concept uh so that is definitely something that we want to support I know that at least one wallet is working on building something that uses that API uh and I haven't heard from them they haven't they

86. 37:32

    haven't reported any major issues with it but I do want to give you just a you know a little bit of a disclaimer there that because I as far as I know nobody is end to end implemented this yet you might you might have feedback on it and should be totally reasonable if you do let us know all right so we did have a couple of questions come up in the Q a maybe we just take them one at a time so

87. 37:56

    the first one is from Paul and the question is for future Dynamic use could metadata such as icons and name Etc be placed on this injected interface as well hmm yeah absolutely um so for the for the dynamic usage actually one of the biggest problems that we have that we're looking to solve that is kind of tied to this piece of work is new wallets uh when we want to have a new wallet join in and we have this default wallets packaged people apply to have their wallet added to right now they're

88. 38:29

    kind of self-attesting that they've done some basic security auditing of their own code and have followed best practices um I believe that in the long term in my mind at least the perfect solution for this would be a Dao where actually the wallets that are able to be displayed the list of wallets exists on chain and is query by wallet selector using a view function call against the blockchain and then it pulls back some Json that

89. 38:53

    describes how that wallet works and that's it we're done and now when a new wallet Builder comes in you know right now we got a bit of a clunky process for these reviews we're opening pull requests for each wallet that we add it would be great if there was not a pull request for each wallet and instead people voted on a dow using an app that we built that allows you to vote and when a wallet has been voted to be supported it by the list of uh wallet

90. 39:17

    selector wallets then it just gets added to the response that you get when you call that view function saying give me a list of currently supported wallets or default wallets um so metadata for icons and name I believe that stuff in the long term will absolutely be part of this API and it will be I don't know if it'll go in this NEP like uh it feels to me like that could be its own NEP because of the fact that it's got this Con this persistence

91. 39:42

    onto the chain we're gonna have to kind of deal with the schema there um but that is definitely what we're looking at is defining these things in a declarative way it will absolutely include something like icons I was actually just talking to Jane earlier this week actually about um hey could we include an icon set and allow people to just give us a string which is what icon name would it be um and we could we could have that be uh part of the dynamic information and

92. 40:10

    all right uh the next question is from Leon will this affect wallet connect methods our wallet opto wallet has supported wallet connect currently awesome so this NEP is different than the bridge wallet so there is a bridge wallet uh standard that has already been landed and I linked that in the chat maybe maybe I linked it before you even sent this message I'll put it in there again just to make sure that it's at the

93. 40:36

    top so the bridge wallet standard does describe um the the interface for something that uses wallet connect and then the implementation that you've linked to here so the wallet selector um yeah that that implementation for the the near methods that is absolutely uh that is what we've decided on for our custom near interfaces so wallet connect 2.0 supports the definition of blockchain specific methods so you can

94. 41:08

    Define your own methods for each chain at sports while at connect 1.0 was all ethereum specific 2.0 allows us to Define these methods so the link that you just gave me there Leon is indeed the near specific methods that we've added that we've defined for the wallet can extended great thank you Daryl are there any other questions cat on Sandy so I think we're gonna move on so the last thing I just wanted to cover is how to get involved well first of all thank you all for being here that's a great way to get involved

95. 41:47

    just to kind of be part of the working groups see what's going on but there have been more ways to get involved that I wanted to highlight so uh if you if you already have a specific idea in mind for something that you want you know to to propose we highly encourage you to to author a nap and submit one uh or to join uh existing working group calls like the one we have today if you

96. 42:12

    don't know what you want to build another great way uh to get involved is to join other community groups which are basically groups of people from the community that that meet on a shared topic of interest you know from a specific idea to a concern or a passion Cameron has been involved with like three different uh Community groups for for wallet so if you're if you're not aware of them please check them out uh on the near governance uh Forum website and I'm sure Cameron can show some links

97. 42:44

    as well or if it wants to speak to it he can yep real quick um so there's a calendar uh that you can join and so every single subgroup meeting in you know General wallet group meeting uh these like Community groups Builder groups they're essentially places for well the builders to get together to identify the missing neps and strategize a plan of attack like how do we actually prioritize which neps to

98. 43:07

    go go forward with keep in mind that there are many verticals in this industry and so wallets are are one of them but by far one of the most important so I dropped the calendar in the chat here so if you want to sign up for that you will be able just to see every time that we meet next Tuesday we're having our general wallet Builder meeting uh that's sorry that's next Wednesday at 11 30 a.m uh it's central

99. 43:34

    time so 12 30 12 30 PM Eastern and uh yeah please come this is where we'll be talking about the progress that we're making with a potential auditing program as well as the wallet transition from uh wallet near.org to well every other wallet out there so um yep that's going to be the meeting where we uh keep everyone update and we also have a very active telegram where you can join and ask questions around about pending

100. 44:04

     neps as well as just like what Fiat on ramps you are native to near what kind of custody Solutions are available essentially anything well related can go into that chat so feel please get involved we're here for you that's awesome yeah and I've been attending some of those calls and it's just it's been really great to just hear ideas and again really hope that we get these ideas and turn them into nips and future improvements so yeah and you can

101. 44:29

     also start your own Community groups and all the information is available on neo.org developer governance and as Max mentioned also if you're interested in implementation we do have a form on that website that you can fill out and let us know and we will also post the recording from today on that website as well as future meetings as well so I just want to give one more thank you to everyone that has been involved

102. 44:52

     especially the the author the original author Lewis who spent a lot of time thinking about this this snap and of course to Daryl who helped kind of champion and take it over the Finish Line the working group members Cameron Daryl Osman the moderators and everyone from the community who has participated so really excited to to have this first wallet standards nip uh approved and

103. 45:15

     excited to decentralize the development of near together uh in more working group meetings soon so cool well I think that covers it for today I want to wish everybody a great weekend and thank you all again so much take care thank you