 first. Hello, hello, everyone. Welcome to the weekly TSC call. I think everybody knows that this is a public call. Everybody is welcome to join in, participate. However, there are requirements to doing so. The first of which is to be aware and live by the antitrust policy. The notice of which is currently displayed. And the other one is to live by the code of conduct, which is linked from the agenda. With that being done, we can move on with the agenda. Let's start with a few announcements. Jessica, do you want to do the Dev Weekly? Sure. So, Dev Weekly newsletter will go out this Friday. It goes out every Friday looking for any updates on projects or events, any new features. Please go in and make a comment if you want us to consider it. But it's a great way to get some more eyeballs on things going on in the technical community. So, please take a look and if you have anything to add, do so. Thank you, Jessica. All right. Otherwise, a quick update on the TSC election. We have now closed the nomination period. And the slate of candidates will be formally announced in the week. I do have one thing here. People who are running, I know that David has reached out to you. Please let us know your formal, the name you want on the ballot, please. So, I know David has reached out to all of you. Just please get back with that so we can finalize the ballot. Thank you. Do you guys know if we have a nomination statement on the weekie for all the candidates? There is one candidate who does not have one yet. Okay. Because I counted, there's like 25 of them. So, I wasn't sure. I didn't want to check on the email. I was lazy. I thought to you guys, we know. So, thank you. So, that means we will have, I guess, 26 candidates. It's a pretty good number. But there are 15 seats, so there is quite a bit of room. But it's good to see people, you know, eager to participate at that level. So, with that being said, let's move on. Then Arun as an announcement he would like to make. Sure. Thanks, Arun. Good morning and good evening. And I quickly wanted to bring up a topic on hackathon initiative that started as part of Hyperledger Social Impact Special, Special Interest Group. So, Hyperledger India chapter has been organizing hackathons for the last two years. In fact, earlier this year, around in March, we had second version. And we did invite all the six and different chapters to participate along with us to get involved in the hackathon. And this request that's the, if I'll make it short, the Hyperledger Social Sick. So, they still had a different perspective or different idea in terms of organizing and what kind of problem statements to solve. And that's getting renewed as of now. And when Nancy reached out asking, can we collaborate again for the next event? I guess the ideas that we are throwing around are, so you can go to the link that is tagged along with the initiative world. So, those are some of the ideas that we have. And one of the idea that interests TSC and probably the rest of the projects is. And it's around getting together as a team from across different communities within Hyperledger and then organizing an event, right? So, here is the invite to all the projects to share some problem statements that you think can be solved as part of hackathon and probably a continuous engagement post hackathon. It could be a smaller problem that we solve in a day or two, or probably it could be a bigger feature that we propose as a solution during the hackathon. And probably ask participants to engage with us on a longer run. So, this is an invite or probably a request to collaborate. And this request will also be sent out to different sick and working groups within Hyperledger. That's it. Thank you. All right. Thank you, Arun. Any questions? Any other announcements anybody would like to make? All right. If not, let's get going. So, quarterly reports. So, we have two reports that have actually been carried over from the week before. And these are Borough and Ursa. I don't know that there's anything new. I haven't seen anything on the pages indicating there was a need for discussion, but this is your chance. Also, so just before the call, I went back to the page that Grace snuck in the Bezu report. But thank you for adding the link and then submitting the report, obviously, Grace. I don't suppose many of you have had a chance to actually review it. So, just, I mean, we'll look at it again next week. But in the meantime, you can review it offline. Any questions or anything anybody wants to discuss on any of those reports? As I indicated in my email, we are missing quite a few. So, that's why, you know, I'm thankful for Grace to step in and do the Bezu one. It'd be good to get the other ones too. So, if you're involved or have any dealings with anybody in those projects, please feel free to ping them and ask them to go ahead and do that. All right? Okay, so then you may have seen the agenda. There is two main parts of the agenda today. The first one is kind of a presentation with a demo from the DCI working group. So, I don't know in which order you guys want to proceed. I think I can give an overview of the proposal and then Peter can jump in and do the demo. Does that sound all right? Sounds good to me. Go ahead. I will share my screen, I guess. So, this is linked in the agenda, but just in case, I'll share my screen here. So, there's a few of us who are part of the diversity, stability and inclusion working group. And we over the last six months, eight months have been working on inclusive naming proposal for Hyperledger to consider. We wanted to bring it here today because partially because the tool that Peter's built, you can talk about it, but it's ready for your review. But obviously, we think inclusive language is really important as a part of, you know, running a strong open source community such as Hyperledger. So, you can see, you know, you can read a lot of this on your own time. I'm not going to read it word for word, but we have kind of three or four recommendations. We wanted kind of bring to the TSC as, you know, ways that we can, you know, make small steps in inclusive language throughout the project. So, just wanted to share it here. I thought this would be a great opportunity. So, the first one, just recommendation one, is for all the projects to consider adding kind of a documentation style guide, inclusive language like disclaimer. So, we've linked here kind of what BASU has for maybe a template that each of the projects could consider. Basically, it's saying, you know, you know, whenever you're entering a documentation or starting to work on a project, it's setting that expectation of how, you know, we like to communicate and ways to be inclusive there. So, this one, for example, has, you know, considering that everyone is from different backgrounds, of course, in different cultures, avoid potentially offensive terms. So, for example, using a lawless and denialist, it's a whitelist and backlist. You know, talking about kind of how we write inclusive documentation as well. And then we also kind of provide a couple links in the BASU one for, you know, how Microsoft and Google also think about it. So, this is our first recommendation, you know, something small that we can kind of build upon in our documentation guides. The second one is around specific language updates, you know, in our conversations with the working group, we thought a lot about how are we, you know, should we or shouldn't we give exact specific examples and the feedback we kind of received from the group was actually it's really helpful to have specific so everyone can kind of just take it, you know, and copy and paste essentially in their projects rather than coming up with their own. So, we provided just, you know, only four examples here. A couple of them are already implemented in several different projects, but it would be great to see, you know, other projects implement them. For example, we have the four that we kind of identified that are, we think good fixes are, you know, switching master to main in the repo, slave to replicas, blacklist to denialist and whitelist to allow list. So, we wanted to, you know, make sure and then just to be clear, like the DCI link tool, which Peter will talk about in a minute, will help with all make this process a lot easier for the projects to do that and not have to rewrite things or the tool itself kind of helps manage that process for them. So, I'm going to skip number three because I'll Peter talk about it more. And then I know we've talked about the badging proposal. We haven't, I know we haven't quite made a decision on that just yet from the TSE perspective, but we did want to make the recommendation that if the TSE goes ahead with the project badging proposal or having something like that, then inclusive naming is one of the badges that's considered. And that can be so if a project meets recommendation one, recommendation two and recommendation three, then they get inclusive language badge. Any questions before I talk to or I hand it off to Peter? So, I think thank you for doing this. I mean, but so I want to make sure we all understand where we are from a process point of view and what's expected. So, this is the output from the DCI working group. And you're basically making a proposal to the TSE to adopt these recommendations. And so, okay, that's just sorry. Yep, that's what you're proposing. Thanks for clarifying. No, but it's good. But, you know, sometimes we use the main objective and it's better to spell it out. So that's why. And, you know, I don't expect us to this way. I realized this was what was intended. And so I didn't put it up for vote today. I think we can let people think about this. We'll go through the demo next, but we can make a decision next week. So, Tracy has her hand up. Yeah, I don't have any issues with the recommendations. I think I would like to understand how we implement this. So obviously the DCI link tool will implement kind of number two for us. But like, where are we supposed to add this to the guidelines under the tsc.hyperledger.org? Are we supposed to just communicate this out to the maintainers? I just want to make sure I understand kind of what the process is for ensuring that these recommendations are available and slash followed. Question and open to others ideas. One thing that I thought about but is, you know, similar to how the project updates have, you know, have those two questions, shoot, I can't remember which ones they are. We could have a third question that's, you know, have you implemented inclusive language guidelines and include that over the next several quarters? That could be a one-forcing function. But also, yeah, open to the staff's recommendations, too, because obviously they've done these type of things more than I have. I mean, I think this is an ongoing thing, right? I would want to just bring it up for six months in the reports and then let it go. Because I think this is something that needs to continue regardless. It needs to ensure that, you know, as new people come into the projects and into the community that they're thinking about inclusive naming is, you know, should be something that's forefront in everybody's mind as they go through and think through the what they're doing, right? Whether it's writing documentation or writing code or just, you know, participating in the community. Well, I think I like the idea of using the project reports as an opportunity to get this in. But there may be other opportunities, you know, like the code of conduct governs everything we do. And this is also an ongoing thing. We don't really, you know, how do we enforce it? Well, we have people on the lookout and there's a way to, you know, alert or raise an alarm if there's a problem. But maybe there's a combination of things like this where we can point to it in prominent places and, you know, we will have to think. Angelo, do you have an idea? Maybe? Or a question? No, a question. I don't know. I must admit, I was very curious. I guess this target mainly English. Is there in general, I'm not, I don't know, I'm really ignorant in this of these things I would like to understand. How does it work for other languages? I mean, if there is some, if a project has documentation in multiple languages, do, does the tool cover also other languages? Do we have recommendations also for other languages? How does it work? On the English, English is the only language that matters, actually. Maybe, yeah, you know, but that's also would be nothing. No, no, I'm just kidding. Obviously, that would not be very inclusive to start with, would it? This is an interesting question. Obviously, all the code and stuff, I think every project uses English as the primary language for documentation and all, but you're right that there are translations. I don't know what we should do. Maybe there is some room for addition there. I don't know. That's a good question. Any ideas from, I mean, Grace or Peter? The tool right now is English only because the recommended terminology is English only, but if the INI or the DCIVG comes up with, or pretty much anyone, if there's language recommendations in other languages that could also be plugged into the tool, I'm not 100% sure what the technological solution for that would be so that the languages don't cross each other. But the point is just to keep it short right now, it's English only, but I would be open to looking into other solutions as well. There's just these dependencies that we take care of first. For example, if we will support German or whatever other language, then the language recommendations have to be there first. And DCI is built on top of the language recommendations that come from the inclusive naming initiative, the INI. All right. So Peter, since you're talking and I don't see anybody raising their hands anymore, why don't you go ahead and give us the demo and then we can talk some more. Okay. Can you see my screen? Yes. Okay. So this is the DCI repository. This is the software. I plan on ending more documentation on here for now. It's documentation-wise is limited, but there is a GitHub action that encompasses this software so that it is as convenient as possible to add it to any hyper-legal project or pretty much any GitHub project that you would like to add it to. And the way to do that is to send a similar pull request that compared to the one that I added on cactus. And basically copy-paste this to have the recommended defaults. And this was an important part of the extra work that made it take much, much longer than I initially thought, which is that you can verbatim copy-paste this code snippet, put it into a workflow file in your GitHub repository. If you've used these YAML files before, then you already know exactly what's happening here. But I will say a couple of sentences basically. You're telling it to use the GitHub action that I published. You're telling it to clone your pull request, which is dynamically configured through environment variables. So that it clones it, that it fetches the specific git reference that you want to check for within the pull request. And then it loads the configuration for the phrases or the language recommendations directly from the INIs website. So you don't have to come up with your own language recommendations either, either, and you also don't have to put those language recommendations in here manually yourself. It is all powered by this JSON document that is just a machine-readable version of the official recommendations of the INI and also the Hyperledger DCI work group. And so once you add this code snippet, then send the pull request to your own project repository, then you end up with this extra step in your continuous integration workflow, where the check runs next to other checks that you might have, like the build or tests. And then it either fails or it succeeds. If there were no linter errors, then obviously it succeeds. If there were, then you get all the stuff files like I just got them here in Cactus. You see which phrase triggered and which file and then you can either go and fix it if it's in your code or if it's in a dependency, then what you can do is say you can create a file called .dciignore, which is 100% equivalent syntax-wise to the .gidignore file. So it's also that way just so that it feels very, very familiar and it doesn't require learning anything extra if you had used a .gidignore file before, which I expect most people have done. And so then you can add entries like this and that will make some of the errors disappear. And obviously it's up to the project maintainers to supervise whether the things that are being ignored are dependencies or in actually the code. The tool itself is not police, that it just follows blindly what you're telling it to ignore. And then finally, if you go back here, if you look at your own pull request, then this is how it looks, you get an entry and then yes, right now it's failing, but that's the point. And this is it, basically you just add that code snippet one-on-one like I showed that I've also published as actual documentation. And then you can enable in the settings of your repository in the branch access, oops, yeah. So in the manage access for like my, my branches, yes, sorry, I just want to make sure I show the branch protection rules. So if you come here and then you say DCI lint, then you can add this to the list. And from this point on, no pull request will be mergeable unless the DCI lint check is also passing on top of the other checks in your list of desired continuous integration passes or checks. And I'm going to turn this off for now because I still have some work to do to actually fix it on cactus, but this is generally the flow to introduce it to your project. And then once it's introduced, it will be just there automatically for all the pull requests that you receive going forward. That's it. Thank you for listening. Well, thank you, Peter, for working us through this. Is there any questions or reactions, comments? All right, well, if not, I mean, is there anything else you wanted to add to grace or Peter on the proposal? No, I don't think so. If there's no, you know, feedback, at least on the recommendations, what we can do is go back and come up with a process proposal. So if it's a part of the project updates of code of conduct, we can work with the team. And that way you can be a little, I think that's the only open question from the group at this point. So we can do that. Yep. Sounds good. Sounds right. Thank you. All right. Thanks to both of you. And so everybody can think about it, obviously, in the coming weeks and before they come back. If you think of anything else, feel free to raise it. All right. So let's move on then to the next agenda item. We received a new request from the Firefly people. As I'm sure you all remember, they requested to create a project in incubation back in June. The project was not approved, but so they created a lab and they've been existing as a lab and being making quite a bit of progress as an open source project. And so they feel that now they are fulfilling the requirements that they expect us to have them live by to qualify as a project in incubation. So they're coming back and I think Nico is here with some slides to give us an update. And then we can discuss how people feel about the request. I asked you to say the decision officially back in June was we were postponing the, you know, considering moving them, accepting the request by two months. So the two months are actually passed. And so we're in time with regard to our previous decision. Thank you. I appreciate the context on there. And I think you summarized it well. I was going to lead in with that, but I think you summarized it really well. Can you all see my screen? Yes. Okay, great. So yeah, there's been some exciting things going on since June, kind of both in building the open source community around Firefly and also just in the project itself and some of the milestones that we've hit. And so that's kind of what I want to walk you through today. I will try to move through this quickly. I'll try to be sensitive of time to leave some room for discussion. And if everyone is favorable, hopefully a vote at the end, but we'll see. So I first want to talk about progress toward what the Firefly team views as a V1.0 release. So we've been working on a lot of stuff. We launched in June with on chain off chain support with Ethereum support. Since then we've added support for fabric as well. We're working on token support right now, as well as a unified API for custom on chain logic, whether that's with the token or whether that's with a purely custom smart contract. So we checked a lot of the major boxes of the major pieces of functionality that we would like to see in Firefly before we're ready to declare. This is a 1.0 release and it has the features that we want. And we've tested it thoroughly and it is ready to declare 1.0. So the next major thing is production hardening, putting it through lots of different testing, scaling, and that sort of thing. So that's kind of, this is just a brief snapshot of a high level of a roadmap. There is an issue on GitHub that tracks this at a much more granular level. You can go check out that issue if you're interested in seeing what the other things are that we're looking at there. So kind of zooming in on an important piece of this, I wanted to just briefly touch on sort of the road to custom on chain logic. Early on, there was an impression that Firefly, well, it has a smart contract that has one line in it. Well, so it's not really using blockchain for a whole lot. It's just using it as a timestamp service. And this is not true. And so I just kind of wanted to highlight this a little bit. The pieces that we have been building are sort of the stepping stones to completely custom on chain logic. And so there's two main ways that people can use custom smart contracts with Firefly. If you just want a token and you want to transfer and mint and burn tokens and work with digital assets that way, there's a really simple API that we've been working on that allows that and you can plug in your own custom token contract or something off the shelf, you know, ERC 1155 or 721 and just plug that right in and use it. That's in progress today. Right now through, so we originally launched with Ethereum and with ETHConnect and we've added FabConnect. You can go use either of those directly through their APIs and run your own custom smart contracts. The last piece to this after tokens is building a unified API that can talk to either ETHConnect or FabConnect through Firefly to provide a consistent API to be able to invoke smart contracts through either one. So there's lots of exciting stuff going on here. These are some really big pieces that we've been working on and it's exciting to see it coming together. So just wanted to kind of zoom in on that particular piece of the puzzle of the, as all the pieces click into place to bring Firefly's functionality. Also wanted to touch on just a couple of code-based activity things. So since June, we've added over 44,000 lines of code. A lot of that comes in FabConnect and Firefly Core. So that brings us up to about 119,000 lines of code total across all our repos. It's probably more than that now because I measured that several days ago. So two of the big new highlights obviously are FabConnect. It's an entirely new repo. FabConnect is really interesting because it has value as a standalone piece of software as a service and it also is an essential part of the Firefly system as well. So it allows for easy communication with the FabConnect work and that is also what enables support for using a FabConnect work in a Firefly network. The other entirely new repo is what we call Firefly tokens, ERC 1155, slightly wordy, but it's essentially a reference implementation of a token connector for Firefly. So if you haven't been a part of any of the community calls where we talked about the design and the work that's going on in tokens, essentially the goal is to be non-opinionated about which type of token contract will be used in Firefly. We want to be totally agnostic to that because people will have different needs. They'll want to plug in their own, whether it's an ERC or just a totally custom token contract. We want Firefly to be able to support all of those. We have this concept of a token connector which allows Firefly to adapt to a completely custom contract. This repo is sort of a reference implementation of, hey, if you wanted to use 1155, here's what that would look like, but you're welcome to take it, fork it, change it, or just create your own that implements the same very simple API contract. There's a swagger JSON that just needs to be implemented and you could build your own token connector in whatever language you would want to talk to whatever type of contract you'd want. All right, so I also want to touch on community activity. So one of the other topics that was discussed a lot when Firefly was brought forward last time is, hey, this hasn't been an open source project for very long, and is there a community? Will there be a community? We want to make sure that that's true. There's a lot of work to do here still, but I think we're off to a very good start, and so I just wanted to kind of touch on what's been going on in the community. So we've had weekly, and then we've switched to bi-weekly community calls. At the beginning of those, they were more of the maintainers telling people about Firefly to get people knowledgeable, to get people familiar with the architecture, how the code base was laid out, the project structure, and the goal really here has been getting people knowledgeable about Firefly and how it works behind the scenes so that they can contribute back to the code base at some point. That's the ultimate goal. As we have progressed, we have transitioned more to, there's still some of that, there's still architecture discussion that goes on. It's at this point, the last few community calls, it's been much more collaborative. It's been more of, hey, here's what we're thinking in terms of tokens, or fabric, or integration with other systems, and getting feedback from the community. The community's been great in voicing feedback like, hey, that feature would be awesome, or it would be great if it worked like this, or I was thinking of plugging in this, can I do that? So those conversations have been really fantastic. We've also heard from several different people or teams that are using Firefly, and they've been able to voice feedback and ask questions on the community calls, and it's been really fantastic to just dialogue with people that are excited about blockchain technology and using Firefly with it. We've also had several meetups in various regions, kind of as an introduction to Firefly, telling people what it is. We've done some live demos of showing how it works, and we've also done a, like a really hands-on, like, hey, let's actually run commands in the terminal and set up a dev environment to get new contributors set up to make sure their machines are ready, and they know how the project is structured, and all the tools that they need to be able to contribute back to Firefly. I'm also on rocket chat every day, talking with people about adding stuff to Firefly or how to do things in Firefly, and it's been really neat to see the, we have a steady stream of new people showing up and saying, hey, Firefly is really cool, and I want to build something on it, or Firefly is really cool, and I want this to be my first open-source contribution. So just really exciting to see people showing up and being interested in it and wanting to get plugged in. There's also been some great synergy with other Hyperledger initiatives. There have been some, through the development of FabConnect, some contributions have been made back to the Fabric Go SDK. We're in the middle of working on Basu support for the Firefly CLI. Firefly works with Basu today, but there's no out-of-the-box command on the CLI that you can run to just set up a local dev environment using Basu. That's being worked on. It's almost done. I've been collaborating with another member of the open-source community who has been working on that, and he's been doing a great job there. We've also been working really closely with the Giving Chain Project. That's a Hyperledger mentorship program, and it's been really fantastic working with them. They're doing some pretty cool stuff with NFTs and are excited to use the new and upcoming token functionality in Firefly. There's also continuing discussions or open interests from a variety of other Hyperledger projects, and we're really excited just to be able to work with the broader community. I think it's been a very positive experience so far. That's just a quick update on what has been going on. I also wanted to thank the TSE for, since we met in June, taking the time to clarify, hey, what are the things that we look at in terms of moving a project into incubation? I realize that it's not a checklist, although I may have laid it out like one. It's not a checklist, and I realize that, but we've been looking through the things that TSE considers. We, as a team, feel like Firefly is in a good state. We feel like we satisfy the considerations. I just wanted to briefly walk through that and talk through each of them. I went to the Markdown document. I copied and pasted kind of the main sentence in each bullet point here and then have commented on each one. Code should exist as open source. Yes, for Hyperledger Labs. That automatically checks a bunch of boxes for us, including we have DCO sign off. That's just automatic through being in the Hyperledger Labs or projects should have multiple maintainers. All of our repos have at least three maintainers. You can go to each repo and see the maintainers.md in each repo to see who the maintainers are for that one, who's allowed to push the merge button. They should all have at least three right now. And they're different based on individual expertise of that person and familiarity with that language or that code base. Moving on in the maintainer section of the considerations, projects should have demonstrable examples for POC or production uses publicly available. There's several POCs and they've been discussed on community calls. I linked to the recordings of those. If you're interested to hear about them, you can go watch the community calls. Giving Chain is one of them. They're building a, it may be more than a POC, but we've been working very closely with them. It's been a fantastic collaboration and it's been really neat to see somebody building a new app, especially using some of the cutting edge features in Firefly. There's also another financial POC that several individuals have discussed on community calls. It's not open source, so I don't have a ton of details about what it does, but it has been publicly discussed and documented on a community call. The projects should have backing of one or more organization or individuals. We have numerous maintainers, sorry, numerous developers who are not maintainers are actively contributing code. They're working on a couple of different things, including in the CLI and FAP Connect. We also have other companies that are planning to contribute to the project as well. They've opened up some issues on GitHub and kind of the main Firefly Repos and ETH Connect and Firefly Core with ideas and designs of things that they would like to see in there. We've talked with them and they will have some developer cycles in a month or two where they want to help get in the code and they want to build some of these things out and work with the Firefly team to design some of these major new functionalities. There's also a large healthcare network that is standardized on Firefly and they're going to be building a lot of things on there. I can't comment too much on that one in detail but there will be a press release early next year to talk more about that. And lastly, Consensus Health is building on Firefly in the healthcare context and they've talked about making contributions as well, looking to extend Firefly to add new functionality as well. There's individual members who may come from a company. They may just be one person. They see Firefly and they're like, hey, it'll be really cool if Firefly did this and they hop in, they add a little feature and that's great. There's also some longer term commitments from some big companies that are like, no, hey, we're not just trying this out as like an experiment. We're really building our business on this and we're in it for the long haul. So I feel good that we satisfy that one as well. All right, moving on. I'm trying to watch time here. Community contributors are familiar with open-source practices. I can't speak for everybody in the world that might want to contribute but I can speak for the maintainers and we are familiar with the open-source practices and for people who want to contribute that aren't, we've documented that. The Hyperledger has great documentation on it already so we've linked to some of that but there's good documentation in the repos of how to get involved, how to commit code, how to set up your machine in order to be able to contribute and that sort of stuff. So I feel like we checked the box really well there. It should be more than one sponsor and they should be from different organizations. You can refer back to the original project proposal. There are more than one sponsor and they are from different organizations. Okay, Legal was another area that did come up and Tracy reminded me of this one that there was early on a concern about licensing that was dealt with right away actually I think even before we moved into a Hyperledger lab and so if you're interested, I can link to the PR where that was addressed if you want to go look at how that was solved but there should be no licensing issues with Firefly. It is all Apache 2 licenseable. The license files are in the repos. Oh, I skipped the project names. Firefly is not a trademark name by Kaleido so I think we're okay on that one and yeah I think copyright-wise I don't think there's any other issues that I'm aware of or anybody else on the team is aware of. If there are concerns still please raise those. We'll take a look at them right away but I think we are good on this one and I think one other area that came up in discussion last time was overlap with existing projects and we'll elaborate on this one a little bit here. So first of all there's a consideration that Hyperledger doesn't want to take on another distributed ledger. I totally get that. Firefly is not another distributed ledger. It's a layer or several it comprises several layers above the distributed ledger itself so no concern there. New projects should bring something to the table that current projects did not. Firefly fills a real gap in the enterprise blockchain space. It has made sense to a lot of people like oh this makes sense. It fills a gap, it meets my needs and it helps me build an enterprise blockchain app really fast and that's the real goal here. Firefly presents an opportunity to build solutions that integrate and deploy across numerous Hyperledger technologies so it integrates with a lot of different things. It does not overlap with them though. There was a specific concern raised about potential overlap with the Fabric Smart client which came into labs right about the same time as Firefly and we can comment on that one directly here in just a second. We have a slide on that as well. Okay so that was the considerations. There were a couple and I alluded to some of these. There were a couple of action items from last time when we said hey let's table the vote on Firefly and come back to it in a couple months and I just wanted to I think some people have heard the conclusion on some of these but I don't know that the entire TSC has so I wanted to revisit some of those so everybody's on the same page and specifically overlap with Fabric Smart client. So the Firefly team had discussions with David with Angelo as a follow-up action from last time and the conclusion was that a Fabric Smart client and Firefly were different enough that convergence wasn't obvious. They're solving different similar but different problems in very different ways and it doesn't make sense to merge one into the other because they're fundamentally different things and so we all agreed that the proposed Fabric Connector as is makes the most sense for Firefly's support of Fabric being Fab Connect and we agreed to potentially revisit the Smart client in the future and possibly reuse certain features there possibly if there are pieces of that that we can reuse as a library or code added to the project definitely still open and looking for collaboration anywhere we can but the overall conclusion was hey these are different things and there's room for both of them because they're solving different problems in different ways. There was also a question about does Firefly use blockchain does it just use blockchain for time stamping? There was a lengthy discussion on this on the original project proposal I've linked to it here if you are interested in the back and forth on that discussion. I hope by now people have had a chance to look at Firefly more in detail maybe even had a chance to try it and see all of the things that it does and all the ways that it uses blockchain for more than just time stamping but the short answer is yes it does or the short answer is no it uses it for a lot more than just time stamping and especially with the work that we're doing for enabling completely custom smart contracts it really it really does complement the blockchain and it's built on a the foundation of blockchain it is the most important piece of the system but Firefly brings a lot more above that and around it to help build applications that use blockchain much faster so yeah that is it that's my last slide so I will pause there and very good I'm sure folks have questions I'm sure folks have things they want to discuss so I'll stop talking and let other people talk now and I just wanted to say thank you for letting me go through that well thank you for putting this report together it was very thorough and I appreciate that so I don't know if people have a lot of questions but let's find out does anybody have any questions for Nico or comments bobby hi I just wanted to say that for the mentorship program the giving chain I have three student mentees who are just learning coding in their colleges or well excuse me well on their way and the Firefly community has been so generous with their time and their resources walking these students and these mentees through the process so I have to say thank you so much it's been such a great experience the mentorship program has been such a great experience for them because of your support so thank you thank you bobby it's been great working with you all excellent thank you Bobby Angelo is next yeah first of all I found the presentation very interesting and I also think that was a very good decision to pause a little bit to not rush two months ago because we have seen now the improvement so we pushed and the improvement came I think there is also a better understanding of what Firefly does I personally still this is my personal belief that Firefly is still using the blockchain as a time-standing service and as soon as you say that you will allow customized the smart contract you are failing your mission of saying that Firefly is agnostic to to and you can swap essentially any blockchain because if I'm using fabric chain code I cannot swap immediately to a firm contract but that's I mean that's my just a personal consideration I don't like this concept of equalization about blockchains because it reduced the incentive on us on the blockchain developers of the blog or who develops the blockchain platforms to introduce new functionalities but about this I really appreciate the work that has been done in these two months thanks a lot I think it's been clarified many points have been clarified thank you I appreciate that all right thank you Angelou I thought there was another hand but I don't see it anymore Angelou you can lower your hand unless you want to add something is there any other questions or comments we had some great expression of support so or at least appreciation of what has been accomplished so date so I think that's great well if there is no comments I am going to propose we hold the vote Arun hey so quick quick question and thanks Nicole so for answering some of the questions that I sent over email that clarifies it so quick question right on the regarding concerns that I heard last time one thing was on the choice of words that were used in the proposal I guess we can figure it out going through the PR in the HIP and the second question that I had was on on so Hyperledger is going through a charter's change so do we it's just like when do we accept the project right so it's that question now should be accepted before that the charter changes come in or should we wait for it or right well how do you think the two are tied it's not obvious to me so if we go from the current charters it just feels like it should be a blockchain project but the new definition allows for projects other projects I see what you mean I mean we have you know we have infringed on the charter more than once so I you know unless anybody has a problem with this I would claim that we can just keep ignoring it and I as you just said we are actually in the process of updating the charter this has been put before the governing board there was a governing board actually earlier this week that I attended and I can tell you there are some it has not been approved yet because there were some minor discussions on on some wording which is completely unrelated to this question and that I expect will be solved pretty quickly and nobody objected to the general gist of the changes being made so I really think we can just go ahead and assume these changes will take place and I don't think that's a barrier but that's my opinion you can disagree yeah heart is next yeah I just wanted to agree with Arno and say that I don't think there's any reason to delay this over the charter and I think it like sort of fits even with the current charter enough that I wouldn't have any worry about the charter being a problem so I don't think the charters an issue here okay thank you heart so given that let me get back to what I was just about to say before which is I think we should just hold the vote to see if we can all agree on the moving firefly from labs to a project in incubation a second a second sorry all right we have a whole bunch of seconds so that's great uh I guess we have time to do a roll call okay give me a second to get the the list of people sure okay in the matter of before the TSC uh Angelo how do you vote I have a thing Arno yes Perun yes Bow Wow yes Bobby yes Dano yes David yes Grace yes heart yes Nathan yes Tracy yes Troy yes uh okay the yeses have it with one abstention so it's a three absent uh 10 yes and one abstain so the motion passes the motion congratulations guys welcome to the club thank you very much already in the club but so on behalf of the firefly team I just want to say thank you uh it's it's been a pleasure working with you all and working with the hyperledger community over the past few months and just really looking forward to continuing to work together and uh where we go next from here it's very exciting thank you so I think we I want to go back to one technical aspect though is what Arun says I think is accurate I don't think you guys have updated the heap which is in the form of a pull request and maybe before the pull request gets merged even though I mean you know we we have now agreed from a TSC point of view so there's no question as to the project being approved or not but maybe the text should be updated you might want to have a look and I notice there's some technical aspect like there's no DCO although you know for for this kind of PR I don't know that the DCO really matters but you know the the PR should be probably updated refreshed and made ready to be merged that sounds good I think some of the wording suggestions uh had been addressed but I will make sure we go back through it thoroughly and double check to make sure that we've we've looked at everything that's there all right very good thank you is there anything else anybody wants to add uh I just want to say congratulations to the Firefly team and uh Nico if you could reach out to me let's start the mechanical process of moving your repos over and let's make it happen let's make it happen I can't wait to find all the broken links yeah I know it's it's easier than it used to be but it's not easy yeah all right all right well again congratulations and thank you everyone for joining today and uh talk to you again next week goodbye thank you everyone bye bye thank you for the rest of the game bye