Contract Standards Working Group Meeting – January 13, 2023

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

1. 0:03

   everyone welcome super excited to have our third contract standards working group call my name is Ori and I'm a technical program manager from Pagoda and just to go over the agenda for today first I will give a quick overview on developer governance and some updates that we've made there next we'll do some brief introductions as we have a few panelists joining us today then we will

2. 0:29

   jump into the main discussion in f351 for 23 and 431 and the links for those are on the invite to this call in case you want to follow more closely then we will open it up to q a and lastly we'll talk about next steps and how you can get involved in developer governance we're going to start with a little bit of background on developer governance so over the last few months we've been

3. 0:53

   engaging with the community over this initiative which is really about bringing people and organizations together other to help build a decentralized developer ecosystem and we've been bucketing most of the developer community activities into four buckets ideation implementation review and support and I just wanted to quickly highlight them to help contextualize our meeting today and how to get involved in general so starting with the ideation this is

4. 1:24

   about sharing and exploring ideas with other people in the ecosystem so anyone can submit an idea like improving the protocol or standards and it's important to have a place for people to freely Express and explore their ideas in in a welcoming and permissionless way and one way to do that is on the developers gigs board and this is a new platform on near social that we've been working on that enables anyone in the community to share their ideas and get feedback and support from the community and it's still in the

5. 1:57

   early days but anyone who has an idea is already welcome to post it today and start conversing with the community now you may have a seed for like an early idea or you just want to explore a topic uh with others so another great way to get involved is to join an existing community group and Community groups is a self-organized group of people who who's interested in a specific topic like zero knowledge or wallet standards and it offers a great

6. 2:27

   opportunity to discuss ideas and collaborate with like-minded people and a lot of these groups have started and they have dedicated communication channels like Telegram and as well as regular meetings and you're welcome to join any of them or to start one yourself you can find them on the developer governance website and we're also going to publish a blog post really soon that will highlight some recent learnings and insights from some of those groups so what if you already have submitted an

7. 2:58

   idea and you want to turn it into code that's what developers do right so this is where implementation comes in and you can also use the developer governance gigs board to submit an implementation solution to your idea or if you have an alternative solution in mind for somebody else's idea you can also propose that as well and this is just a really great way to help gauge Community

8. 3:23

   interest and support and get a variety of perspectives so that we can strengthen our problem solving and Innovation collectively as a group and if you have an idea that you want to get integrated across the ecosystem like a new contract standards or protocol improvements or if you're seeking funding support you will need to get a more official validation from a recognized group of experts and you can do that by submitting a net

9. 3:49

   a near enhancement proposal which may be familiar to uh many of you especially the authors on this call who have submitted them and this is a rigorous process that is similar to other open uh Source projects like rust and it enables anyone to submit their proposals and get them reviewed so so what happens once you submit a nap and how does it actually move forward so this is where

10. 4:14

    the review comes in which involves the working group like the contract standards working group that we have here today and the working group is basically a selected Committee of subject matter experts that help review proposals in a furly and timely manner and oversee decisions and there are multiple working groups each one focusing on a different ecosystem need and we've already kicked

11. 4:39

    off uh four of those groups who've helped to bootstrap the net process and we've been iterating on those over the last few months to learn what works and what doesn't and we hope to continue to introduce more groups in the future and empower the community to run them and iterates further so yeah I just wanted to go a little bit into the roles that are involved in the net process and then

12. 5:00

    we'll jump into the um to the call so first we have the um the author or champion this is the person who writes the proposal and presents it to the working group then we have the moderator the person who facilitates the process and helps helps validate that the proposal meets the guidelines and and progresses forward we have the reviewer the subject matter experts who review the technical

13. 5:24

    feasibility and then the working group member the approvers who helped make the final decision and there's a diagram on the nep001 that illustrates the process there are basically three stages draft review and voting and two outcomes approved and rejected and all the roles that I just mentioned helped move the nip through these stages and towards the outcomes now most of this happens asynchronously on the net itself within GitHub but when we do get to the voting stage each

14. 5:54

    working group has a public meeting to discuss the neck with the author and to formalize the decision and that's exactly what we're doing today we're looking at three different maps that are in the uh voting stage and lastly I just want to talk about what happens when an app actually gets approved and how can the implementer seek seek funding and so this leads us to the last area which is

