NEAR Contract Standards Working Group Meetings, 21 Apr 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Contract Standards Work Group Meeting – April 21, 2023

Description

Today the NEAR Contract Standards Working Group met to vote on a couple proposals:
➡️ https://github.com/near/NEPs/pull/452
➡️ https://github.com/near/NEPs/pull/469

Meeting Summary:
[Coming Soon]

Chapters:
00:20Agenda
00:48 Objective
03:49 Introductions
04:40 NEP-452 – Discussion
35:47 NEP-452 – Decision
42:47 NEP-469 – Summary
49:08 NEP-469 – Decision
50:49 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/master/neps/nep-0001.md

Join the Contract Standards Community Group:
Telegram: https://t.me/nearnft

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

A

And Welcome to our fourth near contract standards, work group call, my name is Ori and I am a moderator from the near developer. Dow team and I'm excited for us to look at a couple of net proposals today and make a decision about them.

A

So here's our agenda first we'll discuss the objective of this call and provide some context about our near developer ecosystem, as well as the net process. Next, we'll introduce all the participants that are involved and then we'll get into the main discussion of neb, 452 and 469.. You can follow the links for those in the video description and after we will open a doctor qaa and talk about next steps so to get started.

A

Let's discuss the purpose of today's call. We are here to publicly vote and arrive to a final decision on net 452 and net 469, and also to celebrate the effort and time that everyone invested into these naps as they went through a rigorous review by the community and many subject matter. Experts who all care about making our ecosystem better before we jump in I want to give some more context to help contextualize.

A

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 bring together people and organizations to help innovate in a decentralized way and provide social structures and tools to support that, and one of the main tools that we use is the near Dev Hub, which is a platform for near developers to contribute and stay informed, and it used to be called the gigs board.

A

But we've recently changed the name to help better communicate to the concept and more changes are coming soon. But in the meantime, anyone is welcome to share their ideas, Solutions and get technical support and apply for funding. You can find various communities of people interested in specific topics on there, such as zero knowledge or tooling, and it's really just a great way to meet with others to share ideas.

A

So, in addition to the informal Community groups, we also have formal work groups who helped make decisions in various ecosystem areas such as protocol and contract standards, and these groups have selected recognized experts to engage with the community and help review proposals. In a thoroughly and timely manner, for example, they help make decisions on technical proposals that you may want to get integrated across the ecosystem, such as a new contract standards or protocol Improvement.

A

You can submit an idea for a technical proposal using an app a near-enhancement proposal, and this allows anyone to propose an idea to the ecosystem and when a new net is submitted, the relevant working group will review it and move it through our next process, which includes these four roles: author moderator, reviewer and approver. The author is the person who writes the proposal and presents presents it to the working group. The moderator is the person who facilitates the process and helps move things along.

A

The reviewer is an assigned technical subject matter: expert who reviews the technical feasibility and then the approver is the work group who makes the final decision in terms of visualizing the next process. There are three stages: draft review and voting and two outcomes approved and rejected, and all the roles that I just mentioned, help move the net through these stages and towards the outcomes, and most of this happens asynchronously on GitHub.

A

But when we do get to the voting stage, the work group has an open public call to arrive at the best decision in a transparent way, which.

B

Is exactly what we're doing here.

A

Today, we're executing this process and and getting into the final voting stage on those two naps so before we jump to the net themselves. I wanted to highlight the participants who have been involved in those two naps. So uh first, we've had two authors. So Ben is the author of net 452 and laquan. Is the author of net469.

A

I played a moderator role in the process and we also had uh some subject matter: experts that were assigned Joe and Olga, and then we had two working groups that actually looked at the net.

A

The the main one was the uh the contract standards work, Group, which is made up of Vlad evgeny, Alexander and Robert, and then we also had a representative from the wallet standards group Cameron, look at it as well, so just in the interest of time we're going to skip formal introductions, but please feel free to say hi in the chat or at least when you speak up just a quick hello and with that I'd love to move to the actual neck discussion um and I'd love to start with neb 452 link drop standard and invite the author of dotnap to present a summary of of the nap and why he believes it is important.

A

So, with that I'd like to welcome Ben today,.

B

