Tools Community Call #7 - near/dev/hub

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

1. 0:05

   hi friends my name is lill and I am Dev contributor at near devhub I would like to welcome you to the seven tools Community call if you haven't attended one yet those are informal sessions where we share updates discuss and present tool Ling projects from the ecosystem if you want to get involved join our telegram Group which you can find in the description below uh or visit the tool Community page at near Dev hub.org you can see the recordings

2. 0:28

   of all previous sessions on devhub YouTube channel we have dedicated this session to uh JS stack and the JS tool Ling on here so we we're going to be talking on near API JS the JS SDK which recently got updated and in general what would be the future in JavaScript so um I would like to start uh off with Vlad who is going to present us little bit more insights uh about the agenda I just want to provide a bit of a

3. 0:59

   context it was passed to me we actually had a pretty long discussion in the recent weeks regarding the GS stack tooling with various teams in N system so I suggested ludell to use this time to actually align all of us uh on this matter so we can efficiently allocate resources and uh actually move forward uh as as efficient as possible uh um so today we'll cover this GS St specifically in the tooling ecosystem of near uh I promise we will have another

4. 1:39

   one for us later but today uh let's dive into and I want to just remind all of us that we have this lovely um Dev Hub page for the community tooling Community you can find other communities out there as well um and all the relevant GitHub Twitter uh telegram links right there without further Ado uh let's get into the agenda that I suggested in the chat um and that is the nearest DEC GS near

5. 2:14

   API GS and near wallet selector uh of and and we have plenty of stuff to discuss there um but let's um align all of us on the terminology first so near SDK GS is something is is a SDK that uh with as a community and uh initially pagota contributed a lot to to build the um nice framework uh to build uh apps or contracts in JavaScript for near um which is in in my opinion is very novel um in technicality it's uh not a rocket science but definitely requires a lot lot of very careful

6. 3:01

   crafting because we need we have on here basm run time so we can Bic compile any c code to it which we did with JavaScript one time as well uh anyway moving on that is the near apjs and this is our uh offchain SDK to interact with near blockchain outside of um the contract environment and the near wallet selector and that is something that we provide the users to uh to to the developers so they can provide to the users uh a choice to select any wallet they like um when

7. 3:41

   interacting with the D app web app of the de developer and we have plenty of ideas how to evolve each of those directions and today I will invite um lime chain team who maintained uh um near APS for the recent uh I guess year or so and pagot team who previously maintained it and authored it uh to provide their inputs and um ideas uh how to evolve it further um and they want to start with near SDK GS and by the way it was just

8. 4:21

   recently launched a 2.0 release um and just to illustrate how it looks like like when you build the apps um for the blockchain using near kgs this is the screenshot of the minimum so-called contract application with uh basically uh two methods and um Constructor initializer um and the first argument that I wanted to make is that we previously had the SD key for near assembly script

9. 5:01

   uh isdc to build uh contracts in assembly script if those of you were uh with us so long ago you may even remember but the idea is that the their uh API looked drastically different and uh this is something that I feel we may consider to and and share the feedback regarding the this style of writing the API for contracts uh which got inspired by rust uh SDK versus the assembly script um

10. 5:38

    does anyone have any opinions and while I'm waiting I can show you the assem script version just so we are patient by the way funny enough near AP GS still uh refers to the example in assem script um just as a reminder for or who didn't see it before assembly script looks similar to JavaScript but it's actually a different language uh with um more strict types and you cannot use regular

11. 6:17

    JavaScript packages um which was a a showstopper for many uh but syntax wise it's close to JavaScript and we made it I believe very simple to use and build the UPS because you basically uh export functions on the top level um and expect the parameters to pass in like this versus just a reminder the uh in in in this mode the current 2. 1.0 and 2.0 of Ja JavaScript is Decay this is a small difference but it's very not noticeable uh we need to build a class

12. 7:04

    and methods to the class does anyone want to speak um yeah actually uh Vlad can you give us like a quick note on like why we decided to move away from the assembly script SDK I believe it was that the language itself wasn't so actively developed or am I mistaken yeah ass script had a lot of Works uh with had a big bat on it but ultimately didn't uh um got a lot of traction and uh there used to be

13. 7:40

    some bugs in the compiler uh which made it not suitable for any um secure critical applications um because you never know how it will actually compile down to the web assembly code and other like the the tool was not there like the you need uh various libraries and most of the time people just would fall back to using R yeah I think that it's also worth noting that the ergonomics while like assembly script is uh inherently similar to JavaScript and typescript nowadays

14. 8:19

    like people like there is yet another layer of complexity that you need to learn like what is this super set of actually of going into assembly script so that's why people and like the ergonomics of just the ability to write uh smart contracts in JavaScript or typescript are like way better than yet like a small but uh yet another step of complexity of using the assembly script

