 Great. Welcome everybody. We're, I sent you a meeting request to open up the screen if you want here. Okay. Just, we did a lot of work, evidently since the last time it looks like we're re enabling where we are with saw tooth. There's a bunch of discussion couple people have asked questions and. Thanks Sean for guiding a few of them through there and Kevin, and I believe. Bill have all guided people through there so that's good, and we need to start reaching out and having more people enabled on this. So the, I just threw the agenda up here in terms of what's up on. Google Drive. So basically, you know we're to keep the one dot current X line current we've got a bunch of ideas on here. We need to walk through. We made a lot of progress let's keep that up. And I think the first question we had on there was should the project take what's in Maine and take one dot three or one dash three and make it the main so that would be the branch structure. And I believe that was Sean. You're the one who brought that up so if you want to walk us through that. So kind of the current state of Maine, why this is this is interesting is. There's a ton of good stuff in in Maine that isn't in one three. That kind of puts one three to shame, actually. However, the decisions that we made quite a while ago is switch over to transact before it could run transaction processors. largely because some of us are completely uninterested in any other language than stuff that would run in wasm, which included all of the maintainers. So we put that effort into into that and didn't implement transaction processor support. Which leaves it in the current state of, you know, the rest of the community here not not migrating to it. So as we as we move forward, like, I guess like a principle I'd like to move forward with is that we move forward as a as a single community, and not kind of fork the project. And so with kind of renewed interest in in one three. It really makes sense to go back there's a larger, I think community here around one three. Then I anticipated surely that we go back and we just start back porting the good stuff off of the other branch 23. But then to make it clear that like, you know, we have one, certainly development branch that we name that that branch main. And I think it's probably an easier. It's an, it would be an easier path to start with one three. Kind of not break it as a as it were, then to fill in any gaps between main and what the community expects right now out of one three feature set. Do people have comments on that Kevin bill anybody else. I totally ask is if there are there any infrastructure you got just I don't really have an opinion on whether or not to do it. It's just, are there any. Well, will there be a breakage. If we do that from infrastructure and things like that. Build stuff. You know, the most the most disruptive piece beyond, you know, the cleaning up to build stuff obviously is going to be messing up everyone's repos. The forks here. Right, the forks and like, you know, personal checkouts based on main and stuff like that. You know, in an ideal world, this is something you would never do. Right. But it is where we are. And I think it does make sense to kind of rally around, you know, single code base. More than just kind of continue to diverge. Because we can, there's plenty of examples of communities diverging and essentially creating two completely different things. I think that that can work if there's a big enough community. I don't think we have a big enough community for kind of multiple projects here. I'm in full agreement with that that we need to have it merge back I don't think you're going to have much pushback I'm not sure who's using it. I'm not aligning I think we'll find out once we break their forks or break whatever they've got on their server. And they'll come to us at that point so we have to be ready to answer those questions but I've been involved in multiple open source projects and sometimes it comes to a point where you've got to do this so I think the people that would care are using the splinter, because it is, you know, like 100 times better. So, basically in every way, then then sawtooth except for consensus and transaction processor support, but like from like a stability perspective. So, that being the case like there's not a lot of sawtooth notes that are first, like first order sawtooth notes. Okay. Um, what do you what do you mean by that running actively, you're saying. What do you mean by that that statement there's not that many nodes, not that many splinter I think it means not that many splinter. Not that many, like, uses of this code base in Maine in like, POC is your production and stuff like that, because in the wild, I see. Right. So I don't think we're going to be breaking, you know, people's environments. I don't think that's a real concern. So you don't think there's very many people using sawtooth itself. And they've many of them migrated over how many people are using splinter, do you think so I don't, I don't want to comment on that, because of all the days, and all of that stuff is this NDA so But suffice it to say that like, you know, the team that was working on on the stuff, you know, a lot of like the vision the overall vision was to bring all of the really good stuff that is in splinter, essentially new networking layer. And that's what the main branch essentially does in part. It's not like we're going to kill the branch though right we're just going to move it off to another would just move it, but I'd rather like for me personally like where I'd like to invest my time forward it's like okay. We can take some of those features, we can we can merge the stuff into into main and then kind of move forward as a community. That way, as opposed to filling in the gaps in that current branch. It's like we can look at what's in Maine and we can like, you know, there's, there's some patches that were just, you know, that we can just pull right directly. And the one problematic one is that transition to transact, where we wouldn't want to pull that exactly. We will want more finesse and to not break the current transaction processor support. And it's down to the practicalities right so it's the life of the splinter community, we just born in advance and advertise that this is what they need to do to switch to the branch. So just switch to what is currently made but will be, you know, branch X. What would you want to call this branch we want to throw a new number in there so everybody's aware of what's happening or we can call it a one three call it a one four and start merging into that. We called it like 199 informally, but I think just giving it a name that's not a virgin number, because we could see like the current one three growing up to be 2.0 so I don't want to like, take away from that for us to kind of get to the same point by different direction by like claiming version numbers. We like the main branches never been released never been declared ready for like production or anything like that. So, so we have we were very careful never to just kind of developer discussions, not kind of claim that it was ready so. So I don't think there's a big concern. Just picking a different different branch name. I have to think that I haven't come up with one yet. Who should we have on that should it be yourself, Kevin bill. Anybody else. I mean, I think everybody else is working for one of the companies. Probably only maintainer that has permission enough to do that stuff. Okay. It's very easy. It's not like a time consuming thing it's just like a more of a big decision type of thing. So I think we should go ahead with this unless there's objections from buddy, anybody on the call. I think you just pick the branch name and then read me somewhere. Just to warn people what's happened. Okay. Just a note. So that's a good idea. Right. Let's figure out what happened. Yeah, so let's make sure we post that up on discord several places and possibly under announce that way. It kind of gets permanently hung there as well as the active to active channels that are there. Let's get it posted all three once it happens. So people understand what's going on. Any more discussion on that one. So I have a question. Embarrassingly, I've pretty much ignored main because I almost all of our work has been in the one one that Francis so I've pretty much tuned out of it for a while. What are the, you know, what's the elevator picture what are the main changes that have gone into main that are in the regular one series is you said network layer stuff is there anything else. So it's hard for me to talk about the vision then like focus on like what's currently in in Maine, in terms of like our intent and direction, because some pieces aren't there but it's hard to talk about, you know, being compelling without kind of the whole. The way that we started splinter was just a recognition by us, you know, like the authors of soft tooth, right, that wrote all the code that that the networking layer is bad. Right, it's. It's got some pretty extreme problems with it. Even more problems with the journal and stuff like that the abstractions aren't good. It's extremely difficult to make changes there without breaking something. And it's always to some extent always been broken because of how it's written. You know that's that that's an artifact of the intense effort over quite a long period of time to construct it and get it to the future set it is right so not taking away from that but just saying it has issues. So we're looking at moving that trust say like okay. Like, we actually don't want what's there not has issues. You know what do we want. So we started kind of thinking about that and thinking okay how should this work cleanly. And that turned into splinter. How I saw splinter initially was essentially just a lower level. Networking layer that we would use under sawtooth. So most most of the thinking in the early days splinter was kind of at that layer, like, if you think about dividing things up cleanly what would you want at that layer versus you know mixed with the other layers and stuff like that. So we put a lot of effort into into that layer into three connections things that like in one three. You know our, are rather broken those problems don't exist in splinters network layer. But as splinter kind of grew up took a life of its own. And, you know we kind of started to use it to kind of prototype things that eventually, you know, you know, from a vision perspective we see like okay this would make sense for sawtooth but we can't do it in the subject code base. So we have to splinter and then we can talk about how to get it back over to sawtooth so things like reconsidering transaction execution. You know, implementing transact, for example, and the reason that transact was in splinter first is it's easier. It's not so easy to to deal with that mix of Rust and Python code that we currently have three. And so, all the transaction support which is, you know, leagues, leagues better than, than what's in one three. Right we took everything we knew. We created something far more elegant. The only thing missing in transact is, you know, a transaction handler to make external calls and, you know, kind of act as a transaction processor. All the other capabilities are essentially there, including like really good that's what we cared about. I still do care about. So, so as, as we're kind of exploring this okay so we have like transaction support it's like, you know, I would say half of sawtooth, right. In a cleaner model, more flexible doesn't have the issues. We started to look at, okay, the worst part of sawtooth is the journal. Why is that right. And so we started to work on abstractions around. Okay, what should it be. Right. You know why does it feel like spaghetti code currently, right the boundaries must be wrong, which they are, and that is why it feels that way. We stay around with that. Okay, what, you know, what does it look like if we if we clean that up and we think critically about the, the function of consensus and in the journal and stuff like that. And a lot of that is currently in splinter now splinter only because of where our focus has been is all to face commit because the use cases were ones that just lent themselves to using to face commit. So it's a capability sawtooth doesn't have to go down to two or three nodes. But there are some interesting use cases where you don't really care about the trust issues, but all these other features are compelling. And that's kind of the space that we were playing in for a long time with what's splinter and grid. So it's really like every. So the way that we came back to sawtooth to the vision was okay let's take the work that we've done in splinter and put the interesting pieces of that. That make it into a blockchain in the sawtooth. And so a lot of that work has been focused on live sawtooth and saying, I don't know exactly what we're going to do in the future. I don't know exactly what we're going to do in the future. I don't know exactly what we're going to do in the future, but we essentially finished transact for for what we needed at the time. There's a long list of stuff that, you know, I'd like to see going to that code but even if you don't want was and but you're using rust. It's really good. But the things that splinter doesn't do that, you know, I couldn't see it really doing was, you know, becoming a blockchain, you know, that's, that's what that's what sawtooth is about so all the all of these other things, you know, like the consensus model and journal in splinter are not block based. It's a simplified version so that we could work on, you know, various pieces. And so sawtooth to really about, okay, let's take the good pieces that we have in splinter. Use those. But in sawtooth and really live sawtooth rewrite the journal. And, and all of the things that make make it a blockchain that aren't like the lower level things and reconstruct that up. So, you know, main is part of the way there. But not so far that it that we can't like, rebase that effort on the one three. I think the, you know, the, the direction that we were going with that branch was really to think of, think about redefining sawtooth, right, from here's a validator to here's here's a project that has a really nice rust library for building distributed ledgers, whether that's block based, like sawtooth, or whether that's non block based, like scabbard, which is the splinter transaction processor essentially. You know, but really see the project as, hey, we're going to build this awesome capability to build custom distributed ledgers. Right. And the validator is going to be a reference implementation. And the things that we've seen over time right with like forking in within our own community and, and especially people on the call here not contributing back all the time. Right. Under that model is great. Right. We build the pieces, you build your own ledger you customize it you make it do whatever you want to do. And that's the model. Right. You can customize it, customize the add value replace components. You know, that that that and the validator just being like reference implementation. And so, you know, the reference implementation like most reference implementations, you know, can get users pretty far but from like a development standpoint, seeing that as like, okay, what we're really doing here is we're going to build a model kit to create these things. And so, you know, with that with that like in mind, kind of the vision for, you know, splinters roadmap and sawtooth roadmap is essentially like, okay, eventually, both use live sawtooth and they're just slightly maybe the bludgers, you know, sawtooth being a proper blockchain and split or not. So, yeah, so. Okay, thank you. Thank you very much for the for the summary just it's good to know, you know what the state what the state of the artist right and then, again, I admit to having not paid attention to the to the main development effort for a while. How does it does it run what is the current state can you actually stand something up off of main that actually, you know, functions. Yes, but it's not something that even I have done recently because it's not. It's not an incredibly useful thing to do. Well, that depends. It wasn't it wasn't incredibly useful to me is what I should say. Because we weren't using use cases that were like PBFT based. But you can stand it up. And we did this with like our grid testing and stuff because all of the, the grid testing. And the grid grid runs on both because everything in splitter is 100% compatible with what sawtooth and so you can kind of, you know, pick your distributed ledger that you want to run a grid on. Now, we're going to end of life grid, eventually. But. But that being the case, you know, they're very, very similar. I feel like the difficult thing in Maine, which is extremely true. In one three as well is like the difficulty of standing up and not work. It's pretty extreme. With all the Docker assumptions that we've made there and stuff that kind of just makes it more difficult than it needs to be. But it's functional. But it can only run wasn't smart contracts. So maybe not functional for this crowd. Why don't we go on to some of the specific changes. Just to keep us on track so we can get this in under an hour. Any other questions to Sean on the first thing. And he's given us a wide ranging view. So if you want to say that was that was that was a good, good presentation. Thank you very much for going over it. Just think it helps to, to give a basic understanding of where everything is. Thank you. The thing that we need to do post switching branch out is, is basically come up with a game plan to identify the bits and the things that need to move forward right there are definitely good bits in the main there. And the goal of frankly, we're one of the original goals of eliminating the Python. It's a great call. There's a lot of the boundary violations happen inside the Python stuff right. The, so what we should do basically put on the board as the next thing to do after we do the merge is to go through and try to identify those things that need to be pulled across because they're or they skip us down, down the way, and then put them up on a board. I know we don't have. I don't think we haven't, we haven't even brought up jury and I'm not suggesting we talk about jury now but that's the next one. Whatever right it's, but it's, it's a some sort of tracker right to go for it as it goes through but the my point is, next thing after we do the branches to come up with the plan to see see what's what the first first goers are. We're already talking about some right which looks like the database abstractions and stuff like that. And those are, those are similar. Do we need to have a board. Do we start putting actions on, or is there one that you're using Sean. I think it would make sense to just use GitHub issues on the on the repos that are that are affected. You know we always use like internal boards for everything in Jira or, or whatever but like, I think we've used probably four or five different things but from a project perspective because we're not, you know, we're not going to run sprints together. It makes sense just to enter them as issues and you know assign and stuff because I imagine people are going to commit to timelines and stuff. Okay, so we'll start using GitHub issues to start putting notes in there. Okay. Zmcube message I can't remember who sent that. Do we want to start just talking through that one. Yes, yeah that was, that was me and so we've been using sort of as a transaction process. And we've done a couple of integrations in rust and currently working on unifying abstractions between a couple of different transaction press implementations. And there's a few mainly ergonomic issues with the current rust sort of SDK when it comes to using it from modern rest, mostly around using it from asynchronous rest. It was designed at a point when that wasn't particularly stable, I think it was around around around the time features were introduced into rust and it was still a little bit up in the air, I think, but the two main issues from the perspective of using it as a client to communicate with a validator, the Zmcube message sender is both blocking and concrete, so you end up having to put your own traits on top of that and putting asynchronous implementation on top of that as well if you need a sync. And the other side of that is in the transaction process itself is the the apply method supplies a mutable reference which is quite a difficult type to deal with even in synchronous rust, but in asynchronous rust it's very tricky you need to build a internal mechanism and effects systems on top of it to be able to use the transaction context in a, in anything that's asynchronous that you're supplying into the into the apply method. So, Sean, is this part of what you've already got done in your other projects and we can move on. I mean, yes, we've completely rewritten that code. That's actually in the software now because we move transact there. And that's all part of transact. I think a couple things. Yeah, all that code is synchronous. So, so all the async use case here is, is new. There's, you know, not those pain points at all without that. I think, well there's a couple things one. I've seen the sawtooth SDK trade has kind of deprecated for a long time. So, I don't think it's necessary. Like, it's interesting because I was thinking about this yesterday today, you know, like, oh, you know what do we do with the sawtooth SDK. Because those of us using transact have really just seen that like as completely, you know, replaced essentially by what we have in transact, which doesn't include the transaction processor pieces. Right. So it's not 100%, but it's like 90%. It's like smart contract APIs and stuff coming from transact. And we have a lot of smart contract smart contracts that probably have conditional so that we can select between them. Because that was interesting for for a period of time. So I think like at a high level. You know, I'm on board with with iterating on that stuff. I think that we should do that in probably in the sawtooth. In the sawtooth, we should we should make sure we have a clear delineation between what's in lib sawtooth and what's in sawtooth SDK. And that becomes hard because there's a lot of potential like code sharing. So, you know, do we want more than one crate? It's essentially like the question there, or do we just want to pray where you turn on the features that you're using? Is it shared because of the dependency on the protobuf primarily in the existing sawtooth SDK because it does have both the transaction processor side and the client side and all they all they really need all they really depend on mutually is the is the protobuf generation. As far as I can see. Does the MQ code can all be shared or is shared, right? Use the same same MQ socket code for clients and for TPs. Yeah, so I think that's something we can explore we don't you know need to make technical decisions here. It's kind of isn't the form for, you know, in-depth technical discussion that we haven't, you know, kind of already hashed out and thought deeply like on the channel. So I'm not sure what the answer should be, but that's, you know, that's kind of where I'm starting from this. Oh, this was deprecated maybe not now. Maybe we need to rethink this. Some of the stuff we have in the sawtooth should go over to the SDK and we update that. And do our development there. Or maybe we move it all to the sawtooth. So any more thought, I don't want to even recommend one way or the other, like, I know I would lean towards the sawtooth because that's where the transact stuff is, but there's a lot of things that we've talked around. So we should take this over to Discord and discuss it there and see what we can come up with. I think that's the best place. I think really we need to. So it's interesting considering using like async stuff within apply. It's interesting that like that I've really thought about because it's completely uninteresting if what you're doing is writing smart contracts. Right, because smart contracts should be like that. Right. It shouldn't be that it should be logic, right. It should be stuff that can run within wasm. And so you wouldn't do anything asynchronous because it's it's doesn't make any sense. So, but if you go to transaction processor level, then that's different. So I think it's, it's important to differentiate like okay what are we where are we kind of changing the interface and like who's the who's the target. Interestingly, our use case for the asynchronous bits in the transaction processor is purely for serialization for various reasons we've ended up with a some asynchronous stuff in us in our civilization. But the the actual core bit that would map to smart contract would be that still that's purely that is purely synchronous code but there is. There's a bunch of there's a bunch of there's a bunch of serialization and deserialization which goes on inside the transaction processor for its dispatch to the to the simpler synchronous bit that actually doesn't work. That's over to discord. I'm trying to just get us running the next 14 minutes here. The apply signature processor. Do we want to have that discussion on discord also, or do we want to talk about it here. It's probably quite detailed so I'm quite I'm happy to move that to discord if that's okay. Let's do that sounds good and my concerns are going to be like how do we how do we get to like one code base so you know we could take, you know, and diverge significantly. And you know my goal is going to be. Okay, I want to make sure that like where we're, we're unifying more than separating. So, you know the viewpoint I'm going to bring is like, okay how do I use this within splinter how do you use it. How does it impact all of the smart contracts that we currently have stuff like that. Yeah, we can take it to discord. Okay. The next thing on the list was existing test infrastructure should be rebuilt, built, and especially considering we're changing quite a bit of infrastructure here are the codes. Do we want to rebuild that who would do that. So last time I think I threw up my hand I said I would help out with that I have some time to deal with that this month. And you said you had some terraform stuff for running up the past infrastructure. Yeah, and this was like ad hoc stuff not stuff we would like the system, but like, yeah, we could connect on that and try to get one of those systems up. So I did, I didn't maintain that stuff. And the person that's that's maintained it. I'm so interested in answering questions about it. So, like, maybe. But, um, Yeah, sure. We can work through it. It's a place to start and we can throw up some things. Got some ideas. My goal would be to get it so that it could run in a CI infrastructure. And then a short test, and then a long one. We'll see. But that's that's that's a stable so I'll think it was gather up materials and see what we can do. That sounds good. So I'll put on there Sean and Kevin take this up on a fly anybody else. What their name on that. Okay. I think the new smart contract interface. That is on there. I think that goes back into your first original discussion unless there's something different that I missed on that. Yeah, I think so I think that like, we just need to differentiate between like, because we use the same interface for maybe multiple things right now. But like, okay, we really shouldn't be doing that. So smart contracts should be using a smart contract interface. And then we have the transaction processor stuff that is more flexible and to make sure that like, when we trans change the transaction processor stuff we're not rewriting any of our smart contracts. Unless it's to like a better smart contract API. Of course, but like, that those are kind of two, two different things. They're maybe too tightly coupled. So I think that's the thing to think about there. Okay. The last thing on there is update any of the demo somebody's asked for that on discord a couple times. Don't know if we want to do that, considering the changes we're talking about. And that would be down the road maybe some firm has an intern who could do that once these changes are made, because interns usually start in May. That's what I was thinking on there. You get the demos and GitHub, because right now somebody tries to run them. They're a mess. Like what's demo specifically. Like this. Yeah, there's a slight. I was a problem with the XO demo right there I was broken to I think the XO right so just like documentation and probably primarily Docker issues. Yeah, most likely it's probably just you know there's a disconnect between something changed in the documentation was never updated or you know somebody forgot to build the Docker container or something I think it's mostly stuff like that. Well, the nice, the nice thing to report here is we have all of the website stuff is actually all hooked up and like commits emerges that repo will update the live site and stuff, which is one of the more recent things that we that we did is converted over to charcoal and stuff and made it accessible. Before it was very hard to deal with, but you can actually just go into the doc repo and just run. You have to install just first and then you can do just run and then you can run the site locally and work on it. It's very easy. Okay. So I'll table that one for now and hopefully this starts getting itself out over time. High priority bugs or issues anything that we needed to talk through on that. The needs to be handled fairly quickly. Anybody have any of those. I don't think so right now. Keep that as an agenda item always. Yeah, and anything on an open discussion that we want to talk about that we haven't talked through is monthly a good. Go ahead, Sean is throw this out there. So our current life maintainer policy. I think could use a revision. I think primarily in in two ways. I think the first is defining some inactivity period by which we might retire maintainers, if we cannot easily contact them to ask them if they want to be maintainers. Or just a period by which like, you know, we've kind of defined the period so that, you know, no one is offended. If we change their standards and rules around that the current the current policy is ask which is is I think the best policy for folks that are that have a lot of knowledge that like we would rather be we would rather keep on the project than eject from the project because if they do come back they come back with knowledge that that maybe the rest of the group doesn't have. And so to be very careful about removing people that fall into that category. But at the same time, feels like we have a lot of inactivity on folks that are unlikely and probably don't have that level of knowledge. So that's first thing. The second thing is making it clear about kind of the criteria by which we add new maintainers. The current current process is all of the maintainers vote. And that leaves a lot of ambiguity because, you know, in our heads we have the criteria the criteria is something like you have to have been committing in the project for a long time you have to you have to be following all of the community rules all of the pull request rules all of that, you know, before, before we would add someone as a maintainer. And so my thought is, you know, instead of leaving it ambiguous. We should probably document what the expectations are, make it more concrete so that it's achievable. So I am probably going to draft up. And I'm thinking that this is like something that we just added the website terms of like here's what our rules are that would replace the current process. But also make it like very kind of explicit. Kind of on both on both ends. And so, mention it here because it would be great if people have thoughts about what that should be the duration of time of involvement before before like adding maintainers, the duration of time before retiring maintainers. I think that is as important as I, as I write this up. Okay. Any other thoughts. Good. Just to throw out the note is that apparently, according to hyper ledger anyway you're supposed to put the rules inside of the maintainers MD in the repository, which makes sense. Yeah, we can link it there for sure. And lastly, a month from now, a good time to reschedule the next, or schedule the next meeting. Yeah. Okay. So we'll put the next right. Can you help me schedule that for the next meeting. Yeah, I think it's already set to be recurring but I will check. Perfect. So, I'm just kind of the kind of stick the stuff together so we get going. If people have thoughts, let me know. Other than that, I think we're done for today, trying to keep it at one hour. Any last thoughts or that's it. Okay, thank you everybody.