 So you don't have to vote on anything. All right, you're going to flip the page? Yeah. Thanks. So good morning, everybody. Good afternoon, good evening. Wherever you happen to be, we've got a fairly light agenda this week. So maybe we can get it done quickly. And then, of course, we have the hack fest next week in LA. So be sure to get your last minute changes to the agenda listed. We will cancel the TSC meeting on Thursday because I think people will be traveling. And so we'll be back at it in two weeks. I don't know, Todd, is there anything else from a hack fest planning perspective that you need to remind people of? Yeah, I think the only things are for the day zero training, if there are any folks from Borough, Roja, or Quilt that'll be there that can do quick reviews on that and then help folks set up their dev environments in the afternoon, please let us know. Otherwise, we've got a lot of topics slotted in there. Any other things that people would like to see, please get that dropped into the Google Doc. And we're going to form up the agenda a little bit more in advance than we have in the past. That's one of the requests we've heard from folks. Otherwise, everything's moving as is. And we have a lot of people registered for this. So we're excited. Excellent. Excellent. And how about the internship program? Again, that was very successful last year. So looking for another. Let me just drop the link in there into the rocket chat. I think the big thing on the internship program is call from mentors is open right now. That will close Friday of next week. So we will continue to remind everyone, if you're interested in mentoring an intern, please get that submitted ASAP. Last year, we had twice the number of people requested to be mentors than we had funding for. So we've expanded the program this year, but please get your interests submitted there. Excellent. So I am just looking for the link on the work group updates to your charter template. So for the work group updates, I think, and Tracy, maybe you want to chime in, but I think that was all approved to move forward. Yes, I'm just looking for the link because that has the schedule. And I don't see it in the Wiki. So I know it's in the Wiki. I just say it's not in the main page. The schedule has not been updated yet. We're still waiting on the IT folks here at the Linux Foundation to make sure that the template is in place for any new files or Wiki pages, I guess, that are being created. So once that gets done, then I'll reach out to Ram and make sure that he has a couple weeks to set that up. And then we'll get those rolling on the schedule. OK, excellent. Thank you. All right. So then we're up to Composer Update. So who's doing that? Is that Simon or Caroline? Simon's here. Hi, Simon. Shall I share my screen? Go through the document. You can do that. And I think it'd be good if somebody would paste the link into Rocket Chat if they haven't already done that. The trouble with doing Rocket Chat and go to meeting is finding the different pages. Because go to meeting is such a... On that note, we're going to be moving over to Zoom, starting for the next meeting. So that should overhaul some issues. But that one stinks, too, because it just takes us. All these tools, they want to take over your entire screen. So if you use multiple screens and stuff, it doesn't work because it just keeps following you around. And you can't toggle between different tools. It's annoying. Zoom is better than go to meeting, but that's for sure. OK, Simon, you're up. All right, right. So Project Health First, we've been continuing to deliver weekly releases of Composer. And those releases include new features and bug fixes. We pushed a new one out about an hour or so ago as well. So we're definitely keeping releases up to date and giving new functionality to end users on a regular basis, which is really good. We're getting a lot of bugs raised in our GitHub repository. Hopefully not a sign of bad quality, but we are picking them up and turning them around quickly. So that's good to see. We're seeing a continued significant amount of interaction on rocket chat and Stack Overflow, with people posting questions and problems that they're hitting, and we're turning those around quickly as well. We've recently seen over the last three months, I think, quite a lot more people starting to contribute to the project, which has been really nice. Most of these are quite small contributions, like fixing typos or adding a few little bits of docs. But it's good to see more people coming along and starting to contribute. We don't have any issues to report to the TSE at this time. Again, we've been delivering weekly releases. If you want to go through our release notes and find out what's in each one, then you can just go to the GitHub page. All the releases are posted there over the last quarter. We see very little interactions on the mailing list. Most of the mailing lists tend to be me posting out the release information. There's a couple of questions on there, but very little. Most of it is on rocket chat and Stack Overflow, along with GitHub issues. Although sometimes GitHub issues really aren't suitable for the kind of questions being asked. Sometimes we'll get asked, how do I do this kind of thing on GitHub? And then we sort of try and push people over to Stack Overflow or Rocket Chat for asking questions instead. Because of the amount of questions we are getting on Rocket Chat and Stack Overflow, we have two team members within IBM, at least dedicated to answering the questions on Rocket Chat and Stack Overflow and keeping them going. That's Paul Mahoney and Rob Patcher, and they do a great job of quickly turning around all questions and dragging in various developers as needed to help out. But one of the other nice things we're starting to see is that when those guys aren't around to answer questions, the community are jumping in and answering questions as well. So there'll be community members helping each other out on Rocket Chat, which has been really nice to see. And that's also a recent new trend, which is good. And we're definitely good at commenting on GitHub issues as well in a timely manner. As I said, we've been pushing out regular releases. Some of the new big features that we pushed out recently are around business network cards. A business network card is something we introduced a while ago, which is sort of an easy way to pass around information about how to connect to a blockchain network and the credentials that you use for connecting to that blockchain network, so the digital certificates. And we started off doing that in the Playground, our web-based tool, and now we've finished it so you can use business network cards in all of the Composer tools, the command line and the APIs and the rest server. We've delivered support for Hyperledger Fabric 1.1 and thanks to the Fabric team for delivering that because it delivers us a really key feature, which is Node.js chain code support, which means for once we can run natively because Composer is completely JavaScript. Before, we were running it in a Go JavaScript interpreter called ducttake. It's pretty slow. It had a load of back-level language. It was missing a load of the new language features rather. And now we can run natively within Node.js. And this gives us support for the latest language features in Composer transaction processor functions, which has gone down pretty well with the community. It allows us to use cool things like async await, which makes the business logic that's being encoded into transaction processor functions much more easy to read and understand. Any questions so far before I continue? This is Ruben. I have two. One is, do you have any plans at all to support any other DLT other than Fabric? Because if I understand it correctly, when Composer was first brought on, that was touted as a possibility. Or is it pretty much narrowly focused on Fabric? So Composer has been designed from the start to be portable to other DLTs. And if other DLTs have JavaScript support, then it's definitely possible. I know I've spoken with the Sawtooth guys about that. They have the ability to write JavaScript smart contracts. So getting Composer running there would be a definite possibility. As for other DLTs, not sure. It depends on whether they support JavaScript or not. But as I said, Composer is designed to be completely open and portable to other DLTs. I don't think my team here are intending to do that work. But we're happy to work with other people to do that work and provide help and guidance and whatever docs we can give you. That's great. So that obviously means there's no plan to get this done. It has to be done if there is support from other members of the community. So the second question has to do with your JavaScript compatibility. You mentioned especially the async weight. So these kind of things, are you at all worried about any kind of stopping problem there? Or you're not because some of the other like Ethereum, for example, which have sort of JavaScript support, have gas which limits the runaway code. Are you guys thinking of having any kind of ways in which you can limit those kind of negative interactions? I'm not saying that that could be solely due to malicious code but also due to bugs. Yeah. No, it is something we're very interested in. Before with the previous JavaScript runtime we were using, we were very limited in what we can do because it was a non-standard JavaScript platform. It didn't have any way of plugging in additional functionality. And we sort of weren't too worried about looking at ways of fixing it because we knew where we wanted to go. We wanted to get to Node.js. Node.js has lots of either built-in capabilities or external third-party modules that allow you to do things like limit the time a function takes to execute so we could start looking at ways to solve those kind of problems, introducing time limits for transaction execution. But it's not something we look at yet. Thank you. Horace? Totally unrelated questions. You mentioned GitHub issues and I'm curious what your experience is like with GitHub issues and whether you're using JIRA and this would be in the context of, I think we had a discussion last week about JIRA and security issues and trying to get all the projects on to JIRA. So we all love GitHub issues. We'd really be opposed to moving to JIRA. It's a bit over-complicated, I think. And it's nice to have the code and the issues all in one place. That would be my opinion on it. I'd really rather stick with just GitHub. And I think that's sort of the familiar experience for most open source developers these days. OK, thanks for that feedback. OK, I'll carry on. So what are our current plans? We're starting to work towards a version of Composer that we would be happy as calling a 1.0. And this is mostly in part due to the fact we can now run natively in Node.js. Before with the weird JavaScript interpreter we were using, we were not very confident about people running in that in production. A, it was slow. B, it wasn't really widely supported. It had a very small contributor team. And it certainly didn't have the whole backing of the Node.js ecosystem. So we're much happier now we've got that. But there's a set of features that we're looking at working on now that will help us get there as well. I'll just go through these quickly. Today in transaction processor functions, there is no ability to access external modules. So one of the power of Node.js is the ability to go to MPM and grab any of the 500,000 modules that have been published there and pull them in and use them in your code. You can't do that in Composer today. You can do it in Fabric. And so we'd like to support that in Composer. And that's now made possible because we have the Node.js runtime environment. In order to, this next one is what we call native Fabric deployment. And this is because of the weird JavaScript runtime we had before, we sort of deployed Composer business networks in a very unusual way. We deployed a generic piece of Composer code that we build and everyone uses. And then we gave it the BNA, which gets stored on the blockchain. And this sort of doesn't really work with the Fabric governance model, where everyone is meant to install the smart contract. And then at that point, they can sort of approve it. And then everyone agrees to stand that smart contract up. So we're trying to fix that and actually deploy to Fabric in a way that Fabric would expect us to. We're looking at the generation. So Composer has some functionality for doing complex queries. In Composer, you can store assets and participants on the blockchain. When you store them in CouchDB, you can do complex queries. Someone's talking. All gone. So when you store them in CouchDB, you can do complex queries over those. However, those complex queries require that you create CouchDB indexes. Otherwise, the queries are quite slow. The indexes make them fast. Because we have the models in Composer that describe all of the data that gets stored in CouchDB, we can generate those indexes for you. So we're building some tools to both generate those indexes and automatically create them for you so you don't have to worry about that. And you just instantly get performance queries. We have an application generator that allows you to generate an Angular web application just by running Yeoman and answering some questions. I've sort of been beating up on it for the past year or so because it looks both pretty ugly and is pretty incomplete in terms of the features. It only shows you assets and all of the other parts of your Composer business network. And so we're going to finish it off and give it some good amount of design love as well to make the generated app look nice. On a similar note, we're looking at our vehicle lifecycle demo, which is the demo you will have seen me present if you see me present before. And we're not happy with it at the moment because it's quite complicated. He uses a very complicated model. It's quite hard for a new developer to take that demo and look at how it was built and understand it. So we're going to radically simplify it to provide a better experience to developers. We're looking at automatically generating documentation from Composer model files. So if you start describing assets and participants and transactions, wouldn't it be nice if you could use that information to generate some documentation you can give to a business person or a developer to understand what's in the model files and what the different properties mean? I mentioned before about business network cards. Currently, you can only store them on the file system of the system running Composer, whether that's using the APIs or the command line or any of the other Composer tools. We have this fancy sounding feature called Cloud Wallets, but what it really means is you can store your business network cards anywhere. We're introducing a plugin mechanism that will allow you to store your business network cards in S3 or Mongo database or just even a different file system directory than our default. So that'll be quite good. And that's something we've seen quite a lot from our users where they really struggle to maintain all of these different directories of business network cards across multiple systems. One of the pieces of feedback that a lot with Composer who are familiar with Fabric is that they have never been able to drop into the underlying Fabric APIs, which they need to do if we haven't wrapped some of that functionality in one of our higher levels of abstraction. So what we're doing is just exposing the underlying Fabric API to Composer transaction processor functions. And just to go back to Vipin's earlier question, we're doing that in a way where it doesn't introduce a dependency on Fabric again. It's done in a way where other DLTs could plug in their own underlying APIs and have them exposed to transaction processor functions. But use of that feature would make your Composer business networks non-portable. And finally, we had some experimental code go in last year that allowed a Composer transaction to call out to an external REST service. But it was pretty limited in that it only allowed you to do HTTP posts, which were great for the demo that was done, but not so great for all of the people trying to go to external data sources and do GETs and things. So we're gonna close that off by putting in a standard HTTP client instead. And then there's some other pieces that are not really massively important to end users but are important to us. So we're looking to work with the Hyperledger CI team to move our builds to Jenkins from Travis. And we're interested in doing this because it'll provide us a much wider range of platform support. One of the things we get asked for on a regular basis is window support. And until we do any kind of testing or CI on Windows, then we can't really claim support. So that'd be good to get done. We're doing some work around automated performance testing and generation of performance reports. And finally, we're working on a data collection tool that will allow the contributor team to ask end users to run a simple command and it'll package up all the logs and version information and things that make it easier to diagnose issues. For example, we're seeing a lot of, I'd say quite a lot of our issues that we see are due to misconfigured environments and it'd be good to just quickly gather that information so we can check and see, oh, you've got the wrong node version or you haven't installed this version of Composer or I don't know, you've got the wrong business network name somewhere. So that covers all the work we're currently looking at. Are there any questions on that? Okay, mainly in the diversity, we haven't added any new maintainers. There's me and Caroline in IBM and Dan in Clause and I've got the list of contributors there. A few new ones. I couldn't track down the unknowns to a particular company, whether they're individuals or acting on behalf of an organization that I can easily identify from their GitHub page, don't know. So that's sort of it. All right. Any more questions for Simon? Comments from the Peanut Gallery? If not, thank you, Simon. No worries. Looks like everybody gets about 34 minutes back unless there's any other agenda items. Dave, actually, I just, you weighed in. Where do we stand with the Jira consultant? I've been traveling so I'm still catching up. Dave, who's being? Are you on mute? Yes, I was in mute. Sorry, I'm here. What's up? I was just asking the Jira consultant update where things, because I've been traveling so I haven't been able to move. Oh, yeah, you know what? Honestly, so have I. This is my first day back this week. So I can, I'll email you as soon as I have an update, but yeah, that's first on my list for this morning, actually. Okay. I'm guessing that the statement of work will be approved. I think that's the next step is to just go over those details and then put it out for signing. Okay, thanks. Any other items? If not, we'll see many of you next week, hopefully, and have a good weekend. Cheers.