15. 8:43

    and I see that the hit is with his hands the kit you want to talk yeah um I think the one of the other benefit of JavaScript is like uh there are 28 million JavaScript developer so so it's we should we cannot ignore not that uh my question is more about the not the syntactic level but like a do we still have to kind of a uh deploy together with quickjs or or is it compile to a

16. 9:16

    wasum and then we deploy wasum okay what what happened there well you cannot get away uh without having a some sort of a runtime because JavaScript is inheritant dynamic language um so you cannot so this was the design choice that assembly script did um they actually produce a very tiny um vasm files but that is because they actually can uh very strictly typed type what this i32 means

17. 9:48

    and there cannot be undefined or null or string here whereas in JavaScript um it just a syntax sugar as you can see there is no type annotation here but even though there is a typescript support in ndgs it still boils down to um transpiling to JavaScript which doesn't have a sense of proper strict types or like um yeah so we cannot just compile it to wasm and then uh that support like a a near uh uh wasum format and then de

18. 10:30

    yeah so the how the SD the JavaScript SD key works yes we use some uh runtime I believe it's written in C that we compile down to vasm and we side Lo the JavaScript code um next to it basically if like if we are looking at it at the high level and there were uh there were some exploration of different um uh run times out there quick GS Hermes Ander but it seems like um none of those

19. 11:10

    Alternatives actually were feasible um either depending on vasm GS proposal which is not a standard yet in vasm world that's why it's not part of the near core um I'm not following like I don't know what's what was the here cann't find any compile yeah so probably there was a lack of documentation or something like this um so that's a current state thank you Josh I remember you had some opinions regarding the assembly script maybe you can shed some light uh on why

20. 11:51

    we moved away from assembly script um in well that's I guess more or less clear but uh regarding the the syntax wise why did we move from script syntax to rust syntax and do you have any like knowledge memory of that um I don't remember I just remember like messing around with the assembly script and finding some very very primitive things uh that were wrong with it um where it didn't understand um certain

21. 12:23

    values were greater than or less than um and also as we were going through um um just yeah trying to get support for it it just yeah the the ecosystem itself um was only managed by like one or two individuals um and trying to get like some support for some things and and getting um yeah some features that we wanted to get done with it it just yeah the bandwidth was yeah assembly script twice it's it's clear like it's not no

22. 12:49

    no no go but for JavaScript we could have gone with two different syntaxes we we support this uh shinig gun suround the classes uh and Constructors and methods uh or going very simple like set value it's just like a standalone function um and there is no self there is no this it just like you you you you interact with the storage directly um Mike I also remember you were Prett

23. 13:21

    active at that the time where this text was still a thing do want to speak I see that um Elliot's dropping some questions in the message Chat uh Elliot would you like to speak up or shall I just read them for you yeah I can ask it quick it may be too big of a question and we can skip it but I'm just wondering how this compares to JS and Russ so like JavaScript embedded in R smart contract the JavaScript runtime versus this is a

24. 13:57

    smart contract written in JavaScript for yeah I believe the for for I I don't recall exactly the just um remember the the name of the project the because it looks like the same stack just like a different approach yeah so as you can see it's us it uses quick GS probably it compiled it into rust tooling um so it's a same runtime but it allows you to integrate in from inside the cont this one so my guess that it just allows it

25. 14:57

    to execute some um well it's okay it might be too deep to get into may be too deep or like it's it's definitely experimental right um and from from the naming I'm deducing that it's uh actually using the um the same run time so it's a bit oral to this kind of discussion but it definitely just allows you to basically call some JavaScript code from your R functions so you write your

26. 15:38

    functions using potential nearest DEC RS and then just execute JavaScript code so it it could potentially allow you to make uh Dynamic um logic inside your function qu I want to add one thing uh so I think almost two years ago uh i r run bunch of Workshop uh in ASF with uh near sdjs and most of the JavaScript developer like they understood easily the decor decorator part is easy for people who know a little bit of

27. 16:19

    JavaScript so I think the syntax was um Pleasant like a and rust and JavaScript it was easily like a you could port a rust code to JavaScript because syntax is so similar um so my experience was when I talked with people who are even just learning JavaScript they were able to kind of pick up the like a simple hello world or those kind of things which was really really great so I was really big believer of near jss DK I think Josh and other

28. 16:57

    people know like pushed about it I think if we can make it reasonable size um and uh have some production example I think there is a adoption will be bigger like they they actually tend to be smaller than rust contracts which yeah so that means like we just have to promote it like it's like you canot imagine like how easy it is to go to a like a hackathon or onboarding new people and then when you are really um um have experience

