NEAR Contract Standards Working Group Meetings, 30 Jun 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: Contract Standards Work Group Call – NEAR DevHub June 30, 2023

Description

Today the NEAR Contract Standards Working Group met to vote on:
➡️ https://github.com/near/NEPs/pull/393

Chapters:
00:22 Agenda
00:45 Objective
04:38 Introductions
05:24 NEP-393 – Discussion
42:59 NEP-393– Decision
52:26 Getting Involved

Learn about DevHub:
Website: https://neardevhub.org
Twitter: https://twitter.com/NEARDevHub
Telegram: https://t.me/NEARDevHub
NEP Process: https://github.com/near/NEPs/blob/master/neps/nep-0001.md

Join the Contract Standards Community Group:
Community: https://bit.ly/ContractStandardsCommunity
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

To the fifth contract standards work group call, my name is Maxwell I'm, a community moderator and contributor working with Dev, Hub and I'm looking forward today to us uh going and looking at a new token NEP and coming to a decision about it.

A

So here's some you know background about the agenda, we'll just go through these things before we get into the meat of it, um I'm just going to give some context about the new developer ecosystem and introduce all the participants and then we'll get into the name. We did the discussion and open it up to q, a if anybody has shown up to ask some questions so to get started.

A

Let's uh discuss the purpose of today's call, we're here to vote and come to a final decision on net 393, which is a new token standard for what you call a soul, bound token on a the near protocol.

A

We're also here to celebrate the effort and time that everybody invested into this NEP, as this has gone through a rigorous review process and has taken the time and effort of a lot of subject matter: experts as well. Okay, so before we jump into this, let's give a little bit more background on our process, so Dev Hub is a current year initiative that we're looking to decentralize nearest development and really open it up to any interested members of the community.

A

um We provide the social structure and tools to empower anybody to contribute to near from submitting ideas on dev hub for people to discuss, to actually contributing the code that we may eventually Implement into the protocol or as a contract standard, or something like that.

A

So today, our main tool for interfacing with this organization is this near devhub.org. It's a boss component, and this is our main platform for new developers to contribute and stay informed. We have various communities on this website that you can join and get involved in or create your own, and this is a great place to meet with other like-minded individuals to brainstorm, make proposals and also to get technical support and also funding.

A

Now in additional to these uh informal groups that we have on dev Hub. We also have our formalized work groups who help make decisions on various ecosystem areas such as protocol and contract standards, and these groups have selected recognized experts who engage in the community and help review proposals in a fairer and timely manner.

A

So, for example, they help come to decisions on technical proposals that you may want to get integrated across the ecosystem, such as contract standards or improvements to the protocol.

A

Anyone can submit an idea for a technical proposal using an NEP, it's our formalized uh format for making improvements to the protocol, and we have a process that will that's detailed in this mep-001 that we tape all of these through to come to a final decision review. Implement, all those sorts of things.

A

As part of this process, we have four e responsibilities in this. In this um formalized process, we have the author of The MEP himself, who writes and presents the proposal, takes it through reviews. We have the moderator which is Ori or myself, who who facilitates this process and discussion and kind of helps to move things along.

A

We have technical reviewers who get involved to go through the proposal and the implementation and kind of submit comments, give feedback and suggestions of what things people can change and then, finally, we have this recruit itself which functions to approve and finalize the proposal.

A

So these are the three stages that every MEP will go through. First, you have an author that creates a draft. You move it to a review. It gets reviewed by reviewers people, give suggestions, it gets revised and all of this is done in a very transparent, asynchronous way on GitHub and one sometimes on dev hub and finally, once we take it through all these reviews and all these edits and approvals. We take it to this final formalized voting call with the uh with the working group, which is what we're here to do today.

A

All right, so, let's highlight the participants that are actually involved in this MEP, so we have Robert. Who is the author of this proposal? We have um Ori who helped to move things along and myself. Who is here just to leave the call we have our viewers because I'm their dad and Alex a and then we have the contract standards work group working as our approvers.

A

We also invited the wallet group to participate, but in the end they chose not to um just wanted to point out that, as Robert is the author of this proposal, he will not be voting whether or not to approve this, uh this Ned, which means that it's only two people voting on this but I, guess that's what we're left with and uh now I guess we'll get into the meat of the actual NEP.

