Wallet Standards Work Group Meeting – April 20, 2023

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

1. 0:04

   hey everybody and welcome to our third new wallet standards work group call my name is Ori and I'm a moderator from the near developer Dow team and I'm excited to discuss an epic extension proposal today here's our agenda first we'll discuss the objective of this call and I'll provide some more context about our developer ecosystem next we'll introduce all the participants that are involved then we'll get into the main discussion

2. 0:27

   net 428 and you can find the link for that in the video description if you want to follow it more closely and lastly we will open it up to QA and talk about next steps so to get started let's talk about the objective of today's call we are here to publicly vote and arrive to a final decision on NEP 428 which is a wallet standards extension proposal that was submitted by a Community member and we are also here to celebrate the effort and time that everyone invested into this snap as it did go through a

3. 0:59

   vigorous review by the community and many subject matter experts who all care about making our ecosystem better before we jump in I wanted to give some more context to help contextualize our call so when it comes to the near developer ecosystem there are many ways for people to contribute from submitting ideas to implementing code and we really try to bring people and organizations together to help innovate in a

4. 1:24

   decentralized way and provide social structure and tools to support that one of the main tools that we use is the near Dev Hub which is the main platform for new developers to contribute and stay informed and anyone is welcome to share their ideas Solutions and get technical support and funding you can also find various communities of people interested in specific topics such as

5. 1:47

   zero knowledge or tooling and it's really just a great way to meet with others to share ideas in addition to the informal Community groups we also have formal work groups who help make decisions on various ecosystem areas such as protocol contract standards and zero knowledge and these groups have recognized experts who engage with the community and help review proposals and answer questions in a fairly and timely manner for example they help make decisions on technical

6. 2:18

   proposals that you may want to get integrated across the ecosystem such as a new contract standards or protocol Improvement and you can submit an idea for technical proposing using a nap a near enhancement proposal and this is a rigorous process that is similar to other prominent open source projects like rust and it allows anyone to propose their technical idea for the ecosystem and when a new nip is submitted the relevant working group will help review and move it forward

7. 2:49

   in terms of the participants there are four key roles in the net process we have the author uh or champion this is the person who writes the proposal and presents it to the work group the moderator the person who facilitates the process and helps ensure that the net progresses the reviewer this is an assigned subject matter expert who reviews the technical feasibility and lastly the approver which is the working group who makes the final decision just

8. 3:15

   to visualize the the process there are three stages draft review and voting and two outcomes approved and rejected and all the roles mentioned before help move the net through these stages and towards the outcome most of the activity happens asynchronously on the net itself within GitHub but when we do get to the voting stage the work group has an open public discussion to arrive at the best decision in a transparent way which is

9. 3:40

   exactly what we're doing here today we've been executing this process and are looking at a proposal that's in this final stage so before we jump into the actual nap I wanted to highlight the participants that were involved in this snap so first starting with the author which is Amir thank you so much for submitting the snap next to moderator so myself and Vlad have been playing the the moderator

10. 4:03

    role on the snap and we've had two uh technical reviewers Joe and Andy and lastly the working group the wallet standards members which include sterile Osman and Cameron so please feel free to introduce yourselves in the chat or when you speak and with that I'd love to move to the actual net discussion 428 and invite Daryl who's going to present on behalf of the author who wasn't able to make it to the call a little bit about the net and why it's important so there

11. 4:34

    will please take it away sorry uh so I'm Daryl I work over at Pagoda I was originally hired to take over on the wallet team so I worked on the near wallet John wallet.net.org for a long time and these days that involved in acting onboarding so Integrations on near.org Discovery Integrations it's gonna be awesome um just to talk about what this NEP is all about uh for some context right now anytime

12. 5:07

    that somebody signs into a DF using the new api.js they signed into a specific smart contract this usually is just fine most the apps are made up of one smart contract but there are use cases where D apps now as they become more complex are spending across multiple smart contracts and interacting with one logical app might actually involve some big transactions from more than one smart contract

13. 5:35

    and this NEP revision or update it's meant to add a brand new method to our injected wallet standard which will facilitate this use case of a deact using more than one smart contract so the user when they actually sign into a deact will be authorizing that that d-app can sign transactions against more than one contract and this is part of the near blockchain um core the ability to create limited

14. 6:08

    access Keys which can only be used to interact with contracts specific contracts in specific ways it's kind of a special thing about mirror not all blockchains have the ability to have multiple keys on an account and as a result this is something that will really make it more flexible for d-app developers who are taking advantage of this this type of functionality the benefit of using these types of keys is that the D app can submit transactions without interrupting your user by prompting them the wallet to sign each