29. 17:35

    JavaScript developer most of the JavaScript developer nowadays knows rust or or like to run rust when they're a little bit experienced so we can use JavaScript SDK as a top of the funnel so like bringing a lot of people more like a boss component right so bring a lot of people let them build few things and then if they want to make something big transition them to rust so that will be my

30. 18:02

    recommendation yeah oh sorry I was just going to say for did you make um some did you guys make some updates to the jssd because I remember size being an issue when we first launched the the first version of like the smart contracts with JavaScript were you know one for one comparison to Russ were a lot larger um that was a big issue but has something changed did you guys do some just magically now it's smaller I don't know like I I personally didn't

31. 18:26

    address it but it like at some point it actually got smaller because I was testing it was like 300 kilobytes uh hello world and it would only grow like in Rust you can easily introduce beefy dependency and it would um go from 300 kilobytes to 500 kilobytes uh in JavaScript contracts what I saw uh usually it doesn't actually pull in too much of the uh blood and the main cost is actually the runtime and then

32. 19:01

    JavaScript uh code is just text which is much okay is is it maybe like like the initial JavaScript is a little bit larger but then once you start adding more data to it it starts to like one becomes maybe maybe we pulled in some like to Big dependency on JavaScript side but I was testing with okay some counter example and uh with board sterilization it it worked pretty uh good cool I I am actually interested of

33. 19:33

    like because this topic of the contract size has been coming around like pretty much every time that we have JavaScript uh been talking about and I was wondering of like the the difference could be twice but since like Mia provides like this Lock Storage that the users can get back essentially when they clear the contract and in it State like why would it be that big of an effort of like trying to make the contract size

34. 19:58

    like that much smaller so like what are like the the what is the biggest benefit of that since like all this locked for storage amount is able to be retrieved for like production value I mean it's a matter of couple of near I assume so like what would it be maybe I can give a little bit of an an input first of all on on on package size and why the wasm is as big as it is uh basically if you uh compile and you do kind of a decompilation of it you can

35. 20:30

    see that about 25% of it is variable storage uh now the sad part is I cannot see exactly which variables are stored right but if you have an array buffer that is set to zero in the beginning uh that takes a fixed fixed space and that's reserved space uh during the compilation Pro process so that will always be in the package so there might be something uh that has either been initialized and this is actually something worth looking at right um if you think about the the the effort that

36. 21:05

    it takes uh I mean spending a couple of weeks on just looking at the dependencies right going from uh from the SDK to the API to the Builder as well right the SE Builder and just looking at that chain um I think a couple of weeks at least just to get an idea of you know why it happens what's going on taking a look at the variable change es and maybe you know uh reducing because um like I said the initial hello world is about 400 kilobytes give or

37. 21:36

    take out of which 100 uh 990 something almost 100 are some memory storage right just uh some memory register that's being stored it's not usually it's not doing anything it's not being accessed it just exists there so this might be one of the reason Dynamic allocation there exact exactly uh one yeah um and like another thing that I also had in mind is that when we speaking for JavaScript in production uh

38. 22:07

    a part of the contract size like uh what are like the guarantees or safety precautions that people are not like overflowing not sending money to the wrong thing they're not making operations with combining strings and numbers to receive objects and stuff like can anyone provide some like input of that in how is that like uh addressed into the smart contracts in JavaScript I can but I saw that the he had a Reen

39. 22:34

    hand so no I just wanted to say like a one of the challenge about the size and everything is kind of a there are not a lot of information so I think if we can do like a few Benchmark like a few standard contracts so like a hello world nft step token so then if we can show the memory and execution time so let's say side by side that will allow us to even if we want to improve or if we want to convince others so like a that's one

40. 23:06

    of the really important thing we can do um yeah and then performance like we should also not just the storage also the performance is very important so there's a nice folder here I muted no can you hear me okay uh they there is a benchmark for here which has a pretty extensive uh comparison even if I remember correctly with yeah with rust um side and the the ultimate summary so it was Prett extensive uh you can read it uh completely but the

41. 23:50

    details uh well the the sizes wise well probably I I misremembered something but well it's still on par with rust contract I would say it's not like bizarre um too big um but there was also a performance wise and I guess unless you do a number crunching uh the most of the uh costs come from the host functions call so when you dualize caliz data or like reading from Storage right into storage that is most exp expensive and

42. 24:25

    JavaScript and rust doing exactly the same thing and basically um doesn't have too much of a different there that's how I remember it but maybe you want to review it in depth sometimes I even saw some of the benchmarks given better results look this guy I guess uh GS promise bch uh well well uh let's not touch this one right now uh the uh on the different topic about the like secur

