 Hello. Hello. James, I will make you the host. There you go. James, I can see your mouth moving, but I can't hear you. Sorry about that. There we go. Yeah, I switched headphones there. So let's give it another minute or so for everybody to log in. And it looks like you've got what, 10 people, which is good. Hey, Sean. Glad you can make it on there. I don't think anybody else is going to join this meeting. Looks like we got everybody there. So the reason, let me go ahead and toss the agenda up as I've got it. And then just kind of walk through why I decided to hold this meeting. Can everybody see the agenda as I've got it on there? Yeah. Yeah, so what. The reason I called this meeting is that we haven't really had a contributors meeting since last July or June, actually. And my company, which consists of Bill and I and another part time individual, we've been putting a lot of effort into around the 1.0 code base. We've, I think we've done a few contributions last year, including the go SDK. And then we kind of got a little bit worried that it was going to wayside, and then I, I heard through Duncan, BTP that it was going to be a transition to kind of an older archive version, and taking off of the main page. And I wanted to see if there was still interest in working on the 1.0. thread. The two oh thread, which Sean has been leading on there has been happening for a, a couple of years now, and is linked in with their code base that they put together called splinter. And transact and saw tooth. But the 1.0 is really the one that a lot of people seem to be working on. I thought I'd just toss one particular screen up just to show people how much saw tooth has been used. And see this is, you know, there's 609,000 lines to code. But the big thing to me is we have been in a media a lot almost 5000 media mentions. But, and 4.6,000 or 4,600 full request. We've had a lot of activity it slowed down quite a bit over the last year. And I thought I'd put him call out and see, do people want to join in to work on the 1x code line. Don't mean to take anything away from the 2.0 code line, but I put some ideas and what we can do on the 1.0 code line and number two there. And I wanted to basically toss it out and see what people think. Based on this meeting today. Do people like what's happening with it in terms of being put off to the side or should we be working on it. More As a group and everything else so Duncan, go ahead. Thank you. Thank you. First of all, thank you for convening this. Second of all, yeah, I mean, B2P amongst other companies, you know, has invested interest in sort of continuing and there is unfortunately the sort of the careless talks, careless talk cost lives aspect to this that, you know, it's, you know, mutterings that oh well it's you know it's there's not a huge amount of activity therefore, you know, the next logical step in in high pleasure land is to make it a dormant project. That can't happen unilaterally but you know that that was a set the alarm bells ringing for us certainly because if something becomes dormant. It's being downgraded from being incubated to dormant and then if it, if it ever emerges from its dormancy whatever that word is, it winds up being in incubation stage, state again, which obviously is would be frankly from our point of view, nothing short of a disaster. So anyway, that you know, and the fact it's dormant I guess you could say is, you know, is as much, you know, to do with us is to do with anybody else in that we've been doing a lot of work on the, on the one dot x branch, but haven't really focused on contributing that back. I don't think there's any issue by the way with there being a one dot x and a two dot x version of something. And so yes, I fully support the idea of us, you know, re galvanizing work around one dot x, which is the area that we're most, most, you know, closely associated. With my money I was most closely associated with. So, so I hope that makes sense. So, are there any other thoughts on this. Anybody like a run you're on the technical hearing committee. You have any thoughts or Duncan, no other thoughts. I mean, you were you're asking a room specifically for a positive. Yeah. I mean, it's, it's interesting to hear the rumors. That's not how you spell my name. Yeah, I got it about making it dormant. There's been no communication from anybody at hyper ledger to that effect towards any of the maintainers as far as I know. So I think that's, you know, maybe maybe indicates a maybe deeper hyper ledger issue. In terms of the interesting bit of this, which I think is is re kindling one dot x, you know, I'd like to point out that, you know, we've been active working on, you know, version two for quite a while, but we did write version one. So, so don't position me as not caring about version one either because I think the project health as a whole, certainly more important than version one versus version two. I think, given the speed at which version two is progressing at the moment. If there are things that we can do to bring version one kind of forward and really even maybe taking some of the stuff from version two and backporting it. One of the things on your list is abstracting the LMDB database that works already been done in live sawtooth. So that's, you know, I would I would encourage that path to be seen more as making, you know, one dot three, which would be the development version of the one person one branch. Making version one dot three use live sawtooth. And it wouldn't need to use the parts that don't apply. But that being a pretty good roadmap to kind of unifying the code between between the branches. And the few of those contribution ideas are stuff that we already have and it wasn't aware of the Saudi of the saute database abstraction happening in the sawtooth live. We have one which needs to be tidied up for the upstream, but for Saudi be we have that that we contribute we have one for the transaction commit cash. And the end a rock DB implementation time that it's perfectly okay from my point of view to try to align that up with what's in saw sawtooth live and look and compare what we have versus the sawtooth live into their it required a fair amount of changes to basically life span life cycles, not lifetimes in a lot of the rest code or to do it to distract the trade out so it's we separated out the thinking about the rocks to be versus the Saudi be just because the the trade is a much more significant change. But yeah, that's cool. We can do that. The, I don't know. Well, I guess rust weekend. And I don't know what the state of the sawtooth live is on the current 1.3 meaning right as as of this moment in the 1.2 which we base everything off of. It's not in there explicitly. 1.3 and 1.2 are identical at the current moment. Yeah, they're almost identical. There's a there's a couple of changes that weren't worth releasing. So we can work to line those up. Pretty easily I think I would assume it's not that it's not rocket science that one. But live sawtooth isn't really tied to sawtooth to in any way in fact it doesn't even have that as the version of birds, it's version numbers one, one dot something or 0.1 something. And that was on purpose because it's, you know, doesn't really need to follow the same life cycle as the sawtooth core repository. But also the idea of making things reusable is kind of the point of live sawtooth is, you know, let's abstract some of these things away so that we can make you know, a library that makes building sawtooth or or variants on sawtooth a lot easier. And so, you know, you're talking about making that a trait that that's one of the, you know, the focuses of that code is doing things like that and then fixing other issues. But the code that's in live sawtooth from a, a rust perspective is far better informed from experience than the older rust in one dot three. But it's going to be a better, a better place to kind of move forward with given that so like things like life, lifetimes and stuff like that. There are not very many lifetimes and live sawtooth, at least not that code. Stuff like that that just advanced with the team's advanced knowledge across the room. You got any comments from the TSC side. I'm being really careful on this conversation right now. So multiple parts flowing floating around, right? I wanted to, I want to hear from, from all the viewpoints before making any statements or any of my statements going forward is purely to inquire not really like an opinion distribution, right? Just trying to understand and sense what's going around. You know, like previously I was involved to greater conversation details, even the tech conversations, but nowadays I'm unable to do to other activities. However, from what I understand is happening, at least I was from since when, since when I was involved, the two dot or the approach that Sean was mentioning, the library approach. That's the direction that like I liked as well in terms of composability of sawtooth and bringing that modular aspects into the code base, right? However, I also understand from your viewpoint that there were a few things that went in with the earlier release before the refactoring happened. And, right. So, I mean, I do have some thoughts around it, but my question to either of these comments is, is there a way like maybe for first, right? So James question to you, do you think the features that you want to bring in? Is there a merit in adopting that to sawtooth library or that version of code? Like what's the effort involved and what's why it's not possible. I think it's case. No, sir. Oh, go ahead. Go ahead. Kevin. I think it depends on what's what the changes involved. Right. So, from. Speaking from our perspective in particular, we're when we work on the changes and the features that tends to be stuff that we're particularly interested in as a business. So, we're so therefore we're doing it off of the, the line that we're supporting, which is the 1-2. The so that tends to be our 1st protocol. It also tends to be that's also for a lot of it tends to involve the Python code more than anything else. So, even if we do like take the Saudi visa, if there are Python changes, I have to go along with that. We can do stuff in the sawtooth live, but the heavy part has to be well, sorry, the payoff is in the sawtooth core for 1.3 or 1-1-x whatever. The, so there's not a problem with it at all, whether it's important or not is a different whether it's important to do it and sawtooth live. It depends on the content of a change, I would think right saw DB obviously wasn't aware of the DB abstraction stuff in sawtooth live. So that's, that's a good one. But the core instance, another thing, which is, which we have in mind on this list, which is another abstraction thing, which is abstracting out the, which I don't know if it's progressed and sawtooth live or not, abstracting out the identity signer stuff, but we need that to work in 1-2. I guess the way we would like to go about things is doing our contributions from the 1.x and then porting it forward, as opposed to do it on 2.x and then figuring out a way how to carve it apart and put it in 1.x the other way. But there's no philosophical disagreement with abstracting everything out until the library seems to be the right thing to do. Yeah, but from our, our perspective is we've, it's just basically Bill and I and Bill can comment on this, but we're using sawtooth as a back store. The store documents then. And we've been using a different consensus service, which we're going to need to figure out how to push that up so that it can be used by everybody, which is we're using the Hadera consensus service and we're using it in a more complete manner than say fabric did when it was started in there. We're being sponsored by the Hadera foundation in order to do that. And we're using that as our consensus. So we have a public consensus with a private back store and we're using a 1.x code base for that. And that's why we haven't pushed into lip sawtooth or any of that other stuff in there and we just haven't had frankly time, which is why we did our go library we've done some other contributions we're about ready to put some other ones in. So from our perspective, it's important to keep working on the 1.x as it is before going into lip sawtooth. And Bill, do you want to say anything on that? You're muted. Thanks. Yeah. I just want to reinforce this thing. So, you know, all of it seems that all of the people outside of the, maybe the core group who are contributing or doing work on sawtooth is doing our doing the work sort of business work, right? Improvements are coming in because we need them in order to build the applications that we're building that we're actually trying to commercialize or release to the public. So from that perspective, I think it really does make sense for that a lot of these innovations and improvements end up in 1.x first because that's the place where it's going to be able to be able to leverage the quickest, especially because you know it's 2.0 it's not ready for prime time, I guess. It's the best way of saying that. And there's a lot of existing code and there's a lot of existing experience on 1.x so it does make sense for things to go into that. We also support the idea of taking the best of these improvements and porting them forward into lib sawtooth. That makes a lot of sense because maybe there will come a time where sawtooth 2.0 is ready for production, we're ready to be building serious applications on top of it and we would not want to lose all of these improvements that various members of the community have done to the system. So that's mostly what I wanted to say. I just wanted to reinforce that. Yeah, go ahead. I'm not proposing that any of these things go on sawtooth 2.0 at all. But here we're proposing a new library, sawdb. I don't support that just because it's more overhead maintenance and we already have a place to do that work, which is lib sawtooth. I feel like, you know, if we're talking about keeping that stuff in core, not creating a new library, then essentially it's, you know, would be adding some technical debt if the overall direction is to try to separate that stuff out into a library. So what we're proposing is that we start to see lib sawtooth as a Rust library that's used by version 1.3. So there are pieces of things in lib sawtooth that we wouldn't want to adopt for sure, or not in its current form. There's a lot of, for example, there's transacts in there. And the, well, that's great. It doesn't support transaction processors currently, right. So ignore that part of the library. But when we're talking about the back end for doing the merkle tree stuff, that's that's an easier piece to separate out and say like, okay, we can as a group create one implementation of that and collaborate on it moving forward. I'm just suggesting that the place to do that is in lib sawtooth. It's a library. I don't think that's as controversial as it may sound, honestly, the what we have as an implementation of that already it's already a separate crate just happens to be inside of the sawtooth core library shouldn't be that big of a deal to lift and shift it out. But if there's stuff already there and also shouldn't be that big of a deal because everything's already by a trade to migrate over to it and then have it be supported. So I don't think that's that's not really a problem. And the changes that you've done to the Python code and stuff like that are probably things that we require to do that that transition generally right to adopt the sawtooth will be very similar to what you already have. The details would be and okay what's the trade look like. What are the changes between what you have and what's in lib sawtooth, and that would be the activities is reconciling those. I'd rather see collaboration between the group. Then not. I think, you know, we've been very fragmented in the past where where we do have some activity that's not been brought into the project is we're kind of all working separately. I'd like to see, I'd like to see that change moving forward. And if that means, you know, a greater focus on the 1.x code base. Then, yeah, I can support that. That sounds good to me. I'm not a technologist when it comes to the actual collaboration based on the contributions and so on but it does it does feel like if if there's a way of collaborating where we can bring in or at least propose some of the changes that have that have been made and are actually in running in production elsewhere. And then have a sensible conversation about, you know, how that works practically speaking with what's what's available through sawtooth lib. I agree with them. What Bill was saying, which is, you know, we have something that today we know works and has had a lot of improvements and we'd love to see those improvements find their way into the 1.x arena. And then obviously have a sensible collaborative discussion about, you know, the pros and cons of one approach versus another or whether it is that big of a deal. So, may I? Yes, please. I don't know if I was holding on to commenting this for a while now. So it looks like everybody is willing to collaborate on what the features site at least that's clearly evident from the conversation that nobody is saying that we don't need certain features. It's just matter of reorganizing code and which library to put what kind of creates and all of those discussions and I'm sure like these things have a logical ending. If we discuss it through, like, if we take this upon a separate call and then discuss through there will be logical ending into these conversations right now. And there is also a general agreement and other sense that I couldn't see on this call is that the collaboration is is I mean at least the proposal that I hear is that you want to put down the code that you have with you. Right chains and will and Kevin maybe and like you're willing to support it on a longer term basis and through maintenance and that support is not necessarily just restricted to that version but rather it's forward looking in the sense you're willing to collaborate for the future releases that like the current maintainers have vision for and of course there will be arguments in few cases that hey this is already implemented in certain way. Should it be read on or should we model the feature that you have and change a bit to adopt our version right so those kind of conversation do happen at the future level. I'm sure there will be logical end to those conversations as well going forward and that will be an ongoing basis right. And I don't know it's just a thought process. Can we think of a mechanism where I know some of the other projects have to release approach rates or for instance I don't have one or two. They are changing the language of implementation and some of the production systems are continuing to use one where they work on to and this plan for deprecation and there is plan for migration of features and all of all that. And similarly I know some of the other projects they do to release us within the project itself in an incremental feature release fashion. Right so they say maybe like release one dot something does not have certain features to dot something has certain features but they differ they are breaking changes. And we do have come the core set of maintainers supporting both releases. These are just suggestions from different projects but we have been saying now. I mean since on this call there is a general agreement and I don't know maybe Sean this question to you. If something like this works out for everyone is that something that you can think is doable. For instance it's it can be something like one dot two dot like one dot two dot alternate release right does not necessarily need to be a one dot three something. Because one dot three as you said, you want to more adopted to sort of library. So it could be one like branch derived out of whatever is the branch. That's what one that's what one dot three is. I'm proposing a path forward that I think, you know, if where I think we can collaborate the best in terms of focus around you know any an existing area based on work that's already been done. But that we collaborate and not kind of fork off in different directions. It's not that like, I guess I don't really support. The idea of like one dot X and two different maintainers sets. I think that's too complicated for the amount of interest that we have generally in sawtooth that feels very, very heavy weight. I think it's if the interest here is to further one dot X then that's where we then that's where we expend the effort for for this group. I never proposed that we have to maintainers. Sorry, if I interpreted in that way. I thought that was your example. Oh, no. Okay, maybe I was about example then. So I was not proposing having to maintainers like the maintainers site would remain the same, but maybe for one dot X, the features that you're bringing in will be adopted. And of course for later releases, there will be improvements done based on your suggestions, which James and the company will spend efforts towards right and it will be eventual effort instead of the one go effort initially itself. Well, I think there's, there's a few things that are kind of commingled in there. One is I think we need to kind of expand our maintainers a bit. But to we need to have people answering on questions that have come up because I think the questions are pretty much dribbled to a stop because no one's answering them. I think that's one of the main issues. And Bill and I haven't had time in order to answer them. But we need to make our effort to make sure that we answer and bring that forward. We're hoping we've been in using government grants for the last four years working around saw tooth. This time we're working on a commercial version and we hope bring a lot more people looking at saw tooth. Because Hedera actually needs a back store in a bad way and if we can actually launch it properly that would make saw tooth the back store for the Hedera consensus service, which would bring a lot more people into the project but if no one's working on it if no one's contributing. So instead it will stay dead. So we need to start living it up both with contributions, but also people answering questions and it's not a thing on you Sean or anything else because you guys have been carrying the mother load of that for the last several years but all of us need to step up and start answering some of the questions quickly, because the speed of answering those questions. It keeps people involved and who knows where the people are coming from for a while they were coming from extremely large companies looking at it. I think they've kind of faded away. And I think there's a lot that saw tooth actually can offer that nobody. Other project and can offer, especially my consensus and and the fact that it's segmented in, in a lot of different ways so you can really adapt it a lot differently than any other project and you know splinter takes it even further than that. But I think the short term problem is we need people that are, we need more contributions we need more people to answer questions and we need probably another maintainer or two that can step up and be helping besides Sean and VTP, or bitwise I'm sorry, being the only people working on it I think we need to expand ourselves beyond there. So that was the purpose of this call from my perspective is to get interest back to get us working on something and then start scheduling meetings so that we can start hitting this on a more consistent basis than we have. It sounds like, you know, Kevin is willing to do that Sean sounds like he's willing to do that I know Bill and I are to the extent that we can. I don't know if there's other people are willing to step up that are not in any of those three organizations or are not. I don't think we're going to solve the problems here but I think we're going to get a good head start on there. People have other comments. I just to throw out I brought it's not just me from the events I brought three people on this call and we're going to be doing the contributions actually from us forward but it's also I'm volunteering them. If they haven't realized already that they're there to watch the saute channels and either try to answer the questions or tracks down people that can do on the discord today so we're cool for our hands and that as well. The list of like maintainers. I agree we need more maintainers a lot of the maintainers that we have on the list. Probably won't contribute in the future. If I have my guests so the list of maintainers is of active maintainers is fairly low at the moment. You know, the best way to become a maintainer is get stuff merged in. You know we've discussed adding bill as a maintainer to the sawtooth or the subject go SDK right which I support. You know that's easy, but it's easy because there's contributions. And so I would just expect that problem to solve itself as we start to merge some of the stuff in. Where if the discussion that we're having is one of, you know what, what threshold metric do we use before we make someone a maintainer like what how many contributions over what period of time. And that's the discussion that we're having I think we're in a better place than, than we are now. Because because that's the stuff that we can discuss as a community and make decisions around. Well, I agree I think that it's going to be based on what contributions come in and how well people are working on it but I just, I wanted to push that out as something needs to happen. And I feel bad because we just haven't been as active as we'd like to be because we've been slammed with other other stuff on there but I felt the need to try to see what I could do to ignite the community. And it sounds like we've got at least three companies for a fund here. I don't know where everybody's from, but I'd like to have a 1.3 on the discord, if we could. Because if I go into the discord that we have now I'm going to lose it on here but if you look fabric has 10s and 10s. And all of these have 10s and 10s of stuff but we don't have much going on in terms of sawtooth. And we got announcements contributors and basic sawtooth. Maybe we can do one on 1.3 and start there by adding yet another. I think the channels are dormant as they are I would actually go the other way so we don't even have enough chatter for one channel. Yeah, but for two channels right where we should go down to just one sawtooth channel to your point about monitoring and answering questions and stuff like that and like the channel feeling dormant that's because we have too many channels. At the moment, for the amount of chatter, because it's one thing if someone asks a question that isn't easy to answer and it scrolls off. And another thing, which is what happens now where there's not enough discussion in the channel for that to ever scroll off. And so the question and there's a time period where it's like, there's not enough discussion, generally, to warrant checking it every day and so like to check it and it's like, oh, that was maybe even easy one to answer but you know it's, you know, it's been sitting there so long that the person probably isn't really looking for an answer anymore. So part of what we can do. I don't think more channels is answered because I don't think more dormant channels is impressive we don't, we don't currently use the contributor channel very much. You know case in point, none of this stuff was discussed on the channel before the meeting. So that's, you know, that's a sign in and of itself that like, you know, we're not really using the channels in the way we should write. It shouldn't be a mystery when we meet what we're meeting about it should be like we're meeting because we have to have a discussion and stuff that like we've been discussing async, and we want to synchronize touch point where everyone can very quickly get on the same page. And maybe make decisions, but really the primary method of communication really should be discord in my opinion. These meetings are great, but only so much as they coordinate up things that that we otherwise are are doing I think. Yeah, I wholeheartedly agree with you I was kind of surprised when I put something up and nobody really said anything on there. I'm just trying to get things going and get us discussing it. Go ahead, Kevin. Just not to have the discord switch over which is not this project fault was a bit disruptive so we basically didn't follow along with it. When I went through it so that's part of it I agree that we don't need more channels. Let's fill up the challenge channels we have already. Before we start breaking them off. That's, that's all just sensible what that's my principal concern is. I believe that that's the flow of changes has stopped I also believe that there are more folks than us out there in the world that have interesting things that they've done with the, the collection of soft tooth projects that we're not getting basically just because the focus is shifted, or had shifted elsewhere. So if we shift back to get them coming in could be my foolish optimism but I think it's a good optimism. I think we'll be in better shape. Yeah, yeah, absolutely. And I think that just starts with us, the other people that are on this call chatting, because chatting there because, you know, that if we do, if we go through some of this stuff, you know, we can talk about these traits and go and go back and forth and you know, maybe compare the traits and put a branch up to start discussion or, or whatever, and like just kind of just get into it. I think the people that that are lurking that won't say anything. Sometimes if the channel doesn't have enough traffic people will not say things because they don't want their comment to be the comment that's out there for for a month, right. So if we, we liven it up ourselves. My theory is that like it will just become more active and not just us because there's more people on the channel. And I'm an agreement I think these things that I put out there just as just a staking ground should be taken to the channels. I just want to make sure there's no high priority bugs or issues we need to talk about now, or they should be able to be taken to the channels. And I think the, the other thing that I wanted to get out of this is, when should we schedule the next meeting. And I think a month from now, we can see how well actions are happening on discord. And we could schedule it out far enough that people can put it on their calendar and make sure they can make it. Even that if we can throw throw some dates out there. And we could, we could even use that discussion as a way to generate traffic in that channel. Hey, does this date work. Yes, because like today work. My preference is it would be an hour later. Yeah, if that doesn't work, you know, it's just I had to get up early to attend this meeting, which is fine. If that's the only time that works. But if we coordinate the time in a day, then we can make sure that at least when we when we plan it that it'll actually work for us. Let's let's put that up on on the channel. I'm 99% of the time I'm mountain time so this would be 7am my time start pretty early. So I was trying to get something I could attract people to so that being said, do people have other comments on what we should be doing, or should we take you to the channel and just start seeing what we get back. I'm trying to keep it in an hour. And we're at 47 minutes now. I think I have one other question which is, you know, we're talking talking like one of the things that historically we've put a lot of effort into. It's on my mind. Quite a bit lately but like the you know we're talking about one dot three. What's the importance of releases versus just being in the branch. I'd like to get a sense for that, doing the releases of that one dot X code is a non trivial and extremely time consuming. And so I have two questions one, our release is important or are you forking the branch anyway and so so releases aren't aren't aren't all that important, or are they important. They're important they're important for like maybe community wise but but I'm curious. For the people here how important releases are. And then whether there can be a commitment to help with with some of that. Maybe CI release management stuff. So I can give a sense for whether people are willing to contribute I guess is what I mean. So I can give a pretty detailed description of the good and the bad of that actually the from the standpoint of this is BTP as all do we care about the hyper ledger Docker images tag releases, not particularly but that's because we build our own. Because we have different enhancements around the image and things like that and we're running off of a fork with our enhancements already great. That said, the so from that standpoint, the we don't super care about the formal release process up there, however, because the version number is so wired into the build. In a lot of places, and so many places actually the tagging of the release is the most important thing for us. We also throw in just because you threw in the CI thing like we run all separate CI and we build publicly actually the both the main lines and all the standard branches and also our release branches on a public Jenkins already. So, I mean, we know the ins and outs of it very well. The, in terms of a source only thing obviously that's what you do with the Rust libraries really the binary stuff. I don't know there's a it's a wider issue around the build actually and what to do with the bills. So, I guess, given given that information I would say I could go either way on that question. It's more about the being consistent about what it goes all the way through like there is another conversation I think in the last POC TSC update around the Docker image builds. And again, it's I can sort of see both sides of that in terms of, I think you had a back and forth with a room Sean, but little back and forth tiny if you don't remember it's not surprising. About the building in Dockers versus don't building in the Dockers and that's honestly something we struggle with both ways. We tend to focus on the building by a Dockers just because that gives us our guaranteed product at the end. However, it's annoying to have to do that all the time because it can be time consuming. It's it's a big it's a big discussion topic actually is what I'm saying it's a good collab discussion topic. The versioning itself versioning of the tree I think is important just to go back to known sets and the validating out the CIA CIA's and having knowing that everything runs to a certain good step is fine. If you're referring to the weight of the release that you're thinking of like those those long run tests and things that we ran previously, or just just the build and pushing out and publishing and stuff. Because I don't think we've done a long life test for quite a while really. Yeah, and that that was maybe the majority of the effort for one dot two is the, the extent to which we tested it before we put out a release. It's not in a position to do any of that testing and future releases. Just because we don't have that environment set up. We have. We probably have some terraform and stuff for recreating it. That we can share. But. And this is this is why I wouldn't want to put out another one that too, even with minor changes is that I think like, it would be hard to test, like, like we could if there was like a security thing or something, you know, we could push that, but let, but I mean like, you know, anything substantial. Whereas one dot three. Well, at least we didn't break one dot two, right. Yeah. So that sense of, because there's definitely a lot in one dot in one dot three that, you know, when we, when we work on the the pluggable Merkel tree stuff. Right. Does that introduce a memory leak. You're not going to know if you don't do one of those long running tests. I mean you might find out in your production. But that's probably not the place you want to find out about it. So it's stuff like that that like that I would be concerned about in terms of kind of the lack of that that currently for the one dot really want to just version one branches in general, because it's not set up. Well, let's have a look at it. Honestly, see what the long running tests are to see what we can do with it. We have infrastructure we can perform probably get stuff from hyper ledger to one of the if we got it settled but we can certainly put together the foundation I guess gives up the stuff that we can put together the whole run. We have a sort of priority on making sure that anyone that does anyone that uses uses our forks of everything not just saw to they have to be able to run it all themselves so totally happy to work with that and put it out and make sure that kind of anybody can inspire up the the long run tests would be the goal. And so it's a bigger thing that we can answer in this call right but it's but absolutely. We have a bunch of tools as well for like running those networks that we're a little too specific to check into to check into the subject itself but you know whether whether that stuff is interesting or not. I don't know but like CLI is for spinning up entire networks and running running tests and stuff like that. With like a CLI with like tool with terraform underneath it and stuff like that. So that that exists. We can. Share that 10 minutes willing to kind of take that. Also got on if if that's interesting. Maybe you're already set up to do enough testing. Maybe yes maybe no I don't know what's the. We tend to focus on home chart so we're a lot of our stuff. And so far proprietary stuff that we have is all home chart based home chart basis kind of hard to say proprietary really but the we're not too far off open sourcing that stuff as well. So we can probably take those and maybe take some of the sex specific stuff out of that. That's anyway that's just another ingredient that we can possibly take use of we're very Kubernetes focused everything for us is always going to run. The point is it's a it's a good active area to talk about. So let's let's do it. John did you have another thing you wanted to bring through. I was going to say in terms of like the my comment about getting rid of Docker. My plan to start with. With sawtooth and just simplify that. There's no reason to use Docker in that in that context. Well it's a rust great right. Yeah it's a rust great right you don't need to. Exactly yeah right. Are you some Docker didn't you know kind of grew up from the one dot X branch where you know we were trying to solve the problem of having a stable Python environment. So Docker actually makes a little bit more sense. In one dot X than it does outside that context. Unfortunately that that that doesn't. It's done in such a way that it's it's hard to get things built or working without it, even doing stuff manually so. That's the stuff I want to clean up. In terms of just simplifying it. It's really it's really it's really more about the CI stuff and kind of approach ability from a developer perspective than it is like the end result whether we publish the, the Docker image in the end, or not. It's like a completely separate thing, but just like kind of the maintenance of doing releases and stuff like that. Well let's take a lot of this on on the list and talk through it so that everybody can see what we're doing and how outcome we're doing it. I'm just trying to keep the call within an hour and get sounds good and then push it into discord from there. This is, I mean we've basically been the Kevin and Sean discussion here. Anybody else have thoughts questions. So, we're trying to wrap it up now. I just want to make just just say a couple things. The first is that Sean I'm definitely willing to take on that role of maintainer for the, the, the go SDK. There's really nobody else contributing to it actively except for us I don't think right now. And we have, we have a pulse on other small patch set pending. So, whatever we have to do to move towards that. I'm definitely willing to take that on. I'm going to take like two minutes to mention, you know, sort of not really not not so much as to make it a shameless plug is sort of to give an idea of why we're working towards these things with with sawtooth so we're working on, essentially being able to put sawtooth in the role of a public permissioned blockchain. Right. So instead of just, you know, solely enterprise with solely, you know, very carefully controlled consensus like PBFT and and whatnot, we're, we're building an application that is putting sawtooth in, in the role of, you know, you have a number of validators all over the internet. Membership is still controlled and permission like some of the other the big, big block chains, but that we're able to handle sort of a throughput of a chain deployed like that. And I do want to mention that I've been working sort of closely with Kevin over the last year or two with maybe a little bit more with his updates to sawtooth and moving over to RocksDB his various other optimizations have made a huge difference in stability and the throughput of of sawtooth 1.2 line. And it's sort of that work is really part of what's making this current application that we're building, even, even possible, because there's, you know, there's some things in sawtooth 1.2 that, for example, dependent transactions are actually really broken under volume is just an example. And that some of that stuff ended up getting fixed indirectly through work work Kevin has done so I just wanted to sort of give an idea of, you know, where we're coming from with this and by the way the work on using the consensus service as a, as a global consensus mechanism is is part of that. And we do have that working today, you know, I'll be it in a beta capacity we're able to we're able to run nodes on the internet and using the Hedera consensus as a source of the source of truth for coordinating sawtooth and all that works pretty nicely together. So, you know, not so much as, you know, on the direct development side but but as a sort of a testimony to the work that Kevin's been doing sort of the feedback loop that we've been sort of running as far as us testing it out very thoroughly and his improvements. So it's been a positive thing and I think that, you know, sawtooth really will work well in this role, especially, you know, with with some of these these changes and fixes and improvements that are that are, you know, that have been worked on. And, you know, if if if if our if our current project succeeds it'll actually be a really nice, really nice bunch of visibility for the sawtooth project in general. Yeah, and we're going to contribute that back into the project once we have it kind of the Hedera stuff. We're we're we're about to run sort of a pretty big test and you know if it survives that we're going to we're going to contribute that back as a sort of a new a new a new consensus projectable, you know, point everybody to it. Yeah, that's contractually part of our contract with Hedera that we open it back to sawtooth but anyway that that's just an aside. Yeah, practical note with that. I remember you talked about it on the rock and chat way back when Bill, but did you open up and publish your in key test that your your performance driving test. Oh no but I should I really should. So if anybody's not familiar with Bill's got this driver program that that's fairly configurable it is is pretty mean test of sawtooth when it goes through so it pushes things pretty hard and raises things so it's be good to have that in the toolbox. And it actually it actually you know, it can actually bring almost any sawtooth one dot two mainline build to its knees within about within 20 minutes, because of the dependent transaction bugs that I that I mentioned. If you if you set up a dependent transaction test, it basically kills production sawtooth. You have to be reboot all the notes. How long does that take to run well 20 minutes you said right good but yeah less than 20 minutes if it's if it's um you know it less than 20 minutes sometimes it happens within five minutes but it that there's is a bit of randomness to it. But it usually kills probably your your builds don't die right but the but the main but yeah we should bring that chat over to after we push it out bill let's let's plan on pushing that out. And then the people have any other questions for this or runs dropped off I think Ryan's gonna have to. Right it's gonna have to drop off in a sec so we're going to need to drop. Anybody else have any parting thoughts. No. Well thanks and hopefully I just I wanted to spark conversation and sounds like we're well on our way. So let's see what we can do on discord and then we'll plan another meeting from there. And thank you all for for showing up. Thank you. Thank you.