 All right, welcome everyone. This is the weekly TSE call. This is a public call open to everybody. And again, when I say everybody, I mean it. And just because you're not a TSE member doesn't mean you cannot participate and speak up. If you have valuable information, please do speak up. So there is a couple of requirements for you to participate though. The first one is to be aware of the antitrust policy notice, which is currently displayed if you're online. We all need to be aware and live by that policy. The other part is the code of conduct. And again, you should be aware of that. If you're not, that's not, please have a read through it. It's pretty simple. So with that done, let's move on and start with the agenda. Is there any announcements that I don't know? If not, there is a couple of, well, there were a couple of reports due. There's one that was submitted, the basic report. I posted a couple of comments that were responded to. I haven't seen any others. There is a couple of issues that are probably worth taking up, especially so they're actually two. One has to do with rocket chat and the challenges. These represent for the team. And the other has to do with the request to move to active status, which will take separately because I added a separate agenda item for that. So let's talk about the rocket chat issue. Grace, you're on. You want to talk about it? Hey, everyone. Thanks for having us. Yeah, so I think we've raised this a couple of times. So it's nothing new. Don't want to be the dead horse. We just have experienced kind of some more friction to last quarter of onboarding some of the Ethereum tuning to rocket chat. We have. We have been working on things like that. And that was kind of. Investigated, but not fully. Maybe linking to Slack or Gitter to our rocket chat. And we haven't made a decision yet if we're going to do that or not. But we might consider the next quarter to help kind of. Ease the transition point. But that's kind of our. Go forward plan at this point. from the team? How does that work? Yeah, so we've been working with Brian, the community team, to kind of think through what, you know, how we would integrate it. We're not sure exactly at the moment how to do it, but we have been working with them to, yeah, to, I guess, hopefully figure it out. Okay. But let me understand one thing that wasn't clear from reading this text. Is your plan to have this kind of linkage so that people can use either and they would appear? What's the, I'm not sure I understand the end goal there. What kind of linkage are you making more? So essentially, we would have, you know, everything would go to RocketChat, but you could also enter through another chat channel. So there would still be the record and that would be the record within RocketChat. But if someone wanted to ask questions, let's say in Flack or Gitter or something like that, they could. Okay, so that would be forwarded to RocketChat. Exactly. That's how we would hope it would work. Yeah, yeah, no, I understand this needs to be worked out, but that's the plan. Okay, I understand. Thank you. Hey, Grace, is a lot of your traffic on those other channels because that's what the community is? Yes, or so we don't currently have any channels set up for those. Previously, when it was Pantheon, we had Gitter. And that was where we were seeing a lot of the traffic, different Ethereum community projects used Flack and or Gitter. And that's what they're currently familiar with. We are the only project that I know of within the Ethereum community that uses RocketChat at this point. But Dano can speak to that a little more than I can. Yeah, it's mostly Gitter and Telegram and the new one. They started up a Discord server for some of the Ethereum 2 stuff, and they bridged their ETH2 Gitter from the Discord server. So that's throwing another new one in there. But I think the plan of bridging from Gitter to RocketChat by directionally is probably the easiest one. Okay, but that would give a more accurate picture of user traffic and things like that. When we're able to link them together, we see more realistic of what's going on in your community. Yeah, that reduces the friction because to chat on Gitter, you only need a GitHub account. And he uses that to authenticate who you are or a Twitter account. There's no extra step of having to go with an LFID that is only used on RocketChat. And that's the main source of our friction. Thank you. So what was I mean, are these users primarily or contributors? There are some contributors, most of the users. The friction we have with contributors is educating them in the ways of the DCO. And that's not a reasonable ask to get rid of. So we're just teaching them how to do it as best we can. Okay, because that's what I was going to say is like for contributors, they have to have an LFID anyway. I haven't seen that you need an LFID for a DCO. You just need to add that mind to your commit, right? Oh yeah, you're right. The way we have it today, that's right. We talked about making it part of the process. But I just, I mean, for me, it's kind of, you know, when I started working on Hyperledger, I got an LFID and that was it. So I don't know why it's a big deal for people to do that. So the tricky thing is we're trying to bridge into a community that's not just Hyperledger. Ethereum is quite large. There's a lot of random contributors. We're starting to move into more of those random places that are out there. Because there's a lot of people who are very committed to Ethereum that have never interacted with Hyperledger. And those are the people we want to bring in. And if they see that little bit of friction, they will say, no, I'm good. So we want to reduce that friction. Well, so wait, wait, wait, wait, wait. So I get it. I totally get it. But we aren't turning this into Ethereum. This is a community that is a part of the Linux Foundation. And I don't think that we're just going to throw that off just because we want to get a few people from Ethereum to do a two minute exercise to get an ID. That's ridiculous. And maybe we can make it easier for them to do that. I don't know. I mean, if the LF is up for that. But seriously, that is just, it's not an excuse. It's a really lame one. It takes two minutes out of your day. That's it for the users, not the contributors. And for a lot of people just on the slides of the friction, we'll keep them out of hyperledger. I mean, you can say it's a lame excuse, but that is the market that we're tapping into. And that is the reality of what it takes. All right. Well, so if the bridge can be made, you know, I think this becomes smooth. So it's okay. But I also feel like to me, this seems such a small price to pay. It's hard for me to believe that, you know, I would be turned off by that, but I can see how this is the case for some. So in any case, let's hope that this solution works. There's a bridge that can be made so that people can use whatever they prefer. You know, when it comes to tools, though, I have to say we can never settle on any common tools because there's always another one that somebody prefers. So it just named a whole bunch, right? Discourse, Instagram and whatever. It's like, so that's just the way it is. All right. So let's, any, is there any other questions about the Bezu report from anyone? Okay. If not, we can run. Yep. Go ahead guys. Here, no, sorry. One thing that I realized I left out in the original submission that I just wanted to raise the TSC as well is just that the security audit for Bezu is completing tomorrow and we should be receiving the final report then. I didn't have that in the original, when I originally submitted this on Monday, so just wanted to call that out to you all and we'll be, you know, sharing the results. And that's run by Dave and all of it. Yes, Dave, exactly. Dave and the Tivore is the firm that is performing it. Yeah. Yeah. But so it's through the iPod Azure. That's what I was asking about. That is correct. It is one of our audits. Okay. Thank you. I just like to say I'm glad to see that they're working more with the community with Caliper and things like that. So they are integrating themselves into the community at this point, which is great. All right. Thank you. Okay. So let's get back to the agenda. As I said, Caliper is missing. If anybody is involved in Caliper and could make it happen for next week, that would be appreciated. So with that said, we can move to the second part, which was highlighted in the comments of the Bezu report, but which I wanted to take on independently. They do raise the fact that they have got more maintainers and have increased the diversity. And they would like us to reconsider their request to move Bezu out of incubation. I have asked them to update the proposal. So we have a bunch of documents from the agenda. I link to an issue from the decision log, which itself links to the proposal. And the proposal has been updated quite recently over the last two days, I would say. But I appreciate the effort, both Dino and Grace helped out there. And so it reflects the latest status. But I don't know. I'll be happy to listen to everybody who's there, what they have to say. My reading of this is essentially last time we've discussed this quite extensively. There were two aspects that seem to be kind of being in the way of approving this request. The first and foremost was the lack of diversity, especially when it came to maintainers. And in general, it seemed a bit rushed. And in particular, they were not fully integrated with the hyperledger environment, using the tools and all that and the likes. I have to say, I feel like they've been diligent at trying to address all the issues we've raised. And at this point, it seems to me that, you know, they have checked all the boxes, and they are good to go. But so I would like to open it to to the TSE and ask if anybody has any questions or comments in this regard. Nothing? If there is no comments, then I suggest we just have a vote. I'll fuck on that. Do you want to roll call vote or no? Yeah, we might as well do a roll call vote. Okay. And the matter of Bezu, actor stats proposal, Angelo. Sorry, I'm fine. Was that a... Yes, that's a yes. Okay, Arno. Chris? Yeah. Dan is not here. Gary is not here. Hart? Yes. Mark? Yes. Nathan? Yes. Swetha? Yes. Tracy is excused. Troy? Yes. Okay, the matter passes. All right, congratulations. Welcome to the club. All right. So with that being taken care of, this leads us back to the discussion item of the agenda. It's the same one. I do want to highlight a couple of things before we get into this. So there are a couple of issues that I think we could make progress on, and I tried to shake the tree last time, but somehow it didn't happen. There was the plan for the governing docs issue with the GitHub repo. It seems like everybody was in agreement, but nothing happened. We were supposed to have a formal proposal put before us. And the other one was the security reporting policy. It's the same. I think I would appreciate if the people in charge of each of these items could take the half hour or 15 minutes to text to put the proposal on the wiki so that we can put those to rest. So I am working on the governing docs thing. You all may have noticed that you were added to a TSC repo at GitHub, and all the TSC members were added. This is, I'm working on it. I promise. So. All right. Very good. Thank you. I appreciate that. I did notice the notification on the TSC report. And I'm working on the security thing. And it came to the conclusion that I'm not sure that it needs to go before the TSC. There's not going to be any significant changes to the way we report security issues. We're looking deeper into the cost of using GitHub issues in general, but that's an entirely separate issue. In terms of security advisories and security bug handling, there really isn't much of a proposal here. I mean, I'm willing to discuss in further detail, but I don't think that it should really bother, it should concern the TSC. And that's totally acceptable to me, but then, you know, we need to, so should we just drop this issue from the decision log and say it's abandoned or it's become irrelevant or whatever is the right characterization? Yeah. I mean, at least in terms of reporting security bugs and handling them, yes. I'll detail it to the TSC mailing list if you'd like, exactly how I got to that conclusion. I think I owe you that. Because it may sound silly to you, but the authors, but you know, for me, it's like, I'm looking at the decision log backlog, and there's this issue and I'm like, okay, what can I do to close this, right? Yeah. So if you hear your way out that nobody's going to scream about, I'm good. Okay. I will go on to the decision log item and make a comment in there explaining the logic and just saying, I no longer think this is an issue. How's that? All right, sounds good. Dave, can I ask a question? Yeah. Well, a second question. Will the changes you're proposing require anything different from the projects? Or is it all internal behind the curtain kind of things? It's internal behind the curtain kind of things. It really concerns just the volunteers on the security team. Okay. Thank you. Then yeah, I was just going to say, you know, if you could at some point highlight the changes, but if it's all behind the scenes then. Yeah, I'll explain it on the decision log item. No problem. The people this really affects are the people who are on the security mailing list. Yeah. And that's the audience really. Okay. Then yeah, I'm fine with what you're proposing. And Rye, I had a question for you. Is there anything we can do as a TSC to help you? I know you're swamped with a million things on the previous issue. I am waiting for some guidance from Brian on exactly which documents to bring over. The pieces that I guess would help is taking a strong position on the format, like Markdown versus RST. So that's the only thing that would help really. But I don't know that that needs to be chatted about here. And then approve pull request when I start sending them in. All right. Anything else? There was an announcement that I think Dave Hughesby wants to make. Oh, Dave? What was that? There is an announcement that should have been at the top of the call. It was a very important announcement. Are you talking about the calendar one? Absolutely. Why don't you take a victory lap on the calendar? I wasn't going to bother anybody. But yeah. So I've been contacted by a number of SIG chairs and group maintainers over the last month, right? Ever since we moved away from Google calendars over to groups.io, we've been plagued by a bunch of nagging issues related to, hey, I scheduled a meeting and now it's not showing up in the community calendar, or I scheduled it and it's not reflected in the community calendar very quickly, that kind of stuff. After weeks of investigation, we tracked it down to, yes, this is definitely a problem with the groups.io platform. And with Rye support and Brian's urging, we went through LFIT first because I think there's some relationship between LFIT and groups.io, but ultimately we went to groups.io, filed a very polite bug report. And as of two days ago, their fix has been launched on groups.io and it appears to have fixed all of the issues that we are seeing. So I asked that all of the SIG chairs and working group chairs and all of the project leads or maintainers to go and double-check, you know, if it really concerns you, if you've been running into issues, just go double-check that all of your events that you've scheduled on your groups.io group are now showing up in the community calendar on the wiki. I've gone through it myself and it appears to be correct. And I've emailed the people who have emailed me recently about bugs and they have all confirmed that it seems to be fixed. So this is huge news and thanks, Rye, for poking me with a stick. It made my day yesterday, actually, because we were faced with having to move back to Google calendars and I was not at all excited about that. But now we don't. Anyway, we're sticking with groups.io. You guys, your calendars should all work out. All right. Thank you for the announcement. That's good information. I'm glad that this was sorted out. So let's get back to the agenda, long-term agenda. So we spent a couple of calls talking about this last week. We actually had an interesting presentation that was right on spot when it comes to discussing, you know, how we could position the different pieces one would need for hyperledger blockchain framework that is generic enough that people can take pieces here and there to suit their need. And I thought it was pretty thought provoking and interesting. And so there wasn't much discussion after the fact, though. And I still haven't seen any discussion on the wiki. So I would like to turn back to the TSC today and ask if they have had the chance to think about it if they want to share any thoughts or comments on what we heard or the issue in general. Don't all talk at the same time, please. I think I agree with you. It's a very interesting idea and approach and, you know, especially with cloud-based services and things now, everything is going more modular, mix and match, microservices, all those other buzzwords. So, you know, I think Dano brought up a good point at the end that, well, it really depends on the execution model of what you can mix and match together, things like that. So I think there's a lot to look at. I don't know, you know, if we want to address it as a TSC or if we want to have someone like the architecture team go look at it, or just let things run their course, you know, was the proposal that we should all go and break up like fabric into different components that can be pulled in? Or just a general suggestion that that's the way to go in projects? So that was certainly for myself, but, you know, it seemed to me, I mean, this is what the issue really is about, is what is it that we want to do in this regard? And do we want to go down the route of, you know, that was kind of sketched out by this presentation and define this kind of high-level architecture where we identify components and how they might interact and identify further down the different pieces of work that could take place so that we enable this kind of integrations or not. And, you know, we can do it in different ways. We could say we're going to, you know, just put some kind of high-level recommendation that people are free to ignore or take it at heart to start tackling, or we can just put of a foot down and say, no, this is hyperledger. We want to enforce some kind of convergence. And we have to discuss how we would go at this. So to me, this is what this all discussion is supposed to be about, is what could we do and what do we want to do about this topic in general? So not too long ago, we had this huge kerfuffle over working groups versus task forces. And, you know, I think that the general consensus was that working groups sort of working independently of and sort of, you know, trying to do this sort of the top-down view of something weren't going to be effective. And we chose the approach of task forces, which really were targeted pieces of work that, and again, I think the important, you know, tweak was that involved projects, right, looking to do some piece of work collaboratively between them, you know, whether that was to adopt and integrate a new API or a common API or whatever, but to do a piecemeal and not try to do some big top-down architectural set. And I'm still very much, I mean, again, we have, now we have, what, four active top-level frameworks, none of which have anything to do with the other. And this is not going to get fixed by coming up with some architecture and then trying to force fit everything into some high-level architecture. It's going to get fixed by teams getting together and looking to figure out ways that we could get to the sort of Lego approach that we're talking about. And so, I mean, I think the important thing is that you want to essentially set that that's our end goal. It may take us three years to get there, but that we want to start getting people serious about collaboratively working together to try and solve those problems incrementally rather than trying to come up with some, you know, architecture to rule them all, because that almost never works. Right. All right. Thanks, Chris. Yeah. So I'll say I agree with Chris that sort of the top-down working group approach hasn't been effective. So I guess the question I have in response to that is what can we do to sort of put people who are working across similar things on different projects into communication? Because this to me at least seems like the most effective way to solve this problem is that if I'm doing X for project A and you're doing X for project B, you know, we need to know about this and, you know, know about each other and then we can potentially discuss collaboration at that point. Yeah. So I think in this regard, I mean, one example that was given last week, which is like, you know, the consensus algorithm. We all have some and they often are pluggable in some ways, but they all use different types of APIs and whatnot. And would there be a possibility to have a common API so that all the project can reuse some modules? And it seems to me that one thing that is achievable for the TSC maybe is to identify those potential, you know, areas of collaboration. And it doesn't mean we have any ways to enforce it or we even want to force prizes to work on those. But at least highlighting what we think those are and inviting the community at large, you know, to look at those and maybe, you know, try to facilitate some collaboration, I think maybe something the TSC could take up. Yeah. And part of the way we want to talk about this is this is not it. We're not giving the maintainers a task list or, you know, a list of chores that they need to accomplish. What we're trying to do is we're trying to set out position pieces on here's where there's good overlap. We're trying to inspire more contribution and more collaboration. So I think part of how we want to set the stage for this is we want to make sure that we get folks like has been said before that are working on overlapping pieces to write something about how cool it would be if we can, you know, accomplish a certain vision or we can give something a try that maybe no one's tried before. Thanks, Nathan. Who else? Any other opinions or agreement? So I guess in a container world, it's not as important. But, you know, we have, it seems like every project picks a different language to work in. So, you know, what, how much stuff would a user have to add to their machine to run something that has go and rust components and C++ components, you know, maybe most of the runtime stuff is already there. But it just, you know, we need to look at things from that perspective too, I think. But then again, if you're all separate containers or, you know, identity or, you know, the crypto libraries are in their own container that you just called and maybe you don't need as much stuff if you're doing a rest interface or something. Guess I'm showing my age. No, no, I think, I think that's a valid point. And unfortunately, you know, it's kind of like the discussion we had earlier about communication tools and my point about, you know, some will prefer telegram and others prefer rocket chat or Slack or whatever. And the same is true for programming languages and whatnot. Ideally, we would, we all agreed on one license would have been nice to have one programming language would make, you know, this kind of collaboration much easier, but it's not going to happen. So we do have indeed to live with that and find some ways to accommodate. Yeah, the programming language is, you know, is an issue for a lot of things like we would love to try to do some fabric or integration, but sort of the go see interface is a real problem for that. Well, and this is where, you know, inspiring contribution is important. And we've been looking at in the rest community, they've been looking at how to bypass or get around the go see or the seago limitations in order to make native calls more friendly from rust to go. And there's some interesting things that could be done there. It's a question of, you know, getting that problem exposed to where someone feels like they can work on it. All right, anything else? Because then, you know, for me, it seems like we all feel like, yeah, there would be some value in doing this. Then the question becomes, okay, practically speaking, how do we go at doing this? It's not so easy, is it? No, but we don't solve easy problems. We let those for lesser people, right? You know, I think it was hard who was, you know, talking about it. We need a way to know what's going on inside each project, you know, so we can identify areas that are currently both being, you know, worked on in separate projects. And people can at least talk, you know, developers for each or architects for each can each talk and figure out what, you know, maybe even just define a high level API for that component. So that in the future, it's easier to integrate if the need comes up or if the desire comes up. So there needs to be a communication vehicle there somewhere. And not sure, you know, is that projects talking to each other more or, you know, is there some team we have that sort of digs deeper into each project? I don't know. Jimmy, this is really the hard part, honestly, because, you know, we've all been advocating cross pollination, coordination, you know, cross projects activities for years. And it just, you know, it has happened in some cases, but not always as much as we would have liked. And I think it's fundamentally hard. And so I honestly don't know what to propose. We actually do practically speaking that will get us there. We can keep preaching, but that's only goes so far. So I know this is Andrew, I was feeling these minutes about what's what's essential in each of these hyper blockchain, blockchain systems, so you can take fabric, you can take Bezu and so the most fundamental thing they are doing the system is to build the truth, right? So they build the ledger and the ledger is the source of truth. But this thing is necessarily not compatible. They do this in a very different way. And the only way to make them to get to communicating is not saying, hey, you have to to now speak my language, or I speak your language, we have to find a third way necessarily. Because I was thinking, okay, what if fabric uses doesn't make sense if fabric uses as ordering service Bezu, just as ordering service, and then for execution using some some other thing, it looks to me that it would be a waste of resources. So why using Bezu there's much more complex machinery just for the ordering, the ordering service. At some point I was thinking maybe we should cut all this project, we should not have these monolithic systems that do all the things they do execution, they do ordering, they do validation, they do this, they do that. We should really have only the components, but much smaller. So I don't know, cutting fabric or having a component that is only able to handle the ledger. Another component is only able to handle the ordering service. Otherwise, there is no other way. I mean, how can you take to make this whole monolithic system communicating, you have to develop a protocol that build trust among people who are speaking different languages. This is the task that you want to solve. And probably there is a project, we have an upper ledger somewhere is implementing some of this interconnection, right? So these are the things always, either we cut everything in modules or we push for this system, these Esperanto languages that will allow different blockchains to communicate. That's the way I think. So thank you, Angelo. I agree with you and I don't think, I mean, what you just described, the ordering service, let's take this as an example. I think it's a good one. It's like, I think this is exactly the proposal that James and Bill put forward last week, or Barry, and it's like, they basically said, yeah, we would like to have all these pieces independent and be able to combine them the way we want. And I don't know that, and this is really what is before us, is their desire to go that way. And how do we achieve this if we want to? How do we break these things up? And I don't think it's by radically saying, okay, tomorrow there's no more like all these monolithic projects, it's more along the lines of what has been done with indie where you kind of like break some pots out and say, okay, we're going to make this component more general so it can be used by other projects. And, you know, like we've done with Ursa or Aries. And maybe there's a way to externalize the fabric ordering service. And you say, okay, if you want an ordering service, here is one. And you have to define the API at the right level so it can be used by different projects. And then, you know, so this is really what I think is in front of us is, you know, what would it take to go down that route where eventually fabricants say, hey, we don't need to maintain the ordering service as part of fabric anymore, we use the hyperledger ordering service. And then other projects can do the same. And, you know, step by step, you can go towards this system where you have a set of components that you all use. And there may still be some like secret source that's specific to each project on how to put those pieces together that fits different needs. But at least as you know, but at least they share a lot more code. That's right. I will say that fabric in a sense is going this direction. If you say that they are splitting, there is the fabric process, the fabric chain code, the fabric, then still the monolithic piece that puts together ordering execution and blah, blah, all these things. No, sorry, ordering validation and blah, blah, gossip and all these things. But it can really be modularized. It could really go that way. But this is up to each project, I guess we cannot force them to say you have to cut this in pieces. Well, and I really think what this gets to is we're trying to maximize the usefulness of our code and how much utility our community can provide. And modularity is a means to that end. And when we start talking about modularity for its own sake, we get lost. But if we talk about modularity as making pieces of code more useful and making it so more people can come and contribute to that code because they need it for something, that's where we grow the community and we've done a good service. And so what we're trying to do is we're trying to identify chunks of code or chunks of architecture that have common utility across the platform and then make it obvious that those things have common utility to try to get more contributors to those pieces. Hey, there's a couple comments on rocket chat as well. I don't know, Bobby, do you want to speak up or James? Sure. Hi, everybody. Just the learning material group is trying to collect like documentation. And if you take a step back and look down on this, I think if everybody gathered the same type of documentation, it would be easier to compare and pull out what commonalities each one of these projects have. So the learning materials working group could help out in that if that's just a position. Thanks. Thank you, Bobby. And James, you posted the document. Can you tell us what this is about? Sorry, I was trying to unmute there. So this document was from the actually, it's up on the architectural working group for Hyperledger. So I pulled it from there. I think it looks like somebody tried to attack this a year ago, but I think the concept is exactly as whoever talked a minute ago. There are components that are being rewritten two, three, four times that if you're able to pull those out and have the people working on those and each of those projects together, you'll end up with one component, you'll have more people to work on it. You'll have a component that can be shared across the group. And that's really what you're trying to do at it or what we would like to see out of it is components that actually can be shared across. And it didn't even have to be in Hyperledger. It could be a different blockchain altogether. But we extensively, before our National Science Foundation grant, looked at consensus and we looked at how it was done within the Ethereum for Enterprise. We looked at fabric, we looked at what it was doing and saw to. And the commonality is probably 75% of the 80% of the functionality is the same across all three of those. All three of those allow a variety of consensus mechanisms. Then what if they were using a single component that cuts quite a bit of programming out and now it allows you to move faster within your own project as long as you're able to use it. It's what the working group was doing or the group has been doing in SaTooth and then the Splinter group that went off on the side. They're moving all the networking components for their Splinter and SaTooth into a single component so that we have two projects using one set of networking protocols. And it shouldn't matter on language I think language, at least that I've seen over the few decades I've been involved in and programming has become just a what everybody likes to do. The last two large projects I did had seven or eight languages intermixed within the entire program because we were using a variety of different things we downloaded off the web. I had a bunch of different people working for in different languages. I don't think that's necessarily anything that you would ever want to do because languages are changing very rapidly and can be adapted. But I think it's really about how do you share time? How do you make it so that you probably have a better consensus mechanism coming out if everybody's working on one way of doing it than you do by having three groups spend a fraction of the timeline. So that's what we were after and I think it was well said earlier. All right, thank you. Any other comments? Troy? Who's speaking? Go ahead. I was trying to. Dana. Go ahead. So in that document that was shared that second diagram I think is going towards one thing that I think we kind of need to develop which is an OSI type stack. You know they got that for the networks and the like for example one thing you can do is you can take out the physical there, you can use wires, you can use wireless. So I think that's a bit longer term vision for where this this stack should go but I think that's the sort of integration that we would want to move towards. All right, thank you. So I seek a little bit of chatting on the channel and you're gonna be good to verbalize those unless you guys prefer we hang up and then continue the chat. Oh, sorry. I guess I made the comment on the chat channel that these modules we talk about, these Lego bricks, I think too much we focus on sharing among frameworks and I think there's a bigger topic that is how can I build my customized solution built up from these Lego bricks. So I don't think it's just about framework sharing code but how do I actually build my custom solution and that custom solution being a customized fabric or a customized other framework but I'm just not familiar with fabric. Yeah and I think this is the message I heard last week in the presentation right they do want to have their own way of putting all these pieces together. I just think that you know setting as a first goal to be able to have these components shared by different frameworks is is a move forward into that you know in that direction. Right so Mick asked in the chat if I might sort of share some of the reasons why we're not using transactive fabric. We initially thought oh this would be cool we can share a common transaction processing mechanism that the challenge of course was that transact actually bites off most of what the fabric here does. Not all of it but a lot of it and so what ended up instead of just having sort of a pluggable transaction processing engine that had an API to a ledger we ended up with the full validation pipeline that was redundant with what we already had and a schedule order to schedule the processing of those transactions which we already had and yet it didn't solve the complete problem because we couldn't just sort of throw everything else away and adopt transact because it wasn't doing all of the things that we needed. Right so you know the challenge there was I think it was a poor approach to you know coming up with this sort of modularity if the focus of transact had been exclusively on okay so you know you know if you were to sort of carve out the piece of code that's essentially doing what the EVM and what you know hyperledger fabric chain code and what the sawtooth you know transaction family thing was doing just do that and maybe you know adopt a new approach that people seem to be evolving towards in terms of wasm that that might have been the thing that we could then use as a way of carving out the need to have all these different approaches but again the problem was that it was essentially becoming the new engine for sawtooth and so there was no desire at all for fabric to essentially integrate all of this for very little value right because we weren't going to be using the schedule or we weren't going to be using the validation pipeline we already had one that it was didn't it didn't meet our needs. Yeah so that that sounds a bit like what the situation in Jillo was talking about earlier where you know you wouldn't want to use the whole Bezu framework to just do the ordering part and it has to do with you know where do you draw the line between the different components so that they are actually suitable for many different users and maybe this is an area where the TSE could get involved in trying I mean the project should probably try to figure out is there a better API than the one like Transact you know has today or but but if not the TSE maybe could could help here in identifying where to draw the line between the different components I don't know. I don't think there's going to be one per one for the whole stack I think each component is going to connect to the different layer in a different way and I think that's part of the difficulty it's figuring out what the connections of each layer should be for example for spark contracts one thing you could do is you could use host functions inside a wasm and use that as your connection but when it comes to consensus that's not really a something that's easy to do. So you know the one thing that I think you know if there were a single area that you could carve out and say this is an area that we could actually start working on collaboratively and adapt to our respective platforms and that would be the SDK right how does an application interact with the underlying blockchain framework and you know if you were to take something you know along the lines of let's say web three just for get some shiggles here and expand that to be able to support you know larger payload sizes and so forth that we're needing to do some of the things we're doing around supply chain and yada yada yada then and come up with a you know a single API that could be multi-lingual you know we could support it in Java and JavaScript and all the things then you have a common way that you interact with the underlying platform people building applications have certain additional amounts of choice and then you know they can you know we can differentiate and so forth underneath then as you you know then once you get past that then you start to think about well we could all share the common set of protos or whatever to interact with the underlying you know the back end platform and then start consolidating and then working your way in rather than trying to sort of decompose something that's already got inertia and I think that that's again the kind of thing that potentially has the most promise going forward so that then we can just be you know maintaining a single SDK with you know some adapter to the various back ends that could eventually be just a single SDK with a common set of you know a common protocol that we use to interact with the back end that kind of thing makes much more sense than trying to figure out how do we do ordering because again ordering is not something that is as Angela said it's not handled the same in all of these different platforms it's completely different right and so as a result it's not clear that we can necessarily just tease out an ordering API because they are so different yeah and then there's always you know every searching for performance and those things tend to come in the way of performance right if you have a very generic API you're not going to get basically the best performance out of it so there's an incentive to do more built-in functionality for some of those things at least but I agree with you at the API the SDK level I you know I actually I forget who I was talking to about this recently I look at the latest fabric SDKs you know they're not different than many others it's like at the end of the day what do you do you know you connect to a network and you say okay I submit a transaction you wait for the receipt and there are different variations but you know a few more things but I can write a fabric API that application that submits a transaction in less than I think 15 lines of code now and I bet the concept being touched on by the different calls in these 50 lines 15 lines is very generic and applicable to pretty much any blockchain framework so all right I think this is a good discussion we have five minutes left anything else anybody wants to say before we close all right if there is nothing I'm happy to close with a few minutes to spare but I you know I think we I find that you know quite frankly when Dan brought this up initially I was like oh my I don't know where we go with this but he did acknowledge well this is not something I expect to be solved in a in a couple of calls but I do find the discussion to be interesting so I'm happy to continue I do want to say there are a couple of other issues that may not be as exciting in some ways but I think would be useful and for those of us for those of you who were at the Hyperledge Global Forum and so my my keynote there I touch on some of the issues that I would like us to also tackle as part of the TSC now that we have pretty much closed all these other issues that I have to do with trying to harmonize the different ways the different projects conduct themselves in terms of okay what does it mean for instance to be a maintainer what's the process to become a maintainer to remain a maintainer maybe to you know deprecate or whatever we call that like a retire I should say a maintainer and I think there are many other things like this we we agreed on a common repository structure and I think that this is a good thing and we should continue down that line and try to tackle other aspects of how the different projects conduct themselves because they would benefit the community at large we have a lot of people out there we're trying to understand what those different projects are about how to interact with the the community and the more harmony we have between how the different projects behave the easier it is for people to find their way around and I think it makes sense for us to tackle those issues so you can expect from me to have this kind of to bring these kind of issues in the decision log and try to get us to to set some guidelines it doesn't mean we have like a one way and this is mandatory every has to do it that one way but I think we could at least try to provide some recommended way so that if projects don't have a strong feeling they could adopt something that's more common than not so with that being said I'm going to shut up and close the call on this so thank you all for joining good discussion talk to you next week good bye