15. 6:19

    support and basically once the working group completed their technical due diligence and approved the proposal they can use the dev gov gigs board to post official attestations and this tells any potential sponsors that there was a formal review done by recognized experts in the ecosystem and any organizations or individuals can choose to sponsor that project so this was a lot of information in a very short amount of time uh so just to make it easier um there's a blog post that you can

16. 6:51

    check out later that goes into more detail on the on the developer governance website so with that I want to officially uh get into the contract standards call and start with introductions so I'd like to introduce the official contract standards working group members and hand it over to Marcelo sure yeah we're doing this uh each time um so I'm Marcel a former developer developer near and then a developer at

17. 7:21

    Aurora I've been involved in the near position for a long time and I'm very happy to collaborate in the moon forward all these standards oh Jenny hello my name is evgeny I work at Pagoda on the protocol security and Bolson contract standards and me jumping in right here I'm Vlad I also joined me in here uh when it was quite early days before launching my net for sure and we've been work I've been

18. 8:02

    working on different projects throughout the whole landscape of uh in here including Explorer indexers and now I'm very Main uh head into the naps and dedicate my time into the Wilbur Gardens full time happy to be here so let's move on to the next slide Lori awesome uh first I'd like to welcome Osman hey guys Osman here um from Pagoda as well working in the ecosystem for about two years now um worked on the wallet near api.js and

19. 8:43

    also now wallet standards and devtools in general so yeah plasma hey everyone I'm Lachlan uh I'm an engineer at few and far uh nice to be here awesome yeah and then uh farat is unable to make it but um but we but he gave me the content for um for the slide for his nap so um yeah awesome well let's get into the actual enough discussions these are the three naps once again and I'm gonna hand it over to uh Osman to just give a little

20. 9:23

    bit of a author summary you know of the snap and uh then we'll get into the discussion yeah all right um yeah so this snap is an extension to an already existing map that um is about the metadata that's on the contract and currently it's very focused on the source code so um there's a there's a view function that's proposed on the on contracts that is called uh contract underscore Source

21. 9:49

    in the score metadata and currently the the existing map 330 uh proposes that you get back the version so a commit hash um of the code that's on chain and you also get back a link to the open source code um so basically what this map this extension is proposing is we add an additional key to this structure that is a list of um of naps that the contract adheres to and this helps with things like if you want to know like what uh methods other

22. 10:23

    methods to expect what events that would be emitted by the contract any other abstract ideas so like API might fulfill some things like what what a function calls exist and stuff like that but this this will allow you to know like what nuts that are part of like whether it's a nap or another standard even outside of not that the contract adheres to um so that if you're building a client

23. 10:49

    you can build it around that and you can you know what Behavior to expect from the contract um and it proposes it just uh an array of a map basically that has a standard key and a version key so you can see it at the bottom that I could like uh just standard inversion and it's just an array of these so for example nap 141 version 1.0.0 is what we have on screen there so yeah very simple just an extension to the existing view call that tells you what maps are available that

24. 11:20

    whatnaps the contract adheres to awesome thank you for taking the time to to submit uh the snap and work through it uh so the community has reviewed it along with uh subject matter experts and the working group and I'd like to invite uh Vlad to summarize some of the benefits and concerns that um we saw yeah sure so the main benefit is that it's and first of all it's an improvement to the whole ecosystem um the tooling the own chain can use the other contracts can use this information

25. 11:58

    to better integrate um with with other contracts um instead of blindly expecting to happen something to blindly call in some methods um and this enables um compatibility composibility of the contracts and the last but not least this change is a non-breaking change um it's totally optional for the implementers if somebody already implemented nap 360 then it's it's not breaking those contracts though it's definitely

26. 12:38

    beneficial to update your contracts if possible with this new um feature and it's uh it's just super nice addition to to this to the quality of life of contract developers that want to build composable contracts so we also explored the concerns and well had different concerns while we reviewed the nap initially and I collected this list of three uh main concerns that were highlighted um let's go one by one through them the very first one that when initially it

27. 13:21

    was introduced we had an integer field representing the standards um map number um meaning that we would just see that it's a nap 330 supported and then if somebody would preferred not to submit a formal nap but instead just introduce their own neutralization in a centralized way it's totally fine like XYZ uh company could decide to run their own registry of of uh standards and that would be a bit of collision and like uh and unfortunately

28. 14:00

    one that it's it wouldn't be supported that's why we went with the string value where we we recommend people to use nap the pattern of a prefixing map and then a number so nap 173 uh and XYZ 001 could coexist and it would be totally fine for contractor support like standards of a different basic sources which is super nice I've seen people doing this for Json events uh they didn't uh you don't need to register your own