Thanks for thanks for uh for the introductions, um yes, I mean I've, been working with with link, drops and sort of contracts for a very long time now um and with that came uh a need for a standardized interface, because you're going to have all these wallets and all these link drops out in the wild uh and just for a brief introduction of like what like what the heck is, a link drop.

B

It's it's essentially a way to embed assets within a link uh and it's a wallet, agnostic solution to transfer assets and to create accounts uh using nears access, Keys um and it's a really powerful tool. It's been used for years, um but historically, all of the link drops lived on the one route near contract and on the test net contracts.

B

um So you know, as as companies and as projects and apps started to sort of push the boundaries and um you know create custom link, drop implementations. You had all these different link drops with all these different interfaces out in the wild and from a wallet's perspective, or from uh as I like to call them claim page perspective. If you have an arbitrary link drop, which essentially just a link containing like a contract and a secret key, how do you know how to claim it right? And so we needed to provide an interface.

B

That's standardized to allow for arbitrary link, drops coming from any link drop creation platform to be able to be claimed. So, for example, like key Palm makes link drops near drop, mix, link drops the you know.

B

Route near contract makes link drops if all these link drops coming from all these different sources and they need to all be claimable by wallets um without the Wallace needing to know like each individual implementation of how each of these different contracts do their things um and yeah, and it's it's becoming more and more important as more wallets come out and as you know, the blockchain operating system comes in to play, and you know you're going to have all these different platforms everywhere.

B

Claiming and sending assets and stuff like that and Link drops are pretty cool for cross-chain compatibilities, and so now is the time uh to standardize this and to make the updates before before it gets out of hand.

A

Awesome thanks so much man for that intro and also for for writing this snip uh and working through it. So I.

B

Guess really really briefly: I also just wanted to give a quick shout out to Ken, because I worked. I worked a lot with Ken miyachi on on this uh on this standard, uh so I think he's in the call, but uh but yeah thanks thanks again for for the hard work we hopped on some calls and sort of um developed out some of these Solutions together. So thanks.

A

Yes, thank you so much Ken and for for being here today as well. uh We appreciate it so I guess, um as I mentioned there were a lot of uh you know, async discussions on the net itself and some benefits that were raised. So if there are any other benefits that maybe you haven't mentioned, maybe you could quickly highlight them just from the discussion. Yeah.

B

So I mean we've: we've created this this standard um in a way that is very extensible like a very, very good examples: we're working with minor wallet uh right now to extend the standard um and have like a custom, key Palm standard, which introduces like trial accounts that can be claimed by a link drops anyways. We've we've written the standard in a way, that's very extensible for all these different types in the future.

B

um We've also tried to make it backwards compatible as much as possible with existing implementations.

B

Just because we've had link drops for so many years and there's all these platforms out there that you know are assuming a certain Behavior, so we wanted to try to make it as backwards compatible as possible, but for the purpose of this NEP, um specifically in the past, it's just been sort of near link drops so embedding you know a set amount of near tokens in a link and sending it to someone where they can claim it with an existing account or create an account and claim it there all atomically, but with this NEP we've we've taken that concept and we've expanded on it to introduce support for fungible tokens and nfts embedded within links.

B

um There are some really cool things that we can do in the future. To expand upon this even more like introduced function, calls where, when a link drop is claimed, it executes an arbitrary function, uh I guess it's predefined by the funder, but anyway, so um that's kind of a high level overview of of this specific standard.

A

Awesome, thank you cool. So, in addition to the benefits there were various concerns raised throughout the discussion and I'd love to invite a couple of the work group members to maybe talk through.

C

A

And see if we can yeah resolve any of these, so uh yeah I guess Alexander did you want? Were you okay with starting or did you want me to start with uh Roberts list of concerns?

A

Where should we start.

C

um I think we can start with that table um yeah with this one um I I like I, think overall, the nap looks pretty decent.

C

um However, just had many questions related to technical details, um like personally I was not familiar with the link drops, um and uh so there were questions uh like I think the first one like, for instance, why they have to add the public key into the contract, account and so on.

C

um I think we fixed um many of the uh of our comments, and um still there are a few ones to unresolved ones: I'm, not sure how to proceed from this point, as we have probably the first session in this format, I would start with probably the most uh like important one uh I think this is the number seven and um it's something still not resolved, so we have a few options: how to define the claim method API properly. So there are a few.

C

