Tools Community Call #17 - near/dev/hub

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

1. 0:05

   Hello once again friends. I'm Ludmil and I'm de contributor at near DeHub. I would like to welcome you to the tools community call. Those are informal sessions where we share updates, discuss and present touring projects from the ecosystem. If you want to get involved, join and reach out in our telegram group. Today I'm joined by uh close to all the Vlads in the Vladiverse uh which is delight delightful to be

2. 0:29

   here and uh of course welcome to uh everyone who joins we are very happy to have you around. Uh today we are going to be sharing a little bit more about what's going on with uh the Python tooling and the pying SDK um as well as some ongoing work in um alphas or different SDKs and like exploring the space of what how far can we push uh the entire ecosystem in this contract building tool. So welcome everyone. uh

3. 1:02

   if you want to give like last minute or blitz presentations or want to uh get highlighted on this call just drop a message into the comments uh into the chat so I can see it and I can bring you up. So I would like to start the call with uh Vlad who is not only representing NearDev uh he's longtime contributor to the near ecosystem but also presents the infrastructure committee and also recently comes up with very not so easy actually quests for developers which uh got quite a few

4. 1:34

   people struggling in order to win some awesome prizes but more about this on the newsletter. So Vlad if you yeah uh happy to be here. Thanks uh for having me and it's great to see all the familiar faces and uh I hope we will have uh even more people watching it uh at their own pace uh in the recording online. Um there are a lot of news that uh we completed over the last months. I I I I think it's uh it's been very uh packed with events.

5. 2:14

   Uh there was East Denver and everyone tried to push uh all the tech before the East Denver event and there was u Python SDK uh for contract development or near which wasn't targeting East Denver at all. I never expected it to land so quickly. uh from the um previous experience and how many challenges we had in the beginning. Uh but uh today uh I will show the the current state of things. Unfortunately, Ricky uh couldn't join because that would be great because

6. 2:56

   he he was the main contributor to the high level SDK. uh and uh another Vlad could not join who was the um one who built the lower level uh um integration and but we fortunately have July um prototype uh proof of concept that we can actually have the smart contract in Python. uh on the high level just for you to understand this the complexity of this work uh it the near runtime near

7. 3:37

   protocol allows you to build applications in any languages uh that can basically be compiled down to vasom assembly uh rust is a very natural choice there's a lot of uh great community and tooling around uh for uh vasom support C is natural uh zig is natural because they are low-level languages that uh you can have full control over what uh uh you compile and what you execute.

8. 4:08

   Um but many other assembly script was designed for assembly web assembly. Uh so it was also one of the original first options to go with uh for um near but uh those are fairly uh niche and uh fairly complex in in the on the scale of other languages obviously uh and uh the modern languages especially. Uh so the uh the natural direction that near development uh for smart contract um like developer

9. 4:44

   experience went with JavaScript uh uh SDK and when the just a brief of history uh since not many of you may have been around uh back then in New York system we were actually discussing to do the Python ZK almost at the same time. So it was like uh two years ago or so. Uh and the only reason we didn't go with that is like oh we we we thought that let's well we we had limited capacity and we want to give a try with one language and

10. 5:19

    uh um we kind of randomly picked several options. Uh so for for JavaScript uh we picked uh quickJS and for Python I think we didn't find the good solution back then uh to um to to be able to compile it down to uh web assembly. Uh oh and why we are even talking about quickgs and some solution for Python is that we for dynamic languages we need to have some runtime that would be compiled to vasom and

11. 6:03

    then load the uh dynamic scripts in JavaScript or Python as a bundle inside that web assembly all together. And that is how the uh smart contract with dynamic language uh looks like in u in in in near. So basically uh we compile C implementation of quick g of javascript runtime and we bundle the whole javascript uh user application into single javascript file. We have a very small um bridge uh that is taking

12. 6:43

    the function calls from the host when the contract is executed and pass it along to the uh actual JavaScript function to be executed in case of JavaScript SDK and um we went with that it was fineish but still didn't fly as we expected and that effort was uh um recorded is not a huge success even though we I still believe that it's uh still a good tool to have especially in contrast to assembly script. So senders script was a trick to many developers