29. 14:39

    um Contracting your own needs uh and and make it a nap in order to to emit Json events and this is we just borrowed the pattern so it's uh aligned and also quite extensible um going forward uh so it was resolved Osman took another look and addressed it so now we have this nice flexible interface um another concern that is still not uh update like addressed in the in the uh pull request but it seems like there is

30. 15:18

    a common uh agreement there is that nap 330 and nap uh 351 uh should be defaulted and like listed as supported as implemented naps so it's sort of a dog fooding here so it's it seems reasonable uh to have it on the list by default um I think it's a minor thing um and we will address it after the call and the third concern that was raised uh was that it could be beneficial to have Json events about when the metadata with this contract Source metadata is changing

31. 16:01

    but it was decided that it's outside of the scope of this snap and given that usually the source metadata changes only when with the contractor deployment that could be the basically event people could subscribe for and once the code is redeployed just check this contract Source metadata so it shouldn't be really problem I I believe and it's even more reliable than uh introducing a decent event that expects people to

32. 16:35

    implement it so we decided to postpone it and probably won't fix in the future so the these are the ones I collected from pull request itself um as we were discussing previously um with the previous calls of the working group uh we maintain all the information in the comments or on the GitHub so there is nothing new here it's just a summary um we encourage you to uh review the naps and the commit a comments there if

33. 17:19

    you have any other additional contexts so we don't miss it and don't have a last minute you know through prizes so but still there is a chance right now for last time to maybe highlight something uh that we totally missed and that could be a potential blocker for us to merge uh but that's basically the summary uh or do you want to uh to to take a word and say what's gonna be the next steps

34. 17:54

    yeah so as you just mentioned uh about everyone kind of already commented on the nap and presented their their indication but I'd like to hear from each working group member just like based on these benefits and concerns and everything you saw where where are you leaning in terms of your opinion um and I think that brings us to basically the decision uh stage so yeah who wants to go first

35. 18:22

    um yeah I can do it so in general this is a very straightforward uh and useful map I already wrote this in the in the comment section and I linked towards uh approving this now maybe maybe you go next that will be lost I think it game is frozen so maybe you go Vlad oh I see uh sure well as I summarized in the in the previous slide uh the concerns I um recognized were all addressed and

36. 19:02

    resolved or decided that it's not the time to to even look into them so I'm lean towards approving the snap and yeah yeah I see some uh shot me saying yup yup so I think that there seems to be support um awesome okay well we need two third volume majority to make a decision and it sounds like we already have that um I do I would love to hear from evgeny as well if he's if you're able to hear us but if not I think we can probably rely

37. 19:37

    on the the two-third vote as well as the comment that we saw from you which said that you were also leading towards approving it Afghani are you there or no okay we will proceed for now and hopefully we'll regroup with evgeny so awesome so I guess uh this snap is officially approved and shot seems pretty excited and I'm pretty excited as well uh so let's talk about the next step so where do we go from here uh so Vlad you want to speak to this as

38. 20:10

    well yeah sure so in terms of next steps um this is an app and it just it's basically a standard and uh so far it's more like a recommendation and we would need to have the um um better support in SDK so people can benefit from the snap immediately so there is a need for design and better tooling around it um like on the on the sdks level and then on the API packages um like in in your api.gs and near API

39. 20:50

    Pi um to you know um make people's developers uh life easier so this I so far I haven't heard any um Champions uh willing to take this snap to the implementation stage and this is where we are standing right now in terms of implementation so let me just walk you through what would be the next step as I see them first would we would need to so we actually were looking into the previous uh experience of previous previous snaps

40. 21:31

    it seems like it's very beneficial to include benefits and concerns section from the presentation uh the summary into the map itself for the future reference so those who would read this the nap itself years ahead would have a chance to understand what were the limitations what we considered as a problem what we decided it's not a problem so ideally we want to embed this section in the nav documents going forward and

41. 22:03

    Osman if if you would uh be happy to take it it would be great otherwise we would take it as a burden on the moderator side ideally as as you may have seen we have a lot of naps so it would be great if if we would distribute the load um so maybe let's sync up in the comments later on uh if you don't have time to do it uh the second step is to add the change log uh same reasoning uh it's it's better for a future review to understand the evolution of the nap and

