NEAR Wallet Standards Working Group, 17 Jan 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Wallet Standards Working Group Meeting – January 17, 2023

Description

Today the NEAR Wallet Standards Working Group met for the second time to vote on: https://github.com/near/NEPs/pull/413

Meeting Summary:
http://bit.ly/3kvv9hW

Chapters:
00:22 Agenda
00:50 Update on Developer Governance
07:05 Introductions
11:39 NEP-413 – Author Summary
14:03 NEP-413 – Benefits
19:02 NEP-413 – Concerns
39:11 NEP-413 – Voting
46:29 Getting Involved

Learn about Developer Governance:
Website: https://neardevgov.org
Twitter: https://twitter.com/NEARDevGov
Telegram: https://t.me/NEARDevGov
NEP Process: https://github.com/near/NEPs/blob/mas...

Join the NEAR Wallet Builder Community Group:
Telegram: nearbuilders.com/tg-wallet

Join NEAR's community:
Website: https://near.org/
Reddit: https://www.reddit.com/r/nearprotocol/
Discord: https://near.chat/
Medium: https://medium.com/nearprotocol
Blog: https://near.org/blog/
Twitter: https://twitter.com/NEARProtocol
GitHub: https://github.com/near https://github.com/nearprotocol
Dev Docs: https://docs.near.org/
Create a wallet: https://wallet.near.org/create
Apps on NEAR: https://awesomenear.com/
Learn to Build On NEAR: https://www.near.university/
Grants & Funding: https://near.org/grants/
#Blockchain #FutureisNEAR #NEAR #nearprotocol
#nft #dao

A

But hi everybody Welcome to our second wallet standards working group call. My name is Ori and I'm. A technical program manager from Pagoda and I'm super excited to kick off this group yet again and to discuss another wallet standard proposal today, so just to go over the agenda. First I will give a quick overview and some updates on developer governance.

A

Next, we'll do some brief introductions, as we have a few panelists joining us today, then we'll get into the main discussion at 413 and hear from the author Phillip who proposed it, and then we will open up the Q a and talk about next steps on how to get involved in developer governance, all right, so just a quick update on developer governance.

A

So over the last few months, we've been engaging with the community over this initiative, which is really about bringing people and organizations together to help build a decentralized developer ecosystem and empowering anyone to contribute from idea to code and we've been Bucking in most of the developer community activities into four areas. So ideation implementation review and support and I just wanted to quickly highlight them to help contextualize. Our meeting for today, foreign so starting with ideation. This is about sharing and exploring ideas with other people in the ecosystem.

A

So anyone can submit an idea like improve in the protocol or standards and it's important to have a place for people to freely Express and explore themselves and explore ideas in a welcoming and permissionless way, and one way to do that is in the developer. Governance gigs board- and this is a new uh platform on your social, for anyone to share their ideas to get feedback and support from the community. And it's still in the early days, but there's already a lot of activity on there and anyone who's interested can start posting their idea today.

A

Now, maybe you have an early seat for an idea or a topic that you want to explore with others.

A

So another great way to get involved is to join a community group, and community group is a group of very passionate self-organized people who are interested in a specific topic, such as zero knowledge, wallet, standards, Etc, and they offer a great opportunity for people to come together uh and just discuss, ideas and and concerns and things they want to uh help improve, and many of these groups have already formed and have dedicated communication challenge like telegram, as well as regular meetings and you're welcome to join any of those groups or to start from yourself, you can find them on the developer governance website and we're also going to be publishing a blog post, probably this week that will highlight some recent learnings and insights from a lot of these groups.

A

So what happened? If you already have submitted an idea, and now you want to turn it into code. This is where implementation comes in. You can also use the dev gov gigs board to submit implementation solutions to your ideas or even if you have an alternative solution in mind for somebody else's idea, you can propose that as well, and this is just a great way to gauge Community interest and supports and to get a variety of perspectives which really can help strengthen our Collective problem, solving and innovation.

A

Now, if you have an idea that you want to get integrated across the ecosystem like a new contract standards or protocol Improvement or if you are seeking funding support, you will need to get a more official validation from a recognized group of experts, and you can do that by submitting an app a near enhancement proposal, and this is a rigorous process that is similar to other prominent open source projects like rust, and it enables anyone to submit their proposals for review.

A

And you know this is actually what we're talking about today on call as and if those submitted. So what happens once you submit a nip and how does it move forward foreign?

A

So this is where the review comes in, which involves working groups like the wallet standards working group that we have here today and basically, a working group is a selected Committee of subject matter. Experts that help review proposals in a fairly and timely manner and oversee decisions, and there are multiple working groups each one focusing on a different ecosystem need.

A