43. 24:59

    and the object plus number plus train what's going to happen with JavaScript World well we never know and the um the the reality that it's it's not what we need to solve in my opinion uh there are plenty of applications that do not need this uh level of scrutiny and that's what we want to actually uh um uh like send a message to the to to the community that not every app needs this um security aspect they you can you can

44. 25:35

    you can still you still have the history on chain uh you can always just recover it uh with indexing and reapply the data if necessary uh and applications like devhub for example uh could have been built in JavaScript uh there is no nothing really like too critical it's in my opinion is still much more convenient to build bigger apps in Rust because just compile time checks are helping a lot uh

45. 26:09

    but when you're building during the hackathon um rust might not be the best choice and you just want to get things done very quickly and I think that is a lot of value for um new system for the developers to choose between when they when the Tool is right for the thing they want to accomplish thank you yeah um so if um like more people are interested into talking into the SDK and stuff just join the tools Community chat uh in telegram group actually and uh yeah and um

46. 26:47

    provide some more input and like part discussions uh thanks everyone for for your input uh I believe next on the agenda was the API JS if I'm correct y we have two people from lime chain as well that uh they would be uh talking about it uh but Vlad if you want to provide some context on it as well you can go just a little bit just one second one one uh slide basically just to remind everybody uh here what we're talking about so this is the uh API how

47. 27:27

    well let's let's probably open some uh code right here so it's in cookbook and that's how we can see that near APS could be used so you import or require the uh certain apis available to you then you can use them by instantiating the uh new connection to the RPC then you initiated this like account and then you can uh prepare a transaction and send the transaction and call view functions on the on the Chain using these apis uh this code is

48. 28:06

    designed to be run either in the browser or on your no GS environment um so it's not executed on chain and uh the the cornerstones here are usually key management and uh the API itself understanding uh when you need to send a transaction and or when you want to have a view function and how to manage all of that and why heck we need to call a view function on account which is totally nonsense but it's a

49. 28:39

    different story and the yeah I want to um so and and in my opinion this API um has proved to be converson uh to many of us and a lot of folks on this call actually acquired a lot of experience um um maintaining building improving and building upon this near P so I will stop here and let uh you guys speak and suggest the ways forward and I want to hear both lime chain who previously

50. 29:14

    maintain it and pakota folks uh who or and currently maintaining and Paka folks because they have uh also a lot of context here okay we have uh Michael from pagod Mike can you yeah hey guys uh so for anyone who doesn't for anyone who doesn't know me uh I'm an engineering manager at pagota and then I have it here as well Andy and pavle who are senior Engineers on the team and then Josh is our product guy who you guys all probably already know um so yeah we have uh some bandwidth on

51. 29:49

    our team at pigot and an opportunity to refocus some of our efforts towards you know really impactful stuff like developer tooling and near API JS especially you know Vlad calling out uh some of the pains that have been experienced there and I can speak firsthand to that because last week I was like okay let me take a step back and kind of try this and see where things are at you know looking at

52. 30:12

    someone who's like coming in fresh looking at the documentation trying to get up and running and it was painful uh to be honest I I ran into uh some things out of the gate where it was just kind of like a mismatch of like documentation overly cumbersome apis um and just kind of like an incomplete picture of how to really get started uh so that being said uh we have Andy who has some deep history with near API JS who um worked on the modularization of some of the

53. 30:42

    pieces there uh and uh we've been talking about some improvements that can be made just to the near API JS uh core interface layer uh before we get to the point of really how do we like make this nice to expose to different Frameworks and things like that um so that being said I've kind of set the stage I'm gonna have Andy talk a little bit more on specifics of some ideas that he's had on improvements I'd like to see um and

54. 31:09

    Andy i' had asked that first thing you touch on is kind of an overview of where we stand with like the near API JS package versus the near JS packages um because I think the document the documentation misses kind of calling out the existence of both of these things and some people might not be aware thanks Michael um yeah so I'm Andy um intimately familiar with with some of the near PS and like Michael was saying I was in charge of decomposing that whole package into its um constituent

55. 31:38

    kind of pieces really to just uh Define the relationships between um the different concepts and Primitives in there and uh uh so you know that was I think intended to be the first part of a work of kind of cleaning this up making it more accessible um but ultimately the first step of decomposition and a big refactor like that is just kind of keeping things as they are so leaving

56. 32:00

    your API JS up and so that people could continue to access it um but the intention I think was always that that people would start going to the nears packages um to more directly pull in the um the dependencies that they need and so as we were kind of talking about this and you know what are the shortcomings and and what are the things that we're not um exposing to to users uh to

57. 32:23

    developers um you know I think really what we're missing we we have this Gap here where we're not showing you you know what does the composition look like you know how do I take these pieces together count and key store and things and put it together in such a way that you can use it and I I think um what we really saw that was missing was just a way to directly kind of map some functionality in your APS to an