A

So first I'd like to have Robert present a summary of the nap and why that's important and from there we'll have the work you've discussed and ultimately get to the final decision so Robert. If you're there I'd like to take it away.

B

Sure, yes, hi everyone um could you switch to the to the uh to The Nap page itself, Maybe like if you can open that up.

B

C

B

Anyways, like the summary here, is in the in the screenshot right, so um the the goal of of the standard is really to um to provide a standard interface which will allow to compose um different contracts and different use cases, yes for sbts in a way how we use it for fungible tokens, non-fungible tokens or, like even the house, which is coming up soon, so uh I think it's like obvious. Why we need a standard interface, for you know all sorts of tokens um and like here.

B

The major thing is that uh SBT, like it took us probably eight months right to like get into this final shape, and then the main um founding finding here is that SBT is really not nft.

C

B

We wanted to model it as nft, it's a non-fungible token, but eventually uh we arrived um earlier this year. In fact, the model where um we we really separated- and another thing is that you know um SBT- must have internal economical costs of transferability. So transferability is possible, but it must be limited in a way that it, as the name suggests so Soul bands token. So uh the transferability is limited, yes to to keep bonding that bounding, the token right to the soul.

B

um So this is what it's all ordered about. uh We um at the beginning, we explain how um how this banding Works, what's the what's the cell, so soul is basically a property of an account that it has kind of a digital identity and the main focus we are very of of design of this design is really like a human identity.

B

um So this leads us to like various decisions, um notably the the major one is the separations of concern between the registry, so where the tokens are registered, the balance book and the issuer so who and how issues the tokens. So traditionally this is done in the same smart contract. So, let's say: if you have your own smart contract, let's say um USD team, then it will have both these use cases in the coded in the same contract right.

B

So it will have the logic of of issuing token, and also it will have authorizing yes, the issuance and also a logic for for recording the token yes here, for the reasons mentioned previously so bounding the soul to an account as we we decided to separate it.

B

um It also unlocks few interesting properties, notably what I call a semi-atomic transfers. So um we can like really do some migrations between accounts, in a way that um it will limit the um let's say, civil attacks or like a civil Behavior, that um a malicious user yes would like to keep them. I mean avoid the system of uh of really bonding this all to an account yeah. So that's like from high level. This is the motivation.

B

um uh We have a primary use case which we are working on for for a while already right, so I am human. uh It's already in production, we got uh two beta releases and finally, the the final release around April this year. uh We also like successfully change the issuer, so we proved various Flows In in that within that model. So in our first Beta release, we we had like one issuer, which we used to qualify Humanity over a time we change it.

B

um We prove that the model works it allows for compatibility, notably for elections for for voting, for nominations for like now, the the next area of research implementation, it's kind of a kudos right, so it's not only about like approving Humanity, but you can also like proof um with SBT uh your membership to a community and again like allow it to I mean combining it then with Humanity. So let's say you have a proof that you are a member of a community and you're a human.

B

uh Then you can have like a more specific um rules for for, let's say for a governance um or um other notable. Examples. Yes, are related to uh to a finance where you want to, let's say, can create like a more and dedicated instruments. While, knowing that say, someone is okay. Firstly, a human or maybe an institution with a specific background or um uh Financial requirements. So all this is possible also like we don't here, need to share like any specific information. So it's open the standard. The whole standard is open.

B

How uh how the I mean, like the relation between the the token and the proof of what this token represents right? It's it's not really uh a part of the standard. This is open in the same way. How, let's say um uh proof of um what is called proof of Reserve right for, let's say values, um uh stable coins is, is done so I think that's enough for the like a general introduction.

B

um We we have like many more use cases described in the um in that net. So yeah, please have a look.

A

All right awesome, um thank you so much for that summary and your submission and work on this NEP um Robert. Would you like to like give a quick overview of like potential benefits that sort of thing like just in general, the uh of introducing the I know. You just touched on some of this in your overview, but.

B

Right so actually like this nice, also, like um uh already, let's say outline that um the the main use case here is, is really like. You know creating that kind of a properties for the accounts which are not possible today, with uh with nft.

B