Our considerations like uh backward compatibility with the existing contracts, and also this is like one side of the things. Another side is that the methods should be um like agile or something like uh good for standard. You know so we shouldn't over standardize that from my opinion, and so we still have a few um options, we can go uh to the options on the GitHub.

C

Probably then just uh proposed a few cases in the last comment, so basically um I think my proposal also Ben agrees that we probably could uh use Justine promise as a return, type and I'm, not sure whether vlads, maybe you know, I agree with it or other members of.

D

This, let me comment on it like Pro promise is a pack from the point of view yeah, it's all back of the client, so defining a promise doesn't mean we Define anything, which means we don't Define. How to even reason about the success of the execution um there, which is the whole point of the whole discussion, is to what is like successful uh result.

D

And what is the failure result because currently it's misaligned the near uh link drop, uh convert the the Legacy one um or operates in an assumption that the Panic would happen that the transaction will fail uh if the uh if something goes wrong, um while uh key Palms implementation, as far as I understand, needs to actually commit some changes to the storage.

D

So it cannot afford uh to panic and revert all the changes down to the storage, which was the main reason for Ben 2 uh align the existing interface with, like the other method, called claim and read account which actually just Returns the value through uh Boolean value as a result. So.

D

Is compatibility to be honest, I I, I'm, I'm, fine, with Boolean I'm, fine with any other value I want to understand what would be the pass forward if we break the API or like or do we want to keep the Legacy contracts, as is, and then introduce a separate like candle handlers for for going forward? But do you have uh yeah.

B

This is, this is probably the only the only comment that I'm that I'm, like not entirely 100 sure how to proceed with um you know just the unfortunate reality.

B

I mean just for some context on on the key Palm side like uh we we've hyper optimized all the link traps, so that one a key is used uh and deleted, uh because when you, when you create a link drop, you pay way more than what you actually use in terms of allowance on the key you're paying for the pessimistic allowance, and so you, you know, let's say you attach 100 Tera gas to the transaction.

B

You have to have an access key with like 171 pair of gas worth of allowance um and you're only ever really going to be using, like you know, 30 40, Tera gas, and so you know you're you're, paying for like five times more than what you actually use and so on our contract.

B

um We refund um the unused allowance, but in in the accounts try like in the state in the runtime, we don't have access to the access Keys uh allowance at runtime, like the signers public key. We only have the public key, but we don't have the allowance, um and you know I tried to make an NEP for this to expose this in the runtime, which would remove our need our our need to not panic, um but it it. You know it didn't go through.

B

um So you know I'm more aligned- and you know, there's a ton of security implications here too, because you can't you there's no way for you to ensure that a contract won't Panic, uh which is something that we're working towards um fixing so I. You know I'm, I'm, probably fine um to to like keep on for for some more context, we're going to be refactoring like basically the entire contract and in the next couple of a couple of months. um So you know I'm I'm, fine, with bringing back the introduction of of panics.

B

The like I mean the only. The only thing is that you know you have all of these outgoing cross-contract calls you know and like I'm, a I'm I assume the worst case scenario, which is like a link drop with I, don't know five different, fungible tokens and I. Don't know three different nfts and some near and stuff, and so you got all these outgoing. You know receipts all this stuff happening.

B

All these cross-contract calls all these assets being transferred, and how do you determine the validity of that without um or the success of that without bogging down your bogging down your contract and I would argue that um the success of outgoing assets like nfts and fungible tokens should probably be handled on the client side, um the the only the and and as I mentioned here in this comment, the only annoyance is the near value, because it's it's less hard um or it's it's harder to determine the success of that when you're claiming to an existing account when you're claiming to a new account.

B

It's it's fine, because I mean you can just check if the account was created and has the balance. But if you're claiming to an existing account and I, don't know you it's it's a one-year link drop. um You know what do you do you check the account balance before and then after, but you know, there's no guarantee that you know the one near came from your link drop contract um unless you like sift through receipts and stuff and like it's just a mess um and so yeah.

B

The only annoyance is claiming to an existing account with near everything else. I think should be handled on the client side, uh which is why, out of my three options, you know there was the simple promise um or just like kind of don't Define the return type or don't at least in this NEP. Don't worry about success, value, leave it to the client or a Boolean, indicating whether or not like all the transfers were successful. So you're, just like you know, call all back uh and check.

B