13. 7:21

    into believing that um oh well it's it looks like JavaScript but it actually is not and you cannot use the node modules you only can use node modules for assembles script which is non-existent basically there are just a few packages available out there and um so in that aspect javascript is much bigger success because you can use any almost any um JavaScript uh package out there. But personally,

14. 7:59

    I do not like back ends in JavaScript myself and I I think uh it's a general preference in developer community. Um for backends, people still use like either more legacy systems and more like um framework like like Java and C providing the uh like some foundations for building the back ends or rapid for prototyping they would go with Python or Ruben rails uh solution and that is I

15. 8:45

    think what is contributing to the adoption of JavaScript SDK being not very popular. Uh with Python though I believe that we have a lot of uh chances to actually uh go really wild and I already see a lot of interest in the community. Uh people are excited to play around with it. Uh even in its current state um which is uh looks very nice but still lacking some of the high level uh features like cross contracts uh uh promises API and um some of the collections and etc etc.

16. 9:27

    Um and yeah and uh maybe good idea would be just for the sake of recording to show how it looks like at this moment in time. Uh so this is uh not my project. Uh this is totally built by Ricky. uh and uh I wish he would present it here over the call but I really cannot afford you guys the community to miss out and do not see the beauty that is already there. So it's a very nice documentation here. The there is a low kind of

17. 10:13

    simple API that you can use which is based on just uh functions. uh in contrast to Rust SDK for example which is uh the SDK itself is uh recommending you to use uh strct and implection for methods of that and expose it that way. Python ZK at this moment in time does not require you to have any uh default state uh for your contract.

18. 10:48

    you can manage it yourself. You just use the uh storage API to set and get values. Uh so this uh but at the same time you can go and build the the way this the structure that is uh uh more familiar to those who are building contracts in rust for near and you just re like reexpose them reexpert them as top level functions and they are then detected properly. So there are some um host APIs provided to you

19. 11:25

    through context uh predecessor county for example. Uh there is nice uh storage API that has um byte um interfaces for storing bytes uh strings and also uh JSON. So that automatically uh just uh serializes and deserializes when you use set JSON get JSON. Very nice wrappers. I really love the the simplicity of it like this.

20. 11:56

    Um and uh it's super simple to get started. You especially if you use UV which is a modern uh tooling for Python these days. So you do UV in it. Uh you have your project folder. You add the SDK pi dependency. you potentially copy some example from from above into your contract and you just uh use uvx uh to execute the near c is the another uh package here that bundles the um micro python as a runtime with your user code

21. 12:35

    that you implement into a single vasom and then you can use a standard near CLI to deploy a contract. um and interact with it and uh what not. So this is uh on the high level. Um there are still rough edges here and there. The I think this is uh still this um cross contract APIs are still not flushed out. And there is um some other challenges on the way but I've managed to build uh already like five contracts um in the course of last

22. 13:17

    uh maybe like two three weeks um running the quests for you guys and uh uh also testing providing the feedback to the to Vlad and uh Ricky about usability and bugs. So it's uh evolving extremely rapidly but I really want to hear uh some of the thoughts uh from Vladimmer who actually built the initial uh proof of concept as I said for that powers this near C um CLI these days which is uh basically

23. 13:59

    bundling I think it's here microython with um um um hot fixes and patches on top of it uh and uh exposing the um host functions of near runtime into it. maybe you can uh talk through it and how how was it and uh yeah I I've I've looked through the um uh both uh parts like the high level and the lowle part and uh I'm especially amazed how uh uh well structured the high level part is that all the use cases and uh it even has

24. 14:43

    some I think CI uh setup uh for it repo uh auto tests and uh whatn not. Um uh but also for um um uh for the near C part um I see that uh quite a lot of work was done uh exposing functions um through uh mod. Well, yeah through through basically extending MicroPython uh to support those host functions from near runtime. Um so I think it's uh uh great effort uh and uh really glad to see that um everything's working on the protocol side as well.