So, for example, NST could be very good for representing a real world asset right, like maybe a picture traditionally or a car, a wine a unit of a gold right, but um but as good, it's more suited for um for a property ownership, um I mean human Clarity or, let's say entity or property right, um uh uh this kind of things right and finally, right like because this property is bound to the soul. Yes, we have like all this all this definition right. It allows us to create some simple resistance mechanisms for many.

B

Many use cases also, like you know, like the whole whole thing, is it's really driven by the um decentralized Society? So if you look like more broadly in the research of the centralized societies, this all done is really like the foundation of of the model proposed by um uh the idea.

A

Cool. Thank you.

A

All right, um so we have like some of these concerns that were posted on GitHub. A lot of these are still marked as open. Would anybody like to like take us through some of these and whether we should you know mark them as resolved, completed or.

B

Right so actually we had yeah. Actually you had a discussion about it. I kept them open because um I thought that we would close them. Basically, we made this decision today and, if there's various concerns. Yes, that will be like publicly sharp here so I guess that uh with uh two other um uh standard uh contract standard work, group members- we basically like you know, Mark them or I mean- might become like as a closed or add. Maybe some additional notes?

B

How about that.

D

Yeah, that sounds pretty reasonable. Can you Robert probably uh like read or like conceptualize each individual point and right.

B

Then so let me let me go one by one and then let's say we do like a voting, so the first one is about like the snap uh NFL 70 171 is nft right and that's one of the early concerns where we were really discussing uh that's already different last year.

B

In fact, if, um uh if SBT should follow some of the um um uh nft interfaces or events in order to keep compatibility and the reason for the motivation for for having that compatibility was really to um um have for free the support from the existing ecosystem, right tools, indexers and so on.

B

Over a time you realize that that would require some patching. That's um it's not desirable, and instead of like adding a compatibility layer which could potentially create a wrong implementations or maybe like technical depths for the future. Yes, we decided basically to really separate it. So even if some events would make sense from NST perspective right, we decides okay, let's just separate it, because those those two are two different entities.

B

um Also like another motivation for like the separation was that we we agreed to use the class which is like this. You know um another level of abstraction, so if you, if you anyone, is familiar with this multi-token um uh idea, multi-talken standard. Yes, we can have kind of like a class or a namespace. For the token, this is similar to what's in ethereum, ERC 1155 or like a fractional, fractionized fractional nfts.

B

Here we adopted it from the get-go, basically because it really composes well about like certificates, some additional proofs in a way how the um issuer would like to like, qualify or separate- and that's, let's say, a different expertise for the same user. So overall, uh the the here like the funding from various comments, is that okay, uh we uh we don't do like any compatibility layer and we do dedicated interfaces and dedicated events.

D

Yeah this was uh originally brought from my site when the original nap was submitted, with more like more closely resembling non-transrual nfts, and the argument was that we don't. We would create a lot of Burden for for the indexers and the rest of the ecosystem uh collapse into two.

D

uh So I I was insisting on having a different uh prefix and like a couple completely different, namespace and now looking at the final version of the nap I'm I'm glad that we did go that route, because there are many more uh specific extensions to to those events to to the methods, and they would be very hard and non-intuitively smashed into the existing like nft nap.

D

If we would follow that route, so I'm glad that it's it's a separate thing and we don't need to discuss that compatibility and burden that that could put into the system so totally agree. That's yeah resolved now.

B

Correct yes, and like this argument of a technical depths, it turned out I think to be real.

D

B

Okay, so the next one is I mean. Does anyone else have like a different comment? If no, let's go forward?

B

Okay, now um some memo fields in um most of the let's say transactions. Yes, we include the manual field related to uh so again, like SBT could be like used for some legal terms, legal as like legal actions. Yes, which might have some.

B

um Legal relate to like a legal action: okay, so Unchained transaction, yes, which has to be reference to some uh Real World um action, and this is why we have like an animal field. Think about it, like you know, in money transfers, Bank transfers, we have a memo field as well, which we use I mean, as we call a reference um in various other, let's say: blockchains. Yes, the memo field is part of the transaction, rather than like a function called in nap 141.

B

We you have the we have the memo field right, so the concern was okay. Do we want to include it in event or not? So the reason is that okay, with the I propose here to basically not include it, it's part of the transaction. There is an event even is always linked to a transaction, so there is no need to copy it right.

