 All right, and I see that Richard just joined from R3. So that brings us to 8 of 11 from the TSC. So we have Quorum at this point, Chris, to get things kicked off. Cool, thanks. Thanks, Todd. So on the agenda today, and we have the Action 9 review, we have a proposal from DTCC and IBM to discuss a proposed project incubator for Java chain code support for the fabric. And then we have our updates. But I'd like to add a couple of things. Richard, I'm glad you're able to join. Sorry, I'm late. No, no, no, no, no, that wasn't intended as a slight. None over them. But it's rude of me that these calls can't start till we have Quorum, and they're quite often. So sorry to overhear you. Yeah, so but since you've sent in some feedback on the white paper, I was hoping maybe you could just go over that and some of your thoughts. Since we have a fairly light agenda, I thought that would be good. I also sent out in response to one of my action items to come up with a representation policy. I did something to the list about an hour ago. And I thought maybe we could add that to the discussion as well, Todd. Are there any other topics people would like to bring up? No, OK. So the first action item is to me to send in a representation policy draft. And I have done that. So Todd, you can take that off. White paper review. So the white paper has been published. And there's a review feedback form. Or you can send an email to the list or however you want to channel that. So I think that's sort of ongoing. We've had feedback from Richard and our three, and we can talk about that. And I don't recall seeing any other submitted feedback. But maybe is Davon? Yeah, hi, Chris. So we do have the forum. We had our meeting yesterday. We reviewed the feedback that people had submitted. There was actually only two individuals. And I didn't see Richard's. So Richard, I'm not sure how that feedback was sent. But we actually would like people to use the link that we provide on our white paper working group to fill out the form. That way we have a little process where we go through, we're reviewing them, we're keeping track, we're going to have a feedback mechanism. But that's something I did want to discuss is how are we going to get more feedback? Because we only had two individuals that had actually submitted anything. Every time I pick it up to review it, it gets sidetracked. So I have to, I know I think everybody's probably in a very similar situation. Thanks, Dave. And then Todd, we have a couple of doodle polls out there. How are those going? Yeah, so if you haven't had a chance to complete the doodle poll for the June virtual hackathon or the July potentially West Coast hackathon, please do so. Today's the last day. We'll have people let us know their availability so we can get that locked down. For June, it's looking like the week of June 13th is likely the most popular. The follow up to that would be the week of June 27th. So please take a chance, take a quick stab at putting your availability in there. The one question that I did have is in terms of doing the virtual hackathon, I wanted to get feedback from the community in terms of what platforms they'd want to leverage to do that. Obviously, we can boot up a WebEx or go to meeting. We can have Slack running, the mailing lists, all of that. But what other tools or platforms would help this process for everyone to have a successful virtual hackathon? Welcome to WebEx. Press 1 to be connected to your meeting. I think we lost Todd. No, sorry. I'm still here. I was just muting someone who had stuff on the ground. It sounded like you dropped off abruptly. So you're saying, do we need other tools, like Google Hangouts or whatever, to facilitate some of this? Yep, exactly. Is there a platform? This is Morali from DDCC. Is there a platform where you can create virtual rooms and you know what attendees are there and join virtual rooms? I'm just thinking loud. Are there any platforms like that? Etherpad is used in some projects. And it's sort of that. I mean, you can have sort of a virtual live recorded for posterity. This is Brian. I think part of the value of a virtual hackathon is just the speed and the responsiveness of interactions using the existing tools. I mean, knowing that people are there and you're not competing for their attention, or at least only partially competing for their attention with their day jobs, or their kids strapped to their chests or whatever. I think the value is knowing that you'll get quick responses. And I think continuing to use a real-time channel like Slack is a good thing. And therefore, during this virtual hackathon, simply making sure that people are present and responding quickly is the key part of the value. So I don't know if people would find additional value in video or shared whiteboard. I guess that's conceivable. Etherpad is probably the, or simply Google Docs in the multi-editing mode. I don't know if any shared whiteboard thing that actually works, but in terms of real-time editing of a document or something, those might work. Do people find value in voice as a group in this kind of thing? Well, I think that if it's code involved, that using something like Screen Hero, which I think we get because we have Slack, would be an alternative for those of us who are hacking on the code and have a question. And they could run it with somebody on Slack and then open a Screen Hero session to essentially bear on problem solving or coming up with a write-out or whatever. And so forth. I've done a couple of virtual hackathons. And I think one of the main things is that there are some periodic kind of check-in times, in a sense, especially when you're doing something worldwide. If every eight hours or so, people kind of checked in to sort of say, hey, I'm beginning work in my time zone, and I'm going to be around, and I'm checking this. I'm going to be listening to Slack, or I will keep a Skype channel open, or I guess in this case, one of these things. It's really handy to sometimes be able to speak up and go, hey, does anybody have any experience with this? And somebody will pipe up that's in the same time crossover thing. In general, virtual hackathons do need a good beginning and a good end. So don't forget those. There was a question in chat about it being five days, and I think I have a concern about that as well. I was more thinking along the lines of a couple of days, where people could really know that there would be resources available to talk to. Yeah, Christopher. Yeah, go ahead. Just to clarify on that, we were just gauging general availability on a week-by-week basis, and it would not be five full days. We understand people have a lot else going on in their work lives. So just trying to see when critical mass was on a week-by-week basis, and we would narrow this down to two, three days to be in line with what we've been doing before. Thanks, Todd. So for those of you who haven't already hit up the doodle polls, please do. And then we'll narrow that down. And I think we can take the discussion of any other additional tools that we may or may not want to use to email. And then finally, I had promised to summarize the exit criteria, and God, I need a clone. So I'll get to that next week. So as I said before, I had sent a proposal for the representation policy to the mailing list about an hour ago. And I thought maybe we could tee that up for discussion, but I can do a welcome paste into the chat what I sent so that we can all look at it. Or Todd, maybe you could just screenshot the email or something. If you'd give me a sec, I can drop it into a Google Doc to share out. Oh, OK, cool. And I'm looking for my note. I can post it in, Chris, if you want. I think Todd's getting it. I'm just, my God, I've just way too much email. How did I pre-pathetic when you can't even find your own email? All right, I just dropped that into the chat window. Thanks. So as we have discussed previously, there's been a couple of occasions where one of the TSE members has been able to attend. Maybe they're on a plane or with a customer or we've got a baby strapped to their chest. And I think the intent of the TSE was essentially to be individuals who were essentially chosen by the community to provide the leadership from a technical perspective. But initially, we didn't really have that, right? And so what we chose to do instead as we formed the governance was to set aside a six-month sort of get-to-news and where the TSE would be a representation of the members of the, the premier members of the foundation or the project, I should say, chosen by those companies essentially to represent them for the initial six months. And then we would hold an election where those individuals who've contributed are both eligible to sort of either self-nominate or be nominated to serve on the TSE. And who, again, those individuals who contributed are the ones that get to cast a ballot for representation on the TSE. So what we talked about the last time was, well, in most organizations that have sort of representation, sort of member representation, some standards bodies and some other foundation committees and so forth, typically you can send an alternate if you're unable to attend and they can speak on behalf of the company. And so I thought we should probably formalize a policy and make it clear that that policy, that we would extend a policy to allow somebody to send regrets and name a designated hitter to represent them as an alternate and for a particular meeting or meetings as the case may be. And then once we go through the election process and actually select individuals that are elected into the TSE, that that policy would be abandoned. So I tried to write that down. And then the one exception that I had is the project technical, I'm sorry, the project leads that are representing their respective projects on the TSE, they could send a designated alternate to represent the project as long as they give it an advance notice to the staff and chair. So thoughts, comments, concerns? Question for you, how many project leads are there on, well, are anticipated to be part of the TSE versus the elected ones? And do project leads also vote? Yeah. How many project leads is, how many projects there are? Currently, we have two in incubation, really. I mean, there's sub-projects. But I think we have to, as a group, decide what a project is and so forth. But is it something that's in incubation out of incubation? These are things I think we can decide, as a group, as long as we decide them before we have to use them in anger. But all good questions, but in terms of whether they get a vote, absolutely, they're the leaders. Is the transfer process documented someplace? I went looking for it the other day and couldn't find a long route. Is the what process? The, how we do this transformation from the first six months to the rest, is that document? It's in the, I don't know, Mike's on it. I think it's in the bylaws. It's in the charter. I'll paste the link in and reference the section in just a second. Thanks. Chris, this is a part of the, I had a few questions that I emailed. How long do these members serve? Did any periodic elections, things like that? Well, it's a year, but it's not really relevant to this discussion. Again, this is about just dealing with the representation policy to allow for this period, for this initial six month period, to allow somebody to designate an alternate if they're unable to attend. That's really what this is about. So we shouldn't, I mean, we can have a conversation around the election process, how we're gonna go about doing that. We need to have that fairly soon, but I'd like to just run out, just focus on this particular policy. So I'll, I'd like to second this motion. I think that makes sense as long as, you know, the voting, so the basic idea is that, you know, as if you were elected, you're sort of representing your constituency, not your company, the people who elected you in a sense. The point is that, you know, you're the only one who can do so. The, so I think I agree with that in principle. And then I think the, you know, the open question is, can project leads do this, you know, can project leads delegate? And I think that makes sense as long as it's not a large number. So I'm in favor of the proposals. Alice, you had a question. Should there be guidelines about the qualifications and the employment of the alternates that's sent? That's a good point. What do people think about that? I'll speak to it real briefly. I mean, you know, the, you know, so we're only talking about the project's leads, that they're the only ones. No, no, no, no. Well, okay. Go ahead, sorry Chris, go ahead. Good. As I understood the proposal, only the, once we transition, only the project leads can delegate. And, you know, I think the key thing is that, you know, has to be somebody in the project. I mean, somebody in that project, which seems very reasonable, but I don't think that person needs to be a, you know, have any, you know, much higher qualification other than the fact that the project lead goes, hey, you know, I need somebody knowledgeable to represent me at the meeting. A knowledgeable at the project. I don't know that there needs to be much more than that. I think it's a little bit different, you know, for the other, but we've said that the others can't delegate, so. Yeah, so on that part I agree. I guess I was, Alice, and maybe you could just type in chat if you're not on the line, but as to whether or not you referred to the project leads sending an alternate, or if you're referring to the initial six month period that we're almost done with where, you know, I might send somebody from Oracle. I'm not sure if that, maybe you could clarify which alternate you were referring to. Oh, she meant both, okay. Yeah, so I tend to agree with Christopher. I think that, you know, and I try to write it, you know, the project lead gets to designate somebody to represent their project in their absence, so I don't know if we could qualify, or clarify that to indicate that it has to be somebody from the project, or, you know, that's active in the project. I thought that was implied, but we could be more precise, I suppose. And then, you know, I would assume that if somebody sends somebody from their company in their stead, I agree with Dan. It's up to the Dell elevator to make their decision responsibly. If it been, no mention of project leads, Dan, actually Charter doesn't include project leads for steady state and TSE. I thought it did. Where's Mike, when you need him? No, I just mentioned for the startup period, but not for the steady state. You know, I'll have to talk to Mike about that. I think that's, I think the maintainer was supposed to be in the steady state. That's my bad. I'll have to go back and talk with Mike about that. I think, trying to remember if we talked about this. Oh, no, no, no, no, no, that's correct. Yeah. So maybe we don't need that class. I think, yeah, now that I'm thinking back, and I think that we decided to eliminate the maintainers as automatic, thinking that, well, they would likely get a vote from the community anyway. And since there were, we were gonna have 11. There could be potentially more projects or sub-projects, and therefore we might get in a situation where we had too many, so we decided to just make it elected. I'll double check with Mike to make sure that was the case. So, given that, thanks, good catch, Stan. Then probably don't need that qualification. And what do people think about that? Let's see, Todd. Are you paced at that? So, it sounds like, I mean, the main thing is if you're elected, you can't delegate. Right, that's right. So that's the bottom line proposal. So I would suggest removing the highlighted portion there. Are you sharing something that's highlighted? Yeah, Todd paced a link to a Google Doc. It's just got cut and pasted in my email so that we could all edit it collectively. Good catch, Stan. So people have had enough time. So now it basically says, propose that we adopt policy that permitted TSE member to send regrets for a given meeting and designate an alternate. Once the TSE is comprised of elected individuals, this policy will be abandoned and representation will be exclusive to the elected individual. Does everybody agree? That's good to me. All right, you wanna move that, Mick? And we can just get a, Todd can do a roll. Yeah, I move that we accept Chris's proposal for alternate representation. I guess second, please. I think I heard a second in there. Seconded. Thank you. Thanks, Stan. So, Todd, you wanna go through a roll, please? Yep. So, Stan, that was a yes. Tamash, Tamash, are you on the line still? Yes. All right. Stefan? Yes. Parda? Yes. Part? Yes. Oshima-san? Yes. Chris? Yes, please. Vic? Yeah. Dave? Yes. And Richard? Yes. All right, great. That passes unanimously. Screen go, here it is. Okay, so up next is Morali. Are you gonna present the proposal? For... Sure, I can. Thanks. Yeah, sure. Or Sheehan, up to you. Go ahead, I'm happy to have you do it. Okay, sure. So, let me post the link in the chat window. Give me a second. So, we posted the proposal in the wiki and slagged it two days before. So, basically the proposal from DDCC and IBM is that right now from a chain code or smart contracts, the goal language is supported. But what we would want to do is also support Java as a language for specifying your smart contracts. So, Todd, do you mind sharing that on the screen for everybody to see or...? Does everyone have the link from chat? I was there. Okay, all right. So, if everybody has the link from the chat, I think from a proposal, it's pretty straightforward. We support the Java chain code and we'll work closely with IBM. IBM has done some initial work, has started some work towards that. And we would put in our resources from DDCC side. And Partha is our partner in crime who is also committed to this project along with IBM. So, I mean, in short, that's what it is. Support Java chain code. Any questions or any details that we need to answer? Just one question about how you envisage it working is that you would envisage people would take the core fabric code and for one set of use cases, they would deploy a version that has Java chain code and for a different independent set of use cases and hence a different network they may use Go or potentially some other language. Or is it that you would have an envisaging network that runs both chain code that is... So, some chain code is Java and some is Go, which means that anyone participating in that network would in reality need to be able to validate both types of transactions. So, I guess what I'm getting at is, is it envisaged that this would be a choice for at a network level or this would be an additional things that networks would support and therefore we're adding to the, I guess ultimately the complexity in the attack service, not necessarily a bad thing. Right, so for the same network, we should be allowed to specify the smart contract whether it's in Go or Java. So, Shihana or Chris, if you guys want to add in anything there, is that that's correct, right? We want to support both in the same network. Well, it's correct. I think it'd be a choice by the network essentially. So, they could either turn both of these on, they could turn just one on. Yeah, so it'd be a network decision. Okay, thanks. Do you envision further API for the Java added functionality compared to what is available at the Go chain code or is this just a literal translation of the interfaces or the inexistence? I think whatever interfaces that Go supports, the idea is we'll support the same interfaces from the Java side too. Thomas, does that answer your question or? Yes, yes, this was my question. So, it's basically the same chain code APIs as available in Go, just with an access from Java. Right, so I see several questions on the chat too. I think the first question is, what has already been accomplished or what is already working? Shihana, do you want to chime in on that? Yes, so a couple months back, IBM wrote an initial kind of experiment of Java chain code, which was working and running, but then it has since gotten out of sync with the current progress that's been made in the Fabric project. So the plan is that we will contribute that code in a branch initially, probably not. It may not be in a fully working state yet because it needs to catch up with the current Fabric APIs and then we'll work to add new APIs that have been added over the past month or two. Thank you, Shihana. I see Vipin and Greg asked the questions if Fabric allows mixed types. And I think we answered that question is in the same network, we should be able to have Go as well as Java smart contracts running at the same time. Then the next question is from Jean Safar. What about verifying the code, what version of Java? Any, I think we would support the latest, any thoughts on that from the group as to should we support the latest version going forward or should we support one older version too? Open to ideas there. So just a suggestion on that, that the whole concept of versioning is gonna be a really interesting challenge as a general problem. It would be nice to have some insights come out of your project that would help us understand the more general problem and how to architect for it. So this is not a proposed solution. This is just a, you know, this is a really interesting problem that we should be looking at. And I think this is a really nice area to start looking at. So to make you're talking about the versioning part of it, you know, not just the Java, but anything else in how do we version? Yeah, so I mean, presumably the Java that you have, the version of the Java that you have over time for long-lived ledgers is gonna have to evolve. And so managing the evolution, it's not just a single shot versioning. It's gonna be, it's not just a single shot selection of a Java version. It is a progression of versions over time and how that's reflected back into the semantics of the expected semantics for the behavior of the smart contract. This is Jeremy Severed. I would say that there are a whole host of issues related to this that are gonna come up that presumably would have to be worked out over time. So I think it would be great to get a start on it because there's versioning, not just of the VM that the contracts run, but of the deployed contracts themselves. And then inevitably somebody's gonna wanna run, write contracts in Perl or Shell or who knows what other language. So there may be a need at some point, just as the way that discussions about everything being pluggable that perhaps smart contracts need to be defined in some sort of language agnostic protocol form. So just a thought, but a lot of good things could come out of this migration. Yeah, I think this is a good thing to explore. So not that really helpful to this, but this is something we're doing a lot of work on with Corda, I guess as many of you know, when we're targeting the JVM in Corda. And there could be some opportunity here to look at these things together. And so all the points that have been made about versioning, about sandboxing, maybe even to the point of having a white list of acceptable deterministic classes in the libraries. Yeah, exactly, as part of just said, that they're all part of the correct design here. Thank you, thank you for the feedback guys. Well good point, so. Go ahead Chris, sorry. Was there another, oh determinism. So is there another question or are there questions for Morali? I don't hear anything. So I guess, you know, we can put the question. One quick clarification. So on the resources you said that you expect this to last about a month, to a month and a half, and presumably that's what the single specific version as opposed to some of these other questions that you're likely to help us expose going forward, right? Can you say the question again, Mike? Sorry. You're expecting this, what I saw in the project proposal was about a month. Right. And that's with a single Java version with a very specific set of constrained expectations on, I mean there's a bunch of questions about verbs and how you restrict access to generic functions. I'm assuming this is, that the month and a half seems like an optimistic estimate unless it's very constrained. So I think the estimates were based off, you know, part of it that was implemented by IBM. You know, we worked with IBM, you know, Sheehan and Morali from IBM. They helped us in the estimation part of it. So, you know, based off their feedback, we came up with that estimate. And like you said, the initial version is going to be what is supported on the go in terms of interfaces. And, you know, it's not probably going to be complete by any means, but it's going to be a first version, you know, equivalent to go that can be running on the same network. And then we'll expand that, you know, once it is table and published, then we can keep expanding on that. Okay, thanks. Any other questions? Are there, do you want to add anything from DD-60? No, Morali, I think you covered it all. So, I guess I'll put the question. We have agreement to, you know, to support this sort of sub-project proposal, I guess it would be because it'll be incorporated into the Hyperledger Fabric project. Any, I don't know, Todd, do you want to do a role, please? Actually, I should ask for somebody, I moved and said, let's get a second and then we can take a role. Yeah, I'll second. David? Thanks, mate. All right, Stan? Yes? Tamash? Yes? Stefan? Yes? Pardo? Oh, yes. Hart? Yes. Oshima-san? Yes. All right, and Chris? Yep. Mick? Yeah. Dave? Yes. And Richard? Yeah. All right, that passes unanimously. All right, thank you very much. Thank you guys and thanks for IBM support. Thanks for your proposal, thank you. Okay, I have to find the screen, let's see. Next up is workgroup updates. Oh, we wanted to have Richard, do you want to go through your feedback, Richard, on the white paper? Yeah, sure. So hi, everybody. So first of all, apologies that it was late. I was sitting there for a few days and also there wasn't a sense using the approved forum, but I figured something was better than nothing. I put quite a few, I sent it to, I think there's Hyperlegia Technical Discuss, I sent it to, so if you're not on that mailing list, you may not have received my feedback. I have now sent it to Dave Evolve, so you can get it from me or him if you don't have it and want to see it. I don't propose to go through all the comments line by line, there's quite a few of them. Instead I've just got six broad observations that maybe we can discuss or we can take as input. The first one was, so mostly minor and then there's one significant one and I'll come to the significant one at the end. So first observation was there are lots of unsupported assertions throughout the paper, primarily about the value of this technology, of blockchain technology and clearly, those of us who are involved in these projects completely believe those assertions, also why else would we be doing this? But the assertions do have to be justified. So I think we should be humble and somewhat modest by either saying that we believe this technology has wide reaching implications or we believe it will or we don't say it because the reality is with very few exceptions none of this technology is yet deployed at scale in production environments. So it's not correct to say we know for sure what it's impact will be. So that may just be a stylistic question but when I think about the good white papers you read and I think perhaps you know think about the seminal Bitcoin paper, it stood the test of time because it didn't make unsubstantiated claims. So I think we should dial back some of the rhetoric or at least qualify it. The second broad comment was there is a lot of assumed knowledge in the paper. So there were quite a few terms used without having been introduced or defined. And some that are probably one might think are appropriate to use blockchain being a perfect example but we know that these terms are evolving in their interpretation and different people understand different things from them. So I think the paper would benefit from just as a stylistic approach whenever we introduce say a term we define it or we have a glossary. But right now I think there's multiple opportunities for the paper to be misinterpreted because we use terms that aren't defined. The third point relates to vision. The thing that struck me was actually the vision there is a sectional vision. The reader is left wondering at the end actually what the vision is. The closest I got was and I think this may be the answer the closest I got was the vision is we believe we as the authors believe that blockchains need to be but lots of different blockchains all need to be built from the same underlying modular architecture. And that may not be true or I happen to think it's not but that's fine we can have a debate about that but it's not a particularly inspiring vision it's quite a specific technical one and it may or may not be true. And the point I made in the comment was I think you can make a compelling argument that the modularity in a single code base is desirable perhaps by analogy to the history of Linux but you do have to make the analogy you have to motivate it and take the reader with you. I should say even if that we don't know I'll probably push back on that but that's fine we can have a debate but right now the vision is not particularly clear and it's not justified with any either with any argument or with any rhetoric so there's a bit of what to do there. Fourth one generally and I guess this is a drive to it's fine but I think as a document that one would hope would have significant importance of visibility and would be the rallying cry for this project of projects I think the quality of the prose needs to be raised that may come out in the editing at the end but right now there are quite a few sentences that you have to read three times and at the end of it I still didn't understand what the sentence meant so there needs to be a focus on the quality of the written prose but again that's a minor comment because that can be addressed later and then on to two more significant ones and this is my fifth comment and there's a section labeled requirements but it doesn't really contain any requirements you know I expect requirements to have have words like must, should, may it should tell us what the system should do to a large extent the requirements section that should read to more like a sales pitch or a description of what the system does or is rather than the objectives against which it's being engineered that one may just be a style issue but I suspect there may actually be heavy lifting to do that to get that into shape and then my final comment and this is the significant one is the paper and this may be because of its heritage because you can still see echoes of the original OBC paper in it that the paper, at least to my view I don't think it yet adequately distinguishes between the vision, mission, objectives of the Hyperledger project as a whole and the design goals and the architecture of individual projects under incubation in that project so when we switch to the architecture section everything before that with a bit of work is something that in principle I think most people could sign up to after the fixes are made as a vision for the Hyperledger project as a whole and different designs could then flow from there but the architecture section onwards is essentially just a description of OBC or perhaps OBC with the bits of proof pieces added there's nothing that I could see about Sawtooth Lake and it wasn't made clear to the reader that there is the high level project and then there were code bases under incubation of which there may be many and we may never get to a single code base or instead if the objective is to get to a single code base that should be part of the vision and it should be justified so in summary that may sound like a whole mist of criticisms and it's not intended to be hopefully to take it in the spirit of constructive criticism some of them are just stylistic but one or two of them especially the requirements and the distinction between overall vision details about specific code bases that I think they are probably more fundamental but again still fixable Yeah, thanks Richard you know that's excellent feedback and very thoughtful and we'll certainly take all those points into consideration you know just one point on requirements for example you know and I guess maybe we need to make this a little bit more clear but you know this isn't meant to be the requirements document we really just wanted to provide some examples that would be illustrative of the types of features that we were looking to do and I guess we want to make that a little bit more clear but in fact you know we did receive other feedback submitted through the form where we discussed yesterday that you know there is some more examples that were being provided or use cases and requirements and in fact we felt that you know we wanted to have those ideas transferred over to the requirements working group and so yeah again you know we just are trying to be have a couple of samples that are illustrative of the type of features that we were looking to do but I mean the rest of your comments I think are really excellent and we can take those into heart and make some modifications to reflect that great thanks David thanks Dave and I echo David's things Richard they were it was great feedback so thank you any other comments questions on this topic otherwise we can move to the updates okay let's see Elizabeth first Oleg are you on yes I'm on good morning everyone well we're working on the use cases on the financial use cases in the group we discussed the swaps interest rate and currency swap we had an interesting discussion about asset depository use case which in our view is a base use case for many use cases for equity contracts and for fixed income and for property management so we're still discussing this use case different trading scenarios so whether they're traded over the counter or on the exchanges we'll probably need some help from members of the project from DTCC to validate this use case when we have it there's also a discussion on how much of the implementation of workflow detail do we need to include in our use cases basically we need to limit the use case document only to user stories or should we propose how this use cases can be solved or implemented by a blockchain this week work is I'm working on equity contracts and fixed income which like I said derived from asset depository frankly working on protection so hopefully in a week or so we'll pretty much complete all the financial use cases at least the first milestone that we need to break it through so all in all I think we've picked up speed like I said well we should be done some of the financial use cases and I'll move on to and I'm already working on peer-to-peer insurance and QIC global database so that's all from us okay thanks Oleg any questions for Oleg next up we have Ron hello folks so a quick update on the architecture of our group we had the larger group meet yesterday and we're making good progress on kind of understanding at least the consensus module and as well as the smart contract business logic layer and how those two interact to start off we had previously decided to use Slack as the primary communication channel and in yesterday is prompted by Brian's email we've had a discussion around is that still working for us as a group and we decided given that we wanted to have deeper discussions with appropriate context Slack is not working well for that so we are going to start a mailing list so Todd is working the logistics about setting that up and hopefully we will have some automated method to kind of move people over from the Slack channel to the to the mailing list if not then we'll just have people self subscribe to the mailing list we'll post post that on the Slack channel and hopefully we can have more of those discussions on the deeper discussions on the mailing list so just a quick reminder we you know ideally we would like to have the use cases and requirements kind of big before we we can have more detailed discussions holistically on the architecture but you know while we wait for the requirements were grouped to kind of work through those we decided to pick up the more obvious topics with some understanding of requirements preliminary requirements and deep dive into those and we picked you know the functionality and interaction of the consensus modules and the business logic smart contract layer if you will and that's what we're going down now and we broadly have two approaches one which is more closely aligned with the bitcoin style mechanisms and Sartu Lake as well and the other one approach that the fabric folks are are still developing and are in the process of documenting which is motivated by the requirements for confidential transactions and so you know the next step is to kind of understand and discuss the pros and cons of the two approaches and see whether both of those can can indeed meet some of the confidentiality requirements and hopefully by the end of that we'll be able to see whether we can align on one approach that's pretty much where we are right now okay thanks Ron any questions for Ron if not next up is oh last I lost my place next up is Dave so Dave I think you wanted to talk a little bit about yeah so um yes we had our our our update yesterday our weekly meeting and you know our we one of the things we just confirm that our strategy is to put an update and publish a new draft every other week so you know again basically the processes weekly we we review the the feedback that's been submitted discuss among ourselves either assign individuals to do the updates or we'll do it right there on on the call and then and then the following week is when we would we would incorporate those so the idea is to have a new new version every other week um as I had mentioned earlier the yesterday there there are only two individuals that had submitted feedback apologies Richard we didn't meet see yours so for some reason you know my corporate email is still filtering somehow some of these technical mailing list things it's odd Todd's email comes through but not the other so for whatever reasons right we miss that but it we we would appreciate if people you know if they go through the form on the white paper you know that we we'll be sure not to miss and we'll be sure to be able to respond to you know the suggestions for for feedback on the paper so yeah but it did seem light and in fact one of the things that we wanted to discuss and ask you know the TSC here is suggestions on how we could and get more feedback I mean we did think about you know right now unfortunately the the only way you would do this is kind of have to you know it's kind of buried in the wiki in the white paper working group in you know all the way down there you have to click on to see where to do the feedback we were thinking if we had something you know up on the charter page in the wiki or through hyperledger.org and maybe emails but you know we figure that perhaps Linux foundation could help with some of this as well so we could encourage more feedback from a broader audience I thought that that was part of the purpose of the new announcements list so I would like to see these types of things be put on the announcements list yeah that's a good idea yeah again this is supposed to be low traffic but you know when you want people to pay attention to something I think I agree with that the thing that struck me though was and I didn't say anything previously but I tend to you know it struck me when you know Richard sent me his feedback initially and then he sent it to the list it struck me that you know we hadn't seen any others I brought it up because I thought that was the only feedback and until you you noted this morning that you had a couple of others sending feedback I think part of the problem there is a sort of lack of visibility and you know my my my my my sense is that typically and I I thought we had some good conversation you know here this morning or under I think that typically it's when you see feedback from somebody else that often that triggers your own thought process and and that it's you know the active engaging in a conversation in a dialogue around a particular question or concern or or recommendation that I think we get the most engagement and I'm just wondering David maybe the right approach would be to you know even you know maybe even just set up a temporary mailing list where we could you know people could post their thoughts or an edited version of the you know or a commented version of the document and engage others in a discussion and if maybe that might trigger a little bit more interest and and generate a little bit more feedback I again I'm just sort of thinking out loud here but you know I was struck by you know so you guys have seen the feedback obviously from the others that sent it in through the form but nobody else has yeah that's an excellent that's an excellent point and yeah I don't think there's shouldn't be any reason why we would want to prevent other people from seeing suggestions so yeah I'm sort of that I know that wasn't that I know you're just trying to pick an appropriate way of collecting and and managing the feedback and email would obviously be a little bit more challenging because it's all over the map but so is there is there a Google link that allows for you know commenting directly on it I think last time I I tried looking at it it you know you couldn't you couldn't view it but you couldn't comment but if you're using Google Docs see there's this intermediary mode where you can invite people to comment on edit yeah I could you know I just I changed the end of it from I think view to edit on the URL and that that feature was available I just couldn't use it when I was on a plane but it just seemed to be the feature there yeah this is Brian I think my I think would be there's there's probably some input you want to incorporate from the feedback you've gotten already and I would take the time to make some changes incorporating that feedback but then I would post it to the announcements list and if there's concern also post about it to some of the other lists but I would I would try to have as few other channels for feedback as possible like no more than two and I would also encourage I mean this is this is a pretty foundational document in some ways this isn't quite the constitution for this group but it's pretty darn close to something you know that that really people will be rallying around and need to I think you'll comfortable with and I right now the the most common watering hole for the community I would argue would be the technical discuss list and so I think you know once you're ready for broader input and ready for what could be a high volume I would try to focus comments you know on the on technical discuss and maybe as comments in the Google Doc but not editing right just just try to have as few so that people see there's other activity and perhaps you can build upon each other's comment yeah that's that's that's a good idea you know the it's the one of the advantages of the form and you know also we could certainly make that that feedback form visible you know when somebody submits submits their feedback it actually you know the Google provides service spreadsheet list and way of organizing it so it's convenient for us as a group of people to just you know go down starting at the top one work our way down down down down and you know see and discuss some in isolation it's somewhat convenient for for us you know we we we want to make sure everyone has a a bit of an ability to voice their opinion on it not everyone is always in an agreement so so you know as a group we'll debate a couple of different ideas back and forth amongst ourselves and again you know it there's having that that structure very much helps facilitate that that workflow and but I also agree with and appreciate you know that when people see you know or the value of you know a group chat it just can really bring out a lot of good feedback as well so I guess we're just trying to we need to find the right balance but certainly you know adding visibility so everyone can see who has suggested what is would be a key way to make it happen my only issue you know with email lists is I know my email box is just crazy with so many things even with filters is I'm missing a lot of things now and then but but that's the benefit of of having these group chat sessions as well so that's those are all good suggestions thanks Dave next up is Christopher yes so we only meet by weekly so we didn't meet this week however we are hoping that next Wednesday we will have the IBM membership services team presenting you know a sort of a deeper dive into the architecture and a little bit about the cryptography and and confidential confidentiality support that the membership services feature of the the fabric demonstrates and so I have not received a confirmation that that they're going to be ready for Wednesday but I'm I'm hoping to okay thank you next up is me CI so we've actually made a lot of good progress this week I'm still catching up from yesterday there was a flurry of activity so I'm I'm not actually completely clear on exactly where we are but I think and I think that we have Jenkins up and running we're looking at getting it also to be able to spin out slaves onto different you know alternate alternate platforms so that's a a good thing and it's making some progress and I think that the beginnings of setting up at least for the fabric and I'm hoping that we can get the fabric API and the sawtooth lake going up there as well but there's the the beginnings of process to set up an actual pipeline and start getting the the processes flowing out and and and tied into some of the other various things I think you know we're going to have a little bit of work to do to integrate with slack and and the email or whatever as well as you know integrating some of the other various checks that we want to do when we when we get on to Garrett Garrett has also stood up but we're sort of in we're only using it currently actively for the the CI pipeline itself and and you know spinning up the Jenkins jobs and so forth but eventually we'll want to transition other things there as well so I think Todd what we probably need to do is schedule you know maybe just an overview training session I don't know if we want to take time out of a TSC call to do that or set up an independent office hours kind of a thing where maybe people if they're interested a need to could get a you know an immersion into using Garrett because I think it's it's not something that everybody is necessarily familiar with and I'd like to make sure that before we start moving projects over to Garrett to you know sort of enforce some of the review criteria and so forth that people are prepared for that and it's not going to be too disruptive and no so I think you know I think there's been some really great progress and now that it's actually up and running I expect that we'll start to accelerate that process and we'll start to be able to get differentiating pipelines going where we can do more than just run one pipeline for instance where we can actually have a different serve independent pipelines one that does smoke test one that does the full test one that you know one that's building out and continues deploying to someplace we can have long-running tests running against that and so forth so all good and very pleased with the progress we've made this far people are more than welcome to engage just jump on the the CI pipeline channel in Slack and about it now the one thing that I did just want to note is I try to reach out to make to your team you know to Dan and others to say you know Jenkins is there and and I'd love to see the process of sort of migrate I know you guys said that you were using Jenkins internally previously to for Sawtooth Lake and I'd love to see that transitioned over and then Tamash I think for for the for the fabric API build out if there's something we can do to help transition and transfer I should say over the some of the build processes that you have into the Linux foundations Jenkins that would be super as well. Yeah this is Dan on the Sawtooth project we put a bunch of detail into the about our Jenkins process into a thread with the other folks on the CI stuff that's probably what I need to catch up on okay good thank you yeah excellent excellent okay that's all I had for the CI any other topics people need to bring up if not people can have 15 minutes back or so well thanks everyone um good call and uh we'll see you all in virtual space thanks cross thanks guys thank you everyone