Hiero SDK Community Call - 2026/08/10

Good morning everyone. >> Hello. >> Yeah, we'll just give it one more minute. Let's see if anyone else joins. Okay. Um, let's get started. Uh, welcome everyone to the STDK community call. Um yeah, you know, as we all know for all these community calls, um please be respectful to each other and uh yeah, and we'll open it up. Is there any agenda topics that anyone want to raise for today's call? Uh, okay. I see comments here. So, in the chat it says Sophia said TCK integrations in SDKs and the TCK data structures and HIP implementations in the SDKs. Okay, great. Yeah, let's talk about all that. Um, maybe I can just start with a a product overview um for the SDKs. So I think uh the most uh important uh new requirements coming up for the SDKs is the account balance uh query deprecations. I think we talked about this in last week's meeting but um so um I'll just I'll I'll pull up the design proposal or um and in the SDK collaboration hub we'll find the divine proposal for that. Uh in that you'll find that there's a couple of initiatives. one is is that some SDKs have this ping functionality and that currently uses the account balance query function uh function. So if we're deprecating that obviously that has to be changed and there's a proposal in the in the SDK proposal to change it to a different like a a null value. So basically what what will happen is it will return a if you get a return if you see any response you know that the node is active. Uh maybe I should back up and explain what the ping functionality is. Um the SDKs have this ability to ping different nodes to make sure that the nodes are healthy before you submit a transaction to them. So basically you're just looking to see if a node is alive or is a node dead and that's what the ping functionality is. I think also I would say that not all SDKs have implemented that ping functionality. So that's something else maybe to think about. So um yeah there's the ping functionality and then there's just the account balance query deprecation itself. So that means that when a user uh in the we're still in the timeline of September when a user tries to submit an account balance query they just came back a response that you know this kind of transaction is no longer supported and then in in the in the collaboration hub there's an entirely separate um uh SDK proposal around setting up a new mirror node um request. So basically you can get the account balance query from the mirror node. So that would be a new query that we're adding to the SDKs uh with new functionality. Um so I still think we're looking for comments and questions on both hit proposals and maybe I'll just try to type and do anything. Um so [sighs and gasps] let's share my screen. Um okay so if you see my screen if you go to the SDK collaboration hub and you go into proposals uh you'll find the two proposals here. One is the account balance query deprecation which is here. As I said it's broken into two stages. Stage one is just to replace the ping functionality. Stage two is to deprecate the query itself. And then the other um SDK proposal as I mentioned is the um here we go account balance query mirror node integration. This is about adding a new query called mirror node account balance query. And yeah now if there's any comments or questions um actually we had this discussion our last meeting. I did set up discussion topics for both of these in the um SDK collaboration hub discussions. So if you have any questions or comments for either of these SDK proposals, uh please um leave them here. Um and this is where we'll have the interactive discussions about you know changes, updates, modifications to these SDK proposals. Again uh just to these are important because we are actually deprecating networkwide this account bounce query is being deprecated. In fact if you go to um just type in account balance query deprecation you're going to see the public announcer on this. Um there's a blog post. In that blog post, you'll just find all more details including the deprecation timeline. And as seen, uh we're planning to fully deprecate this functionality in September. It's actually been a gradual process each month. uh we roughly we've been uh declining the throttle on that query to make it so people like they start noticing it's getting harder and harder to use and then by September it will be fully deprecated and then we provide the the alternative for people to use which is the mir a mirror node rest API free the mirror node rest API to check account balances so again um just because this is the most important piece of work uh at least from my perspective right now for the SDKs um I wanted to throw it open And any questions or comments on this piece of work? >> So we follow the the uh proposal document and that that's it >> or do I mean with other things? >> Yeah. Can you explain what you mean by supplement with other things? So how how do we deprecate it in a way that suits the requirements? Do we follow this this document um or do we have to supplement that with any other information? Do we read the blog post as well or something? >> Um I would think that everything you need is here in the account bounce query. There's the the new APIs. there is the let's say okay for stage one there's the information about how to replplummet and then for stage two there is the information about like you know for example what error code to return um things like that so I would think that all information um needed is here and hopefully across the SDKs we have a consistent um implementation which is why we have these documents in the SDK collaboration hub um and you know and if you disagree or if you think that we should change certain things. That's why we have the discussions to have an interactive um to have interactive discussions around DCSDK proposals. But I think the idea would be that once we all agree to the proposal, then this is what we would implement across all SDKs. >> Okay. Sure. If there's an issue, we'll just like add on to that. But great. >> Yep. >> I've created the issue in the Python, so someone should get started on that. >> Perfect. Awesome. Any other questions or concerns? Okay. Um that was my um my big uh topic. Um I would also just say that um we are also going to be making this change. Uh yeah, this is the most urgent change we'll be making in the um Go JavaScript Java SDKs. There are some downstream dependencies um this change in that um you know we have a lot of tests and things like this that rely on this also there's some reliance on the solo on this um I would say that uh you know if we just talk about the consensus node um just for so people know um so in September the throttle will go to zero that just means like any request you make around the account bounce query that goes to node it will just return like transaction not supported and then probably in this was a discussion we were having last week probably in November or something they will remove the code from that uh consensus zone completely that just means we have to do uh puts more urgency on the SDK changes because um any tests they have will start failing at that point um so yeah that's just a little bit of background so maybe um with that we can move to Sophie to your agenda items So first of all you had a TCK integration in SDK. Um what would you like to talk about for that? >> Yeah. Okay. Um so I just started looking at the TCK um code very recently. So I created some issues. I apologize if I'm not yet an expert. Um but appreciate any guidance. But uh yeah, I just had some questions with things. Um so okay I >> so actually just um sorry just so before I let you begin who do we have on from um Mustafa are you gonna be able to answer the questions on the TCK? Yeah, I think I can answer the questions. >> Okay. Sorry, sorry to interrupt, Sophie. I just want to make sure we had the right expertise on the call. So, okay, please go ahead, Sophie. >> So, I'm just trying to understand what these what these do. I understand this is like a like a flag. Uh, yes, it a test has been created for schedule create transaction or no, it hasn't been created. Can I confirm that's that's what this means? >> Yeah. Actually, this is a table. You need to switch the view like >> Yeah. >> Yeah. And at the end of each scenario, if you scroll to the right, you will see uh yes or no. Yeah. >> So, this is this is manually manually like yes no flagged. >> Yeah. I think this is for the TCK. Which scenarios are implemented for the TK itself? >> Okay. So there's let's say there's a new transaction account you know account whatever account create and then you create the TCK test and then you you then flag it yes manually. Is there any way to instead interpret the flag through the tests themselves? Uh the idea is that uh this is the first layer like the first thing is you need to have the test on the TCK repo itself. But after that each uh SDK have to implement uh given endpoint. uh so the TCK test can u call this SDK and then uh this operation to go to the consensus node and after that SDK returns to the TK and this case validate the given scenario. So it is more complex than just dynamic. So this is the easiest. So this is only showing if the TK have this scenario implemented. Uh >> yeah. So is that like what you run here which is like the you like run the JavaScript TCK tests does that tell you whether the JavaScript integrated correctly? Uh so on this case there are workflows and if given SDK uh doesn't doesn't have the given endpoint it just skips it and if it have it then run it. So for that reason I am telling that this those tables that you showed are actually only for the TCK part of the story. uh for the implementation itself, we need to check the uh workflows on the TCK works >> uh in in the SDKs >> uh >> or where where are those workflows? uh on the TK rep itself like in a there's a actions uh tab on GitHub and you can see the runs maybe I can >> okay yeah because um so some context is Angie and I we were doing some data analytics Angie was doing some data analytics for this specifically and one of the things that you brought up Keith in the TSC meeting a couple weeks back is are we able to infer HIP completion status by running the TCK tests um for things that are hips and seeing if they they complete. So um what as part of that I wanted to understand what already exists in the TCK so that we don't duplicate and what kind of data structures would enable some kind of SDK based um tracking whether you do sort of any of that um at the moment. So, I'm trying to work my way through the repo, but I've, you know, there's a lot of content here. I've just sort of started to make my way through it. Um, >> so most of the operations should be there like uh 80 or even 90% of the operation should be there on the TCK side. on SDK side. Uh I think GS, Java and Go also have the implementations. So maybe if you want on Python side, you can start implementing the uh endpoint. So TK can be configured to work also with the u Python SDK. Uh but yeah the idea the main idea of TK is uh verifying like you said the hips but also when you have scenarios on the TK side you can verify that each of the SDKs have the same behavior under given scenario and also with TK we can catch if there is a regression on the network uh side one because this is a multi-level testing. So yeah, it is very cool. So when you say you you run it against like the the JavaScript and you know it's integrated and things are you catching like 100% of the services like do you do you fail the run you know if if you're like less if the JavaScript is done less than 80 do you record the data like the the implementations themselves by >> by functionality or you you just kind of >> Yeah like the on TSK part we have uh scenarios and assertions for these scenarios. So if we have regression on SDK level or even network level we will totally catch it because the workflow will fail also consensus uh rep also are running TK test. So it is not only on the TK repo itself but other repos also run TCK test to verify if they have regression or not. Okay. Um yeah I know that this is only implemented for the SDKs. So I think the C++ may maybe it's not fully implemented but go Java and JavaScript. Um >> yeah I think go Java and JavaScript are with the most of the implementation for C++ like you said maybe it is a little behind. So yeah. Um, and then so I created some issues to like add the Python as you mentioned, but also like would would there be a use case to add like Swift and Rust or >> Yeah, I think uh we should be able to do that. >> Okay. And um I can't remember where where is the file where this I can't remember where you guys document the different types of services. Okay, maybe you have to go go with that. But I was just wondering if there's like an easy way to describe if something's a hip. So I know the TCK provides like lots of different services and things. Can we add to like a JSON file for recording that this is hit 1001 for example and recording which SDKs have passed the relevant tests for that service. Yeah, I think uh for example for every new new heap the test scenarios uh we will just u create the test under the name of the given heap. So when we open for example he 1313 I don't know.js like where is the tscript uh and there would be the test. So yeah. >> Okay. Um yeah, I mean that that kind of thing would be really useful to to Andy and I like in terms of gaining visibility with how the implementation of things are going. Um, Keith, I thought it was a great idea that you had to like run the TCK tests to just get a sense of what was being implemented. Um, yeah, thought that was a really good thing. Angie, Angie has made a pull request um making the first steps to start tracking hips. Um, but I think we still have some questions to and things to resolve like if if we should just run the test directly, how how much of the front matter you you you guys are okay changing and stuff like that. And I would appreciate maybe just um someone having a look through these little issues that I've just created. I think from the sounds of it, maybe this first one isn't quite right. But um yeah, that that would I think this this one was causing a little bit of confusion for me for a while. So I would appreciate if you have time to maybe check that out. Um I also found that there's quite a few good first issues and stuff in this repo that could be possible. For example, there's quite a lot of hashgraph references inside the TCK codes. Um, you know, you could have a good first issue where somebody changes the reference to Hyro or whatever. Um, so I just wanted to let you know that there's there's quite a few things that could open this repo to the rest of the community if that was desirable. >> Um, I am actually dropping a link which is to hip one. In hip one there is described each field and the whole idea of the hip. So you can maybe also look on that if you don't know about it. >> Thanks. Yeah, I I have seen this. I just wasn't sure how up to date this was because hip one was created in 2021. But if you're confirming that that that's the that's the that's the reference then I yeah I will take a look at that. Thanks. So I just want to call out one a couple of things. Um just so um now I yeah I really thank you Angie for your for your input. Um I definitely take a look at that. Um you know this this is not this this idea has come up before. Um so if you go to just the main hyro project and you go under projects uh you will find a board called cross SDK tracking. This was actually created by DM and the idea of this I think it was I mean I think is kind of similar to what Angie is uh saying. Basically it it tries to track um hit progress across the SDKs like uh we created an epic at this level and then we kind of tracked all of the work across all of the different SDK repos for that. Um, oh, and I I see. Yeah. So, and now like maybe this was a good or bad way to do it, but this was our attempt to track HIP status across all of the different SDKs >> um in one single place. >> So, this was the board that I had originally created. I shared this with Michael Garber and was still waiting his input. He had explained that he wanted to try to get this board a bit more automated seeing as how it's going to exponentially grow and require even more manual intervention. At the moment that board is completely manual. Everything that's been added, everything that's been documented has all done has been done manually by me as we don't necessarily have a good kind of accurate way to deduce what is and what is not implemented in the hips. So I ended up having to go through comb through every PR with a mention of the word hip, the hip number, things like that just to kind of get this board as accurate as possible. So ideally I would like to integrate this into the PR that I've also shared just to kind of give a bit more of an overview and then I know in the analytics repo on the dashboard we have something that is a visual representation of this where it goes into not just the SDKs but it'll go into consensus and mirror and all of that and give about an accurate estimate of the number of PRs that have been open in regards to whatever hip is being focused on. >> Oh, okay. So, so that's why I'm saying you created this one, Angie. Okay. Because there was one >> there was another board that Dion created which was very similar to this and I'm just I'm searching for it and I just I can't I think I need to go back through my see where that is. There there was a board that Yeah, go ahead. >> Oh, sorry. If there is a board that would be great. I had tried to find one as well. I could not. The only board that I had ever seen so far was the one uh that I believe Hendrickk uses where it does go in and it gives you the status of each one versus having to see it on hips. I think that's number 36 of his project boards I believe. >> Okay, let let me just because yeah, Dan had created a board that basically showed the status of all hips across all SDKs, but I just don't see it now. But let let me let me go search my emails and see if I can find it and then I can share that. Um yeah. Okay. But you know otherwise I think it's a great initiative. So if you have something that you need us to or me to review um And here Sophia just like a PR request is your PR something that you want review on right now. >> Well please if you have any feedback I did also try to share it with Michael Garber. I have not been able to get a hold of him. So if you are able to, I would love the input from both of you. I know he was also interested in seeing more of the hip process unfold as well. >> Okay. And where would I find your PR, Angie? >> Hold on one second. I can share a link to it. >> Is it in the hieredger or? >> Yep. Or it should be actually in the TCK repository for the first PR. Okay. This one here. This one here. Add hip tracking. Yep, that's the one. >> Okay. Okay. I I'll take a look at this. Um I Okay. Oh, and I'll link this for um all of the team to take a look at. Okay, that's great. >> Thank you. >> Now, um did you have so Sophia? >> Yeah. So, I I I think that the things can it it can be done faster. So I think Angie she's created a really good PR given the existing data structures and the existing like um formats with how things are documented but if there's scope to change like the data structures as mentioned like being able to add like um the tests run run the tests themselves and based on the test like l to see if there's any scope with that like I think things can become more efficient. Um but that that would in that would add like more changes and stuff so that maybe we could talk about that later as an option. Um >> yeah, >> I mean I'll just >> Yeah, >> I was going to say I I mean I I'll just tell you what I do these days Sophie to tell this stuff is that often um if I have this question in our new world um I I'll you know to me the SDK of reference is usually the Java JavaScript SDK. So I will go in and ask AI to say hey um does the for the for this feature supported by the by the JavaScript SDK let's just say like account balance query just as an example I'll say please look at the Java SDK and then please tell me look across all the other SDKs and tell me which feature this is also implemented in and then like I'll get back an immediate report that says oh well account balance query is supported in the JavaScript and the Java SDK but it's not supported in the Swift SDK or maybe it's implemented in the Go SDK, but it's missing these features. So, I just wondered that's become actually really easy and simple to do. So, I wondered if that's something that also can support um like documentation or analysis >> because that's just that's just the way I I I do it quite regularly now. >> Yeah, we don't we don't have any budget as far as I'm aware for AI tokens. So the the issue I would see with that is that would just tell you at a given point in time which how you know the level of priority that they have or the functionality that they have or give you a good guess but that doesn't necessarily mean that next week it's the same you know they could revert something or whatever. Um, so I yeah, like if I'm allowed to create like a pull request that changes a little bit of the data structures in the TCK, then I think we could just run some automated tests on like a regular cadence and either present the results in the TCK repo or present them elsewhere. Um but that those small data structure changes might enable you to get this the same kind of insight without having to call the AI um yourself manually and interpret the results. But I actually I I just want to ask another question. So as I understood it from your meet your when you presented at TSC the one of the reasons why your team wanted this functionality was because you know you're often being asked by team members oh like should we be working on this hip or this hip or that hip because you know we have if you go to our hip board we have I think literally I don't know tens or hundreds of hips that are approved but not being worked on. Um, so Mike, if if it if I don't know if I've gotten that challenge correct, but if I have that challenge correct to me that you would need even something more because there would also have to be and maybe this is where you guys were going the insight of well what hips are being prioritized and normally like hips always start in the consensus node. That's always like the starting place for all hips. Like usually it's like you implement the hip in the consensus node first and then when that's kind of getting almost finished you implement it in the mirror node and the probably in the future the block node and if needed or in the SDKs because they're all downstream of the consensus node. So like you have to understand that consensus no design first and then you can implement in the other things. And so you know I think what I heard from your previous conversation is like the other piece of value is like well what hips are being prioritized for work in the consensus node because again the SDKs are downstream of that. Is that an accurate thing to say? Um yeah, we we also have another issue raised in the governance repo that we were hoping to discuss in the TSQL which is um based on I think Steven's Stephen she she she's idea about um having it implementation status MD in the repos that maybe can't TCK based tests like I don't know maybe the consensus node or whatever. Um yeah maybe it's the last issue 678 >> and not this one. Okay. >> Yeah that that's that's me. >> Oh 6. Okay. Yeah. Okay. >> Um yeah. So so that's something that we want to discuss as well. that this isn't necessarily just a TCK thing, but I think I'm just trying to work towards um manually maintaining hit implementation or service implementation across 41 repos or whatever is going to become an increasingly losing losing game. So what can we do today to make that um more machine partable? And I think there are rough estimates that we can do and get reasonable results, but there's ways that we can make the data more accurate. So that's like a first step to >> trying to do that. >> Okay. Hey, I think as I'm sure you're aware, we have this um hip tracker in the now, but what the hip tracker does not show I think is like the status of implementation across the different products like um consensus node or mirror node or SDKs. So would um and you know and we've even struggled with that. I I'll just tell you like here you have tentative release date. You know, we've even struggled keeping that one updated because often like things will slip and stuff. So yeah, I mean I think that's a great topic discussion for TSC. I just kind of giving you some insights here is that you know often we are nervous about like saying oh well we expect the feature to be ready in consensus mode on this on this release because you know things often slip and then people get upset and angry. Um, so like this the difference between like the TSC like approving HIPS and then individual companies like Hashgraph implementing HIPS like anyone can obviously implement a HIP but then how do you communicate the progress um of that implementation is something that continues to be something that we should discuss and I see that um even please Ivan even please uh welcome and and what's your question? >> Yes uh thank you for having me. So, I'm just kind of exploring solutions for us. And this is kind of just maybe even a really simple overview question or something. Um, we're doing a digital twin e-commerce system. And so, my I'm just kind of we've been diving in and using uh Fabric and Basu and IPFS with some Ethereum. Um, I'm looking for stuff that speeds up transaction rates. It's a social commerce. So, we have social and so I'm really kind of looking and trying to figure out if there's documentation to hook this in for like social media governance, AI governance, uh, or uh, digital twin assets. And I've been asking AI and I'm sorry, it's pro probably a stupid overview question, but I was just kind of curious. >> Yeah. Um, can I can I make a suggestion? I I think we just have maybe a few more topics on the SDK topic and then I'm happy to stick around and answer all of your questions about the Hideera network. Um do would you be okay just doing that you and me doing that at towards the end of the call? >> Absolutely. Thank you. I appreciate it. >> No problem. Cool. Um yeah, so just to back to this tracking topic. Yeah, I think it's a great topic. Um I will ping um uh I'll I'll ping you know [clears throat] Hendrickk and uh also Michael on this topic and so we can come to the meeting more kind of prepared but yeah let's discuss it again like there's more overall like I said because I think the SDK is in isolation if you're talking about advanced tracking is is is limited because like I said you first have to track you know normally the cadence is consensus node mirror node and then SDKs or mirror node and SDKs together. So it's it's about tracking status in the consensus mode which becomes really critical for a lot of these things and also how we publish the information about the design in the consensus node. I think we've not doing a great job of that cuz you know like the leader is the is the um the SDKs and that we publish the designs here. Now other SDKs were trying to also follow this pattern. But I this would be my suggestion Sophie and Angie is that I think we need all SDKs following this kind of pattern where they publish the design or the feature in their own repo and then also like we have a someplace where we kind of track that imple that implementation. Um this allows people to because you know from the SDK side of things you have to understand what that implementation looks like in the consensus node. That's very important. Um, so yeah, that that's how I would think about it um for discussion in our next meeting this month. Two cents. >> Okay. Yeah, that makes sense. Sort of like translates to Python or whatever and have a framework. >> Yeah. Okay. Yeah, I look forward to being on TSC then and um talking about that. >> Okay. >> Thanks. I hope >> No problem. So maybe we could just do a quick round table of things people are working on for the SDKs. Um maybe I can just start with the the lime chain team. Um Mustafa do can you start with just what what you're working on for the SDKs and what's coming around >> uh on JavaScript Go and Java we are focused on uh deprecation of account balance query and for this repo uh we have either merged the pink pingo refactoring or it is on a PR and we are continuing with duplication itself for account balance. query and implementation of the mirror node compounds query and yeah this is our focus. Cool. Um Dosey any updates from your side? >> No like Mustafa said the same thing. >> Okay. Um any update on the Python side Sophie or Angie that you would like to share? Um we are continuing to complete a lot of TCK tests. Um and then we are refactoring some of the chunked transaction logic. Um and some we've got some serialization bugs that need to be fixed. So we've got a major release 0.3.0 coming up at some point um which will be probably a quite a big quite a big one. So yeah. >> Okay. Any um problems or blockers on the just on the Python implementation side? >> Not that I know any either. >> No, none that I can see. Uh we did have issues with the workflows uh last Friday given that the GitHub uh issue worldwide, but we've managed to get through those. Uh it was just issues with our runners, but as far as I know, the runners are back up and running and we've been able to continue. >> Okay, great. Um anyone else have any um updates or questions around SDKs that we can answer or address? Um, I have a question. Oh, sorry. >> No, no, please, please go ahead. >> Um, was for the uh C++ SDK. I apologize. I have not had an opportunity to take a look back at this. I just wasn't sure uh if Robert had been able to come back as a maintainer or if uh there's a new process for trying to find someone new to kind of take over it. >> Yeah, great question. Um we I did communicate to Robert after our TCK meeting uh and he he was immediately going to jump on like approving those PR the outstanding PRs. Now I actually need to go check and and see if that was done or not. But yeah, he is still going to be um acting as the maintainer. We have carved out some time for him every week to spend on that. So that's the status. Um but I should just go make sure it's so it's uh it's happening. >> Okay. Thank you. >> Right. Well, if no one has any other topics then um Evan, I I'm happy to answer your questions about the Hideera network more generally. That means like any of the SDK people, you're welcome to stick around for this conversation or you're welcome to um go back to your day and drop off. Um but yeah, so what uh what questions? So Evan, maybe we um what questions can I answer for you? >> Uh yeah, thank you. Thank you for having me. So I guess I'm kind of I'm wondering if there's any I I I've of course been using AI. I've been going through the documentation. Uh I've looked over everything as well. Um but what I'm trying to figure out is you need my understanding is you need IPFS to hold the asset if you want to do a decentralized network and then do Hyera hashgraph and then that scales. That that's correct, right? >> No. Um there's um maybe we just go back to so you know Hideera itself is a a decentralized ledger an L1 so you know it depends what you mean by certainly that you could implement a model where things are held on IPFS okay let's just maybe back up what is it that you're want to create what are what are the objects that you're looking to create and store are they tokens are they messages are they what are they what's the data type. >> So, yeah, I'm coming through to you through my mixed reality headset. This isn't a really great 3D model, but we're using AI models to clone out things um from the real world into ECOM. And so, the storage of those 3D digital twin model systems is one thing. >> Okay. So these are quite big pieces of data that and that's why you're talking about storing them on HCS or sorry on IPFS. >> Yeah, I think it's still going to be I think [snorts] by the time you compress it down to a GBL format or GBLF. Uh it's somewhere between five and 30 megabytes which isn't super big but it's still you know >> Yeah, that's big. Yeah. for for a blockchain that's big. Um so so normally most of people when they're implementing uh something like no so it depends what your goal is. Um I'm just going to go to hapskin. Um so on Hideera we have many different services and and uh and those things include things like um smart contracts or tokens or um many different services. I think the service is probably most relevant to you is the service we have called which is called Hideera consensus service or HCS. So basically what that allows you to do is is a contract where you can create a topic and then under that topic you can have individual messages and then so this typically when people are building out stuff in IPFS so so um you know a fundamental question is well so you're storing these um sorry I'm going to butcher this but you're storing your 3D um images or your 3D assets on IPFS and I'm guessing is that what you want is a source of immutab ility about the either tracking about this data on IPFS or immutability well like what's your what would be your goal of pairing a blockchain with um your storage medium IPFS >> yeah sure um so right now we are we're actually storing our proof of authenticity so we have an AI provenence agent which isn't really that new scan an item do a quick web search uh it's an AI agent link chain ling graph linksmith kind of thing um Python and then that relays and creates a certificate of authenticity um right now and then along with that um doing the storage pairing option with uh 3D scanning we've already got the certificate of authenticity but um yeah that's um >> yeah that's what that's what I assumed you were looking for so so basically what you do is that um with Hideera consensus service like I said you have this construct of a topic this is the topic and then you can have one or you can have like a million messages underneath the topic um you know the whole thing about HCS is that it's very cheap like each of these messages costs um 8 800s of a cent um but basically what's powerful about this and I don't this is quite unique to Hideera I don't think any other blockchain has this functionality is that this message can be a free form payload up to 1,024 bytes. So typically for this kind of content authenticity use case and we do have some kind of uh PC's and stuff around that but something you could do is like you you have your your data you store it on IPFS um you create the certificate of au authenticity um which it sounds like you already have a process for and you can just store that that um that that certificate of authenticity payload here or maybe a hash of the payload. load and then what this what this enables is authenticity um that you know everyone can say well it was created this time on this date was the and then I don't understand your model exactly so let me explain to me maybe a simil similar model that we worked on so let's say you're a photographer and you're doing pictures and you want to make sure that um if anyone steals your photo you can prove that it's your photo you created that date and time so one model you could do is that you you take that photo um you the JPEG or whatever you do a hash of it and then also you can sign over that hash um and you can you can almost maybe just do a jot like um like a jot with the sign the payload and then assigning the payload with your own signature and then you just store that jot here as an hs message. So, if anyone in the future says, "How how do you know if you really created that photo," you can go, "Well, anyone can just take that photo, recreate the hash of it, um, come here, compare the hashes, and see that it was authentic and that it was created at signed at this date and this time." So, there's been a lot of like use cases around that type of application. Does that sound like something that you're is am I in the right direction of what you're looking for? >> Yeah. Yeah, that that's very helpful. Thank you. Um, the one other thing I I'm really curious about is we've been using uh setting up an MCP server with uh you know ling graph, lang chain, etc. and then uh having the AI agent call it over to the blockchain network. Is that something possible with Hyera? So, Hideera ourselves do not offer a MCP server but well actually I should check on that. Maybe maybe maybe one of our teams does but um but there is another company called Hgraph um Hdraft um and they have just offered they offer an MC. So basically Hgraph offers so um maybe I just need to explain Hideera architecture a bit you know in Hideera we have consensus node but then we also have what we call the mirror node that's where it stores all of the data. So all this data we're looking at here comes from a mirror node. So, Hgraph has also operated their own they operate their own mirror node with an with an MCP server connected to it and actually their mirror node operates a um GraphQL um layer. So, basically you can traverse data very quickly. So, this would be one service where if if what you're asking for an NPC server is like can I have a service that very easily traverses and looks up data then um I think the answer is yes. Maybe you could use the Hgraph server, but otherwise like all of this data is freely available um using Hideera APIs. Um so you can also get the data that way. Is that what is that what you're asking for MCC server? So you can look up data. Is that the purpose? >> Um [clears throat] actually it's to post data. So like I said, we we've been doing like fabric, right? So post data and post the thing over to the private network. So the AI agent works as as opposed to the user posting the data. They just interact with the AI agent and the AI agent automatically creates the certificate on the blockchain itself. Um that's that's kind of the process we've been streamlining. >> I mean uh so you know this meeting is the SDK meeting. Um obviously as part of that like we have SDKs like normally when I want to do something like you're discussing I will just go into my AI I'll say hey AI um can you please um create an HCS topic and maybe you know using let's say just say the Hideera JavaScript SDK. So I'll say to AI hey please create a topic and then please create like 50 messages under that topic with these different payloads. So, I mean, I don't think we have a dedicated Well, okay, we do have something called AI Studio. I need to go look and see if they've added that capability. Um, so you can go look at their AI studio. >> [snorts] >> Um but for me um and you know this this was intended to to have that kind of maybe more automated functionality but I would just say like I um you know I just using my own AI that's usually a pretty simple process just create these Hideera consensus service messages on Hideera use just using AI it does it pretty easily. Also I'll just say one thing. Um if you just want to understand um the functionality just better also we have something called the the um the Hideera portal uh portal.hera.com and uh in that there's a playground. So everything I'm talking about for Hideeric and Sansa service messages um you would find here hcs and in that you can do what I was just talking about like create a topic um update an a topic submit a message um so yeah we have these tools as well if you if you if you as a developer want to play with them but like I said you can just tell AI to like read our docs and then just do all of this um using our JavaScript SDK. Does that help? And also, yeah, please check out Hideera AI Studio because it maybe even has something maybe a layer above that might be useful for you. >> That's great. Thank you. Um, the other thing I've been looking at is so I've been going through and uh like linking over our AI with a D-Wave quantum computer. So, of course, with fabric, I realized that I could go through and use the Nestie uh to basically build my own chain code to upgrade the algorithms to quantum resistance. And so, that was something I was kind of curious about with Hideera as well um or and zero knowledge proofs. So um the the nice thing about Hideera consensus service as I mentioned is that these messages are all um they are all self-contained. So basically um you know so this can be any payload you want. So this this means that the payload could be something like a I don't know something signed over by a quantum resistant key. So basically like if we go into a postcon world you don't need to support you don't need to trust the network itself or let's say you can just trust the the self-encclosed payload and that could be a zero knowledge proof it could be a quantum resistant signature the like I said the only limitation on this is that the payload can be has to be under 1 bytes I do I don't know this the the quantum resistant scheme you're using but that often a problem with the quantum resistance schemes is that the signatures get very big. So, I don't know if what you're looking to do would fit under 100 1,024 bytes. Um, but yeah, that's something to think about. >> That's great. Thank you. Yeah, I mean, I was looking at the crystalline uh I'm butchering that probably. I got to look back through my notes, but structure. Um, but yeah, I mean, that's great. Thank you. I I was just wondering about that. Thank you. So Sophie, I saw you raise your hand. >> Yeah, I correct me if I'm wrong, but I I don't think right now the consensus repo is written in a way where it's you could you could just flip the different algorithms used. It's TSS based as well, which um is not fully resistant either. So, I think there needs to be some sort of short-term migration to just enable like a different um a different switch there and then maybe some of the signing methods may have to in my view. >> So, so we're talking we're talking about quantum resistance. Is that what you're referring to, Sophie? >> Yeah. Well, basically right now the the code is not as resistant as it could be. I think there needs to be some refactoring um to be able to do that in the hierro consensus mode. >> Yeah, I I think I think the main change that we're looking to make for quantum resistance is adding a new account type that supports a new quantum resistant key. The problem is there's not been a lot of um you know the the quantum keys are still kind of up in the air in terms of their technical design. I mean I mean not they're not they themselves are not in the air but like which one will become kind of mainstream is still kind of up in the air. So um and you know is it so I think we're just waiting for things to solidify a little bit before we implement that kind of functionality. I I would just say like no blockchain these days is quantum resistant. So, but I I would say like as I said under HCS because you can submit your own payload. You could submit your own signed pay like you could submit a payload signed by a quantum resistant key. At least the payload itself is quantum resistant. Um but yeah, that's maybe the only thing I could add. Can I answer any more questions for you, Kevin? I don't think so. I mean, that was kind of the big ones. Um, thank you. Yeah, that's just something I've been looking at. So, as far as how to because right now we're using um D-Wave for optimization problems and then having that formatted in a Python kind of payload that the AI sends over to a quantum computer. And so, I mean, I thought, "Oh crap, if we're doing this, is there a way to proof our certificate of authenticity program?" [clears throat] So, thank you so much for being so kind with your time in answering the questions and this was great. I took notes and uh put it all in my browser and everything. So, thank you so much. >> Cool. I actually I did have one question. You mentioned a few times that you're looking to use fabric. Actually, I I I thought that was really, you know, I I worked on fabric many years ago. Um, but there is no, am I wrong? There's no operational fabric. You're looking at setting up your own fabric network. Is that what it is? Yes. So, I I've done this a few times. I've used uh Collido and Filecoin and kind of combined the networks and then also um over our Google cloud account had our own fabric network that kind of thing and ran it that way. >> Okay. Have you run a fabric network before? >> I have actually. I've ran a fabric network and a Basu network. I've done it locally and I've done it on the cloud. I did it for a hackathon last November and combined it with our AI agent and uh NFC cards. They really didn't know what to make of it in the hackathon, but it was cool to see it come together in about 48 hours. >> Cool. Okay. Yeah, I I I I don't I don't normally disparage any other network. I I would say that from my own experience uh running a fabric network in production uh was very challenging. So um but yeah, whatever network you choose that that's great. Sophia, you had your hand up. >> Yeah. um even I don't know if your code is going to be close sourced or something but if you are working on experiments um as a way of like raising awareness and seeing what's available seeing how the community responds and things there is a nice place um called hierro hackers which is uh sort of part of hierro which which which allows you to create these fast prototypes, integrate, test things out, and uh yeah, there's some AI agent stuff there as well, but but it it could just be like a you could set something up and then you have something more more um concrete to sort of discuss on the TSC. I've actually been working on the quantum migration of the consensus node which I will post here eventually but it's only at like 99% accuracy so far so I I need to work hard for that remaining 1%. Um but yeah this is it's just like a good link if you want to create proof of concepts or something like that. Um and it's visible to the hierro community and it's all open source so we're all there. we were looking at this and there's some developers who are also happy to pick up issues. Um, yeah, that that will then sort of pull things into the higher ecosystem if that's something that you want to try. >> Thank you so much. >> I realize that I I'm we're over the time so I'm going to have to drop but please uh continue the conversation guys. Um, yeah, thank you. Thank you so much. It's great to meet you. >> Great to meet you as well. And um thank you. Thank you so much for taking time to answer the questions. Uh both of you, uh I really appreciate you just taking time. Like I said, I'm just trying to figure it out. And uh thank thank you everyone. >> Cool. Thank you guys. Thank you everyone. >> Thank you.