B

So like the idea of the event here, okay, like the motivation at least I want to- or the narrative yes I want to provide here- is that you know event should be something that you know like many indexers or off chain um applications will listen for and and then like. Based on that, like react, so let's say it should like have something that is like a menu. It should not be a copy of the transaction right because but it should be like really meaningful. What is the purpose of the transaction?

B

What is that transaction about right? The transactions, for example, can be a bundle of few different actions like let's say um a transfer, maybe account creation um or uh I, don't know again. Newport creation uh bonding things like that right. So um so, technically, that's why we have these events right, because we uh we can have few different actions in a single single transaction.

D

I think we don't need to go into like very deep all.

B

D

uh So overall I think we are like all in agreement. That's uh okay. uh Memo is like optional and even in in nft uh world, it's not very widely used. So, let's, let's see without it as part of the standards. If anybody needs it, they can edit. No, no, it's extendable. uh The events.

D

The support would be limited, but it's fine I guess so. Moving on to the next one, I can probably take it. uh So there is a concern about token spam and given that you can't burn and transfer away the tokens.

E

D

Is there was broadly concern that well what to do with those uh cell bound tokens issued to your account and I I? Think it's the same uh problem all around in in FTS and nfts as well. uh Spam and flood is uh like, is there and and people will spend their tokens and I? Don't think it's uh it's our like it's job of the standards and it's not the job of the owner to burn those tokens.

D

So I think we can just uh rely on the uh like on the um wallets and other entities who display the the data to just filter out the spam. That's.

B

Right so here, actually, yes, the concern was like okay, that we I mean. Should we require it or not required as a part of the standard. So from the very beginning, the standard defined a burn event that you know tokens currently burned. However, the standard doesn't require a specific function, and the reason for that is that the burn function can be different for various Registries right. So, let's say also it could change like. Let's say if you want to be more specific, how the burn Works, what arguments? What extra? Let's say arguments should be provided.

B

That's that's why we don't keep it right, it's not needed for composibility here. uh If we will find like a solid use case, we can always add it right, but um as an extension, but.

D

It's resolved now for current state yeah. Let's move on uh multiple Registries. Can you shed some light on it right.

B

So there's also like a spicy uh discussion about it, so mainly because we have the saturation of concern that um there's issuer and registry and what, if one issuer, will try to issue the same token for multiple registries, so, first of all like we cannot dictate that there is only let's say one blessed registry: it doesn't work in the permissionless blockchain right, um so we can make a recommendation right, but we cannot. We cannot require it.

B

So the concern is valid like if one issuer will um will issue the same token in the Registries and then kind of a duplicate but the same argument. So our recommendation is, of course, to not do it, but we cannot enforce it and the same concern in fact, is in any other traditional uh token right. So if you have an nft representing again your picture and the issuer decides to copy it, you can prevent it right if there will be like a second bold Apes collection exactly the same by the same issuer.

B

You cannot do anything about it right, so it's a permissionless blockchain. So um that's basically um yeah.

D

I would call it out of scope for for the standard exactly.

B

D

Concern for the audit for specific contract, rather than the standard.

B

uh Also I mean we made the recommendation that you know how this should be interpreted right like how it should be used, but that that was the founding here right. We made the recommendation yeah.

D

Let's move next.

B

uh Yeah, the multi-talkends are like to approve it or to not have it yeah so at the beginning, we're talking about it discussing like who needs it, who doesn't need it at the end of the day, we found that okay, let's do it because uh it provides a better model. If you do it from the beginning that issuers can, like you know, really separate the different sbts. In fact, also in I am human right.

B

It turns out to be helpful because, let's say there is a community SVT right and Community has Beauty can have like a few different types like OG or maybe uh I, don't know like a community Master, something like that and those will be represented as as a different class. So that's the the multi-token approach so again, like um the month of um of application, it I mean using it in in big project, turned out to be to be really helpful for proving this approach.

D

Yeah makes sense to me, though it seems like it's a different approach like it's not completely multi-talken standard, it's just some like variation of it. That makes sense for the SBT rate.

B