We've already kicked off four of them to help bootstrap this process and we've been iterated on it for the last few months to kind of understand what works and what doesn't, and we hope to introduce more groups in the future and Empower more people in the community to to run them. So before we get into the actual call. Today, I just wanted to highlight the roles that are involved in the next process, as well as the the stages. So, uh on the rolls front, we have the author.

A

This is the person who writes the proposal and presents it to the working group. There can also be a champion who takes that over in case the original author is unable to uh continue. There's the moderator, the person who facilitates the process and helps validate that the proposal meets the guidelines and progresses forward. There's the reviewer, the subject matter: expert the person who reviews the technical feasibility of the proposal and then the approver.

A

This is the working group member uh who helped make the final decision and in terms of the actual illustration of this process, there are three stages: draft review and voting and two outcomes approved and rejected, and all of those roles help move the next through these stages and towards the outcomes, and most of this happens asynchronously on on GitHub on the nip itself.

A

But when we do get to the voting stage, each working group has a public meeting like the one we're having today to discuss the net with the author and to formalize the decision, and this is what I meant to show when I was talking about that we're here to to vote and have make a decision.

B

A

uh uh Lastly, I just wanted to highlight what happens when an app actually gets approved uh and how can the implementer seek funding, and that leads us to the last area, which is support So. Once the working group completes their technical due diligence and approves their proposal, they can use the developer governance, give gigs board to post an official attestation, and this tells any potential sponsors that there was a formal review done by recognized experts in the ecosystem and that any organizations or individuals can choose to sponsor that project.

A

So that was a very quick uh overview of the latest parts to developer governance and as I mentioned there, there are more blog posts come in. That will help kind of go into further detail and you can already check uh one that explains it on the developer governance website and with that I am super excited to jump into the wallet standards. Call today and I'd like to do some introductions uh and start with the working group members and I'll hand it over first to camera and Dennis.

C

Hey everybody how's it going uh Cameron Dennis here, I am the uh CEO of the Banyan Collective. It's a ecosystem management organization, dedicating to scaling near in the United States, but simultaneously I am uh still working at near Foundation, where I've been working here for the last uh two years, primarily on filling a lot of the core infrastructure gaps in the ecosystem, uh whether that be on-ramps, custodians, uh oracles indexers, whatever people need to actually build on here.

C

uh I was working on mainly on bringing new partners in and now I'm more focused on the social layer. So azori has eloquently described, uh making sure that there are clear paths for devs to uh get engaged.

C

So now it's about meetups and hackathons and standards and dinners and Builder days, and everything in between so uh super excited to be here and personally, very passionate about Management's, zero knowledge, uh Dows and I like D5 a lot too so a little bit of everywhere, but um yeah very, very interested in Key, Management and onboarding billions people went through there. You want to go next.

D

Absolutely uh so I'm Daryl Collins I work over at Pagoda as well. I was responsible for the near wallet code base for a while, after being hired um and I'm, currently working on the onboarding team, we're trying to solve the issue of onboarding people with zero friction or as close to zero friction as possible. uh I love, JavaScript everything, JavaScript I'm kind of one of those one of those strange people who actually enjoys the pointy education language, so I'm involved in everything JavaScript across the ecosystem. Here, if you go to as well.

E

Hi guys Osman from Pagoda as well, uh currently working on tools at Pagoda before this I was working on your api.js and before that, I was working on the wallet so yeah like a lot of clients, a lot of Standards, a lot of uh like uh apis and stuff like that that deal with linear protocol so nice to meet you guys.

A

Awesome, thank you all for for being here and for all the the work that went into uh reviewing the the nap and and helping kind of iterate on this process all right. So next I would like to introduce the moderators that are here, which is Vlad and myself so Vlad hello,.

B

Hey everybody yeah plus here you also can see my handle a lot under for all nickname on GitHub and on sticker flow. I'm I joined near quite early on one of the first engineers at the team and since the time I've been involved in all the engineering tasks, and lately I got involved with the the small, formal and scaling infrastructure like ecosystem task, which is the Delaware Gardens and nap. Specifically so doing all this work to help us going and scale as much as possible and Ori.

A

Awesome back to me uh yeah, so I am playing a moderator role in this process and yeah been super excited to just start. Seeing momentum, you know of the working groups and the nests and the community groups and there's more to come so I'm looking forward to it all right so now, I would love to introduce the author for the nip that we are discussing today, which is Nip 413, so hello Phillip. Would you like to introduce yourself.

F

Sure, hey everyone, um I'm Philip I've, been at near for I, think going to a year and two months now um started working originally on the wallet code base, um did some work on the JS SDK launch and currently working with the 2nd, so um yeah security.

A

