 Hey, great. Thanks, Todd. Welcome, everyone. Well, the first up is the action I interviewed. Todd, could you make it a little bit bigger so I can read it? Sorry. Thank you. Oops, that's too big. Oh, what happened? There we go. I think I can read it now. So the first action was for Chris and Mick to complete the read me blurb for the incubation, and I don't think I've seen that. Chris, I think you're on. I think you're on as well. So Chris and Mick, do you guys have an update on the... Hey, Chris, I'm just... I sent you the potential read me. Do you want me to just put it in as a PR on a high level? That's one way of doing it. Did you send me something? I didn't see it, or... There was a couple of paragraphs on the rewrite on the initial introduction. Okay. Could you just send it to the list? It may have been filtered out. I don't know. I'll have to look. I don't recall seeing it, though. I'll send it to the chat. Hello, this is Emmanuel from Accenture. Hi, Emmanuel. Welcome. Okay, so if you guys could send it to the list, that'd be great. What proposal is this? The next was for me to move the project lifecycle to the Wiki, and I didn't do it, but I know it did. So that one is done. And the same with the project proposal for the initial heavy age proposal that was moved to the Wiki. So those first three are done. The next one was for Dave to finalize the... I'm sorry. Is there a question? Yeah, I had sent to the TSC list. Yeah, so we met with Scott yesterday. It was fairly... Overall, we feel that Don's is strong. If you're not... He doesn't have mute on. I don't think he was as much of a mute on as Don was, somebody who was talking to Don is taking over the meeting. Turn on mute. I'm going to have to go ahead and mute everyone, and then please come off mute to talk. No, this is Chris Allen. I had sent a note to the list regarding the project lifecycle after some discussion. I met with Mick on Monday, and we're just talking about, in general, security software needs some additional stages, and I'm not sure that all the different stages that I put in my proposal are required, but I definitely feel like the experimental one is important. When you're doing a hackathon or things of that nature and want to share ideas, we need to have a category for that, which we don't, and then the evaluation stage that is basically an important intermediary stage where you can have it reviewed by cryptographers and security reviewers and security engineers and things of that nature, that just moving from, you know, into mature is too fast. So, you know, I wanted to, you know, I don't understand how the decisions are made as far as how the lifecycle document list is created. I've heard that, oh, this is the way that people do it, but this, I'm not really accepting that that's the way that people do it. So, anyhow, I posted the thing to my list. It was posted up for comments for weeks, but again, I think they're, you know, for whatever reason as far as, you know, how the processor hasn't really been an open discussion on it. So, I'm just, you know, I added it to my list of something I wanted to talk about. And if, you know, if nobody is interested in that evaluation, that's another story, but I think it's worthy of discussion. So, Chris, I mean, I think you were on the call when we approved this last week. So, I mean, we can have further discussion. One of the things that's on my list of things to do, and it should actually be in action, is to actually start the process of the TSC defining the exit criteria for an incubation, which is maybe what you're getting at. But it's, from my perspective, and I've been involved with quite a few open source initiatives that are running under open governance, and none of them go to this level of, you know, I don't even know what to call it, but I mean, incubation and then mature, and then, you know, wouldn't we call it? So, a lot of it I can throw out. It's the evaluation stage before mature. The, you know, it takes a lot of work to do a security review. It takes a lot of work to do the... That's not under debate, Chris. And I said that we're going to describe and define the process for the exit criteria. We will do that. But it doesn't seem to be that we have to actually change the life cycle itself in order to achieve that. So, if you've got specific criteria that should be addressed, let's start discussing that. Absolutely. Absolutely. But that doesn't change the process of going from incubation to mature. If you're saying that it's a very high bar, that's fine. We can have that discussion. But I don't think we need to have, you know, all these little fine-grained levels of, you know, between incubation and mature to describe... I don't see what value that adds. Again, I will accomplish some of these initiatives, and they all have incubation, they have mature, and they have deprecated or attic or other various terms that they use for the stuff that they're no longer using. So, if I can just... Is the concern... This is a question for Chris Allen. Chris, is the concern about the labels or about the criteria used to advance from stage to stage? It's a little bit of both, because it communicates things to the community that, you know, where sort of the intent is. The, you know, one of the things about incubation is that, you know, we're going to potentially have five, six different things that are going to be incubated. But we, on the other hand, we want... We have a goal of, you know, trying to bring things, choosing one for a single code base. You know, when is an incubation ready for serious review that, you know, basically, you know, we've reached a point where, you know, we really want to dive into deeply into that. And that's a signal and a process point that, you know, exists before production. And that's the... I mean, I put in a longer list, and I probably should not have, but the key one is that particular phase. It's something we're still careful with maturity. If you go back to view the minutes of the technical steering committee meetings, you'll see that one of the points that we agreed to do was to start focusing on exactly what the exit criteria was. And so, in the context of that discussion, Chris, this is, you know, we can certainly add in all the things that you're talking about as a function of the exit criteria from incubation to mature. But I don't think that it necessarily abrogates exactly what was in the lifecycle proposal in the first place. There's just... The pages are pretty clear. Everybody, you know, pretty much understands what these things mean. And I think we should move on. So, I mean, you know, what we can do is we can set up a small subgroup that starts focusing on the exit criteria. And you're more than welcome to participate in that, as is anybody. And, Chris, can I have a moment? Yep. There's some confusion. Several people have talked to me. Just to be really clear here, this is going to sound mildly repetitive, but this is an open-source project, right? There were five weeks of discussion around this topic. Everybody's welcome to participate. People did participate. If you don't feel like you can, you can. It's an open-source project. And so, you know, saying things like there's no open discussion, if you haven't had five weeks of open discussion, it's a community. And so, you have to, you the participants, you know, I'm from the Linux Foundation, I sit down on a lot of the projects, you the participants have to participate, and participating ex post facto doesn't help. So, if the discussion's going on, you have to be engaged in that discussion while it's going on. And once decisions are made, you have to move on. Coming back and bringing it up, it's not like anybody's excluded from those discussions. Everybody's invited in. There's 100 people on the call. And all 100 are welcome to comment. So, I just, I think there's a bit of an understanding, or lack of understanding here, that the TSC call is the discussion. And when the discussion's over, the discussion's over because the TSC has made a decision. Right, well, but the discussion can happen in Slack and on the mailing list. Yeah, yeah, absolutely, yeah. It's all part of that whole community. Right. So, let's move on with, you know, just wrap up the action item review, because I'd like to get to the Intel proposal. So, quickly, so Dave was going to finalize the wording on the white paper. Obviously, that means Dave and the working group, but, and get in front of the board to review. I take it that since the white paper's not finished, this hasn't been done, that's fine. Yeah. Yeah, so Chris, we, I think we were specifically talking about the section of the white paper that made reference to a permission versus a permissionless type. And we did, we did update that section. So, what we're planning to do, and I can cover this when we get, when we get to the working group update, but basically, you know, we're going to have our first draft, draft 01 or whatever, published next, next Wednesday. And then I think what we'd like to do is show that first draft and then specifically highlight that one section, because that's just the one, what we were talking about last week was just kind of, we wanted to zoom in there and just make sure that they're comfortable with how we're describing a non-permission use case as well. That's the point. All right. Thank you for the clarification. Todd, if you wouldn't mind just clarifying that, that action item and we'll track it. We'll do. And then I take it you updated the, did you update the minutes for the work group? Yep. Yep. So I was able to follow Patrick's format. And so now if you click on the white paper working group, you'll see a member section and then, you know, an entry for each week, each weekly meeting minutes. And that's in there. Okay. Thank you. Excellent. So we can close that one. Chris Allen, Chris Rowan rather, Canvas everybody interested in the identity subgroup and find out if they want to list or just use Slack. Chris will we be able to close on that? That's, we're having the meeting on Friday at 2 p.m. Eastern, 11 p.m., 11 a.m. And that is the first agenda item for the meeting. There are 14 people that have said that they want to participate in that discussion. Excellent. Also part of it is that we're not absolutely sure, you know, should this be a separate group or whatever. So, you know, this is just, you know, a first meeting to sort of Canvas what it is that, you know, why people are interested in the topic and what we want to try to do. It could be that it, you know, we instead roll into architecture or requirements. It just was a unique area. Okay. Great. So we'll just track this one, but thanks. And it sounds like there's a lot of good parts on the identity group. Todd, you want to update us? Whoops, just lost the agenda. You want to just update us on the two doodle polls and thinking about the tooling face-to-face and the next technical face-to-face? Yep. Sure thing. So in terms of the technical face-to-face, there have been about 20 people that have responded. The most likely date is looking like that Thursday and Friday after the consensus conference in New York. Though the following week looks really strong as well. I would like to see a few more people respond to the doodle poll. So we'll leave this open for about another day or so. So the people on this call and the people that see the TSC minutes have a chance to respond. And then we'll close on it from that point. But along those lines, if anyone in New York City or, you know, in the East Coast have space that they would be willing to offer up for this to hold the face-to-face, definitely get in touch with us and we'll be reaching out as well. And then on the other topic for the tooling face-to-face, only a couple people have responded at this point. Five people have responded. And three of those people are not available at any of the times that were proposed. So I suspect we're going to either need to look for a different time frame. Yeah, maybe we're starting to sort of run the calendar here. Maybe the things, although I did want to be able to sort of start this, maybe we just don't need a face-to-face and we just have to have a two, three hour call to sort through the various tooling needs. I started to put together a little bit of a list. I need to focus a little bit more on that maybe later today. And I can't remember what I was doing. I'll have to go back and look where I was doing that, whether it was a wiki or maybe it was just a slack. And have other people sort of chime in with some thoughts. But if a face-to-face is not in the cards, that's probably fine. It saves a little bit of budget for travel and so forth and we can just have a two to three hour call in the next week or so. All right, that sounds good. Yeah, so why don't I work with you and Steven and see if we can't figure out a time for a call and get that out to the list and anybody can dial in if they like. So I'm actually going to follow up with you and Steve. And Chris, to that end, there's a page on the wiki that I'm logging all of the meetings on. It's Hyperledger, Hyperledger wiki. And down in the bottom you'll see a list of a calendar link. If I've missed any on here, just send them over to me in Slack or wherever else. I have the recurring meetings, the working group meetings, and the meeting proposals up there right now, including the doodle links. And as they become meetings, I'll post them up here and this should be a good way to get them out and easily in hand. Excellent, thank you. This is Ram. It looks like I dialed in just around the time when you were talking about the word group updates. I just wanted to mention that, you know, we are meeting the architecture word group. About nine, 10 people were interested and about six, seven people have confirmed that they will be able to attend tomorrow based on the doodle poll. Okay, that's a little premature. We're just actually just going through the action items, but that's... Thank you. Thank you, Ram. Oh, you're going through the action item, sorry. Yeah, you're just clicking at the action items, right? And Phillip was just telling how he had created a calendar. I think Chris Rowland had suggested a calendar. I think it was a great idea, so Phillip just followed through with that. He was just identifying that he's posted the meeting times and so forth. So, any proposed or meetings that aren't listed in the calendar, please get with Phillip and he'll add them. Okay. Okay, so I think next up on the agenda, I lost my, here we go, is the proposal from Intel. And is there a link to it? I'm sorry, before we get into it, can I ask you a question? Can I ask a question of Chris Fennix? This is Jatinder Bali from Citigroup. Go ahead, I'm here. Yeah, so if there are... I just want to get your answer. If there are more than one very strong proposal for a hyperledger, are you considering, just like we have different versions of flavors of Linux, are you considering having two different fabrics, or would you not accept that and just say one has to be the best of both worlds and only one fabric would be accepted? So, let me see if I can address this. So, I think it's a good question. Thank you. And the answer is I don't really know. I think, again, as Phillip said, this is really a community. We have to, this is something that we as a community have to decide. This is not up to me or anybody, any individual. It's not to the board. It's up to collectively the TSC, ultimately, to make this decision. But here's my take. Here's what I'm thinking. And again, I don't want to take away, I think this proposal is fine, but I'm, you know, I would like to see that, you know, this group come out with a thing and a thing that can be used in multiple flavors, right? So, you know, we talked about the scope initially and how we were focusing on, you know, the very lowest layer, the sort of the core, not on building out a specific framework for banking or supply chain or anything else. And that from that core, you know, the analog of the Linux kernel that you could have multiple things, multiple flavors, multiple platforms that may compete or not, or that may be, you know, different domains and so forth. That's what I would personally, me personally. This is not me or it's not IBM. It's not the TSC. This is just me personally. It's not the TSC as drive towards an answer that, you know, the world can use. I know others, you know, think that there will be many blockchains and I think that's true. But I also think that at the core, there really don't necessarily need to be multiple, you know, entity managers and multiple, you know, databases and multiple, there may be different consensus modules, but I would hope that we could have a framework that could allow for pluggable consensus. And then, you know, that we don't necessarily need to have multiple approaches for how we deal with smart contracts, but we may have different smart contract languages, like we may have Hopper and we may have, you know, I don't know, the security or, you know, the go, you know, version that was contributed from IBM initially and so forth. I would hope that we had a number of different approaches for that, but those are just core pieces and that you can then assemble those core pieces, which we would, you know, strive to harden and so forth, just like they've done with the Linux kernel, but that would leave room for a market and a whole ecosystem of opportunity that was built from that kernel. So that's my personal vision. You know, we're going to discuss the Intel proposal and, you know, as we discussed in the past, we can have multiple proposals. And I don't necessarily, you know, I would hope that as we consider this proposal and potentially approve it that we also are starting to think about, I think what is hinted at in this proposal is how we can take some of the great ideas from all the different incubation proposals that we may or may not see and come out with something that we can all, you know, that we've collaborated on together and that we think addresses the, you know, the set of use cases and requirements that the requirements team is working on and so forth. Does that make sense? Yes, yes, definitely it makes sense, right? When I wake up on Monday morning, I love the Intel proposal. Tuesday I go back on IPM proposal, I love that one. It's, I mean, there are so many things in both and many other, I mean, many other legions, right, that we need at least, you know, your answer was great, right? If it has got these modules and then we can plug in previous modules, that would be fantastic. Yes, thank you. But, you know, so let's turn this over to Mick and Patrick to present and let's have a healthy discussion. So Mick, Patrick? Okay, thank you. This is Patrick Holmes from Intel. Can you see the screen? Okay. Yep, thank you. Okay, I am, you, in the agenda, you had a link to this document. I'm just displaying this, the same document that the link was to. Again, Patrick Holmes, Intel. This is a hyper ledger improvement proposal. It is co-sponsored by Mick Bowman at Intel Corporation and Richard Gindle Brown at R3. And the content came from both. I'm not going to read this word for word. I assume that's okay. I'll just walk through it. So, the abstract. So, the proposal is to accept the Intel distributed ledger into incubation. Incubation status and we're proposing the name Sawtooth Lake. And then collaborate with others to improve the project. Then formally evaluate it as one of the foundational platforms under the hyper ledger umbrella. The motivation is, well, first we think it has some compelling features. Most notable is that we've decoupled the ledger from the transactions. The second is the concept of transaction families. So, we have very extensible, very pluggable with different data models and transaction semantics. So, very extensible. And then we've also got the pluggable consensus which enables different consensus protocols. Which would support both permissioned and non-permission networks. So, we believe these are compelling features. They make it worthy of consideration. Eventual evaluation once we have an evaluation criteria. And we think having multiple code bases facilitates a deeper discussion of the requirements and vision. And we can explore and test different ones, different assumptions that underpin each of these designs. The members, the observers, the users could develop a better understanding of the problems at each approach. And maybe come up with some shared requirements. But there are also improvements to be made to all of the code bases. And while we figure out the use cases, the requirements, the evaluation criteria, we'd like to collaborate with others. Smart, passionate developers from both the hyper ledger companies and the public as best way to improve the software. So today we're proposing that this move into incubation status. We have several tasks in mind that we'd like to collaborate on. And I've listed several here. We need to continue to develop the artifacts, develop tutorials for developing transaction families, develop some transaction families, extend our endpoint registry transaction families to work with permission services, identity, authentication and permissions. Permission granularity from permission nodes right now, they're not permission, but they could be extended. Develop a blockchain explorer, a network explorer, etc. The effort depends on many factors, so I can't tell you I didn't size the effort to do all these things. It really depends on the community involvement. Intel is committing several full-time engineering resources to ensure the success. The initial maintainers would be myself and Sean Amonson at Intel. We are open to having other maintainers once they've made some significant contributions and demonstrated a good understanding of the code. Other Hyperledger project members have indicated to us they're evaluating the code and they've expressed interest. Now the how-to can change, but the idea is that we'd create a single repository within the Hyperledger organization named Sawtooth Lake. That repo would point out to another GitHub organization such as Sawtooth Lake, which would hold multiple repositories containing the project. We think that's a better approach than trying to combine all of the repositories into a single one. We also don't want to take more than one in the Hyperledger organization. In terms of closure, we'd work to continue on this project until it graduates to a mature status or we make some other decision. By that time, we think there'd be a more robust system for prioritizing managing improvement requests. That is the proposal. Thanks, Patrick. Any comments, thoughts, questions for Mick or Patrick? Richard here, is there a comment for me as a co-sponsor of this? Just to echo some of what Mick said, I was particularly pleased to see this contribution because it ties, I think, directly to a point that I and others have made that there are many architectures we should be exploring and this allows us to do it within, if the innovation is approved, allows us to do it in the context of the foundation. In particular, looking at some of the codes from the design docs, my sense is the Intel approach makes them as well as having a different design. It makes them very different assumptions about the problems it's trying to solve and how it might be used. I figured that could be quite a useful way to help us as a group get to a much clearer idea of what problem or problems we're trying to solve. So I hope this is one of many new proposals for incubation. Hey, Chris, this is Morali from DDCC. So this is a question for Patrick. So I saw several things being mentioned there in terms of data explorer and block explorer and other things. I just want to confirm. I think wouldn't the first step be as to how to integrate the Intel platform with the OPC or the other code bases? How does this interface with the other two things that we have? That would be the first step, correct? Not necessarily. I think it would be a mistake to rush to try and integrate as many different solutions as possible. I think we could wind up with a Frankenstein of a system. There are different languages, different architectures. I think it would be best to understand the different approaches, the different architectural approaches, the pros and cons of each, and do that first. As well as continue developing the requirements, the architecture, the white paper. So we understand what it is we're looking for. Okay, because I was going based off Chris' comment that we want to develop this common framework or fabric which will allow that plugability that other things could be added. So you're saying this will just independently evaluate first and then think about it later. So let me try a slightly different version of this, which is the OPC code base takes a very, starts from a kind of permissioned PBFT based consensus kind of model and then is trying to move towards other usages. The Intel chain starts from a more open permissionless model and is moving towards the permissioned spaces. And I think the two architectures will at worst inform us about what the potential design space is for the final solution, whatever that is. And if there are fundamental differences between the two of them, that's also useful to know because that identifies a couple of different optimization points. We don't have one database. We have structured database and the non-structured database are SQL and no SQL database because they serve different purposes. We try to make them as common as possible and try to build libraries that allow us to move back and forth between them, but they are different optimization points. So I second Chris on the ideal is to come out with a single set of building blocks that can be used to put together. I think the process in getting there and in particular having a plurality of approaches allows us to bring thinking from different sides to this problem as we sort of figure out what those components are. You know, I will say personally, I don't think there needs to be just one identity service. I think that identity is one of those things that we have historically found to be decentralized. This will give us an opportunity to actually do some exploration into those kinds of assertions about what works and what doesn't work. Thanks, Mick. So other questions, I was just trying to chase the chat, but it seems like this user interface doesn't like me to go back far enough because as soon as somebody types it, it tells me what the latest thing was. Chris, there was one question in case everybody's not following the chat. I forget who it was who asked. Somebody asked me, Richard here, how sort of the incremental and quarter of three were late? Are they the same thing? What's the relationship? The point I clarified in the chat is that they are separate and different, and in particular they make quite different assumptions. I think about the problem spaces to which they'll be put and the design that's needed as a result. And it's actually precisely for that reason that I was so keen to sponsor it because it does come from a very different way of thinking in a different problem space. So it adds to the range of options and then the range of thinking from which we can all draw and learn. So just to clarify, quarter, which we announced last week and is still under development, is separate. And as that matures a bit further, it's at that point where we will be releasing the source, but hopefully that clears that up. Okay. Thanks, Richard. So let me just ask generally the community here. You know, as I mentioned, and I think as you alluded, these environments can inform one another, and I hope they do. The question that I have, though, is how does that happen? And how shall we, as a community, how shall this TSC sort of set things up so that we are encouraging, you know, the sawtooth-like chocolate to get into the fabric, peanut butter, whatever. I mean, this is my concern and my fear is that if we, and again, I'm not saying that I don't support this. I do support, I'm fairly supportive of this notion, but I'm concerned that if we go off and develop sawtooth-like independent of the fabric proposal, that we approved the previous week, or two weeks ago I should say, that they become independent things with, and there's not a whole lot of cross-pollination. That's a little bit of what I'm concerned about, and I'd like to have, you know, I'd like to figure out how we can, you know, work towards getting some of that informed cross-pollinations and getting towards a process for how do we take these forward, whether we work them in parallel. So, Chris Allen, I'm really looking forward to doing exactly what you're talking about. I think, you know, in the week that I've had a chance to look at Sawtooth Lake, you know, we had some questions from the, you know, that emerged as part of the Hyperledger hackathon about, you know, how exactly to, you know, define some lines between the consensus layer and the business logic layer. And, you know, they're Tendermint, which is another group that has, you know, had some ideas in that space, but we weren't quite comfortable completely with that, and I thought Intel did a good job in that area. So, you know, one of the things that this can lead potentially to is things like, you know, OVC containers that are on top of, you know, a standard, you know, architecture that underneath can be, you know, Sawtooth's poet or, you know, a proof of work or a permission PBFT, you know, and, you know, it seemed like a definite improvement in that area. So I'm looking forward to, you know, looking at some other architectures as well for where, you know, they've got something that is, you know, innovative, that really does cross, you know, all the different use cases and, you know, drive things forward. So I'm hoping that there will be more, a few more incubations, and I'm very happy with the Sawtooth Lake proposal. Yeah, so again, thank you for that, Christopher. You know, and again, I agree very much that there's much that we can each learn from one another. And again, what I'm looking for more is a sort of thought process on how we make that happen. Maybe we look at the next hackathon and, you know, and we basically do a bit of musical chairs or something and, you know, have the LBC guys hacking on the Sawtooth Lake and vice versa. I don't know, I'm just sort of throwing that out. But I mean, I think we need to, I think collectively as a group, we need to figure out how we turn this into something that is collaborative and engaging as opposed to turning it into a bake-off, because I don't think a bake-off is a healthy situation. Chris, I think it's very good. Go ahead. Hi, Chris. This is Ram. I think, first of all, I think having a diverse set of solutions being brought here is, I think, a very good thing for the long-term success of this effort. And so, you know, I'm glad to see the internal contribution and especially the kind of different approach that they have taken. So with regard to, you know, the overall approach, you know, one of the reasons I've been kind of saying that, you know, discussions around the use cases, requirements leading up to, you know, a healthy debate on the architectural options in the architecture workgroup is that, you know, it gives us a forum, if you will, to have somewhat of a top-down approach, which we can then say, hey, you know, from the bottom up, the contributions, how can we evolve to a more, at least a unified framework, if you will? And I think it's very desirable to have as much of a unified framework as we can achieve and if we can use, you know, that kind of top-down discussion to say, hey, what are the pros and cons of the different approaches? What are the, if you will, if you have to divide the solution space into kind of different options, how do we want to kind of do that in a somewhat unified and thoughtful way? So I'm viewing that approach as the way where we can use those, you know, those discussions to come up with a unified framework. Now, whether we will end up with one ideal architecture, you know, that's an aspirational goal as far as I'm concerned, but I think we ought to try for it. Hi, this is Dave. So, you know, I could definitely envision over the course of the next six months, six or seven or eight new blockchain fabrics being proposed to come under the Linux Foundation Hyperledger project umbrella. And are we going to, I mean, this isn't specific to, you know, mixed proposal, which, again, I read through it, it looks great, like it a lot, but are we going to let every single proposal come in and live there, or is there going to be some kind of criteria that we're going to use to assess which ones we do want and which ones we won't? I mean, you know, what's preventing us to have, you know, Eris and Tenderman or maybe even Corda be proposed and then also come in there? And I guess the risk there is, maybe this isn't a risk at all, but maybe, especially if our attention gets spread out across lots of different things and, you know, we may not make enough progress on any one of them, or maybe it's a situation where, yeah, let's go ahead, let's them all come in and then we'll just see which one gets the larger development community and moves forward the fastest. But, you know, like I said, I think there's lots of potential future fabrics that I think are going to be proposed. I think if I was building a brand new blockchain, I would like, and I wanted to see it open source, I'd like it to be under the Linux Foundation and this as well. So, you know, we should be thinking ahead and deciding, you know, if we're going to make these evaluations, which ones we actually do want to incubate because of, you know, the timing and everything, you know. At what point do we say, okay, we've seen enough, we've considered enough, and maybe it's driven out of use cases and requirements, but, you know, I think there's going to be more coming. So, Dave, if I can just, you know, I think the earlier discussion went to what we were talking about, which is the kind of exit criteria. Do we put the filter on projects that are coming into incubation, or do we work hard on identifying what the set of exit criteria is for what comes out? Foster ideas, and it does change a little bit of our notion of what incubation and mature is. But I will agree completely with you that, you know, one of the things that does point out is that we don't have a sufficiently mature set of requirements or other criteria that help us kind of filter through these things. So, I agree. Hey, this is Morali from DDCC. I think, like, this is my opinion, I think we should all aim for a common fabric, you know, like Chris said, if everybody starts proposing, then we're all bifurcated, our resources will all be distributed. If we all work towards a common fabric, and the common fabric could be, you know, we can take much of it from Intel, or if you have to break down the components within the OBC or DH or whatever it is, right? But I think the aim should be developing this common fabric. Again, this is, you know, this is my opinion. Thanks, Morali. Other thoughts, comments? There's more chat. Kind of increasingly hard to track. This is Chris. I mean, I think this is sort of the root of why, you know, there were some questions in the last two calls regarding the, you know, the initial incubation, which is we didn't have that, you know, enough requirements and architecture things that some of us were uncomfortable with the incubation status because we felt like, gosh, that means, thus, that means that has to be the base fabric. And we were basically told, no, it isn't the, you know, necessarily the base fabric, and that there will be multiple incubations. And now we're kind of, you know, coming back and going, well, no, well, we want to have a single fabric and thus those things that are incubation have to be, you know, have to be already in it. And I still come back to, I mean, whether or not it's through the lifecycle or not, it's feeling like we're missing a couple of stages, which was kind of my opening argument in the beginning, that there is an evaluation stage that is, you know, missing here either before going to incubation or out of incubation into, you know, to mature. So, I don't know. Yeah, I think this is Sharon from IBM, you know, Ben's not on the phone today, but I do agree that we need to have a common fabric. And I believe pretty strongly, as I know, you know, the rest of my constituents here agree, we need to bring in the best pieces. And there's a lot of innovation in the industry, right, and we should bring these pieces together. So I want to make sure that whatever we do, right, we're looking at all the pieces coming in, bringing the best to the best and the best innovations together. But I also agree, we've got to make sure we get the requirements down so we're all headed to the right goal. And this is Morali from DDCC. And maybe Intel proposing this is that opportunity, right, of identifying, you know, what is the fabric from the Intel side, you know, what is the fabric from the OBC, what is the fabric that DAH has, right? And what are those? Can we pick and choose the best elements? Can they interoperate, right? Maybe this is the opportunity for us, you know, this hip will allow us to do that, go through that process. Yeah. And it's almost like this is why I really liked the face-to-face that we had, the hackathon, because I felt like, we're bad, the DAH pieces and the IBM pieces started to come together where we're trying to bring the pieces together. And then maybe we need to do that here. What pieces do we need to pull together from the two proposals together to figure out what's the best of the best and how do we move forward, right? And then from the third proposal that comes forward, same thing, right? This is Mark here. I agree with this 100%. I'm a big fan of sort of the modular architecture and plug-and-play and extensibility. And I think, you know, sort of, you know, the more proposals we have, the merrier. We just need to have some way of dealing with fragmentation and some way to try to streamline things so that we avoid sort of one-tenth of the people working on, you know, 10 different proposals. Hey, Chris, you know, this is Morali. You know, I can volunteer to, again, pull this team from Intel and IBM and DAH, right? To understand the fabric across all the three and, you know, see if there is something, you know, before getting into the code level, understand the architectures of each of those fabrics and see, you know, how things can work together, right? If that makes sense for the rest of the group. So if I can just jump in here. One of the things that I think is already starting to happen in the working groups that I'm participating in is that the different approaches are leading to some really nice generalizations. So at least in the white paper group, and I know in some of the discussions leading up to the architecture group, we'll see how that proceeds. And certainly from what I'm seeing built out in the requirements, use case groups. So I think, was it Sharon that was talking earlier? Again, I think that is our ultimate goal is to identify those pieces and to move there as quickly as possible. I think it's also useful for us to encourage a couple of different viewpoints that bring and apply tension to the architectural decisions that we've made to help us understand the spectrum of what those building blocks need to be. That is, you know, having one code base means that we come up with a really nice set of blocks which solves that one problem. So I think Mike was saying in the chat earlier just about the filter can be not at the incubation, but as it comes out of incubation and among the, I think, set of criteria are breadth of adoption, breadth of use, generality, appropriateness, all of those kind of criteria of what constitutes the best building blocks. Thanks, Mick. You know, I tend to agree very much. And, you know, I think that, you know, it's our job to figure out how to encourage that, right, encourage that output. You know, the thing that I'm very encouraged by is that, you know, this discussion is all about that. That makes me happy because, but again, I think, you know, the devil's in the details as they say, right? So here's what I would suggest. Let's take a vote on this, unless Mick, you guys want to let people think about this for a week or so. But if you're interested in having and calling for a vote, I could certainly start that process. But then let's, you know, let's take the next step of formally pulling together, you know, the group that we talked about doing. And, oh, is it hard to hear me? Can you hear? I can hear you, Chris. Let's pull together the group that's going to sort of noodle on the whole exit criteria perspective. And then, you know, let's also start thinking and discussing in Slack and the mailing list about just how, you know, different ideas about how we can sort of work to encourage the cross-team collaboration that I think is going to be necessary to achieve what we've been discussing this morning. Again, I'm very encouraged, but again, the devil's always in the details. And I guess I would like to call for a vote if we're in a situation to do that. And again, I don't see the incubation projects necessarily being bound to an answer to how we get to the end. I think the takeaway, and in many ways what I like about the fact that we have two, is that it's forcing us to start answering some of these questions about how we get there and what those criteria are. So, yeah. I agree. So, Nick's calling for a vote. Can I get a second? Sorry, I was on mute here. I was taking that. So, I do want to call you all. Sure thing. I'll just walk through quickly. Can I get a second manual? I'm on mute if you're on mute. I think Todd muted everybody at one point this morning. Come back to manual. Stan? Tomas? Yes. Stefan? Stefan, you may need to come off mute. Come back to Stefan in a second. Parda? Yes. And Chris? And Dave? Dave? You know, I'll say yes, but I think at some point we do need to draw a line in the sand and talk about how we're going to approach the next ones that are going to be proposed. And then just going back quickly, Stefan? Just going back quickly, Stefan. Yes. All right. And then lastly, Emmanuel on the line still. All right, Chris, that was nine of the 10 that were on the call at the start. I think we may have lost Emmanuel at some point. Okay. All right. So we have an approval. Thanks, everyone. Thank you. So I guess the action for Patrick and to me to start the discussion, I think, would people be interested in having an off cycle call? Well, an ad hoc call to talk about the exit and potentially entrance criteria, as David was suggesting. Isn't to a certain extent that's what the requirements group, which is meeting on Monday, an architecture group, which is meeting tomorrow, kind of beginning to establish? I think the requirements are an aspect of the criteria. I don't think they're exclusive. I think there are other things like, you know, many organizations, many open source projects require, you know, take Apache, for instance, so you have to demonstrate a diversity of contribution and participation, collaboration in order to exit incubation. So it can't just be a single vendor thing. And I think there are going to be other aspects, you know, the sort of the non-functionals that are going to be applied as well. And so, again, I think there's a broad set of things that we need to consider as part of this process. And I don't think it'll be all articulated in requirements. Again, this isn't waterfall, but I do. So I agree with you. I'm also concerned about the number of meetings. Well, I mean, we could, you know, I mean, I don't disagree, but we do have, you know, some work before us. You know, we could wait until next week, but that doesn't get us moving the ball. I'd like to move the ball. I'm going to have the discussion in Slack or mailing, you know, on the mailing list and try and get some of that out of the way. You know, that's an option before us. I'm asking basically if people are interested in having an ad hoc call early next week to start discussing some of this and start working on building a formal proposal in deafening silence. Does that mean nobody wants to do that? I think it's a good idea, Chris. You know, I'm just, myself, my calendar is just book solid next week. And I just don't have time personally, but I agree with you that it should happen. Then why don't we do this? Why don't we take it to Slack and start the discussion there and see if we can, you know, start work on maybe a Google Doc or something that starts to form our thoughts around that. All right. Try it that way. Okay. Thanks, Patrick. And as I mentioned, Todd, so Patrick has an action to get the repo and I have an action to start the discussion on the criteria. Next up is the workgroup readouts status updates. Patrick, you're up again. I'm up again. Okay. The requirements team meetings are going to be held every Monday from 8 to 9 Pacific time. The details, the meeting details will be announced today on every possible channel I can think of, so there's no confusion. There was no meeting this week while we were polling for the preferred daytime. Obviously, we could have had one. I apologize for that. We do have an agenda for Monday's meeting, which I discussed last time. Primrose from Accenture is going to go through the counterfeit drug use case. The progress is we discussed last week we're going to do top-down user stories, but we also thought we should do bottom-up and we now have an outline for our requirements document. It's just a start, but at least we've got something. And so we'll go from there. Okay. Thank you. Ron, you gave an update earlier, but you want to maybe just quickly repeat what you said earlier so that everybody who may not have been on at the time gets a... Ron, you may be on mute, or he may have had to leave. I think he had to leave. Sorry, I'm here. It's the mute. The multiple mutes. Yes. Just to recap what I said earlier, the architecture workgroup is going to meet tomorrow at 10 a.m. Pacific. I think I've sent the WebEx to the folks directly who responded as well as on Slack and on the email list. Please do join if you're interested. Initial meeting is just to go through the framework in terms of what communication channels we want to use, how frequently we want to meet, what are the tools we want to use, and also kind of get people's input on the work plan. Should we wait for the requirement workgroups to kind of be at least ready with their first set of requirements, or should we plunge ahead with the well-known architectural choices in front of us so forth? So looking forward to getting started this week. Great. Thank you, Ron. And Dave? Hi, yes. So as I mentioned, we have our minutes posted up on the Wiki. We met yesterday. We're meeting it weekly on Wednesdays, 1 p.m. Eastern Standard Time. And we had a full attendance. Everyone attended, and then they're right smack on time. Thanks, everyone. We kind of kicked off meeting reviewing the Wiki page structure, going over our prior minutes. We discussed the process that we would like people to follow for how we want to solicit feedback for the white paper. And basically every two weeks, we're going to be generating a PDF from our Google Docs working draft and putting that on the Wiki, and then alongside of that is going to be a form that we're going to ask people to that would like to provide feedback on the draft to kind of fill in there. It's a template for providing feedback and then that would be emailed to the working group members. And then we would be reviewing them and incorporating it into the next draft. So every two weeks, we're going to be posting a PDF alongside and reviewing people's feedback. And then we just started stepping through, going through the various revision proposals that the team had been made. And at the end, we just kind of talked about the process. Are we comfortable with it? We noted that it is going to take some time, but that's probably okay. In order to get everyone a chance to provide their suggestions and have enough discussion around it to actually update, it's going to take a little bit of time. But the fact that we already are incubating now two projects, it's not going to be holding back anyone. And also it would be good to be able to, to the extent that as we're making progress on the requirements and working in use case groups and things like that, and since members of our working group are also participating in there, we'll be able to get some of that feedback coming through those channels as well. And that's about it. Okay. Thanks, Dave. And Christopher. Yes, so immediately following the initial architecture meeting is a, let's call it a box for right now around identity. There are a lot of issues in the identity area that may or may not fit neatly into requirements or architecture. And we want to try to have a further discussion about specific around things like token hardware, different forms of authentication and authorization, privacy issues, selective disclosure, and other different things that are very specific to a number of the use cases that maybe are not the two, you know, the specific architecture requirements. So that'll be the discussion. We'll decide at that point whether or not we want to formally make it a working group and have further meetings at that time. Okay. Thank you. And last actually, we should be the continuous integration group. I haven't done anything there because the first thing we need to do is have this meeting with Steven and the Lynx Foundation infrastructure team to get the base tooling up and running the Garrett and figure out if it's Travis or Jenkins and so forth. So we have, I have an action to try and get that on the calendar for early next week. And I will do that. But I did have overwhelming response to that. So now that we have two projects, that's actually a good thing. But they're an awful lot. And so thank you for all of those of you who did sign up for the CI work. It sounds like we'll have lots of help with that. So that's a good thing. And that's really it. Unless anybody has anything else for the agenda, we can all get about 15 minutes back. If we're hearing no other agenda items than Todd, I think we're adjourned. Thanks everyone.