42. 22:41

    what was added when so it's not a surprise for somebody that well somebody would think that they implemented an apps 330 and then suddenly the content changed um so it would be great to have a change log um in the in the nap itself so it's another change in the pull request but well given that nap is already approved it I feel like it's just final polishing steps and then once that is done by Osman as author of the nap or by

43. 23:14

    moderators we already and I will jump in as a map moderators I'm I'm playing the troll as well but not today uh will help and merge the nap a proven margin app in the GitHub repo and then we will create a call for Champions um post on the gigs board so that's the strategy I I believe for us it's it's as we stated before this whole process is getting improved over time and this is the next iteration of it as

44. 23:55

    you may see we have a more clear structure here and like better understanding uh what what needs to be done next we are stepping into the um area where we leverage gigsport more and more these days so expect to see um engagements uh over there um Ori do you want to add anything here yeah this was great thank you so much for for clearly laying this out for everyone I guess before we move on to

45. 24:27

    the next step I just wanted to ask I know there are several attendees on the call like is there anyone who's potentially interested um you know and and implementing this snap taking this this on or being involved in any of these next steps or are there any questions and we can also come back to it at the end but I just wanted to open open it up in case anyone had any burning thoughts

46. 24:59

    okay well in that case um this is awesome I'm super excited to have this uh net move forward and uh yeah we'll regroup on the net itself with next steps yay okay we have two more to get through now we have the drill figured out so the next ones will be even uh faster right all right so uh did you uh had the chance to rejoin and you now can hear us yes I come here you unfortunately my

47. 25:32

    Wi-Fi is not very reliable but hopefully it will work awesome yeah we we had to move forward uh but still it's probably beneficial to well it is beneficial to hear all the working group members opinions so do you have any like okay can you share your um um basically decision uh over the snap how do you feel about it so I'm in favor of this snap I I don't know how much of what I was saying you

48. 26:04

    like got through because my connection like stopped working when I was speaking I think so I am in favor of the snap because I'm repeating what I said you there is a need for developers to know which features contracts Implement and without something like what is proposed they will try character heuristics like trying to call some functions and check what works and this can be unreliable so having some

49. 26:38

    something like this is instead is much better for them totally agree awesome I'm glad we have it in the recording so we know we didn't speak uh incorrectly on your behalf so all right perfect so with that I'd love to move to the next one uh NEP 423 and to invite Lachlan to speak to this hey um so yeah this this was driven by a situation or multiple situations where um we encountered that uh contracts had or contract owners have updated uh

50. 27:17

    things like a base URI for instance on the contract uh because maybe they they purchased a person uh dedicated ipfs Gateway and they wanted to add it to the contract and they added it to the contract except no one knew about it uh and also I think this is pretty uh reasonable expectation that someone might want to change the name of the contract or the icon etc etc um after it's you know initially initialized

51. 27:46

    uh so this this event um is intended to remedy that uh so that any updates to the contract metadata are broadcast um and any uh tooling can can update uh accordingly awesome thank you for that summary all right next benefits Vlad same drill yeah so well uh it's an again very nice uh quality of life improvements and this uh definitely something that I personally was also hitting uh while implementing

52. 28:31

    the indexers myself and also uh needing to either excessively check the metadata almost at every single block or a hope for the best that metadata didn't change and then discussion validation problem uh is one of the um artist ones in the computer science area so it's very nice to have this extension to the events on the nft conflicts I think we'll also benefit from having such event on other contracts and other standards going forward this is a this thing paves

53. 29:16

    the road I feel and just to mention this is not not a breaking change so all the previously um existing contracts will behave exactly uh fine and nothing is changing in terms of the expectations to them um speaking about uh like breaking changes uh on the cons on the concern side of things can you switch the slide here so there is um there is an unfortunate situation that we have all the nft contracts that do not emit any adjacent events at all and there are current nft contracts that

54. 30:00

    only emit mint burn and transfer events but the hope is that eventually the new contracts will um will be upgraded or just new contracts will will be deployed and the Legacy contract will die out with the time so I think it's not a blocker for us to consider so I adding this event will definitely help us down the road um even though it it wouldn't be the immediate help for us and the other concern that was raised in the

55. 30:40

    comments was about adding a similar event for individual nft update so when whenever NF like each nft item is edited uh it would be great to also have an event about it but it was decided that it's uh it opens up too many other questions and concerns it's better to split the it into two different discussions so um we will merge this one first and then potentially discuss the another event

