 Just checking quickly, have Ben or Greg joined at this point? All right, so we do have 8 of 11, we are at Quorum. Chris, when you're ready, we can get things kicked off. Okay, welcome everybody. So we have the action item reviews, including a brief update from Dave on the white paper. That's actually more of a top-level thing. I think Dave wanted a few minutes to cover where they're going with that. Then we have the Aroha proposal to do a final review and take a vote. Pardon me, we had the presentation last week, and so people who had hopefully a week to think about it. We did not, I gather, any apologies for having to drop last week, but there was this hurricane, just minor detail on my end, and I had to go pick up my parents. So we have the Java chain code demo that I think we did not get to last week, and so we will have that. Arno wants to update on some edits, I think, to the code of conduct that people have highlighted, and then we had intended to have Vip and present his update on the HIP numbering scheme, but I think he's absent today. He had a conflict, so we'll push that, I think, to next week, and then we'll have the working update. Is there anything else that anybody would like to add to the agenda? Okay, let's get going. So December hack fest, Todd, where do we stand with that? Yes, so also just really quickly, Ben and Greg have also joined, so we have 10 of the 11 now. So we'll move quickly through this action item review. December hack fest, I think we're still looking at December 5th and 6th right before the member summit in New York. We have a couple potential offers of space, but nothing firm yet, so if anyone on the line has office space that they'd be willing to offer up December 5th and 6th in New York, definitely get in touch with me. And then we can start firming something up for the TSC to review. Any questions? This is Jared from B&Y, we can just do if you want to connect offline. I'm sorry, could you say that one more time? This is Jared from B&Y Mellon, we may be able to get you some office space if you want to connect offline. Great, I will connect with you after the call. Thank you. Thanks. Any other questions on December hack fest before we move on? All right, sounds good. The next item is the wiki migration. In the call last week, people felt comfortable to move forward with wiki.hyperledger.org. A lot of that information started to get migrated, which is fantastic. And so the plan was to leave that and to continue to build from there. The wiki that is currently on GitHub, we have restricted the editing access down substantially. So at this point, any future edits that you have in your work groups or in general, please do on wiki.hyperledger.org. And so we'll continue building that out. Any questions there before we move on? Cool. And then the last one, and I don't know if Brian's on, but so we did boot up the test instance for discourse. It's at discuss.hyperledger.org. And there were a few emails around this, kind of the reasoning behind that. So we currently are in an evaluation stage to use that as a platform. No firm decision has been made yet, but we want the technical community to go in, poke around, kick the tires and see what they think of it as a potential tool. So please head over to discuss.hyperledger.org and set up an account if you have not already. And over the next week, provide your feedback, the good and the bad on that either in discourse or on the mailing list. And just one quick question, someone had raised the question if they can use LFID to log in. Currently, it's not possible, but assuming we move forward with this as a platform that we'll use long term in the paid version, we can install a plug in to allow for that. Any questions? Go ahead, Chris. On the discourse, which is, it's really replacing the email, right? I mean, we obviously have a problem with Slack where we're hitting the 10,000 limit. We can't afford to pay for it. They won't give us a free license because we're 501.6. Yep. And so, but somebody asked, I think it was on the mailing list whether or not we're getting rid of Slack. And I think the answer to that is doesn't have to be the case. But the concern, of course, is that we're doing things and we're making decisions and we have things that we probably want to be documented. And so we should be using something a little bit more archivable, if you will, than Slack. Of course, Slack doesn't have threaded discussions either. And so I think the answer is we should probably keep Slack around for the back and forth of negotiating or just chatting about some tasks that people are doing or requesting and answers. But we're longer running technical discussions that need to be threaded where people want to be able to go back and see what was discussed and so forth. It's probably the case we want to use something like discourse rather than Slack for those kind of questions. The challenge I see, Chris, is that, so first of all, I fully agree that would be great. But the challenge I see is that it's going to require distance for people to move important kind of big conversations over to the mailing list. I'm not sure that this will do that. I don't think it's going to be kind of dynamic conversations about certain things where it's still at the same time. It is a path of least resistance in the way our community work right now. So I think we'll be slower to have the conversations move to the appropriate places that we don't do that. So I don't know what the answer is. A lot of background noise, and Greg, you were getting cut out a lot as a result. But I agree it's going to require a certain degree of discipline. I was thinking that there may be some things we can do to integrate discourse with Slack so that maybe at least we're flagging that conversations are going on there so that people are aware of it. I don't know what. I mean we should definitely sort of explore this. But the reality of it is we have almost 3,000 people in Slack right now. I think it's like 28 or 2900. And many of them are active. There's at least 100 or more people on any given day yacking away. And the sad reality is is that we only have about three or four days of history before it falls off the edge of the world. I found it awkward even though I was traveling and then I tried to catch up and I was like, oops, can't go back that far. This is Brian. So I definitely would love to see if discourse is an appealing alternative to email and potentially if I think an appealing alternative helps draw some of the conversations from Slack over to email. What I think we will also want to do is explore alternatives to Slack. IRC is not quite there. There's been suggestions of rocket chat. Let's check out. So let's get through the discourse test and let it find it's kind of splitting. And we'll see what moves there. And then we can take a look at rocket chat. This is Arno. If I may just add a couple of thoughts on this. My observation with the biggest issue with Slack right now is that although it's helpful for people to be able to get in touch live with somebody which I think is very worthwhile in some cases. What I'm seeing is we see patterns of new people who are trying to use fabric for instance and fail the same way again and again and ask the same question. But they don't even have the chance of looking for an archive to see if that question hasn't been answered before. So that's unfortunate and I think we would gain from having something that's archived and a bit structured so that people can say, hey, has anybody faced that situation? Oh yeah, here it is. Yeah, that is definitely a case. Although again I keep reminding people if you see the same question over and over again, put it on stack, overflow and answer yourself. But yeah. And actually, you know, I actually don't, I mean the stack exchange, is there a free version of that or is that only a paid tool? Which tool? Stack exchange. We use that on other projects and it is not as great as it seems. People really like to build their rep on the main network of sites so we just didn't get the traction. It may be different for this community but in my experience it's a little island that gets ignored. Well there is, there are hyper ledger tags on stack overflow and you know, we should use them. Anyway, okay, so I think we've beaten that one to death. But you know, again if people have good ideas and are familiar with other tools that we haven't tried and would like to suggest please do feel free to do so. Probably the best way to do that is to send a note to the mailing list to the TSC mailing list and then we'll give it a try. Okay. Or that. Yes. Okay, so next up is Dave. Dave wanted a few minutes to talk about the feedback that we've gotten on the white paper. Dave. Chris, yeah I'll try to keep this short but yeah it's been a couple of weeks now since we had our white paper walk through. And of course you know that was some really, really good feedback from the community which is exactly what we're looking for. And you know I just want to give everyone an update you know what's been going on since then. And you know we've been holding a couple of working group meetings since then. And you know we talked through you know do we call the white paper, do we not call it a white paper? You know we obviously need to have an introduction section that sets the expectations of what's in here. You know we definitely heard the message that you know we're now the reality is and the direction we're heading here is that the Hyperledger project is this migration towards this umbrella organization for different blockchains. And so that should be incorporated into the white paper. And you know and we had kind of going back and forth you know some really good questions around that and how we should best look at that. And I mean you know some of the things that we really wanted to do is you know make sure that we have a clear view of what the purpose and the objectives of the white paper should be. And you know we discussed a couple of them you know should we be really looking to capture the concepts of the umbrella organization and clarify what it means. You know what's our vision, should we include a vision of where we see the Hyperledger project in one, two, four years from now. And you know making sure that we have a very clear set of objectives around what we want the white paper to cover. And you know to that end we are looking for a little bit more feedback especially around the umbrella organization concept. And you know one of the big questions there is you know like how do we reconcile the new umbrella organization vision to the original objective that formed the Hyperledger project to begin with. You know where we were looking to establish standards so that distributed application developers can develop their apps to the broadest customer use, customer base. And you know are we trying to prevent fragmentation or are we embracing it. Now we have some we don't think that we're embracing fragmentation but you know these are the I think these are some of the questions that people may have in their mind when they're thinking umbrella. You know we're going to have this blockchain stack and that one and this one and that one. And what does it mean and you know are we actually you know it's our four year vision that we will continue to see this or do we see them consolidating. And maybe they're consolidating around specific industries and use cases but we're going to see two or three. So you know there's some real fundamental points and important information that we think should be captured in here. So you know and a lot of you know what I'm just describing here you know it's in our working group meeting minutes so I encourage anyone to go on and take a look see what we've drawn up there. And you know so our strategy to get more feedback particularly around you know the vision and the concepts around the umbrella organization. You know we've invited and you know Brian Bellendorf he's agreed to attend our next working group meeting. Richard Gendel Brown again you know great thought leaders in this space he's agreed to attend our next working group meeting as well so we can talk through some of this. And you know we'd like to open up this meeting to more people as well to get their input and feedback because this is you know very very important existential type of questions that that we want to make sure that we're being that we're addressing. And you know so after we have a couple of these sessions with our thought leaders in the space then you know we're going to come up with a short list hopefully three or four. You know I gave a couple of samples that we've discussed about what the objectives are make sure that everyone you know agrees these are the things that we want to cover in the paper. Possibly even have a vote on it so that we have TSE members to say okay yes we want to we want to clarify the vision of umbrella and we want to include you know this future vision of where we see things in different timeframes in the future. And then and then once once it's clear that everyone agrees that these are the topics that need to be covered. Then we'll you know we'll do what we need to do best whether it's renaming the white paper you know ripping out the architecture section if it appears to be too closely aligned to you know one implementation under incubation or the other. So yeah so that's just a quick dump I just want to let people know you know we've kind of gone silent for a little while I want to make sure everyone understands we are thinking through this. We think that we have a great opportunity to add a lot of clarity to this shift from the original sort of vision was and when we first launched the Hyperledger project where you know we heard that you know we would be coming up to this difficult stage where some groups may want to stick and some may leave because we're heading down this one direction and not you know adopting something else. Now that's shifted now so let's we think we can add a lot of clarity get that view captured into a paper of some sort and that's our plan going forward. So what we'll be doing next is again we've got this meeting schedule we're going to have Brian and Richard participate as well. We'll be put out on Slack or through the email additional information so others can join in much like we did with the white paper and get that feedback so that we can agree on a set of objectives and move the paper forward. And that's my message. Dave when is the next meeting? So our working group meetings are every Wednesday 1pm New York time and yeah so that's when the next meeting is going to be held. Okay that's wonderful that's 1pm or 1am should I know. Yeah I know Brian's going to be in Singapore as well but you know he's a busy guy but he recognized this important, I'm not sure if Brian. Yeah that's stuff. Yeah just if you wouldn't mind sending the gals to the list. Yeah I don't know if you know Hart or Mick or Morrell or Ram or anyone if you guys have anything else you wanted to add I might have missed. I think that was great Dave thanks for bringing that up. Yeah I guess we're looking for feedback on what should the focus of the white paper be so we'd love to hear what lots of people in this meeting think and have to say. And Dave I see that version 2 is up. Does this incorporate all the latest feedback or is there a newer version? No it does not. So this is the version 2.0 draft is the pre-walkthrough version and again yeah before we ripped out the architecture section or added in this new section we really wanted to make sure that we understood so what you see there right now is the pre-walkthrough. I want to say something a little stronger than Hart's comments. Hart and David are being tactful and saying we want feedback on this. I think one of the things we want is a commitment from the TSC that this is a set of objectives for the white paper. I'll express that we're six months in and not really quite sure, more than six months in now, and still not quite sure what the intent was of the white paper and that seems like a problem so getting a commitment to what we need to deliver seems like the most important thing. This is Jared. So first off can someone send me a PDF of this because I can't access any blocks for work. Hey Jared I'll send you a copy. Which is why I haven't given so many comments so far. I do think that we know what happens. There is this architecture section you're talking about. I can understand why that might become a touchy subject but if the decision is to kind of move it out of front and center and have more of an overview, kind of hyperledger as a vision where everything is going to everything I do think it's still worthwhile to have kind of an appendix with the architecture details and it could be of multiple different architectures and that's kind of a point of contention. But I do think it's useful for people to be able to get kind of a flavor of what the different projects are and how they're built up. So that's kind of my only feedback with very limited knowledge. Yeah that's good Jared. In fact that was definitely one of the takeaways. People would like to see a white paper for each of the blockchain stacks under incubation and this paper could reference those for details on those. Yeah that sounds great. I think part of what will come out of this, I think, there will be some kind of weirdest type of ledger go. You mentioned things like do we start combining those? Do we want to have less kind of a less special landscape? I do think it will be helpful to start seeing kind of how things are built up and where one might be better than another. Although I do suspect that kind of over time eventually a bunch of projects will just kind of stagnate and die and it will be left with one or two that have the greatest community. Okay great. Alright well thanks I know we want to get on to the HIPP Aurora and so yeah again we'll just put out some emails and Slack and hope to see members joining in. Thanks. Just a quick question. Where is the white paper draft or what did you publish an update to it? I wasn't quite sure I thought. So right now everything is still on the old wiki. Actually Mick I think started migrating some of our meeting notes but the link to the Google doc is in the old wiki so if you just go to the white paper working group you'll see all that. It's also in the new wiki. And then where would you prefer comments before next week's meeting on the document? Do you prefer it as comments or notes in the wiki? Do you prefer it on one of the mailing lists? Do you prefer it on a particular Slack channel? Go ahead. Dave what I was going to say is Brian the first thing we need to do is to establish what the set of objectives are. So I think what we're looking for you is not comments on the document. The comments and the feedback that we got a couple of weeks ago was we thought we were going to fix this sentence, modify this section kind of things. And the feedback that came back to us was wait should we cover the broad objectives of the organization? Should there even be an architecture section? So I think what we need from you in the short term is what do we want people to take away from this paper, from the white paper? And that's the feedback we have to establish before we start talking about the actual document itself. Yeah I'm going to agree with Mick here. We really just, we need to figure. Okay got it. Who are the intended audience? What is the primary purpose? What are the secondary purpose for the document? We need to make sure we're all aligned with what the primary and secondary purpose is of this white paper and what the message that we want to convey to the primary audience. We need to have clarity at that level because I think we need alignment at the very highest level of what we want to achieve with this. Right. So say here, I agree. I think, you know, it would be worthwhile I think to at least start a discussion. I was going to say discuss it out on the discuss, you know, that hyperledger, but I would be afraid that we would lose that. So the question I was going to actually ask, Rai and Todd, is if we take stuff to discuss now, to discourse now, are we going to lose that or can we migrate it to whatever the page? I wouldn't presume that we wouldn't lose it. So I would be cautious about doing something there that we really don't want locked just yet. Just like on the Wiki, we want to make sure we have the freedom to be able to wipe it if we move it. Yes. Yeah, thanks, Brian. So I would just suggest we start a discussion in the mailing list then. I mean, I think it's worthwhile to at least start having people get their thoughts out on paper and going a little bit back and forth about the merits and demerits of whatever we're thinking so that when we do have the meeting on Wednesday, we're more sort of cleanup rather than, you know, just getting and starting to air the different positions because I just don't see if we're only starting to have the conversation in the call on Wednesday, then I don't think we're going to get necessarily to anything. Right. And would we prefer to have that conversation on the TSP mailing list or the technical discuss or on discuss? Pick one. Let's do it on the TSP. Okay. I think this has been kind of the TSP topic for the last few days or the last few weeks. And yeah, I think we'll have the highest quality conversation there. So I will write up exactly what people asked for here. I'll try to push that out long before next week's meeting. Not sure I can get this down today, but I know that having several days to have some conversation on this ahead of that meeting would be highly productive. So I'll do that. Great. Thanks, Farron. Hey, Chris. This is Morali. I think just extending what Ram was saying, other than the Wednesday's meeting, it'll be good maybe in the members' meeting. You know, if they come up with a vision, maybe that's the other opportunity where the vision is aligned right from the top. From the members' meeting? Or maybe I've missed. We have a members' meeting in December, right? Or bring it up to the board and have it aligned from a board perspective too? Yeah, yeah. Okay, sorry. I definitely think it's something we can add to the agenda items there when we talk to folks about, especially because the question will come up, how does the umbrella vision reconcile with the means to drive to a common standard and a common vision and a stable platform to build on top of? Totally. I will say that I did get the board, the governing board's consent and input on the umbrella document before publishing it. And so I think we can consider, you know, many of the concepts in that paper to be solid enough. So the question is really, you know, about implementing it and what's the way. And I certainly want to keep them informed, but I feel like we've got that high-level sign-off. And let's make it a topic of conversation for the members' meeting. Okay. All right. I think we've beaten that horse to death. Next up, Takim Hasan Roja. So we had the review of the proposal and then I had to drop, so we couldn't take a vote. Hopefully people who had a chance to think about what was presented last week and are, I don't know if we need to have a refresher. I know she and I think you went on. Maybe Takim Hasan, if you could just sort of do just a very brief synopsis and then we can probably proceed to a vote. Yeah, sounds, I can do a quick overview. How do I share my screen or does Todd have to give me the rights for this? Yep, one moment. Okay. Okay, great. It's working, right? Everyone can see my screen now. So I'll just do a quick, I don't know, five-minute overview of the proposal. So this is a proposal for a C++-based blockchain platform and also related libraries for iOS, Android, and Web. It's a co-sponsor project from my company, Solimitsu. Also co-sponsored by Chou-san from Hitachi and Inaba-san from Entity Data and also Mark, the CEO of Kodi, who are also members. Hitachi is also a premier member and Inaba-san, I don't think he's online, but he's also a technical student for me. So this is a modern C++ project. We try to use C++-14 and for cryptography we use Twisted Everett's Curve and Chou-3, which is a slightly better performance than Chou-256. We also have a new consensus algorithm called Sumeragi and we tend to use Chou-based smart contracts. Another feature is instead of having everything defined in smart contracts or in chain code, we also have some standard transaction types to make common use cases simple. And we have been working on a draft of a classification which is on GitHub and if you have time, I was just looking over it some. Different transaction types are explained and there's some details about the consensus algorithm. There's some resources here. So this is a way to bring in C++ developers in the literature until now there hasn't been any C++-based project. So we have been focusing on user interface development and application design. So we have libraries for iOS, Android, and JavaScript. We're also working with several use case partners here in Japan. So some buildings, they're one of the three largest insurance companies, casual insurance companies in Japan. There's quite this article about a project two weeks ago or last week or so. And they have about 10 or over 10 people working on a project using Iroha studying insurance use cases. And we also have a research project with the University of Tokyo, University of Aizu, and International University of Japan to do study local currencies and economic effects without that's using Iroha as well. There are about 15 people, these different companies working with us both on development and also on studying use cases. And there's going to be the first large field test with Iroha in November. And we currently also have live system development underway but that will be later next year. So the point is this is my company working on this but it's also multi-party effort. It's just Japan but we also have Koldu in Israeli company working with us as well. So why accept this now? Why not next year or two years? The reason is Hyperledger as a project is still young and so it's our opinion that this is a good time to bring in many new ideas but it hasn't yet solidified. So in the future maybe in two, three years I expect the project Hyperledger as a project to be more solid and have less fragmentation. But at the beginning there should be lots of ideas coming in and that's really what the incubation stage is about. Once project reaches maturity you can graduate to active and then I think eventually the long-term goal really will not be to have many different fragmented projects in Hyperledger but rather just to have kind of a set of components that have been well tested and can interoperate with each other. And that's the type of thing we want to work towards. The vision we want to help create and one of the ways we can do that is by taking our mobile app and web libraries and expanding them, not just to work with Irohap but also with Fabrik and Saadjit Lake as well. So that's the very simple rundown of the project. There's lots of details written in the proposal and then also in the very, very rough draft of kind of a white paper specification that I'm working on. So that's I think all I'll talk for now. So are there any questions? Someone's got quite a bit of background noise if you could mute that would be helpful. This is my kind of a couple of questions on it. I guess the first thing is it looks like a great piece of code. And just looking through the repository a little bit looks pretty great. But one of the things, you talked a couple of times about kind of modularity and it looks like the APIs are pretty clean between things but there's an awful lot of functional dependence between them. Do you see the pieces that you're building as something that could be pulled out independently from Irohan and reused or how do you see what's your objective for the modularity you've talked about? Thanks for the question. So the current draft of Irohan is very, very rough and what we want to do is make everything less dependent on each other. So using things like C++ templating more. In the future I think if we need to interoperate at a higher level we can use things here at PC but that's a little bit, we kind of don't want to do that. You can also inter-process communication in other ways in C++ but I think for now we want to try to encapsulate things more with templates. So there's lots of things to be done with that at the current stage. Any other questions? Again kind of a question about maturity level. To what extent has the current code base been tested and how would you describe its maturity? The current code base is still very rough. It's been tested somewhat with some of the use case partners here in Japan and from that we've gotten feedback and are expanding things more. But yeah it's still a very rough project. But I think that's also an advantage because bringing it into an incubation stage at this level can help be able to guide the development in a better way and also maybe use some better development practices if you can get some suggestions on that. So it's still very rough and I would say immature project. Definitely not at the active stage but for incubation I think it makes sense to try to make some of the good ideas here help them reach the full potential. Hey this is Hart here. So I really like your vision of sort of the modular components. I just had a quick question. At what point in the project do you expect to sort of achieve that modularity? Is that something you're going to sort of shoot for early on or are you going to try to have a complete ledger first and then focus on modularity? Well we're obviously focusing on having a feature complete version done first. But being said at the API level we already are looking at some ways to bring things together. So we've been talking to people at IBM here in Japan and one of the things we want to try to do is create a cross-chain transactions between Inoha and Fabric at a really early stage. And we could do that with Sawtooth Lake as well. I mean I don't know anyone from Intel here in Japan but if anyone wants to introduce me that's fine. No, it'd be Mick and Dan. Yeah we can certainly point you to a contact at the right time. We've got offices in a few places including Tokyo. Yeah that would be great. Actually I've never met Intel employees here in Japan. So I'm sure there's people somewhere. But yeah you can introduce me later. Any other questions? Okay. I think we're ready for a vote. So Todd do you want to call a question? Yep, sure thanks. So we'll walk through the list right now. Yes I would like to add a comment if I may at the same time. You were just for C++ I think the argument is a bit moot. Not that I discard the fact that there is a large C++ developer community out there and that might help bringing them in. I wouldn't want us to go down the route of well now we need to have a framework for every single programming language out there to attract as many people as we can. But I think the project has many other aspects that make it interesting to bring in. Yes. Ben? Are you still there? Sorry I was on mute. I would vote yes. Alright great. Chris? Dan? Yes. Part? Yes. Mick? Yes. Morali? Yes. Shihan? Yes. And Tamash? Tamash you may be on mute. Alright it looks like I got Tamash type yes into the chat window. Great. That passes unanimously then. Okey doke. Great. Thank you. Thanks. We'll work hard and continue to try to make as much progress as we can discuss as possible. Super. So if you want to just sort of ping on the CI, what is it, the channel, CI something or other, and ask Rai and we can get you hooked up with Garrett and so forth. Okey doke. Thanks. Next up is the Java demo, Java Chain Code. Okay everyone. Go through it now. The Java Chain Code is merged into Fabric now. So it's pretty much there to a level where people can start experimenting with that developing Chain Code on Java. So we'll go through what are the tools required for you to start developing Java Chain Code. And it runs on JD 1.8 and you will need a build tool, either Gradle or Maven as a product for Chain Code development and Fabric here. And you need the Chain Client that is currently built inside Fabric and published to the local Maven repository. And now in the future you will be using, starting using the Fabric Java SDK, that is a work in progress and that will be eventually published to the Maven Central repository. And if you look at the features that are currently supported, these are pretty much where you get for them, the range for it in cable and Chain Code with Chain Code invocations. TLS is currently being reviewed on Garrett and ACL is a work in progress. And setting events from Java Chain Code is not anything similar to what it will be. If you want to start developing Java Chain Code, these are the steps you would follow. You can use any of the examples, a bunch of examples published inside the Fabric repository, that features, that it demonstrates one feature each and you will start copying that project and then extend the Chain Code base class and then implement these three methods. And modify the build tool to call your main class. And we will go to a demo. I will provide a set of basic things, basically a copy, one of the examples, an interest of time and then created a folder and imported my IDE. And I will create a new class and call it Asset Transfer. We will go through a simple Asset Transfer demo, debiting on account and then creating another account. So this will extend the Chain Code base class. And you would need to implement these three methods and basically have a switch case function to run the incoming function and have this and in this method. He stood the point of view, he is bringing it. Let's understand it and then we should go with our conviction this way or that way. Sorry, yeah, I will continue now. And this is a transfer method. When a transaction comes with transfer and this is the code flow that is going to happen, it is going to get the balances of the corresponding account and then debit from one account and then credit to another account. And the query method will return the balance of a particular account, so in this case. So whatever account comes in, it will return the balance from it and get the chain code ID. It's a name that is given for registering and the depth mode. And it will limit the main method to start and listen for events after registering with the peer. So this is pretty much what you have to do to a basic example and you would need to modify the main entry point. Let's start there in the depth mode. I'm going to run it on the depth mode. In a production mode, when you deploy it, it's going to bring up the stocker instance and then run the chain code inside of it. But here it will run the chain code and then see if it gets registered to the peer. What is this now doing is compiling the project and then going to run it. And when it runs, the chain code will talk to the peer and then get it first registered and then gets into the innist mode once we issue a innist transaction. Meanwhile, I will open another terminal and then be ready to make a typo. Yes, better for that. Good. And I will open another terminal now. And basically we will initialize two accounts. Alice and Bob with 100 units of asset and another account with 200 units. See if it gets registered. Looks like it is ready now. And it is registered with the peer. Now we can start calling this. And it is being initialized with 100 and 200. We will do a query and see if it gets the set result. And we will invoke a transaction. This will transfer 20 units from Alice to Bob. And we will query the account of the other end. And it reflects the new balances now. And Bob got the 20 units per transfer. So this ends the demo. Get back into the presentation. Yeah, I have a question now. So this transfer asset, asset transfer process. So is it communicating to a public ledger or is it sub? It is communicating with the local node. And here I have it running locally on my machine. So it communicates to that. That answers your question. Okay. That's fine. Thank you. It's Vikas here from CLS. I just have a question. This Java chain code, is it based on the new version of the fabric, the version 1.0 or it's still on the old model? It is on the old model. It is not based on the new 1.0 architecture. But from the chain code perspective, the new architecture has a lot of changes on how a transaction is being invoked and how a transaction is being recorded to the ledger. But from the chain code side, there won't be a lot of changes. But it currently works on the free 1.0 architecture. And you said, is it checked in for folks to download and use it? It is currently merged into the master for fabric. So it is available in the 0.6 branch and also in the master. Okay. So this is Greg. I had one question and two comments. So one question is, I was curious about the TLS reference there, but let's come back to that in a minute. My two comments, one was that as a side note, and for reasons I don't fully understand the issues, but note that we've been having some problems with the choice of Gradle on some of the architecture supports on the non-X86 platforms. I guess it's limited support on other things, which actually doesn't make a whole lot of sense to me considering its Java, but apparently there's issues with non-X86. So that's one comment we might need to rework that. I don't know if this is an alternate strategy or some other way to do it. The other comment was that I would love to work with the team that's working on this on getting support in ChainTool for the CCI schema definitions to support Java. If there's any interest in that, please reach out to me. And lastly, to revisit that TLS thing, could you explain what you meant when you were mentioning that TLS is still a work in progress? I'm just not clear on where that even ties in. Why does the ChainCo platform need to care about TLS? Well, when ChainCo runs in a different environment, basically from a doctor, it needs to talk to peer, and that communication has to happen over TLS. TLS is required. Okay, I got you. Now I know what you're saying. Yeah, I understand that. Thank you. About the Gradle, not being supported on the platforms other than X86, the reason we are having difficulty is Gradle and Maven uses another port detector plug-in to figure out some of the things to run it on a native, be it protocol or in case of TLS, it is going to need the boring static SSL. So this is something we need to figure out how to achieve on the platform like PPP and other stuff. But with respect to Protobuf, we will be able to move away from the Protoc compiler to generate the Java classes soon. So that's something we've got going. Right, so if we were to integrate the tool, part of the work would be helping me to define basically the code emitter that can spit out the Java language implementation of the interface, which should be relatively straightforward. The other aspect would be we could possibly, some of the Protobuf compilation stuff that you're talking about could be integrated into that process. So it might make your life easier in a couple different regards. We just have to come up with that initial, basically the code emitter. Exactly. We can take that offline, though. No, this is good stuff. So thanks again to DTCC and Fujitsu for doing this work. This is good stuff. So we're at end of job, and obviously we aren't going to get to the workgroup updates, but if the workgroup leads would each sort of post to the TSC mailing list, they're current update. I would be much appreciated and be comfortable with everybody. And we'll talk to you all next week from China. Thank you all. Thanks, Chris.