 Hi and welcome everyone to the Hyperledger Cacti Maintainers meeting, please abide by the antitrust policy notice and the Hyperledger Code of Conduct, which you can find linked to in our original document. And with that said, recordings, we just discussed this, we'll try to figure it out with Rai, I'll volunteer to help out if he's been doing stuff manually, then I'll try to help him. But for now, Rama is recording. Yeah, by the way, Rama, did you hit record to local computer or record to cloud? No. Okay, you won't be able to find that video. Then you also have to contact Rai because of that, because only he has access to the recordings that we make on the Hyperledger account. Like it won't show up on your own zoom account if you log in and try to check it. Okay, I think it's safer though. I mean, I don't want to save it on my computer and then what would I do after that? Where would I upload it? To the Viki, the Confluence page. You just upload it as an attachment. Yeah, yeah, you just go edit and then you click here and then you click this insert files and images, then you say upload files, that's it. Okay, I'll remember that for the next time. You just have to get in touch with Rai for this one. Yeah, CI performance, just a really quick update on that. I assigned some work to Jackpreet to work on that dependency graph optimization so that the only one tests that are necessary. But now he's on leave. So I'll just pick up the slack there myself and I'll get something out this week because the CI is very, very slow. And then on to the quarterly update. Yeah, just before we go to quarterly update on the performance. Sandeep, did you change the reach allocation for the steps that you mentioned? Yeah. Okay, that's looking now. Yeah, it's looking now. So this is the quarterly update of the POC. So Takuma. So I already saw that. Sorry, sorry, stop. Before going to the quarterly update, we are still discussing number two CI performance. Yeah, I think that's Sandeep confirmed that it's the resource allocation that we made and the test working. So yeah, we can move to the quarterly update. So Takuma, we stopped creating Viki entries now. So the procedure right now is to submit a PR to the link that I just posted. That's the one repository now where all the activity happens. Anything to do with the hybrid TOC. So if you go there, go to the PRs and see some of the closed ones or even I think a couple of open ones, and you see how people are submitting it. So you just have to the same file that you uploaded on the Viki. You'll have to make a check in there and then the TOC members will review it. Okay, so this page. So is it right? So I posted chat window on the repository. So is it okay for me to upload the same work on this? Yeah, under project reports 2023, you have to create an entry called 2023 Q2 hyperledger tech tie. Okay, I will upload. Just like, yeah. Sorry for my detection, but I will. No problem. We reminding everyone when they're submitting a new report, some of them. Yeah, they try the old way and then we remind them or we tell them. Okay, thank you. So I had a I think couple of comments the last time we talked it was a while ago. Did you check them out? I don't remember. So, so that the report so that I approach for that your device version. Do you have any comment on the device device version? I think there was a comment or two after that, let me quickly checking the chat. Yeah, so, oh, okay, this is a bit dated. What are the only thing I just mentioned is that we probably should probably should list the mentorship project that got selected. Sorry, so, yeah, so please, so, please, definitely as to this for the TST Wiki, so, so, and then so I will approve, I will approve the copy of the this MD on the TLC. Okay, so you want me to edit the, edit the wiki and then you'll submit a PR. Okay, thank you. Thank you. I didn't have anything else. Thank you. Okay, so then I guess you can move to integration. I think the last time we were discussing exactly how to fashion the API function. There are two options right one we could create a new plugin and and work with that. But then I also wanted to investigate. He could update the cactus core API plugin itself. Still have to do my homework on that. But overall, I think I wanted to ask you guys this. Yeah, we wanted to I said we could go over. We were package organization ones I mean, we did this like a year ago but I think as a refresher we can just see how it's organized so that we can then integrate the the two in the best way possible or the easiest way possible. In. So, under we were the, the different modules are organized in a in a sort of a functional or a hierarchical manner, I mean functional and hierarchical manner so there are different folders that contain different kind of functions. In fact, are we supposed to have the screen on or can I share my screen. No, you can share. I'll stop sharing. Okay. Right. Okay. Okay. So, in in cacti inheriting this from cactus we have a all the plugins under the packages right. In we were we have a the organization is as follows we have some data structures that are under common under core we have the the autonomous modules that one is supposed to either run separately or by within the particular network. So we have a drivers under drivers we have categorization by DLT. We have identity management where we have agents, which are some deep here. So, here, you're supposed to have different folders correspond to different DLT's that I mean this how the source code is organized again. How we expose it is a different thing but just showing you okay and back to identity management there's also an identity network which we haven't quite done yet. Under network we have again these are the the smart contacts the ones that are there in the architecture diagram the sort of the common smart contacts those are categorized again by DLT is based on this one of the fabric which is like chain code of Corda which is like Corda app and then there's a relay because we don't need any DLT specific features here this is just a single common component and then we have under the SDKs we have again a single categorization or the first categorization based on DLT by SDK we basically mean these are libraries that one can incorporate it's sort of like how the cactus code API and then the the client API generally works and within cactus so here we have under each DLT we can have a different an API corresponding to a different programming language depending on what language the app developers programming in so we have one that's using the fabric the API another using the fabric node API and for the others we just have a single one for Bezo we just have a Node.js version for Corda we have a cotton version so each of these is a place where we are developing the source code but also the packages that we have been creating roughly corresponds to each of the endpoints in the file system that I just showed so just wanted to ask if we can categorize the packages here as well in using a similar kind of logic so then it will be easier to move or port the code from Veeble to there because right now this is a completely flat package structure we could but it would complicate every single build script that we have because a lot of them depend on paths outside of directory and then it becomes less copy-pasteable is there any sort of technical reason to do it in the tree structure or is it just the the way people understand it would be easier with that hierarchical the latter I think I think we also discussed maybe okay in that case maybe we can just continue on the experiment we were trying last year you remember you created new branch and we were you're trying to move Veeble code there that sort of stopped when we were after the announcement was made but we can try to do the same thing here like we'll move the source code in such a way that it maintains the hierarchical model so that it's easier for people to understand where to go and develop if they want to make any changes but then we can have a simulink inside the packages I think that may be a better way then okay I think I get what you mean I'm happy to restart that branch again but from now yeah let's I have that branch so I can yeah I mean Sandeep and I can take a look at that but for the immediate task I think maybe we'll just stick to what we have we will connect either Cactuscore API or create a new plugin that will depend on something within the viewer folder directly and then later we can move the code from viewer out to someplace else in the root folder yeah kind of manage to delete that old branch because rebasing that would be hell yeah so I would just create a new one and then start playing around with the current main branch being the basis instead of whatever we had back then because I don't even remember what we had back then and there was a million changes in both code bases in the meantime so reconciling that would be hell I would rather just delete that old branch what I meant restarting the concept of it so like redoing it from scratch but with the same idea yeah I agree but yeah we can come to that later I think I just want to get to the API feature that we have sketched out as quickly and seamlessly as possible so let's do that and then we can do the big refaction yeah that's more important okay sorry but I have to go I have a hard cut off I'll talk to you later alright thanks bye bye