56. 31:16

    added to the nft standard uh without with this set both of the concerns are resolved and uh it seems like we are good to go forward all right so yeah can we go around and get each member to State there no I guess so basically from my point of view it's only beneficial and as I said I personally uh wanted to have such an event uh once I Implement started implementing indexers I'm totally

57. 31:57

    um aligned with the with the goal here and uh I would I can see my my previous team benefiting uh this new standards and Italy um see no downsides uh right now so I'm I'm voting for approving it um Marcelo maybe go next yeah um yeah so the fact that this is uh not a breaking change um it is actually solving a problem that developers have makes it like a no-brainer to approve so yeah I lean

58. 32:30

    towards uh in the beginning and I also lean towards approving this snap just with the pre just like with the previous snap developers need this functionality and without the standard they will try to use some heuristics which will sometimes work sometimes not work and they will still need heuristics for older contracts but at least with the newer contracts which implement this it will work reliably they with the

59. 33:05

    virus tools will know when the metadata is updated so everything will be better cool cool well I'm hearing unanimous uh consensus um so it sounds like this is the snap is approved uh which is awesome yay two naps in the same day so yeah I love that comment from shot like the new ecosystem has changed so since I've gotten involved in the net process like I don't recall ever being having two nips in one medium that we're able to get through so

60. 33:40

    definitely a lot of kudos to everyone that's involved in in this process and helping to move it forward and for anyone who might be new to this there might be a lot of steps and maybe formalities but really we're trying to make it very transparent and and to evolve this and if you have ideas and ways that we can make it better please feel free to to share them okay so in terms of next steps kind of oh sorry kind of similar to the

61. 34:05

    other one but uh glad yeah well really very similar to the previous one um it was was probably one exception over the comments we had uh uh I I believe Maybe Maybe I'm Wrong actually let me know if if you previously stated that you would be happy to implement it into SDK at least near near rest SDK yeah I did I'd be happy I'd be happy to do that um I think there was just um I don't know a little discussion about the exact like implementation um

62. 34:45

    but yeah happy to do that awesome yeah but still other tooling would also benefit from it uh so we'll we'll see we'll um still post a a call to for Champions on the Geeks board and as I previously already mentioned I I would love to to ask you to embed the benefits and concerns and introduce change a lot of changelog to the uh to the pr if you if you don't have time please let

63. 35:21

    us know and uh or in or I will jump into and help there but ideally uh it will be very helpful for authors to help with the final mile here Murray do you want to add anything here awesome I think we're ready for the third nap unless anyone has anything else for they want to add to this one we just discussed okay so let's move to net431 and as I mentioned farat was unable to make it to

64. 35:57

    the call I'm curious if there's any working group member who's maybe willing to just speak at a high level to the snap just to give context for maybe anyone who might not be familiar I can do it okay thanks I'm speaking too much today hopefully we'll you know you're you're not too bored with my voice here today but uh the overall let let me just present the summary of the nap or the proposal here uh so it is an

65. 36:28

    extension to the existing fungible token contract uh which suggests to add new functionality to introduce allowance uh for other contracts uh to other accounts uh to be able to spend your tokens on like on your on your behalf uh so the the use cases that were presented there um included a subscription model like allowing somebody to charge you uh by just giving them a certain allowance ahead of time another use case was

66. 37:07

    making it sort of zero cost for the owner of the tokens so they would create an allowance once and then the other party would charge it and use those tokens on the behalf of the owner and pay for for the gas fees themselves so this is was the the idea and yeah let's jump into the benefits and concerns slides um the well after after the discussion uh in in nap itself it seems like there are other ways to achieve the goals and

67. 37:52

    also the um the the goals themselves could be addressed in a very different way to begin with so I spent some time and tried trying to actually encourage the benefits of this specific map unfortunately I couldn't so let's jump into the concerns so maybe I can unpack what what I see is is why I don't see the benefits here um and not only me it's it was actually every single uh reviewer highlighted

68. 38:28

    those and we basically just were super aligned there um that this map does not solve the zero cost transfers for the for the person who received the tokens uh from somebody they would still need to submit a transaction and pay for the US in order to create this allowance to set it up so it's not zero cost at all and then it opens it it opens up a question like how to do how to what to do with with the allowance

69. 39:07

    amount is it frozen uh or should it be like always available to to the um to the person we are approving access to um so it's all kind of worms with just allowance itself the second concern is that the subscription model also doesn't work because the the service you would need to either create a very big allowance or renew your allowance regularly which defeats the purpose of having this subscription pattern

