 So welcome everybody to the May Sawtooth contributors meeting. There are two rules for all Linux Foundation meetings that I need to remind you of. One is the antitrust policy notice. This is a safe harbor for competing companies to work together. So no antitrusting. The second thing is we have a code of conduct that we take very seriously. If you feel that everybody is welcome and if you feel that there is a breach of the code of conduct, please reach out. Let's see. So if someone else wants to jump in and talk, this is just a copy of the previous meeting minutes. So if someone wants to jump in and start editing, I posted a link in the Sawtooth channel and we can just collaboratively edit this. And Kevin, I see you've come off mute, so I'll shut up and let you take the floor. Yeah, I'm just, I am happy to do it. So items from the last call was top of the thing was quarterly report. So is it just a GitHub PR request that you need to get done, James? Or is it anything else? I think the report's done. You okayed it. Sean never replied on there. I was waiting for him and I forgot about it. I've been waiting for him a couple times and I don't know if Andy knows anything on what's going on there. I think Andy's the only one from Sean's company. I looked at it. I think it's fine. I don't know if Sean ever actually looked at it, but it's probably good to go. I would say just do the PR. Okay. It gives at least one more opportunity to object. So okay, the main branch, we haven't done the switchover. Sean and I didn't get a chance to talk about that, but I don't think it was any major issue too much other than the selections of the patching stuff, which is a little bit of a separate issue. However, the default branch is now to one three. So that's, as I see from the PRs. That's at least part of the way through. I'm just going to rattle through and say either ask or give what I know about the statuses. Number two, the poet consensus stuff. So items, the main takeaway, I think was that, Joseph, you were going to go and take a look at looking at the code and cleaning up the documentation and running it through. I know you've been poking around at it. You want to just give a summary of where you got to and what you still have to do. Yeah, sorry for any background noise. Yeah, as Kevin said, so day jobs, et cetera, but I've got to sort of poking around through the tutorials, which was one thing people were kind of complaining about on the Discord and just running through those myself. And yeah, I can confirm there is definitely an issue of poet while the PBFT stuff seems to work. So yeah, I'm going to continue working on that. I had a question. Actually, I'll come back to new items in a second. Go through the old stuff. Raft decommission stuff. James, did you get a chance to go through the documentation? No, I have not. And remove, what was this? Remove mentions of what? Oh, remove the, oh, decommissioning of wrap. Make sure we go to identify where we're referencing and decommissioning. Okay. Do you actually have time to do that over the next month, James? Yeah, I will get that done since I promise to do it. Make sure I get rid of any wrap mentions in there. Or even just to listen about where they are. Yeah. Okay. Once we do that, then we have the work slate of what can be done, what we have to do to make an efficient decommissioning that and just all the places that we need to touch and advertise that. Okay. Long-running testing, that's me. So the, what are we looking to do is actually contribute forward our helm chart that we use to, our helm chart to use to install sawtooth, the, which can do it with all the different consensus stuff. The thing that's holding up that is that it's actually wound up with a bunch of stuff that's, that's peculiar to PTP as we go through. And I'm in the process of trying to pull out that stuff. Among other things that that helm chart depends on is a standard library that we use, which may or may not be controversial to the rest of the world. So it's just to make it more, call it vanilla and less opinionated, I think. But so that's ongoing. The strategy to taking is because the, the test tool seems to be sort of in bits and pieces that was formerly used is actually to use something that we're putting, we're putting together for our own reasons anyway. And B2B, which is basically using a helm test to periodically hit a blockchain under test. And that way you can install one and then periodically set up a job through either prawn or a periodic check his job to run some load against the server. And that can be done as continuously as we'd like. So that's the general strategy. If there's any questions around that, I'm happy to explain further. But it's in the end, it's, it ends up being very simple and very portable to different, different environments. So I think it's, that's one of the better ways to do it. Any questions about that? Bill's releasing the Hedera consensus. And Bill just joined us. Yeah, I am. No, it's happening. So we're, we're doing a live stress test on a five node cluster on Google Cloud. Sort of I'm, I'm gearing that up as we speak. At the end of this stress test, we're going to release it because I still suspect there may be a bug or two. So at the end of the stress test, we're going to go ahead and open source it. We're extremely close. And the main thing is, let's, let's, why don't we, that's not a soft tooth announcement, but it can definitely be in the soft tooth channel announcing that, right? There definitely will be an announcement. No, I mean, I was talking discord channels, right? Oh, yes, yeah. Is it really advertising? Not that this is advertising, but you know what I mean. Or end on the contributors channel, I think people will be interested. But it seems there's a lot of people on the discord channel, the main discord channel that are experimenting with things. And I'm sure you would like to have people experience it. Okay, for sure. I'll make sure to do that. How goes the, any news on searching down additional soft tooth developers? And they're out. We have half of my developers on here. Keep the search out and try to get them contributed. Anytime we hear anybody, let's get them in. Turn the end user experience into the documents. I'm not sure what this refers to in the last one. Oh, that's some rust code from the Python. Okay. Actually, can we go to the tools listing there? I think is that doc? No, sorry. That was just the last one. Okay. Listing out the build tools. Okay. So that's a decent review of the last time. What I want to suggest is ways to keep this meeting a little survivable just briefly in terms of making sure we have a cadence in the meeting. Why don't we from now on, we'll just set up a, we'll put in the notes and all the afterwards a standing agenda of what items we do. So we'll review past events, major issues, outreach, ideas and open PRs. Not necessarily in that order. And then that agenda is open to be changed, but I think that's what we should do. Anybody else have any ideas about that or outstanding agenda items? I just want to have it repeated every single time we do the meeting. We'll do the same agenda. I mean, that sounds pretty good. Silence is agreement. As is the tradition in my team, if nobody ejects, that makes it official. Okay. So to that end, I had a question that was coming up for me in the poet stuff or at least related to the poet stuff. Are we still in touch? Or is anyone still in touch with any of the other than the, or is it just bitwise, the original designers of the poet protocol? Or is that Dan originally came up with that? Or because I was thinking the critical part of the poet design is the SDX and or the sort of naughty CFT. We all just agree to keep our clocks current strategy, but it could be designed to use an authoritative time service or like a verified time service that are out there in the world. So anybody else familiar with that? Basically where you can get a sign of a time reading and it's not fully decentralized, but the number of time servers like that out there, or trusted time servers out there are quite a lot and they're quite open. And I can deliver one step above this. Yeah. That's from, yeah, but that's linking into it. I was thinking the trusted time service, all you got to do is be able to trust the certificate that they print, right? It's a public service. Right. And I'm wondering, digging into the poet protocol, it's proof in the way it works. I'm rusty on it. But the, what you can guarantee is that if you've got a trusted time reading, you can guarantee that the time you have gone at least that far. You may have gone further, but you've gone at least that far in terms of the clock must have passed that. And you don't necessarily have to be in sync with that time service either. But anyway, I wanted to know if we knew who was the original designer of the algorithm and just discuss what was going on there because because of the SDX is a lot of other security analysis that went on around it. I want to make sure we don't loosen it and think about whether this is something that could be done as an enhancement to P poet or if it needs to be something totally separate for my trusted time service. So I think that was Dan from Intel, wasn't it who originally built that? I think you're right about that. Dan wasn't the initial designer. I'm, this was a long time ago and I wasn't involved initially, but Dan was the, like he ran the project in Intel. And I know he's still, like you can still reach out to him, but he's not really involved anymore. But there was another scientist within Intel who actually designed the algorithm. I'm blanking on his name right now, though. Just be helpful. Just, it's just someone to track down and talk again, bounce the idea off of Spindor. Tell us it's a terrible idea. Something like that. Anyway, that was an idea around poet. Was it Mick Bowman? That sounds right. Yeah. I think a lot of this was Mick Bowman's work. I remember Mick. I also noticed, and I don't know if you saw it differently, but I noticed that the algorithm itself isn't all that documented. There's stuff smattering around here. There's not really a full description. Yeah, I found the same thing with the documentation. It'd be nice to actually document the full algorithm because that's actually what I'm looking at. What is the discussion of the algorithm? So what bits are? Locked down and trusted and not trusted. We're going to be flexed. So in terms of the time thing, one of the other things I'm thinking about is there's a company called HopTruff that does this and they can do, they can do auditable time, which is a little bit different, but one of the things they do is an open standard time. It's a IETF standard for what I'm talking about. I'm blanking on the acronym. I think it's TAS. Anyway, that's a poet thing. One other thing is new items is Ryan. You've been doing some work with Sawtooth SDK and in particular kind of doing a more idiomatic one. Also the protobuf thing. You want to talk about that for a little bit? Yeah. So internally we're replacing the existing Sawtooth SDK rust with a Tokyo based implementation while trying to preserve as many interfaces as possible, as much of the interface as possible. I'm also adding some additional features, which will allow connections to multiple validators and prioritization of which node to write to based on, based on potentially a bunch of factors, but initially which one has the greatest block height. So it's more likely to make quicker. And as part of that, we're also swapping out the existing dependency on rust protobuf, which if you look at the GitHub is currently it is out of maintenance and all the energy seems to have moved to Prost, which has slightly nicer ergonomics, but again is actually being maintained and is part of the Tokyo group of projects. So we'll probably be in a state soon enough that with that bit of work to deal with creating a new Tokyo client, we'll also be able to provide the interfaces for the transaction, the traits for the transaction processor, both synchronously and asynchronously using that new using that new ZMQ client code. So at that point, it effectively becomes an alternative to the existing sort of SDK rust. So we're wondering whether that might be worth an official move or at least considering it as an official move if it can be released in a way that doesn't break too many existing users. So the main breaking change would be the swap of rust protobuf to Prost as there are some differences there. They're only minor and they're mostly more convenient because Prost is more dramatic about it doesn't expose slightly odd protobufy pointer types. It uses options and vectors and things like that. So it's a little more ergonomic, but it is potentially a breaking change. So in a previous meeting, it was mentioned that sort of SDK rust is effectively up for grabs really as it's out of maintenance itself. But yes and no, right? Because it's used in, it's obviously used in the other projects, the validator being one of them. So the two things I think you're talking about, one is an alternative SDK really, which the first step there is let's get it published, let's get it published as separate because I know where you're talking about in our code base, which is open, but let's get it out and publish so at least people can look at it and have an informed choice on it. However, the other thing you're talking about is more serious, which is the rust protobuf being out of maintenance. That means the SDK, the SDK therefore is in trouble. Could you, or again someone I should say, take a look and see what the the tent, other than the dealing with the protobuf drugs and traits themselves, what see what the impact is just moving the software SDK rust to Proust and or if there are any alternatives, you should always have three choices, right? Just in one out of maintenance, what are the other options? Are there other options therefore Proust, right? And remember, if no one else volunteers, it's going to be Ryan. I have a question. Are you using the same designing library in your new SDK? That is not currently part of it, no, but we probably wouldn't be, no, we'll be using the one which we bring in in Chronicle, which is KT5-6. The pure rust one, there's a pure rust one out there that I've been using. It's a pure rust one, KT5-6 that we're using. Yeah, there's the open SSL dependency would go as well, at least in our version. I've been playing with building a, for my current project, I've been playing at building a client library that compiles to WASM, so a JavaScript code can use it, and that's the sticking point. I had to swap out the signing. Right, it was killing me there, right? So I had to rewrite all my signing in another library. It works. It works fine, actually. And then I can do transaction creation in WASM, and then put JavaScript stubs. It's actually a nice, it was a fun, fun project. But yeah, we've not been using open SSL from our application code for some time, so yeah, that's fine. That's good to know that somebody else had the signature. Are we truly not using it, or is it just the build of it hidden behind another dependency, meaning transitively pulled in, or is it really just completely independent of open SSL? No, it is. We are doing the signing. We are doing the signing in Chronicle with KT5-6, not with Swartif SDK, and open SSL. So one thing I'd watch out is it's the particular patch, rather, of SECP-256, isn't it? That's K1 or whatever. You do need to make that call. You can make that call explicitly. Yeah, that's not the default. I can't remember the exact name of it, but yes, that specific variant. It's catered for, but it's not the default. Thinking about publishing it, there is a contrib folder somewhere around, but rest crates are a little funny to put in that, I think, unless I'm on this taken. So why don't we let's get the stuff published. Let's get that SDK separated out, published in some repository, and then we can do some sort of democratic thing to see whether it needs to go in, or just the ideas taken and evolve the SDK rust. Cances are being the last one. The other thing I was thinking, so there are still some open holes in that SDK, right? So you don't have the transaction processor side signing and presumably the consensus side as well. Yeah, the transaction processor. Yeah, it's purely the ZMQ client stuff that we're replacing currently, but the rest of that should be relatively simple, as we're preserving. Well, ZMQ client, and you've got a little bit higher because of the, it's the true sawtooth client side of the ZMQ client, because of the block height stuff. But the TP doesn't have that going on. You can't have a TP attached to more than one. But it will preserve the ZMQ message sender interface, so we can just slot that in. Okay, what I suggest, we need questions answered by you, Ryan. One is impact of moving the existing SDK to Proust and to the publishing of that, I realize I'm going to put that a little bit, to publishing of the Tokyo ZMQ recipe. I'll put a good name for it, too. So is that dependent on ZMQ? Yes. Yeah, transitively via TMQ, so there's Tokyo bindings for ZMQ. There is a pure ZMQ implementation, but it's no one, it's very experimental, so I'm not going to. Yeah, I actually, it's interesting that you guys are doing this. I have, I literally just ran into this with my last thing that I'm building, because I'm building a custom API in front of it, and I'm using an async API engine, and I had to put every call into the blockchain in a thread wrapper, so it would be interesting. That's quite uncomfortable. Yeah, you can use Tokyo's blocking tasks, but yeah, it's still pretty uncomfortable. Well, I mean, that's, when I say thread wrapper, that's what I mean. I use like sort of a blocking wrapper. Actually, I'm blanking on the web framework I used right now, but they have their own blocking thing, but still, I mean, you're behind the scenes is running a thread pool, and you got to think about all that mechanics if something's going wrong, too. Yeah, this implementation is mutex-free and just all Tokyo tasks, so it should be should be quite a bit simpler. Now, I'll check it out. Thank you. So, which since you're talking, Bill, you had some work you were doing with updating the Go library, sorry, the Go SDK with the consensus stuff, is that all done? I don't remember if we merged the last commit, but I will follow up on it, because I needed to do it anyway to push out the Hadera stuff. There may have been one or two more commits in my branch that I haven't upstreamed yet, but it's absolutely usable. I actually haven't touched the code that's the Go SDK, actual SDK code for the consensus. I haven't touched it in like four or five months, maybe more now, because it's been stable. So, I'm pretty confident in if somebody else wanted to build consensus with that, that it would work just fine. Okay, I'm more just checking to make sure it's all being contributed up. Yeah, I'll make sure. I'll make sure. There may be one commit. I may be one commit behind, but I'll follow up on it. Okay, okay. Thank you. What else? That's what I have to riff on so far. Does anybody else have anything? They would like to do. Okay. The other thing, sorry, we need to add to the standing agenda too. I will note down is answering questions on Discord, which I saw the last one was done by you, Andy, so thank you from everyone. Go through it, but I think we got a little weaker this last month in terms of answering people's questions. They tend to seem to be the, they all seem to be the same questions. Is one thing I noticed looking back over it, which is instructions not matching up to how you have to do things in reality and some things are a little out of date. So the answer to that is we should figure out a strategy to get those documentation up to date so we can stop those questions or at least give people a fighting chance to actually get the right answer without having to go to Discord. Can I get a volunteer for that? You have 10 seconds to volunteer, otherwise it's going to be one of my guys. I'll be more explicit, 10 seconds, otherwise it's going to be you, Mark. I figure they might be. All right, so Mark is volunteering. Okay. Mark is being voluntold. You're being voluntold or to, it's specifically those, all those questions around, because I think you'd like to do it anyway, is around setting up the different consensus and with the instructions or flag, so you could actually literally go back through the history of the last month or so on setting those things up, run through the documentations, make some recommendations about what needs to be updated. Okay, changed. And or added. Anybody else? Sorry, I'm kind of keen not to dominate the conversation. I realized three of my guys on the call here. So I've been talking, so if there's anybody else that wants anything to open up any other versions or any other issues, please talk. Okay. Any last one is any any open PR is a need attention that haven't been mentioned on the soft tooth contributor, any other practices where no one knows how to do it, or we're not being explicit enough on how to do it, or once, or twice. So I have, I have a patch commit to the multi-vestigate arrest, which failed, failed CI for a reasonable reason, I think there's an app get failed in the lint. So that was an approved PR won't, but won't merge due to that lint validation. So if someone could rerun the lint on that, that would be, that would be good. I'll rerun it. For that, we need, okay, cool. So it's just the maintainers that can poke that back because that's a github action, I think, isn't it? Or it's the just action. Okay. Thank you. Any other business only once, going twice, we can give 12 minutes of our lives back. Okay. Thank you. I will, I will, once you close this out, right, I will add in the, I will go through and edit and add in the notes that I've got for it. Okay. It's there for you. And I want to thank everyone for joining and I'll see you in a month. Thank you. Thank you. Bye, everyone. Thanks. Bye.