 You have four okay, so anyone's not familiar with it already there's the antitrust policy and the code of conduct policy if we review it and make sure you follow it. So, just following the, the basic agenda that I put out last time and going to run through everything. So first step is the review of what we said we do last meeting. First was the TOC update. Thank you, Rye for finally actually submitting that for James. The, the outstanding questions I took a quick look through whereas both of them were like grammar and spelling things. I think, I think all the sort of substance and issues have been reports, but I will take another look at that night. What is the in terms of the process is like it has to be a unanimous improve. No, no, usually it's two weeks after submitted. If there are any outstanding questions. One of the larger outstanding questions was the maintainers list is way out of whack. So that's Peter is also on the TOC so I'll let let him speak to that but Peter was there anything else that you recall from the last to see meeting about that. Yeah, I think the someone, I don't remember who it was, but someone brought it up that it seems not very up to date that there were people listed as maintainers. We haven't done anything on the project for maybe six months. So I think what they were saying is that maybe that could use an update to double check who is still actually active as a maintainer. Right. The, so agreed. The certainly to be pruned out. I think the question a little bit is whether anybody needs to come into as replacements. For stuff. The principle sort of active maintainers really are are Andy yourself and gone right. And I haven't seen really many of the others from the existing lists go through and do active reviews emerging. Yeah, that's pretty accurate. We have in the past. When someone has asked to be removed gone through and sent out emails to people to ask them if they wanted to be removed so there's some people on there who have actively said they wanted to stay on, and sometimes pop up the example of that is like Sean Montgomery, who was very active in the project originally, but we haven't done that for a while. Okay. What should be the process we deal with that in terms of should we go and do that again, or should we just take it by the rule which I mean there is a rule right with of so many months in active you're supposed to be retired and then should we go through that process again see if anybody wants and actually probably better to actually set up the emails and just take them and try to get them more involved again or explicitly out. I think he's give one more shot. Yeah, so I just wanted to say, Sean is unfortunately on vacation right now. He's not on the call, but we had talked about going, we have the maintainer rules in the such. I forget what repo it's in the RFT repo. RC. Yep, that's it sorry. Not fully awake yet. And we had talked about going through and revising that to not only make it easier to know when we should retire people but also make it clearer when we would move someone into maintainer status. Both of those have been, it's pretty like up to the current maintainer group so obviously as the maintainer group has gotten smaller that has become a little bit more unique since we haven't had time to really deal with it recently. So that's one thing is make going into that and updating the rules so they're really explicit. It would also help us get new more maintainers from the perspective of, it's very clear what someone would need to do before we could make them a maintainer. Unfortunately, we don't have that yet. What would be the next step just we got to wait for Sean to come back to have that discussion and put it forward or is there something we can do now. Yes, that in terms of moving or moving things along. When it when is Sean do back. Next week. Next week. I do collect stats on maintainer activity. Actually, I collect stats on all activity. So it's pretty easy for me to get that data. I can do it again. So I'm putting down because I'll make sure to update notes for this so we need a reflection of the container rules. We need to do a poll of the existing maintainers. One more thing that I can recommend is. If someone wants to stay on, but they haven't done anything in a while. Then you could make them maintain or emeralds and just list them in the same document but on a separate list so that way. They do get the credit for life that they've been putting work into the project, which they should. But at the same time it's not confusing it doesn't look like there's a bunch of maintainers when there isn't. Yeah, I actually had a bunch of pull requests to do exactly that. A while ago and they were not received well so. I would like it if instead of removing maintainers inactive ones were moved to emeritus. And then it makes life a lot easier. I would prefer that to right when I see a maintainers list I expect somebody actually to be here taking a project right. Yeah, and then if you keep their names on there but in the emeritus list. I think that's a very reasonable trade off that they should be everyone should be happy to make. There's their name is still in there, but they're not anymore actively maintaining. So, if it was me, I wouldn't bother too much with the poll leader to be honest, I would just look at the stats and I would say, I think there's a reason to go and. And he's contact everybody to see if they're willing to come back into the fold. And get active on it and maybe even just give an update because it's entirely possible that they just haven't been paying attention to what's happening here. But I think I think it's still worth the effort to go around and see if anyone's still interested in going. If you have the time, then sure. Time is there to be spent. Okay. The case that's the previous report that the next update is due to lie. Try to do better this time. Is it due July or is it due to August or is it due to, is it already due? You know, I would have to look at the. The last one was for April. So quarterly, so I would assume July. Okay, so. I want a volunteer from my guys to help me with the POC report. Or anybody else. Because I have a feeling it's going to follow me to end up doing it this time. Mark, you want to help me out with that? Oh, it's basically just a poll request of a markdown document against the, against the TSE just to say what's been happening in the project. Okay. It's very formulaic really. Okay. So saw tooth is July 27. So last. So the question is. The main thing I wanted to sort of emphasize is in terms of that we've messed up last time is that we just sort of dropped the ball and took too long doing it. So I think this time, mainly I just want to make sure mark you and I will carry it and make sure it's done. Anybody else just welcome to participate of course. My suggestion is that I'll put together a little bit like James put together a markdown document or a, or a Google document posted into the discord to see if anybody has any other input before it, like a week before so like on the 20th. It's do if anybody has it and then we'll submit the PR onto the TSE of the 27th. Any other suggestions on what we could do better there. Let's go on to the fun stuff. Joseph. You did you've been doing some work on social poet and what's going on there. Why don't you give a summary of where you've gotten to. Sorry, I was on mute. Hi everyone. So I, the past since we last met I've been looking into sort of poet mainly prioritizing the user issues that have been reported on the discord. And I've been the kind of outcome is a PR that I've opened in the docs repo which tries to point the, the guide for the creating a sort of network guide which is one that's people seem to be having a lot of trouble with. It currently points to the YAML file for sort of poet from Maine so it's pointing to nightly images and I found in my tinkering and sort of extensive going through that guide that I that it works. It's annoying to say it works on my machine right but it, it does work for me if I am pointing at the chime images so I've opened a PR suggesting that we point to the 1.2 version of things that in that particular case. And otherwise I run our BTP CI checks on sort of poet and they all passed no problem. And I've also used the poet consensus at the back end of our with one of our products and and that works fine as well so. And that's kind of the current stage and then does further the other questions that we had about the algorithm and the build and stuff like that that's a kind of longer term research project that I've got sort of on the back burner. So that's where we are with that. So these CI builds on the, the sawtooth me site, are they actually still failing with, or they so run fine at ours but it's got to run on the main one. Is it just need to be kicked again and maybe everything's fine, or is it. You know, I don't know. Looks like the builds on this PR I just need to approve and run them on the, and they should kick off. On the docs one. Yeah, I think just thinking of the actual sawtooth poet, I think that would kick this off was we were looking at the CI builds on sawtooth poet were failing, but they looked okay now. Correct me if I'm wrong, but I think at the last meeting, people pointed out that they state the CI checks seem to have been working working again. Is that right. Uh, looks the last valid bill was June 28 2023. So this morning, at least it's running now. Okay, good. So it seems to be kicking up. Well, from this it seems to be sort of occasionally failing the test, but otherwise going well for past month. After month. Okay. All right. Uh, then me long running testing. So the, this is currently it's got two parts. One is we're what I'm doing is basically putting together a good versatile helm chart for it. We actually already have it, but it's, it depends upon some PPP custom stuff. So I'm pulling that out. And then putting in a helm test method. So they can run that'll make it so that essentially you can run the test long running against any on any Kubernetes infrastructure and make it simple. And then we leave aside any of the terraform stuff. Uh, make good progress on that. It's more about the, the scripts that that we have to replace there are fairly elaborate scripts for setting up Genesis. And doing a lot of fairly custom stuff that is only relevant to be to be so that's that's what's got to be replaced. I might actually contribute. That basically simplified scripts there are exclusive. It's all two family stuff. To help that out. But that's ongoing. The next item we did before, well, we've had before was a description of the tool chain that seems to have lost enthusiasm. However, one of the things that keeps coming up in the documentation and the questions from the users is actually the Docker compose version. For two different reasons. One is that the that there is actually a difference in the interpretation of the YAML specifically around scripts that happens between one and two. And then, but all of our Docker composes are actually in a schema versions that can be theoretically can be interpreted by both versions of what I'm. What I've been saying, recommending is actually the real problem we have here is making sure that the all the Docker composes work on any Docker. All the Docker compose YAML should work on either work only on the appropriate version of Docker compose or if you work on all versions of compose. The problem that shows up is that the Docker compose version to changes the name of the containers which throws. Basically a underscore turns into a dash. And that throws a wrench into a ton of the testing framework stuff on all of the on all of the talk to score all basically every single thing, just because that run testing expects names to be formatted a certain way and they're just formatted differently. So we have two things I think we need to do. One is update the Docker compose schema versions where possible to make sure that they run only in the right version of Docker compose and be thrown error. And longer term update those run test programs so that they actually can handle the new names it's a minor but it's a minor. Technical change but it's it's all over the place so it's kind of irritating. So what I think there is the right thing to do here which I shouldn't ask for volunteers but to open up an issue summarizing exactly that. That makes sense. There is everybody understand what I'm saying there. And then the rest of the tool chain I think is in terms of documented rest of the tool chain I personally think is less of an issue it's which primarily about Docker compose. Any thoughts on that. So, James had volunteered to do scan the documentation for the raft mentioned of the raft consensus. I think James is off onto other things right now it's what's unlikely is going to come back to it but can mark since you're already doing documentation scanning for other reasons can you take this on as well. I could do that yes. So what remember what the goal here is what we're trying to do is is deprecate and eliminate the the sawtooth raft. So we're looking for it's just cataloging all the references to sawtooth raft and making sure that we either remove them or note that it's deprecated better so that we could clean up that. Okay, I can do that. Okay. I guess mark you want to summarize what you've gotten to where you where you're going through with the documentation. Yeah, I've been kind of. Well, there was an initial question actually which documentation to look at the Sphinx based stuff in car or the other stuff in the docs repo, but I've been working through them 1.2 documentation at the docs repo and basically it largely in order of how it appears. And I haven't noticed any big issues beyond things that we've already mentioned like some of the poet stuff wasn't working for me and there is a question about which versions of the composer meant to be using to get this stuff working. But, and then I've gone currently working through the architecture section I've nearly done that too. And I'm not noticing yet any obvious or big issues apart from the ones you've mentioned. There was suspect the real test will come once I get far enough to actually try using the documentation to make some simple client. That's of course I am so far and I'm very happy to continue with that this coming off. It's right to focus on the saute doxing that was a good call way back when to move the docs out of the individual depositors because the docs were causing dependency update problems are causing problems in the bills for everything else with the pain. That's to keep it separate. Definitely keep focusing on that depositor. Okay, great. In the comments on that for the next one. I should mention my plan is I'm just if there's also noted some issues that I want to note my issues before I look at what those if noted, but separately in terms of what to do about them I thought start to split them between things I can easily fix myself and things that seem quite simple things I can't fix myself that I need to get up a few about and then things that seem more worthy of discussion that I plan to raise in discord. Yeah, that's that makes sense. Put them up in different forums for different things that's good. Okay. With that let's move on to Ryan Roberts Palooza. Ryan this is around the. The first one was we were saying what the look up. Look at what the impact of just moving to post from the protobuf stuff in the subject FDK Russ what would it happen, what would happen, what would it break. So, yes, so we've done that for for our own stuff. And it is purely a syntactic change that's the, the way we're using structures is equivalent. So it's really going to depend on how people have, how people have used protobuf in application level code as to how difficult that might be. So if you use the decorative structural style to initialize things. It's pretty clean cleaner than you no longer need to use into and things like that. If you've used it if you've done it in a more imperative way and use the set methods, then it's going to be a bit more painful. There's how even in that case though it's it's a mechanic say it's a hands on keyboard kind of process there's no real way for it to go wrong. It's the types of equivalent and rest will make sure you don't get it wrong. It will ensure that fields are initialized when necessary and things like that. So if we've made this change would it would be, let's say to to people who depend upon the SDK if we made this change, it would be a breaking change but or would it. Yeah, it's certainly it's certainly a breaking change. But it is a it's a syntactic breaking change largely it's a relatively easy one relatively easy one to deal with and the types will the types will lead you down the right path it would be not silent is what you're saying right not silent basically just keep typing until the red squiggles go away kind of process it shouldn't be too, shouldn't be too painful. So if I remember right the issue here is about maintenance right the existing protobuf libraries aren't really maintained. Yes. Yes. Yeah they have a, it's not it's not officially marked. It's not officially marked in rest circuits deprecated but they're called for maintainers and there's been no contributions for for some time. And cross is what the seems to seems to seems to be where all the where all the energy is at and it's maintained by the Tokyo people. So, that I guess the next thing to do is to actually put together a PR there. That justifies why we need to do it. Right, just turn the description where it is let's let's put the PR and it will and note that it will require breaking change stuff because I don't have impacts into everything basically. Um, well it needs to be noted. I would depend on it go about it I think I think the intent is to release an alternative sort of SDK which is async sort of SDK and then shim that into sort of SDK where we can. I think we probably need to do both honestly. The just because they're just kind of from the principle of change one thing at a time. I know that the so changing the pros because we're dealing with the dependency issues it introduces a breaking change. Or the SDK, but the doing doing the Tokyo stuff one the Tokyo stuff isn't finished right. Yeah, the but the other is that it's a it's biting off a lot more of the cake. You're committing to you're committing to a rearchitecture of your code at that point as opposed to just syntax change. Bigger, bigger break is what I'm saying. So I think I still think it's a good idea to do the pros change, particularly if it's just syntax update, get the PR together. So that it runs through and passes checks, then we can take a point of view and have the PR there open and mergeable if not necessarily merged and then at the same time let's do the Tokyo stuff. Why don't you update on the Tokyo stuff as well. Yep, so Tokyo stuff. We have what looks like a version, an asynchronous version of the sort of SDK. So it has low level zone key primitives and it also has a high level abstraction for correlating block updates and user and custom sort of events. So that's at the state where we should hopefully be releasing it, publishing it before the before before the next time we speak needs a fair bit more work on the on its unit testing. We also have some enhancements to it over the capabilities of the existing sort of SDK in that it can connect to multiple validators. And there's a mechanism to be able to select which valid which valid which validator node you actually want to try to send transactions to. So that's a kind of a pluggable strategy pattern but by default it works on which one currently has the highest block number. So and that definitely that resolves a bunch of issues with the synchronous sort of SDK SDK if you're accessing it from asynchronous code which we've actually had endless issues with around shutting it down shutting it down clean when it's running and when it's running in reactors is quite quite painful. So I should hopefully resolve all that and it should be a lot more lightweight there's no synchronization, there's no explicit synchronization required to in any of its, any of its code, which is nice. And it all runs nicely without any additional friends. So it should be, should be a lot more, a lot more lightweight to use. And to address the comment on the in the last meeting, we have completely removed any references to open SSL and as well it should make it a lot easier to compile to to wasm anything else doesn't support open SSL. So how are you able to remove the open SSL? How do you do the signing or is it just using for envelope envelopes and stuff. Yes, just using it's, it's just using K256 and. So it's pure rest peer rest cryptography library. So, first step on that is getting that published when do you think you can get that published out. So once we have this, while we can, we can, as soon as we have the better testing for it. That should be publishable in the next week or so I can't imagine probably that. Obviously, so even the work that you're doing with getting the stuff working is probably better to get it sooner in the open rather than later so the folks can look at it. Yeah, because the plan is to get it open and see what ideas can either be taken over directly merged into the SDK or incorporated basically open the discussion, right. Okay. So that's, so, like, even the work you're doing right now, better to switch it to do it in the open on the repository publishes and there we'll bring it up. So basically do a stark start a start the discussion around the change because it's quite a, it's quite a huge change. It's a very good change I think but it's, yeah. Yes, yeah. Yeah, particularly the stuff around the our ledger abstraction is possibly more controversial and the low like more controversial than the lower level stuff and it's not necessary necessary to use it was. There was a common pattern we've rediscovered in our in our integrations. Right. That's that's the deal right is you also you never know what's controversial until you let the other people look at it. Yeah, that's what you. Okay, that's a review that was a bit long. I think we can close out some of the stuff and get more specific. Next time. Any other questions of old stuff that I've maybe forgotten to include I went through all the previous meeting notes, if not, let's go on to the housekeeping. So, just want to do in terms of housekeeping there are three, two main things is CI jobs I don't know of any jobs that need kicking from the CI to get them to rerun anybody disagrees with that. If you know, or let the people know on discord and get it kicked the DRs that are open, I went through and listed all the ones we have the the just going from bottom to top there's the Java SDK updates these are just dependable updates. They actually need to get looked at real quick to see why it's failing. So, I'm volunteer for that mark I know you're a guy as well. Take a look at it there. It's actually the same dependable update and two different spots. It's for some of the test programs. It's just it's just a, and I remember with the dependency. It's pretty, pretty trivial stuff. Joseph, your PR PR 200 on saw two docs, which is about the one to poet that still needs reviews. Mark, you have a PR on SDK rust, which is the free after use this looks like it's just about great. Yeah, just the security. The previous version. The rust sec. Yeah. It looks fairly controversial for that also needs a review. There are three in salt to score. What is the just based GitHub build action, which I personally don't find controversial strong actually put it through as I recall. So, but that still needs review and put in the. Another thing here, this is an update of the saw to poet thing. I think this is actually, this is the syntax thing actually from the doctor compose may actually throw in there. But otherwise doesn't look fundamentally particularly controversial. And the last one I think is maybe a little controversial, which is. This is the arm, the build on arm dependencies. I don't believe that I think this builds with that thing because it's not doing the build on x 86. The, I don't know, I don't think that this is, I'm surprised that it only took this to actually change because we've tried to do this before. I'm surprised that it took only these changes to get it to get the whole thing to build on arm. There's a lot of other support tools that aren't being touched here and they definitely have problems. I believe the reason this PR is still open is Chris was planning to get back to it because it's not complete. Like you said there's still issues. It builds but I don't think it actually runs at like locally on arm. So, Ryan you were doing. I was just going to like, agree that I don't think this PR should be merged. It should maybe be converted to draft if we can, just so we don't lose the work but I do that I don't have to. I probably can. Yeah, maybe put it back. But I was going to say Ryan, you've also got a PR and one of our repositories trying to do this, this arm build stuff as well, just for comparison. Yeah, it is as far as I understand it, purely to do with Python dependencies and the, they're not being supported on that particular release of Gabby on arm. One of the things I noticed when doing the overall rebuild the way we do it is that's there are certain there are certain Python packages which actually are not published up on tip and they're only on. They're on the repo softies me as devs, you know, see how to build I ended up actually our build I end up reworking them. Rather they are on pit but there's no actual published wheel for them so I had to go. But what do I think the install installs a dev that's being pulled from repo softies me and that dev is not actually being built by the softies core, nor any of the other SDK packages. And I think it's actually the sec 256 stuff. Yeah, yeah that is that that that that is an annoyance because it's that the one that is where gay is that the one that's actually got the problem that isn't built for arm or is it a tip level. That is that that is an issue. Yes. Yeah, on that on that version of that. What would be better is if we could actually eliminate the Python dependency for that bit of code right because it's because if you look at it like the the softies core doesn't actually have all that much dependency outside of the SDK. So it might be worth going through and trying to eliminate those little bits of thought to this to Python saw to SDK dependencies in favor of what's going on and saw to SDK rust. And then maybe this becomes easier, the arm and also just the sort of dependency spaghetti that we've got. I guess there's no reason that couldn't just be re exported from the rest SDK and call from Python rather than. Well in general on the core right it's better to have a dependency on the rust SDK than it is to have it on the Python SDK, in terms of just qualitative judgment. Okay. Let's go that was maybe we'll throw in the link to your PR that you've got open on our side, which is not official obviously not just to compare and contrast. All right, I am now calling for. So that's the housekeeping and go through that sort of basically every meeting I'll go through and do those lists or I don't know we'll go through as exhausted. First time is always the most expensive, but now on to community care and feeding. Thank you guys who have been doing answering people's questions and stuff on discord. Everybody agree that's helpful and it's always good. That said, I'm not a fan of looking at issues but personally which is why they tend to go along with the truth. But I went through this time and looked at all the issue counts and go through it and what I'm looking for our volunteers to help triage and see what's going on with those issues. There's quite a lot of them that are if you take a look at them some of them are sort of plans ideas some of them are bugs. Most of them are not. Quickly speaking about some of our questions. Can I ask actually, I don't know if anybody wants to be particularly point man for going through issues but can we, we all sort of make an effort to these comment on them and get familiar with the issues, or some chunk of the issues. So we can decide what to do with them. That makes sense or is there a better way about that. My guys. In case my guys didn't buy wondered. I am actually volunteering you go through the issues and see what's what. Understood. Right requests for the computer requests from the community or orders for BTP. But I'd like to go through those. One of the things though is what we don't. I think the, I haven't even looked at the, the, the bugzilla that was on this for a while. I'm not sure we necessarily want to go back to the bugzilla and using it because it was sort of intentionally moved around, moved away from a long time ago. So, I'm thinking why don't we just focus on the issues in which case then don't we need a set of templates and what they're sorry labels to triage them. And does anybody know a good example of them. I know like the Kubernetes core and things like that for instance use labels to triage issues and basically just are pretty native on to GitHub. Anybody have any thoughts about that. We haven't to date done that any kind of labeling like that on the thought to stuff. I am pro labeling pro labeling. Yeah, you know what I'm saying like like label for triage this needs somebody needs to go look through this then this is cool this is dead this is fail that kind of thing. Okay. Yeah. Well, there's a built in ones. I'll, people can look around for a set of labels on this. There's a standard GitHub labels but I don't think those are sufficient. Let's look around for a list of labels, we'll bet around on discord what they should be. And I don't think I can think they're controlled on GitHub as I recall. So I don't think I can set up set them up so Andy, you can help us out with that and we'll just start using starting on issues I don't know so much on PR because we've got controlling bills on labels. Yeah, just a note for people are going to be looking at issues if I Peter or Sean added it they're probably just stories that we had in the backlog on JIRA. That we moved to two different reposts because we stopped using JIRA. Right, I did remember that okay. That's what I thought it happened. Okay, and then that's, and then those stories become things that people can pick up them, or evaluate whether they're still optimal and if they are like people can pick them up right. Yep. Cool. No. So, any other ideas, contributions, things that people want to throw out there once going twice. And open discussion if anybody wants to talk about anything else they want to do. The last is anybody like me to run this meeting differently. I'm happy to take suggestions. Also, would anybody else like to run the meeting, any other business. I will update with my notes and public afterwards and let everybody, anybody can comment on the confidence about what's going on. If they disagree about what's happening. Once going twice, three times. All right, thank you guys. Bye everyone.