25. 15:40

    Um yeah, overall quite surprised uh as as as Vlad is uh to see this uh so early. Nice. Yeah. And uh what do do you think so something that I haven't dig into uh too deep um but maybe you have the perspective uh we I initially started this exploration through rust python uh rust python is implementation of python language in in rust and it has a lot of uh claims specifically around uh web assembly support uh and that is why I was uh actually using it as my first

26. 16:24

    choice and I would love to see that succeed there. Uh but uh reality was that it was very bulky and the ultimate uh uh even hello world that I was trying to build was initial size like 8 megabytes. I managed to slim it down down down to four and a half megabytes and then uh while I was doing like I I didn't have time and while I was uh contemplating how to squeeze out maybe one more megabyte because the the

27. 16:57

    previous uh the limit uh of the vasom file of the transaction size in near protocol was around 4.5 megabytes. the the the the protocol has changed the limits down to 1.5 megabyte. Uh so it was uh even less uh realistic to get uh Ras Python down uh slim down to that size. But Vlad said uh recently that he believed that C Python the the the full original implementation could be potentially slimmed down uh to uh to

28. 17:33

    our requirements. Um do you know like do you think it is feasible from your perspective? Do you have any guesses? Um I I think if you cut uh quite a lot of uh stuff from it uh manually uh like all the uh modules that pack packages that are not used and whatnot. Um, it might be possible though I uh to be honest I haven't looked much into C Python um size. Um so uh it it looks like um

29. 18:22

    uh yeah it looks like if it if it's possible that that's quite a lot of uh work compared to adopting micro Python which which is built for being compact uh from the opinion. I I I would be happy to hear uh like the concrete ideas why uh he thinks that that that's possible. And I I think he he his um his take is that the overall so I actually there is this project I think called vit

30. 19:06

    uh that allows you to build uh python apps into uh web assembly using like cython and it bundles so it's designed kind of to for uh front-end development in python uh if I understood the initial in intent of the authors but the very quick hello world lead me into 28 mgabyte file uh was site uh so basic way above the uh threshold uh but Vlad said that uh they didn't strip down like many of the packages that are

31. 19:52

    totally irrelevant for contract development like uh um HTTP library uh and uh even cryptography some places um the cryptography may be a bit more relevant than the other parts um he says that maybe it's doable so we'll see then Yeah. So you can uh strip stuff. Uh that's um um one way to reduce size. But um on uh Micro Python side of things, they also reimplemented existing um stuff in in C

32. 20:39

    um using well using less space I hope than in C Python. uh because it's uh the goal of the project is kind of uh targeting embedded systems. Um so yeah but at the same time uh I actually when I was uh putting this challenge uh in the community for building the Python SDK there was another person who actually took the approach from Ras Python uh and he had initially pretty good results. he managed to slim it down by like removing

33. 21:22

    basically the full std uh from Ras Python uh down to 1.3 megabytes. So it's on the border line and still couldn't get the it executed in the in the runtime there. There are actually some something that we will probably talk about later today with another VL on the call is the challenges uh with the like getting basm file is not enough. You need the features and various uh uh need details uh about the your expectations of your basom. You cannot expect that

34. 21:57

    there is a host function to that is like that is provided by lip for example. you don't have uh many of those symbols you and you also have some features of the vasom runtime vasom specification that are uh evolving and that are still not supported in near core uh like bulk memory and uh some that I don't remember and this is the challenge we had with python uh with with ras python

35. 22:30

    um but yeah well Um yeah and the why I was talking about it that that person had the previous experience with uh Rust Python uh in a different environment and he said that basically he's now strongly considering to switching to microython or CPython implementation which is like okay maybe then we are one step ahead of the curve than uh if someone already didn't like try to explore for that path and didn't like um R Python that much. Um the

36. 23:09

    claims were that it's uh not fully uh compatible with uh CPython implementation. Uh which we also kind of hit with MicroPython, but I think it's still more mature being a longer time project. Cool. I think that's all for the PP spy and contract SDK. Uh are there any questions? What's what's your experience? Maybe someone wants to share their uh ideas, hopes. Yeah, personally personally when uh first of all once

