 Hello, everybody. Hello. Hello. Hey, Francesca. Long time no see, I'm at. Yeah, they've been keeping me busy. But I think that the next, I think I'll be at ECC, if you're going to be there for our next. Nice. We should, we should definitely then organize some specific like protocol panel that might be good, you know, like post merge. Yeah, I can ping ping me separately I think we have a lot of topics we can discuss but it would be a cool time to. To organize for sure. Thanks everyone for joining. We're going to give a few more minutes. Yeah, there's an agenda that was just pasted into the chat. The item is in specific that I've placed in there, but we can talk about whatever. We also have some new folks on the call. So maybe we can do some intros and answer like any kind of Q&A. I see new faces. Welcome everybody. You see faces I need to fix my zoom. Wait no faces names and let's say that. Well I'm missing the link for everybody. I'm right now on mobile but Matt you want to share the link we can go through I think like there were a couple of points, but not that much so we probably like to be sure. Yeah, I'm, I can just honestly share my screen if that makes sense. We're still having folks come in so probably wait another moment or two, but I'll still share the screen in the short and the meantime. Whoops that's huge. Oh geez, not still getting bigger. Okay. We can always get started and then as if people join we can go. So we have some new folks on the call. Does would anyone like to volunteer to go through intros. If not, I can start for those that don't know me. I'm Matt Nelson, I work at consensus as a project or product manager. Sometimes it feels like a project manager for the basic team at consensus and I see new faces on the call. I'm definitely eager to help out folks contribute. What have you. So let us know how we can help. Next. Oh, good. No, go for it. All right. Yeah, I'm Gary Schulte. I'm on the chupacabra team at consensus which has traditionally been a main net focused basic team although consensus now has a broad main net focus all of the all of the basic teams of consensus have been focused. Yeah, I've been working on basic for about two years now and on discord, my handle will often be suburban dead if I haven't already changed it to my full name. And yeah, feel free to ping me with any kind of questions you've got I end up typically doing just because of time with the time zone works out I do maybe about half of the releases release and focused a lot on the storage layer at the moment in basic. Sounds good sounds good. Very. Yeah, Francesco here I'm part of the devil team at consensus I'm helping out with with those like computer call and doing some housekeeping and yeah I'm just excited about everything that is around the protocol and busy related to me. Yeah, around like, you know, agenda and and other awesome things. I will pop for now to Justin. Hey, I'm Justin Florentine protocol developer on basic team work for consensus. Let's see, we're gonna for for for mostly these days. You can find me on all the things as Robocop scon man. So, welcome to all you new faces. Hi, I'm George it's a brand I'm part of what we love so I'm a backend engineer. I'm, I start working for them like one and a half year ago. And now my main responsibility is the way to jail library. And I was I mean I joined another contributor school but that was long time ago so I'm pretty new. Also, I did the PR like I contributed to best and I have my mostly I did with it every day. I can go next. So I'm on this show. So same from web three labs and contributing to web 3J and be so yeah so have couple of yeah PR as much. And yeah, looking forward to contributing more. Okay, Fabio from working on consensus as well join it one years and a half ago. My focus has changed during the battle with the main net during the year. Laterally, I'm working mainly on transaction pool stuff. And yes. Welcome to your. Join us. Yeah, hi everyone. I'm from the piece with team at consensus. I am focusing mainly on the performance work and the memory issues. Welcome everyone. I'm down a fair and I'm a swirls labs. I've been working on basic for a while now. My focus is even performance and EVM upgrades to the EVM object format. Yep. Hi everybody I'm Daniel, I also work at consensus is a practical engineer. I joined around one and a half years ago. Also, I think. Hi, my name is Matthew Whitehead. I'm in the UK is you may be able to tell from my accent. I work for a company called collider. And I contribute. So far I've contributed primarily to another hyperledger project called hyperledger firefly, which is a middleware stack that runs against any Ethereum chains. And I'm interested in becoming more more involved in best to contribution. I haven't contributed anything yet. As we sort of try and understand how it can be a good fit for our enterprise customers that we have more of a focus on permissioned and zero gas sort of environments. But today I'm here really just to listen and learn. And yeah, I've been spending the last 10 days trying to get up to speak with Bessie generally. Awesome. Welcome everyone. Thanks again. Oh, Nishal that I you speak up. I'm not sure. I don't mean to put you on the spot. Yeah. Perfect. Okay. Yeah. Thanks everyone for joining. Hopefully these meetings continue to get bigger and bigger as we get more folks on board. I didn't go through the housekeeping before but there is a Linux foundation antitrust notice. Basically just be ethical, have fun. This meeting is recorded and we put all these meetings on the wiki, as you might know, and just stay muted and use appropriate things. So as far as release updates are concerned, 23.4.0 is out. There's a ton of changes that I won't go through. A lot of changes around main net. Some breaking changes on privacy. So for those in the enterprise side, definitely go through and release. Read this carefully. There's removal of go quorum compatible privacy features. And also we are planning on deprecating the go quorum compatible permissioning in the next quarterly release 23.7. This one isn't as contentious because we frankly haven't even documented that basu is compatible with go quorum compatible permissioning. Partially because we don't necessarily want people using it. But we will be deprecating in 23.7. And we removed IBFC one as well in this version. 23.4.0. So I'm not sure what. You know, a lot of the enterprise folks are using they should be on IBFT two or KBFT. In general. We haven't discussed too carefully what a migration path looks like from IBFT one. That's something we can definitely discuss. I don't know if consensus would be able to build it ourselves, but we definitely would be able to support any kind of. Approach to migration. Also IBFT two to QBFT migration path might also be useful in the long term depending on. What people's networks are using considering QBFT is what we're kind of pushing as the most production ready. And you know the most current consensus algorithm on the private network side. And you know the most current consensus algorithm on the private network side. Some other stuff on performance and changes. Some EVM performance improvements, regular performance improvements, RPC updates. Memory fixes an update to rocks DB eight. Yada yada yada fixes for zero base fee. And then we can go into the bulk of our stuff today. No, I mean, a few days ago I started to update web to JEPM to your, I mean, I started to do the update to this new release version. And I noticed that. From all the components. The best. So if I'm not wrong, best internal crypto. It's still pointing to the older version. Can you, I mean, do you have an idea of why it wasn't also that one release? I mean, to have the same versions as we have so far. And the EVM stuff. Yes. Because it should be pointing to the current stuff. That must have been some, some release bug that, that crept through. It should be at the same version as everything else. Okay. Okay. Just a second because I should have the link somewhere with the Maverick. Yeah. And I was looking inside there and I saw only 23.1 if I'm not wrong. We did change the name of some of the crypto things to make it external 23.1. No, that was this. Post details. We'll sort it out. It should be using the current. There's no reason for it to use. I'm out of sync versions. Okay. Once I found it, I would just base it here in the chat. Maybe it wasn't updated yesterday. And that's why it failed on it. Try to get the dependency. But anyway, it was just for curiosity. Would you mind posting that in the release channel? You know what? If you post it in chat, I'll post it in the release channel. That way it's capped captured there on discord. Okay. Awesome. Diego is not on the call. So. I don't think we really need to discuss five through three zero. We missed it in the 23 four release, but we'll put it in the 23.4. Dot one release. What one aspect of five, three, three zero is that we were potentially going to do a fast follow for that. Is that are we going to. Do a 23, four one follow up. So that we can get that in since that. Does break sync for. Ethereum classic. And anybody doing a full sync of main net, I think also. I think that sounds warranted. And then if we also missed a release on native, we can do that as well. Yeah. And there's dependency bump too. That's Sally put in yesterday. Right. For the graph QL stuff. So it could be, it could be worthwhile doing a quick check. We can discuss. An expedited schedule would be a Friday burn in release with a next Wednesday release for 23, four one. If that's what we want to do. Cool. Yeah, we'd have to finish up the PR. So yeah, yeah, exactly. So we definitely don't want to rush it more than that. But yeah, we can discuss in the release channel. I think that is warranted, especially with the graph QL dependency bump. I don't know how many folks are using it, but definitely want to fix that. Vulnerability that was disclosed in the dependencies. Cool. Where was this graph? Vulnerability disclosed. Let me, it's a, sorry, it was in the. A user actually put in an issue for a dependency bump. I'm trying to find it. Here we go. I'll paste this in the chat too, Dan. Yeah. So it's just a generic graph QL machine, not something targeting Ethereum. Oh, no. Yeah. It's, it's a. Like a consumption resource consumption. Situation. So definitely can bump it up. And since it's not enabled by default, it's not super critical, but definitely want to get this. If we're doing a fast ball of release, we can definitely include this to bump and Sally's already opened a PR to update these. Does that include the withdrawals fields in it? Or is that something I would need to look into? Cause I know there have been some changes to the spec to turn on some of the withdrawals and other stuff added in Shanghai. To the graph QL. Spec. There's no way it'll be ready for the fast follow. So it's no need to get it in this Friday. Okay. Yeah, no, I, I. And those are related to the high failures. There's high tests for these new features now. Yeah. Gabriel was working on. Some of the withdrawals failures. I don't think we're specific to graph QL, but we can. Probably push that to 0.2. Oh yeah. That's fine. But yeah, if I'll, I'll reach out to Gabriel and discord and have him post an update and see if they, there's overlap. Hey, back to the wiki. No wrong wiki. Cool. Also, there is a proposal here from Simon. He captured the details from last contributor call on his proposal to avoid cherry picked releases. His new proposal is basically to avoid cherry picks. I'm going to give two. Like a minute. Folks want to just read this. It's not very much text. And then we can discuss. I think this is essentially is. A different way of saying, let's get rid of release candidates. I think yes for the quarterly. But for the point releases, it's. You know, releases are from Maine. The only thing that comes from cherry picks, like by, by a process is released candidates. I think this is essentially a different way of saying, let's get rid of release candidates. I think it would be reasonable, honestly, to, to skip the whole release candidate process in favor of just having a release from Maine. That we have a public beta of that we burn in, so to speak, for a bit longer and alert the public, anybody who wants to test ahead that can help us ensure the quality of a quarterly release. I think that would be a reasonable strategy as opposed to, if we're trying to avoid cherry picks and the complexity there. So the flip side of avoiding cherry picks is sometimes you're going to have to freeze people out of submitting these domain line. And that's very problematic. I agree. I think cherry picks and release candidates are a useful, useful process to have. I don't think we have to have them all the time. If we don't have something that. We're worried about freezing somebody out on, but. I think it's a good tool to have in the bag. I'm going to keep notes here. Yeah, I mean, I agree with this, but I would not want to have to like, we create a situation where we are reverting PRs. Potentially at like as a counter to the kind of RC process. So which is more of a pain, right? I don't know. That was more of a question. Yeah, I agree with that. I agree with that. Ripping code out is from what I've gathered the reverting, reverting certain things is just relatively simple from what I've gathered, but it's. I think one of the artifacts of the chair of the release candidate process is that we end up with these release branches that we can always use. As a way to backport fixes to prior versions. And that's, that's really useful to have in my opinion. We could probably still do that without release candidates. If we're going to abandon the whole notion of release candidates, then maybe what we should do is. Get off of our current. Simver. Releasing cycle and just say, you know, this is Calver and if you want to be current, you need to be on the latest one and then we're not going to backport bug fixes. We haven't really been backporting bug fixes. Much either way. We've done the thing where we, well, I think what we've done is the. Additional point release on top of a stable release branch in addition to the quarterly. I think some CVEs we've actually backported, but that's, that's a pretty rare. I think that's the only case I can think of where we've actually done releases on prior. Quarterlies. So when there's a hard fork on main net that kind of blows everyone's prior version support up anyway, because you have to advance forward to support Shanghai. So that's the main net. So, so Semver already doesn't really work well for a main net client. Yeah. And there's been, you know, we've discussed a couple of times, not necessarily a different release strategy for private network releases, but. Some kind of either like a rubber stamp or something similar. Because I think you're right, you know, it doesn't really make much sense with the main net releases. And frankly, with the velocity that we've had on kind of main net versus private networks, like it doesn't make as much sense for the private networks either. I think that my preference would be that we've coalesced on a strategy that works for both. But basically loosely favors main net because I feel like the majority of the changes that go into the client each release are either tailored towards main net or are specifically, you know, kind of related to that. If we see more contribution from the, like private network code base, I would argue for something different, but as we gain steam, I think it would be better to just kind of collaborate on what that would look like. Maybe some of the enterprise folks on the call, because, you know, I don't know how many of your users are picking up quarterly releases or even releases every two weeks for our updated beyond something with a 22 in front of it. So I can speak from our point of view, and that's really that we have a SAZ offering. So we update to releases that we have sort of validated and we know are the right release for, you know, we're not going to break existing customers, that kind of thing. So we cherry pick releases much more than the average user I expect. Gotcha. Does the Calver, sorry, does Simver help you at all? Like the quarterly releases help with that? Or is that just immaterial and you're going version by version? I don't think it's super critical particularly. I think, you know, we're going version by version, certainly from the point of view of paying close attention to breaking changes and checking if we have customers, for example, an IBFT one that is obviously one of the most current sort of breaking changes that we have to be aware of. So yeah, I don't feel like it adds a huge amount of sort of value in and of itself right now. That's good feedback because I think that the only the only reason only justification I can think of for doing Simver is for stability for enterprise releases. So if our enterprise customers don't see the value in that there's going evaluating on release by release, then we can simplify things. Yeah, what would your proposal be Gary? Basically just go to Calver release more like Tech who does where you release when you're ready and you don't worry particularly about release candidates and cherry picks and backfording. I think that for for large changes for we could potentially still have a longer burn in for significant changes and open public beta anyone else. We'll need to flesh out the governments of who decides when and what required participation is. Yeah, that's the good counterpoint is that with the with the kind of two week release cycle, there's no arbiter to your point Gary. Like the tech team decides when it's ready because it's kind of a centralized entity that can decide those things. Right now we've just had kind of a rough consensus on basic contributors or basic release channel. I mean, I would advocate for trying to maintain that rough consensus because oftentimes we can create a bunch of process that doesn't really benefit us. It doesn't benefit, you know, not us. I mean, this is all basic contributors and basic users. I guess I would just advocate for consensus within discord and open to counterpoint. So it would all have to be in public this has burned us before where consensus decided in their own realms and with their own tests and for their own standards when releases soup and when it's not to the exclusion of literally every other contributor. So that is, you know, why these processes have been proposed is because they have been abused in the past. So that's the one thing that needs to be considered in any of these processes is how those abuses will be prevented. I think at minimum we could discuss the removal of December, just move to more of a caliber type structure where instead of these kind of quarterlies where we shove everything in because I don't I think to the point of most folks is that localizing the kind of breaking changes and some of the more like speculative improvements on the quarterlies doesn't really seem to do that. And it just kind of oftentimes delays the quarterlies to the to two plus weeks after they're intended to go out and it just creates development. It makes development at that time kind of a pain that could be you know what is that a step one and then we could discuss once we're on kind of a more caliber based structure. I think it will be more flexible to move around from that kind of two week cadence. So I think it's a great idea to think about how we could gate releases on get up because right now any contributor can do a release and it's it's really only needs two people if you're going to do a PR for it so I don't have any I don't have a great idea for a great experience on GitHub about how to gate the release process but it seems like that would be the way to to to force some level of consensus. So unless we're going to put you know like some multi key thing on there or whatever I don't think that we can really block the release software. Just we do have to see when we see violations that would go back and yank privileges would be the solution there. You do a release out of out of you know out of spec then you lose your commit privileges. That's why a lot of places do it. But I think there just needs to be a strong commitment that any and all discussions about releases must be in public and must not be done in private and any standards must be done in public and there must be a consensus grown of all the contributors rather than one team pushing through their will, dropping over the express dissents of other contributors. Yeah, completely agree. I don't think we've had any situations like that recently that I'm aware of. We just had some six months ago, so that's recent. What was what was the issue. That was the merge the merge. Right. Yeah. Okay. I got places to go. See you. Bye. I was a bro. Goodbye. It is at top of the hour. We can pick that one back up I suppose. That's too bad. I was hoping he'd be around for this next discussion. Okay. The other things yet we want to discuss two items that might require honestly, well, there might be some input on the on the last bullet point from folks in the call. We're thinking of. We're trying to decide how we can best kind of abstract, but architect some of the consensus formats so that it's easier to maintain the code base long term and not have to have to have to have the same kind of consensus mechanism like POA or POW. Basically to in order to better serve proof of stake. So, you know, there's a few different approaches and we could have some more. Context provided by the team. But, you know, what we're thinking through what it would look like to basically pluginize some of these consensus mechanisms or. But we don't have any Ethereum classic reps on the call today. Any context, maybe that someone wants to add here from our team or another team. I saw Matt, you came off mute. Yeah, I came off mute, I guess. To ask for a bit more context, just to understand a bit better. What's the situation with plugin ability in Bessie in that area, if any today. I know Bessie has sort of plug in architecture for other sort of features or capabilities. Yeah, I was just interested in a bit of background or context on it really. Yeah, absolutely. So the plugin system exists to allow a bunch of different things basically to sort of overwrite default values, but also to extend functionality of certain modules. So, you know, we were thinking through what it would mean to have the consensus modules as a plugin so that the interface lines are very clean within the code base and we don't have to lean so heavily on kind of like the names, network configurations and the Genesis file to do a lot of this stuff. The reason being is because there's oftentimes unintended consequences of changes that are meant to. Impact Ethereum mainnet that trickle to other areas of the code. And then when things break. Oftentimes sometimes much later on it becomes a question of like who did it, you know, what's the reasoning and who wants to fix it, right? So, you know, this could be, you know, now that we have this thing called the engine API that allows us to kind of influence the way that Bessie runs execution through the EVM and through other areas. We were discussing, you know, how can we take advantage of that and the plugin architecture to basically just remove the consensus algorithm as like a hard kind of dependency and make it more of like a pluggable kind of mechanism. I don't know if I'm missing any context. Gary or someone else. Yeah, I can. I think the notion that we were discussing was basically a mechanism that would allow us to have first support for other networks and consensus mechanisms without polluting the code base with a lot of special cases. And as the number of L ones and L twos that are EVM compatible proliferate, just not end up with a huge mess within Bessie. So the goal would be. I think to have, we've got a couple of examples of a non mainnet uses of Bessie and we're adding them currently that we're thinking we could have provide a paved path for how to support a non mainnet. Configuration and consensus mechanism. Via the plugin system. So that's kind of the notion. It's really just a notion right now, but it's going to, I think it's going to be a problem in the future as we as basically tries to support more and more networks natively. There was also the idea to take advantage of the engine API, you know, to drive or the consensus stuff. So the engine. Engine API right now is mostly RPC and like plugging into a merge consensus. So I think we would probably, there'd be some work there to abstract the engine API even to, to extract that into a plugin interface that we could use, but I think that would be a good strategy. Yeah, it would, it would maybe not be a plugin. It would really be that maybe the consensus that there is like similar like a mainnet. There's maybe a separate consensus client or a separate separate process just for the, just for the consensus. But then of course you always have to run to two processes. Not just one. Just an idea, but then taking some notes down. Yeah. I'm sure that it would be interesting to say the least. I don't know enough about the POI consensus mechanisms to see where and how they would take advantage of the engine API basically, or if there's enough functionality. Yeah, they're quite, they're quite complex. I mean, it's just, I mean, if, if, if we do a plugin or we do a separate client, I mean, in the end is more or less. I'm not sure I mean the work is maybe similar to to extract everything in another place. But yeah. Yeah, the first example or two will probably be the hardest ones and then we have a paved path for others. Okay, we can revisit this when we have Diego to discuss. I think proof of work is probably the big first big one that we would want to think about. Okay. Yeah, adding networks to base you process and governance, I think. I'll, you know, I'll contextualize what this is, but I think we also might want to wait for Diego and Dano to return as they're probably the biggest consumers of non. Ethereum. Or basically private chain networks. So the, the. The discussion point around this is like, what is the process to add kind of name networks, names, networks to base you and to the point of what we just were mentioning, as Gary said, you know, there's compatibility within base you at a, at a main line with. You know, things like Ethereum main net private networks, Ethereum classic, etc. But as kind of L2 types network proliferate networks proliferate. What is our process for providing kind of built in configs within base you do we want to do that. Do we want to push everything to the plugins. Do we want to use kind of that engine API consensus plugin approach because an L2 is basically just in many ways a, you know, another consensus mechanism built on top of this kind of Ethereum state machine. So, yeah, I don't know if we're going to get very far on this call with these folks, but that's what this is I'll probably leave it for the next discussion, unless there's any. Anyone that wants to chat with through what this looks like. I don't know that we need to chat through what it would look like, but we might want to chat through what a process for it could look like, you know, so for instance, do we come up with like a software architecture design and then try and get some buy in from it. Asynchronously, because if we keep saying like, oh well we don't have the right people here. We're never going to really move forward, but I think that we could, you know, write some of this up and run it by the people that we think might have opinions on it. Okay, so we could write it up offline on the consensus with the why side. Well, I actually think we should do it in the wiki. No, I don't think we would take the lead for that because I don't think that anyone else would do it in the wiki for sure. Yeah, yeah, yeah. And then, you know, drive discussion around there and then, you know, when we do meet here. All right, yeah, that's a good, that's a good bullet point Gary, we should add that to like, you know, a loose list of goals to treat as an outline for what we are trying to design here. I'm just just one input I remember from one of the other execution clients from Aragon. The team that was working on the Binance chain, added the network as a PR to Aragon. So they didn't have to do anything. But afterwards they removed it again because they were left with the maintenance. So if any user had a problem, they also claim of course to the Aragon team. So we also somehow, I don't know. When we include the network, we have to be aware that the users will come to us if there's any problem with it. Even though I would argue that this plugin approach protects us from that. Like you could create, you could create a plugin system that represents the network. And then it's up to, you know, the plugin authors within reason, obviously we think we could potentially break things that would that would break the plugin contract. But I think it does minimize that responsibility surface quite a bit. Yeah, I agree with you actually Justin. Now the one, one curious thing about the plugins is that they need to have like, maybe I'm wrong about this, but don't they need to have their like, basically the check sums like in the code base hard coded, or there's like a rollup of all the, the hashes of like the individual plugin packages that we store somewhere. Yeah, well, it's the plugin API specifically, which is probably a good thing, you know, because that's that's what the plugin developers if you're building a Binance chain plugin, let's say you're going to, you know, you're going to use that API hash that we generate to make sure that, you know, we didn't make any changes. That is a very old mechanism though, and I think that the scope of it needs to be revisited and re-evaluated to make sure it's correct. Taking one third. Yeah, there's going to be investment, I think in in pluginizing various things from various dimensions if this is an approach that we want to go into. So what I'm proposing the doc is not just a software design, but also processes design, organizational design, documentation design, etc. that we kind of at least need to get a list of Wow, this is going to be a big move with big upside. And here's what we think the bill is going to look like. I like that I'll make sure that we touch on just taking notes. Yeah, I think we can take a first pass at the wiki at some point and then reconvene in this group. Chat about the next steps. Yeah, I mean, I think this is these two bullet points kind of go together as just like an overall evaluation of the plugin strategy. I think that. As we look, we're kind of moving the client in multiple directions, right? We want to focus focus as much as we can on like the base use case, which is building all the functionality kind of separate from a consensus mechanism. So the EVM, the networking, RPC, etc, etc. And then where we have those kind of difference points is where we need to think through the plugin stuff. So I think we need to just take a hard look at the plugin system and see if it's going to meet those requirements anyway. And it would be good to get that input. But yeah, cool. That's all I have here today. Does anyone have anything we kind of have like an open open section now we can do Q&A. We have some new contributors on the call that you can ask us any questions process related. No one has questions or comments. Okay. I'm just going to do a quick little walkthrough of some labels that we have. Those in the enterprise private network side. We've been tagging all of our issues that come into the GitHub that are not directly related to mainnet or public networks with this non mainnet tag. So if your users are experiencing specific bugs that you're not aware of, or if you hear something from support channels, it might be worth perusing this label. Right now there's only four issues that probably isn't fully accurate from our 222 open issues. But from as far as new issues are concerned, we at consensus triage with labels, we don't like, we have also a Zenhub board that everyone can get access to. Let me know. Me or Rai Jones from Hyperledger know if you need access. Maybe not Rai, but I don't know. If you're having issues, ping me and I'll figure it out, getting access. But we mostly do our triage here. If you see these team labels, also don't worry too much about them. You're fully welcome to pick up literally anything you'd like or to ask for any context. We use these team labels internally at consensus to try to decide how we want to best organize these issues. But again, they're very open. It's not necessarily intended to be exclusionary. It's not necessarily intended to be exclusionary. There are other labels that are useful to call out. Of course, the mainnet label, good first issues label. And doc change required. If you make some updates to the code base that requires changes to the documentation, use this label on the PR. And the documentation team at consensus will review the PR and change the appropriate documentation. You can also use the PR code for an RPC. For example, if you change the format of an RPC or if you add a new RPC, something along these lines that will require documentation, just put this label in and it will trigger kind of some automated processes on our side to make sure that we include that. Let's see. Yeah, it's kind of it. Yeah, there's privacy permissioning labels also. So let's see. Let's see. We have a new PR code. This is a 25 prioritization matrix. I have it in a Google doc right now. I'll actually put that on the wiki. For folks to review as well. If you're looking to triage bugs against this. This all also might help raise awareness of things that consensus might need to jump on. Depending on what the use case is. If it's an old yet critical bug. That someone is trying to address in a private context. Yeah, that we might need to provide context. These might be helpful. I'll take for action to just actually post my post the prioritization matrix that we use on the wiki. Or updated if it's already there. Gary, I saw you came off mute. Do you have any comments on this? Nope. Cool. Any comments or questions from the contributors? Actually, I have one question. So actually there's one issue in non minute. That's regarding private transaction tracing. So like what will be the priority for that? And like if you have any, you know, tips or anything. So like I've just started, you know, contributing to a base or so. If there are any tips. Yeah, this. Any tips on getting. Go ahead, Justin. Sorry. Yeah, as far as just like general contribution. There is a section in the wiki that covers that. I haven't reviewed it personally, but if you see things in there that are ambiguous under the priority or for that issue. As far as we're concerned, probably not like I'm our process before we will review any. Code that is generated. We also can, if you have questions, we'll obviously provide any context. So. There's also people actively working on tracing APIs, not private transaction tracing, but it's going to be fresh in some contributors minds. So if you want to maybe if not pair with something, pairing would be ideal, but just kind of having a. A DM conversation or a thread with somebody who's actively working on it would probably be beneficial. Okay. Okay. Yeah. Yeah, I'd be happy to make myself available for pairing if that's going to work out. Yeah. Yeah. Yeah. Yeah. Yeah. Put a question in that base channel also. And yeah, we'll DM in case or find an issue. In the distributors channel. Yeah. The contributors channel. Sounds good. Thank you. Any other questions? Any other questions? And now I was going to say just especially that I might have a look through some of the good first issues just because it's always nice to get your first PR under your belt. Right. And also on the, the, the plugin architecture discussions that around consensus plugin. I'll be very interested in how that progresses. So if there are discussions again, I can listen into or, or. Yeah. Discussions to be involved in and then I'd certainly be happy to sort of participate in those. And I guess related to that. How does process work in terms of sort of scheduling. Calls and, and is there a, is there a repeat invite for the contributor call? Or is it just a case of keep an eye on the. The wiki for, for when calls take place. There should be. There's a hyper ledger calendar that has. Hyper ledger events and. These are my weekly, right? With alternating time zones. Yeah, there's, if you go to lists, lists.hyper ledger.org. Then you should, you can subscribe to like the basu group. And then you can make, you can subscribe to the calendar as well. And then they'll pop up in your, in your calendar. I think this is what I did. And if you use Google calendar, I don't know like what you all use. You can just copy this URL and it should just pull in. And that's kind of what I used to track, but yeah, it's lists.hyper ledger.org. You might need to make like a new account. I don't think it uses your L F I D. Thing, but you know, whatever you need to do to get on there. And then any, any basu related calls will show up in the, the basu group. Under your groups. That's great. Thank you. Yeah. That's what I was missing when I had a look. Like a few days ago and, and in terms of, are there like working groups for sort of big ish features? How do they tend to get arranged? Yeah. So we've done working groups for forks in the past. So we had like a king or a Shanghai specific channel in the discord where we have kind of working groups around that. I think that that's, we can basically continue to create new channels around large buckets of work to organize however we'd like. Typically we just use the contributors channel. And create threads in there. So the basu contributors channel and then we can, you know, pretty much all of the contributors check that regularly. So if you have a question or if you're trying to organize a bucket of work, that's one way to do it. There is ways to do it on the wiki, but I, they're kind of not effective because you have to like meticulously update everything. I think that kind of more of the communication and discord is better just because people can chat back and forth as opposed to like creating endless documents. But yeah, I think it just depends on the feature. We kind of have organized around big buckets of work typically and not necessarily on feature development because that seems that tends to be isolated to the team that's working on it. But I'm open to new suggestions depending on what it is. Yeah, no, that makes sense. Thank you. Yeah. I'll answer some questions I had here. Any other questions here? If not, we can give some time back. All right. Thanks. I will post the notes that I took back in the same agenda. So if you were looking at the 20 2359 contributor call link, I will modify this with the notes there. I'm just going to share this link one more time. Just so that everybody's got it. It's the same link Francesca shared. We put our notes back into the kind of like agenda items. And then we're going to move on to the next section. Thank you so much. Awesome. Thanks everyone. Thank you. Thank you.