Correct kind of right, because multi I mean the the near multi-token standard is for the fungible tokens right. So this is like have multi-talken for I am in isil called multi-token. It's technically not a multi-dog can write, but the idea is similar is that we have like another level um in.

D

The model, so you have token ID and you can have numbers several of them.

B

Yeah and you have like a class so like you have issuers, then any issuer can have okay.

D

B

You know the site, so I mean like a few principal examples. So let's say you have University right and then the class will be that. Okay, what is your graduation I mean? The class will represent both your graduation year and the uh the strategy that you made right. So, uh instead of like creating multiple issuers, each issue will represent- uh let's say a tuple. uh You know the university the graduation year and the uh and the study you did so.

B

Instead of that, you have like issue value, which is a university, so you keep the The Entity, which is you know, providing the certificate the same, and uh the graduation study will be here modeled by the class and then hsbt is basically like its certificate for that study.

B

So now that's like one example another like I mentioned with the community and the team.

D

Okay sounds good: let's move on.

B

um Right so uh use of milliseconds as a Time unit, um yeah. So again, like various comments here, um the the motivation about like using milliseconds. Okay, like we were considering seconds, milliseconds or nanoseconds um right so um yeah, the let's say default in here is of course nanosecond right but uh like, if you think about like a block propagation right, it and and I mean how where this millisecond is used, so the millisecond is only used for the expiration time right and given that you know all of these are transactions.

B

We don't need to go to this. Let's say nanosecond, um precision and if I remember correctly, okay, I, don't remember now, but if I remember correctly, NST is also using the nearly Second Son. That was like a second argument.

B

I mean initially I wanted to do the seconds, but because I think nft was using um milliseconds. We decided to.

D

Just for context, it's a hard balance to strike here.

D

um The conflicts environment exposes the nanoseconds time Precision from near blockchain, so the like, if you just use the like nearest Decay standard function, to get the current timestamp, you will get it in nanoseconds Precision already, so you will need to do any operations and, like you, just use that number.

D

um The problem, however, is that it doesn't fit into uh like number Precision value in in JavaScript, so it's more than uh two in power 253 and then it it just. It loses the Precision. And it's like you, don't it doesn't matter that much, but it's it's cutting some like precise number at the end um and and seconds is not enough because it's uh basically, um we could have several blocks in the same seconds and probably uh not a great idea to have like potentially colliding to to events in single.

D

B

Right I mean because you wouldn't have like attack Collision. Yes, because you always have like a strict rule. I don't know either if it's the first one or not, but anyways like a.

E

B

Seconds have basically way more advantages here right, it's also like compatible with what we use in a web. So that's that was the final rounding right.

B

So I think we agree.

D

Yeah I guess I guess so.

B

Okay, so the next one is burn. um I think we already like made that um I repeated her burn because uh actually part of the standard and the token stamps are kind of similar right. So in a token spam I mean Vlad. You already commented here, uh I extended.com and yes, that we don't add burn as a part of the standard, but we keep the burn event as a part of the standard.

D

Yeah, it's the same story with nft ft events as well, like the excitement and burn methods did not make sense, but events are very valuable for indexers exactly.

B

D

Track, uh what's what's going on.

B

Okay, so the next one is the salt transfer. So the salt transfer is like this unique thing um or a unique feature, yes of SBT, and in fact that's what we got really qualify as between so salt transfers is like a special um action. Let's call it this way uh where we allow in fact a token to be transferred by a user rather than like glow back or enforced by the issuer.

B

What kind of recoverability and the reason for the sole transfer is that you know like users at the beginning, don't think that much about the identities right, like very often like we realize that lay down down the line that okay, we made some mistakes, but you know creating many identities or like at the beginning, creating our let's say public identities where we would like to start rather not fully public and this kind of things, however, right because of the composibility, how it works here and maybe like some mechanisms, would enforce us.

B

You know to merge some accounts or like proof that, um for whatever reason, right that you know, one account should be merged into another one. So, like you know, we want to move the soul from one account to another one.

B

uh Then then we need to have some way yes to to handle that use case.

B

So this is really what the sole transfer is, uh and um at the beginning the sole transfer was part of the standard, and so the function um later on, uh like firstly as we change the implementation and that triggered me in fact, to um not put it as a part of the standard in the same way, and the motivation here is again the same like as a mint mint is not part of the standard, but means even the spark of the standard.