37. 23:50

    again amazing work uh from Ricky on the high level and also from Vat on the lower level uh of implementing that and the repo looks already like amazing and I just shared earlier on like when I saw the overview of it I was like oh we can like I did not expect to everything to happen that fast and yes indeed after looking a little bit more to it then you hit those challenges that uh things are not uh not uh yet implemented but it

38. 24:21

    looks very it looks very promising and I definitely see it as a something that u uh people would be using as if you can like if you remember just a couple of uh issue like what was it two months back or three months back I bet that if we get the SDK we will see more Python contracts than R contracts I'm still on this bet and looking at this also SDK that we're going to to have. I I bet that this is where we're going. So to me

39. 24:52

    and uh I've already seen like some people within the public chats of like asking about it and the general feedback of uh what we have seen is been like very positive. So yeah, um it would be awesome to get or maybe we can make like intermittent call so so we can get uh Ricky to to present a little bit because he also like did quite a few uh um other uh contributions. He worked on like different implementations of Borch as well and I already see like some

40. 25:28

    JavaScript developers already like trying to make use of it instead of the original implementation. Um so yeah the general feedback is is amazing. So looking forward to see uh like where does this it takes it and how long it's going to take us there because I seriously did not believe that this would happen like this fast. And Vlad I I asked you like when we presented on the um on the

41. 25:57

    challenge the open call for the this experiment with Python that I was like how long do you think it would take? And you were also like yeah not quite sure. So like did you expect to to to to happen like that fast to reach? Not at all. Like to be honest on on my trajectory uh by this time we would only have maybe the the low-level implementation. So Vlado also pulled out out of nowhere actually like I've been working with two other contributors uh trying to um attack it from the

42. 26:33

    microython or rust python angle. And then one day uh Vlad just messaged me over the weekend I guess like it's done. I was like what is done and I had I I couldn't believe myself so I had to go and check and it was actually working. and deployed it to test net. Uh, and it was like no way.

43. 26:57

    It was amazing. But it also well it it's been I want to uh still send kudos to Veemer because I think uh that original proof of concept really sped up the like direction where the where you need to look into in order to get it up and running. uh and uh he initially contributed it like mid last year, right? So we it's it's not something that we built just in uh in the past two months. It's been there for kind of a year with on and off. Um me

44. 27:37

    trying to find the contributors, some contributors trying it out, failing it. Um and um and finally we found uh a very good match actually with Vlad focusing on the low-level um foundation for the um just integrating it with with the runtime and uh Ricky is uh like he he told me that he would never touch that part but once the bridge is like like there is a bridge and it's all in Python world. He he can do everything else. He he he he's

45. 28:16

    happy to to work with with us uh um blindness and not knowing what that C and symbol meandling even means. He's he's he's just happy with the user space kind of. Yeah. Amazing. I think like in general general the the the initial breakthrough of things it's like very the hard part but like once we tend to when once we see that things are possible and they could be like pursued then we this is where we see like a little more rapid development. So the

46. 28:50

    initial steps are like usually they're always like the the hard steps in order to lead off like more people actually considering the effort because uh uh this is a very big effort. It's not something that you just say hey I'm going to do this weekend. So yeah amazing and just into the chat I see that Sasha is going to publish understanding the new SDK for Python already. So Sasha, I saw that you actually you had quite a few releases on like new material or on learning club.

47. 29:25

    Do you just want to give a quick shout out about it? Uh it's like the basically with by the way happy to meet new faces. If somebody does not know me, I'm Sasha uh founder whatever of learn club and with that I it's not even pivoting right like with that I still uh disturbing our life uh like on daily basis right like this is what we are uh we are pushing learn club so we we are we are trying to to revise the existing learning materials and that new relevant ones and

48. 30:04

    the and we figured out like after dealing with with AI for learning for a while, we figured out that the the model itself does not uh uh does not much matter you know like garbage in garbage out and this is what we are focusing on preparing the uh machine learning friendly content for the bigger model and we using one of the part six trees for our private rug and and so far so good like if you go to learn club website