58. 32:47

    intention to a behavior um that you want to see so a good example that that Michael gave um and part of his struggle was just how do I get account balance you know something something really straightforward um and you know like at a minimum what do you need to know or you need to know what network you're on and what account you want to know and that's that's essentially it um what you have to do now is I think pull in two packages probably take you four or five lines um

59. 33:11

    to write this whole thing and if you don't do it in the right way it's going to break because the account expects a signer and why do I need to sign if I just want to look at some RPC data um so I think csome is is a really nice way to say it uh Vlad um but yeah it's it's it's kind of an awkward um sticking point and I I think it's a uh just unnecessarily difficult um to interact with a lot of these things this

60. 33:35

    lowlevel um or and even high level Concepts um you know Josh pointed out we have the cookbooks right why why can't you just you know if the cookbook is called get account balance why isn't there just a function called get account balance that I could then import that I could pass the configuration to um and so I think we've identified you know just this this big bu um that we'd like to address and show up and you know

61. 34:00

    having gone through and and detang disentangled a lot of these relationships um I I sort of I'm coming from a place of knowing where a lot of the baggage is and how we can move forward and present a more refined interface without bringing in this baggage so that other people when they want to extend this they're not having to say oh I can't make this a different package because I can't decouple it from the accounts class or something like

62. 34:24

    that's what we want to get away from because that is hard there's not an obvious way to do it um and it doesn't need to be hard so that's my that's my pit yeah what uh what they can say from providing support to the like uh to the channels um yeah uh to the public channels developers are hitting like a hard time of actually getting this information and like all the cumbersome steps that they

63. 34:49

    have to set up their connection and like even a lot of times come comes up of like that they need to set up a wallet in order to introduce a contract that want to interact from their front end so like people are hitting like a lot of these issues so like what you just spoke for like hits very like the very nail that people are also like trying to escape from so I would say I would

64. 35:12

    assume everyone on this call would agree on that so yeah I'm sure people have seen it in varying context and and capacities like why is this so difficult and I see a question from V maybe or was answer that no I want to hear the side from the um lime chain team what they how how is their experience and what uh they had in mind because they they were also thinking through this problem yeah uh thanks uh so uh most of you guys don't know me uh I'm Marin from lime lime chain uh basically I'm a

65. 35:51

    Solutions architect uh within uh lime chain uh I have pav over here so we also have a pav uh there are two of them currently uh so I I I fully appreciate Andy's points here I completely understand and and really uh also from a Solutions architecture perspective it is a nightmare to even uh go from chain to chain let alone you know within the same ecosystem let alone go for something

66. 36:21

    that abstracts uh um something that most uh most developers or most blockchain developers are familiar with right into something that is completely unknown um so my team our team basically has been uh kind of thinking of uh a few things uh on how to make things easier right uh documentation Improvement is definitely something that needs to be done um two things that need to happen over here are um first of all uh separating documentation from front end

67. 36:55

    and backend right I think um a lot of focus has been put on uh kind of a uh frontend and JS contract perspective um but we also need to understand that there are backend systems that can run uh contract things right they can call contract functions and get information so uh one of the attempts is to actually improve kind of the sample set of projects that uh kind of show this within that cookbook within

68. 37:26

    these situations a uh right um additionally right the other point is from uh from how we see it right if you look at an API you have your set of core libraries and then you have your wrappers around these core functions um on one side and I think uh I think Andy also mentioned this improving some of that core functionality is extremely important um but also um uh we need to take a look at at at the potential users

69. 37:59

    and the potential adopters here some of them might be uh new and fresh uh familiar to uh a very limited subset of knowledge for example they might just be knowledgeable of react framework uh like react right uh and we're not talking about react from uh six years ago we're talking about react 18 and that's all they know uh so they will be limited and are limited to Concepts such as hooks uh but they don't understand Primitives the same way we do from from back in the day

70. 38:35

    uh with that means is uh creating a set of uh wrappers around the apis to uh function with these hooks right so or to function as hooks um within react uh just to kind of improve uh some of that adoption right and these ones can be um again uh as mentioned before they can can be some of the basic things uh using a connector or uh using an account manager right to see what your address is whether you're connected or

71. 39:06

    disconnected um things such as you know get my balance without having those complications uh I I think we're we're we're really uh we're really going within the same frame of thought here um how can we make some of the most basic things basic and keep that right uh BAS contract interaction uh and then you have the other side which can be contract logic which can be a lot more complicated um maybe separating these and working on a separation of these two

72. 39:39

    is is key over here uh so this is actually something that uh that our team has kind of been thinking about and uh focusing on improving uh so increasing the hooks increasing the examples uh for for for the backend and um and then and there are other quality of life improvements that come in over here right so um we can have uh for example uh multi-axis keys for example that you know uh would allow