Awesome yeah, thank you so much for submitting the net and excited to get to it, and I also wanted to just highlight that, if at any moments during the proceeding discussion, uh if you have questions or feedback feel free to drop them in the Q a button on the screen, you can also add your comments in the chat box. Just make sure to select everyone, because sometimes it defaults to just the panelists, and uh you can also.

C

A

Hand, if you want to speak with that, I am super excited to get into the next discussion, and we first will have the author uh Philip kind of present a summary of the nap and then from there we'll have the working group kind of uh discuss uh their findings and ultimately we'll get to the actual decision. So with that uh Philip, would you like to tell us a little bit more about uh your neck? Why you believe it's important Etc.

F

Sure um so the this nip is basically proposed in like a standard for sign in messages um using a new account for a specific receiver, so the this actually came up from like a request to enable like a means of authentication for accounts where that is not like results in in carrying any gas Visa having to be on chin. So this, um and you be basically purposes that we add, like a sign message, interface to the wallet API. That would allow daps sign specific messages um for their like contacts.

F

um Yeah. There are a lot of things should I would I need to run through like some of the things in the actual document, or is that something we're going to run? Yeah.

A

So Daryl give us a summary of some of the uh benefits and concerns story rates. So um if there's anything else at a high level that you want to highlight feel free to, but otherwise we can proceed once you feel like you're, good yeah,.

F

I think at a high level, that's that's exactly what it does um and so like in doing it, we had to like make sure to factor in, like all the security risks that could be introduced by like um making sure like people, there's no malicious, um there's no opportunity for malicious actors to perhaps make people sign things that look like um just a message.

F

What are valid transactions um also reduce the possibility of a replay attack where um people um the apps, could potentially delay um the signing of the message and potentially use that to stop like do things on people's accounts subsequently or perhaps submit this for for the activity on the account subsequently to the blockchain, so yeah I mean there will dive into more detail. But at a summary, that's some of the things we talk about when coming up with this.

A

Awesome cool, thank you so much for that summary and again for our first submitting the snap next I'd love to uh get into the actual uh overview from uh from Daryl on the benefits and the concerns that we saw and just for context for anyone who might be new to this call and this format uh that everyone has spent time like, including the community going through the nap discussing it on GitHub. And so what we're doing here is we're summarizing all of that activity.

A

That's that has happened asynchronously um and you can definitely follow along as well on the net itself, which is linked to the invite. So with that Daryl, hello,.

D

Good stuff, um so benefits for this one are pretty uh pretty huge actually from the ecosystem perspective, um one of the biggest things that people have had a had. A issue with on our current signing in process for logging into a d app is the fact that there's always a side effect.

D

There's an on-chain side effect to logging in, and one of the biggest benefits that we get from this approach is that there is no on-chain transaction executed, so you can authenticate somebody without adding an access key to their account, and this means that you don't have to pay for storage for an access key.

D

um This is a huge benefit for folks who have very little near in their account and they're, not looking to lock up additional near uh holding an access key and in some cases actually the apps have been written that don't actually need a limited access. Key. A really obvious case for this is some defy apps. Every time you need to do something you actually need to sign it with a full access, key to transfer some wealth around right.

D

You have some value and, having somebody add, a limited access key for a smart contract that you can't even call without uh having a full access. Key is just confusing to the user.

D

uh People have a it's kind of a dark pattern on the user side of things, because you end up with uh an approval for a sign in where it tells people that they can call a method on a smart contract that might not even exist, and it means that there is an overhead on signing in that requires that somebody has near available on their accounts that is burned in gas and also some amount that is then staked onto this chain uh to store this limited access key, and if the user then deletes the limited access key later, uh you know it's confusing to the user as to whether or not that will impact their usage of the app.

D

If I remove that limited access, key will I no longer be able to use that defy app. Well, actually, no you'll be you'll, be fine, because every transaction goes through a full access key anyway, so it eliminates a lot of dark patterns in the onboarding experience for somebody people signing in, and it makes it so that there won't be unnecessary gas burned on chain.

D

In order to authenticate that somebody owns a given your account, and it also is kind of convenient that it it would apply for an implicit ID that you may not actually have even created on chain. uh This can be used to to verify that you own any full access key for an account, regardless as to whether or not it exists.

D

uh This is also a really nice thing, because it allows us to implement uh authentication using JWT or a web authen type of uh challenge, uh signing response, so you don't actually have to use a transaction like an oracle. That is the chain in order to verify something. You get a signed message. You verify that it's signed with the key that that it says that it was, and you can treat that as an authenticated login for an app that actually doesn't use the chain.

D

Yet it's very useful for a progressive onboarding, where somebody may actually have access to an app as an identity, but until they actually deposit some near and want to interact with it in a privileged way. They don't need to worry about what that means for an on-chain account uh depositing funds Etc, and it also removes any kind of uh block delays. Now this is kind of a funny one, because you know block times on. Your are incredibly low.