If you know any of the results were were a failure and then just return false or whatever uh or just you know, return a Boolean and only care about the near value.

B

Those are kind of like the options that I uh thought about, but yeah it's kind of a tricky one, because you have all these like, and you know you might have assets down the line where it's like partial success, or you know partial this or partial that and it's just kind of complicated.

D

Yeah I think we cannot disregard the fact that uh partial um assets transfers will happen because uh we don't control all that stuff and it could fail for various reasons, and we cannot revert uh those that were already transferred. So it just.

E

D

Indefinite amount of uh gas, we would have this problem Robert.

F

Yeah, so if you scroll up a little bit, I just want to share that. You know: I have an opinion about about that.

F

Right so I mean like the moment. My main motivation is for like adding a concrete value um for the return. It's really for composability I mean panicking, is different, like you know, than composability, so here in claim, when I as a contract, for example, if one contract would like to claim for another contract, okay, I don't provide the values I'm, claiming I, provide like the same ID or the queue within it right um so so think about it like in this way, um is it possible right that um I will sign the message?

F

uh Send that message to contract a and that contract a will? Do the claim contract.

F

Or like are there any other.

B

That's not that's not possible with this NEP, because it's defined that the the access key should be limited access key and only point to the link drop contract. So you would never sign a transaction where the receiver is not the link drop contract.

F

I think it doesn't construct it with what they say. So I will sign the message: I mean user right, we send a message, but it will send that message to the contract a and then contract a will. Do we'll call it okay, it will still work right because the signature is the same and the and the ninja verifies like the signs. It doesn't verify who's. The predecessor.

B

Yeah but but the signer can only execute transactions on the link drop contract because they only have a limited access key well.

D

It depends on the client who set up the link drop but yeah.

B

At least in this NEP, it's it's defined that um that you should like the the the the predecessor should be the signer or sorry. The predecessor should be the current account in this NEP.

F

I think I wrote that as a restriction, no just saying it doesn't it doesn't make a restriction and it's in my opinion it would be interesting. We have to allow that kind of exercise so like a composability, I.

D

Think that would.

F

Be a different.

D

F

I wouldn't document to make it too generic, since we don't provide the value in the plan, it provides an install pack right so also.

B

I'm just looking back.

F

To do some registration, some, like I, know balance keeping I.

D

Guess it's not.

F

Necessarily yes, what how was sent so if.

E

You return the.

F

Value to that constraint.

C

D

Right, we lost.

C

You Robert, to be honest, that was to be honest. That was the reason why I finally thought that to promise would be okay, because we have so many ideas: how to define a better return value, and all these cases are pretty specific, like Boolean would be enough string or the whole list of all transferred assets. So we used to get the rest status.

C

How many statuses are we going to have and backward compellability compatibility, um and the final thought is that we probably are running out of time boxes defined by this meeting and we probably had had. We have to had a separate meeting only for this function. You know to, but.

B

Yeah I agree also real, quick uh Robert just to clarify so there's no confusions. This NEP does Define that the predecessor of claim and create account claim must be the current account. That's written into the standard.

D

And I also want to make sure that we are not keeper optimizing for super genetic use case, which we don't know, even if it exists for four years, we have a link drop which works very well, and it only assumes that the users, the the the users, will interact with the contract of the link drop through the wallet so without, like intermediate contracts involved there.

D

So please, let's not assume that we will like build the link drop as a part of some other flow, because link drop is onboarding tool and we want to keep it this way. We don't want to make it.

F

Right so this is like my suggestion right sorry, my internet connection is not stable.

D

Can you hear me yeah.

F

Yeah, okay I must feel like it's yeah. It should be good. Like that's dropping me off so I mean what I wanted to say is that you know I, don't see like any reason why we should like be restricted, and in my opinion, it's not that complex to basically add the return type it's like it doesn't make like the whole the whole process of implementing the simple version as it is down down by the by the by the link drop or the key pump uh more difficult.

F

So me, personally, it's like kind of a no-brainer. That's just written the value, so we unlock all the use cases in the future.

D

Well, that's what Ben suggests my concern was that the existing link drop contract panics. uh If, if something goes wrong and keep on contract, returns false and doesn't.

F

D

So the wallets now needs need to somehow what is actually the failure case and we need to Define it as a standard.

F