73. 40:10

    us to do things in different areas without having to uh continuously sign uh or uh the complete opposite where we have very very fine control with limited access keys and key pairs uh which could uh which could do these things as well um I mean in terms of of the API or the JS API this is kind of where we were thinking of focusing and this might bring a lot of value to developers as as

74. 40:40

    they uh either uh come on board because this is kind of what I think is the focus mostly on newcomers uh older Generations or people who have been uh early adopters of nearer they've seen the pain and they're experiencing the quality life improvements now the question is how do you bring on board uh new people and that is by making the journey easier uh to adopt by using Concepts and Primitives that are very familiar to

75. 41:13

    most JS developers thanks for sharing that uh question to whoever I I I wonder if we need to separate the uh wallet selector uh right now but I think that it it definitely contributes to this problem space uh with the key management um and uh just access of those potential uh use cases of signing in without actually creating a new uh access key and and and and blows like that um I

76. 41:56

    wonder like how how separation could look like um within these projects does anybody uh put a thought into it um have any ideas maybe it's too specific though like I maybe just to to provide a bit more context about what I'm talking about the the wallet selector is this separate project uh World selector which is the collection of packages uh which are integration into different Wallets

77. 42:34

    on near system which you can as a developer of a web application uh as you can see long list you basically Plug and Play into your I assume uh react or angular uh application and you get this nice dialogue when you click on login thing and you can provide your users with basically choice of which uh wallet they want to use to uh log in or sign transactions and uh uh this is just

78. 43:13

    a yeah basically it's it's it's your choice which Wills to support and then you initialize it and somehow it's done um but there are definitely a lot underneath um Marin yeah uh so my team uh our team has basically uh kind of uh taken an interest deep interest into the wallet because uh there are there's definitely room for improvement over there uh I think two primary things that are uh

79. 43:51

    very kind of important within this are um the ability to kind of a a default wallet that you want to use right just have that pre-selected for you uh and remembered uh so that uh you know you can you can have that throughout your let's say your user uh life cycle rather than session I don't want to use the word session because that has a very specific meaning uh but uh up until the moment where you choose not to use this wallet have that

80. 44:23

    be your default have that be your uh your custom uh Choice um and the second option here is the ability to pin them actually you know uh have a limited Set uh of of of of wallets that you choose from um what I would do here is I'd do kind of something where you have a priority list and uh you know you've kind of set your priority list and the first one is the default uh and then uh if you choose to you can kind of Dr uh just just to

81. 45:03

    bring more context here I think in the context of near AP pigs uh near the VA selector should be viewed as as a key management solution sort of um so it's your like key store that is not local storage but actually the your your your API uh for signing a transaction uh and there are plenty of problems out there that I see is when you want to interact with several contracts using

82. 45:35

    several limited access Keys manage it managed for you or you want potentially to use a vol selector to uh sign transactions for to prepare them for da for example so instead of sending them as is you actually wrap them into add proposal and submit it to the Dow contract so there there are like use cases like that which not necessarily they well they they require some UI changes on the wall but the discussion I wanted to to rise here is more like

83. 46:09

    integration between lowlevel near API GS um tool tool set and the the API that W Sor May provide to nears Michael um yeah so I I definitely don't want to like cut off this conversation but just like being cognizant of time like being able to continue a little bit more into specifics of the near API JS improvements and then maybe later on that could kind of surface into like how it affects walet selector right um so just kind of back to the near API JS

84. 46:50

    improvements um I'm somewhat raising my hand on Andy's behalf uh because there were kind of two things that we wanted to have time to touch on while we're here one was uh we talked a little bit earlier about uh I wanted to give him a chance to respond to your question of like does it make sense to do a rewrite uh versus a restructuring and then also uh we have a little bit of like a proposed uh interface uh that we could

85. 47:13

    take a look at as like a starting point for refining the conversation about what improvements like this could look like um because that'll really be like a you know Community effort to decide to decide what this thing could look like um so Andy do you mind touching on or responding to uh you know whether this should be a rewrite or not sure um yeah I don't I don't necessarily think a rewrite is required here um but what I think we should be

86. 47:38

    doing is sort of uh advocating for better patterns you know replacing things that are maybe have outlived their usefulness or um are like account the account class in particular is one um that I think we should maybe be more judicious in how you use it so if we're offering an alternative offering a better way we can kind of let these other um less desirable or deprecated paths kind of die out without the need for for rewriting them so we're just presenting kind of new interfaces and letting the old ones die off seeing what

