 All right, let's get started. Thank you for joining. This is the weekly TSC call. It's a public call. Everybody is welcome to join and contribute positively. There are two requirements to doing so. The first one is to be aware and lead by the antitrust policy. The notice of which is being displayed currently on the Zoom client if you're online, which I think it really is. The other piece is the code of conduct, which physically requires that everybody behaves decently. With that being covered, we can get going with the agenda. Before I get further, I wanted to ask, I don't have any announcement. Always take this moment to give a chance. If anybody else has any announcements to make, please speak up now. All right, doesn't sound like there is any. That's fine. Let's keep on moving then. We had one quarterly report submitted, and we are on time actually. There's no delinquent report. We had a report from the Iroha project. From what I've seen, most people, most of the TSC members have actually checked the box, meaning they have reviewed the project's report and didn't raise any questions. There were a few questions that were raised by Sarah, I guess, who filled out the form. Thank you for doing that, Sarah. I think we can discuss briefly here. The first one, I think it's for the staff. It starts to do with the notification, I guess, for the report. Is that right, Sarah? Yeah, hi. The thing is that we again received the report only week before we need to present it. The TSC needs some time to review this as well. I basically had to write this report during my weekend. I mean, I'm fine with that, but it would be nice if we could be notified at least 10 days in advance. I would have time to do that, to plan my time for these things. TSC would have more time to read it through, so it wouldn't be like the last time, the previous quarter, when we basically posted it like three hours before the call or something, because we didn't have enough time. It would be really nice if it's not too difficult. It's just a tiny note. Maybe it will be also easier for other projects as well to receive the notification a little bit in advance. All right. Rai, is that something you control? Who do we send or to? You let me know, and then I tell me to go and make those edits, and I'll do that. All right. Can you do that, at least for Roja, since they asked? Yeah, it's pretty easy. I just have to do it. All right. Thank you. So that will be taken care of. The second question has to do with maintainers policy. This is a pending item, as you point out. I have the intention to bring it up to the TSC for blown. For now, I sent a request of basically, I mean, the gathering phase where I'm trying to figure out what the different projects have been doing. There isn't much, but there are some projects that have some kind of policy, and so I will bring it up. I can't tell you yet whether the TSC will decide that this is, you know, we have a mandatory policy that everybody has to adopt, or if we'll be just recommended policy and we'll give some other projects of leeway as to how far they go into implementing it. We'll have to see, but you're welcome to participate in the discussion. Oh, okay. Because we have a few ideas, and I don't know, should we write this down, or should we wait for a general policy so our work wouldn't be like in vain if you decide to honor general policy for all the projects? So, you know, just to know. Okay, so I'm glad that you're eager to contribute. And my, I mean, the ball is on my side there, because I took the action. I tend to put it together in the first place. And so, you know, I didn't want to start from scratch. I know they are projects that have one. My plan was, okay, I'm going to try and find out what's out there, and I'm going to create an issue for the TSE to discuss that links to all the different policies that are in, you know, that are being in use today. And then we, once the page is set up, I'll, I'll let everybody know, and you can comment on it. And if you have ideas, you want to, you know, the TSE to take into account, that will be the time to chime in. Okay. Okay, great. Thanks. And then the last point as to do with the code of conduct, and, and, you know, practically, I mean, how is it being displayed or in the repositories, right? I believe that's one of the questions from our developers, one of the developers, because that wasn't my question. Maybe Mikael here could tell me what that was about. Sounds like this is what it's about, because it talks about separate file or link or what. And so I mean, just to cut it short, we actually have on the agenda, the first item after this is the, the, the common repository structure. And so that's something we can discuss that. Oh, okay, great. I'll wait for that then. Okay. Sure. So we have no other questions I think for now. It's like, okay, let me turn to the TSE. Is there any questions otherwise for Sarah? Okay, if not, then we can move on. Yeah, thanks. Thank you. All right. So let's move to the discussion items. So as I was just saying, the first item is the common repository structure. And then we'll talk about the discussion will continue discussion on the BIF proposal. But so the common repository structure, we had this issue a while ago, whether we should have one, there was a proposal to use the to do groups repo linter. We agreed on that. There is a, there's actually a little, there is a configuration five that was set up in the GitHub repository that, you know, make some changes to the default one to adapt to Hyperledger. And we left it at that saying, if you go to the, so if you click to the link of common repository structure, it points to the issue in the decision log with the, you know, marked resolved. And if you look at the formal proposal, basically it says, well, we're into use this. And where we kind of fell short is that, you know, there was the six, there's, it's unclear. I mean, we haven't gone any further into ensuring compliance with this. Or, you know, and so, yeah, so I actually took a survey last week, I started there at the end of last week, I was kind of looking at the different repo. And I have to say a level of compliance right now is pretty abysmal. It's like, it's an exception when a repository is compliant, rather than the opposite. And so I think we need to try and improve that. There are some valid questions, though, when I actually started looking into it and look at some of the repo that I'm a maintainer of, but it would take to be compliant because I have to admit, even those were not. I realized that sometimes some of the requirements seem to be a bit bizarre, like, you know, they're not quite relevant. And so, and then there was a change. So, Daniel, you're on and you actually raised the question in the comment there, the question as to whether we should change some of the requirements, some of the tests, especially when it comes to, like, the code of conduct, which is very much in line with the question that was asked by the hero team as to whether, you know, what is the actual content of the code of conduct? At the beginning, the first, the repo linter configuration file we had, it just tested, there's a file called code of conduct in the, you know, in the repository. And if you add one, that's all you pass. Daniel actually submitted the pull request against the configuration file that changes that to a test on the, which is based on the hash. And it means that you have to have the exact same copy as what's in that repository, what's considered to be the reference. And I mean, it sounded like, Daniel, you raised the question as to, you know, whether that was the thing to do or not. And then, I think, Rai went ahead and merged. As a result, I can tell you, I ran it again today, and against like Fabric, which passed before, and now it fails. And when you look at the details, because, oh, well, the code of conduct actually in Fabric is just a pointer to the code of conduct to the, basically it says, hey, we have an, this is important. Please make sure you read this stuff kind of stuff, right. And it has a link to the code of conduct. And of course, the hash is therefore different than the actual, you know, code of contact with as the full text. And so I think it's a valid, so this is something we really should discuss. I don't think we should necessarily do that, honestly, because they are pros and cons to this kind of stuff, especially, you know, if the code of conduct was ever to change, I think it's better to have a link than, and you change it in the one reference place, and it really is up to date. If we have copies all over the place, it means anytime we change it, although admittedly, you know, we've never changed it so far. So maybe that's not really happening often, even if it doesn't open often. If it were to happen, we would have to make sure that all the repos have changed. And it's kind of a pain. So there are two sets of questions for us to discuss or consider today. There is, you know, how do we move forward on, you know, the compliance, increasing compliance with the repository structure that we have all agreed we should adopt. And then the next question is, you know, how much do we want to go into, you know, defining the common repository structure reference, you know, especially with regard to files, like the code of conduct there, I think the license, and oh yeah, the license with fabric fails. And when I looked at the difference, I was like, those files seem to be the same. I did a diff and it's like, yeah, one has one more empty line at the end. And of course, the hash is different than therefore you fail. And I find a bit like, okay, that's a bit silly. But, you know, admittedly, you do a copy once, you commit the change and you're done. But this is the kind of stuff I think we should discuss. So, Daniel, can you tell me maybe what you thought? I mean, you made that change. I figured you had some opinion that this was the right thing to do. Although the way you asked the question, I wasn't completely sure you were convinced either. So, I mean, I was expecting when I put the discussion that I'd be the one to open the discussion with to set the stage for it. But the questions are, you know, so we have a common structure. We specify there should be three files of content, the code of conduct is the license and security. Now, security is an interesting case, because you advocated for the link method. There was actually a dead link in the security that we're being told to go out and share. So, putting a link in there isn't a panacea because links go dead. In this case, the security page we were pointing to changed. So, if we would need to update that, we need to go to everybody's repository and also change it. And it's interesting that when we first went to the repo structure, that there wasn't a facility to check file content. You could only check for the presence of files or rep for strings in it, like the code of conduct. The check that's the default in repo lenders to check, do you have it? And does it have the phrase email in it? And that's all it's checking for. So, I was able to get a patch and accept the patch to check for hashes of files. Because according to the charter, we have the Apache license is supposed to be in all of our repos. And so, you know, it's yeah, there's a difference in the new line, but that's easy enough to fix. You just see from one repo to the other when you do it. So, I think checking for fixed file content is the thing to do. And the next question is, what is the fixed file content? If we have the code of conduct as text or code of content as pointer, it comes out as a hash. So, you just copy one or the other. You know, what the exact content of those files are is kind of parallel to do we check it with repo lenders. So, you know, I'm less ambivalent about, you know, what's in the file, but more about that we check the files. And if it has required content, we should check it strictly, in my opinion, it's the best way to do it. To make sure that it is exactly what is intended to be. So, people don't sneak in crazy things that, you know, hey, we have a code of conduct. We put in there that, you know, some crazy thing is okay. And it's on. So, yeah, no, I hear you. All right. So, let me turn to the rest of the people here. Anybody has an opinion? I think in all of this, we have like a high level intent that there is, you have coverage for important things like the code of conduct. And then once we start getting down to the nitty gritty of how do we how do we prescribe this in different repositories, I think we can quickly get into the space of micromanagement. So, I'm in favor of whatever the least touch way is to make sure that we've got the important aspects of governance in place. But in this case, I mean, for those three specific files, are you in favor of having a full copy of each file and ensure there are those and nothing else? So, yeah, so at least touch way for me would be we've got a link for the code of conduct. So, we don't have to ripple changes everywhere. And yeah, I guess that's a good point that a link can break. But these are important governments, governance documents, those links should not be going down because that's that implies some other problem too. So, I'm in favor of links wherever possible. And strict things like hash checks seem fragile. Yeah, this is Chris. Look, the point really is that we want people to be able to find things in the same place in each of the projects. Now, whether all of these things are exactly the same, you know, or whatever, I think we can, you know, we can noodle on on a case by case basis. You know, the license file itself, I think it would be a bad idea to check for a specific hash, because technically, you're supposed to put notes or notices at the bottom of the license file. And so that means that the license is never going to be the same if there are notices that you have to add. And so I would think, you know, we already, you know, yes, they all have to be Apache licensed. That part is sort of gated on the on the inbound, you know, searching around and trying to find a case where somebody modified the file, I think is maybe something we leave for the the periodic license scan and not the repeal enter. So the security, that's a that's a static file that we copy into each one. Sure. And as for the code of conduct, I thought that we had discussed, and normally, I would agree with you, Dan, but I think we had discussed that we wanted to copy it into the file and provide the link. Anyway, there you go. I mean, we could have your license. The notice is actually a parallel file called notice. No, we had the notice file. But if you read the actual process, you're supposed to put it in the license. Yeah, it's weird. Yeah, and the notice file I am from what I can tell nobody has it. Yeah, no. So this is Dave Huesby. Can I jump in here for a second? Sure. The closest thing we have to this right now is the core infrastructure initiative stuff. And that's just a questionnaire where you self attest that your project has certain things and you add links to the proof. I mean, the easiest way I think to enforce this would be to combine all these ideas, right? Potentially have just one file called, you know, the checklist or whatever. I don't know what we'll call it. But that is standard file. And that asks, you know, where's your license file? Where's your code of conduct file? And you can either put a, you know, a relative path to a file that's in the repo or a link. And that's what the tool does. It goes through and scans and gives you a report and tells you what you got in the wrong places. But yeah, okay, fine. Well, I mean, you don't understand what I'm saying, but that's okay. I think I think Dave is suggesting we have a file that points to all the different part of fires, but data driven. So then you can say like if it's left unanswered, then that is an error. If it has an answer and it's a link, but should be a local file, that's a warning. And, you know, so it's data driven. So that you don't have to go and, I mean, I guess there's a config file in every repo. Yeah, maybe that's how you would do it. It's the same way. Okay, never mind. I talk myself out of it. Okay, but so, and then there's the question again, nobody has spoken to this is the, I mean, do we, there was, I think it was in the proposal that we adopted actually that they would, we would periodically run this repo linker against all the repo to get reports done. So I mean, right now it's kind of, I mean, anybody can try it. And I have, and as I said, it's not a pretty picture. So I'm kind of inclined to, you know, tell all the maintainers, and I would, you know, I'm thinking of sending an email to the maintainers list and tell everybody, hey, we have adopted this, please do your part, make sure your repo is compliant. But before I did that, the reason I haven't done that is I wanted to say, okay, maybe, you know, we should discuss the details because if we don't agree on exactly what needs to be done, then we have an issue because I don't want to have to keep telling people you need to fix your compliance because we changed the reference. But I don't know that we need to have a routinely, and I mean, there are different options. We can just, you know, let that be, just tell people, and then occasionally we can do it, or we can ask people when they do their quarterly report and, you know, we can add to the template, are you compliant or ask them, you know, that would be a way to do a checkpoint. I don't know, do people have ideas on this? I like making it part of the quarterly report. That's a great rhythm to check out your compliance. I agree. I was about to suggest something similar. Because that would be easy indeed, and that would kind of prompt people to do it and say okay. So say that recommendation again. The recommendation is to ask people when they do their quarterly report to add, you know, whether they're compliant or not with the common repo structure, and it's kind of an incentive to, you know, prompting them to actually check and fix it if it's not. Any anybody objecting to this? Dave has his hands up. Is that still true? No, I talked myself out of it. How do I lower my hand? There it is. Lower my hand. There we go. Okay, I've heard a few people in favor. Anybody objecting to this? I don't know that we need to make it a formal decision. So let's keep it casual. All right. Hearing none, I'll do that. Just before we move on, because I want to keep enough time for the BIF proposal, I just want to finalize the discussion on the content of the files. Sounded like there was quite a bit of a position to having full copies, but so we should revert the change that was done, I guess, right? So we will not check on the content of the files, but we'll just keep it at the present existence check. So if we're not going to check the hash, one question, there's three proposed files in there with the license, the security, and the code of conduct. Are those contents fine? Do we want to keep the code of conduct as the text or do we want it to be a pointer? Because the security license, I think, or subtle issues, the code of conduct was kind of in flux, you know, whichever way is fine. I think the link would be good. And if you look, in fact, in the December repository, if you look up, there is exactly a file with the link. So we could use that and keep the hash test, but, you know, then we don't have the full text. We have a link. I guess that's one, that's what possibility. Could someone post a PR proposal then? That'll make sure everyone gets the same check. Okay, I can do that. All right, I think we are good. Let's move on then. So the beef proposal, we had a first presentation last week on the overall proposal, and there were some questions raised, and then there was a different file was submitted to the mailing list, which I linked to from the agenda. You need to go back, right? It's in the, it was the sub bullet. Yeah, there's a use case. And so we can go through this now. Who is going to present it? I think Takuba was pointing out presenting. Are you there? How much time do we want to allocate for that? Well, it's only a few slides, right? So it should be pretty short, I would hope. Hi, my name is Shingo Fujimoto. I will present this slide in short. Okay, great. Thank you. Let's do this then. If you can walk us through those slides pretty quickly, then we can have an open discussion. Yeah, thank you very much for taking the time. So this slide is showing to the some of the security models, describing to the how the beef supposed to be work. This slide is showing to the how the procedure will do, the explaining, explaining about the behavior of the beef. So the, you can see the green box in the middle of the, the slice. That was what we call the business logic programs. That is a mandatory module of the PIF, which will implement to the business logic. The, that will be developed by the users. So the, on the other hand, the two boxes on the edge of the left and left and right, that was named to the DOTs. Those are supposedly be the one, the independent blockchains, like Ethereum and Quorum in the examples. So the, the, the, the business logic, the program will be invoked to the several other transactions on the, the one of the DOTs. For example, the first transaction on your left, that will send the money from the source account to the escrow account. And the, that fact will be observed by the programs and that will be notified to the, the business logic programs. And then the business logic program will invoke to the another transaction on the right DOTs. And that will be invoked to the some, send the money from the, the, the exchanger account to the, the, the designated accounts. And finally, the, the, that fact is also observed by the business logic programs. And the, the business logic program will add the, as a response to the, that, the observations. The third transaction will be the remotely invoked. That will be the, the, send the escrow account to the, the exchanger account. So the, in the total, the, the, when the user wanted to the one money to the, to the, another result, the, the exchanger will be the intermediate, but they will not to the, involve to the actual transactions. So the VAF will in the help to the intermediates to the, those two transaction security. So they go to the next slide, please. The, this one is actually the showing to the, the, the system modules that I explained those other in sequential. So the, the, we designed to the business logic problem will be the implemented for specific use cases. And we are expecting to the VAF will be the infrastructure of the, or the fundamental rivalries to build such a solutions. And the business logic will also responsible for the handling to the error cases, like a friend, the one, radio was failed to the, to finish the transaction. And that was designed for the, to recovering to the, such a escrow, the money will be sent back to the original accounts. That was expected, the behavior of the VAF applications. I think those are short presentation for the, the question answering to the previous sessions. Thank you. All right. Thank you. Questions. All right. So I mean, I'd like to, the way I would like to put it is, you know, I want to first take a moment if anybody has more questions to help them understand what the proposal is about. And then we can discuss, you know, how people feel about the proposal, whether we should make a project or should we keep it as a lab. So I'm, again, I struggle with any kind of integration between different ledgers, but let's leave that aside for the moment. This, what you just described seems this sort of tell the same story as quilt. Am I completely missing something here? Yeah, Chris, this is quite different from quilt. Quilt is an implementation of a standard and quilt only, only works for sort of monetary transactions. The idea is that this works for sort of general sort of smart contract logic. It works for just about anything. And, and I'd also like to add to that that we had a discussion in one of our previous TSC calls. We had originally intended to contribute this to a quilt, but the TSC thought it was not appropriate to usurp a quilt for other purposes. And so that's why it's not part of quilt. Yeah, the remarkable, the difference between from the quilt project will be a quilt is based on the ILP, that is some sort of the atomic swapping for the always the two transactions will be occurred at the same time. That our approach is more like a flexibility for the sequential record and error handrails and those kind of things. So the, but the, we need to do some sort of the abstraction for the, to absorb the difference of the between the registers. So the initially that we, our project was categorized as an interoperability, but in the at the certain discussion figured out the, this is a certain mechanism for integrating to the several registers into the one single logic. So the, we named to the integrations for the other, the name of the other product. Is that answering your questions? Well, some of them. So I think, and again, my recollection of that conversation, Tracy, was more along the lines of built seems to be abandoned, hasn't been updated in forever. Can we just take it over? And I didn't, I mean, I think that, you know, you're right, we, we agreed that that wasn't appropriate, but bringing the same context, the thought process and working to evolve quilts to incorporate some of the capabilities that you're talking about here, doesn't sound like a bad idea at all. Whereas what this seems to be doing is setting up a parallel thing that's, you know, yes, maybe it's doing some more things or something slightly differently, but, you know, implementing a hash time lock algorithm in a different language doesn't seem to provide, you know, I think it just sort of continuous on this sort of so half fragmented stuff that doesn't work together. Yeah, Chris, I mean, so history for, for those of you who may be not familiar with it. Back in early 2019. So basically, right after I left the Linux Foundation, I was in conversations with Quilt to bring the Quilt maintainers to bring blockchain integration framework into Quilt. And we were having great conversations. The maintainers were really for it. They were like, this sounds like a great idea. But as you recall, appropriately, right, Quilt had not filed their quarterly report to the TSC at about the same time that we were all coming to the conclusion that, yes, it should go into Quilt. And that should happen. So the TSC did think that, you know, maybe it was abandoned and we were trying to overtake it, which we weren't because we were in conversations with the maintainers. And we wanted to kind of do a sub project. But there was obviously that concern, right? Is Quilt going to continue? Is it not going to continue? Maybe it makes more sense to have us do a full project proposal since this is a larger interoperability project than just the ILP. So, you know, all I'm saying is, like, we've been here, we were told not to do Quilt, right? And so. No, I hear what you're saying. Yeah. Again, Quilt, you know, there was a bunch of circumstances at the same time going on. I know you had been talking with them, but then all of a sudden they all left Ripple and did a startup, and then they got really busy. And so they weren't really paying attention to Ripple to Quilt. And now it's been rejuvenated, if you will. And there's somebody that's actively working and they're submitting progress reports and so forth, which is all goodness. But, you know, again, with all the other conversations that we're having, I'm just wondering if, and again, there is a JavaScript implementation of Quilt, essentially, of ILP over and I've been talking, I don't know, Brian is on today or not. But, you know, I've been saying to Brian and to Chris Borchers over in the, whether they open JS now, he should bring these things together. We shouldn't have, you know, essentially a single project that's split by virtue of which SDK you happen to like, you know, which language you like. It just seems to me like we should be trying to bring things together and make things more relevant to each other than just doing it. So I hear you just saying, Tracy, I just think in the spirit of the conversations we've been having, could we, what can we do to try and make these more smushable? Mr. May I speak a little? Because of the Quilt or the ILP is designed for the other heart already mentioned, the ILP only covers the monetary exchange or swap that is the other designed for. And in our white paper described to the possibility or applicability for the different use cases, like if we're interwork with the different type of the ratio, like for, let's say, the one ratio, the built for the data exchange, and we need to charge for such a data exchange as a trade. So the exact use cases cannot be covered by the ILP. It doesn't matter the programming languages will be used. So as an agent of the ILP is a equivalent value and has to be the swappable cryptographically. So that was a very limited applicability for the nowadays. So let's say we're having a blockchain application is more like a supply chain management, health care, whatever. Those are not covered by the ILPs. So that is the current existing issue need to be solved. Yeah, Chris, and when I talked about this, one of the first things we looked about was, you know, should we, you know, as Tracy recall, should we join Quilt? Should we merge with Quilt? And it was pointed out to us that sort of the charter of Quilt was to implement the ILP standard. And in this case, we want to do things that are sort of well beyond the ILP standard, you know, our sort of transaction mechanisms go well beyond the sort of, you know, time lock stuff that the ILP is doing. So if you dig under the hood, our techniques are sort of very, very different from what Quilt is doing. Yeah, so I think this is a very point. And it does touch on the what Tracy was saying. I mean, you know, the previous discussion was basically, hey, you cannot just start, you know, we use the envelope of the existing project and start doing something quite different. And that's my recollection. And yes, Chris, you're right that, you know, Quilt, you know, the Intelligent Protocol is kind of all over the place. I remember pointing that out way back then when they brought it up. There is a DER 3C community group that works on the spec. At the time, they were trying shopping around to try to standardize the spec through IETF. They had one implementation for JavaScript in the OpenJS and the Java one here. And it's clearly not ideal more for them than anybody else, I would say. But I agree with Chris's point that, you know, clearly, when we considered that question, Quilt seemed to be in complete disarray and he would seem wrong to just say, oh, we have this kind of body, you know, lying there. Let's just invade it and use it for a different purpose. That's kind of what I remembered of this. It's my interpretation at least. And so, you know, I think we should just put that aside. I don't know if the current maintainer of the Quilt project, which I agree with Chris, is clearly Quilt has restarted and they have somebody who is quite active. I don't know if they were part of the discussions that you refer to, Tracy, where they were excited. I'm sorry? They were part of the discussion. So, would they still be open to working together in one bigger project? I'm not sure. We didn't go to them because that's not the direction that you gave us. Yeah, actually, I had a conversation with some of the community of the ILP communities, but they're the very focused on the financial area as their applications. So, the Ripple or some other vendors are more focused on the such area. And this, the BIF is a different area, like the charging or accounting or so. So, the the technically, we may have the sudden similarity, but the approach itself is quite different. And in my understanding, the Quilt project is certainly scoped for developing to the ILP protocols that was described as a charter. So, they are saying that unless the charter should be covered like a non-financial area, we cannot merge the two projects. Those are different purposes. That is my understanding. Is that something different view from yours? I'd like to maybe take a step back. I mean, we're discussing from the project view what's it going to be like to people that are consumers of both of these projects, right? I'm assuming BIF is going to stay out of the financial area and leave that to Quilt. But, you know, if you're coming in to Hyperledger looking for something you can use for cross-ledger work, you know, how are we going to distinguish the two? Well, I think that's pretty simple, right? If you want to run, if you want an ILP implementation, right, you would run Quilt. If you don't, if you want a general blockchain integration framework, you would use the BIF. Right. But in a year, are people going to say we should combine these two and have one solution that works? Or are they so much different, not an implementation, but in theory of what they do? So, in my understanding, Ethereum cannot apply for the ILPs because of the time rock is not implemented for the other standards. So, the certain limitation is always exist. If we choose to do the different protocol or the platforms nowadays, we have many choices. So, that is an existing problem on the market. The time rock is very limited applicability for the technical. Can I say something? No, this is Angela. Yeah, so, I must admit, I personally struggle to understand why this solution should be used by any blockchain system that is distributed and private. So, you are describing a solution where there is a centralized party. So, a single point of failure. We are back to a system where a single point of failure, which blockchain wants to avoid in the first place. And then, this solution of this guy is as access also to both ledgers, this routing piece has access to both ledger. This ledger might have different security privacy requirements. So, I would be more interested to see what's because hyper ledger is for the advancement of blockchain in the enterprise applications. I really would like to see a use case, an enterprise grade use case, where you see, A, these are the requirements, the privacy requirements. This is where it's acceptable to have a trusted third party that's a single point of failure in a distributed system. I struggle to see this, but I might be wrong. But to me, if you are presenting just another trusted party in a blockchain system, I mean, what's the point of having a blockchain in the first place? So, Angela, so I know it's not split up in this diagram, but you can distribute all of this stuff. And in practice, that's what we're doing. The BIF is not like a single entity, like the business logic plug-in is going to be a decentralized system. So, I know it's not drawn like that in the system, but that's how it works practically. All right, sorry. I know it's not like that in this diagram, but... Yeah, fair enough. Fair enough. But this guy still have access to both ledgers. I mean, and these ledgers might have very different... I mean, one can be a supply chain and the other one can be a payment system. I mean, why this guy should have access to the secrets of the supply chain just to be able to connect with the payment system? I mean, maybe the guy who are inside the supply chain might want to have some... I mean, might want not to rely on this third party that has access, full access to both ledgers. Sorry to interrupt you. Can you show up to bring the previous page that I explained about your questions? Yes. Your question is, this business logic can be supervising to all the governance of the region. That is not true. In this slide showing, this business logic will be limited the privilege or accessibility for the escrow account on your left. So the first, the money will be escrowed on the intermediate place and this business logic can handle or control this account as end users' perspectives. So the business logic problem only observed the distributed ledger that is involving to the both side and the expected event was occurred on the other ledgers. This business logic problem will operate their own account, not using to the super power. So for this example, I said to the isorium. Isorium does not have... allowing to the any users to have the special power. So this is the fact. Our solution is workable without having a risk of the single point of failure. You still have this guy, this escrow account. But anyway, now you are describing us, so that's also... when I saw this, I thought, but they are describing something that can be done with the inter ledger. So I mean, I would have expected now, because I'm talking about payments here, but then you said that you want to be more general than this. So maybe you should present an example that is more complex than payment where you... we can better see the limits. Actually, I'm just saying, I'm not... I have nothing against this proposal. I must admit, I only think that you want to address something that is very, very complex. And I mean, even the literature is still not well set on how to solve this kind of problem. So I was wondering who will use this in an enterprise setting where the privacy... the security and the privacy requirements are so strict. And you really want... I mean, it might be very tough. And the business logic, if you say that you want to be more general than asset transfer, then you are kind of saying, yeah, we are really have to... what does it mean exactly an escrow account for a business logic that is not ready to transfer asset? You see? I'm sorry, but we had a certain description about... and such a wrong... more than the 20 or 50 pages, the white paper describing to the such a... the various white... the use cases, the one for... from the beginning of the very simple one to the... the complicated one, the... describing to the whole sequences as a sequence of diagrams. One of the diagrams was attached in this... my presentation, the showing to the how it works, but that is not appropriate for the TSC discussion for the such a details. So the... I'd like to ask you to read out to the some of them to understand the... my explanations. But my point is that our solution will not provide to the any single point of failure. This is a kind of the support of the two peer-to-peer trading with health as a service. So the... because of the... our organization hyper-region providing to the enterprise service, but we also need to the interoperability with the public service, like Ethereum or the... let's say the Coder or something, those are public chains, but public chain cannot be the... using to the... the single point of failure. That is a fact. All right. Let me interrupt you here. I'm sorry, because we're running out of time and I want to make sure we are ending somewhere here. So I agree with the point you just made for them that matter that, you know, there's only so far we can go in this discussion at the TSC call, and we are not here to actually solve the problem. The point is to understand the problem area enough so that people can form an opinion as to whether this should be made a project at this point or not. And this is what I would like to ask people now. We only have three minutes left. I don't know if we have time to... if we want to have a formal vote right now, but who is in support of this? There are quite a few people who've stayed quiet. I'm generally in support of this type of project. I'm interested to hear more about Angelo's concerns on the architecture and response from the proposers. And I don't... on the other subject matter of the quilt integration, I don't see that as a requirement, but if there's any additional specifics that come from the quilt quarter to provide feedback to this proposal, I'd be interested to hear what they said. I would say that I share Angelo's concerns. I tend to prefer an architectural approach that does foreign signature transaction to try to eliminate the need for the routing entity, but I understand the architecture need for this. And it's obvious that people have real uses for it. So I don't think that's grounds for opposing its creation or moving forward in one way or another. So just a comment. We have this... we have 40 pages of white paper if you want to look at sort of the details and understand what we're saying here. And if you have concerns, we'd encourage you to look at it. The link is in the proposal document. I think it is unfortunate you guys use the financial use case because that falls directly into the IELP stuff. And that's probably not the best way to sell your idea. We thought it would be the simplest and easiest to understand, but in hindsight, that was not the correct decision. I understand. Anybody else wants to speak up? Just as a final word, we had some of the QA section in the proposal document. So please look at those questions pop up during this session. We'll be partially answered. So we are extending to our proposal to solve the existing issues. Thank you very much. All right. Thank you very much for all your input and answering the questions. I think we're going to close the call on this and that means we'll report to next week on making a decision one way or another. I am in part of it. I heard Hart say pretty clearly before that one of the motivations to turn this lab into a project is to attract more people and make sure that the API they ship up address everybody's needs so they don't have to revise it later when finally people pay attention. I do encourage people to join the lab for that matter. There is no need for the project per se. But so on this I'm going to close the call. Thank you very much all for joining and we'll talk again next week. Goodbye. Thank you very much for your time. Bye bye. Thank you.