 Chris, at this point, we have eight of the 11 TSC members, so we've reached quorum and are ready to get started. Can you hear me? Yeah, somebody needs to go on mute, though. If you're not speaking, if you can go on mute. So good morning, everybody. I think the background noise I was trying to say is before. We have a number of items on the agenda this morning. Intel is bringing forward, and would like to discuss, I think, a proposed contribution. Is that correct? Is Patrick on? Okay. Alright, great. And then that'll be followed by, we have two documents that we've been noodling on for the past few weeks, and I think it's important that we sort of settle on these. This is the project lifecycle and the project proposal template, and so Arno and Vipin, are you on? Yep. Okay. We'll cover those, and hopefully we can finalize those and agree to them and make them formal things. Again, we can always change them after the fact, and bring up proposed changes to those, but I think it's important that we just sort of establish the initial set of ground rules. And then we have our work updates, so from requirements, architecture, white paper, and entity, and again, some of those are just getting underway, and that's fine, and maybe that can just be a call for participation. Then we have two upcoming face-to-faces. So we have tooling, continuous integration, face-to-face that we talked about on the last technical steering, when many of us were in Tahoe, and see what's more on proposed that we sort of get everybody together and we can sort of sprint through getting Garrett installed and configured appropriately and so forth and figure out exactly what it is that we need from a tooling and infrastructure perspective. And then that'll be followed by discussion of the next technical sort of hack-a-thon face-to-face following on the success of the one we had in Brooklyn. And then the other thing that I thought, I don't know if you caught this, but I think we just need to make sure that we power through the action items from the previous minutes. And I was just looking for my previous minutes, March 25th, I'll leave everybody, I was just, I had them. Okay, so from an action perspective, I was prepared, so we had an action, I was going to send a request to the list to solicit volunteers to join the continuous integration pipeline team, and I have done that, and we have a number of volunteers, which is great, and I created a Slack channel. There was just a couple, I think some people said, oh, people from my company can do this, so let's just follow that up, make sure everybody that intends to participate and contribute get on to Slack and join that channel so we can start coordinating. And then there was an action from the Linux Foundation, add identity mailing lists. Oh, oh, create an identity mailing list for Chris Allen. I didn't see that happen, did it, Philip? We'll get that sorted out shortly and connect directly with Chris on that. I think that was the action, I don't see any others. Oh, I know, there was an action for Chris and Mick to work on the REAPY. I'll take the blame for not having that done today. We've been having a conversation about it, we're meeting on it. I just want to make sure that we're, you know, that we stay on top of these things, that's all. Yes, we're aware of it. All right, so can you hear me okay, and can you see my screen? Yes, we can. Yes, cool. System works, okay, so thank you very much, I'd like to tell you about what we're doing today. We are open sourcing our project, which we're calling distributed ledger. Just going to give you one slide to cover some of the high points, and then I'm going to go visit the GitHub repo and then visit our documentation, should take only a few minutes. All right, thanks. So some of the key points of our distributed ledger, the first is that it is highly modular and extensible, and three examples of that here, the first is that we have multiple gossip topologies, we have both random walk and Barobasti Albert, the latter one being a scale free network with preferential attachment. Second is the consensus, we have something called poet, which I'll talk about in just a minute. We've also implemented a quorum voting consensus algorithm, and you can switch those just by changing the name in a configuration file, the same with the gossip topology. The third is the solution domains or problem domains or business logic, and for that we have something called transaction families, and what the transaction family, a transaction family provides the data model, the transaction semantics, and the validation. What we've done is we've separated the consensus from the business logic, so you can drop in new transaction families to do this. We include three transaction families, and the first one is a very simple distributed key value pair where the values have to be integers, it's called integer key, and just as an example of how to do a distributed key value pair, the second one is called an endpoint registry, which we use for registering our endpoints, and the third is the most complex, and that's called a marketplace, and that allows you to set up participants, asset types, assets, holdings, offers, exchanges between the participants, and so you could extend any of those three transaction families, you can use them as is certainly, and we have, very successfully, you can extend those or you can create new transaction families. Now the consensus algorithm that we're calling POIC for proof of elapsed time, and it's a power efficient replacement for proof of work. Very simply, each node calculates a target mean time to delay, it picks a random number, and then it delays that amount of time, and at the end of that amount of time it claims leadership by publishing the block, and it is that it would run inside a trusted execution environment such as Intel software gardener extensions or SGX, and that environment would provide and provide certificates of attestation in some way, not only that the random number was picked in a trusted environment, but also that the delay executed in a trusted environment, and you can get this, or see this, at github.com slash intel ledger with two Ls. Okay, so let's go to the repository, I'm sorry the project, so here's the Intel ledger project, we have several repos, I'll go over just a go over a few of them, so our internal name for this project was Sawtooth, so you will see Sawtooth here and there. Sawtooth core is the fundamental components, and if you go down to the readme, you'll see a couple of things, one of them is a link to our documentation, all of the readme is linked to our documentation, and then an explanation of what's in the repo. So Sawtooth core is the core components, Sawtooth validator is the validator process, so this includes the startup and all of the configuration settings and all of that wrapped around the Sawtooth core components to build the validator process, and that's in here, and then the third one is, and that validator, by the way, includes the implementation of the integer key and endpoint because they're very simple transaction families, and then the Sawtooth marketplace, as I said, is a more complex transaction family, so that's in a separate repo, which is a Sawtooth marketplace. And then the Sawtooth dev tools is the vagrant environment, you can jump in there, you can start a vagrant environment, SSH into it, and be up and running tests and our tutorial in a matter of minutes. Hopefully, we have tested it many times on many systems and it works well, and then lastly is the docs, which is the source code of our documentation. So jumping to our documentation, that's on GitHub.io, posted there, it's generated from our documentation files, we've got an introduction, which explains what I've said in a little more depth. We've got a tutorial, so this one not only gets you started bringing up vagrant, but also running a marketplace, and in this marketplace, you're actually creating participants, asset types, assets, holdings, doing offers and exchanges, which are all of the entity types supported in the marketplace. And then we have an API for the developer's guide, or we have a developer's guide that includes the API documentation and the web API documentation, and then the marketplace developer's guide explaining how to use some of the marketplace code. Anyone from in salt have any comments on this first, and then I would like to get other questions. Did I miss anything? Okay, all right, and then Chris, it's up to you how much time you want to allow for discussion or quick. I know you have a full agenda. I think we have time, so I mean, anybody's got any questions? One question is, so is it intended to make a formal proposal to incubate this or part of it, or help me understand where you're, you know. So today, we are simply announcing that it's out there. We're hoping people will go and look at it and study it and run a tutorial and get feedback to us. We would like to come back within a week, maybe two, but ideally a week with further proposals of what we'd like to do. Okay. Hello, Patrick. This is Thomas from DigitalSat. I understand you. Can you hear me? Yeah. I understand your proposal of proof of elapsed time as an alternative to proof of work, also in the sense that it is, since the block creation is random, there could be also parallel block creations in the network, right? So this means the blockchain would have to be the three orcs of the blockchain, right? Yes. Okay. I think that's a very, very important requirement then to incorporate such an algorithm, which I think is really a very exciting, very exciting development. Thank you. Right. So we have the equivalent, I believe it's the equivalent of the algorithm for the double spend problem in Bitcoin, right? So we have to back off some blocks and then go forward. It's a similar fork in. Patrick Richard here from R3. Thanks for this. Very exciting. I'll show some ignorance here now because I don't know how widely deployed SGX is. So it may well be that I'm not speaking accurately, but on the assumption that these chips are available, is it possible to use SGX with the code you release or code you plan to release? So in other words, could we or could people run something now or in the future where the proofs actually are coming from within the secure enclave, so to speak, rather than simulated? Is that in the plan? That sounds quite cool. It's a fantastic question. Thank you. So SGX is on some processors. It's not on all. So what we've done is we have created a poet simulator and that's what's in this release of the software. It simulates the behavior of poet running inside SGX, but it's not running in SGX. And for that reason, we have several cautions in the code in the documentation that this is not a secure implementation and should not be used for a production secure production environment because we're only simulating the trusted execution environment. We are still working our plans for a final implementation that would use a trusted environment. And Kelly can say more about that. Thanks. Yeah. So I'll jump in and set the algorithm that's there is the algorithm that would run in the trusted environment. So the intent is to provide all the performance and functional characteristics of the full-fledged deployment, but in a way that makes it easier to experiment with. One of the important aspects of the design is that, sorry, is there a question? Just feedback. One of the important aspects of the design is it brings things, it brings consensus back to something like one CPU, one vote, or one machine, one vote. And in order to put up test networks, if you want to run a simulated network of 20 validators on a single machine, it's actually a little bit easier to work with a simulated environment because you're not actually restricted then to running just a single one per device. I put up a few fact items on this that he asked me to get merged in this morning, but I was running a little behind. So we'll be doing updates to the docs throughout the day. And of course, ongoing, now that we're live out there. So there's also a Slack channel that will be referenced in the documentation. And we'd love to get feedback from the community in that channel and all the other channels that are available to us through Hyperledger. Hi, Dan and Patrick. This is Hart here. I was going to ask if there was a white paper on this or something written up like reasonably formably? No. The introduction in the documents is what we have today. I don't recall if Mick has a separate documentation. We've been working on this for a while. So there's been different versions of documentation going on and off for a while now, but I think what we have written up in the project documentation out on GitHub is at least a strong overview. And then of course, the code is fairly precise. Great, thank you very much. Hey, Dan and Patrick, this has been from IBM. Could you elaborate a little bit on what happens when the leader self-elected and sent out a batch of transaction? How is the validation work in your independent page today? Execute an engine or a scripting engine or something like that to execute the transaction? So the blocks are made up of just transaction identifiers, which are hashes of the transactions. And the transactions are also distributed through the gossip network. And to validate a block, it needs to validate each transaction, and then it will call out to the code in the transaction family to validate each transaction, which is what makes it extensible to new transaction families. And a code for the transaction family is part of the distributed ledger? It is part of, it is running on each node. Yes, you can think of the validators as a composition of the business logic, which is abstracted from the consensus mechanism, and then the selections of the consensus and peer protocols. Right, I'm trying to compare with either Bitcoin or OPC or DAH model, whether there is an interpreter or an execution environment for the, I call them the scripts for the transactions. I see what that is. Baked in as part of your distributed ledger code. Yeah, I see what you mean. So it's more on the side of being baked in. So our security model was more that the network would be safer if there wasn't arbitrary code execution. And so the transaction families are concretely defined and then deployed as modules on top of the validator. Okay, great. Thank you. This is Morali from DDCC. In terms of the business use cases, have you guys tried this platform in implementing any business use case like an IoT or other business use cases? Yeah, so that's a great question. Maybe, I'm not sure if that was Kelly or Mick that was going to jump in there, or neither possibly. Sorry, I was on mute there. Can you hear me now? Yeah. Yeah, so there's been a couple of different use cases that we haven't been heavily focused on IoT, but we have used the endpoint registry as one sort of example of that. We've also done, we did participate in the R3 projects. We did some financial service use cases, and we also have some work that's ongoing with other digital assets such as event ticketing. One of the motivations of the consensus protocol was to facilitate things like IoT where you would have considerably more nodes than what might be in say an isolated internal distributed ledger at a single facility or something like that. Yeah, and I think Mick can probably talk about this a little bit more, but we have tested the consensus mechanism with up to a thousand different participating validators. That's correct. I think the highest I pushed it was about 2,000 running on VM, so we weren't using, so we're using an emulated version, and the integer key transaction family that's in there is kind of our testing family. Thank you. Hi, this is Vani Khmerra from GTCC. Just wondering what kind of language support do you have for smart contract development? So the validator and the code is written in Python, so that would be the simplest language to implement the transaction family logic in as well. And the options again would be extending some of the existing Python transaction families that we have or if there was interest in creating a new transaction family. Like Patrick said, the easiest thing to do would be to do that in Python, but of course there's always ways to adapt different languages to intermix. Hi, this is Dave Vole. Did I hear you say earlier that the transaction families, do they support like a Turing complete language or not? You want to restrict it, so it's more deterministic? I guess you could look at it from two different ways. You can author a transaction family that has whatever kind of orthogonality you want in it, so you could author a transaction family that is fully Turing complete. You could, for example, attach something like an Ethereum style execution model as a transaction family. The example transaction families that we've written, though, have a restricted verbiage to them. And privacy is achieved through executing within the SGX secure environment? Is that the plan or the reality? So privacy, there's a number of things that we have working on in privacy. What we've got available today that's out there on the webpage that Patrick has up, there are not specific or different private mechanisms in that. But yeah, the short answer I guess is that what we anticipate is being able to do some unique things in SGX enclaves that afford a certain level of privacy confidentiality in the transaction models. Oh, I'm sorry, I was just going to just to clarify. So we wouldn't be able to implement something with just this code base yet. It hasn't quite been developed for that yet. Is that what you were saying? No, I was just saying that there wasn't like a private facility within this code. The transactions are fairly open at this point. But there's nothing that restricts you from layering any sort of privacy model into that. I was just going to say that the transaction families provide you a way of defining the set of semantics and what you want exposed at any given point. We are not in this release providing some of the fundamental capabilities for doing peer-to-peer private transactions at this point. And all I can say is that is a very interesting question for how to do SGX development for them. There's some work that's being done at Cornell and some other places that are already looking at those problems. But again, correct me, the transaction families, you could either extend marketplace or write a new transaction family, which could include encrypting the transactions. Absolutely. Yeah, absolutely. Patrick, just so much again. Your model basically restores one word per CPU. So how is your permission or identified? Did you develop the concept for that in the code please? Yeah, there are actually two parts, two levels to that. One is and the current transaction families don't use this for the validation process, but we've made the facility available should it be necessary. But all of the validators register themselves. There's a particular transaction family endpoint registry, which is used to identify all of the participating validators connection information identities for them. That can be used as a point of restriction for identity access to it. Again, one of our areas of development is how to make the identity processing more robust. And then the second thing is SGX signing allows us to at least identify the fact that two of what we call wait certificates originated from the same location. So we have at least an ability to identify and articulate enumerate participants in the validation process that way. So in a sense to avoid any kind of a civil attack on the network, at least there is an authority on your side basically certifying the uniqueness of the chip? Or how should I explain? Yeah, there's a hardware based key that's on every Intel platform. Either that key could be used as a sort of uniqueness or a unique identifier for the PC. The other option is that you can actually provision, for instance, in a private deployment, you could provision a unique key to each device into the SGX enclave that would be unextractable by the user of the system. And then that could be used to identify and prevent civil attacks. So there's both a sort of a solution, an already embedded unique key for permissionless settings that can be leveraged. Or in a private setting, you can actually provision a specific key to allow validation to happen on that platform. All right, that sounds great. Okay, I think we should wrap up. As Dan mentioned, the documentation within within hours will be updated with a flat channel. You can send an email to get an invite to the flat channel. We welcome discussion and questions on there and we will do our best to answer them as quickly as possible. I have to get off mute. I think we're not the only ones that do that. Yeah, yeah. Well, I cover up the thing because I have the full screen for the rest of it. Anyway. Okay, so next up, where did my agenda go? Next up is, oh, the project life cycle, and then we'll follow that so that I know you want to present the project life cycle. Yes. Hi, everyone. This is Arnold from IBM. So we actually already looked at this draft a few weeks ago. There were some people made some comments into the document. We edited the document as a, you know, in response to those comments. There were a couple of comments that came out, you know, concerns that came out in the in the cold last week, which I try to address. And those letters changes have been highlighted in the document. So if you scroll through it, you'll see a few on my train yellow highlighted areas. And so, you know, briefly, what this is about is trying to clarify the fact that what incubation actually entails the fact that incubation is meant to be fairly easy to get into because we want to, you know, make it easy for the community to bring new ideas and to explore. And so it's kind of a freefall in some ways from that point of view, because we want to possibly allow competing efforts to be in incubation. We don't want to preclude anything at that level. So the text was edited to make that clearer. There is also there was a question about the, the different stages that have been defined and how you progress through this, whether this is a linear progression or whether we can actually have this civil iteration. The answer is the latter. So I made the text clear on that prompt as well. And there's this notion that, of course, you know, if we make it really easy for the, for things to go into incubation, that means that there is no guarantee that because you get into incubation, your project will move any further than that. And so I added the sentence to that effect to say that, you know, there's no guarantee and some projects may never go beyond incubation. We may decide to abandon it. There is one question that was raised last week in the discussion that is still not being addressed by this document, because I think Chris had and took the action item to it's defining the criteria that would be used to move from, you know, incubate, maybe to get into incubation and then from incubation to match your stage. So I left that out. But other than that, I think the document, you know, seems to make sense. And I have tried to address all the questions that have been raised. If there are any others, please let me know. Otherwise, I think it's a fairly decent document that we could try to, you know, that we could adopt as the basis for now. And as Chris was saying earlier, we can always iterate and make changes as we move forward. Yeah, just a quick question. Are there particular specific reviews to go from state to state? How will a project go from incubation to mature? Are there gating reviews? Yeah. So the idea is that the, you know, within each project, there are some people who are, you know, labeled as leaders and they would decide with the community that's around involved in the project when they want to go to mature stage. And they have to have their own internal decision making process to get to that point. And then they bring it up to the TSC. Ultimately, the TSC is the body that decides whether a project goes to maturation or not. And this is what I meant. There is no, I mean, the process is just you bring it to the TSC, the TSC decides. What is not defined is how or what base is exactly the TSC decides. It is assumed that, you know, the leader of the project would come to the TSC with a proposal to move to a mature stage. And, you know, with information they feel is relevant. But we could define possibly, you know, some criteria. And we have, I mean, VP will talk about the template for the proposal that is used at the first stage. We could possibly have either a revision of this template for moving to the next stage or something equivalent to that. That's still open at this point. Okay. Thank you. Any other comments, questions, concerns? If not, then I'd like to suggest that we sort of, we take a quick vote and see if anybody is, if everybody is ready to sort of accept this as our, at least, you know, as I said, this is a starting point, you know, to be able to change it over time. That's our prerogative, obviously. And we'll go through a similar process of, you know, suggesting edits and so forth. But I would, I'd like to suggest that we have a quick vote to see if everybody would agree to accepting this as our life cycle going forward. How do you want to put that to a quick vote? So we can just walk through that, through everyone quickly. So, Stan? Yes. All right. Tamas? Tamas, are you there? All right. Parda? Yeah. Yep. Chris? Yep. Mick? Yeah. Dave? Richard? My apologies, I'm too liquid. It's the first time I've seen it, so I can't comment. I'll just abstain from it. Thank you. All right. Sounds good. So that's seven in favor and one abstaining. So that passes. All right. Thank you. So we'll move this in the Wiki someplace where it's not under proposals. Let's see. I'll put it on, I guess I'll put it on the TSC, so I'll move that a little bit later. So I'll take an action to move it. And so next up is the project proposal template. And Vipin, do you want to present that? And let me just link it in the chat. Here you go. So, Vipin? Yes, Chris. Like I said before, I do not have access to the Google Docs, so it would be good if somebody else brings it up, but to present anyway, I don't have access, but I have access through other means and I will do the talking. Okay. But Todd, if you want to give me a present, I can sit right there. So to give the context, basically, nothing much has come up, or nothing has come up except for Chris's comment that it should have something saying sponsor instead of author, which I've changed. That's where it stands until I heard Arno's comment just now, talking about criteria for transitioning in the lifecycle, which I think is, you know, probably beyond the scope of a proposal template, but you guys are free to comment on that. I will rest at this point because everybody has had a chance to comment. I've taken care of all the comments, I believe. If, Chris, you want to take over at this point, or should I say anything else? No, I think that's fine, unless anybody has questions, comments, concerns, hopefully everybody's been out there for a while. I think we've gone over this, I think, a couple of times before. And we've used it in anger, so to speak, with the previous proposal that we just approved for incubation. So with that said, unless anybody's got questions or concerns, I would propose that we thank Bippin for his efforts and adopt this as the proposal template. Did someone just comment on this? I see a highlight, but I don't see anything. Okay, I don't see anything either. Yeah. So, Todd, let's put this one to about two then, please. All right, sounds good. We'll just walk through the list again. Stan? Hi. Tamash? Yes. Parda? Yes. Hart? Yeah. Yes. Yes. Chris? Yes. Yes. Mick? Yes. A nice work, Bippin. Yes. That's great. That's all eight that passes unanimously. Then I'll take an action. Thanks, everyone. Let's see where my agenda go. Next up are the updates from the various working groups. So first up is Patrick with requirements of use case. Okay. I just posted the link to the page. We held our first online meeting and there's a pointer to the agenda there. In case you're interested and you missed it, the meeting was announced on the Slack requirements channel and an email to all of the, or most of the people who have told me they want to be members. It was not on the TSC mailing list. I'll make sure the next one is. We reviewed the goal of the group, which is to create system requirements and not use cases. However, we do agree that the best way to do that is through use cases. But to kind of look ahead, we're starting a project to define how the requirements will be created, organized, and presented. So we're working at it from both directions. We have an agreement in the next meeting to take at least one use case all the way through the process of completing the template, because many of them are not complete. And Primrose from Accenture has volunteered to do that with a counterfeit drug use case. So we'll start at the top and we will work through all the way through the use case template. Explain any requirements to people and add any that we may have missed. There was some discussion in the previous meeting about whether we should be using wikis or Google docs. We're going to continue to use wiki. And the day and time for the next meetings are not set. The one that we had wasn't ideal. So we're going to take a new one. And as I said, we'll announce it, I'll announce it on the TSC. And then also just a reminder, we have a semi-active Slack channel just for requirements. So if you're interested in requirements, please join us. Thank you. Any questions for Patrick? Oh, thank you very much. And thanks also for, I love the way you've written this up. This is great. Architecture, wow, are you on? I've lost, I can't see the, and they don't see long in the attendees. So I guess we can skip that one and go today. I saw him leave. He knew he was next. Anyway. Hi, yeah, Dave Vole here. Yes. So we too had our first meeting post face-to-face yesterday for the White Paper Working Group. You know, we, unfortunately I haven't, I've been in back-to-back meetings since that one. So I haven't had a chance to update it, but I will, as I have done before, follow Patrick's good guidance on the proper way of posting the documentation and things. So thank you, Patrick, for doing that. So yeah, I'll follow the same format. Okay. So we had, yeah, thanks. Yeah, so we had, you know, we started off kind of inviting our three new members. So Noam from Digital Asset, Morali, and Mick are, were added since the face-to-face, and so that makes the membership at nine. And so one of the, you know, other people have been kind of reaching out and saying, oh, we want to, want to be on there, want to be on there. You know, I think it's nine is a pretty good size working group. And, you know, we certainly want to incorporate other people's feedback, but I think, you know, we agree that we want to kind of freeze the membership at this point. Now, Staha, I know you had, you had asked about that. Noam actually wasn't able to join us, and I know it's, it's a tough time for him being in Israel also. Be happy to swap you out for Noam as a Digital Asset representative. But as in terms of the size, we agreed that we're going to kind of keep it to nine members. We talked a bit about, you know, just kind of reviewing, you know, why were we starting off with the OBC White Paper? You know, is everyone comfortable with that? I know if we kind of chuckled at the coin desk article that, you know, said it was kind of raising eyebrows or was a little interesting, but, you know, we kind of, we reiterated it. It wasn't just so much as a, you know, rubber stamping OBC as our platform, you know, it was just really taking it from the perspective that, you know, the White Paper really was very well written, and it kind of set a minimum bar for technical journalistic rigor in describing the rationale and approach for the distributed ledger platform. So, you know, they just did a, a franking company just did such a good job of putting together the argument and the professional writing, and so everyone seemed to agree that, yeah, it makes sense. We're going to modify it to reflect what's different, but we're all, all comfortable with moving on that strategy. We, we spent a little bit of time talking about the logistics of the White Paper, what we wanted to do, what we're going to do, and anyone, you know, jump in here if I get this wrong, but so every, every two weeks we're going to, we plan on publishing a new version of the draft so people can review it. You know, we, we definitely want broad community feedback and, you know, we'll define the process by updating our wiki page here on how people can submit their comments and, and suggestions and things like that. And then, you know, we'll do our best to get those incorporated into, you know, we'll, we're going to have weekly meetings, and then every two weeks we'll be pushing out a new updated version. And we'll be, in addition to the wiki page, you know, we'll just make sure everyone knows how to comment and provide feedback through Slack and the tech mailing list. We also talked about the Google Docs. So Google Docs is, is good for now, but once this thing starts to settle in, we'll probably migrate it over to Latech. And, and that has certain advantages, you know, it can be, you can start doing, you can put into, to get repo, you can, you know, start versioning and pull requests and things like that. But we're going to keep it in, in Google Docs until we, until it starts to settle in. And, you know, like we've said before, this is not, this is, you know, this is going to be a living document as, as Hyperledger itself evolves, will be evolving the white paper. We did talk a little bit about, you know, should we have a white paper for each code stack? And the answer is pretty much no, no, we think there should be one white paper and the white paper shouldn't have any, you know, implementation details or things that are specific to any specific fabric, you know, that is under the Hyperledger banner. But the way the, the paper now describes these high-level architectural components, we feel that that is pretty broadly applicable to most any type of distributed ledger. And so, you know, we're going to keep that level in there, which is at a high enough level again, that we feel that it should be able to align with multiple fabric type of implementations that may come in the future even. So, so that was a bit about around the logistics. And then we finally got into the actual edits. We didn't, you know, didn't have a whole lot of time to get through that. We did accept a bunch of the, of the earlier suggestions that the members were putting in there for edits. And, you know, and in fact, just getting to the background section of the paper, we talked a bit about the fact that, you know, OBC was originally designed to be permissioned only. And, and, you know, we are going to modify that to also say that we also envision the scope for, you know, other use cases that are more appropriate for a public permissionless type of mechanism. But it will probably, you know, be a later focus. We haven't exactly phrased that, but in a paragraph that we're all comfortable with. So once we do that, though, we are intending to get, we think it would be valuable to get board review and, and agreement. So, so, so that will be our goal for next week is to finalize a wording there, get something that we could actually get in front of the, the board to review and a pine on just to make sure that we're in alignment with their thinking as well. And yeah, and that was about it. So, so we'll be, I'll be updating the minutes similar to how Patrick has done. And we have another, and we'll be meeting each week. And, and that's, that's what we have achieved. Awesome. Thanks. And I think, you know, I definitely would encourage, you know, putting up, you know, how people can, even if they're not part of the working group, how they can, you know, comment and, and make suggestions and so forth. I think that'll be important to this going forward. Because I think it's, it's probably a case that everybody would agree that it's better to test things early than, you know, if we have something in there, then all of a sudden we have a big site over something that's already pretty far down the road. So I would, I would certainly encourage people to take, look, you know, maybe you might think about, you know, when do you guys have a, you know, reasonable draft that is worthy of review versus, oh, no, this one's still, you know, think about, and especially for, for these, and maybe for the requirements and use cases, Patrick, you know, when do you guys, you know, when you guys think you have something that's almost soon, you know, that you may share with others so that we can, you know, so that people can contain time to review them and so forth. I don't know if you want to call it that. A draft or a candidate draft or whatever, but something that would give people a sense of it is worthy of review. Yeah, so yeah, on the wiki, you know, we'll, we'll be saying, you know, our goal is to have draft 0.1, you know, of course, everyone can go in. One of the things we, I didn't actually initially realize was that when we made the document public for read only, I thought everyone would be able to see how we were putting in our suggestions for edits, but apparently that isn't the case. It's only if you have edit rights, can you actually see all the suggestions for edits that, that we were reviewing yesterday. So, so the only, so people can see, you know, the live accepted changes in kind of real time, if you will, but we do want to snapshot and say, okay, here's our, you know, 0.1 release, you know, and now we're going to have go to 0.2 on this date, or maybe we'll call draft 1, draft 2, whatever the numbering scheme will be, but, but they'll be in the wiki page and so people can click on it and even see how it's evolving from draft to draft possibly. Okay. All right, thanks. Next up is Chris, and Chris, I, you know, I realize you're just getting started, but I thought I'd give you an opportunity to, you know, reiterate your call for participation. Thank you. Yeah, so I reached out on the mailing list and we have a starting list of people that are, you know, interested in the, in the discussion. There's a couple of people have asked about, you know, where can we, you know, is this a discussion list? And I think last week, it was decided that by the, by this group that we didn't want to have a proliferation of lists. So I'm basically, you know, had to have to canvas everybody to talk about it further. You know, how do we want to meet and how do we want to have our discussions? But the basic idea is that, you know, when you're talking about a permission system, identity is an important part of it. And there are a lot of different models and complications on the identity side that we need to address. For instance, identity at the, you know, at the blockchain level is very, very different potentially than the identity from the business logic level. And how do we handle that? So that's the goal of the discussion. It may feed into the requirements working group, but it may, you know, may be a separate discussion. That's it. All right. Thanks, Chris. And so, yeah, I think there may be some confusion, but I thought, you know, there was an action that we're going to create a list of maybe the back and forth just didn't seem to have a clear resolution of it. You know, Phillip, if you and Tyler, you know, could work on getting that. I think it's fine having a list. You know, some people prefer Slack. Some people prefer lists. I think, if I understood correctly, that there is going to be some sort of a Slack and email integration that will have to work with Steve and his team to see where that stands. But I'm fine with creating a list. Well, I need to canvas everybody. It's been a pretty crazy week. So I'll canvas everybody who reply. There were about nine people that were interested in participating. And let me find out exactly what they would prefer. Okay, sure enough. I guess we can hold on. Chris, could you make sure I'm on the list? I believe I have this slide to your email. It's been from IBM. Yes, you have. I'm fairly, yes, I have your information. Okay, thank you. Okay. Great. Let's see. So next up, thanks, Chris. Next up is the two face-to-faces. So we try to see what small amounts would be on a TSD. And his suggestion was we get together for a half day or so. Somewhere convenient to go through what tool needs we would have and actually start the work of driving that integration. We've put in Garrett to lock down to get repos and integrating that with Slack and with Travis or whatever we're using for the build orchestration. And so I think the best way to deal with that is to put together a doodle poll and throw up some dates. And again, I think this is, from my understanding, was a half day, maybe a full day face-to-face. And probably in New York, I think we were waiting to see where the individual was going to be sourced from that would be primarily responsible, although Steve did tell me that they're pretty much a global team. They're on 24-7 and they have full coverage around the globe. But he's got hope in Toronto and I think also in Portland that he was considering. So hopefully we can get a name identified for who be our primary contact. And then we should get a poll out there probably within the next couple of weeks because I think they're starting to come together. There's a code repository. We need to get Garrett installed. And we need to get a build linked in that when people are checking in requests that we can actually drive a build, drive some of the unit integration tests and come back with whether or not Travis or Jenkins or whichever we use is giving us the green light and so forth. So anything we can do there I think will facilitate getting this full request merged more quickly. So that's the tooling face-to-face or the continuous integration face-to-face, if you will. And then the next hackathon, the next single face-to-face, we talked about doing around the first week of May. That also happens to coincide with the consensus event and there's also I think a hackathon of the weekend before consensus in New York. We did talk previously about where people would prefer to have the next hackathon while we were at the hackathon that was hosted by JPMorgan Chase. And it seemed like there was a heavier lean towards New York or East Coast. There was a few people that would prefer San Francisco and the West Coast where I am now. But I think New York seems to have went out. And again, if we want to do it in the beginning of May, maybe if we can organize it around an event where people are possibly already going to be attending, then that might be the right thing. So any thoughts on having another hackathon in New York and across the Philippines, Todd, whether or not they were able to solicit any offers? And if not, we can ask on the phone. A quick note. I believe that a number of companies are scheduling workshops and other things the day after the official consensus conference. So I'm kind of confused. Is this a simultaneously with or the week before or the week after or one day on Friday or what? Right. And so just as we just suggested with the tooling face to face and with the requirements group, I think we'll put out a doodle poll to figure out what day or days I'm thinking maybe two days would be good would be the best where we could get the most attendance. So but I'm just trying to sort of get a sense for is this in line with what others are thinking? Or is it people thinking that that week might just be too crowded? Hey, Chris, this is Hart here. I just wanted to comment that I think New York is probably great if there's already something out there that people are going to be traveling for. But it might be wise to consider the west coast for one of these at some point. So we can kind of engage the community and get more people interested on the west coast. I think a lot of people preferred the east coast at the previous face to face because well, most people were from the east coast. And I think if you took a similar poll at a west coast meeting, you'd get a strong west coast preference. That's possibly true, Hart. Thanks. And I tend to agree. I think we should move around. I don't think we should have it always in the same place, certainly or in the same even. But there are some people coming from Europe. And so also the east coast is a little bit more convenient for them. So any other thoughts on this? I think, yeah, let's just do a doodle poll and quickly get a sense for what dates might work for people. And then Phillip and Todd, you know, I'd like to start soliciting offers to Thomas. David, I wanted to join the spot, but that was a really awesome facility out there. I don't know if that's available. Sorry, I was on mute there. Possibly there was a little bit of sticker shock from our management on the cost with our internal stuff. We're big supporters of this, so I can ask again. But I can investigate that. Okay, fair enough. And we should also explore whether or not the project can offset some of that. Well, that's true. Yeah. So, I mean, that would certainly lower the barrier for a follow-up. So that could very well be the solution then. Okay, great. So I guess we need another action then for a doodle poll around the face-to-face the week of, I don't know what the actual date is, but it's the first week of May. And then that's, I guess, we're sort of at end of job unless anybody else has the items they think we should bring up. Hi, this is Vani Kamala from DTCC again. Something slightly off-topic. I see that these sessions are being recorded. So is there any way for us to get access to the recordings? So if you miss a meeting or a portion of the meeting? They're all posted in the Wiki. So if you look on the Wiki under the Technical Steering Committee, the minutes and the recordings are all posted. I have a question for Todd on chat, but I'm going to repeat it here. We want to publish our images, our Docker images out to Docker. And we've been using the location open blockchain. I like to change that to hyperledger location, but someone already has that location. Do we know whether that someone belongs to the hyperledger community? I'm not certain. I can connect with you offline after this call. Okay. I appreciate that. Okay. I think then that we're good. So thanks, everyone, and we'll talk to you all next week. Thank you, Chris. Thanks, Chris. Thanks, everybody.