Contract Standards Working Group Meeting – August 22, 2022
Nothing is loaded from YouTube until you press play, and then without tracking cookies.
About this video
The first NEAR Contract Standards Working Group Meeting!
Today we introduced the updated NEP process & working groups and discussed NEP-359 – Non-Transferable NFT Standard.
Chapters: 00:28 Agenda 00:57 NEP process & working groups 03:50 Introductions 06:42 Discussion: NT NFT Standard (NEP-359) 24:52 Q&A
Learn about working groups and register for upcoming meetings: 👉neardevgov.org
NEP Process: 👉 https://github.com/near/NEPs/blob/mas...
NEP-359 👉 github.com/near/NEPs/pull/359
Join NEAR's community: Website: near.org Reddit: / nearprotocol Discord: near.chat Medium: / nearprotocol Blog: near.org/blog Twitter: / nearprotocol GitHub: github.com/near github.com/nearprotocol Dev Docs: docs.near.org Create a wallet: wallet.near.org/create Apps on NEAR: awesomenear.com Learn to Build On NEAR: near.university Grants & Funding: near.org/grants
#Blockchain #FutureisNEAR #NEAR #nearprotocol
Transcript
6,220 wordsCaptions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.
- 0:10
hi everyone and welcome to our first near contract standards community working group meeting my name is oriapobam and i'm a technical program manager from pagoda and i'm very excited to kick off this group and discuss contract standards today so to go over the agenda first i will give a quick update on the nap process and working groups next we'll do some brief introductions as we have a few panelists joining us today then we will get into the main discussion non-transferable nft standard
- 0:45
and lastly we will open it up to q a so if at any time you have questions feel free to drop them in the q a q a button on the screen and we'll answer them if they're relevant or wait until the end let's start with a little bit of background so pagoda currently owns a lot of the software development for the entire near ecosystem and we recognize that in order to make meaningful progress and make decisions in a more decentralized way we need to make it easier for the community
- 1:15
to get involved so the first step is that we've introduced a more formalized nap process near enhancement proposals earlier this year as a way for anyone in the community to submit proposals provide rationale and build consensus and as we've been getting more nep submissions we realize that we need a way to move them forward to review them make decisions and determine the next
- 1:40
step so that they're not just sitting indefinitely so that's where the working groups comes in the the working groups really is a way to help operationalize the review of those naps and in the short term pagoda has selected a few leading subject matter experts to help bootstrap the first two working groups contract standards and protocol and putting these groups into practice will require a gradual approach and flexibility as we learn what works and what doesn't but in the long term as we
- 2:12
iterate we plan to introduce more groups to handle various ecosystem needs and empower the community to run them now speaking of iteration we are here today to kick off the first contract standards working group and actually start bootstrapping this process so before we talk about the actual steps it is important to highlight the various roles that are involved in this process so there are four key ones
- 2:37
first the author this is the person who writes the proposal and presents it to the working group second is the moderator the person who facilitates the process and helps validate that the proposal meets the guidelines and progresses forward the reviewer the subject matter expert the the person who reviews the technical feasibility and then the approver those are the working group members who make the actual decision
- 3:02
and all of that may sound confusing so here's a diagram to illustrate the entire process and basically we have three main stages draft review and voting and two outcomes approved and rejected and all the roles mentioned before help move the nep through these stages and towards the outcome the thing that i wanted to highlight is that today we're trying to execute this process and look at a
- 3:26
proposal that has been in the review stage and the goal is to have the author presented to the working group and ideally go into a voting decision and today we're kind of demonstrating and talking about the process and and working through it but in the future a lot of these activities will also happen uh very actively in the nep directly so before we jump in let's do some some brief introductions
- 3:52
so i would like to start with the contract standards working group members and would like to introduce marcelo marcelo could you please introduce yourself uh yes sure uh hi everyone uh i'm marcelo from fornet from cuba i am a software engineer at aurora currently working at the leading the protocol team and have been involved in a new ecosystem for a long time looking forward to see the whole
- 4:23
movement moving forward and hopefully confronting this thanks evgeny do you want to go next yes i am evgeny kapoon i am working as a software engineer at pagoda i am working on security of near ecosystem also on the protocol and focused on cryptography awesome and i i'll join the crew my name is lutz prolof i'm engineer manager at pagoda and i'm um i i joined the team quite early on and we worked on very different
- 5:02
uh projects in the ecosystem bootstrapped a lot of things and i'm excited to see how in-app processes will benefit the whole community as a whole yeah thanks sorry awesome thanks vlad all right next we will introduce the moderators in the process and i will hand it over to max hey everyone i'm max um so i joined near as actually the first employee i was here from the very beginning and yeah me and oria were launching this war group project and so i'm here to
- 5:37
facilitate it as much as possible yes and i've already introduced myself but i guess i'd like to also add that i am playing a moderator role in this process and very excited to do so i just joined pagoda recently and yeah very excited to just kick off this this nap process so cool and then last but not least i would like to introduce the nep author for the nep that we're reviewing so jasper sorry yeah hi everyone my name is jasper tim i'm a
- 6:07
software developer working for kyc dao mostly on smart contracts uh we would use something like this non-transferable nft standard that we've proposed uh in our kyc platform basically so that's why we're hoping to get it standardized so looking forward to working with the rest of the working group great well super excited to have you all here and i think now it's a perfect segue after jasper just spoke to
- 6:39
actually jump directly into the the major discussion which is the non-transferable nft standard discussion uh the link for that is uh is listed here and we'll also again post it after the meeting but yeah let's just jump right into this nep and i'd like to hand it over back to to jasper to provide a high level of this nep and why he believes it is important so jasper take it away thanks sorry uh yeah i'll i'll try and make it super short because i'm gonna be under the
- 7:10
assumption that like a lot of you have uh looked through this uh standard proposal already and uh i'm familiar with it so it's it's really just like a high level walkthrough then um yeah but in summary i i think um there's a need for something like uh an nft that is not transferable it's gone by a lot of names on on the various chains um stole-bound tokens and the countdown tokens just essentially something that looks
- 7:40
like an nft that is intended for for one wallet and not to be transferred out of it so that's that's what this standard is is supposed to be for um yeah essentially we're just trying to create a standard so that there's sort of like compatibility with the existing tooling that's around basing it off the nap 171 standards essentially and trying to make things like metadata calls and events that would be logged for all the standard events
- 8:12
uh similar or if not exactly the same as the existing sort of nft standard in that 171 just so that it makes things like compatibility with tools i like displaying in wallets as as simple as possible for those tools so that it kind of just uh carries on and we get these things by default as much as possible um yeah um we're trying to create your standard so that it means um tools get a hint as to yeah essentially how to handle these
- 8:44
cases that they know that there has been a standard created for these and that the intention uh with uh any sort of contract that's created with this standard is that they're not to be they're not to be transferred uh and that there won't be any uh transfer slash approval functionality uh in this uh in this contract and so the the wallets know this and hopefully in the future if this gets adopted then that the wallets can you know for example just display that they're not to be transferred but
- 9:17
um yeah it's essentially what we're aiming for then i hope that that covers it uh as a summary and yeah there's been plenty of discussions in the in the thread already i assume we're gonna get to that now perfect thank you jasper yeah so next vlad will summarize some of the benefits and uh and concerns that we sign the comments and the public comments on the thread so i will hand it over to you vlad yeah thanks sorry yeah uh i'm i will serve as the
- 9:51
um sort of moderator for for the working group uh right now so i collected all the benefits and the uh concerns that they found in the nap during the all the discussions including the old ones so i just want to make sure that we are aware of the whole context not only part of it so please bear with me so i'll start with the benefits and the first benefit i saw was that it's a dedicated standard for
- 10:24
a specific real use cases uh like pages ticketing and certificates uh it follows the the second is that it follows the nft standard um methods like defined in nap 171 um i will unpack it later on uh so i feel like it's blessing curse um here and the third one is that uh standard itself is quite slim and it could even be uh viewed as a base of the original knapp 171 as it was suggested in the comments um i don't want to put any color on the
- 11:12
on on the facts here so i i present them as is and i'd like to move forward to the next uh slide where i collected all the concerns uh and uh the very first one is that uh what what was rised is that it seems like uh this snap does not solve non-transferability property and it was stated in the app itself so it's not a surprise to anybody you can transfer the whole um all the tokens the account holds by
- 11:53
selling the whole account so and the second uh very tied together to it is that what people brought in the comments uh actually many of them is that non-transferability is the property is itself is concerning um and there are a lot of use cases where people still want to transfer their tickets certificates uh and uh and other stuff um just for for different reasons they are not
- 12:32
immediately like it's not specifically trading they just want to manage their assets so this is the outstanding um these two are outstanding whether like connected uh concerns uh there and the comment that was uh brought in the in the community was trying to argue that the nft itself as a standard should not define the transferability uh while the map 171 actually did it but the state is the current state of the ecosystem that we already have one nav 171 so we need
- 13:18
to unblock ourselves uh starting from here um or can we move to the next page awesome yeah so the third concern i found was that the device ecosystem can be like a system i mean all the tooling and the apps that were implemented uh using nap the assumptions that map 171 will be not the only but well the only standard interface and currently with this current proposal it could be a
- 14:06
collision with the with the naming of the methods uh while the json rpc json events are different the method names i want to just remind everybody the json the interface method names are used the same as in app 171 meaning that like it has nft underscore token and um yeah and and potentially the metadata uh was advised in the in the in the snap to be used exactly the same as in app 171 which
- 14:49
uh makes it very hard to tell them apart um from map 171 so if you have two contracts deployed uh following these two different standard well technical different standards uh it would be very hard by the tooling to uh tell them apart and this brings us closer to the to this force point uh first concern about discoverability issue uh which was also rised a few times that while it's not solved for
- 15:23
nft itself for nap 171 it's a it would be very beneficial and actually more comments more people brought the idea of necessity to have um a way to discover availability of mint burn methods and the resolution there that was suggested in the comments was define how we discover nft interfaces which methods are available and that way it would be more generic version of this nte nfg standard and the the
- 16:06
comment i chose here was from jasper that uh indeed like it was among one among uh many uh replies there that it would be indeed uh quite an interesting direction to explore um yeah then let's move on the last two um concerns i found were actually resolved or like irrelevant and the the the fifth was about the fact that we could actually suffer from spam of ntnft uh that cannot be burned because well burn interface is not defined and um and you cannot also you can transfer
- 16:54
it but uh it seems like it's general issue for the whole nft ecosystem in general and it should be solved outside of this these two naps so i i put it like irrelevant here um and the last one which was actually resolved initially there was a burn method implemented or defined as a standard and the general consensus was that this standard should not define a strictly defined burn method because
- 17:25
there are different use cases and currently it's sort of results so uh just to sum it up uh to you all the list the whole list of um unresolved items uh we can see them all on the list on the screen and um basically there are quite some of them um or can you can you help me uh to navigate to like just to to the next stages uh here um after we summed it up yeah absolutely thank you vlad by the
- 18:04
way for for looking at all the the comments you know from from from everyone in the public thread and and aggregating them so basically what we're trying to do in this meeting is we want to get into the voting stage right we want to be able to uh decide if we want to approve the snap um or not basically and so i think based on these concerns that you know you have summarize flat i
- 18:28
would like to open it up to the rest of the working group members and basically uh ask sort of what what your thoughts are in terms of how you're leaning um as well as the reasoning for it so does anyone want to go first uh yes i can go ahead so yeah so asan was writing before in the discussion uh there is actually nothing preventing developers from having such nft with uh with non-transferability property that's something that we cannot enforce uh at this level uh so and there are legit use
- 19:15
cases of uh of this standard so it's in the best of our interests uh to have uh such a standard available for the community to be used and so actually tools can support it if they choose to give instead that i do uh highly i do think that um the main uh problem that this snap it's kind of supposed to solve is the discoverability like health both on-chain and off-chain tools uh that this is actually an unsustainable nft so they can react accordingly uh to this so i think
- 19:59
uh like uh having such a such a standard without discoverability uh it's kind of trying to get ourselves ahead uh of the of the actual so in general my opinion would be the according to the nap guidelines that would be the case but uh like i wouldn't say i reject the standard i would just prefer see this not included after uh uh the discoverable interface discover uh standard uh process so maybe that means that in the short term might lead uh towards a rejection
- 20:41
but uh i do think that uh having this is better than not okay thank you marcelo evgeny do you want to go next no okay sure so well just just bring some context uh about my experience with nft in general like as in in the community is i've been working on the tooling side uh quite extensively meaning like off-chain and on-chain as well and what i discovered there are indeed a lot of problems with discoverability and
- 21:23
it's not solved for nap 171 uh but at the same time i see that with the proposed solution of having um an app that would just help people to identify whether transfer mint or and burn methods are available would be even more beneficial than having just a non-transferal nft standard as it currently states so with that in mind i am leaning towards rejecting this uh standard as if it is today
- 22:05
and strongly support all this future um effort in in writing this uh extended um an nft discount interpreted detection and nap going forward yeah um worry i guess overall given that we are in the same like we have the uh currently we have uh evgeny and marcelo um on the board and uh well uh again do you want to uh to um to participate uh in in the voting uh today or do you prefer to um yes
- 22:54
i would agree then with other approvers that probably instead of having just two types of nfts in terms of the functionality it's better to have some more generic interface that would allow more flexibility in terms of what functions are present or not okay well it sounds like we are at consensus that we can well officially move on to this voting process so ori you can take a stage and just help us to
- 23:28
make it more formal here cool yeah so as part of the the decision making step of this this nep process um we're looking for two third consensus you know on either like we have two third majority to to approve or to reject it sounds like in this case there's there's more of a majority even beyond that but i want to just ask just to to make sure um that we have it on the call so it seems like there's a leading there's a consensus leaning towards uh
- 24:02
rejecting the current nep as it is written um if you if i stated that correctly please yeah please thumbs up if if you disagree with that thumbs down so yeah working group members i don't have a emoji here so i'm using it's old school okay okay cool so it seems like we have reached a consensus then uh towards rejecting the approval um the the proposal at this time and obviously we'd want to leave
- 24:32
specific comments in the nep itself uh you know as we discussed on on what it would take uh you know for a future proposal uh uh to look like so yeah we will summarize the the discussion on the ndp itself and ask the working members to formalize their vote there after the meeting so okay great so i think now it's time for q a and i see actually there's quite a bit of chatter and questions so we can
- 24:58
go um yeah we can go through them so ben couric brought up a comment i kind of disagree with the spam nfts being irrelevant irrelevant with the standard this is a much bigger issue than it is for regular nfts as with regular nfts you can simply transfer them away well just just to briefly mention that uh why because it was my decision to market as irrelevant uh i feel that you you won't battle with the spam spending your near just transferring
- 25:32
something again like away and usually you would find some way to hide them and that's much easier way to deal with those so it's i feel that could be a separate standard that would basically have some blacklist or white list of contracts that will be part of wallet uh standards going forward uh yeah you're gay i want to say why this has nothing really to do with spam like this nepa the problem is that someone can make a token that implements the regular
- 26:14
nft standard but which is not actually transferable like they have a transfer function that always panics for example and so you can't really fix this with a standard because spammers their adversaries they can not follow standards and they even can set very high you know gas uh expectations for that function you they will burn everything you just just panic or or just panic yeah also from then is i'm also confused about the approval rejection process we're doing right now if there are concerns that are
- 26:54
unresolved shouldn't we resolve the concerns and vote in the proposed resolutions first until most things are resolved and then approve the nep itself that's a great question well i do uh i do agree with ben i think this is a lot of problems right now even it was uh rejected but in general i just think that there are before we need to have a potential solution i guess worried the best way to describe
- 27:23
it with with the diagram we had uh in the previous slides and ideally so today as already said it's our first meeting and we choose to force things a bit but going forward we'll try to make sure that all the decisions are recorded in the nap itself and the meeting will be mostly used for a formal final discussion if there is some tie or just uh out of order work group meeting where we would have the who would this we would
- 28:05
ahead of time um agree that we need to have a sinkhole with with the community with the work group and discuss matters so this to today call is a bit uh unusual one i also want to add uh for everyone that one of our core goals of this workgroup meeting is to make sure that discussions that are started are actually ended and they are not ever never never end in discussions it's not not in anyone's interest to have
- 28:39
a discussion on the proposal that just doesn't end and so um we're very we're open um for any suggestions how it can be achieved in general so if you're on this call or you see it later as a recording please suggest to us how you recommend to resolve this issue the current way we're resolving it is that we put a firm deadline for any kind of proposal we say by the end of two months it should be either approved
- 29:10
or if or it should be rejected like and you we can reject things based on right this is the rest concerns are still being brought up they're still unresolved maybe this is too raw or maybe this is an indication of some kind of inherent flaw uh in in the in the proposal itself um so that's uh our way of of addressing it is that if it not if cons outstanding concerns are not results after two months it can be indicated or like maybe deeper
- 29:39
underlying issue but as i said we are also open uh to anyone here to propose alternative solutions to it so there's another comment would this mean extending nep 171 with an interface to check if the token is transferable or not yes sort of so we actually discussed on nap briefly though that there is a huge interest in knowing whether burn interface is available whether mint interface what what is the name of the mint function so uh it could be as slim as just a boolean
- 30:22
flag but i hope to see if we can make it more generic and cover mint and burn methods as well somehow i was actually uh even thinking to take it further if possible i also don't want to just take this particular standard but uh on a feeling there is an interface is total uh standard that allows uh contracts to tell which interfaces they implement so it's possible for uh for a contract to implement several interfaces at the same time that are not related to each other so maybe we can
- 31:02
also have something like this in here and i think that's exactly what we could use in this case yeah and i saw that cameron just asked a question and it looks like max just responded to it max did you want to speak to this the question is is there a path to editing the proposal for it to be approved at a later date yeah basically it's continuation what i was saying is that if we reject it then it can be either indication of well they can't
- 31:32
either concerns have been generated and not been answered which might be an indicator of inherent issues so maybe start again rethink it from the scratch or maybe just also an indicator of a lack of the interest from the community right if someone proposed an idea but it was not developed by anyone even if it was a good idea maybe there is just not enough demand and no one uh took it over
- 32:00
as a torchbearer and having polished it to the end so uh just to keep things going you know start another pull request it's really up to you whether you like literally copy the code and edit it or like copy the original request and edit it to address the issues or you start entirely from from the scratch yeah but like the form the formal part here is at the start and you pull request okay so then uh another question from cameron is what is the next nep that is
- 32:32
going to be reviewed how is this decision made yeah that's a really great question and and that is something that we're actively still figuring out in the process you know we have a list of neps and we're trying to figure out how it makes sense and so i think we're actively exploring that like that way and would love ideas but i assume also just kind of uh looking at where there is uh activity
- 32:56
is probably a good place to start kind of seeing like where where is there seem to be a lot of interest and engagement again as i think a few have mentioned earlier we really want to start having more of this dialogue in the neps themselves and you know once we have enough of a backlog of naps and we need like a very clear here's how we protest that we will make sure to also specify that approach you know we have another um
- 33:20
work group that we plan we we picked another nep to try this experiment with and we will follow a similar sort of approach and then kind of gather all the the feedback and insights and continue to iterate from there all right does anyone have any other questions i do a question for jester uh even it's uh and your main interest to have this standard is are you or your team available to work on a following of any key that helped address current
- 33:53
concerns for which visual was rejected so just to just to check our question that was a are we planning on working on a on a new nap for the same standard that like addresses the concerns is that what the question was yes i think in this case it will be about addressing the problems of uh interface discoverability uh and it's wondering if yeah um maybe just if i could quickly slip in i feel like just in the in the discussion i guess then it yeah it feels like i got the
- 34:32
impression that there was a way forward with with this existing nap and like i understand this is kind of a working working progress of how it works but i guess i don't know somehow practically i guess it feels like some sort of like on hold status or something like i understand you guys want to get through these naps as quick as possible but just yeah it feels like there is a way forward i guess then but yeah i'll follow the standards and
- 34:56
given that i think it makes sense that like once this interface detection is here that we would essentially yeah uh include that in a in a new net for the same thing so to answer your question yeah i think we'd be happy to consider a net that would that would include that i guess it just feels like we had it and we could have included it but it's if it's in you and evidence and you have this one
- 35:19
yeah yeah i would recommend to actually write first maybe in the near forum uh to start a discussion there um yeah so such that we can actually get to some consensus and then become more of a formality than anything else of details technical details yeah yeah i think it'd be handy to to get some consensus going in a in the forum first i guess then as to what would be required uh so that when we when we submit the net the next time that like
- 35:51
we know that they'll be that they'll do some backing from the approvers that those that those concerns won't come off again so yeah that'll be helpful yeah one thing i want to mention is that i i i personally hate to like reject snaps because i know how hard it is to to make those been been there done that and been rejected a couple of times for different reasons um totally not fun but overall i feel like uh we are guardians
- 36:23
of the ecosystem health here and this like especially breaking other tools i know how like i've been on the other side as well where implementing tools you need to then create a lot of uh custom code to just avoid detecting the thing that you don't want to take into account so uh definitely it would be like we will need to think through of some faster way to get semi-consensus
- 36:57
as you mentioned so we don't spend so much time um talking through it um i i personally wanted to just make some progress even even if it's harsh and you know uh feels um and like that we are so strict and decided to reject for sake of rejection it wasn't the case it was very hard decision as i mentioned in all my comments yeah yeah and jasper in that doc in that link that's actually on this screen there is a whole part about like yeah the the front end of the process and like you
- 37:39
know kind of engaging in the governance form but i will go and actually try to make a really explicit sort of idea that you mentioned because i think it's really good oh and i see that max just answered cameron's question about the next nep that we should review max did you want to speak to that yeah uh definitely this is the beginning of the process for nomination so someone needs to speak up and say hey what about this snap so thank you cameron for bringing it up as we said in the future we're gonna have an actual pipeline for
- 38:10
this but right now this is exactly how we have this nap surfaced um we gonna look how it stacks against other neps so we need to look and see whether anything is on fire right now and we need to discuss something urgently there if not then this is a really good nomination to discuss multiple fungible tokens standard next regarding your next question of uh which of the pull requests slash naps should be uh discussed uh yeah if you feel very passionate about this nep then please
- 38:44
help us by deduping them uh either close such as the closed one merge them together whichever um that will certainly make our life easier to focus on one nap instead of two so ryan just posted one depending on your schedule for how frequent these meetings are another one or more than one that will come soon will be from j code l relating to some important important partnerships okay yeah please reach out i don't know what this really means but yeah definitely reach out if you have any
- 39:16
questions thoughts concerns ideas okay uh one question of my own audi is it supposed that every nfp should go through this process of approval in a meeting yep okay so there will be different work groups as is already presented in the very beginning that we will also have a protocol working group which will be using the same nap process same repo but there will be a different people in charge of reviewing those and there there even could be
- 39:58
a stricter process there and we believe that uh protocol is uh super important uh to make sure that those features are actually implementable and will lend eventually and uh contract standards are of a different nature and it's more like finding how the tooling should fit into the table so expect all those working groups focusing on different aspects being more or less uh strict about their requirements but overall
- 40:36
like i i work with worry closely these days and i see a lot of work put there to make sure everybody on the same page and the community can have certain expectations which is like which contributes to transparency at the end of the day and um yeah or do you want to speak uh there yeah no i totally agree and um yeah we're just going to continue to try to iterate on this and would love ideas concerns uh participation because
- 41:14
that it's gonna it's gonna be a collective effort right to figure to figure this out and really the goal is to create more more movement you know on these neps that a lot of them have just been sort of sitting in an idle state and we really want to give them the attention that they deserve because everyone has you know great ideas and we want to to align and help evolve the ecosystem so yeah cool so with that i want to thank
- 41:38
everybody for for attending today uh especially you know jasper the author thank you for taking the time to submit the the nep and engage in this process that we're figuring out uh you know as we go and also thank you to the working group members the panelists who joined today and who have been involved in the actual forums and and in here and then of course to the community and everyone else who has been
- 42:03
engaging that's super awesome and we hope to to see that continue just in terms of next steps so we will be posting this meeting uh recording and summary and github we also have a website that we put together for the working groups that will list the upcoming meetings that are coming up and as well as links to previous recordings so we will have the protocol working group meeting most likely happened in september we're actually actively discussing uh you know nep right now uh
- 42:34
in the forums and i hope to figure out the best one to to have this this this process uh tested with but yeah other than that i think this concludes our our first working group session so thank you everyone so much and hope you have a good rest of your day or evening wherever you are so take care you