D

uh Transaction execution does not take a long time, but it does mean that signing in doesn't involve uh waiting for finality on a on a transaction on the Chain. uh It makes error handling simpler. You don't have to worry about. Oh this transaction failed for some reason. Let's say you couldn't access our PC. This doesn't require RPC. Actually, so there is no dependency on external uh Network requests.

D

There doesn't have to be a a access key added to the account, so it eliminates a little bit of a delay there and simplifies the the mental model for any Engineers who are building on this stuff. If you're building a forum, let's say that you want to authenticate people that they own in your account, but they don't necessarily submit transactions against that in your account, you just want to use near for identity.

D

This is a really nice benefit to having this kind of assigning functionality, where you can verify that somebody owns the account without having to wait for a transaction and write the code that pulls hey, that transaction succeed or fail. What was the results of it? uh That kind of thing? So those are the high level benefits uh and on the drawback side of things, uh we have a totally a separate slide here that goes through the drawbacks, or the concerns I should say, are blockers.

D

Most of these have been resolved, so we've had really Lively discussion on the pull request. I have to thank everybody. Who's been involved in the discussions. This has actually been quite a quite a journey from its original concept. The original concept was very tightly scoped to a verifying ownership on the account- and this is a much more generic approach, that I think people will find more useful and the the major things that that were concerns were that there will be a possibility where there could be a division in support.

D

If a certain wallet does not implement this new part of the standard, then this could penalize a wallet that uh otherwise would have users logging in to a d app. If the d-app only allows logging in Via this new method, then there will be a split which login, which wallet can I I log. In with to this to this particular D app. Well, you can only log in to that D app with a wallet that supports the new uh extension to The Standard.

D

um This is definitely a concern. uh Our our recommendation is that the apps should have a a happy fallback where, if somebody wants to choose to use a wallet that actually adds a full access key or a limited access key, then that could be an alternative way to sign in there's no requirement that this is the only way to sign in, but the user, of course is going to see that extra friction they're, probably going to put pressure on their wallet Implement her to go hey.

D

Why don't you support this functionality uh and it should motivate motivate those wallets to implement the easier, lower friction way of signing in the uh the idea that uh wallets are obliged to implement the the standards is also one that we that we talked about so in in order to be listed in wallet, selector, there's some requirements uh around uh Security reviews and implementation of basic apis that the wallet selector has to use and at some point here this new functionality.

D

This new API call can be required uh to implement or to support a wallet in wallet selector. That would add a an extra API call. That is the base standard API that wallets need to implement into their support for wallet selector in order to be listed in the the list of wallets that you can log into using wallet selector.

D

So this can uh provide a little bit of a nudge towards the the wallets to say if you want to be listed in wallet, selector the whole point of wallet selector being an easy way of providing a compatibility layer for all the wallets in the ecosystem to be able to work in a consistent way, then you need to implement this API in addition to the ones that you had implemented in the past and the the second major concern was well by removing the sign in creating an on-chain key where reducing the number of transactions that happen on chain.

D

So right now, every time somebody signs into a DX there's a transaction submitted on chain that has an access key to their account to prove that they own that account. And if everybody started using sign message, then there would be less transactions on chain, and this is a true. This is true, however, we're we're not trying to index towards usage of the chain on authentication. You know as it requires as a benefit towards the the chain or as a driver for train on chain usage. On-Chain usage should be driven by organic usage.

D

That's necessary things that actually make a difference. Transactions that are valid, that add some kind of value to the user. That need an interaction with the blockchain and there's.

D

There was some discussion about this, but the general uh consensus was that this is a a good way to be moving there is there is a reduction in transactions, but also it's also worth considering that most d-apps or many D apps still will need a limited access key to give you a smooth interaction with their smart contract with background transactions that you pay gas for without having to constantly be interacting with the wallet.

D

uh This is a different way of authenticating that will likely apply to a subset of apps anyway, if you need to be able to submit transactions with a limited access key, then you'll continue to use the other API and the user will still get a limited access. Key and it'll make sense to them. Why they're getting one because they're using a d-app that uses transactions on chain, so this will simply simplify the mental model for users as well.

D

uh Third, one was one that I had actually brought up in uh my final review of the NEP, which is currently signing a transaction as a receiver. Id, that's used a receiver of the transaction, the Target that the transaction executes against and receiver is a key on this payload that is being provided to the wallet to be signed as a message. So there's some uh similarity in terminology, but a difference in logical meaning between these things, because receiver in this NEP is really it's the requester or the origin of the request.

D

