Hiero SDK Community Call - 2026/08/24

Hey everyone. Got a few minutes. Hello. Right. Um, welcome everyone to the STK community call. Um this is a a call where we talk about all the great things about the hierro STKs. Um key governing principle for these calls is uh hopefully everyone can be nice for one another. So um let's dive in. Um and on the agenda today um I did have a new proposal um in the SDK collaboration hub that I wanted to quickly discuss. Is there any other agenda topics anyone else had? No. Can I check? Can you guys hear me? Okay. >> Yeah, we can hear you. >> Great. >> Perfect. Okay. So, let me uh go to the first topic. Uh just give me one second. Okay, I'm going to share my screen. All right. So, on Friday, I put up a new uh SDK proposal. Um, and maybe I can just give some his uh Sorry, it's just a PR right now. Uh, yeah, this one here. Um so basically uh maybe I just give you a background for this proposal. Um you know as you know um I we've had some other uh SDK proposals around adding uh balance functionality and token balance functionality using the Hideera mirror node. And you know this is not new. the uh the the Hierro SDKs already have mirror node functionality. I guess the most biggest one would be like fee estimate query is a big mirror node one. We have uh we also have um you know we've also also always always had the the uh the the one for HCS streaming although that's a bit different but I think as we've as I've been working on these new SDK proposals for the mir node uh account balance query and mir node token query uh Hrik has been doing a architectural review and raising some concerns that maybe the architecture we've been using for those mirror node HTTP request is not ideal and he has you know this was in particular I think he left some comments on for the Java in the Java SDK but I I think the comments are probably more universal. So kind of following his feedback which I I kind of did document uh you can actually see his comments here in the in in the Java uh in the Java PR uh regarding mirror node balance query. Um I put together this revised architecture proposal. So, you know, this is obviously a bigger effort, right? This would mean that we would have to not only would this affect potentially the implementations for mirror node balance query or mirror node token query, but maybe we have to go back and actually fix fee estimate query as well. And and there's a couple other I think they are they're all here all these queries. So now you know obviously there's there's some specific things to specific SDKs and then there's just a more generic architecture. So let me just first ask um Mustafa uh did did you have time to look at this or or at Hendrickk's comments on the Java um SDK? Yeah, I look at that but I need to uh do deep dive because I only get familiar with the problem and uh ideas. So I need uh further research. Okay. Um, so yeah. Uh, so like I said, there's like a generic there's some generic points here, but then there's some specific ones like when we talk about Android, that's more specific to probably Java. Um, uh, and there's the goals, the non- goals. There's a proposal for new APIs, new headers, uh, SPI. Um, so yeah, and I and I just be honest, like I just created this on Friday, so I certainly need Hendrickk to go through this and uh provide his feedback and make sure I've gotten this proposal correct. Um, and then just beyond the transport, there was just also some comments about just overall behavioral alignment between the SDKs on uh some of this stuff. So yeah, it's obviously it's a big proposal. um it has an impact. Um I do think it raises the open question which I also raised to Henrik is like for these outstanding SDK proposals we have on um mirror node just in case anyone's not seen them on um the mirror node balance query and mirror node token query. Do we move forward with those proposals using the current architecture or do we hold until like we have this new HTTP client architecture finalized and then implement them? You know, we've already actually already implemented mirror node bounds query in the JS SDK. So, you know, we certainly have to go back and refactor that. Um, yes, that that's an open question that we have to we'll have to work on on an SDK by SDK basis. >> Sorry, Keith. Hi. Sophie, I didn't understand exactly what DHTP is is is um where are we switching to? >> Yeah, maybe I I think you maybe just joined. Uh so I I think so. So do we do we make these changes? uh like do we finalize this proposal before implementing mir node token balance query and mir node uh account balance query or do we move forward with the current architecture the current proposals >> okay so we will have to change them afterwards is what you're saying >> yeah like just just to be clear the current the the the current proposals for um mir Let's say mirror node balance query um follows the the current architecture used by fee estimate query. So it uses that current architecture for the HTTP requests. >> Does that make sense Sophie? >> Yeah. Okay. I mean I guess I don't have enough experience sort of to judge what is best but um yeah that sounds reasonable. >> My question would be I guess what are the benefits of going with disposal as opposed to considering one of the current architecture files? >> Yeah. So, so maybe um maybe the best thing is actually let's just look at >> let's look at Hendrickk's original comment. There's some echo I think uh so so let me just because maybe maybe it's easier to understand if we actually look at Hendrick's original uh objections. So this is just so Hendrickk's point and this was looking at the the implementation for mir with the proposed implementation for mirror node token balance query in the Java SDK. his comments were so I have huge concerns with the implementation and and this is why um I'll just let you guys read this but like um there was some concerns about uh also some concerns about precision although that was specific to the JS SDK and I think I I have a different proposal to fix that but you know some you know each each static HTTP client owns its own selective thread and connection pool. Uh, none of them is ever closed. So, I mean, this is kind of more deep architectural stuff. Other problems, the HTTP client doesn't use client executor. Um, there's no builder. So, callers cannot supply a corporate proxy query. Specific to the Java one, it's not part of the Android class. So, it kind of breaks Android compatibility. So yeah, this was his suggestion was to stop all this development and to kind of take a second look at the architecture. So I I mean I'm not doing a very good job explaining all his points, but I think it's easier you guys can just go in and read his comments. And that's his concerns about the existing architecture and this would be the existing architecture for most importantly this is the architecture used by fee estimate query which today is in all the SDKs. So he's saying the current architecture we have for fe estimate query is also in some ways problematic. Although I don't you know I think the the feedback I gave to Henrik was well we've been running festimate query for quite a while now and we've not had any problems but I I do think that in the review I mean his points are valid. I I mean it was probably a not an ideal architectural design what we're currently using at least in the the SDKs I looked at. Does that make sense Sophie? >> Yeah, I mean this I I didn't create like the estimate query. So yeah, this why I'm trying to like extrapolate a little bit but um yeah, I think that makes sense. especially like uh fetching and stuff is like hard to get consistently right I guess. So I think his points make sense. Um at the same time we probably have this kind of thing going on in the SDKs anyway and we sort of used to it but yeah it's not great. Thanks for explaining. >> Yeah. So, I think the call to action is if um you know, if everyone if you go and look at the PRs, if you can go look at this this PR, and like I say, it's still just a draft because I need Hendrickk to review and make sure I got it right. But yeah, if everyone can go in and take a look at this PR um and you can this is your chance to provide comments and stuff um early comments and questions and we can uh work through it. Okay. [clears throat] Um, that was the major topic I had. Um, maybe we we could just do a kind of a round table and see if there's any other uh comments. So maybe I'll just stop with you Mustafa. Any updates on the SDKs from your side? >> Yeah. uh from Java we were and we are also now focused on this uh mirror account balance, mirror token balance. Uh also I opened some task in uh go and we are currently working on them but I can give the word to do you want to say your update? Uh yeah we're um yeah in the go ak we are also working for this uh deprecations uh also there are some uh issues that are open in thek and I'm working on them and yeah great um Angie or Sophie any updates on the Python SDK We are moving forward with the deprecation of account balance query and switching over to the mayor note account bounds query. Uh my question for you Keith is the status update for 1195 has this document been finalized where we are able to go ahead and make an issue to create uh the functionality for 1195 or do you suggest that we still hold off for the time being? >> Yeah. So, uh, HIP 1195 or Hyro Hooks is, uh, still on hold. Um, my expectation is that we will probably eventually be making some architectural changes to HIP1 195. So, my recommendation would be to hold on HI 115 for now. >> Okay, thank you. U, but beyond that, we we do plan on implementing uh the next upcoming HIPS. We are just waiting for them to reach final status and then we have had a few uh changes to our TCK in the sense that we've just been adding our PC methods. Uh so I see your hand up. I think I'm forgetting something. >> No, no, no. It's just uh after you've finished it's not exactly related. >> Oh, okay. So beyond that, that's pretty much it from our end on the Python side of things for now. Thank you. Great. >> Mine's not update related, so I don't know if anyone else wants to jump in. I just have something else I like to talk about. >> Yeah, please go ahead, Sophie. >> Okay. Um, yeah, I was busy over the weekend. Um so we have become aware that there's um permission holders across Hyro that are that haven't had any pull request issue comment or review or merge kind of activity for more than six months. Um, so I created these pull requests to leave it up to the maintainers to decide what to do with this. So for example with the C++ SDK um it would be like the proposal basically I've done this throughout hyro so like it's just one rule applied to everything which is um if you know to remove the permission holders that have been inactive for six months. The reason why I believe that could be a good idea is they hold, you know, possibly write permissions and, you know, they could merge something, but they may not have the same affiliation with the project or they might not have the current knowledge to safely like maintain it anymore. Um, so the idea is to like remove the permission holders. If the if the person then comes back uh alive on the project then you know of course you would just follow the same procedures whatever to get that back again. Um but this means that I have a few pending pull requests for SDKs and um yeah this all has a git vote. All you need to do is go to the relevant page and then you need to give it a thumbs up or a thumbs down or an I. Um yeah, I really appreciate that. Um what some people have done, some maintainers have done is they have requested changes. So for example, you know, I I don't know who all these GitHub accounts are. Um and some of the inactive members are maybe maybe people you don't want to remove. Um so people just tell me can you add this person back and add this person back. So if you want to make any changes with that then that's fine. Ultimately, I think you can also say it's a bad idea. Cancel everything. I think you know that's also fine, but it would be good to get this moving because this this might be seen like as a security issue or just general tidy up. So, for example, in like the analytics dashboard, um we do have like 100 permission holders that are inactive um which I don't think is giving like the best sort of impression. So I think that's like a good good time to sort of tidy that up. So yeah, if anyone from the SDKs has a free minute or two to just look through the ones that you are maintainers of, I'd really appreciate that. >> So I think the Thank you Sophie. I guess my question is I I I I have to go back through and look, but what's our official policy? Is there an official hierro policy on like I I think you've based this on if nobody's had activity for six months they are removed. Is there is there an official policy? >> Um yes there is a I think there is a uh roles and groups or maintainers. Yeah, but I don't Is it in there in that document? Yeah, we should maybe you can open up. I I don't know if it has that is that removal as part Oh, yeah. Here we go. It's inactive for 6 months. So, there's a second part to that, right? And does not respond when contacted. >> Yeah. Um, you know, and it's may as well. So, ultimately, I think you can decide not to. Um, yeah. So, as I said, you could just be like, "Yeah, I'm not interested in this. Let's leave all the permission holders." >> So, >> it seems, you know, in Hierro, it's like the responsibility is given exactly to the maintainer teams. >> So, just be clear, like I'm supportive. I think we should remove inactive maintainers. I I do think though that like some SDKs like you know I can think of like some of the identity SDKs or some of the the um maybe the C++ SDK. No, I think that's a bad example but maybe the Swift SDK there's not been a lot of activity. Yeah, like maybe they've not been proactive but there's not been a lot of PRs or anything for them to approve. So that's why I I I think the and is important because if they are still responsive and there's just not been many PRs for them to approve, then should they be removed? Um you know obviously this is up to the maintain this is up to the maintainers. >> Yeah, >> the inactivity is not about PR approvals only. It's multi-dimensional. So it's going to account for you haven't been creating any issues. You haven't been creating any comments. you haven't been doing any approvals either or merges. So I mean you know it depends the standards that you want to to to kind of enforce at Hyro but my consideration of a maintainer would would be like a project stewards. So um you know creating issues is part of it as well. So we don't have like the chicken and egg problem of like okay there's no there's no issues so there's nothing to do or things to talk about. Um my my personal opinion would be would be um yeah we should we should consider somebody inactive if they've not even created issues and they're a maintainer. I mean you can think of even just basic dependabot updates where you need to update the for security reasons. um the packages that you use that would count as activity and I think that's that's a very fair maintainer responsibility to have to do. >> Okay. Um I uh Daniel, did you get your hand up? Any questions? Come >> I'm trying to figure out how to take my hand down. Sorry, I don't know. >> Uh yeah, just one thing. Uh I just wanted to add on uh Sophie's presentation cuz uh there is uh a point you raised that uh there could be uh repository where maintainers don't have any per but now to the workflows we have the upgrade of the workflows we have like someone can't just come out from nowhere and opens up here without being assigned without uh issues being raised. So I think that's a concern. It's not that uh but that's a concern cuz uh for the PRs to to gain number it means that we have to have more issues to to work on. >> Yeah. I I also believe like if we if we don't have up-to-date data on who who you know is is involved with the project um you know in meaningful ways then then um we we don't know when we need to find new maintainers. We might believe we have three maintainers, two committers, we have a pipeline going. Um that's like the other consideration, right? So, as Daniel said, yeah, we could always have community members stepping in to these repos and they want to be engaged um and the maintainers may not be active. But then the second issue is like we we just might not be aware of the long-term sustainability of that project if we don't have healthy pipelines. By removing the people that are are inactive, we can see what's left and start acting based on higher quality information. Okay. Um, are you going to raise this at TSC tomorrow, Sophie? >> Um, I don't know if I will. Um, but I think Jessica will raise it. So, it was her idea. I think Hendrickk is involved in it too. the we initially tried to call inactive permission holders across >> Hyro as a whole and I think we would need TSC approval for that. Um long story short the decision was uh probably with this is that we're going to have to do it by team. So I went ahead and created like 40 pull request. [laughter] Um but we do have people that are inactive for six months like across the entire project not just in the team. Um, and there's quite quite a lot of people. I don't know how many this is, but it looks to me like 60. >> Okay. All right. Well, it sounds like a good initiative. I mean, I guess at the end of the day, it will be up to individual projects to vote and to remove a maintainer or committer. So, um, yeah, sounds good. >> Yep. So again, if you like the idea of calling permission holders, but not everyone that I specified, please just let me know and I will change the names and things. I just don't know who these people are. So, you know, way of >> I I assume for some of the for many of the SDK the SDK repos, these are going to be like Lime Chain um people that were at Lime Chain that either have left Lime Chain or have moved on to other projects at Lime Chain. So probably um yeah for some of those folks we we will know who they are uh and they should be removed um that that so I'll just speak to the SDK repos that one's for sure. Yeah, we need to probably do that cleanup. >> Right. Thank you. >> All right. Any other questions or comments? >> Just one thing. Uh I just wanted to ask an about the progress of the hip hip tracking board. >> As of right now, Sopia and I are still working. We need to come with a kind of better way to either automate it through the use of TCK testing. Uh we have run into quite a few issues with that. The biggest one is that because of the architecture and the way that the services are structured, you essentially will have uh for example I'm just going to use 1261. It will correlate to a contract service then it will correlate to token service then it could correlate to another service. So you essentially have a lot of test specifications and then there are times where it's duplicates. So we have been exploring a different idea of trying to uh one come up with a better way to automate this to reduce up the uh duplication. The idea that Sophie and I have uh kind of been going around back and forth with is to have individual hip tracking boards uh for each of the SDKs. So essentially you'll have one for Python, Java, Swift, JavaScript, so on and so forth that will essentially follow a set of specifications defined in their repository and then that way users contributors will kind of have a better influence or or idea of where exactly HIPS are in the process in terms of have they been implemented or have they not been implemented. Uh so do feel free to reach out if you have a different idea in mind if you have a better way to kind of automate this process because we do kind of want to get this moving forward especially as more hips are coming out. I know we will have the introduction of 1068, we'll have 1500, then then of course 1195 when this design document is ready. But again, do feel free to let us know if you have any ideas. As of right now, we are still just kind of going back and forth trying to determine what the best approach would be for this moving forward. >> Okay, thank you. Yeah, >> great. Any other comments or feedback? All right, I think we can end it there. Um, as I said, the major call to action is uh hopefully everyone can review that new PR in the SDA collaboration hub for the HTTP client architecture because this is a this is quite important and it will potent potentially uh generate um fair amount of work and have us require us to go back and revise some existing queries. So um yeah, we want to make sure we get it right. So everyone's comments and feedback are most appreciated. Um yeah, otherwise thank you everyone for your time today and look forward to talking again. >> Thank you again. >> Bye. >> Thank you. Keith, have a good one everyone. >> Bye. >> Is the is the link in the chat? >> Uh no, but I I can provide Oh, >> I can provide it. One sec. Just let me just get it to you. You got it. >> Yeah. Thank you. >> All right. Thank you. Okay. Bye. Talk to you later then. Bye. Bye. Thank you.