B

So here's the same thing right, uh salt transfer is, is not something that you know. One contract can request for another one, but it's something that you know should be rather ad hoc and- um uh and we didn't include in a standard later, if, if needed, probably it can come as an extension today, we don't see it seeing it that this will be part of the standard.

B

However, yes again, the the event, the event is part of the standard.

A

All right and I guess I'll just kind of quickly go through this last one. um There's a couple concerns about privacy. You can see here that the.

B

A

One and two are and just pull this up really quickly.

A

um These are quite involved answers, so if uh people want to know more, um please just take a look at the uh the net page and and read through the comments here so we'll just kind of move things along from here: I guess, if that's all right with everybody, yes,.

B

This privacy was like this classical.

B

I'm not sure, should I, like summarize it a bit.

A

If you can yeah, maybe like a one minute summary something like that, that's right.

B

So there were a few Concepts that you know, since the SBT kind of um can qualify your identity right, it can be used to uh deducts like a real identities right. So it's a valid concern right, but you know if someone would like to like specifically deduct it by so my mind point is here the following: right, like uh we really recommend that to not include any personal information in SBT right, but uh it's in fact like cannot be enforceable because I can create a token and I call it deducts and I can only know.

B

I know all the accounts, for whatever reason and I will accept I will that would be non-transfoldable nft and that token has will have like a memo field or whatever a reference, and you know I will be a troll and I will just mint it for already or we will not be able to like to all this account and I will put his name his address everything there.

B

I can do it. This is a permissionless blockchain. In the same way, I can do it like in a spreadsheet and share it with everyone, then Google spreadsheet and share it with everyone right and if I will do it anonymously right, then there is like no, even like a legal litigation that you know someone can can find me to because I'm serving personal um personal information opening the internet. So yes, it is sorry, it is a real concern right.

B

We cannot do much about it uh in a in a let's, say, open permissionless world, you can only do recommendation to to keep it private. um Also, yes, um I think that you know we should go to towards more like a ZK related stuff. So the the standard is like you know more following the approach of of like a traditional token standards.

B

Right where you know balance token balances and everything is public right, because um it's really like targeting uh existing new ecosystem and hopefully yes, this will be upgraded once we have more Primitives, more um more work done related to um to zero knowledge, um Frameworks directly in here and I. Think, like the standard, won't need to change yes, because then we would like the the SBT. Can represent a proof um or a Cavaliers proofs? Yes, without um telling anything right, so it will.

B

It could be like even like um the reason that my account has an SBT might not even like mean anything because, let's say the proof can be that even not valid right. So there's like a various ways how this can be upgraded, um but that's more an open reset.

A

Okay sounds great.

A

B

Actually, there is one more like we discussed it um like one more concern, I think it's about the token ID. Let's not sure do you want to to talk about it. We didn't include it here, but that was like a chat about it. uh Two hours ago.

D

Well, there was a concern about the actual type of uh token IDE. uh The original proposed, like the current, the current map, seems to be uh asking people to use uh uh unsigned integer up to uh two in.

B

D

uh Yeah uh Power and then in JS world. If you try to digitalize it, you will lose the Precision if, if the value is more than uh two in the power 53, so my proposal was to in order to avoid the uh the hustle for uh JavaScript developers, who want to be compliant with the standard, uh is to either turn it into a string, which was the approach taken by nft contracts and standards, or um explicitly state that the value should not be more than two in the power of 53.

D

So JavaScript developers can you know sleep without problems? You know uh thinking about the their like token. Id could collide with something else by just you know, leveraging the numbers um and yeah dude. What what did you decide to go with right.

B

um Yeah thanks, so um um that's also a kind of an interesting concern. I mean like already at the beginning in the um in the design. Yes, I made like a narrative about it, uh and there are like a few motivations for me to use a number rather than a string. uh So like firstly, number, it's also a kind of a uh like moving.

B

The using a string is in fact asking developers to use a library rather than a native type, directly correct, because, uh uh like the JavaScript doesn't work with that, like even if you use number I mean if you want to use number and then like really put it in a string, there has to be a library as to to validate that uh so like. If you are going in that direction, then we are already, let's say saying, asking everyone: okay, sorry, you need to use a library.