Right, but you know I, it's it's like more, like no finding what should be the right, written value and and I don't think like it's. It's like it's really complex. That has the whole implementation like it's something that it's easy to update.

B

And yes, I agree. We should probably have a separate call about this um and and maybe maybe uh I'll just provide my two cents and then and then we'll we'll move on. I was just gonna say in my eyes, there's two sort of panics uh or two um unsuccessful cases. One is you know you, you call you you try to claim something. That's already been claimed or anything kind of like malicious or or out of the ordinary, and then there's also the case where um you know the the assets were not successfully transferred.

B

um Like everything went. Well, you have a valid link drop. Everything was fine, but the assets didn't get transferred properly either. You know you I, don't know. Maybe you you didn't deposit storage on the user's account or something happened uh for fungible tokens or I. Don't know the nfts I, don't know something like that uh or the you know something weird right uh and there's kind of like two areas um but yeah, let's, let's, let's maybe move on um and let's let's.

B

uh Let's can this for now and talk about it and another discussion because I, don't you know, I've got a hard stop soon, so yeah.

C

Just real quick, uh we have two more unresolved, so just minor issues, uh I marked them as a result. uh One is uh the octaneer field, name in the structure and uh another one for you. Just you. Yes, yes, go go back to the previous slide already yeah and if yeah balance, the number item number three is unresolved. It's almost resolved I just marked it like unresolved, so we could uh quickly fix it and another one is unclear how to distribute gas yeah and the um actually.

C

The discussion about required gas field was not marked as resolved on GitHub and so I just want to make sure that we are in the same plate like we are okay. If the balls required.

D

Gas field yeah it it was resolved so.

C

Your all are okay about it and we fixed the comment and it's enough yeah all right. So, let's mark it as resolved.

B

And then the balance one uh we I I changed it to iacto near under underscore yeah.

C

Yeah yeah I just left. The final uh final uh comment that that you use uh camel case and it's not like in the name naming convention. So we probably want to use yeah.

B

I switched it to all lowercase um all.

C

B

A couple minutes ago so.

C

Okay or you can mark it as a result as well, but we have just one result: issue which is pretty significant. One I think.

D

Yeah, let's move on to the next slide: yeah.

C

Let's move on okay.

D

uh Robert, do you have anything else that you feel like our like? We definitely need to address before we move with approving the snap I.

F

Mean yeah I, see I, see a lot, I mean.

D

But yeah sorry.

F

Based on what I've, seen and I was checking it yesterday, like midday, European Time, and all of that was not result so I mean one General comment. Is that would we agree I mean don't take me wrong. I. Think, like you know, the whole standard is good.

F

It's like you know well thought, but like one General comment is that it would be great if you know like the outer, like really cleans out all of that stuff right. So there were like a few comments which were marked as resolved, but then not updated in the in the net itself.

B

Just uh just to to stab you real, quick everything here has been resolved, except for the panic in the query, function and uh clear up documentation by the way.

D

F

Right so I think we also like the fact that that you know this get key balance. They have to remove it um all right, I mean when I was checking it yesterday was not removed and, like the decision to remove it, was I guess like two or three.

D

Weeks ago, if I understand correctly, Ben said that just it was just updated. Yeah.

B

I mean it would have been updated like a couple weeks ago, but you know there was. There was a ton of comments, kind of like in the last couple days and so I've been sort of scrambling to get those all in, um but yeah. Everything here should be.

F

B

Except, except for the the panic and the documentation, the documentation of the linting errors, I will get to just I cannot right now, because I'm underwater it'll be post consensus and that's not really that big of a deal in my opinion, um uh but it will, it will be done. The the bigger one is the Panic, which I mean I, think everyone's come to a conclusion, except for Robert uh about the panic. I think that you might still have opinions about that.

B

I don't know Matt myself, Vlad and some other people I've talked to are fine with the panic but yeah. Maybe we can talk about that. If that's a huge blocker for you.

F

Okay, so, okay, so let's move only quickly like give you the motivation. Maybe someone will change the mind, but if no no one would change the mind. Let's go with my charity.

F

um So, in my opinion, like again similar as I mean I posted already in a few places, I think about it as NST. That's NXT! Panics! If you query for a refundable token, phonics query functions, usually don't panic. That's like one of the different principles.

F