87. 48:09

    works um some things definitely need to be Rewritten or need an alternative to be duplicated somewhere else um but I don't think we're that dire of straits um and then yeah you wanted to talk about the um the proposed client package yeah yeah I think if we uh take a quick tour through this this is something that um Andy had worked on while back of you know what could a better version of this look like just to actually you know put some code in front

88. 48:40

    of people and start you know making this tangible of like what this could be yeah sorry sorry for jumping in uh just before we continue I would like to say that usually we run these calls for about an hour but if if you run over whoever can stay I be more than happy to stay for a little longer because this is a big topic and this is a very uh like a topic that is going to make uh like a

89. 49:05

    lot of impact so if you guys have a little bit more time to stay I would be happy to do so so yeah let's go thank you um yeah so so this is uh some old code that I had worked on kind of during the refactor because you know a lot of these frustrations I felt as well kind of going through and trying to decompose this um so this is something I just kind of dusted off by no means is is a strongly opinionated thing um but just

90. 49:31

    kind of seeing the ways that that things could be uh could be simplified sorry I just dropped the link in the in the comment there if you haven't seen it um but this is just kind of an overview of how you might you know interact with something like this and the important part is being able to surface those high level um kind of functionality like create account you know something like that so we can also during the recording it would be easier to follow oh yeah

91. 49:55

    that's a little helpful ask the same but I uh my browser wants to restart before I share so I cannot if I can grab the right one this look um yeah so this is uh just where I'm talking about in here so being able to surface these things like create account at a high level um is is really going to to let us uh compose this you know directory of method that could then be composed in the idea is you know these would be just core functions you'd

92. 50:31

    be able to use in any context but then if you you know want to encapsulate these within a hook you want to you know couple this to application life cycle then it just becomes kind of a trivial thing like just wrapping it inside of that life cycle being aware of you know what what kind of state things you need to be able to sign transactions or fetch things um so uh yeah I mean and really what we're I think trying to get away from is needing to import multiple things based

93. 51:02

    on the use case that you're trying to do like viewing versus signing transactions um I think there's a difference between two or three Imports you need if you're trying to sign a transaction um whereas these these things could be a little bit more fluid and composable uh and so you see I kind of have this this this kind of janky fluid API where you're just sort of uh annotating what is it that you want you know if I I'm going to be

94. 51:25

    signing so I need to initialize a key store and I would tell it some parameters about where that key store is um you know a ledger is going to need a much different initialization than a uh than an un encrypted file system um store uh and I I've I kind of took the chance in here to just uh quickly rewrite some of the cookbook examples and just show you what what they could look like

95. 51:49

    instead if you're not having to pull in all of these package and and initialize all of these things um so definitely just just kind of a start to get uh the conversation going um you know how how can we just surface these high level uh again functions that map to really specific behaviors on chain yeah I think especially just seeing like the just initializing a client and using it to

96. 52:12

    call immediately into like view calls and uh exposing like a get balance function and things like that um is I mean that that covers such a large percentage of the use cases that uh people want out of near a PS that they're being held back from completing just because it requires a little bit more upfront yeah yeah and a lot of these apis you'd have to be tapping into um are really I mean you're you're maybe interested in 5% of what it's offering and who knows how much of it is actually relevant um but it's kind of on you to

97. 52:45

    dig through that so being having a a package a layer where we can expose these um these highle things and and let you build off of them um as is really a big missing yeah what we have um so this is just a draft PR I have out again it's just some kind of code that I had dusted off so not a lot of strong opinions in here other than let's expose these things in such a way they can be used in different contexts extended and built

98. 53:21

    upon uh I have to say that I haven't seen this uh uh before uh create um like Foundation I would say to actually make it simpler uh though definitely I think there will be more polishing required and thinking through like a better structure here and there that I um see right now but I definitely see a lot of improvement uh in the exploring this direction and it would it's it's framework agnostic and I agree

99. 53:54

    with the with OT in the chat that uh not every JavaScript developer is react developer and uh the hooks should be definitely be there but there's a separate package uh and uh should be based on intuitive core that can be reused everywhere and we definitely need somebody with a lot of experience uh building the apps and knowing ins and out of uh uh various patterns in your e system um multiple keys name the

100. 54:27

     accounts uh interaction with the like with the contracts and what you can expect from them in terms of uh return value meta transactions how they needs to be signed where to send uh all those need details uh change the API drastically um as like where it begins where it ends uh I had to and this is also from my personal experience rewriting uh rustal Li three times um I don't know if you knew about it but we

101. 55:01

     actually only landed into this latest design from the third attempt um and it's totally fine leave the but the the challenges are there and we need to address them and I love that you guys uh have put a lot of thought into it and actually have the capacity now to potentially contribute uh all this knowledge as well um yeah I think I think there's like a a good opportunity for collaboration here where you know

