 Obviously, the next regularly scheduled conversation would be – well, in two weeks would cross over with the U.S. Thanksgiving holiday, so I presume it would be relatively uncontroversial to cancel that meeting, if anyone objects. I'll make sure it's a conversation, but – I'm fine with canceling that. Okay, good. And now, next week – next week on the 17th, I believe Chris is still out. I will be traveling in Asia and can't commit that my travels won't conflict with this time frame. So if another TSC board member would volunteer to run the meeting, that probably would be a good thing. Would anyone who's on the TSC on this call be willing to do that? You know, one second. Sorry, I'll be out next week as well. This is Mick. Mick, would that be your call in spirit or saying you can't make it? I cannot do it. I was going to volunteer, but I will actually be on an airplane at the time. Sorry. Okay. We can defer this to an email conversation then to make sure we have coverage. This is – I know I was also going to volunteer, but I'm not sure. I cannot guarantee I'll be on time. I expect to be on the call, but it makes it difficult for me to volunteer. Okay. Well, then let's take it to email and do it to the list to talk about that. And it may be that we end up canceling next week as well, although there's certainly some balls in the air, so it'd be very nice to get started. It'd be a little bit of a progress in some things. So why don't we move on to the next item? So we've been searching for a space for the HackFest in December to correspond with the members on it in New York. So the system takes three days, so we had relatively locked in, and sadly haven't been able to confirm the locations yet. We have one more opportunity that we're chasing – I'm sorry, two more opportunities that we're chasing down that we will get clarity on probably by early next week. But our sense is that we can't confirm the location by basically Tuesday. I mean, I was hoping this week, but this was one of the two options we'll only know early next. I'd say if we get to Tuesday and we can't lock it in, then we probably should defer or essentially cancel the HackFest for December in New York City. Unless anyone here has any other options they can provide or believe that a shorter time note is acceptable – I kind of think since we want people to travel to make this, it's pretty essential to give sufficient notice. But it's not feeling super positive at this point. So I just wanted to get a pulse of the room and say, you know, A, does anyone have any other ideas? But B, does anyone basically agree? Everyone basically agrees? I think that's a cutoff. Yeah. I think that's a fine cutoff. I think a lot of the benefit of the HackFests is just seeing people face-to-face and having face-to-face discussions. And we're going to get that opportunity anyway with the members' meetings. Well, not everybody will be able to make it to the member meetings. And I want to be respectful of that. And we could even coordinate some sort of social gathering. I'll be there Monday, Tuesday, anyway. So perhaps for those who will be in New York anyway, some sort of social gathering open to anyone at a restaurant somewhere, I hate to say at a bar because I don't want to promote alcoholism. But you know what I'm talking about, it's some sort of a more public-facing kind of thing. Perhaps there'll even be a meet-up we could coordinate at. So there may be something less formal, less full-time that it could still be open to the public. I'd still like to do that, and we'll certainly research that possibility if we don't end up being able to find a location for HackFests. So if it comes down to the point where we cannot have somebody host in New York, before we cancel entirely, I would suggest we ask if there is any other option somewhere else, maybe on this coast still, but it could be Boston or somewhere else where maybe somebody can then host. And that would be a good alternative to rather than just cancel the whole event. True. And we have included researching commercial spaces. So to answer Jeremy's question in chat, one of the options we are pursuing is that of WeWork. And I do want to thank Renat and Altora for helping us track that opportunity down. So we have been researching commercial locations where we haven't spent money. And coming up somewhat short on that, I mean our event team is pretty good at finding spaces. But both the timing is short, and the need is kind of unique, you know, for at least 60 up to 100 people with power and Wi-Fi, with seats that can be reconfigured, it's not your typical auditorium space or a meetup kind of space. And for the daytime as well, which is also good. But we can put a little bit more time this week into locating it. And again, for people who have made travel plans, will be in town, let's try to find a way to gather informally to get the benefits of face-to-face interaction even for a few hours. But we're not giving up hope yet, there's still a few hours. And Jeremy, if you have connections to galvanize, that would be interesting. You know, we've pursued them through, you know, I know IBM has a relationship with them. I know PricewaterhouseCoopers has a relationship with them. They're in New York City. So we've tried kind of both those angles in, we've suggested to our friends, those companies, they've, you know, looked into that and haven't heard back yet. If you've got a direct line into them, that would be, that would be interesting. Hi, I'm Sussi Lajnick, good morning everyone. Mr. Dave, flexing with John, must it be in the December 5th or 6th, can we deliver a few more holidays, possibly when we can celebrate our achievements and possibly give us more time to find a better venue. Just a follow-up. If that was, actually, I'm not sure I could make out what was being said if there's any way that you could improve, you know, take the phone off of a headset or something like that just so we could hear, it was a challenge to hear. Oh, sorry about that. Yeah, I said something about today again. This isn't an instant update, it's back to the 16th, December 3rd, or 6th. How could you delay or do you want to speed up holidays and celebrate your achievements today to come to a level as far as 15? Yeah, I'm sorry, it's still not possible, still wasn't possible to hear in the background. It's, it's, sorry, I'm sorry about that. I think it's being asked as if the 5th and 6th are in stone or if it's possible to delay the hackfest to a later date. Well, these are, these are things that we're hoping to have every two months. You know, we could start the process, we should start the process now of trying to determine the next location. And, you know, it was, it was fortuitous to be able to coincide it with this. We could look possibly for options on the 7th and 8th. I didn't get the sense that, you know, it was terribly sensitive to a few days on the other side. But it's, it's, I'm sorry, 9th and 10th. You know, but that's a Friday, Saturday, which is also tough to ask for from people, especially in the run-ups of the holidays. So, my sense would be if we can't make it work this time, we put it on hold and try to, you know, put effort into determining a location and time, you know, for the one that we would have two months out and look at other cities, other options and put a broader call out for that, unless people potentially feel differently. Brian, this is Sharon from IBM. I'll see if there's, I'm going to all go ahead and put out some feelers to see if there's anything that we could do up in the New York area. I don't know that we have a space like that, but I will, I will go make an attempt and send some feelers out today. That would be terrific, Sharon, thank you. Okay. So, any last comments on this before we move on to the next item? The next two items may be hard to come to consensus on given we don't have quorum, but just a, I guess we could open some space for some conversation on both of them if people are interested. The first one being on the project incubation exit criteria, we have left open one more week for kind of comments or review on the document with the idea that we would approve it. We could certainly continue that online and aim to have an approval at next week's meeting if we can get quorum there, or we could even try to meet quorum through email conversation as a follow-up, but it does feel pretty useful to get this past the finish line. Any comments people wanted to make here on the call and conversation they wanted to have about any of the points in that document? Yeah, sure. I wanted to make a, just a brief point that I brought up before, but I don't think it's actually made it into the document that code review is probably not the best way to assess security and that we should probably have some other way of stating the requirement that we want some sort of minimal security or crypto-analysis. Hard to know. I mean, I do value the purpose of that. If you place some value on proper reviews by just trying to look for those kinds of vulnerabilities, that is actually a fairly high bar to exiting a graduation, though, or something that should be focused, in my opinion, primarily on, is this a community that is able to ship code that we believe will thrive in this point forward? I think it's appropriate to have a question about security practices, you know, can a bug be reported, a security hole be reported with the knowledge that that'll be treated with the appropriate process and respect. But yeah, it's a pretty high bar to say that that's a huge security problem. Yeah, so I'm not, sorry, Brian. I'm not, I don't mean that, you know, we need a system that, you know, we've poured hundreds and hundreds and hundreds of hours into, you know, sort of securing the thing. I just think that sort of as you mentioned, we need to make sure that there is a framework in place to make sure we can analyze security. And like right now, this is listed under the additional requirements in terms of test code coverage. And that's really not a way to assess that. So just hard, I think one of the, I tend to be in agreement with you, but I'm curious as to how we view, I mean, the idea behind the exit criteria is to move from incubation to active state. And then looking at the lifecycle document that goes along with that, it really tries to capture the sense that of completeness, both in code base, the test coverage in the community and its establishment. I don't hear in the description, I don't see in the description that it's perfect that way. Now, given the context in which all of us are operating for most of these projects, security and some attestation that it will do what it says it does seems rather important. Is there a middle ground? I mean, I thought that some form of security review was a good part of the exit criteria. But to expect too much at the graduation point seems like a lot of extra work. So by placing under additional requirements, we've actually, it's something that is going to be defined at the onset of the program and considered as goals to meet that expectation. So these are things that I would see the TSC saying to a project, look, you know, like if you're in particular is a cryptography library, right, something very, very low level, we believe that in order to make the claim that this code is in this community is ready for prime time, you know, in particular you need to have your security claim, you know, have test weeks around all of the claims that you're making. And that wouldn't necessarily be required of other projects because they're maybe not as defined that way, right? I mean, the additional requirements is basically a door through which the TSC could add additional requirements that they're choosing. Maybe that's too much of a door, maybe that's too much. Putting too much on the TSC to add that, you know, and perhaps it opens a door for unfair treatment of one project over another. I don't know. But do we want the idea of these additional requirements that the TSC can place and if so, what are the constraints on those doors, on those requirements? Well, this is Jeremy. I was going to just suggest if all we do somewhere, whether it's requirements or incubation or somewhere else, just make sure that somewhere somebody's addressing what it means to be enterprise ready and whether or not this thing, how this thing is approaching that. That might be a way to attack it. Yeah, so a couple of points here. So first of all, I don't think I was clear enough. I don't want to place, you know, excessive requirements before sort of something exits incubation. My complaint here was mostly that the document sort of implies that code coverage is how you test for security and crypto readiness, which I don't think is correct at all. So I just think the document should be, you know, corrected in this sense. You know, I would like to see, you know, sort of some plan of security, but I mean, that's not set in stone and, you know, we can talk about that. And as Jeremy points out, you know, we probably need at some point some sort of definition of enterprise readiness as well. So I agree with him on that. Brian, just a question. Given that this move from incubation to active sort of represents some form of rubber stamping by the working group, what are our legal liabilities in this case, in particular with regards to security and what we actually attest to about the particular security properties of a project? Do we have any? Yeah, if Mike Dolan is on the line and I can put him on the spot to answer that, I'd probably be happier. Okay. So Mike, we largely disclaim all suitability for purpose in the license. So there's no legal liability here. I think we'd always want to be careful about public statements we make that sound like warranties or promises. And there's some, you know, a gray area where, you know, some folks are agitating for legislation that would not allow creators of software to disclaim liability, but they can set it aside, I think. Because great expectations of open sources use at your own risk. I do think the question, the real question is, what's the reputation we want to develop as a project for the trustworthiness by default of the code that people use from Hyperledger? And I would pitch for that to be pretty high. In fact, I've got a job post close to being posted for somebody, specifically to work for us at Hyperledger, at the Linux Foundation, whose job would be to raise the profile, the security profile of the project by implementing everything from a security reporting process and bug bounty system in the long-term future to, you know, repeatable testing frameworks or relationships with academics who can help come in and get the code, you know, these sorts of things. Or themselves, we'd be technical enough to perform parts of that review. So I'm very desirous of that public reputation being as high as we can make it. The formal liability we carry, I'm obviously interested in not being as low as possible. And I think the expectation is that it's probably our entour. But we can do better than that. Hi, this is Ben Zephyr. Yeah, I told you this is that statement. Although we are incubation, we should really be able to understand the repeatable possibilities to understand where and how to engage in incubation of the community. So, yeah, and even if we started, you know, the federal environment, we could start to look at that thing with you in the test papers, and therefore, test plan to identify any gaps for input. There may be certain categories that we're missing already in the overall test plan, if there is one. So we can say we do have a current product that can now move forward, migrate from the incubation phase. And I think that's important part of the question about to show that we have good standards in place. So in a test plan, to see that, do we have a test plan that can be used to ensure that even if we don't have a positive one, that there aren't any sort of, you know, really clear gaps or areas of concern that there can be a doctorate approach, or are we following this approach? Is this Leonard speaking? Yes, it is Leonard. It's been really hard, at least for me, to get more than one word out of four from the audio. I apologize. I hope it's not a problem on our side. Yeah, I do apologize. I'm just very far away. Is that any better? Much better. Much better. Okay, wonderful. I do apologize. No, I was just saying we always have to proceed on a standard thought about the best way, but we have to give the impression and the understanding that this is really a foundational effort that might benefit all communities. And therefore, we've dogged the ISCOSPY that it's much robustness, testing, as we can, before it moves some innovation out into the community space. So we need to have, and I'm speaking as an architect, we need to have a standardized way of doing that for four-hour releases, testing for our releases. And it could start now because we may not have a full set of requirements by having a test plan that the membership, all of us, can review to identify any sort of glare in omissions or areas of concern that we should address now before the product moves on from the incubation. So I'm just putting this out there. I don't know if we are following that approach already or that's something that we should look at and give us that comfort feel that we do have a standardized process which would normally help us to identify any issues that are concerned right now before it moves on because all of that, our credibility reputation rests really on being able to provide that robustness for our releases. That was all. Sorry, go ahead. No, go ahead. I mean, but this is all I'm speaking. I just wanted to try and reframe a little bit the discussion on one point which I think is critical is that we went through this before when we discussed the project lifecycle and the executory as a matter of fact and there is a, you know, we seem to struggle again with this notion that what we're talking about is the project maturity level as opposed to the product maturity. And I think that's very important to keep in mind what we're talking about here. I mean, my expectation here is that the executory really are a way to figure out whether the community in a way, you know, is really, you know, as proven that it's a functioning community. It doesn't mean that their code is bulletproof and then, you know, it's highly secure and all that stuff. I think, you know, we went down that path before and we eventually agreed that, okay, you know, getting into the product maturity, you know, criteria business is a different dimension that is worth looking at but that is not what this is about. Let me propose then as, you know, just so that we can move on to some of the other agenda items but not to leave this hanging too much. I would actually suggest we drop the additional requirements portion of this document. All of the three of these additional potential requirements are things that speak not to the maturity of the product community. And to Arno's point, there may be good reasons to define objectives, you know, cross-project criteria for these kinds of things, especially for security but we perhaps should track them separately and the incubation phase, this is me editorializing, shouldn't be something that projects, you know, linger in for too long. It's something that really is about aligning them with the project from a community perspective and the infrastructural pieces in place and that things like scalability really isn't tied there. That might be a criteria for calling something 1.0 but let's talk about that elsewhere. Any disagreement with that idea or agreement? So Brian, this is Ram Jagadishan here. So I just want to kind of, you know, agree with some of the earlier points that we don't want to set the bar anywhere close to the requirements that the product would have at this stage but given the area that we are in, it seems, you know, security is a paramount requirement in terms of, you know, having a really enterprise-grade solution. So even if it is some checkpoint which says do you have a security review plan or, you know, code security audit plan might be better than having nothing at all, that's my opinion. And the second thing I wanted to check was it seems like the Linux Foundation has a critical infrastructure effort that's going on and I was wondering whether they have a best practices recommendation opposed to this. And the real question is we don't want security to be an afterthought in this phase. We want it to be an essential component and so I don't think having some kind of at least checkpoint which encourages very early thinking about security requirements I think that would be a very desirable feature to have. Yeah, the CII does actually have a checklist like that. Some of that open-source communities go through and they are about the community and process and they are about the codes themselves and so I'll dig that up and send that around and that may be appropriate but specifically the points earlier in that requirements document not the additional requirements section at the bottom. So the additional requirements section is kind of... the lead into it is set to that as something that is nice to have rather than a requirement. Is there a way that we can... Okay, I'm supportive of projects thinking through the set of things that are in that section and some form of documenting some thinking behind it seems appropriate as opposed to creating them as barriers to graduation from incubation to active. Is there a way that we can preserve those as things that projects should be thinking about and may hold themselves accountable for as opposed to requirements? Like maybe change the section to additional considerations instead of additional requirements? I think there's another document. Yeah, I think that's a very good approach not to lose the content and the brain, you might say, the scenarios that have already been set but include them as some form of consideration or further consideration. I do agree that section would be very important to have. Okay, in the interest of time I'm going to suggest even though Ben has joined and we could in theory declare a quorum now. I still feel like there's some open conversation. Let's carry this conversation on on the TSC. I think one proposal is drop additional requirements and find a way to reflect those somewhere else in the constitution of the project, somewhere codified and formal, perhaps simply not as a requirement from incubation. If I may add Brian, just before you move on quickly I just wanted to add a little bit of background so that everybody knows. I was the editor of this document and so this section was put in the way it is as kind of a trade-off, as a mitigation between the people who wanted more and those who wanted less. Even though personally I think we could drop the section I would not feel comfortable doing this by fairness to those who accepted the document on the basis that we had that section the way it is. At the very least we have to answer the question of where does it go if it's removed from there before we remove it. Okay, let's do that on the TFC call then. Moving on to the next section item, the China Technical Working Group. I have no update to give on this. I needed to put it together into something formal and work with the China community here to define co-leaders for that. Ball is in my court, I apologize for that. I'll get this prepared and then ready to discuss that next week's meeting. I'll actually be in Shenzhen for a day on Friday, once again. Yeah, this is on me. As you're getting that together, I guess one thing that will be important to me on that is having mechanisms that prevent there from being any sort of fracturing of the hyperledger community. There's discussions that don't go across both sides of that communication flow that would probably start to create problems. Anything we can do to keep that from happening, I'll be interested to hear about that. Right, and largely it will hinge on the chairs, the co-chairs that we name, making sure that they monitor for that. We also do have Chinese speaking members of our staff who'll be on the discussion and monitoring for that. And I think in the framing of the charter, I think it'll be, we'll put language in that helps describe how this should really be a bridge while still needing the needs of the China community. So I think it's a very good point for us to both code into the description but also monitor for that. Okay, and really quickly, we're putting together some thoughts around an internship program this summer where we will sponsor and pay for some number that we haven't decided yet. Hopefully up to six, we've thought to work that into the budget, but interns over the summer who will work from home so they can actually be from anywhere. We'll look a little bit like Google Summer of Code and what we need for a process like this are volunteer mentors who are willing to bring developers into their, you know, under their wing. They'll be college students. They'll be people who we can expect some fair degree of self-sufficiency from when it comes to learning how to code, but we'll probably need plenty of guidance on getting into our different projects. We'll send out a more formal call later, but this is a seed planting to say if anyone wants to be a mentor for that or wants to participate in defining the program. That would be, if the door is open, we'd really look for involvement. It's great. I look forward to hearing about that. And myself, Leonard, more certainly, I'd like to talk to you about that. Okay, so we've got Leonard. Who was it just before Leonard said that's great? Dan? I'm sure we can find a mentor in the sawtooth team to work with an intern or two or three. Excellent. This is Mark Wagner. Mark Wagner at Red Hat, we'd love to have an intern at Duke to help. Okay, we've got three of you recorded. And we'll be in touch and, again, we'll send out a broader note, but thank you very much. So why don't we move on to Dan? Did you want to give a quick discussion or a presentation on the marketplace navigator? Yes, I don't really have a presentation set up. I just wanted to make an announcement or just update on the progress that we had said earlier in the fall. We had some code within Intel that could be contributed up for the Block Explorer project. And so it took a little while to get that unentangled from some other work, but that has just been released into... We put it into the Sawtooth repository for starters, but then that can... Now that it's got all the proper licensing on it, it can be copied over entirely or in whatever parts are beneficial to the Explorer project. It's probably best not to think of it exclusively like a Block Explorer, because that's maybe a subset of what it does. You could maybe more properly think of it as a client side. Sorry for the background noise there. It's a full client-user interface, one that's designed to work with our example marketplace transaction family. And so again, with Sawtooth, we have a concept of transaction families that encapsulate business logic for a given domain or set of use cases. And so this client UI is set to play a role in that marketplace transaction family. So that would be inclusive of the things that you would think of a Block Explorer. Can I find a specific block idea and kind of dig into that, but then it's got the logic that would be specific to what is the guts of that block, and you need necessarily interface by trying to find block numbers or something. So terse is that, but you've got a regular interface to conduct transactions as well. And while that's set up for the marketplace, it would be a pattern that we've used also in some other work that's independent of marketplace so that you can use that same style of design for bringing up other sorts of business logic and being able to transact and inspect the ledger for those kinds of transactions. So I think that's probably enough for as much as I intended to say about it, but there's a post out to technical discuss from the engineer that worked on putting most of it together that's also participating in the Explorer project. So the links to the code, I think, are also in that along with pretty good documentation about what it is. It seems like it's very tightly associated with the Hyperledger Explorer, or is it the kind of thing that could be its own independent project. That's what I wasn't clear on when I was reading the description. Well, so it is bound to the marketplace transaction family that would be part of Sawtooth, but there's probably two levels of patterns there. So in the most abstract sense, you could take just a subset of what's there and use that for the Hyperledger Explorer project. And there, I think, the challenge with the Hyperledger Explorer project is what's a common API to any Hyperledger ledger. And that might turn out to be a very small set of things. But then kind of the next abstraction out from that is what would you do to create a user interface? Generally, and there's some patterns there of you need some kind of web middle tier that's able to interpret what's available in the blockchain. So if you look out at a couple of the different explorers, like if you look at the Bitcoin space at Abe, what was done there a long time ago was basically importing that blockchain into a relational database and then being able to do queries against that relational database. And that seems to be an effective pattern. So it doesn't necessarily have to be a relational database, but you're kind of interpreting taking one form of database, being the blockchain, putting it into something that's already equipped with tooling or existing libraries that lets you have a richer interface put on top of it. I think the alternative pattern that you would have to develop is putting a lot of that query expressiveness into the validator itself and turning it into more of a web server or app server directly. And I think there's probably some... there's upsides and downsides to that, but I guess I'd take the stance for now that that's got negatives because it draws away from its core role as a consensus and, well, the validator itself as opposed to making it be some sort of web server-ish kind of utility. Okay, I have some more questions, but I'll follow up off one. Any other questions for Dan with the project? So that leaves us with just about 15 minutes for us to discuss a new proposal for a project called Cello. Is the on the line? Yeah, Brian, I'm here. Oh, and there's your slide deck. Okay, let's take it away. Yeah, I'd like to make the partition. However, we do not have the quorum today. I wonder how can we do the routing later? Well, I think it'd probably be worth demonstrating and for walking through your presentation for five, seven minutes. Don't linger too long. Make it open to questions, and then we can carry on follow-up conversations online and maybe discuss what it is next week's meeting again and if we've achieved quorum there, maybe it's something that could be approved there. Okay, cool. Then I will go through the slides. So today I'm presenting a proposal called Cello and it's actually a blockchain service in a blog platform. And everyone can see my screen, right? Yeah, yes, sir. Okay, okay, okay. So why do we have the Cello today if for the hypervisor users actually take the fabric, for example. The chain code developers, if they want some blockchain, then it has to use the existing set-up docs and those scripts to manually set up a chain for himself. And it was seen in the Slack channel. Actually, numbers of people made some difficulty to build these chains at least with lots of time. So we designed the Cello to offer the blockchain automatic and eventually. And this is the main scenario of what Cello can do. On the line, we can leverage existing infrastructure like the air metal servers and the machine machines. And using Cello, it can leverage those physical resources and build a blockchain pool for those users. And the Cello was designed to follow a very friendly framework. So it opened up to those existing infrastructure tools like the utilization platforms like OpenStack and those container techniques. And also we provide a very friendly portal and the rest of the server API for those users and the operators. So this is the main feature of the Cello. Mainly, it can manage the life circle of those blockchain and can respond to the blockchain request. Also, it supports some customization parameters. And today we support Docker and both swam at the infrastructure clear. We do help plan to let it support more infrastructure like the Kubernetes and the resource. And also, we have tests to deploy Cello with different architecture like from B-Power and X86 from bare metal servers and machine machines. And we also kind of extend it with those open source tools for the monitor and log and the healthy watching. So actually, there are multiple HM founders back here. I just highlight two. One is to support more on the line of structure tools like Kubernetes and resource. And the other one, today we support the hardware fabric and we want to support more hardware platforms like the source link and the IROHA. And the code is on the GitHub. So this is the design architecture of Cello. From the architecture, you can see the components are decoupled from each other. So this can make it very convenient for a flexible design. So if you want to replace it by one component like the monitoring of the health watcher with existing solutions, it's very convenient. And from the beginning, we designed Cello to try to cooperate with existing tools in the health watcher community. Like those set-up scripts and also the existing blockchain control project. Actually, Cello can be a very important complaint for our blockchain explorer. The typical scenario that Cello can help create a chain and the blockchain explorer can handle that chain and show the cities of the chain. So that's me about the proposal and the question. So as part of which blockchains are supported, this is Morali from DTCC. What blockchains do you support currently other than assuming Fabric? Yes, currently we already support the Habitator Fabric and that we have plans to support the other like FTL and Iroha. Just Fabric for now. Yeah, yeah, currently it's Fabric. Hello, it's Victor from Huawei. Can you hear me? Yeah, yeah, very clearly. I have a question about the architecture, Victor. What does COE driver stand for? You mean the container driver or the... The COE driver. Actually it's the container obstetrician engine driver like those tools to support SWATM or MISO. Okay, keep it like this. And I have a question. It looks like a fuel to open stack or magnum to containers. So I can consider it as a deployment tool but to grow into a fast platform I think we should more focus on functions like monitoring, logging and health, high availability. I have read your documents. You have mentioned that there is a plug-in mechanism and you can integrate a third party tool for these functions. I want to know which tools do you support nowadays? You mean for log or for... For monitoring, logging and health water? Yeah, actually there are many existing tools to collect those monitoring data and logging data and send to the database and then use the portal where we can see the statistic view. Currently I have written a monitor collector using Golang and our logging... We have our designed logging collector and we also have supported one existing logging collector. The name is Logspot. You can find it in the Giga Hub. Logstash? What do you mean? Actually Logstash is only one of the solutions that have many log collectors. Yeah, okay. I'm running by DDCC again. Okay. I heard I saw the mention of blockchain explorer. You know, DDCC Intel and IBM, we are working on a blockchain explorer. Is this something different or do we want to integrate our efforts into this or how does this work? Actually I think blockchain explorer and the shallow can work together very well with each other. As far as I know, the blockchain explorer only focuses on one existing chain, right? It will help people to see the chain seeders and do some operations on that chain. While shallow focuses on another perspective, it focuses on managing the life cycle of the chain and also it can support multiple chains. A very good example is using shallow, you can create a chain very quickly and then the chain will be bind to a blockchain explorer automatically and then you can provide the blockchain explorer to the user and it does explore the chain using the blockchain explorer. But I think we should combine efforts there rather than in terms of initiative. This is a very good initiative, right? Yes. Combine multiple blockchain or distributed ledger technology. But I think maybe we can talk off time in terms of the blockchain explorer part of this. Yeah, actually last time I checked out the blockchain explorer, there are some basic framework. I would be interested if you could introduce when we can get some release portion of the blockchain explorer project. Sure. So we will get in touch with our DDCC folks here who are in active development and we'll talk to Intel, IBM and other folks to get it all on the same page. Yeah, I think similarly outside of the blockchain explorer portion and for launching things, be it dockers or native instances, monitoring, there's some tool chain within the Sawtooth Lake project and it's probably worth doing some idea exchange, some cross-pollinization of what's already in that tool set that could be incorporated here or vice versa. So for example, Oh, hi Barbara, this is Leonard. As an architect, I just want to ask with regards to the framework you put together, architecture framework, that's good, I like that. But we have a guided principle for any solution to be highly scalable and secure. Could we therefore look to deploy it with this architecture with any additional components, say, into the cloud to ensure that we have a very flexible solution which can scale even at a cloud level for the future. I just want to ensure that we have the concerns that we are looking at in our overall architecture design. Has that been considered at all? Would we need to at some point? Say for example, let's say you have Hortonworks as a big data platform which can exist sort of as standalone servers within a premise but can also be deployed in the cloud as well for good scalability. I think that's a good standard approach we should address. I just want to make sure that we've given that some consideration. Yes, and actually the shallow project has been adopted in several cloud environments. One of the cloud environments has used it for nearly half a year and supports thousands of chains. We also adopted some individual projects from both the experience it can support. Another factor is today there are some commercial solutions for cloud chain as a service. I guess it will be cool if we can make it an initial solution as an open source solution. Okay, perfect. Any more questions? Yes, this is Mike. It looks like you talk about lifecycle and some things like that and it sounds like this is really a tool that's targeting simplification of prototyping and proof of concept kinds of things. Do you think that the facilities that you're providing here are or can be matured into something that could manage long running production chains? Is there sufficient monitoring and forensics to be able to do kind of live debugging, for example? Actually, I guess whether it is for long running or experimental needs depends on the majority of the underlying chain and chain plan form. Actually, it just helps to set up the chain and do some operational operations and data collection on that chain so it will not affect the chain running. Through our evaluation of nearly half a year, the cello plan form itself is very stable. Any more questions? Sort of. We found that we needed, when we were running a couple of the internal POCs, we found that the tools that we used for doing orchestration for prototyping testing purposes, for things that lasted a couple of days, the tools for that were very different than the tools we needed for something that we ran for three months with an active user community. You've got experience with, and if you've got some insights into how to extend this out to something that would be useful for something that would run for two years. The way you presume we will ever get to the point that we have via blockchains that are running for two years. I want to do it. You're at the top of the hour. I'm sorry. I hate to cut this off. This is an interesting conversation, and it should be continued. I would actually suggest this continue on the text of the steering committee list. I just want to be timely because we do have people with other calls and meetings and such. Thank you to Bawa for the presentation. Thank you to everyone for the questions, and looking forward to continuing this conversation online, and let's see if we can tee up a critical math to be able to move this forward to the next week's call. Thanks, everyone. Thanks, Brian. Thanks, everyone. Thank you. Thank you, Chad. Have a good day behind you. Thanks.