So that's why I'm against it, like you know again, looking from the composibility perspective right, uh if I'm acquiring something I, don't expect it will Panic. It's like Panic is unusual situation situation that you know like. We should not be able to handle right.

D

So now think about it. I think we need to return sorry for interrupting. You uh now think about it. I think we we need to return an option type, so basically in JavaScript world will be undefined or null that.

B

Was that was my initial um sort of inkling and and I commented that? But the problem is that there's a ton of wallets and applications and everything that assume a panic um and so like from the backwards compatibility standpoint. It'll be uh it'll, be kind of annoying.

B

um You know, because if it doesn't panic, then they'll assume that it exists and then they'll try to render and it'll lead to weird behaviors, because they assume that if it panics that's the case where it doesn't exist- and you know everything's good, um and so this is why I've written it. This way, just because.

F

Are we sure that.

B

F

Are we sure, like this is really the case of the implementation in the wallets? Because really it's an anti-patter? It's like.

B

F

I'm worried basically like this pattern will be propagated in like many places like you know, there will be another implementation, I mean not the league drop, but you know something else, and this query functions will panic and again.

D

Yeah, we probably shouldn't take it as a president, so I would consider it to add a comment that it was a compatibility decision to keep a panic there.

B

The problem is that the link drops have been in the wild for so long and there is like no, there has not been a standard for years, and so all of these apps are building off of the assumption that it will panic and so I would like to keep it that way. I, don't think it's that big of a deal like it's not a huge. You know like you can like yeah, you probably should return null, but for the case of backwards compel compatibility I would prefer to keep it that way.

D

Actually Ben, given that we introduce a new method- name: uh okay, can we can we use in like yes,.

B

In the new in the new one, um that's a good idea. Actually Vlad is in the new one. We can probably return uh a null or an option of key info, but in in the Legacy uh balance um method, then okay, I I'm, in agreement with that. Well.

C

Also, to be honest, guys, I recently tried to find also like make yeah. We have. We have a lag may say that just makes sense. Yeah.

F

uh To be honest, uh go on.

C

Yeah I I try to find whether the panic in the view method is kind of an anti-pattern or is not suggested to be honest, I haven't found any explicit mentioning about it. So I know what Robert is talking about. We know fungible token maps and they are just return, zero and so on. But after the second thought uh it's it's probably not an entire pattern. We can decide we can discuss, but I.

F

Don't think I mean yeah, don't you think that you know like in general in in software engineering you know, exceptions are, should be exceptional, I mean do in the exceptional situation. I mean for me. um Maybe that's like the way how I was programming or you know, interacting with it. Yeah I think this is usually in software. We were trying to avoid panics.

C

Usually yes, but so it's like foreign.

F

Okay, anyway, um let's go I think we can continue. I think we reach the consensus here.

A

Okay, so okay I guess so: um oh go ahead. Robert yeah.

F

Yeah, can you go back to one side.

F

Right so, in fact like uh another thing, which is like two things which are missing now, like uh private crystallization, to be honest, I'm against, like using um proposed Bosch serialization.

B

Again, it's been resolved, so please please, go back and and look at look at the GitHub because it's been updated. Everything here has been up: okay, except for the two that I mentioned before.

F

And the registration pattern was also resolved.

B

That is correct.

F

How did you resolve the registration pattern, I.

B

Put it into the security implications, saying that if it's a fungible token drops or any sort of drop that requires some sort of prerequisite that you should ensure to you know: do that, for example, uh registering the new user.

A

Yeah, just in the interests of time to move forward, we need to have two-thirds majority. These are the old um voting indications from the comments and obviously they were prior to the discussion that we just had so they're, not very clear in terms of how everyone is leaning, so I guess. um Can we like Vlad? Would you like to try to summarize sort of for on the group if you want to go around and have.

D

Everyone kind of say, I, I, I, think I have a proposal here, uh so it just for for the sake of uh time, uh and we had a pretty extensive discussion already and it seems like only one one um uh click, the the claim, method, um return value concern is still not addressed, and we we need to erect some disk decision there, but other than that it seems like the we are on the right track to approve the nap and I'm I, still lean towards approving the snap.

D

This is my uh like believe that this this snap is is critical and we need to have it um if there are some like foreign cases, we need to address them, but I'm I'm going to push it Forward, I, don't think we need another call and to do it and discuss it once again. We will just do it uh in in the in the pull request itself. So once we arrive to the decision, um I I, like I will I will uh reach out to all the I can drive it.