There's not a smart contract online that receives this. There is no transaction so having the name of a receiver. If somebody is looking through a near documentation, they may pull up the signed transaction documentation and right next to it the sign message from documentation and it could be easy for them to conflate the two or get confused about the difference between the two. Well, how is time message receiver not like signed transaction receiver? Isn't it an account? Isn't it a transaction? uh It adds if you're doing, Search terms, searches.

D

You know indexing via Google or something or looking for um posts on stack overflow, low you're going to get interleaved data depending on which trial, which kind of an API call you're. Looking at and my suggestion here was: can we just change the name of receiver instead of having receiver? Let's call it something that is more specific to this API, which is my suggestion, was requester or actually, if we want to be uh even more generic earlier I was talking about the implementation of web, often or JWT.

D

We could use origin, which is what web authent uses uh as its challenge it uses. Typically, origin is the domain that the request is coming from and we will probably have a similar kind of a pattern in this usage of this feature where oftentimes the receiver would have been the domain that it came from if you own a d app on that has its own domain, or it might be a string that somebody comes up with on themselves.

D

You know my app my awesome app, you know whatever that might be so that was my suggestion was that we just made a slight tweak to the API so that we don't have this similar but different kind of a argument and, as a result, we separate out the documentation concerns and the mental model is easier for people to understand. This is signing a message.

D

Somebody requests that you sign the message that comes from somebody: it's not a target of a transaction that you're signing uh that's currently unresolved and that I didn't see uh some feedback on the final review. For me, this is not a blocker. This is not something that I would vote against the NEP. If we don't change it, but it feels like a really low. Friction.

D

Change something that's trivial for us to modify since nobody has implemented the spec and I think it would be helpful just from a a a conceptual standpoint for those who are understanding how this works, um the other one was uh brought up, I believe actually by Osman, and that is the NEP should emphasize that nonce and receivers should be displayed to the user in signing requests by wallets.

D

So if a wallet receives an IPI call for this sign message, Api on the screen that the wallet displays, we want the wallets to be encouraged strongly to show the user relevant information that lets them understand what they're signing and why they're signing it and by including the nonce and the receiver. Both in that information, we show the user context that they can use to understand. Do I want to sign this message. Is this a safe message to sign uh and who, who is the person who's requesting? This message?

D

Nonce is very important from a security standpoint to avoid replay attacks. You want the nons to be unique, each time, there's a signing request and it is possible that somebody could implement a d-app that uses this API in an insecure manner. They could use nonsense that are not unique, and if they did that, then we could run into a situation where security of this functionality is compromised. You don't want to be signing multiple requests with the same nonce. uh This is a a bad idea. Cryptographically, you want nonsense to be unique.

D

The whole point of nons is number only used once you want that to be one and only one usage. If you have people signing messages that have the same Noms over and over things, get really freaky from a security standpoint, you can end up compromising your actual full access, key, um the underlying key that you're using to sign them. So it could be helpful to show nonsense just so that the user could say. I've already signed a message with this month. I don't want to cite another message with this nonce.

D

It would be up to the user to keep track of these things, which this is the kind of um uh discussion about like well is this: is this noise to the user? Is this helpful to the user? The user would have to be paying attention to this and they would have to know that they'd sign things repeatedly with the same nonce.

D

um However, that was the the reason for this concern was it can compromise the security of the of the signing if you sign a bunch of messages with the same nonce over and over, um and the last thing was uh not really uh a concern or a blocker. Actually, it's the fact that we should extend our injected wallet API to document this new method right.

D

The injected wallet API is what most people are using in the wallet ecosystem currently to implement extensions, and in fact some people have used the injected wallet API with like a bridge to implement against uh wallet, API wallets that are web wallets. So we should. We should update the injected wallet API once this has been approved to describe how the signed message should be implemented in injected wallets and that's true.

D

We absolutely should, but it's also out of scope for the approval of the underlying NEP that we're talking about, which is this API, should sign message exist as a defined uh interface that people can implement, so that was uh resolved.

D

So at a high level, I think um the main things would be at this point discussion around um voting, there's I've noticed, there's been some mentions in the chat uh from folks that are saying.

B

Let me just bring to attention the comments from the chat so for.

F

D

B

uh That we are on the same page, so jalarma commented that uh the following I do agree with changing the receiver for another name, but I do not like the requester or region since they talk from the respect perspective of the person receiving the message. I would instead propose recipient I'm, sending it to someone which is perpendicular to somebody asked it to me it from me.

B

uh What do you think uh is there a do? You think it's worse to discuss um this like naming um during the call, or maybe we take it offline? uh uh What do you think they're all Osmond Cameron so.

D

