 Okay, thanks. Welcome, everyone, and good morning, good evening, good whatever. So we have a fairly light agenda. We've got an update on the Hackfest doodle poll that Todd conducted that he'll review and give us an idea about when and where we may be doing our October Hackfest, and then we've got a proposal from Babel to incubate a new project, and we'll go through that. We can decide whether or not we're ready to vote on approving it or people want to give it more time than thought and so forth, but we'll certainly have plenty of time for them to introduce the project and answer any questions that we may have. So Todd, do you want to take it away? Yeah, sure thing. So in terms of the next two Hackfest, we ran a doodle poll for the upcoming US Hackfest. The most likely dates look like the week of September 4th or the week of September 11th. We'll certainly try to do this on Tuesday, Wednesday, or Thursday just to make it easy for travel. As of right now, we have a couple of venue options in Chicago. I think the initial request was for East Coast. So a couple questions. Are there strong objections if we were to do this in Chicago? And then if so, if anyone has venue space at your companies in the New York or even Boston areas, please get in touch with me on that. Otherwise, we can look to move towards a paid venue space if needed. So just quickly from September 4th is Labor Day, right? I believe so. So we would certainly avoid that. I think we were just looking broadly speaking at weeks at this point as opposed to specific days. So from those on the call, is there any stronger version if we were to hold something like this in Chicago? Or is the preference really to be very much on the East Coast? This is Dan. I was actually going to be looking into some space around Minneapolis, but I got sidetracked on some other projects. No worries. To the extent that Minneapolis and Chicago are different for people, that's another option here. All right. We'll poke around with a few other contexts that we have to see what turns up in New York and circle back with a few options just to get this locked down. We're still about three months out, but we'd like to get this done as soon as possible. And then the other component is we are looking to bring the final hack fest of the year out back to Europe. We did this in Amsterdam last year in October. Trying to hone in on some dates there. Please take a moment to complete the doodle poll. Let us know your preference on dates. And again, we'll move through the funnel and figure out a suitable time and location for this. Any questions? Otherwise, we can move on to the proposal for today. All right. So Martin in Yakimo, I will make you presenter now. If you have any slides you'd like to run through. Okay. Sure. Thanks. It looks like I have to download an extension. So are you going to present charts or do you just want to walk through the proposal? So now we have a small PowerPoint presentation. I know the conversation has already started on the mailing list. So I don't know, do you want to jump straight to the discussion or go through the PowerPoint presentation? Oh no, I've got charts. That's fine. Feel free. I mean, like I said, we have the full hour here. That's good. That's great. Can you see the slides? Yep, we can see it. Yes, we do. Okay. So yeah, first of all, thanks everyone for considering the proposal. Well, it just gets straight into it then. So what the project, the name of the project we're bringing here is Babo. So it's a distributed consensus component. So I'll explain quickly what Babo is, why we built it, and why we're applying to Hyperledger. Then I'll give a quick overview of how we built it and which projects we think we can integrate with that are part of Hyperledger. And finally, the status. So where we are in development and the resources that have been put into it at this stage. Okay. So what is Babo? Babo is basically just an ordering system. So it's like a black box where we input transactions and it takes care of broadcasting it to other participants in a permission network. And then it feeds back, it outputs the transactions back in consensus order. So that means that all the participants that receive these transactions can be sure that all the other participants are seeing the same transactions and receiving them in the same order. So we're using the hash graph algorithm, which is a Byzantine fault tolerant in the sense that it tolerates up to one third of faulty nodes, including malicious behavior. And finally, it's a loosely coupled modular solution in the sense that the interface between Babo and the app is over TCP sockets. It's a simple JSON RPC interface with just a couple of endpoints. We'll see that later. And so the fact that it's abstracted by a TCP interface makes it possible for the two components to run in separate processes or separate machines. So why did we build it? So first of all, we're presenting this project as a company. Our company is called Mosaic Networks. We're based in London and it was founded a few months ago. And so basically what we're seeing is that peer-to-peer and peer-to-peer systems and distributed computing in general is gaining traction. And we think that we're going to be seeing more, let's say, mainstream apps running on top of distributed networks, so I mean distributed systems. And so in this context, there's going to be a need for dynamic consistency or consensus algorithms. And so our goal as a company is to create easy to use plugins that provide these consensus algorithms. Now we also realize that the technology is new and it's not very mature. And for it to become mature, there's going to be a need for specialization and standardization, just like it happened in other industries where companies focus on a specific feature, let's say, of the technology and do it well. And then they'll get together and define interfaces and standards to make sure that all the bits fit together. And Hyperledger seems to be leading this thing and putting together projects and experts and trying to make them all work together and come up with standards and code that is ultimately ready for production use. And so that's kind of the reason why we would like to get into Hyperledger. So our solution is here we provide a simplified version of the drawing that's presented in the document, in the proposal. What we really want to show here is how the app and Babel work together. So what the interface is really, as you can see, it's a very simple interface with two endpoints. The app sends transactions to Babel via the submit transaction function and Babel sends back transaction to the app via another endpoint. And Babel takes care of sending the transactions to other participants and it runs the hashgraph consensus algorithm to order these transactions. So the hashgraph algorithm was published, I think, last year in a white paper by Lehman Baird, so it wasn't invented by us. And as it's been raised, it's been said in the emails that have been exchanged lately, it hasn't been peer-reviewed yet, but there are some proofs in there that the system is Byzantine fold tolerant up to one-third of nodes. And it has another very interesting feature, which is fairness, which means that it's very hard for, since it's not leader-based, it's very hard to manipulate which of two transactions gets added first in the consensus order. So this is something that's important for certain specific types of applications, like a stock exchange or a game, for instance, or such things where it matters, which of two transactions gets considered first. I can go later into more detail about the solution if anyone is interested, otherwise, what I can add, it assumes for the moment that it's a closed set of participants where we know upfront who the participants are, but this is not a limitation of the hashgraph algorithm, this is just for the moment the way we've implemented it, and it's possible to extend it to add or remove participants on the go. It's also, yeah, so the code is on GitHub and it's written Golang and licensed under the Apache version 2 license. So we think how we're going to integrate with other hyperledger projects. So there are two projects that we know that the interfaces are logically compatible, in fact, they match almost one to one, that's fabric and borrow. They were architected on purpose for modular consensus and we've been looking at the code for a while and we know they're compatible, there's a bit of work to do there, but they're compatible. And also, Tooth Lake, it wasn't obvious how the interfaces would match, but obviously we have no problem with working on that project as well, eventually. So yeah, these are the three projects we think we would integrate well with at first. And then I think what's interesting is that in the process of doing this, we'll probably find commonalities and things that are similar with all of these platforms, fabric borrow and Tooth Lake, especially around configuration and the configuration files, the way you define what the validators are, who the validators are and things like that. And it can be standardised. So the process of actually trying out the same consensus plug and with all of these three solutions will probably can start this process of finding commonalities, I think, and making a first step towards standardisation, which, if I understand correctly, is the goal of Hyperledger. Yeah, and finally, I think Hyperledger also would benefit from having in its portfolio a solution for a consensus plug to choose from when the clients decide to set up the LT with either fabric or borrow. Well, one of the algorithms, the consensus algorithms they could choose would be Babel. And so where are we at now? So yeah, again, as I said earlier, we're in London where there's actually a vibrant community around the blockchain and especially is driven by banks really or the financial sector. And there's also so a lot of meetups, really, really a lot of energy in this space. So we're now going to, we're now hiring people actively and we want to participate in the open source community and part of that is also potentially joining Hyperledger. So yeah, that's all we've thought right now. So we're open to questions. And if there's anything, any of the slides would like us to go into more detail, please let us know. Thanks. Thank you. Any questions from the peanut gallery? I see a couple of thoughts on getting the paper from human peer reviewed and so forth. But any questions for Martin? This is Dan from the TSC. I appreciate your responsiveness on the email list. I think we're able to work through a few things there. I do still see that there's a probably general interest in getting more clarity on the algorithm itself. And I think since the project is essentially the algorithm, I think we could spend some more time during this meeting with you walking through the algorithm that might help some of us. I see Hart has a specific question there too about the big O on the messages. Yeah. Hey guys. Thanks for the talk. So I had a quick question. So I was skimmed through the white paper last night. And when I looked at the message count, I got N log N. Can you guys tell me how you get N? Well, for a message to, let's say for an event to get committed, there's this concept of a witness being strongly seen. So in the best case, the best case scenario for a witness to be strongly seen by another participant is if the message goes through, the events go from one participant to the other in order. So let's say there are four participants. And the first participant syncs up with the second participant, the second goes with the third, and the third goes with the fourth sequentially, and then the fourth back to the first. Then the first strongly sees the other previous events. Do you see what I mean? Yeah. So my thought was kind of this was like the coupon collector problem. So correct me if I'm wrong here. So kind of the way hash graph works is the first player in the first round sends the transaction or message or whatever to the second player. And then in the second round, the first player and the second player send a message to a random person. So it kind of propagates like this. So after there's this like exponential growth in the propagation. So my thought was this was exactly like the coupon collector problem. Are you guys familiar with the coupon collector problem? No, I've never heard of it. So the coupon collector problem is the following, right? So suppose like, I mean, I guess mathematicians in the olden times didn't lead very exciting lives. But suppose that you're like, you know, getting a coupon in the newspaper every day. Yeah. And there are say 10 coupons in a set, right? And you get a random coupon in the newspaper every day, right? How many kind of days does it take in the expectation to get a full set of coupons, right? And so here basically we want we want everyone in the graph to see the transaction, right? Yeah. Since people are sending kind of people are sending transactions randomly, essentially, right? Some people are going to get duplicates, right? If there were no duplicates, it would be order n, right? But if they're duplicate, you know, the duplicates might mess things up. And it turns out that I believe this is isomorphic to this coupon collector problem, which has, which takes kind of n log n and not n. And so I was curious about this. Does right analysis make sense to you? Yeah, it makes sense. It makes sense. It's a good point. So I think when I said or when I said order of n, that's the best case scenario. And I think if I understand correctly in the problem you're describing, the n log n is kind of it's an average. Yeah, it's in a mathematical expectation. So it's probabilistic. So maybe you're right. Ultimately, the average number or the expected number of messages per round, around the ones that are defined in the hashgraph algorithm, maybe is n log n. Maybe you're right. Yes. So that's the messages, right? And the expected number of rounds should be log n, log log n. So again, if you're just running this experimentally, you're not going to see this at all. Because obviously log log n is going to be like infinitesimally small for any kind of practical parameters. Okay. But it's probably worth going through the mathematical analysis of this rigorously. I also had a question about fairness. So you guys in your proposal say the protocol offers fairness. So I skim through the white paper and the section on fairness is there are no proofs. And it's kind of just like mostly things they can't achieve. Can you guys go into more detail on that and kind of present exactly what you mean by fairness and maybe like sketch out a proof or an argument of why you achieve that fairness? Okay. Well, I can try to give you my understanding from what I've understood from the white paper. So the problem of fairness is to say if two people submit, they each submit a transaction, Alice and Bob submit transactions. And Alice submits her transactions before, her transaction before Bob's, then it would be fair if Alice's transaction came first in the consensus order. That's basically how we can put the fairness question. So if the ordering system is just one server, we would say the server is fair if it puts Alice's transaction before Bob's. Now, in the distributed system, it's a bit different. It's not just one server. So for instance, in a leader-based consensus algorithm, it's the leader, the person who is responsible for creating the next block, who has a say or who has the power to decide which transactions get inserted in that block and in which order. So again, we would say that the validator and the consensus algorithm in general is fair if the validator doesn't kind of manipulate that order. It doesn't choose and say, okay, I don't like Bob, I'm not going to insert his transactions in the next block or I'm going to make it appear last or things like this. So again, all these other algorithms, the other algorithms that are leader-based or even proof of work or proof of X kind of algorithms are kind of vulnerable to this attack, let's say, can be unfair. On the other hand, the hashgraph is not leader-based. So basically, what does it mean if the hashgraph is fair? Again, if Alice submits her transaction first, before Bob, there's a chance that since it's a gossip algorithm, if she's connected to at least one other node, then the transaction will, all she has to do is sync up with one other node and the transaction will spread through the network and the event is already created, is already registered in the hashgraph the minute she syncs up with one person. So all she has to do to get her transaction inserted in the hashgraph is to have it, is to sync once with one person. So that's my understanding of why the hashgraph is fair. Does that make sense? Yeah. So I understand why the hashgraph is fair if there's no adversarial behavior, right? I mean, but all of these things are fair if there's no adversarial behavior. So the interesting case is what happens if I have some kind of adversarial coalition? What if, say, Dan and I are together on some hashgraph and we try to corrupt the system? What can we do? So that's mostly what I was interested in and I probably should have specified that more clearly is kind of under what adversarial network conditions are the, is the, or what adversarial conditions is hashgraph fair. And I guess, okay, about the comments. So, Stefan, I'm not talking about rounds. So you get a chance for each coupon in kind of every time a player decides to send a new message. So you obviously get many more chances to get a coupon than one in each round. Yeah, but each message includes all the coupons that the player that sends the message already knows, right? So you not only want coupon code. Sure. But even kind of at the end of the, even at the end of the protocol, that's only going to be like on the order of log n or log squared n, right? You're still going to not know most of the messages, right? They're still mostly known. So, yeah, I mean, so I just skim to the white paper. So it's possible that my analysis is incorrect. But I think this should be like definitely rigorously proven. But yes, I think you're right that for each note, it will still be O of n or less. I think it will be much less actually. I think the bound will be like log n, log log n, as I mentioned before. I think these kinds of analyzers just, I don't know, they haven't been done, I think, or maybe they have, but I don't know, I don't have the background to you know, formally prove stuff like that. I wouldn't know how to do that. Yeah, so it's probably, I mean, yeah, so regardless, I would highly recommend that, like, you guys try to talk to somebody who can help you formally prove a bunch of consensus stuff. Somebody like Marco or Christian or someone like, you know, someone who's a good consensus expert. Because some of this stuff, like proving fairness in the adversarial model is really tough. So I mean, I mean, I think as far as I understand it, like you asked what you could do if you wanted to crop the system. And well, you need to get, you know, more than a third of all participants on your side. And you know, form the plan to have a corrupt entire system. Like if you can do that, you're able to corrupt it. But otherwise, so that's for BFT. And unfortunately, like I'm not a BFT expert, like somebody like Christian or Marco. So I, you know, I couldn't like quickly digest that proof, it would take me longer to go through and analyze. But the fairness, I think you can, I think there are attacks on fairness with a lot less than one third of the network. So do, I mean, kind of how I see this hashgraph protocol is you're ostensibly trading messages for finality time, right? So it takes transactions a lot longer to propagate than if you just kind of blast everything to the network in one step. But you get to send a lot less messages basically. And kind of the, I think that's, that's kind of the point of the algorithm. And the, one of the drawbacks of this is it kind of gives a lot more rounds where people can mess with fairness. So kind of right in round two, like, right? If Alice is honest, her transaction will have only been seen by two people. So if Bob wants to blast a competing transaction, he can perhaps in the same round have his adversarial coalition only broadcast messages to each other. And that way in the next round, they can completely reforge their messages from the past round. And this, this seems like a pretty strong attack on fairness. And so, you know, the white paper doesn't offer really any proofs against fairness. It's kind of just speculation. So I was curious that this is why I was asking the question on fairness. I was curious if you guys had any kind of like supplemental argument for adversarial fairness. No, no, we don't have any supplemental arguments actually. But but you're right. It's definitely questions that that need to be researched more. And could you could you put your idea of an attack on the hash graph into text form? And we probably will be able to take it from there. Yeah, absolutely. I mean, I can't do it now. I mean, but I can probably get to it later today. If you want me to kind of write out what I had in mind, and you can tell me whether it's right or it's wrong or, you know, or maybe it's addressed by some easy mitigation. I'm not entirely sure. But I think the long term goal should be to have a proof. Because if there was a proof, then it would allow me to very quickly rule out or either allow me to rule out my attack or say that kind of my attack is like accepted by the system. Yeah, so sounds good. So I've been trying to get, you know, Lehman also involved into this, like directly. He's super busy. But yeah, so if you can just write something together, put it together, like an idea of an attack. Yeah, sure. I'll be happy to get to that sometime today. Hey guys, it's a big echo there. It's Richard Brown from R3. Hopefully this is an entirely complete trivial question, especially compared to the grilling you just got from Hart. Oh, hang on one second. I know, I know, I'm just sorry. I know there's an echo because I'm logged in on two devices and I was speaking into the wrong ones and beginners were saying. So hopefully a really, really trivial question, which is you showed a simple diagram at the start of the deck where you had the application connecting. I think it was a memorandum of just a rest call to the one of the implementations of the algorithm, which is connected over the network to the rest. Just to understand, the diagram wasn't entirely clear to me. Are you assuming the, I guess, the note to which you're connecting is a member of the cluster? Or is it a proxy to the cluster? And if you scroll to the, there we go, yeah. So you've got this thing called the, from the picture, it looks like that babble box is a member of the consensus cluster. And if so, what are you assuming that you're assuming that that thing is acting on your behalf and therefore you assume that one is not Byzantine and you trust it? Or you're assuming it could be, and you could connect to any at random, but they will then furnish some sort of proof back to your app that the babble proxy will validate to convince you that you weren't just speaking to a representant member. No, so we're not making any assumptions about whether the babble node is Byzantine or not. It's just a direct participant in the consensus network. Okay, so I can connect to any in the network and what it sends back to me with that commit transaction blob call that presumably, and if this is a, this is just a really naive question just to shout me down, but I might do any to assume that message that comes back contains sufficient evidence for me to convince myself that the consensus process did indeed complete and ended with that conclusion. Yes, that's correct. Okay, perfect. Thanks. So I have a question to this, the, the bubble part, this is, this is also like self-hosted, right? Like it runs, like, like the question is there's app proxy, right? So does this app proxy need to be, you know, application specific or can I, can you just use some the same, the same babble kind of building block for any system? Like, do you need, do you need to have this, do you need to change or modify, you know, babble in order to work with different kinds of applications if you make a new application? No, you don't need to modify babble. The app proxy is generic, it just exposes the two endpoints. It receives, it receives submit transaction, it's basically a server, it receives transactions and it sends transactions back and it makes no assumptions as to what kind of application is standing on the other, on the other side. So is there already some, some service, maybe even publicly accessible running right now? No, no, good. Well, the thing is that the bubble, a bubble needs to, to be started side by side with another app. If there's no app, in, if there's no app listening to it, it's going to crash. So we can't just put babble nodes on the cloud and have any kind of app connect to it. Do you, do you see what I mean? It has to be deployed side by side with an app, with an application. Does that answer your question? No, yeah. This has been a question is why, why does it have to be deployed? If you're, if you're having a standard interface and nobody's connected to you, why, why, why does babble crash? Yeah, maybe it's just an implement, the way we've implemented it at this point. So the way it's implemented now, I guess, I guess the idea was that first of all, you don't want to have different apps running on the same, on the same babble network. It doesn't really make sense for, for two nodes to, to run a different app and use the same transactions. You see what I mean? Now we could make it so that babble doesn't break if there's no, if there's no app listening on the other side. That's, I think that's totally feasible. Personally, personally, I think it would make perfect sense to have, you know, just one network, but lots of apps connected to it. And if there's like a block coming in that an application has no clue what to do with it. Yeah, just because it, right? Yeah, I see. So it'd be kind of like a, kind of like an Ethereum type of thing. But then, then there's issues with scalability. There's no reason for, for an app to be connected, to be receiving transactions, or to be sharing the same network as another app. I mean, it depends what you're trying to achieve, really, I suppose. I think if you're trying to do something, whether, if there's no reason to be on a shared network, then there's no reason. Yes, yes, my, my vision, I had what to do with the hash graph, right? Like I had this idea like a year ago already. And then I met Brian Beelendorf and I also pitched this idea to him at the Linux, at the Linux conference, but I don't know. But maybe the time is now, you know, like the idea was to have a public accessible hashgraph that does exactly this, you know, taking transactions from an application and building the consensus order, you know, based on the hashgraph algorithm. And once it's done, sending the commit transactions, commands back to the application, you know, in the consensus order. And, you know, if stuff like this, like if assuming this would exist and is proven to be correct, it could completely replace Bitcoin, you know. So it's basically, of course, the same benefits as Bitcoin or Ethereum, but completely without any mining involved. So no, no energy, you know what I mean. Yeah, that's what you mean. Yeah. So it's public network. But I'm not sure the hashgraph is actually suitable for such a, for such a project is it doesn't actually scale to a immense number of nodes. Other algorithms will be more suitable for that. Like what actually maybe proof of the lab's time or I'll go around. I think they scale a lot better and yeah. So for these types of public networks, maybe hashgraph is not the best solution. I think where it's better, where it performs better is in, let's say, medium sized networks, you know, around 20 participants, maybe more. It also depends what kind of latencies you're looking at. That's true. So the issue I was having when I was, you know, experimenting with scaling hashgraph is just the question how to handle dynamically joining nodes. But what's more difficult is how do you handle dying nodes, you know, like if a node dies, the entire empty don't handle for this case, the entire hashgraph won't be able to reach a consensus anymore. So it will completely crash too many nodes that are dying. That's kind of the open question, like that I'm trying to find a solution for. That's interesting. Yeah, it's true. It's also a difficult question. Yeah, no more questions. Another angle, in the community, is it only the Babel members who are in the community or are there others like, I guess, Stefan or somebody else? How wide is your community? Sorry, I feel to understand. I don't understand the question. Suppose you take all the people who are developing on GitHub under this Babel, is it, first of all, it's open source right now, or is it not? Yeah, it's open source, yeah. So who other than your members of your company are developing on this? No one else really at the moment. We just open source it and yeah, I'm the only contributor for the moment, but that's also why you want to join Hyperledger. Okay, because normally the question asked by the Hyperledger community would be, is there already a vibrant interest in this? If it's just one person, then there are going to be problems if you lose interest, for example, in that project with language. The other thing is, how do you intend to drive interest in the project, which you have to always actively work towards? These are some of the things that I think the TSE considers when they incubate a project. Yeah, that makes total sense. See, until now we've been just developing the prototype, so we haven't been pushing this kind of aspect, but as Stefan mentioned, we've been getting interest though in providing demos and explaining how it works, and there are people who are actually downloading the code and using the code to build demos with. There's actually many among here friends, developer friends in London. I think more importantly, we need to show some direct applications of the program and to show how it's easy to integrate with apps and from there the momentum will build, that's what we expect. Integrating with projects that are already doing proof of concepts out there in real-life deployments, that would be the first step. I think there's a lot of vibrant community here in London of people who are looking to get into this blockchain sector, and so I'm convinced that it wouldn't be hard to bring people into the project. So I haven't weighed in on this, but mostly my thinking sort of falls with where Brian was coming down in the middle of this, and that is I can certainly appreciate the significance and importance of peer reviewing and having the protocol sort of validated as a sort of a gate for adopting something in a business context where you would want to make sure that the risk is significantly mitigated, that it actually doesn't work in some cases, and would then therefore be very disruptive to the business. But for purposes of incubating projects of hyperledger, I don't necessarily think that that necessarily has to be a bar we have to leap over. Maybe for an active project, we might want to hold up a higher bar, but for incubating things that are sort of at the experimental phase and where the broader community is starting to get interest and may want to come in and help to build, I think that's fine. And I think if there's peer review that's ongoing that reviews that, that would be a good thing. And then we have an opportunity where hyperledger participated in sort of bringing that innovation to the market. That's what this project is really supposed to be about. And I think from my perspective, they're really the criteria that we should be looking for. Number one, there was some concerns raised about IP, and that certainly needs to be chased down. If the half graph is encumbered with patents that may present a problem for hyperledger incubation. The second point I think that's going to be important is do we have enough interest in this beyond just Babel, I'm sorry beyond just the original proposers to make a go of this. In other words, are there others in the community that would be willing to jump in and help with the development and potentially also help with working on integration into the other platforms like sawtooth and burrow and fabric and so forth. And then all the other sort of checkmarks that we have from an incubation perspective obviously have to apply. But those are going to be the key criteria I think. And I think also from a TSC perspective, the other existing members of the community need to decide do we want to bring this one into the house so to speak. So I tend to think that this is one of those things that people are going to need to sleep on a little bit. I think this was a useful discussion, very useful and interesting discussion. But I suspect people want to go back and mull it over and sleep on a little bit and get a sense for where this might go. I sense there's a little bit of interest potentially in the community in doing something like this. But I wouldn't necessarily want to, and I think Brian agrees with this, that we wouldn't want to necessarily have peer review be some sort of a gating factor for whether we might incubate a project or not. Of course, if it turns out that there's a significant flaw in the algorithm and the protocol, then obviously we have to rethink what we do with that project. But that said, I think somebody noted in the thread that Well Kafka hasn't been peer reviewed. So it's based on protocols that have been, but it's not exact. So anyway, I'll just put it to that and I'll suggest that we try and wrap up the discussion here and continue to discuss in the mailing list. But Martin and Company, if you can sort of help to sort of reinforce in the proposal. Oh my God, I hate this so much sometimes. Here it is. Sorry. Not just, you know, the what's it about and how does it work and so forth, but also, you know, who else is expressing interest in collaborating on this? I think that would strengthen the proposal. Yeah, that makes sense. So we're going to look at the IP issue first of all and then try to come back with some information about this. So this is Dave. The one thing I saw on the thread that I liked was the idea that maybe this project would be the catalyst for creating a project that was like an abstract consensus machine for lack of a better word, you know, like we could bring this project in as an incubation and we could start moving the implementations of the other consensus algorithms over to it and build a nicely encapsulated consensus mechanism, right? That has a really nice managed API that the other DLT projects could rely on and make it configurable. So it would be a pluggable component into the burrow and fabric almost immediately and then the other DLT projects could abstract or to use this abstract consensus mechanism. I thought that was a really good idea and it would definitely broaden the appeal of the project, I think, and might make it, you know, raised to the level that there would be a lot more support from the community. Yeah, this is Linda Edwin. I certainly agree with her on the thing and what you just said. The only, my only concern is if we are going to recommend it as an interoperable component to module within Hyperledger, we have to do our due diligence to ensure that it adheres to the highest of standards of best practices to ensure robustness because then it becomes a common module within a recommended solution or framework that we'll be recommending to our clients at some point in time. So we need to ensure that we have reviewed the functionality in terms of the standards that have sort of been incorporated in it. We've been talking about the hash graph and others and whether it does so robustly enough to become a component, which would be a major component within Hyperledger. So yes, I agree overall the approach is a good one. The other concern I had is for incubation, do we have a well-defined incubation process in terms of the criteria that must be adhered to and satisfied within the TSE to move any project forward and to enter the approval stage and part of that should be robustness in terms of the standards, the best practices being employed and whether we can recommend that as a solution or as a component to our peers and to our eventual clients. So these are just the concerns that are raised and I'm sure we've addressed them before, but given our level of matured today and the interest that we have from a much wider field, we need to provide our due diligence. So that's all I want to say. So there is great graduation criteria from incubation to full project status that we put into place, things like having your CII badge, right? But that's more about the project itself, that's a meta kind of thing. Like does the project itself have all the right things in place like web page and a mailing list and a bug tracker and all that kind of stuff. But we could certainly look at doing other things like security audits and things like that. I don't know. I think that's more inhibition to active, right? And I think what Leonard is suggesting we need criteria to become incubated? Well, you know, I think it's kind of like the definition of obscenity. We'll know when we see it, right? I don't know that you can write down a explicit set of criteria for incubating a project at Hyperledger. There are going to be different kinds of things. You can't say that a requirement is that it be peer reviewed for something like cello because cello isn't something that you would peer review, right? It's just a deployment framework. So, you know, I think the intention here is that we sort of know what we want and that we're going to be looking at the proposal as a whole for all the things that we're asking for in the proposal template. And then we make a decision collectively, independently and collectively, about whether or not we think it's a fit for the Hyperledger organization. And, you know, whether the project, you know, the TSC members that are in many cases, maintainers or, you know, participants in some of the other projects want to have a sister project join. And obviously, there's politics involved. Obviously, there's, you know, sort of, there's all kinds of things involved. So, you can't really write that down. And in fact, I think it would be incorrect to try and write it down because you get it wrong and then we'll be arguing about it incessantly. So, I suggest that, you know, we have a pretty good template, you know, that, you know, we collectively created. And the things that are in there are the things that we're all looking for, right? And that's why I was emphasizing, I think that, you know, to make a strong proposal, you want to be able to say, we're going to build something, we're very excited and passionate about it. We have other people that are excited and passionate about it. And that's going to be part of the important aspect of things. And then, you know, socializing the nature of the project and getting others to, you know, and again, I think you're, you know, Martin and Company, you're doing the right things, you're saying, hey, we think that it can integrate with this X, Y, and Z. So, now the next step is to say, you know, is to get that buy-in from those other projects, that that's something that would be interesting. Yeah, well, we've talked to the teams Burrow and Fabric and they suggested we do a pull request with, so with plugins, basically wrappers around, around a Bible proctor. Well, there is interest from, I think. Yeah, absolutely. So, you know, we're out of time for today, but like I said, this is, it's certainly, you know, today's been a very interesting discussion. There'd be much more thought-provoking than the others we have. And there are going to be differences of opinion. That's okay, right? You know, one last thing. There was the comment from Dan, would it be possible to prepare a demo for maybe next time that goes step by step through, through basically one or two rounds of consensus achievement on Hashgraph? Yeah.