D

I will reach out to all the working group members and confirm that everything is good and ask you to post the uh it as.

E

D

Message uh to the pull request, and after that we will just merge the pull request without having another call for it. um How does this sound to you guys, Alex yep um Robert, the.

C

F

uh Yeah, it doesn't make sense, I mean I, wouldn't basically like refer that we approved with now. Yes, because.

D

F

Think we are not ready, no yeah, it does not saying that I didn't know. We just agree that you know at least one critical thing is missing.

E

F

Formally, it's not approved but, uh as you said it's it's supposed to be. There.

D

Sure cool, so are we saying.

A

D

Do you feel like uh we need to make any major turns here, or are we good here.

E

Got some minor concerns about security implication. Basically, I want some implications to be specified more clear, but it's not as much about the standard itself, but rather like the text.

B

Just for just for some some more context, I've I think I've addressed all of the concerns that you brought up. Could you please let me know, um because you said I didn't I didn't mention anything about. You know ensuring that you can't duplicate assets for a key or whatever, uh like you can't, try to take the same key and use it. Could you.

E

Sing and things not duplicating assets, I think the current text is very unclear. It says only one key associated with the given assets like what you could send one nft and then create multiple and drop with different Keys, pointing to the same and after this obviously should be protected against.

E

But what I was thinking is a different things, like suppose that you create a new link drop with the same key as an existing one, and if the implementation doesn't check for this, then it will basically overwrite the Alden drop like destroy it and let and have a new link drop in its place, and this is not good, because an attacker could just basically destroy which falling drops and Destroy. They don't need the private key to do it.

B

E

B

You're saying I think, um like maybe something to consider is, is like whether we standardize the creation of Link drops or standardize like the claiming of Link shops and I, think that that might fall more under the the category of the creation step like make sure you can't create multiple link, drops with the same public key or you know, make sure they don't get overwritten, but that I don't really think. That's the purpose of this standard, like in my eyes. This is once you have link drops in the wild, regardless of where they came from.

B

How do I claim them, um but yeah I mean like it's, not that big of you I could probably write that in because it is like you know, it does pertain to link traps as a whole.

B

um Yeah I I. Don't think that it's that that far of a fetch uh to to do that, so I'm fine with with that, but just to take into consideration that this I don't know. If this is more so for creation or like claiming you know what I mean so, but yeah I'll write that in.

E

Yeah but I think that security considerations should be a bit wider. So it's right that this issue is regarding the creation and we don't have a standard which means we just don't have a specific convention like specific method, name specific way, but still if we have a link drop standard, we obviously expect them to be created somehow so.

B

We that's that's a good point. Oh I'll write that in I have a hard stop, so I have to go. Unfortunately, um thank you. Everyone, um I guess, we'll talk asynchronously on on GitHub yeah.

A

Thanks so much ben appreciate all your work on this.

B

Thank you all right, see you later yeah.

D

And so let me just summarize it uh so we are on the same page. We are all very close to. We are close to the. We are uh uh all agree that this snap is necessary and we want to uh see it merged so, and we believe that only one unresolved issue is there that we will all work asynchronously uh and uh arrive to some decision.

D

uh So we are not approving the snap yet, but we are not rejecting it. We will just uh have it approved uh through the pull request, discussion on.

E

D

Is that okay, it was everybody if so, let's just thumbs up and move on to the next.

C

A

Right awesome: we will move on to the other nap right now, um just so that we can um give it the time it deserves as well. So next is uh nip 469 uh at nft metadata, update event to nip 171. uh The author of this step was unable to uh make the call La Clan, so I asked evgeny to summarize the net on the author's behalf, so Evgeni.

E

So the idea is simple: we already have contract metadata and contract metadata, update event and we have nft metadata, and so they what the snap ads is an event when nft metadata is updated.

E

The purpose is to allow tools to track changes to nft metadata, because there is no standardized way how it's stored. It's basically an implementation detail of the nft contract. So without an event, those tools will need to query an optimeter data, potentially every block on every nft to just to know if it changed- and this is not really practical.

E