Personally, I don't have a strong opinion around around the exact wording. My main, my main goal is to not have the exact same wording as the signed transaction I'm, totally fine with recipient as a as an idea. Instead, uh origin was mainly as uh a benefit in my mind and that it overlaps with web often so, since this pattern is basically the same as a web, authent authentication, uh it seemed like it might help people kind of build a mental model of how this works in a familiar way.

D

If they've implemented web often before but I, don't have a I think recipient could work just fine on on my side. I, don't have an objection. There.

E

um I think um like receiver and requests are sort of pretend or or hint that it's in their account ID, where, um like I, don't think it's necessarily A near account ID in this case right so like I like origin, a bit um more and I. Think receiver also implies that, like we're, sending a transaction as well like like Daryl, pointed out um so so those were. Those could be the things that we think about will come up with the naming here like um that. This doesn't need to be in your account ID.

E

It could be like a website. It could be anything and then the second thing is like um we're not sending a transaction here right so, like you, wouldn't complete that with other uh send transaction methods. Sorry about the background.

B

I'm completely out of scope here, but maybe a referral is uh something that we can reuse from the web world of web to world. Is that the term we are looking for.

D

I think referrer would might confuse people as well uh because they usually refer as a domain. uh You know people think about that on the request side of things on the browser uh apis, and in this case it's it's going to be an arbitrary string, we're not requiring that it is a domain it could. It could be. You know, by the name of my D app.

D

Actually um that's one of the reasons why I'm kind of hesitant to use origin as well because origin in web in web authen really is the domain that things are coming from. It's almost I think it's actually even articulated in some of the specs that it should be the uh the domain and that's not always going to be the case for D apps. You know, if you have multiple D apps in the same domain, then they should actually have different origins or different uh requesters. So it's this is a kind of a tricky thing.

D

My my I don't have a strong opinion about where we go other than I. Think we shouldn't have it be the same thing as signed transaction.

A

um Okay, well, do we want to uh continue discussing this part or maybe table in it to the end? uh Do you think this is like blocking us from moving forward with a decision or at this point.

E

F

That's not a blocker for me.

C

I do like what Guillermo is saying about the word recipient. um It does I think help clarify a lot of things, but I don't think this is I think this could be formalized. uh Office call and shouldn't necessarily be blocking the decision.

A

Okay, um maybe um Guillermo, if you're up for it, maybe we can come back to it just to make sure we get through the the rest of the call, but like I'd love to uh yeah. If we have time we can maybe take, you know uh have a five minute sidebar at the end, uh or we can continue it uh yeah on the nip itself. That's a great idea as well, so.

D

I feel like we could do a uh just a final vote on the NEP itself, for the people who've been contributing and get a get a you know. Abc here are three options and see see which one wins great.

A

Thank you awesome and then uh was there. Another comment, Vlog that you wanted, that that you thought was relevant. uh I saw Paul, it was who was I. Think I saw on I'm scrolling back I.

B

I think it was Paul um who commented the following: uh I think nonce will not be easy, comprehensible from the general user perspective. Is it just a bunch of random bytes kind of hard to keep track of the human reading? The interface and I.

F

B

To agree and I think well, they're all you what what you just brought here is that, like we assume uh humans like users, would need to be in charge of checking that they are not signing the same nons again, we probably can have a like a cached uh list of used nonses uh with exploration in local storage, and that would be it's.

E

um So David actually brought a good point on the pr um when we were talking about this and um the nonce. The purpose of the nonce is actually to for the caller, so so that the caller, um so that the the the the wallet or the user doesn't actually resend a signed message that the caller requested earlier. So that's I, think that was the main idea behind it.

E

But this is a secondary idea as well, where uh the user doesn't send, doesn't sign a multiple of the same nonsense so, uh but the main purpose of the nonce is actually so that the caller um doesn't receive a sign, an already signed message. That's um that's signed with a different notes or or delayed or like let's say the caller asks for a signature, and then um the user um like keeps that signed message and then resends it.

E

If there was no Nots, then like the koala, wouldn't be able to tell the difference between the two signed messages. So that was the replay attack that um the NEP author had in mind. I think.

D

Yeah, that's definitely true, so there's two different concerns. One is replay attacks and then the other one is the security of signing many things with the with the exact same nonce and the same key being a security uh concern.

D

um I I actually really like that idea of Vlad that the wallet itself could be encouraged to keep track of nonsense that are signed with a particular key, because the wallet knows the key, that's being used to sign the transaction or sorry. The message in this case and the wallet could actually ball at signing the same. uh Multiple messages with the same nonce I actually would be a big fan of just adding that as um some wording to the NEP. That says we encourage the question then becomes.

D

Is it a requirement for implementation, or is it a strongly encourage uh Implement that be implemented for the wallet.

D

E