49. 30:42

    uh it's uh and and try learning it already gives like more or less relevant uh uh answers for the near protocol near ecosystem uh projects we do not touch much of development stuff like I'm I'm not like an expert in development and you we'll get uh I think we'll get back to that with near doc team and near death and other assisting contributors but like the this thing gives me a little bit of optimism right so like we we can learn together with the I and I does need our

50. 31:23

    feedback and uh yeah and let's see we so basically the bottom line is like feing AI with legit relevant and information nowadays is almost as much as important as it bringing it to users. So this is the point like and and the and this is like a very very very fast uh fast changing environment. So yeah and like of course I'm using I for reading most of our articles nowadays but I still reviewing them myself and ask other people to review uh and see.

51. 32:01

    Yeah. So let's see if the like we don't care who going to be using uh uh Python uh for building contracts on people or robots right or both most likely both so let's let's provide both both parties with relevant information and easy to use tools and see this is exactly this yeah you could like even like like few months ago I was desperate like like like we we are done, right? Like like but no, like we

52. 32:34

    there is still a a chance that we can cooperate together with robots, you know, and do not go like directly into the matrix, whatever they call matrix cells, you know, like when when you just have illusions and get some uh some kind of food and stuff, right? But this is not real life, right? I hope we will figure out how to continue real life and uh and and live together with robots.

53. 33:00

    Yeah, robots. I I love you. Just for the record, don't get me wrong. Good point. Uh yeah, by the uh like on a previous note uh of um expecting to see more contract in Python, I I have to say that I really uh fear that to like I'm hopeful and at the same time fearful of that to happen. Uh I still want Russ to win, but realistically I I see why R why Python could be a very good uh option to uh explore the space to uh let people to

54. 33:39

    rapidly prototype their ideas. Um and I want to highlight that not every contract has to be uh 100% secure and be exceptional in terms of the um you know maintenance and stuff like this. Uh and I pro I think I proved that with uh five quests that I built so far like five contracts and uh three of them are kind of quests uh that were holding uh from 50 to 3,000 near on the contract side and uh

55. 34:19

    basically controlling that uh funding and so far nobody cracked it. So I would say like well you can build a fairly secure contracts um and if they are small the smaller number of lines of code the the the less bugs are in there um in general just as a statistics uh show showing us and with uh Python you can be very expressive and it would be really short and small uh in size and if we would build just many of small uh

56. 34:57

    contracts in Python that could be much more beneficial than building one beefy uh monster uh contracts like we do for example for splittnic dowo which has to be complex uh for sure it has to be written in rust in my opinion but for other contracts out there like for quests or some other smaller like interesting models that people will uh play around um that's totally uh ledger to pick Python or Go or C#. So this is a

57. 35:33

    good segue uh to invite Vlad to also talk about the uh challenges he had with uh uh building Go and uh and success success and with the status of Go SDK and C# SDK. Thanks for introduction. Uh hello everyone. Uh I'm very happy to see you guys and talk about near Go SDK and C# SDK. And first of all I will start from the uh I think from C# uh and I will talk not a lot because I am not finished it yet because I have problem with type of web assembly file which I

58. 36:13

    will upload to the blockchain in order to execute all these methods on the smart contract and uh one of the reason why it's not completed because of unsupported feature of web assembly standards And now I'm think about to add a new target uh build inside experimental uh compiler of net and uh I think uh I can bring SDK which will be comparable with speeds and size like Rust but written on the C. Of course, it will be not 100% C with all these reflections and other

59. 36:55

    features, but uh it will be the same syntaxes and also uh libraries will be supported. So I think I will I will have the results in next months maybe two months I can bring this SDK also uh to some alpha version and um that's all about C# SDK it's also open source but not complete uh and go uh I so happy that uh I find uh tiny go it's a compiler which can compile go to the web assembly and for

60. 37:36

    example if uh we will take C I have challengers for uh six seven months 8 months I try very uh uh I will I have so much challenges and uh I think about maybe I will try another language and what say that go it can be as a choice for us because a lot of developers love go. So I I think about it and I just found this teeny go and I have my first smart contract very easily in few minutes. I already upload

