NEAR Developer Tooling Community, 17 Jun 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: DevTool Community Meeting (June '22)

Description

This month we talk about the creation of an ABI (Application Binary Interface) that will help developers understand how they can interact with smart contracts on NEAR.

Share you feedback & ideas for an ABI on NEAR.
👉 https://forms.gle/isDfKyuZw2e3DTks8

Register here to join next month's meeting:
👉 http://near.ai/tooling-meetings

__________________________________

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

Welcome everyone to another find developer tools, community update we will be having today uh for june uh today, we're again gonna go over the regular format going over what happened uh over the past month and then we're gonna have an open discussion around abi um yeah, looking forward to getting some feedback from the community on this interface that we're uh creating so yeah again at any point have any questions: please drop them in chat or preferably use the q a button at the bottom of your screen, and we will answer your questions um as probably as possible, and with that I will hand it off to austin maggio uh the product uh product manager of developer tools.

A

Is that the official title yeah you got it awesome cool thanks, austin, take it away.

B

Cool I'll jump in uh thanks, josh uh yeah, as josh mentioned, we're just gonna talk about what we shipped and then dig into the api a little bit and, of course we want feedback. That's why we do these sessions, so please jump in at any point uh jump in the chat ping. Us afterwards um come off, mute or enjoy ask to join so that you can talk live, but um without without further ado.

B

I'll just start with our vision, um it's unchanged: deliver the intuitive, productive uh and reliable tools needed for web 3 development, so everything we're doing is to to move in this direction and one one massive step that we took this past weekend at consensus was our our very own josh ford, as well as uh ben, led a workshop at consensus. um This is this. Tweet is pretty cool. It's brendan ike, who is the creator founder? I guess of javascript, uh like all the creators he.

A

Had like a 10 day mega sprint, where he wrote javascript in its entirety in 10 days, pretty crazy.

B

And it was even crazier a feat to be matched by that was him introducing the javascript sdk uh enclave version at consensus that that we just uh we just released. So um if you missed that there there's a link uh josh, I'm not sure what the best way is to share the link to the consensus workshop. I think in in like 20 days or something everyone will be able to actually watch that workshop um and but uh yeah there's a yeah.

A

There's a link to it. I think it's like a placeholder link right, like you, can't actually like view it yet because consensus hasn't released, it uh officially.

B

A

B

Yeah so we'll we'll set a reminder to make sure that that that link gets sent to the community, but uh the all the materials available in github that that josh and ben covered um and it's a really cool workshop, where you basically go from from nothing to writing a full uh javascript contract, deploying it into the enclave uh interacting with it.

B

And I think that it so the I watch the workshop and it's a it's basically like a coin flip, um where you're using another contract to determine the output of a a coin flip and then in the contract that you write. It's like appending a score to a user interacting with a wallet interacting with your api js, and it's an awesome one to send to all your favorite web 2 friends. So we'll we'll definitely uh push that out as uh as it becomes available.

B

But um what I, what I did just want to draw attention to is that um what we've been calling the enclave sdk or the the jsvm uh version of the sdk, we're pivoting towards actually just the the full-blown standalone uh uh uh contract, um uh javascript sdk, which you can think of it. As just like a direct, uh a direct replacement for assembly script and it it behaves exactly like any rust uh or or current assembly uh script contract where it just yeah.

B

Oh, like um the build, generates a wasm file that you can deploy and interact with the same way that you would any other uh rust contract. um So that's that's currently what we're prioritizing and we're expecting to release that quite soon uh and we'll be really loud about that release, because we're we're extremely excited about it um and you'll see a ton of updates to our documentation, examples, etc.

B

um Awesome, uh if there's any questions about uh the javascript sdk, um otherwise uh I can pass it to all there.

A

Was one one quick one someone asked, uh will the jsvm or enclave be deprecated in favor of the standalone version.

B

Yeah yeah great great question: we're we're trying to figure that out right now. um I I don't have a leading hypothesis that it's going to be going away immediately. um So it's if it does go away.

B

It's not going to be like in the very short term, um but I would push that to the community to give us feedback of why they would want to uh what their use cases are to that really rely on the like the synchronous, behavior of the enclave, the benefits of the really small um um contract that you're actually deploying and etc, but um yeah. I would love feedback on that, um so that we can help make uh make a great decision. But at this current time we haven't made a clear decision on it. So.

A

Cool awesome and then just one question george had if we could share a link to the resources um yeah if you just go to near.ai forward, slash javascript, that has a link to everything jssdk right now, it's a link tree. It has a link to the presentation that ben and I created and then also the repo quick start, all that good stuff. um So yeah near.ai for slash javascript.

B

Awesome josh: do you mind actually just pasting that right in the chat and then well I'll pass over to.

A

Yeah, actually I did, uh and I believe you did, I believe you did too just now.

B

I think maybe I sent you to the wrong group, but anyway, um yeah oh hosted.

A

Panelists I gotcha yeah yeah, uh I see yeah, I posted it to host a panelist too yeah. I will drop them in the chat. Good call. Thank you.

B

Cool um yeah and and like like, we said we, we love feedback, so leave it in those. The discussions in the javascript sdk repo are pretty active. So just if you do have questions or issues um just please leave them in there um or or you can find our contact uh through a discord or anywhere, but uh um otherwise I think I'll pass it over to other austin um and he's gonna walk through uh some of the rest of what we've shipped uh and and dig into the api.

C

Yeah, so so before I before you go kind of go more in detail about the api, which is kind of mentioned before and we'll give more context to that, because I'm sure it's very unclear what that is uh to most people.

A

C

Do want to point out the uh the sdk 4.0 stable release because it was kind of like a long time coming and without, like any sort of you know, large announcement or anything like that uh was just you know, posted to discord. So maybe people aren't aware of this, but essentially yeah. So the the sdk 4.0 was released.

C

There's a lot of details and I kind of went over a lot of like the main changes on on a previous protocol uh meeting, um but then also there's like a migration document that shares all of the like changes and breaking changes from the previous version.

C

uh It doesn't go into like a lot of the optimizations, but it goes into like the things that you actually care about as a developer, switching from say, version 3.1 or any of the 4.0 pre-releases to the actual, like stable, 4.0 version, um but the key things to mention like I do want to just provide as much context as I can within this short within this short time is that uh there should be no state breaking changes like you should just be able to update from 3.1 to 4.0.

C

As long as the migration happens correctly there, there will be no issues and no need for any sort of like migration of your contract from the previous version to the new one. It should just be like a cleaner interface, more optimized, and uh you know certain blow cut out here and there uh with some other like semantic changes but yeah again, no nothing should be state breaking it. Just might some things might change, but everything will be listed within that migration dock that that's shared here.

C

So uh there is a link there, but I I think we might want to share within the chat um if other people want to want to jump in with that. um So so I can.

A

Share that link.

C

After after this or someone else wants to jump in and and share.

A

The link to that basically.

C

It's on the near sdk rs repository, there's like the discussions tab and then, if you see the um uh yeah something's happening with the slides uh yeah. So if you go to the discussions tab and then there's just the one for the the migration document and then yeah you can use that for for migrating between them. um Other key things to note is that um the near sdk sim uh is deprecated in favor of workspaces with this stable version.

C

um Unfortunately, there is like functionality that can't be updated from your sdk sim, so we were hoping it was going to be like a smooth transition where, like you, can keep the sim test, but they're deprecated, um but unfortunately like it, just isn't technically possible um so yeah. So if you do want to be able to switch to, if you do still want to use the sim test, you can use the last uh 4.0 pre-release and that'll work.

C

Fine, um you just won't be able to leverage some of the like the more optimized cross-contract calls, um but yeah. If you do want to switch over, the workspaces is updated, but just make sure that when you are updating the sdk, you might need to update your workspaces uh versions, because the the most recent ones will have the changes needed for this, because it does leverage a protocol change that came in which we've talked about on a previous call um but yeah. Hopefully that gives more than enough context um and yeah.

C

As I mentioned, the the main changes with the 4.0 is just basically there's optimizations new new features and cleaner apis, like uh the the primary one being like the the uh the revamp of cross contract, calls and making them more simple for people to use, but then utilizing gas more efficiently um yeah. So we we can. We can probably move on to the next slide, so yeah now on to abi, which is which is kind of a point, that a lot of people might not even be familiar. What what that is!

C

So, let me let me create some context on what abi is uh and then we'll talk about like what we're building with it and how it can be used. um So what an api? Sorry? What an api is is basically, um in our case like what we're defining is api is, is a human readable schema that describes the contract interface.

C

um So, as I mentioned here, like the the things that are going to be included with this are like, if you're writing a contract, it's going to include the function names, the parameters, serialization formats, any other metadata. That's you know relevant to the contract so that you know if you're viewing the the schema you'd be able to easily identify what what how to interact with that contract and what exists within it.

C

um The idea is that it's going to be generated through sdks, um the primary one that we're like, obviously targeting right now is the is the rust one because, um like that is the one that we are, that we're generating the tools as like primary support, but obviously in the future. This can be anything that generates this uh this dbi um and what the benefit with this is that, from this schema file, you're able to automatically generate client-side code or any sort of like uh glue code to be able to interact with these contracts.

C

So say um you have a front-end that wants to interact with the contract, like you, don't actually have to redefine the interface or you know understand what the serialization format is.

C

You can just call a function same with if you have anything if you're, interacting with a contract through scripts or if you're out interacting through a contract through a cross-contract call, this stuff will just be all done for you, um the the the context for for why why we're building this is to obviously like streamline developer um like productivity and make sure that, like velocity, is as quick as possible, without with like removing as many bugs as possible, if you like, the abi is very similar to um and the reason that we're choosing the abi name is like a tentative name.

C

Right now, which can change um is the familiarity with ethereum, like ethereum? Has the ethereum api which people might be familiar with, which allows a lot of developer, tooling and functionality to be built on top of it um if you've worked with other ecosystems like this, this name might also be referred to as an idl like an interface description language um there. It's basically the same thing like the concept is all very similar where you basically have some code and you're generating some human readable schema, and then people can do with with that schema.

C

However, they, like, um hopefully that provides as much context I might. I might pause for a second just to uh api- is an acronym from one so yeah it. The the acronym that abi stands for is application binary interface. um That acronym is, is like, I guess, kind of referred to in in the classical sense of like what you would. It describes how you interact with a binary. In this case, the binary like notion is a little bit uh a little bit yeah.

C

It's it's a little bit opinionated, whether or not you consider like a wasn't binary or wasn't blob uh a binary, but essentially it is basically defining how you interact with that wasm smart contract.

C

um Before we used to refer to this as like an aci, because we you know, we we're assuming this would be more intuitive or like a more accurate name of saying, like it's an application contract interface, um but it's basically defining the interface of of this contract, uh but yeah abi right now is kind of the name that we're going with just for familiarity and- and it I mean depends who you ask, might be technically correct, because the was you know it is a was binary at the end of the day um and basically yeah the the serialization format will is in binary as well.

C

um So hopefully that answers that question um and yeah. If there's no other questions we'll just we'll just continue on with the with the next slide, um so yeah. If this is kind of unclear, I do want to make sure that I I explain a tangible example or like show how this could actually be used in practice.

C

So the general flow is that someone would generate an abi from from a near sdk rs contract. So basically you compile the contract and it'll emit this. This json file, like this uh api dot, json file or whatever, whatever it is named uh in the future or whatever someone decides to name it um and the what you do with this file is it's connected to say some front time at compile time.

C

So uh it'll generate some near api.js uh code, which will basically make it so that you can just like call a javascript function and it'll it'll do all this stuff underneath where it basically create the create the uh create the actual rpc call that's being sent to a node and actually like send that with any sort of um other other context. That's required um and, as I mentioned before, the the main reasons for this is just to remove any sort of bugs with like the incorrect interface.

A

C

Having to like duplicate the interface both on the javascript side and on the and on the rust side, um but yeah, the key here is just like developer productivity, like making sure that developers have as much velocity.

C

Building with this is is kind of the name of the game and and somewhat of a theme within like all of apis like this is the primary goal is just to make it easier for developers to just do what they want without having to know domain specific knowledge or um having to like learn specific concepts that aren't relevant to the application, they're, actually just building, um and some other kind of examples of how this can be used from once the api is generated. Is you say you have another contract that interacts with this?

C

You can automatically generate the cross-contract code generation, so, basically removing the need to like redefine an interface which can be error-prone because, as the as you're changing the contract interface, it doesn't automatically uh connect with this other contract. That might be interacting with it um or say you just want a typed interface to use with an end-to-end test like say: you're, writing workspaces tests, or you have some other workflow to you, know spin up a node and send transactions to um making sure that all the types are already connected with your testing.

C

Workflow um just makes it so much easier to just like develop quickly and not have to worry about thinking about what this interface actually looks like and how you serialize certain things correctly. um Yeah we can. We can. We can move on to the next slide, um so yeah to to kind of to to show what this might look like at a very like early stages, um we're still very much in like the proof of concept phase and in like very early stages.

C

So none of what you're looking at right now is is by any means final, and if you see anything or if you have any suggestions of what they should look like, please feel free to uh share with in the chat or you know after share within discord or github, or anything like that. But um essentially what what this example is?

C

Showing is just um like this, and this attribute matcher macro, where it's just annotating near abi, and basically everything within it will be, will be picked up by the macro and basically used to be able to generate what you see on the right, which is the uh which is actually like the abi json file, um so just to give kind of an overview like. Obviously, all the code within is gonna stay the same as it was before, um and we're trying to make this as minimal as possible.

C

So this obviously might change, um but what the actual format that gets emitted just to give an idea of what this might look like. Is uh it it's? You know we're gonna have an api schema version so that you know you these things are versions so that you like, if things change within the actual schema format, um it doesn't just like automatically break.

C

You know whatever tool you're using um it might have other other metadata about the contract, so for in this case, it's just like the name of the actual uh contract- that's being built in this case just api, because that was the example, um the version which might be relevant to developers, understanding like which version of the contract they're actually interacting with um and then other metadata. That's picked up from from uh from the actual like cargo tamil file that actually built the the contract.

C

So in this case, like maybe authors or something else like that, um if there's any other metadata that you're interested in please like share or like share with anyone else, and it would be great to understand what other what other information would be useful for for people to include in this file, um but the kind of to to walk through some of the some of the other details about it is um you're going to have a list of functions. In this case.

C

It's just going to be extremely simple, because it's just going to have the one function called add it's going to give some context about it like it. Isn't uh it isn't a view contract? It is an initialization function and it's just got this one parameter. That's that's. You know named value, that's json, and it also returns this uh u64 as well, so um and then it and then it just basically represents the type that's below it and the bottom has root schema for any more like complicated types which isn't used in this case.

C

um But hopefully this gives like a rough idea of what this might look like um in practice of like going from the actual rust code that you're already writing to some human readable schema and then from there. It goes on to the to the use cases that I talked about before um yeah. You can move.

A

C

To the next slide, if you want to um so.

A

C

Is kind of where, where we are kind of turn, turn it to the to turn it to you guys and basically ask like this is still very early stages like what are uh what are your thoughts and feedback on this, because we very much want to design a tool, that's very easy for people to use.

C

So the main questions that I, that you know we have for uh for you guys is basically is api, an intuitive name for this tool like we're using something based on familiarity, but is there something else that would be more clear what this is doing? um What functionality information would you like to see in the schema like, as I mentioned like, if you do need other information that uh would be crucial to your use case, specifically we'd love to hear about it, um and also like what format?

C

Would you like to see this data um right now? We're leveraging some like json schema functionality and basically using this outputting, this api in json format, just because it is the most familiar most readable, like most common, commonly used uh commonly used format for a schema, but then also, how do you envision using this tool like what is what is the actual developer experience that you go through that that you would want to go through to make sure that all your tools are connected? So you're not doing things?

C

You know not doing redundant work at any point and making sure things are as streamlined as possible. Obviously we're trying to cut down on as many steps as possible, but if you have any thoughts of how you'd like to be using this um yeah we'd love to hear that and yeah.

A

Just as I mentioned just share.

C

Within within discord or github, um and now that I've kind of get shared some of the context on that I might just pause and if anyone has any questions I know joshua came off. Did you have something.

A

Yeah there's, I just saw one question um that was from will the near abi macro affect the contracts. Final wasm code, um like increasing the size.

C

Yeah not at all, um okay, so to to give an idea of how this how this works. This is just something um that's uh compiled outside of outside of wasm, so it's something that's an attribute. That's used outside of wasm and essentially what's being called, is uh when the api is being generated. It's calling a function, that's only available when it's not compiled to wasm 32, so this in no way will have any effect over the the actual like output of the wasm code um in the future.

C

Some people might want to include an api within um within the extra metadata within uh the actual wasm file itself, so that that information that abi is stored on chain, but there's no requirement that this is the case by default. This is just like a tool for uh convenience and developer velocity. um It does not affect the the final log of code in any way.

A

Cool awesome. um I also um curious. Is this uh the the example you showed was in rust? Is this um just for the rust sdk or will it be available for the javascript sdk? um What once it's uh like? A standalone for wasm uh and or assembly script as well.

C

Yeah, there's there's no there's no blockers why this couldn't be done in any other language. um Obviously, that's on uh that's on our minds of of having this uh be supported with with other sdks.

C

um Just obviously, until we have like a very solid schema format, I think what we're primarily focusing on is the russ one, but if anyone in the community want to build it for any sdk that they wanted to build, there's no there's nothing specific to what we're doing uh that is limiting from the community from coming in and building uh whatever you know, abi generation from. However, they build their contract right now, but this is kind of the most common use case and kind of the most standard.

C

So that's what we're focusing on until until it's stable does that answer that question.

A

Yeah yeah totally um one comment: uh they do. They don't find abi to be very intuitive. They were always curious kind of what it was. um They also sorry um was asking uh or would love to see, an automatic uh creation um uh for like a jpg uh javascript apis for the contract so like they could do like an import get status. Slash gets a set status from interface.js.

C

Yeah- and this is this- is exactly what we're planning on doing it. It's it's, not it's not exactly the import get status and set status. It's more. uh It's more of just like you'll, have an object that you can use and call functions on that, um but that also could could be.

C

It could be a pattern to go with where it's just like individual functions again like this, the how this actually looks, um we will um we will kind of like get more feedback and provide alternatives for people if they want to have different, like patterns for how they actually import and use this and create the code generation.

C

But what you mentioned here is is very much what um kind of already exists within a proof of concept form, but will be kind of made more easily available to people in in the in the future, um but yeah the abi naming obviously naming is the most difficult problem. uh We're trying like that's the abi is kind of what is naturally like what the name is falling into, but if it but yeah, if anyone has any suggestions, we would we'd absolutely love to hear it.

A

Naming is the hardest part of uh development right.

C

Absolutely at least for me, I don't know about you guys.

A

Cool um yeah, I don't see any other questions but again feel free to continue to post them in the q. A portion at the bottom or you know, drop them in chat. Like some of you have been doing, but yeah. We would be more than happy to answer any questions and then yeah.

A

Perhaps um what I could do is create a poll um or a survey form using like google forms from from your last slide, and then also attach it to this video when we upload it and maybe email it out to uh some of our community members to kind of get some more uh feedback uh on some of these items that you proposed, but uh again.

C

And one other thing I I should have mentioned with previously about the api is: is the person who is leading all of this? His name is daniar, so if you ever have any thoughts or any suggestions that you want to talk about, he would definitely be the point of contact for um if you have any feedback for that. But if you share it in.

A

Our discord or anything.

C

Like that, I'm sure anyone will be able to um to be able to to make that connection. um But yeah daniel has been been leading this uh this avi effort, um but yeah.

B

If you, if there's no other questions.

C

Or anything like that, we can, we can kind of move on to touching the other. The other parts of this.

A

C

Like this is this is less for impact or less, uh you know feedback from from the community, but it just just to let everyone know kind of what the what the other initiatives we're working on. These are kind of just like smaller points, but um we do definitely have a focus on like clearing some of the some of the technical debt we have in in some of our rus client, libraries or workspaces.

C

So um the initiative that miraculous has been working on on our team has been like extracting a lot of the primitives from your core for a more stable rust, client interface um and that's gonna, make like the actual, like rust, the json, rpc client, uh more stable and then also um just make it a lot like these types.

C

A lot easier uh make these types uh be a lot easier to be used um and then uh the other initiative that we we've kind of been working on has been uh improving error handling within workspaces rs, which has been led by uh fong on our team, who, I think has been on a previous call, um but essentially just improving the air handling within workspaces rs, because that has been somewhat of a pain point of like errors, not being so easy to be used um being able to like diagnose uh certain issues that that you run into while testing.

C

um So those are kind of the other initiatives that are happening um but yeah definitely less opinionated than the api stuff. So I won't go too much in detail about these.

C

That's pretty much it. You want to move to the next slide and.

B

Yeah awesome, that's that's! That's it from us for so this is a bit of a quicker uh tools, update um and yeah. Just reiterating what we've already said a million times. We genuinely love the feedback, so javascript sdk avi any of the other projects that the developer tools team takes care of anything related to near really we'll, try and write it to the right person, the right group, but uh um you can find us on discord or just jump into any of those github discussions.

B

So um I think that's it from us today um unless there's any other questions, we'll do the obligatory, eight-second awkward wait.

A

Totally um there was one question earlier um that I wanted to get to um from aminu. He was asking about near api uh py, um so the python api asking if there's gonna, be um when the documentation be ready. You know, is there any more insight on that tool? I'm not sure if that's actually something uh that this team is working on, or maybe it's like a project of another person from the collective um but yeah there.

A

There's that question and then also last night, when I was um on discord, someone was uh asking me to help them troubleshoot near ap. I go and I was like oh I um well, they were there, yeah they're, sending me syntax, I'm like oh, where is this from and I was searching and get them like. Oh it's from this. This thing uh that was created.

A

I think, like a year ago, by again one of our collective members, uh probably like a side project or something but wasn't uh actively being supported, uh but yeah, do you guys have any um comments on uh these types of projects.

C

Yeah, so the the python one was was was not within our team. I think it was. I think it was bowden that was uh that was uh working on this.

A

C

Actually sure, if I, if I can remember correctly but um yeah, I I'm not quite sure the status of that. um I don't believe it's something that uh maybe it is something that's being actively worked on. I don't know, do you, do you guys have any uh intuition about that? I yeah.

A

Just looking at the the code it looks like 11 days ago, there was something uh pushed to it and uh yeah actually looks like ilya and uh sandy and uh yeah a bunch of people from from our collective, where we're working on it but yeah. I don't think this is like a tooling team um project. That's at least owned by them more like a probably a community project by some of the the core contributors, but uh but yeah definitely feel free to to interact with them and engage with them in their respective repositories.

A

I'm sure they would love. I love the help and support, but yeah. It's not an official um thing, a product that the the tooling team from pagoda is working on.

C

Yeah- and the same goes with the with the go on that you mentioned yeah, it's it's not it's not directly, uh something that that this team is working on, but it's yeah. I wasn't even really aware that that was uh that was even going on. So that's cool.

A

um And one other question- uh and I got this at consensus: people were asking about new year. Api js and they're really excited about the javascript um uh sdk, uh but they were like hey. What's going on your api js, that's been uh kind of uh lagging a little bit, uh I'm not sure. If the two is it the tooling team owning uh this library um or do we do we have any kind of updates on uh that tool and, um what's gonna, be the future of it.

B

Yeah, so um yeah so loud and clear, um the api.js needs a little bit of love. um uh The the wallet team actually owns that um josh under under patrick. um So um what I would, what I would stress is just keep pushing hard on those issues. I know that some of them have gotten a little bit stale um but uh um uh yeah, not the direct purview of of the tools team of our team, uh but um I think the pain. The pain point is very real.

B

So just acknowledging that and thanking everyone for bearing with us but uh um yeah. I would encourage everyone to create issues and try and help uh resolve those so that uh in the interim, until we can get full dedicated resources to um to give the attention it deserves.

A

Awesome thanks for thanks for addressing that yeah. I know um a few of our repos. We have some stale issues and some stale pr's um we're really trying our best to uh to get a handle on those and uh to dedicate yeah there's so much to do, and not enough engineers on our team.

B

A

Than people right exactly, we have way more tools than people, um so yeah, please bear with us as we're uh trying to go from this startup to scale up uh position and um yeah, we'll we'll do our best to try to uh engage and uh get these pr's and issues resolved in a timely fashion.

B

Just to like just be like super clear with an ask to the community on that is, is we we can shift priority of what we work on based on feedback. We get from the community so like what we work on is a direct reflection of what the community needs.

B

So um it's really hard for us to make decisions on what tools to prioritize specifically without having direct feedback from the community and there's a lot of ways to give that by being active in the github discussion, showing up to these community sessions or being as annoying as messaging us directly four times a day on on specific stuff.

B

Like I very much welcome that so um help us determine priorities, so we can make sure to work on uh work on the most high value value things for our community um and just keep keep pushing us really hard there. So we can make sure to deliver the most value.

A

Yeah, plus one on that cool um yeah, we'll we'll give it one like a minute just uh yeah any any questions, total ama session uh right now, if you have any questions uh for the tooling team, uh anybody on the call, hey siri. I know you joined um a little bit ago. We didn't, we didn't, have a formal hello.

A

um Sorry, he did a lot of work on the javascript sdk that we just got shipped yeah super super stoked still still working on it still working. Yes, of course,.

C

A

Yeah or if anyone just has any.

C

Questions about what's possible with abi. We definitely have the time and ability to chat about that. So yeah, don't don't uh feel free to uh to send a message and chat in this last minute, but yeah.

A

Yeah absolutely.

A

Awkward silence yeah, it's like it's like you want to give that the the time for people to ask questions uh and, and also I feel, really awkward, just sitting here, silently being recorded. Blasting.

B

Should we just start counting back from ten.

A

um Oh, we got we have something coming in. I would here love to hear more about an idea on how to use abi in the front end.

C

Yeah, so maybe this is even something I can touch on, because it would be a good point for feedback is um the two strategies that we were kind of identifying or the two paths that we could go for um generating javascript code from the abi is um is through um some run time, like so through, sometimes through some uh javascript runtime object, which is somewhat similar if you've used like web3.js like their contract interface, where, basically, you input the actual abi file as a parameter to a function and at runtime.

A

It'll it'll add on all.

C

The all the methods and functions that you can call with it, um this.

A

C

Better for javascript and like maybe you don't need, require the extra step to be able to like um generate some code, but it does come at a lot of like downsides as well, because then you don't have really the ability to generate like the typescript declaration files which make it a lot easier to use with uh with typescript with typescript files uh or like with typescript projects. You want to actually have like type inference on this stuff.

C

So generally, the path that we're going towards is is is not really like that, but something that's definitely less done, where um we're basically going to be generating javascript and typescript declarations for um from the actual api to be able to be interacted with. uh And that way you just you're able to like see the interface more clearly and you don't have to like debug things at runtime. um It just like kind of makes that whole process more streamlined and less error-prone, um but yeah.

A

If anyone does have.

C

You know opinions on what this interface should look like if you've used some some tool in the past and then like hey. I really like you know this interface, like maybe you've used like type chain or you've used like web3.js or or or, however, you've used um like an abi within any sort of tooling within ethereum or any other ecosystem um yeah. Please feel free to to share that like we're going in a direction that um we think has like the most possible functionality, um but yeah.

C

If anyone has any opinions on like what this workflow should look like or what this interface should look like if you've used a good one in the past.

A

C

More than we're more than open to hear it, I'm not sure when you said you want to hear more about the the javascript usage with an avi in the front end, um if that was what you were referring to, but um yeah.

C

Maybe I can also just get share also that from from this like code generation, you can also generate ui components from it and be able to like dynamically include ui or just like generate components based on that avi that make it that make it a lot simpler to um to develop on so like there's, there's tons of possibilities and people can build so much on top of this that unlocks so many different functionalities.

C

um So hopefully that sparks some sparks some ideas from people and yeah. Hopefully that answers some of the questions I was taking that vague question and just kind of running with it in different directions. So hopefully that was helpful.

A

Awesome think thanks austin yeah again any any any question. Ama total total total ask ask away if you have them uh give it another minute before we close early.

A

Likes the idea of generating an object on runtime.

C

Yeah, that's what currently exists within our like proof of concept, um so it's possible that we might support both um but there's obviously like more uh more interface bloat. If we do do that like it is better if things are more streamlined, um but there might be, you know some way of exposing this, so that if people did really want to use that yeah they'd be able to like it.

A

C

That that much overhead to support this, but it might just not be like officially supported um but yeah- definitely definitely very possible and uh is, is what is easily possible. Yeah.

C

Cool- I did repeat the question right before I started, giving that.

A

Yeah, I actually said the question before: okay.

C

Cool sometimes I do that where I just give an answer.

A

A

Totally cool well well, awesome! Well, thank you so much everyone uh for joining us this week on our tooling team update again, please feel free to give us some feedback. We'll be posting this on youtube. uh With links for feedback, we have a feedback, developer feedback channel in discord under engineering uh section, so please feel free to drop any feedback. You have there or you know directly in the repositories in the github discussions. Definitely uh yeah makes sense to have those discussions right in the repo directly but yeah.

A

Until then, uh we will see you next time next month um and uh yeah. I think that's pretty much it thanks again, austin and sergey for joining us. We'll see you next time take care thanks. Thanks.

C