I think it would have to be.

D

Strongly encouraged.

E

At least it's like um it's like it would have to, it would have to keep track of the same nonsense for a receiver right. So it's like. If if it gets the same non-sport, this particular um requester, um then then it rejects, but then if it gets the same knowledge but for another requester, then it's fine.

D

Yep I think we should add that to the wording, I think that would be awesome. uh You know the wallet should we should reject multiple messages for the same recipient that have the same logs. uh How much they're able to persist? I mean this is obviously a scalability thing. Can you keep a log of absolutely every single one and there's concerns around well what, if you're on two different machines, uh but you know best effort on the on the wallet side? All of those are implementation. Details.

A

Perfect, um who is going to take that action? Is it going to be fill up as the author you're, going to go and incorporate that.

F

A

Thank you and then yeah just for we definitely will post this call as well, but I guess um you know. Whoever has spoken today, I think Paul Guillermo feel free. To also add your comments on the nap just again, we want to make this create visibility. You know we know that there are a lot of time zones.

A

So not everyone can attend the call, so we just want to make it really fair and transparent so, but really appreciate all of the input and and the summary Daryl that you gave on the concerns and I think now that we've heard uh all of those I'd love to now hand it over to each uh working group member to present their opinion, how you're leaning, uh which that which brings us to the voting stage of the call so who would like to go first.

C

A

C

So yeah cltr uh I support this as a user of a lot of newer, apps, uh I'm, always looking for better ways to streamline The Experience um I. Also think that this is going to be. You know really helpful for a lot of dap developers to uh help with uh connecting with I guess, yeah extremely experience with other wallets, removing the delay for users uh Progressive onboarding. We talk a lot about in our wallet Builder groups um an exciting easier overall, like this is almost a no-brainer uh for me.

C

So it's a yes for me and yeah I, don't know if you have any other questions uh about my thoughts feel free to just at me in the GitHub repo.

C

Yeah I could pass it on to awesome.

E

Okay, um so yeah for me, I vote Yes as well. I think it's like this is a different function from like access, key Edition and the fact that access key Edition has been is being used for this um like it's, because we don't have standards for it yet. So this is the right way to approach it and it's a completely different functionality and it's I think been widely requested and so yeah. Definitely, yes,.

D

Good stuff, well I'm, also inclined to vote Yes for this I think it's a huge Improvement uh as far as capabilities for the apps that don't require limited access, keys and I. Think it'll eliminate some dark patterns on the intro.

A

All right awesome, so I am hearing a unanimous uh consensus. It seems like and uh with that seems like this. uh Nep is officially approved by the working group. Members, yes and I just saw Shop's message. Is this another pass another net three in less than a week? Yes, I can't believe it either. You know when I first joined uh several months ago, you know there were some nips that were just kind of hanging out for several months and it took a lot of time and effort to even just get one pass.

A

So this is definitely um you know, representative of every single action that that everyone on this call, including the attendees, uh have taken just to kind of help align. So thank you super exciting and thank you Philip again, but before we go to thank you, the next steps yeah. Actually, let's talk about next steps, so uh uh Daryl or Vlad can one of you stick to this or anyone else.

D

Absolutely so all the wallets you're going to need to implement against this uh API, and this actually dovetails very well with our earlier concern of the injected wallet standards- should have this added to it, so that people know what to end to actually Implement against. So as soon as this has been approved and merged, we're going to want to have a follow-up that adds this to the injected wallet standard.

D

I, don't think that needs to go through a major uh review process, because it's an implementation of this NEP, which we've already reviewed and approved, so that can be I I'm happy to follow up on the injected wallet and just get that PR created. That actually has a proof of concept of this. So people know what to implement and once that's been merged, then uh it needs to be broadcasted into wallet teams. So all of the people that are in the wallet Builders groups in telegram. That would be the obvious uh audience for this.

D

People who are building wallets need to be made aware that we have updated the injected wallet standard and that they should implement this stuff into the injected wallet standard. uh That they've, uh that they've conformed with on their existing wallet, implementations, that's something that uh maybe I'm not sure who would be the best person to to socialize that there maybe Cameron.

C

Yep, we actually have a call in 15 minutes with a bunch of wall Builders, so we can get that moving ASAP.

D

Good stuff, so once we've told them about that, then the wallet teams themselves are going to go through and just add support for the sign message, which will be a little UI that responds to this new API call that shows the user that they're signing a message.

D

It can explain to the user that they're not executing on chain transaction, maybe give them a little bit of information about why they're signing a message, it's verifying that they own the account and they will Implement that and release it into production and as they do that they will then update their corresponding wallet implementation in the wallet selector package. So wallet selector is the central place where everybody implements or ties their wallet, implementations to the actual client that the app developers use.