61. 38:16

    it call the first function and understand that I can bring uh go language to the new ecosystem. So after that I show everything to the V and I start to develop and now uh I have uh EA version and everything works. I have integration tests for each uh system methods. Um I still have some problems uh with mock system. I need to improve it and uh of course add collections at near smart contract standards in order to simplify development. But in general uh for now

62. 38:55

    we can easily create uh smart contracts on go and test it and deploy it. Um also uh I working on Redmi and because it's my first experience with writing SDK for for smart contracts uh I have a lot of interview with other developers with junior middle seniors and I already have a lot of things to work with my documentation and readmi. I want to make it super easy for beginners who just want to try uh to write some smart

63. 39:29

    contract and uh uh and that all uh for the persons who already know go know about blockchain system know about near I don't have any big challenges to them in order to write their smart contracts uh and Even with unit testing you can create your own mo your your own mock.

64. 39:56

    So uh it's not a problem to test it at all. Um yes there are some few problems with tiny go compiler uh and I will try to solve it and help and contribute to this repository. Uh but it will be in in the future. For now uh I also create the CLI in order to build it more easily.

65. 40:21

    uh but I also need to work uh on this CLI because this CLI work under work with near CLI and tinigo. So I need to handle all these commands and outputs and format it in the good way and provide easy CLI experience for new developers.

66. 40:42

    And uh I really want to tell a lot of Go developers to just try to use Go in order to write uh smart contracts on Go. And I want to like uh tell a lot of people who don't know about blockchain at all about it. And I think if we will have the right direction a lot of gold developers will will use it and we'll build for example some proof of concept for the first steps and in the future we will have build a big strong

67. 41:16

    community because go is very popular and uh uh good u community language language at all and Google supported and a lot of uh companies support it. So, and I'm so happy that I can easily uh uh it was uh very funny because I work with CU smart contracts a year and uh it was very fun to get the smart contracts on go in one hour and show love. Uh so I think it was mo the most funniest part of it. Well, you learned along the way while you were building for C like C#. Yes. Yes. I

68. 42:08

    wrote a lot a lot and I already understand how not near not works and it very improved me in terms of how blockchain system works, how this transaction works, how this uh code execution works and I was so I I happy really I happy that I choose this problem. I understand that is so hard but uh I have mindset of dreamer. I want dream and I think in the programming field everything is possible. uh we just need to push it and in in someday we can

69. 42:48

    go uh and see the results and see what we want because on the computer we can uh program easily all things because we have zero and once we can uh create SDKs for C, F, Java, Cotlin I think everything is possible but make it first it was so hard and I learned a lot really a lot a lot about compilers about LLVM about mono compilers it's net and C# topic more but uh I started to

70. 43:21

    understand how compilers work in depth and it it was fun for me. I wanted to ask uh uh because like go and see like very optimized languages. What are the file sizes that uh currently they produce like uh do we have like same similar issues that we have to uh that we are like finding well at the beginning with Python um like what are the file sizes of a compiled I think this is the file size right like 40 kilobytes 40 kilob yes okay does it

71. 43:55

    does it uh grow more with you you probably not have the like of did did you try to port bigger contract or adding some dependencies? Yes, of course. If we will add uh some dependencies, of course, build size will grow and um I find that in go ecosystem, we have developers which very love low-level things and they use only low-level libraries and if I will choose their libraries, uh the build size will not grow. So we but when I will choose the typical backend developer library

72. 44:36

    and include it in my smart contract we can have one megabyte 2 3 4 10 uh yes yes we need to choose the package and also I want to create some sea common to check package uh how much does it uh cost for our smart contract size and how much it will cost in years in order to store it on the blockchain.

73. 45:02

    Yeah, for us this status message um contract is fairly slim, but as soon as you start adding functions as parameters, which brings in more uh surilization and stuff, it rapidly goes to like something like um 300 400 kilobytes. It usually flattens at around uh 600 megabytes. I didn't see uh a single contract to be bigger than that except the cases when you include the other contract in your contract as a as a factory. So basically you embed bytes

74. 45:39

    of another contract inside and and and then you basically have roughly a megabyte uh contract which is still manageable. Um and that that was the motivation behind uh have like protocol team was looking for uh reducing the size of the transaction uh the allowed size of transaction from 4 megabytes and they were asking for like what is the um they actually didn't ask they they actually uh downloaded the whole uh like all the contracts on on near blockchain and say and check check

