 and I'm going to start recording. Thank you. I was about ready to start recording. So we're recording this as the Hyperledger Stouttooth April meeting, and I apologize for not having a meeting agenda prior because I just got back from traveling in Asia where I turned my phone off for the first time in five years for almost three weeks. So the purpose today is to work through everything that we've been working through and continue the momentum that we had during the last two meetings. It looks like we've got a lot of things going on right now, but I think the most important thing right now is who should prepare the quarterly report because we do need to keep ourselves going with the Hyperledger Foundation. And Sean, I volunteered to help you, but I've never done one of those before. And later the day I can work on that and get that submitted so that we're not late on that. Are there any particular things that need to be done, Sean? The template is fairly easy. And if you ping me, I'll let you know if I have anything to add to it. Okay. I'll work through the template and I'll ping you and make sure that I've got everything on there. But we do want to make sure we keep those current because there are Sunsetting several different projects and I want to make sure that we keep ours lively enough that we are kept by the Hyperledger Foundation and we're an active project. And judging by Glancing very quickly, it looks like we've got a lot of conversations still happening. That was the only thing that I had and I apologize for being late on this meeting. Are there specific changes or specific topics that anybody wants to discuss on this meeting today? Well, I think the few things. There's probably talk for a minute about the kind of attack on the testing stuff. Or at least just what I have in mind given what we talked about on the chat line. Then we should talk about the main branch switch around that we were talking about last time and see if there's a tangible step that we need to do. And then I think you probably also need to talk about what to do about poet actually because I haven't because there's that set of questions going on there. And I just personally haven't dug into poet in a while. So be careful. Okay. So I got main branch and poet. What was the other one that you... The long run in testing stuff. I should probably just throw it. I mean, I'll throw the approach I'm going to take. Give it a little bit. I'm just over today. Okay. Let's start with the main branch. Are there tangible steps that we need to be taking right now in order to merge any of the code on there? Well, it's not the merge. Last time we discussed around switching around the current main is the 2.x driving thing. And you're talking about switching to 1.3 as the main and swapping things around. Again, I don't really have an opinion about whether we do that. But if we're going to do it, we should move it along rather than just talk about Yeah. You don't have any time to kind of work on it. But I think the next step, because I was gone for a good part of this month. But I think a good next step is probably to go through main and see what in there should be ported over to the 1.3 branch. Should we have a call for this or just continue to make comments up on Discord? My preference is Discord. Yeah. Then who's going to... Let's take another approach on it. Who besides you, Sean, is going to draw the short straw for dealing with this? Probably need at least one other person just to get things off of who, dear? Because I spoke, it's me. Yes, I think you just... Not the end result. I'm giving in Sean. So you guys can work through the pieces on Discord. Yeah. Okay. So I think you guys are a... I don't think, Bill, you have any time in order to do that? In the next couple of weeks, I have like negative time because of our launch. After that, I can spend some time. But right now, I have basically negative time. My general thought is try to bring those two branches together as much as possible and then see if replacing main makes the most sense or just applying a diff. I mean, is there a hyperledger policy for just like switching the default branch for the 1-3 branch and leaving? No. You can... We can start with that, right? You know, you can either do it via the .getupsettings.yaml, which would be the preferred way to do it, or you can do it through the UI. Okay. We just start with that and then we can just... That just eases the PR creating, right, and targets everything. But then, yeah, let's we'll identify that. I think it fits. It depends if the end result. Like I was saying, if we're switching, if we're actually like resetting the branch, that would make sense. If we can kind of get to the same place with just applying a diff on the main branch to prevent that, then that would be somewhat less disruptive. Are we talking about a cherry pick? Yeah, like maybe resetting, like reverting specific commits or applying the reverse on some of the things. It depends. It depends how closely we can bring it together, though, whether that will make sense or not. I guess another option would be to create a new main branch at the point of departure, call it get switch-c, new-main or whatever, and then cherry pick what you want from each branch in order, and then leave the old one as an artifact. But if your current 1.3 branch is the one that you want to be main, is that true? The everything in the 1.3 branch would be the new main? Well, I think the ideal would be 1.3 with anything that we need to add to it from main. And so that's just a little bit of analysis that we need to go through. Poor things over there. There's some pieces that got rewritten and rust that we should bring over. And then there's other pieces of that work that disabled features. And that's the stuff that we would want to revert from, like, a history perspective. 1.3 is essentially an ancestor of main in a lot of ways because there's not that many deviations in the 1.3 branch. So that process ends up looking similar to what you were describing. Okay. Well, it's close. Let me ask a different question. What is the downside of just making 1.3 the default branch and making everything else an ancestor of that? Instead of calling it main, you mean? Right. I think it would be pretty unexpected coming to the project. Especially if we still had a main that existed. I feel like renaming is not necessarily the biggest deal. The question is whether we maintain the current history or not. Or if we can get them clean and then it's like, oh, we just need to revert these few things. We'd rather have the history in main as it currently is. Simply because even if we revert the work, we can look back and say, okay, at this one point in time, this is the approach that we were doing. If we renamed main to main-old and renamed 1.3 to main, are we 90% of the way there? I think that's one possible outcome. That's what I'm saying. It's either that or it is applying a patch domain. So if we go through the exercise of moving all this stuff from main to 1.3, cherry picking stuff and reapplying it and just going through that exercise of applying it on the other branch, it'll be pretty clear at the end of that, which we want to do. So we need to do that exercise anyway. Right. Well, I don't have a preference. Just let me know what I can do to enable it. Yeah. So I think a good goal for the short term is just starting to look through that branch and put things over. We don't necessarily need to be in a rush to switch the branches, but I agree with Kevin. Some progress on it will be nice. Okay. Let's go to Kevin and Sean. Can you guys continue a discussion up on Discord and start working on that? I'd like to make some progress on that. So we've got something that people see all the various things that have happened to this project over the last 18 months. Because Sean's made some great moves, but they're not connected to the 1.3, and I'd like all that merged in if we could. I think what we need to do is start really making some marketing style moves in order to bring more people in. And I think this is the first step once we do this, because I think that the blockchains appear to be going more and more into private mode. For all of the what's happening right now. So I think we have a chance to expand our base. And if not, then we have to look whether it's a viable project beyond there. So let's try to make this a priority over the next month and see if you do guys. And I think Bill and I can shake it once we get our release out. He and I both took time off at the same time. Because we were supposed to work. We're behind on our release date and our vacations couldn't be moved. So we shifted everything, but and see if we can get some additional people. Poet, anything else on the main first before I move on to poet? I mean, most people are using and why am I having a word blip this morning? What's what's our main consensus? Consider I was in that this morning. Most people are not using PBFT. Thank you, Bill. Most projects are using PBFT on this. Do we want to do anything with poet? A poet is the heart and soul of the initial project was poet. But I don't believe poet has been updated in years at this point. And there were issues with it, which is why PBFT came out. Do we want to do anything or do we want to sunset poet and make that public so that people don't try to start using a poet again? I'm going to add some history background. So proper poet, Intel's vision requires SGX. That code's been broken forever. Like you can't compile it. They changed the SDK. It never got upgraded. It's been that way for years. So the poet that we're talking about probably isn't that because that's like a pretty much a complete rewrite against whatever the current Intel SDK would be. So what we're really talking about is Poet Simulator, the code that we use when we're not on an SGX system. And that's really the one that most people would be using. Like if it's in a Docker container, it's certainly not the actual poet implementation. It's the simulator. What that means is there's absolutely no security. So from like, it's got some attributes to it that would lend some security characteristics, but it doesn't achieve what Poet sets out to achieve. And certainly shouldn't be used in any production sense. Yeah, and I agree because you can't even drive it to anybody's enclave and I wouldn't say Intel's enclave is secure enclave. Got any kind of market share compared to some of the others that are out there. So I think it'd be best, at least from my perspective, to sunset Poet and make a statement up on the website. Maybe we can get that put up there that PBFT is the supported consensus for this. Please, just sorry, I didn't mean to interrupt it. Go ahead, go ahead. So I think it's important for the project to have using the wrong term, but a sort of a large scaling proof of work style is not a motor stop consensus algorithm running. And if you sunset Poet, we don't actually have one anymore. The Poet's simulator or CFT, I think it was called for a while, is good enough to actually test out those scenarios. Now, I agree the SGX thing was a bit of a mess. I think there's interesting stuff around Rust libraries who abstract away basically all the enclaves, SGX being one of, where perhaps we can actually make a more stable version without having to deal with the low level Intel primitives again, where we could actually update that. The other option is, to me, if you're going to maintain some sort of massive scaling consensus on there, the other option is to implement something from scratch or something else. Some other consensus algorithm that we do, the Poet has the advantage of not burning electrons. I think we shouldn't just cold pull the plug on it without considering a replacement or remediation of it. No, and that's a really good point, and that's the only reason it's still there is if it's removed, the core of Sawtooth will lose the ability, because we won't be able to test it, to handle forking consensus. One of the things that Sawtooth has going for it is it's probably the only distributed letter that can support both. That's a good point. Right, that isn't like one model or the other. And that's very much why it's been there. Maybe it's a difference between what do we push people towards on the website versus what do we keep for testing purposes? Sean, what happened to your consensus switch, or would that fit into the main that you were working on? The consensus library project? Yeah, I mean, it's there. It supports, it doesn't even have full support for PBFT at the moment. It's got a two-phase commit. Really, I think they'll fit it in. I can keep everything working, which is not my previous focus. It would be to use that, because that's really the idea is, can we create a Rust library that, and this is called algorithm, by the way. It is up on GitHub, but the idea is to very cleanly separate the algorithm code from all the networking and all the other stuff. The end goal, the end idea being, if we could create this library, maybe we could get researchers to use its interfaces to implement future consensus algorithms, because the current state is kind of has been, when researchers are doing this work, they inevitably implement the entire stack. And it makes it less usable, but it's also a lot more work. So that was the idea of that library. That is, it's an area that I remain interested in. But it's, you could think of it as, in terms of like, such as architecture, that we could have a consensus engine that uses that library. So if we wanted two-phase commit, for example, that we can write a consensus engine in Rust that uses that library and kind of provides all the networking and self-toothings and stuff like that. Yes, so the forking is, is what you need out there in testing. I'm trying to think we built a consensus for the NSF that we published the code on almost two years ago now, but it's not forking ideally. I was trying to think if there's another consensus that would go in there that would give you that ability to test against it, that wouldn't be as non-maintained as that, that poet. Or do we just put up something that says on the site that we only maintain it for testing purposes? Well, the thing I'm concerned about is mixing up poet, the algorithm with poet SGX, the implementation that's suffered because implementing stuff on SGX is very, very hard and hard to maintain over time. So I'm wondering, right solutions would be actually, first let's take a look at it and see if can it be, can it be lifted into something that is more maintained, because that's why it's in that shape, right? Because SGX moved on and into weird and different directions and it was complicated. Well, that's only the SGX code though, which, yeah, honestly, we've never deployed anywhere. Any of us, because like SGX isn't even or wasn't at the time when we were doing SGX stuff, wasn't even on like any server stuff. There was no cloud support or anything. So like the only place I know that it's ever really run is on Nooks. But that was, you know, that was a long time ago. So really, when we're talking, like, when we're talking about... It's a secure time. You need some secure time, right? When we're talking about poet, we're really talking about the simulator. I just want to call that out because it's not a thing that should be used in production. So driving people to it under, you know, and kind of advertising it as, you know, some solution that they should use, we really shouldn't be doing that. Yeah, I'm fine with not driving to it. I'm more just thinking of, but we should actually give it a kick in the butt and figure out what the right strategy is, right? The two weaknesses being one, the secure and safe implementation isn't actually remotely practical as you just highlighted. Yeah, I suspect if there... The other one is the simulator, right? I suspect if there's problems running the simulator, it's probably a change in Python libraries. And so it's probably like that level of like remediation is like go through and like, you know, update things or pin versions or whatever and then run it through the integration test. You know, it's probably, you know, from a maintainability perspective, there's... I wouldn't expect it to just break unless we're doing some pretty big changes in the validator. Like we're changing that contract and like that's, you know, going to become a source of pain in terms of keeping poet working because it makes a lot of assumptions or the... Not assumptions, but you know, there's a... The contract between the two is there, right? So like... So in terms of it being broken now, I would just assume that that's either Python libraries or even Docker image problems and not like, you know, we need to go through and like rewrite a bunch of poet code. So then we just need to volunteer to go and take a look through it and I'm staring at you, Joseph. Yeah, I think that could even widen to like really we just need to know that the stuff that we're saying on the website like works. I think, well, it's an interesting thing because I wonder just thinking about the guy who specifically asked me a question, but I went through with that other guy, I can't remember his name is, there was the two things that were going on was that the documentation pointed to the main versions of the files, which didn't have the transaction processors, obviously, but he was running it versus. Fine. Anyway, there's just documentation missing the first one. And then the Docker compose version has shifted and weirdly has syntax that doesn't carry from one to the other. So there's a bunch of stuff like that. I mean, we're going through and looking or at least flagging up when we see it. Okay. So Joseph, will you take that challenge? Yep. Sounds good. Okay. So Joseph's going to take a look at the bug code and see if we can just update it and make it more stable. Let's get main working again. Okay. There's a logical follow on to that. Is it probably the same as true of raft? I don't know how much update anybody has to deal with the raft when there's PBFT sitting right next to it. Oh, I thought that we decommissioned raft. Could we not do that? We could do that. Counter to all of this, I am willing to step aside and let raft be sunset. I don't think I'm going to really use it. PBFT implementation is better than the raft implementation in terms of stability and stuff. And so there's not a lot that testing with raft is going to tell us that testing with PBFT wouldn't. So it's not kind of the same set of problems. We may not have officially done it sunset yet. One of the things that we were thinking for a long time is that we shouldn't really decommission components until we did like a, at least a point release, to say like, okay, that was, you know, poet or raft or whatever was a one, two thing. We're on one, three now. It's no longer a thing. So then it wasn't confusing, but maybe that's too high of a bar. I think we had the same thing with the SDKs. I think we should pair them back. We've done a little of that already. Well, let's decommission that and make that a, if it's, I can go through the documentation and make sure it's not mentioned in there. And then I'll come up with something to put up on the website. So we'll make that official as we go through here. Okay. Anything else on consensus? Long running testing. How are you working on that, Kevin? Well, just wanted to spend two minutes talking about it today. So what I have in mind, Sean, is not to use the LR merge stuff, but to do from scratch. And the reason being is that we've got some pretty good helm charts we can put forward and that'll scale up very easily to whatever we want. And then enhance it to run some load drivers in various ways to go for it. And I think that'll be a good strategy, unless there's some other capability that it has that we don't know about. May actually move the load drivers into a helm test scenario. I mean, it has a ton of capabilities, but the tool overall is like aging. A lot of what, a lot of the value that we got out of running those environments was graphing everything. We use Grafana, like graph the system metrics and stuff like that. That's all stuff that doesn't make any sense with Docker, because it's all ends up being less interesting. But maybe there's some statistics that do make sense that weren't the ones that we were looking at. But then trying to get some statistics out of sawtooth, those are really useful as well to be able to see visually like, okay, here's where it started to deviate. And if you have 20 nodes, you need to know, okay. When did that one node stop progressing? Things like that. So none of that is really that tool. But that's one of the things that we would look at every day. It was like, okay, how's the network going? Grafana has made it super obvious whether things were healthy or not. Yeah, but I think right now we just need a strategy to get it updated. And Kevin, if you're willing to drop all that code in there, let's do that and see how that is. I mean, we're not going to, well, if it doesn't work, we can revert back and see if we can't get something up and going that's up to date on this. Is that agreeable? And then so you're just talking about the pulling, Sean, you're just talking about pulling up the doing the influx and open TFDB and the default dashboard or was there a specific dashboard for Grafana? I shouldn't say default. The dashboard that's in Contrib. Is that the one? It was probably similar to that one that's in Contrib. Managing those dashboards was like kind of an ongoing battle because it's not really meant to be managed like that, but importing, exporting them and it had a lot of issues. But it's probably pretty close to what's there. I think the one that's there, you can stand up in the Docker container. So yeah, we have a, we have a different one. Maybe we can throw forward. Okay. Well, let's start with running up the environment that the monitoring and observability part of it can be added obviously afterwards and just get it start starting running, falling over and failing when things fall over. And we'll be a good step along the way if we do that. All right. So that's what we'll do. Okay. I just had one additional thing that we're going to be doing just and it's related to that consensus. As Bill alluded to, we're trying to get our project out. It's working. We're about ready to push it out on beta, but we have successfully brought in the Hedera consensus into Sawtooth and so that there is a public consensus available. And we intend to make all that code open source, but we've got to get the last seeds and seeds done and then have time in order to push that code out. So just wanted to didn't know if that would be something that we should be sticking up on that we've got that code on discord so that people understand that it's out there, but we just don't have time right now to get the library in shape that the world would be able to understand how to use it. But we're pretty close on that. And Bill, once he's got this out, Bill and I will make sure we get it really should be well before the next meeting as just an additional library out there. I don't know if that's of interest to anybody, but we want to make that that particular library and this one actually works right a lot different than the one that was up on fabric. And we're actually able to do its production ready and Hedera's paying us to do it. And we're gonna it's working pretty slick with their their wallets and everything else so that you can actually have a public confirmation of all the commits into Sawtooth. I didn't know if that I'm just making that it's more of an announcement. I'd say certainly announce it. It doesn't seem to be a problem to me. It's a project based on Sawtooth. It's good, particularly if you plan on open sourcing it. Yes, we definitely are open sourcing it. Do we have a list anywhere or any sort of like page that's maintained with just like projects that you saw too for something like that? I don't know of one. Sean, do you? We had so many of these websites that we run. They're all slightly different. If not, I mean, we should create one certainly an appropriate thing to put on the website and discuss and discord, you know, all of that. I think perfectly appropriate. Okay, yeah. As soon as we get this project out, I'll work on looking for and publishing out that, put up a page and put different projects on there. Anything else that we need to discuss in this part of it? We need to find, I think, and identify additional developers working on Sawtooth and try to get them to contribute. Because right now it looks like there's three companies working on it in haste, that can't be TP and Sean, I can't remember your company's name. But anyway, we've got three companies. I think there's more people based on some of the comments coming through and see if we can identify and bring them in. I'll make a point to try to do that before the next meeting and comb through discord and see if there's anything there. But I think that's really what's needed to make us more active. And project that's ongoing and running for Hyperledger. I don't know if anybody has comments on that. Okay. It feels like there's maybe an opportunity. I don't know how to make it happen. But when the docs are wrong and stuff, to my knowledge, no one's ever submitted a doc PR before. And the docs have all kinds of problems and we know that they have all kinds of problems. So we tried to reduce the barrier. And I think it's used to be really high. I think it's pretty low now because it's just a PR against that repo and it automatically publishes and stuff and it's just marked down. So I think any thoughts about how do we turn some of the I guess the end user experiences into enhancement some of the documentation. Even if they're not clear, but like how because we can't even flip that. We can't flip that into a contribution. You know, getting someone to focus on like harder stuff is probably difficult. So that's one idea. I think the other one would be, you know, if it's things that were, you know, it's not a company like kind of investing, but it's like individuals that want experience doing stuff. You know, there's plenty of the code to rewrite and rust, you know, that can be broken down into, you know, pretty manageable size projects. Okay. Let's this, you know, once I get my project down, I'll try to jump in and start posting up. I haven't been as active as I should be. Any high priority bugs or issues that have popped up that anybody is aware of that we should concentrate on? Okay. Any open discussion? The only thing I think might be just a suggestion that might be helpful if we don't have it already is listing out of what we have as the tool chain for each of the projects. Only because thinking about that Docker compose thing where, you know, Docker compose to break chokes on almost all the channels that we have, right? It needs to be listed somewhere. Something like that. We should probably do, but other than that, no other. Okay. Okay. Not a demand. If there's nothing else, let's, we can call this meeting to a close and I'll push this document up on Discord shortly. I don't know if there's anything earth breaking on this, but thank you all for attending and let's just keep talking through Discord. Sean, if you could send me the template. I'm not sure where the template is for the report and I'll try to hammer through that this afternoon and get any comments you have on it once I've done that. Okay. Sounds good. Okay. Thank you all for attending and we'll do it again next month. Yep. Thank you. Okay. Thanks. Thanks. Bye.