D

So once the wallet team is updated, their wallet to support this API, they will open a pull request against the wallet selector repository that updates the the ads to their Plugin or their module. The support for this uh this method, the sign message, method.

A

Awesome cool yeah and uh one new thing that we've been adding to naps is also yeah summarizing the benefits and concern section.

C

A

The nap itself so Philip I can reach out to you to see if you want to partner on that, uh and I can share with you an example from another nap but yeah are there any other comments? Just the next steps.

A

Okay, cool, so I just wanted to open it up to q a um does anyone have any questions or feedback just on the overall process, and the call definitely would love to hear.

B

While we're waiting for other comments, I just want to communicate back the chat um message it there. So there was a background conversation uh continuing on the receiver naming and my proposal was that we could have actually two terms, one for devs, which we would call a region and another for regular users on the wallet interface and we can easily also communicate it with the within the map, and that would probably solve it again.

B

Our problem right now, but uh that's just the proposal I think we'll uh have it over the GitHub discussion anyway, um so feel free to chip in.

A

Awesome, so we did get just a comment from Guillermo so happy to see the snap moving forward. The new wallet is about to get even more awesome and yeah. That's super super great, so uh cool with that I'd love to just quickly talk about ways that all of you. Anyone on this call can get involved further.

A

So um if you uh have an idea that you want to get integrated, um if you just have a general idea that you want to collaborate with others around, you can use the dev gigs board as I discussed to post that there. You can also add solution.

A

Implementation proposals, Etc if you have an idea that you want to get integrated across the ecosystem, that's where you also need to submit a nap or also, if you want to seek funding and then, if you want to see all of the existing naps discussions that are going on, you can check out the kanban board on GitHub that shows all of the the nips by each working group. So you can filter it down to the wallet standards group and see all those depths. And then, of course, there are.

A

There are Community groups, so there's the near wallet, Builder group that actually Cameron and Sean have been leading and it's been just getting a lot of activity and uh momentum. I, don't know if Cameron or truck you want to say anything, give applaud.

C

uh Absolutely so, uh if you just go to nearhawks.com builders, you can check out all of the Builder groups that the Banyan team helps run uh well, actually there's many of them on that list that we don't uh potentially run. But the whole point here is if you're, a founder or Builder focused on a certain vertical, and you want to connect with other builders interested in that same article.

C

There is a weekly call for you to join, there's an online community for you to, like you, know, collaborate with, and we unpack a lot of future standards here and get the feedback from the community on what they think about the standards before you would start drafting this as an NEP, so um yeah joined it's totally accessible to all Builders. Now we did want to rename it wallet Builder Group after we named it originally wallet community group, because we just had a bunch of people join that just say: hey I'm, part of the community.

C

uh These groups to be clear, are for Builders, and so, if you're interested in uh building wallets and collaborating with other wallet, Builders join that one. We also run nft one Dao D5 and that's.

D

C

It and so there's a bunch of other ones that you can join so next call is 10 minutes from now, so uh we're shot by the way huge shout out to shot for putting all this a lot of this together uh wallet builders near builders.com, too, is a good place to go go so.

C

Thank you, Rory for giving me time there.

A

Amazing yeah: no, this is great cool. Well, uh so just uh if you want to learn more about developer governance, please bookmark our website follow us on Twitter, Telegram and yeah. Also, there's a remind I wanted to give a reminder for the first tools working group, which has happened in this Thursday, we're actually going to be doing it in a slightly different time zone, that's more accessible to our uh community in in Asia and parts of Europe.

A

So um if you happen to be available during that time would love to see you there uh and with that I would like to close by giving a humongous shout out to Philip for taking the time to write this nap and bring It Forward yes, uh Daryl is is doing the hearts uh uh emoji with the hands uh which we all are we're very grateful um uh for for that, and then the working group members Cameron Daryl Osman.

A

You took the time to also think through the snap and add your perspective, which were appreciate the subject matter: experts, Peter Paul, who spent a great amount of effort as well thinking through the benefits and the concerns which helped Daryl and the working group members. Also think further through this snip and then the community that was involved, this Cameron already gave a shout out to Sean and I wanted to Echo that as well uh he's being very active, especially like the wallet, um the community groups and Beyond. So super grateful and yeah with that.

A

I want to wish everybody a good week and give you some time back in case. You want to prepare for that next call. So thank you again and take care.

B

I think we from the comments. We also want to give shout outs to guilmer who worked a lot and that it contributed to the snap so yeah one thanks for uh for the community to also recognize uh each other, and definitely it's worth to uh get everybody to the same page, and thanks to all this effort, we we can move forward some kudos to everybody. Thanks.

A

Yes, cheers take care.