75. 46:20

    the sizes and they couldn't find anything more than uh 1.5 megabytes uh um that would be reasonable like except my experiments with Python that was not uh usable. Yeah, but that does that like if uh adding uh well higher level libraries that would make the SDK behave better for like or be more familiar to people using used to go. uh if this would bloat a lot of uh the file size or the compile tom does it make sense that uh we stick

76. 47:00

    to lower level implementations but make some kind of a intermediate interface over those so strictly I would say it depends like again up to 1.5 megabytes you you're good to go and I I would say that in most cases just like I would assume at least that similarly with Rust it would flatten out somewhere around maybe 1 megabyte so it's still reasonable uh but if you want to optimize even for Python for for Rust uh you look this feels like the hello

77. 47:34

    world small uh contract which uh is uh over 100 kilobytes but if you go and take Nest uh which is another um Rust SDK for near which is not very very popular but it uses no std for Rust uh and then the contracts are below kilobyte. So I have I have one of my contract uh that is 600 bytes or something like this uh um it it depends on the use case. Mhm.

78. 48:16

    Yeah. I believe to you Vlad because on go you also can create smart cons below smart contract below 1 kilobyte and uh if we talk about 40 kilobytes I include their JSON handling and uh there also can be some encoding also hex and it will be not go up to 50 kilobytes if we will be adding some standard libraries which other developer use. I see that uh uh this SDK can produce very low size smart

79. 48:55

    contracts. Yeah. But I I would argue that this becomes tedious to manage at least uh for for NSD without uh std you don't have strings. You don't have allocation of memory. You have to reallocate everything and then manipulate with the data within those uh allocation data sections. uh so it becomes uh used to properly read data into the uh allocated buffer uh check the like I couldn't afford obviously uh JSON parser so I had to manually holy

80. 49:32

    kindly assume that this is JSON data uh so a lot of uh assumptions uh over there but it is fun definitely and it's under one like 916 bytes uh wasn't which is cool. Yeah, maybe um such kind of a challenge would be interesting or using MSD or something like that. Uh but can you send me can you send me a link with uh your smart contract on RA which below 1 kilobyte?

81. 50:07

    Yeah. Yeah, let me send it here in chat. It's transfer near contract. It's actually a a hack for boss. So in boss you cannot send near natively. Uh so I created the contract and deployed it on near. So you can have a a function call to send near. So you attach near to function call and that it transferates further. So it has some utility. This is not just a random use. Yeah. And for those of you watching on YouTube, uh all of the links that we have mentioned

82. 50:42

    before are being put up into the chat and you will find them in down in the description down below uh together with uh the tools community uh contacts. We have a group on Telegram uh which brings us all together. So every once a month we do these calls. Um do we want to um cover anything else? something that we would like to discuss on or otherwise we can wrap it up and Sasha. Amazing.

83. 51:14

    Yeah. Amazing. Yeah. Uh uh uh I I want to check in regardless the wallet selector and uh JF because like the uh yeah you know time flies right? Everything goes very very fast. I have very good updates there. Yesterday infrastructure committee had the meeting. We had the RFPs waiting for like proposals from different teams in near system. Um taking over wallet selector fast near fast not fast near fast remains there. fast o uh uh one

84. 51:52

    click connect uh and uh the winners were selected uh and uh there uh there are two uh teams that will be funded to make to to to evolve and uh support wallet selector those are hot team and lucid team uh hot will be building it from scratch basically they have a very solid technical proposal and Lucid team team will be building it from the angle of a product. They will be maintaining the current implementation and uh potentially adopting the hot implementation

85. 52:32

    uh and uh provide it as u more like a solution rather than just a open source project. uh figure out it yourself, you know. Um and for one click connect and uh uh first off uh uh persist team will take it over that is team behind near mobile. So uh I'm very hopeful to see um those teams rushing into fixing the our challenges. uh they had very solid amazing proposals and uh I'm very excited to see that uh we are finding