So the idea is that instead, they could watch for this event and query the metadata only when this event is triggered and for this reason this event have actually only includes nft IDs and not the metadata itself, because once you know that metadata change, you can just use the view method to query it. This way, all the tools like wallets explorers, whatever could watch for this event, query the metadata only once the S7 happens and the Seven tells that nft metadata changed for specific tokens.

A

Awesome thank you for for that great summary, uh so yeah this map also had um some discussion on GitHub and I'd love to invite Robert if you're still there to maybe give some a quick summary of some of the benefits and concerns before we get to the actual votes.

F

I think it's neither like it's really missing. I mean like the event is something that people want to observe but, on the other hand like we should not bloat event with all possible data right like copy it, because indexers have the access to the to the chain. So I think that was like the only thing I was discussing there right.

F

So um so it's really about like you know what and how we want to um to to notify and then um not copying everything, because it's also like creates a bad pattern, in my opinion, like if you standardize something you know it's something that you know people will learn from, and people will replicate in in maybe um more customs in more custom um contracts or more custom applications right, so I think, like the only issue I had there is it's like putting too much into the yeah either itself.

D

uh Just to mention that uh eviani actually brought a very good point that it this. This snap helps uh the quality system of indexers to implement a more efficient way to keep track of the the existing nfts uh who that were issued before, but then changed over time, and there were different ideas and different reasons why that could happen, and given that we already have the contract metadata update event, it was natural to add another one to track the individual nft um metadata updates.

D

So if, if a URL to to the resource has changed or something else inside the metadata has changed, there is a chance to flag it from the contract to all the indexers out there. By emitting this new type of event, the standardized now and part of the map uh 171..

D

um Given that it's a non-breaking change, it was easy to buy in and let it be there for whoever needed it's very hard to enforce, though so they when we come to the concerns part, uh there is already existing Foundation of um of of contracts. Or can you uh go to the next slide?

D

Please uh so yeah uh the Legacy contracts out there don't support this method, uh but they um hope is that going forward with more uh contracts, appearance, Network, they will actually pick it up and the index service lives will be much easier going forward and they will need to maintain a custom Logic for all the new uh contracts. They will probably be forced to maintain some heuristics for the old contracts.

D

For example, not all the contracts need to be updated, they need to will leverage the fact that the nft could be updated on the contracts, only mint them and never update.

D

uh It's I believe that most of them actually, these days um and the other, the only concern that was there in the very beginning that uh nft underscore update was the event name and it was ambiguous. uh So the proposal was approved to to change it to nft underscore metadata underscore update name otherwise.

D

No other concerns were rised. On this pull request of this map extension and yeah I. Believe all the working group members were uh agree in agreement that it's good to have and we can merge it uh approve it now, but uh yeah we are ready to vote.

D

um We have all the um indications already posted on the GitHub.

D

um Let me know like if, if anybody from the working group has any concerns, um do you want to speak now or you're proven it.

F

Approved um yeah, so maybe I think it's better now just wanted to let you know yes, sir there's one I'd like to basically repeat, like you know, I added the comments about that manual Shield, basically to raise the concern, but this is like a side comment more about like thinking forward. Yes about it, but yes, uh 100 approving.

A

D

A

Was quick yeah that was an easier one for sure nice to end with a good with a good uh with the decision. So all right, uh we will uh summarize the the next steps on this snap and also on the other one. After this call. Normally we would open it up to q a but since we're short on time, I guess, um if you have any questions, please drop them in the chat box and we can come back to it, uh but really I just want to say a huge.

A

Thank you to uh everyone who was involved in both of these naps. uh You know the the authors, the the all the subject matter: experts, uh the work group members. uh It takes a lot of efforts and thoughtfulness to arrive to these decisions for the ecosystem and I really appreciate uh the healthy discussion that we had today.

A

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. So if you have a specific idea in mind, you can submit it using the dev Hub or find other communities to collaborate with. If you have a technical idea that you want to get integrated into the ecosystem or you're seeking funding, you can also submit an app after posting your initial idea on the dev hub.

A

You can also view all of the naps and their various statuses on GitHub and join their discussions there. And then, if you want to join the community, you can check out the the near contract standards, a telegram community group. It's a great place to connect with others.

A

You can learn more about everything, that's going on in the near Dev, gov, org website and our social channels, and we thank you so much for attending today's call and hope you have a good rest of your day. Take care.