15. 6:39

    transaction that can be done that's possible because these types of keys can only do specific things by definition so you approve these keys to be created when you first sign into the D app knowing that from then on those keys will be limited in their scope and what they can what they can actually do if nobody can take your funds with a limited access key so we can do anything anything that can compromise your

16. 7:03

    account within the access keys so this will allow the apps that have multiple contracts to to easily facilitate or log into all of those contracts some DFS right now are all this themselves they actually have uh various hacks that you can do to try and pull this off but none of them are very seamless they are they're all very confusing to the user the user wants a nice easy to understand sign in prompt and it should be formatted in a way that makes sense for what they're doing uh

17. 7:32

    all of the workarounds for this involve prompting the user to sign transactions that may be confusing for them because it's not a sign in transaction it's not a sign in action it's a transaction that happens to do the same things as signing in for multiple contracts um so that's the that's the overall summary of this it adds just one new method it allows you to provide more than one key to be added uh to the

18. 7:57

    account when you sign in and that should give people whatever they need to build these types of more complex apps yeah awesome thanks so much Daryl for that summary and yeah as I mentioned before uh there was a lot of discussion asynchronously on GitHub and we had heard a lot of different comments and so there were benefits that were raised and concerns so we'd like to just kind of

19. 8:20

    summarize anything uh that Daryl hasn't already mentioned and I'd love to invite Cameron to highlight some of the benefits in more detail yep thanks Rory and thank you Daryl hey everybody my name is Cameron Dennis CEO of benue collective we help skill near in the United States I joined the ecosystem about two and a half years ago almost three now uh because of the year's flexible account model and this ability to give access keys to certain contracts and I think

20. 8:50

    that this is just a prerequisite to mass adoption to help abstract I mean to be totally Frank blockchain's really bad user experience away from end users and this is a pretty huge uh you know upgrade to the ecosystem so um in a nutshell this will make it easier as general already explained for users to interact with many different contracts um but the that's on the user side but on the developer side it does eliminate the need for a lot of developers to initiate multiple transactions and

21. 9:22

    create and check their output which is really helpful so you know overall this is a pretty straightforward update and um yeah I mean I'm super supportive of it uh this obviously is something that also uh sort of is an addition to a previous standard that was already passed um so yeah this is a very just key for the ecosystem uh it's just almost no no issues with it in my eyes uh and hopefully oh and also just to emphasize this is also be really helpful for uh the continuing development of Boss

22. 9:55

    widgets and components where everyone's going to be sort of interacting with like many different contracts with this blockchain operating system for those who not know um Ilya has some great threads on it on Twitter uh definitely now it's not the time for me to explain this but this is going to be very helpful for users and developers with this you know further rollout of the boss so yeah in a nutshell makes developer and user experience much more straightforward

23. 10:19

    awesome thanks Cameron so in addition to benefits there were some concerns that were mentioned uh so I'd love to invite Osman to talk through them hey guys I'm Osman um personally came to the near ecosystem to work on the wallet and now I'm working on devtools and onboarding so yeah um so there was a couple of concerns um so the first one was that like we don't want to like have gaps break current ups that are using the sign in method to

24. 10:52

    create a single access key um and that was resolved so we're adding an additional method as opposed to like modifying the current method to support both operation modes so that's the problem is the first concern uh the second concern was that we wanted to scope it to one account for sign in multi um and the thing is with this one is that like um there was so there was two things with that the first one was that um there was some ux concerns about like

25. 11:21

    multiple accounts being signed in to multiple contracts and showing those like success and failure modes and stuff like that um but the second thing was that um it's not Atomic correct so if you're sending transactions to multiple accounts that's not Atomic anymore um like for multiple access keys so that's multiple transactions so um so that was the second concern that was brought up

26. 11:45

    uh and the third one is that um that we don't want to allow users to be able to request sign in or sign in multi and request a limited access key for for one for a fungible token contract or any other asset contract really but many fundable token contracts and then drain the user's fundable tokens or assets for that without the user's knowledge um but then they're all brought up that that's not actually a concern because

27. 12:08

    the standard Dependable token standard actually requires that you add a deposit um which weren't a transaction with a deposit wouldn't you can't sign a transaction with a deposit uh with a limited access key so you'd require a full access key which would require redirect to the injected wallet or browser wall or whatever and uh so that invalidates that concern um so concern one and three are resolved

28. 12:33

    uh concern two is still in the middle I guess right so so those are the concerns awesome cool well now that we've heard uh the benefits and the concerns um I'd love to give an opportunity to each working group member to share their opinion and how they're leaning um which bring us to the voting stage uh and the the thing that we're gonna do a little bit differently this time is that we actually summarize the voting

29. 13:07

    indications from the GitHub discussion just to make it easier to sort of synthesize everything in one place so based on the the indications from from the discussion it looks like we well we need two-third majority to move forward with the snap and it looks like we had complete approval uh just from the discussion but I guess I do want to provide the opportunity now in case there are any other concerns or comments