102. 55:33

     we've been really working a lot on or in the past you know did a lot of work trying to like modularize it and had some of these ideas got taken off of off course and now as we're you know interviewing developers and they're really saying hey what I really liked about boss and some of these other things was the easy way to interact with near and I really want like simpler apis um is you know and we're kind of both lime Tain and ourselves and others are

103. 55:57

     coming on this oh it would be cool if we had like a wagm on on near um but we needing needing to start with first that core layer like uh Andy and Michael are kind of suggesting um would it be good to like you know go to kind of taking the lead on creating this client Library um that then opens it up for any kind of framework to build on top of and that like lime chain or anybody else could come in and create a react hooks package

104. 56:20

     or a um you know view package or whatever you know um whatever you want to build on top of that much like you know yeah rainbow wallet connector or rainbow wallet kit built on top of wagney right like you could also do the same thing with our wallet selector um and and could you know a lot of these other packages and libraries be built on top of um this core infrastructure but I'm wondering if that might be um uh a

105. 56:44

     more efficient way to get something uh to the community quicker um by having us that have a little bit more knowledge in in the near API JS to kind of set this foundation and then working with lime chain and other community contributors to uh build layers on top of I think definitely there is room for collaboration uh across the teams and also if I may drop some ideas right here uh just for the recording uh I think uh

106. 57:14

     uh near SI arrest could be also pretty nice inspiration if we consider just every single command is like dot notation so near do account do uh list Keys dot uh or like a function call with where you provide the uh account ID and then you also specify like which network you want to call it and uh like if you want to call it at the block height or like the latest and then basically your uh JavaScript

107. 57:46

     command could look like something like this but just just throw ideas uh yeah um Pavo panov also says in the chat improving the core functionality will give us the ability to encapsulate the sense and logic in modular and reusable manner this will enable us to warp these core functionalities into react hooks for react applications or utilize them for vgs with composition API an angular

108. 58:17

     with it services and independency injections so yeah like having it modular and like not necessarily going into one direction of just supporting hooks and like being as well building blocks at a lower level which I think that as a foundation would be definitely way better than having it Incorporated straight into the API and another question that we had a little bit earlier that I want if anyone can

109. 58:41

     provide some context on uh this was from J and uh it is that it is saying in your API JS you uh like overse some old primitive code JSF uh JS VM ID not sure what this is exactly is it related to the JavaScript contract somehow and I remember that it's used to be something to do with inclave if I'm not mistaken and it hasn't been used for a while so like can any one of you provide some more context of as to why this was existing and like

110. 59:15

     where it's it's deprecated you don't need to look into it it was a old way of setting up the JavaScript um um runtime so before you you would instead of having independent contract with the VM and your JavaScript code it was a single uh contract with JavaScript Enclave uh where the VM was there and we would deploy at more different contracts from different users into this one B massive

111. 59:46

     account and this if I remember correctly this is what it refers to um the part is not I think that it's still required up until recently when I checked it so this is something we should get rid of so yeah yeah that that entire um connect pattern is is problematic I think because it it makes you think you need a lot more things than you actually do and the jsbm ID is a really great example of that where like

112. 1:00:19

     has yeah amazing so if there are any questions or thoughts on near APS then let let us hear them and if not we can Circle back to what was supposed to come after on the agenda that was the wallet selector so uh yeah uh if anyone like wants to bring in like what are your thoughts like more of what was already covered and like what would be the probable Way Forward of making stuff easier for developers I would love to hear

113. 1:00:51

     it um well uh unfortunately I have to jump to another call and also so we had the discussion in the chat that we may want to potentially invite the wallet teams to also discuss the vet selector at a um bigger room basically so I suggest we save this topic for later um but we need what I encourage us to Think Through the key management underneath because that is out a bit of outside of the wallet selector um uh wallets experience uh

114. 1:01:25

     with they care about on the Vol selector side is the support needed for like sign message sign transaction um and the ways how to integrate with uh all the apps out there um yeah all right so if there is nothing otherwise to set in the chat um then I would like to thank you all for joining us today um so if you want to get in touch just join the to to community group in telegram uh you can see the QR on your screen we have the devhub newsletter definitely sign in and

115. 1:02:12

     subscribe for those because this is basically a rundown weekly of all things around the ecosystem like Dev related uh on Thursday we have the de Hub live which my colleague uh Joe is leading it's also very interesting and if you want to hear more like uh and like get to know when are we having these calls just check out the dehub community calender uh once again those sessions are held usually once per month but I

116. 1:02:39

     think that we are starting getting to the point where we should run them a little bit more uh often if you want to get involved suggest um discussion topics or want to present your work just let us know get in touch and yeah see you soon thank you