86. 53:14

    the teams they are um going to bring bring the value their expertise hot team is um now nowadays have experience building wallets for web mobile telegram web extensions so I'm pretty sure they will be able to figure out all the uh challenges how to make the vault selector working for all the all types of wallets out there uh with minimum maintenance burden that we currently have. But as as as Lumil just posted in the chat, I see that uh uh indeed there

87. 53:52

    was a wallet selector uh version 9 uh.0 released uh I guess yesterday um which is also very uh exciting times uh for um all the devs that the evolution has been happening there. So it was maintained by near dev team until we have this uh uh proper team to take it over. Um so oh uh it's RC. Okay. Well, I I've heard other rumors. Yeah. Well, uh yeah.

88. 54:30

    Yeah, it's uh the pull request is uh has been opened and like it's uh for public for anyone to test uh what is what is happening because uh it seems like a big update. Uh and I wanted to ask uh we mentioned uh the wallet selector fast oneclick connect but do we have selected the winner for near APIs?

89. 54:55

    uh we do not have the RFP for near APIs and uh I have the context there. So the so those three services they they are more like services after all. So they are part of infrastructure community near API GS is part of the dev hub scope. Uh so all the proposals if you have any should please shout out there and ask for fun if you need or just go and build your own version.

90. 55:24

    um like if you don't need funding it's like there is no guards nobody is preventing you from contributing uh but I want to mention that there is some very relevant uh contribution to near core is happening right now that is the uh open API specification will be generated automatically from near core types. So we will basically have the full spec of JSON RPC uh in a form of open API uh specification that will allow us to use the tooling available

91. 55:57

    out there in the public to generate clients in any programming language going forward. So there will be a low-level client obviously that will only be aware of the types of the communication uh uh and in order to construct a transaction you would still need to uh have the types that you can then serialize to borch and then uh s then then hash and then sign and then uh combine that signature with

92. 56:28

    in the borch again and that would be the transaction. So it's it's going to be a separate effort and we have actually for omni bridge uh for omni omni something omniac system uh we have the uh packages to um construct transactions uh as part of MPC implementation. So yeah, we will basically combine those worlds together um and u hopefully um we will see type safe uh clients uh for JSP and then I outlined in the chat

93. 57:08

    that it would be great so this is a foundation and it would be great to have like uh high level APIs for example for react integration, angular integration, I don't know flatter But in the middle there is there should be um some generic functions just like I said for constructing transactions, signing it, public key management, whatever. And I think they those could be individual packages and then you there is would there would be just a

94. 57:38

    bundle of those with a uh use case driven uh design like near APIs did uh for following the near cli style. It's up to people then I would say to try experiment with different styles of APIs or different frameworks. We already know that web and uh like web browser environment is different from NodeJS environment. So I'm not 100% sure that it has to be uh has to have any overlap at all uh except

95. 58:17

    the low-level AP the the low-level client that will be automatically generated. So this is the the long piece of context I believe for for devs and and Python client will be probably also regenerated and we'll try to contribute the new version of Pioneer there. Yeah. Amazing. Um do we have any more questions or topics that we would like to cover?

96. 58:50

    Ne next next call you will see those teams right? Next call is what? You will see those teams here on the call. I hope so. It's absolutely no. Yeah to to bring them just uh just make just promise me you're not going to scare them away because those are very valuable teams and projects of course. So what are my friends? like they like my my nephews. I think that we are all friends

97. 59:20

    in me here. Uh otherwise I would have known. Anyway, so thanks everyone for being here. For those of you watching once again, if you want to present your work, suggest discussion topics or want to get involved, join our Telegram group. You can find the links to it down below. We have this call uh every second Tuesday of the month. So I hope to see you on the next one. Meanwhile, don't forget to sub subscribe to DevHub's newsletter where you can get weekly

98. 59:52

    updates of u what's happening around the ecosystem as lat mention just mentioned. Uh on Thursday we have the desktop live sessions where we started presenting with uh community challenges uh where you can not only win great prizes but also learn quite a lot of new things that um you didn't know that so far existed. Thank you very much for joining and see you on the next one.