B

This is how it works, um and my motivation is in fact like from the beginning. We have still thousands of years before this will be like a really problem for the JavaScript developers, based on an analysis. I made um and issuers like technically should not have that problem because they can like even combine it with the with the class which I mentioned before, which in fact not doubles. Yes, but Powers too, the the space so uh in fact, like I required in the registry to use like a sequence, because issuer cannot request the registry.

B

So in this model the current model in the in the interface issued cannot specify the token ID. It's the register, which has the balance book and keeps track of that of the of the tokens. So registry doesn't know like what should be like the next token ID or like what are the what are the fee unless they double or copy the the balance book right so I require in the registry that you know they should use like a sequence numbers to like avoid potential problems related to, let's say different values, different token distributions.

B

So that's one uh second drug, you know combining with with a Class A Class ID that you know the space is in fact like open, not for thousands years but for Millions years right. So um basically I don't see it. A concern and I would rather prefer to have like a native types and JavaScript is evolving. Maybe we'll use wasn't in the next 10 years or maybe in 100 years uh so yeah hard to say they made like what would be the decision.

B

What would be the best decision like in the next hundred years or a thousand years and based on this analysis, I think uh for 253 right? It gives us I, don't remember, but if you open it, it's like tens, tens of thousands years or um let me quickly find it all.

A

B

D

It didn't matter, but.

A

It covers that, shall we move on from now.

B

A

Twenty eight thousand years overview: yes, okay, all right, so moving along with the nmd process, we need a two-thirds majority to move forward with this net, which I suppose in this case means that the both of the non-authors would need to approve. We've already had indications provided on the GitHub discussion thread and here's a quick summary.

A

We have an inclination of yes from that and from uh Sasha.

D

I'd like to invite you to speak first, probably, and given that you didn't have a chance to put the word here.

C

um Yeah hello, so, basically like my idea is that we are on the states where we just got a reasonable um design. You know like a reasonable design variation from everything we discussed and um kind of. We can spend one more year to polish it. However, it just doesn't make sense. You know like from my my perspective, is that uh it's totally reasonable to kick the standard off. You know to make some um impact on the Lyrica system, like let's, let's move on uh so this is my perspective.

C

You can see that we have uh uh 333 comments on the GitHub, you know conversation it's red and, um of course we have trade-offs and in any complex design you will have trade-offs. You will have some. You know unpolished things and at this point like I, believe, like we fixed critical things, we don't have red flags at this moment and you can see that Robert just had put a lot of thoughts and he can you know he can not just explain, but uh you know deeply go into every tale.

C

So that's why I give like my approval, my consent and yeah.

C

um My consent is.

D

Here, Oh Yeah, from my point of view, I I totally agree with with what Sasha just said. Basically, we uh there is no, there is always room for Perfection and we can uh always find what what to tune, but I I don't want to call those back from potential Evolution like uh much bigger changes once we will have a real production use. uh I think we can always revisit and issue new standards.

D

No, no Pro, if that is, it turns out to be uh like the findings that we'll learn will outweigh the the problems of migration. So overall I feel like this standard is already good enough to be implemented and called in production, and it's not a huge scope for integration from the uh like wallets point of view or indexers, so it should be uh fairly straightforward for them, which is which was my concern initially with no.

E

Non-Transportable.

D

Nfts, for example, uh so yeah I totally totally support the snap. So, let's, let's get it trying awesome.

A

And uh Vlad, you mentioned a few next steps here: yeah.

D

I I try to outline the immediate next steps uh for for us to basically be on the same page. uh So first we need to fill out the change log section on the map. uh Robert. Can you do that please? uh So, basically, what's it include, it should include is per previous examples. You can open previous maps for references.

D

uh It should like there will be a video recording of This call uh and you please, integrate the benefits and concerns tables uh from like preview discussion that we already have here, so just bundle bundle together into the nap uh document. So it's much easier for the future reference instead of Sky through the like over 300 comments uh or whoever will read it in the future um and second step would be for like I can take it. I will just approve and merge an app on the report cell.

D

And Robert, then it's on probably on you again to endorse cell bound token support in wallets. uh There is no other way around uh you. We need some Champion to to brag about it to uh to to.