70. 39:46

    uh kind of so tough uh halfway um it may also potentially open up security flows as pointed out in in the more extensively in the comments um and also like this allowance how much it's a reasonable amount it it from the ux point of view it could be quite challenging and also the major one I feel is that existing fundable token contracts which are I believe the the most used uh and will remain to be uh quite heavily used going forward uh are not likely to adopt this

71. 40:27

    extension because it would require them to go through the whole cycle of review and it's uh it's expensive and also risky uh and this whole pattern of creating allowance allowance could be uh implemented as a separate contract um where you would just transfer your funds like a deposit and then set up the subscription or spent allowance from there so I think composibility is a better way to solve

72. 41:00

    it rather than beefing up the fungible token standards with even more complex features so this was the these were the concerns that I collected from the discussion um I think um yeah I'd like to hear Marcelo and guinea as well if I missed anything and you want to add before we move on um yeah one thing is that uh the fact that we don't have free that here uh it's a little bit uh bad right it

73. 41:41

    would be good to have one Champion uh from the comments in the GitHub uh I guess per all of us are leaning towards so it's good to have someone who is a champion this map uh but but anyway I do uh agree with the points uh presented by Blood and I think it's not if required to be implemented in a separate uh in a separate contract um yeah General I link towards uh reacting business New Guinea

74. 42:17

    so I'm also thoughts rejecting the snap I like have many security concerns in mind starting from some race conditions although this snap is trying to resolve some race conditions by having a argument to the function that that allowance which is the previous allowance so potentially if it changed like this function will fail there is still but but then it's still something that the caller needs to handle and this

75. 42:54

    can be problematic like this handling can be incomplete and lead to some security issues but it's not the only one even like the way this allowance system is used because it exists on ethereum we have some real world usage data and I've recently read an article which basically told people to look which contract they have allowance for and to remove it if they don't need it so in fact people tend to set this allowance to some contracts and

76. 43:33

    forget about it and this makes kind of security hole in their wallets and we don't want to enable like encourages this kind of insecure usage so it's better if we just don't have it in the first place ethereum cannot do it they already have it but we can avoid it that's pretty good point thanks for learning it from the other experiences that already can show the there's it's it's not the right thing to do yeah and me myself as I already

77. 44:16

    mentioned I'm leaving leaning towards to rejecting as well so it seems like we have again Union decision of rejecting it uh this time um yeah so I think it's great that we have a full packed agenda for today with three naps even though not all of them are uh getting approved it's very important step to review all of them and make it make it clear the reasons um why we are making this sort of that

78. 44:51

    decision here yeah already do you want to add anything here cool yeah no so it sounds like we have the decision which we will definitely formalize on the net as well I think just in terms of the next steps for this one um it seems like we're just gonna do that exactly on the net and then if anybody is interested in picking any of this up you can always start with a new idea a new nap um and uh I purchased from a from A New

79. 45:15

    Perspective so all right we got through the three next so I want to open it up to q a or feedback uh for everyone who has been paying such good attention as we went through these three different depths so yeah does anyone have any comments yeah well uh so just to I guess close off um I do want to highlight some ways that uh you can get involved really quickly so as I mentioned uh the gigs board is a really good place to to get started if

80. 45:48

    you have a specific idea in mind you can go there and submit it or start responding to other people's ideas you can also add a solution or implementation details to those if uh you are if you have an idea that you want to get integrated across the ecosystem or you're seeking funding you will also need to submit a nap after you have that idea on the gigs board uh so you can do that uh on gig on GitHub uh

81. 46:14

    you can also go and view all of the naps and in the various statuses on GitHub and join the discussion uh there is a community group as well for contract standards so you can join that to just seed ideas or connect with others and you can learn everything about developer governance on our website side and our social accounts and we definitely have a lot more uh coming and we plan to continue to iterate uh you know and make this whole ecosystem better so yeah

82. 46:48

    lastly I really want to give a huge shout out again to everyone who has been uh involved the authors of those three naps uh Osman Lachlan and firat the working group members Marcelo Evgeni Vlad the subject matter experts who helped do the technical assessments so Robert Olga and and everyone else who's just a part of this uh it really is a community effort so thank you so much and with that I want to wish you all a great weekend and reminder there's a

83. 47:19

    there are two working group meetings happening next week so please join them if you can and yeah with that thanks again and take care