30. 13:31

    that anyone would like to raise uh please feel free to do so so would anyone like to add anything so I think I can go ahead and just point out that there was a condition on my approval there that I do believe that we should change the signature to require login for a single account um rather than multiple accounts and as Osman mentioned the the drawback of multiple accounts is it's not an atomic

31. 14:03

    operation anymore uh to sign in with multiple accounts and also most wallets don't really have a concept of one UI for multiple accounts being active at the same time most wallets uh you have an active account and you're signing transactions you're doing it for that account so being able to approve for multiple accounts could add a big barrier to entry for wallets to actually implement this because a lot of wallets

32. 14:28

    would actually have to implement like some kind of dynamic account switching kind of thing flow in the UI might not make a lot of sense if they're just running around a single account but I just wanted to to mention that that was the thing that I had brought up in my comment was I think we should make it a single account I think that will still solve the problem because it's I think it's far more important that somebody can log one account into

33. 14:52

    multiple contracts and that somebody can log many accounts into multiple contracts at the same time uh I can agree with that I just like sign the sign in method also takes in multiple accounts so like if we if we do go forward with that I think we should update the sign and Method uh to take a single account as well um which is actually um the currently implemented version of that in near PHS as well selector 86.

34. 15:28

    so near api.js definitely has just the one account actually when you sign in you have to choose the account that you're going to sign in with yeah that's what I'm saying so okay but the the NEP has a sign in taking in multiple accounts as well so understood makes sense I think actually most wallets actually ignore the account anyway that you choose which account you want to sign in as

35. 15:56

    from a list ironically enough because most uh most the apps don't know which account request the whole point is the address which account you're actually not signing as so I think that's actually something that's worth noting account ID is not always required I don't think we pulled that out actually what's an optional parameter that might be something that we actually missed during our discussions so I guess is there can anyone from the

36. 16:31

    group sort of speak every however they grow up like the you know the formal sort of uh decision like is it is it you are approving it but with a condition to address this this thing like would somebody like to formally articulate the decision I think we both think that that we should we will approve it but sign in both sign in unsign in multi should take in a single account right

37. 17:00

    okay so that's the the decision to conditionally approve it based on on make on the author making that changes that is the author gonna be the person who needs to address that I can reach out to them uh we have meetings with them similarly so I can check them perfect actually that brings us uh into the next segue which is uh what are the next steps and maybe we need to update this but um yeah Osman did you want to speak to to this

38. 17:32

    foreign because we have the uh the interface or the output I think or input but we don't have the method signature under the wallet interface so just for clarity's sake uh and then as usual embed the benefits and concerns into the any P document um so the third one is uh is where we can start getting to implementation so um they're all about this up as well actually so near Pages doesn't currently have key stores

39. 18:06

    a browser local storage key store or any key store that uh supports multiple keys for a single account so we need to add a supporting key store for that or for adopts to be able to keep track of the keys they currently have uh and then so the wallet selector interface should add to its interface like a new method saying asking well let's implement this as well and um and yeah the last one is just the top wallet teams to implement it

40. 18:39

    awesome Osman could I collaborate with you after the call to maybe summarize these next steps and add them to the nap after our call yeah sure cool Perfect all right well I guess this is exciting we have another nap approved um or an app extension I should say and uh I guess with that I'd like to ask if there are any questions or comments feedback uh comments shout out to the subject matter experts uh Edward from meteor for reviewing um and please uh Ori who were the other

41. 19:18

    ones I want to make sure they get they get the shout out they deserve a hundred percent yeah Joe and Andy and this is actually a very good segue into my uh next slide over here which is a huge shout out to everyone involved you know it really we're we're trying to really decentralize uh how we make decisions uh but still there needs to be some kind of coordination uh happening and I think we are all participating and and leveraging each other's uh strength

42. 19:47

    and context to benefit uh the ecosystem so yes huge thank you thank you to the author Amir for for writing the snap the the subject matter experts that we just mentioned and of course the the working group members here uh yeah huge shout out so all right so just to close it off I do want to quickly highlight some of the ways that you can get involved in the near developer ecosystem first you can submit an idea using the

43. 20:12

    dev Hub or find other communities to to to collaborate with and if you have a specific idea that's technical that you want to get into the ecosystem or you're seeking funding you can submit a net after posting your initial idea on the dev hub and you can also view all of the naps in their various statuses on GitHub and join those discussions there's also a community group that you can join for the near wallet Builder group and that's a great place to connect with others

44. 20:45

    and you can learn more about the developer ecosystem and the near devgov website and our social channels and we look forward to seeing you all on the next calls thank you so much and have a great rest of your day