B

D

Show the uh the benefits and, like the use, use cases and I'm sure that you have the all the context there to uh to make it true. So I hope this makes sense to you guys and we can move forward.

A

D

A

Like we're all.

D

A

Already read about the approval, correct, just making sure that we're formalizing this correctly sorry all right.

B

Yeah- and the final maybe word is that, like you know, um we got like a really I mean Real, World Adoption with NDC for that, and it took like many people. In fact, uh I mean it's not only me yes, but like many people like votes into shaping it, so I would also like to thank you, like everyone uh from NDC for um for helping with that and moving with moving it forward.

D

Oh yeah sure we we actually have a slide right, uh Maxwell about like just mentioning the the.

A

D

Yeah, the thing is like this, of course um yeah. So it's definitely it's it's important to recognize that we have like uh over a dozen uh people, can like just uh leave in the comments and reviewing this snap document on GitHub, but I'm sure there were other reviewers of the code of the smart contracts uh itself. So it's a it's a truly Community effort here and I'm glad that we have so many uh people uh like pushing it Forward uh championing it and uh it's it's our pleasure to to support.

D

Even though we like, as a working group members, we need to be a bit harsh and make making sure we're standing on the on the guard. Okay,.

B

So maybe let me like uh endorse you, like a few people here, sure.

E

B

So, firstly, I mean no AG with who I started that uh so thanks also for, like you know like going into the reviews helping with like putting that attacks together and then Henry the NDC Champion for, like you, know, uh helping on uh getting the group together and and working with that, then like every developer in NDC for like really using it using it testing it like playing with it.

B

um Alex alexstratum from uh I forgot the the project name right, so he's championing like another nft project, so he also put like all independent, like few independent thoughts into that um and uh yeah. Finally, the the world group members, so thank you, Vlad and and and Sasha for, like a few reviews, I know that it wasn't like easy for you like to go through, like all the site comments, because you know then like we were bombarded with hundreds of of of comments from multiple people and then you had to decide.

B

Okay, what to do I mean? Should I read this hundreds of comments or not right so um yeah and, like, like I, said everyone else from the NDC.

D

Yeah and thank you Robert for championing and pushing it through like since, when it was open, it was open in September 14th last year, right.

B

D

It was it wasn't like and- and it started way before, that I imagine, given that you already.

E

Came up, I was just I was just looking it up uh when near Khan was, and we came in short of a year. July 16 I think was a near-con learning. That's when we had uh the first hackathon about this.

B

Nircon was September, I think.

D

September something yeah: it.

B

Was in September all right, all right, sorry yeah, but that was already championing this idea in the summary all right, yeah.

E

Yeah now you were so just a year. That's a lot of effort. Thank.

C

C

At least it means that it aged enough. You know, like a good wine I, think it's.

B

Comments awesome.

D

Thank you guys.

A

D

Thanks very important.

A

um I guess I'll just uh put a bell on this, then, um if anybody's looking for ways to get involved in this kind of process in the future, um I'm just going to quickly highlight a few ways to get involved in the ecosystem.

A

uh If you have a specific idea in mind, you can submit it using Dev Hub and find communities to collaborate with you can work on and submit at NEP, like the one that Robert worked on for such a long time here and put so much thought and effort into.

A

And you can also view all these MEPS on the board on GitHub. These are the contract standards, any fees that are currently listed there right now.

A

um If anybody would like to submit more, you know that's where to do it and of course you can get involved in the contract standards community group here on the telegram, so you can kind of see that here and if you're not already involved. You know we have a more than 150 people there now I think so.

A

um And if you want to learn more, you know, follow our Twitter and telegram channels and uh please use and interact with Dev Hub in the future. So um thanks everybody and thank you for bearing with me on my uh first attempt at moderating one of these. Hopefully it gets a little bit smoother in the future and yeah again, thanks to again to everybody and congratulations on all the hard work that people put in and all the deep thinking and all that.

A

So yes, thank you very much and we'll uh see you on the next one I suppose there's nothing scheduled for now, but uh keep an eye out. I know the multi-token standard is still moving along and hopefully we'll see more of that coming in the in the coming weeks. So all right thanks everybody again for showing up.