 I mean, good evening, good afternoon, whatever it is, wherever you are on tap for today. We have our usual reminders about the upcoming act fest in June in Amsterdam and the internship progress project program. Sorry, it's early, which the deadline for students to apply is a second tomorrow. So, if you're interested in that, please, or you know, somebody who is please make sure they get that in there. Today, we're going to have an update from Explorer and and then from a working group perspective, we have requirements this week, correct? Yes. And we have somebody on for is Clive or Oleg on for requirements. Clive is on. Okay. Awesome. Awesome. And then I have updated the the lifecycle document to add, you know, this sort of first major release stage requiring a TSC review and approval. And so you can go over that. And then we have a proposal for a template to standardize. I'm launching working groups. And you have a thread on that. So, and then finally, I think Dave is going to reveal us with a proposal to open up the bug bounty for hyperlinked to the public. Any other agenda items for today? We're going to pre visit. Okay, then I think we'll turn it over to who's giving the update on Explorer. That would be me, Vinita, I'm representing part of the part of is unfortunately occupied in another meeting. Okay, great. Okay, so I joined the Hyperledger Explorer project last month. So there's quite a few new members that have joined in the last quarter. We have Ashish Kumar Jitendra Dikit from American Express India. Nick Franza, Mikiya Edwards and myself. We are from DTCC and we have recently added Kamak of Inspire Technologies from California. We are making good progress at this time. The project status is green. There are two major changes we have made in this quarter in the past six weeks or so is the front end was switched to React.js. So we have a new UI design. American Express folks are helping us with the UI design work. And besides that, we have also switched out our database from MySQL to Postgres. There are changes going on on that and also with a DB redesign for future development in mind. So our current plans are to finish up whatever we have started. So we have quite a few things on the front end going on. We want to complete the hookup of the front end with the back end data and finish that in the upcoming quarter. We also want to add some admin functionality. So we're helping us with that is Kam with starting with adding a channel that's the first admin functionality we will be adding to explore. So that is the update and I did post the update to the wiki. So it should be up there. If anybody is interested in looking at what it what the Hyperledger Explorer looks like right now I can share my screen. If that is okay. And Sure. Okay. Okay. Here we go. Share screen. Okay, so I have it running locally right now. On my machine. So can you guys see my screen. Yes, I can. Yeah. Okay. Perfect. So this is the new look and feel we were talking about. So we we do need to add a logo up top here, which is something we will be doing over the next couple of days. We do have a logo in place right now, but we just hadn't had a chance to put it in. I have the file that was created for us this morning. So we will be adding that soon. So right now it has five major navigation. Possibilities up top. So when you first log in dashboard is where you would be presented to this is where we want to show some analytics about how many blocks coming per hour per minute or transactions per hour. So this is something we're working on right now. So we know what we want to put here. You only see what the one transaction that got pushed last night that when I was working with this the block with the one block right now and The activity chart right now down here that would be showing blocks as they come in. This is right now static data, but we are working on Making a dynamic. So you will see it as it comes in. Peer graphs. So right now the Network we have up and running has four peers. So this is just showing that Then we have the network tab, which is going to list all the peers in the network currently The blocks will list all the blocks that we have right now. So this is the data that is coming from our Postgres database right now. And this is transactions page right now is static, but we are working on making a dynamic. So it pulls the data from the database and puts it out. And also the smart contracts is to be done. It is in the works. So this is all going to be driven off of what channel you're looking at. We are building functionality to be able to change the channel. So right now there's this is the only channel. We have the my channel. And this is where we are at with this and that is my update. Any questions. Thanks, Anita. Any questions. How does it interact with identity. How does it interact with identity. Right. Able to see You know, is there any restriction on Who can see what We haven't gotten that far yet. We have to build that into it. So this is this is the very first basic Being able to take a peek into the ledger and see what's on there. But yes, that will be coming up in future sprints for us. So, will it support the fabric while and why my version together. This is working with the fabric one dot oh right now. I see one dot one is released, but we haven't upgraded to that yet. So that is also going to be happening sometimes soon. Okay. And second question is about the docker image. Do you have any plans that make some doctor image. Yes. So absolutely. Absolutely. So that that is that is what we want to do. We were discussing yesterday. So make it easier to provide a docker image for people to get up and running quick. That is also slated for for the second quarter. Okay, cool. Thanks. And can you speak about your plans for supporting the other hyper ledger infrastructure projects. I am afraid I don't have an insight into that maybe Part of them might be able to give a better update on that. I can get back to you on that. Great. I know when I was in China, one chain who was working on the Explorer project talked about sporting sawtooth as one of the next things that they wanted to do. I don't know what the status of that is, but I know that they they had it in their plans. Oh, they did. Okay. Yep. Okay, so unfortunately they're not on the project anymore. I'm not sure what happened, but they're not at this point. On the on the contributors list. I might I myself joined last month. So I'm not sure what the status is there. Okay. Okay, I don't know if you know how already has a Explorer capability. I know that they had started off with a lot of Handset capabilities with their platform that you might be able to find existing code within their project that would help you Oh, awesome. Similar capabilities there. Yeah. And then on the sawtooth project. We had a contribution a few months back adding in an Explorer that was geared towards sawtooth. And you'd be more than welcome to just grab that code as a starting point. So you'll see that in sawtooth Explorer. I think what the repo is called or any type of ledger. And then I think Nate is on from the indie project. If there's some similar Explorer capabilities there. On the indie side, we haven't added an Explorer capability yet. We do have some APIs to get the right transaction sets and the right information out of the system. So, you know, if there is a common code base for kind of the UI side, I think that there's some interest in integrating those APIs into whatever others are using Right, that would that would make sense. Yeah, I would guess across all of the projects. And I think this is an assumption that led to the creation of your project assumption that for most of these blockchains, there's just going to be a couple simple restful get queries that would get most of the information from these chains. So it shouldn't be a wide set of differing APIs that you'd have to address. Well, actually, there probably is. Right. Right now we have the. Yeah. So right now we have the Node SDK we are using for for fabric. So, right, I mean, I think that this is, you know, this is an opportunity to, you know, be collaborating across all the projects to get alignment on what that might be. If we want that to be indeed, you know, sort of cross platform, there are going to be some distinctions, right, you know, we was talking about, you know, sort of per channel visibility. Obviously, I'm unaware of any other platform projects that we have that has the concept of channels. But, you know, so there are going to be some impedance mismatches that we have to sort of work through but I think, you know, maybe this is an opportunity, maybe in the context of the architecture working group and then in conjunction with all the projects that are interested in getting integration with the Explorer function so that we have a common Explorer across all these really involved in what it really means is that it's a it's a collaborative effort. Right. So, you know, I heard asked for, you know, when is blockchain is for going to do the saw tooth integration. I heard similarly, you know, the discussion about composer and really what it boils down to is it boils down to everybody. You know, what what what is the interest, you know, open source is developed by people scratching an itch if you have an interest in doing something you get down and do it. So, I think, you know, what we need to do is we need to be thinking about how are we going to affect a little bit more collaboration to actually get these things done if that's what we want to do. Yeah, and I guess I was trying to point out that there's probably not 30 different API calls at each project. It's probably a small handful. So it's a tractable problem. And I think that was that was part of the impetus for this this project. And then when project sponsors come forward to create a project that has the aspiration of being across the hyper ledger technologies. That's that's certainly a statement that that they're looking to go do that that work as far as it being a kind of a doocracy. So there's going to there will have to be a balance between if if a cross project effort is started. How much does that imply a resource demand on the existing projects and how much is that a statement by those people starting the new project that they're the ones that are taking up the the the onus to go across those projects. And I think one of the things that you know the fact that there are explorers that there is an explorer for sawtooth is an indication of a desire for that for that capability so in that you know in the doocracy view of things. And the other observation is that the longer we go down the path with an assumption of a single back end, the more bound we are and the harder it is to add additional features so you know that again as as Dan says if there's some intention for something being kind of cross hyper ledger capabilities then there has to be some pressure put on on ensuring that that happens. Well but again make I'm not sure that pressure is the right. Adjective here I mean yeah you're it's not a function of if I agree but you understand what I'm saying though that there has to be some I do motivation to do it. But again, I think that you know it was also a function and if I recall correctly the way that it was presented was, you know, other back ends could be supported. It wasn't we intend to do all you know support for all the back end and actually I think there was just two at the time, right. And, and then there was an explorer background, you know this the sawtooth as far back and this was contributed but there wasn't. And we did discuss some collaboration between the two products but I don't recall any of that ever happening so. You know, again, I think, as I was trying to say before, I think it's on us collectively to find ways that we can do this collaboration so that we can end up with not multiples. But you know we can have a common project that is in fact across, you know, and satisfies those requirements but it means that there's a certain alignment of apis or certain degree of alignment of the apis to get access to the information we're looking for, and then agreement that you know we'll share some resource and doing that work. You know, necessary to do the integration with the various back ends. And, you know, I think, as I said, you know the architecture work group is an opportunity, you know, we could leverage that potentially to try and figure out what, you know, what it would be and then share that amongst the various projects, so that we can actually start working towards that objective. And, you know, if there's a sawtooth explorer, then I think collaborative working to figure out understand that code base and figure out how it does integrate, you know, maybe what we need is to have a pluggable set of widgets gadgets whatever you want to call them. That are, you know, reflective of an underlying platform, but that are particular to a platform, because maybe there are some distinctions like channels and so forth that you need to be able to height, you know, to elevate to the level of an explorer. All I'm really saying is that I think that level of collaboration is needed in order to pull this off. The other. Well, I do think that if a project has taken on a charter, though they are taking on the responsibility for fulfilling that charter. And in the case of Explorer, my recollection is that the charter for that was to be a cross platform explorer. Otherwise, it wouldn't have been, you know, interesting outside the realm of of say fabric specifically in this case. But likewise, you know, it would be weird to take an Iroha explorer and put that out as a hyper ledger explorer with a stated goal being cross project. I think Dan's pointing out the other end of the spectrum Chris, which is just an acknowledgement that this is really a fabric project, change the charter to reflect that and make it essentially managed as a sub project under fabric. I think that at the very least we should have integration milestones, you know, we should set the few. I don't know if it's quarterly or every even two months, we try to put some API that people can plug into and get some feedback across the project. If you thought as people want to chime in, I don't know, just to make it easy for other people to understand like how much they need to do in order to work together. At the moment, we just update each other about what we have done. We should tell about kind of what we are doing so that it's easy to kind of, let's say if now it's March, maybe okay, mid May, we'll have something to look up to. And then if a sub project or another project needs to change some stuff to work together like the pluggable things that Chris mentioned, it's going to be easy at the moment. I think that the projects don't talk to each other at all, right, at least in the context of Explorer. So so this has something you rise the plan. You know, it doesn't look like we even have the milestones on any roadmap. Right. And that's, that's really my point. I think, you know, again, if, you know, if we want to do this and I think we should, and I think many of us do want to get to this level of collaboration we have to stop acting as if we're all independent competing projects, and start working collaboratively across the various projects now it's starting to happen. But again, I think that it does require sort of investment and interest and execution by all of us collectively. That's all I'm saying. Well, if there's not a team can publish some API that you can plug plug stuff into is going to be easier so that we don't have to dive in too much into it. I think it's the other way around though, right. Did the other projects would say what they expect that yes, something that's an Explorer that's reading information so that's calling the API is that are produced by the by the other projects. So. Right. To that point, the roadmap that was presented to us. We, this is not even though we started with the fabric. This is not just for fabric. There is on our roadmap items to make it compatible with Ethereum sawtooth and other platforms too. So this this is just the starting point we started with fabric. Well, the theorem is a different beast if you have a different API right like completely different. Yeah. Well, they all do that. Yeah. They are different. So you're going to have to have an API that's pretty open, flexible to accommodate, you know, significant variations. And I think that I think it would be an interesting challenge to actually do that and you know, you have to kind of, I mean, there are two possibilities, right. It's always like this. Either you take the common denominator and it's not going to be very useful, or you have to make it, you know, capable of handling as much as you can and, you know, have some part be not appearing or be disabled if it's not provided by the underlying framework. I do think, you know, it's still, it should still be a goal, but I agree, you know, we cannot force people to work on things if they don't want to. This is open source, right? No, but then the challenge should change, right? That's what Danny's saying. If people don't, yeah. I think that's the only that's the only point that I was having as well is that look, let the charter reflect the reality of the project. Well, I'm just saying that it's a sad reality. Yeah, I don't know, it's true. It's very true. It's a sad reality that's not going to change until we view hyper ledger more than we view our individual interests. That's exactly right. Right. And, and we're not there yet. Yeah, I don't even know if I, if I'd go quite in that direction with it. For me, it's quite simply the, the charter that a project aspires to, if they're marching down a path that's making progress towards that charter, that's great. And so if, if the charter is wide, then that's, that's what they've signed up for. So. Yeah, but so let's give her, let's give them a chance. We heard from Vinita that they still have this, this plan, right? So I think we can, at this point, it's fair for the TSE to express the, you know, to basically give a reminder that the goal of the project and the charter is to support more than one framework. And completely agree, not suggesting any, any remediations right now, just that recognition. Okay. Well, actually, but I am, I'm suggesting if that's really interesting to the sawtooth community, for instance, then some of the sawtooth engineers are going to have to, or people that are interested in sawtooth are going to have to step up to help accelerate that if that's indeed what is needed everybody is driven by whatever their priorities are. Right. And, you know, I think, well, at this point, we can't just expect that people are going to do things because. No, I totally disagree, Chris. I'm saying that the charter that they signed up for was to go cross project. If that's what you said you want to do, that's what you're going to do. I'm not saying that I don't think that we can reverse the tables and say that a project can come out and claim that they will be a cross project effort and then require resources from all the other programs. Yeah, so to, I mean, to reinforce that point, sawtooth has an explorer that's clearly a priority for the community for the subject community, but it's easier for sawtooth to build their own explorer than it is to go off and try to modify and work with something that's principally focused on fabric. You're getting in and again that ease is sort of avoiding the collaboration and that's my. I don't think it's avoiding collaboration at all. I mean, we've put out the API's the code is out there. Somebody has signed up to say, alright, there's an interesting problem here which is how can you come up with an interface that goes across multiple API's. That's work that the explorer project signed up for. Dan, I understand, but I don't recall any effort whatsoever to reach out and engage the explorer team before that work was done. That's all that's my in the very early stages one of the first hackfest we had we worked on what was a common API. I had no idea what happened with the artifacts of that, but there was some initial effort at that. And certainly all of our API documentation is, I mean, it's pretty straightforward. I just put the links in there. It's not like there's a lack of collaboration in the sense that there's withholding of information or anything. I didn't say any information was being withheld again. Open source is a doocracy. It means if you're interested in doing something if you have an it you scratch it. And, you know, I think, you know, if we all operate on the premise that, you know, somebody else is going to do something, then nothing will ever get done. That's my only point. And so, again, if the interest is in the collaboration, engage and remain engaged and remain and continue to press that. But if we're not interested in doing that, then maybe you're right. Maybe we should just acknowledge that these are all independent projects. But I think we do. I think that we should be, you know, aligning a little bit more towards the ideal that, you know, that Brian and others are affecting with this organization and that is to have it be an umbrella. There that that fosters the kind of collaboration innovation cross project to the point where we do have pluggable components that interoperate with one another. That's that's where we're I think I think that's where we're trying to get maybe we should stop fooling ourselves. But I personally think that that's where we should be heading. Hey, guys, this is Brian. I've been trying to talk for about 15 minutes, but fighting the new teacher. I, you know, there are certainly some mandates that I think the TFP can play some projects and that, you know, overall we can expect projects to do, even if they didn't want to. One of those is, you know, a release process. What do you get to call a one dot oh, right. So one of those might be, you know, paying attention and joining other working groups around architecture. I mean, the things that it have to do with the quality of the release and that have to do with following kind of a standardized development process. One of the things I don't think we really can mandate of a project is to do work that none of the individual developers to add specific features to add specific functions that the developers on that project simply aren't otherwise motivated to because the response to that won't be, you know, we get those features built despite developers not wanting to work on it the response will be they leave the project. The only way to really affect this is to for somewhere a developer to show up with patches, just as if they showed up on sauce use and said here patches to implement support for poet on chips other than Intel. Right. There's no expectation on Intel to support other non Intel chips with with poet extensions right. Likewise, we need we need those developers to show up and the only way that we as as the project has to do that to pay for work like that we've done is the internships. We can talk about whether we want to pay for other types of development that don't spontaneously appear of their own accord I think that the very, very dangerous path but one that be on the table, but other than those, you know, paying for that kind of work. I don't really think we can cause that reports materialize short of one of the now many companies using and depending upon thought to to be interested in doing that work. As long as the project as long as explore as long as those developers are not actively refusing to support that kind of thing. I think we should change the charter. I think the only reason you would change the charter of Explorer is if you wanted to prevent somebody from adding support for sawtooth to it, or prevent somebody from adding a real hard to work otherwise leave that prospect that possibility. What differentiates a sub project then from a cross project right because, you know, if, if we were to create something that was, you know, let's say propose a hyper ledger wallet, and it and we're only staffed and resource to do that for ero ha. Why should that not just be a ero ha wallet instead of a hyper ledger wallet. Because by definition, if you showed up to an ero ha wallet and said, hey, I've got support for sawtooth for this and they, and they felt charge the order would allow them to say no to that. Right. If instead it's the, you know, this is a hyper ledger wallet that somebody shows up with patches to support ero ha or patches for both either fabric. The developer should at least meet them halfway by saying, here's where you can go or here's the API to follow or, hey, that's, that's great, but it needs to support this feature, you know, like internally you can have that occasion that that here's, here's the standard to me, but unless the charter were to say this is the ero ha wallet, there's no reason the developers should say that's not, that's not the thing we will support. No matter how good the quality of the passage. Well, I think everybody's set a piece here and maybe we can chew on that over the intervening week and head on to the next subject. I agree. Okay, so Clive, thank you, Vanita. Next up is the requirements working group updates of Clive. Hi everybody is Clive Bolton here. I've been heading the requirements working group up now for the year or more. And so I've got some mixed reports. The report actually spans more than the past quarter. It's more, I'd say the past year. Folks when they come along to the requirements working group, we don't have a regular cadre of attendees, the folks who come along to the requirements working group. We have a couple but generally the folks come to the attendee requirements working group are on new solution architects who join consultancies show up a couple of times. Sometimes folks from the consultancies intend to author requirements, but very rarely do they actually get to author requirements. After talking with some of them quite often the reason for that is that once they and actually this has happened a couple of times once they start sharing authoring requirements. It leads them into the business ideas, and that gets cut off pretty quickly. In fact, very broadly. It stops because I think they're sharing some IP in ideas and we've already covered many of the use cases which span generic functionality. This actually happened last week. The product traceability group came along from, I think, North America and projects traceability group came along. They've got a marvelously rich website, but don't really have any starting place to go to implement Hyperledger. I'll come to that in a little bit because most of the folks that I'm talking to are not really developers, they're solution architects or even business architects. What is happening though, increasingly, and I've actually visited some of these folks personally actually even flown to a couple of and actually gone out of country to visit somebody in Canada, is we have folks coming to Hyperledger who really want to develop new SaaS and solutions, but they have a different starting point than a technical starting point. They start the requirements, but they need that next step to get going and they find that many of them I find are now looking for a mobile client, a mobile application that interacts with the Hyperledger projects and are almost looking for a copy and paste mobile app. So I'm going to talk a little bit about that. I'm going to skip over our accomplishments over the past quarter because these have been a reflection of what I've just updated, just gave. And also they are, they're actually, I would say, more of a contributions over the past year, over the past four quarters. And they span everything from input from a research group on after the fact mandate changes that got stopped pretty abruptly to supply chain counter anti counterfeiting. And we recently had a an academic project submitted contributed by Tatic consultancy on actually a full full belt braces permission blockchain on fabric. So, and there's links to that on the on the on the update. So the way in terms of like our participant diversity, we have, we have folks coming from all over the US and also Canada and internationally. And again, I think the, certainly the folks coming from India are much more interested in a, and a mobile client help in foster a mobile requirements for a mobile client. And also in Canada as well with the Canadian government legalizing the small growers of that of cannabis. So there's a need for a mobile client to, and actually this interfaces with the product traceability.org to, to, to provide a very simple in app, which interfaces with a larger SAS hyper ledger database. And so I think that the overall requirements with group our, our, our folks are participants, folks showing up have changed from sort of folks who come along to because they recently joined the hyper ledger blockchain ecosystem, just navigating and trying to understand how do they plug in probably into these other projects that we've just spoken about like, such as Explorer. But they're, and they're also particularly interested when they make any contributions to the requirements working group that they rarely do. How do we interface with the other groups such as the architecture working group. And I don't think we have done a great job of that so far. And I think the opportunity is to personally, I am a developer, or program manager developer. And I have actually been giving some actually reprising Mark Miller's work on on security, particularly capabilities in JavaScript and also mobile applications. And I think this is probably a message in a bottle that that we could be working to with some of the business people to on the requirements of a mobile app and then turn that into some UI screens just getting some and trying to do the simplest things possible to make a easy to get going mobile app that works with some of the more popular hyper ledger projects, whatever the easiest way to do that is, whether it's the restful API that was commented on earlier. So that's, that's pretty much my update, I would actually like to add, additionally, I think it's really important and somebody put this in the chat that the The one, the, the sample sample code that we come up with should really should be in light of meltdown a spectra and Cambridge analytic or and all that stuff, and the ability of new standards which have dropped in Atmoscript 2015 ES six and so forth. We should be Coming up with the best security templates or just That we can in in sample code. And I think there's a number of ways to go about doing that. So that's, that's pretty much my Update and I'd love to hear any feedback. Thanks for the the thorough description there. I'd taken a look at some of the meeting minutes and been listening to your feedback on on what sounds like the principal challenges that the If I can overstate things slightly that the requirements work group has difficulty producing requirements. And I wonder if we're at a stage now after this working group has been active for so long that we can thank the working group participants for their time and maybe transition That community into a discussion forum so they can keep Ford momentum with the sorts of mobile app discussions that you were talking about there, but we can archive The products such as they are so far from this working group And then there won't be any confusion by Any of the the general public that comes to the hyper ledger working group Comes at the hyper ledger requirements site and gets maybe some confusion based on the current state of artifacts there I think I would I would support that and support that for two two really important factor of reasons. One is that we do occasionally get folks who come along And add a document title to the hyper ledger requirements That we're working on but that's all they do they don't actually add actually add a document And they I think they add it because they would like to get to those requirements or they'd like to have somebody else create the requirements but it never actually happens unless one of us who's I would say is a more regular participant and there's not too many Dig in and actually user expertise to all of those requirements So that has happened but it's it's attenuated to to to pretty much zero So I but on the other hand is this this discussion in this need to get going with hyper ledger projects from an app developer point of view as I'm not sure about is surge the right ways but it it's it's active and it's it's it's tangible I get And the other thing that happens is I get you know private advice please you know can we talk about this privately because they've got some sort of a business idea and they don't want to quite share that but they need this application piece and I would like to Help surface that and turn that into into code into some working especially app code Great right so and and you know this has been saying this for the longest time and every time you know people ask me how come there aren't more you know use cases and requirements. And you know the fundamentally inclined you just you just mentioned this people aren't willing to share for various you know oh my God we're going to disrupt the world. You know sort of business thoughts and so they're somewhat unwilling to share what their use cases are because they don't want to give away their bright ideas to somebody else but You know I You know I know you know I know that you know the the the folk that are working on you know the various platforms, various tools are being driven by some set of requirements. Some of those are getting shared you know within the context of the projects. You know as you know jeers or you know whatever have issues or what have you You know that are motivating development of some new feature or of some Capability And And we're we're you know maybe the approach that we've been thinking about is somewhat You know turned on its head that instead of that that we actually work to see how are the requirements that are driving the development of sawtooth and fabric and borough and indeed Anaroha Aligned or not as the case may be and surfacing where they're common and surfacing where they're different and then trying to understand Both aspects of that. Why are these the same and why are these different is their different use cases is you know what's motivating that that set of things. And You know I think initially you know we had the idea of starting with a set of use cases and then distilling from use cases a set of requirements and then mapping those requirements to some development. But the development in the individual projects has been you know sort of Parochial and And I think that again this this this highlights the fact that you know I mean we could continue down that path and maybe that's the right path. I don't know But I do think that there's opportunity here for us to be You know larger than the sum of its you know a certain amount of time. Something that's larger than the sum of its parts and yet right now you know I think if we continue down the path then we're just the sum of our parts. I can I also belong to the Google Developer groups have been a belong to that organization for five plus years and I noticed that They have an active Code labs in that help foster a community of app developers and it's almost I could see some sort of opportunity to Stand things on their head and figure out what are the What do the API's look like across some popular projects and Or maybe even there's some quite I couldn't I don't quite know what hyperledger explorer does apart from the great demo we saw earlier But if there's some sort of a A restful API which is has commonality somehow Understanding what that API looks like and the Capabilities that it provides and then and then Discussing and building the mobile app that but mobile app client that would work with that and trying and trying to use standards to do that whether that's mobile web standards or Or a client that will work on both iOS and Android So, you know, so Dan made a proposal Do do do we feel like that's fully fleshed that People are ready to think about Making a decision on that proposal or is there a desire to Maybe Have a little bit more discussion I'm fine with this especially since Clive seems to agree to Agree with it, too I do think that this This Dan mentioned another part of that which is this discussion that is kind of quite important for people that are new You know professionals arriving and they're They want to jump right into the to hyperledger unit By weekly provides that point, but it doesn't actually add too much other than just me giving some navigation updates I would like to much more Turn that into into some into some helps in that into some some app So that smaller projects that don't come Don't come from folks don't come from large consultancies could get going with hyperledger Maybe think about coming back with a proposal that creates a discussion forum that might meet on the phone or video chat or something on some periodic basis Okay, okay And On the other side to that Coming up with a Mobile app is that also of interest I know that there are some efforts to do mobile apps for the indeed ledger simply because it's the identity edge agents mandated But I don't know if there's a jet if there's general developer support for that A broad hyperledger level or not It's been my experience with distributed apps that each Each distributed app is you know an app unto itself And so you would want a mobile component of of an app But I don't know if there's a good way to have a general purpose Mobile client But yeah, I think we're always open to new projects and that's that's something that maybe you could Think on and if there's a way to make that general purpose You could propose that as a project or maybe if if you're able to have What heart was referring to here as an onboarding form an onboarding call that that might produce some Some other Engineers that have a similar interest or or designers for that matter that have similar interest and you might be able to collaborate on something Yeah Okay, I see the there's a template Which is going to be for standardizing and launching working groups that is coming up Maybe some of this work on the edge stuff is You know could be Generalized into a template I mean generalized into a working group that can then work at least explore some of these things without Being bound to a specific projects because that seems to be the biggest Point that we are discussing today because What seems to happen is there is a Fragmentation or balconization And only the working groups are the only glue sort of trying to hold things together rather than You know the projects are naturally as they mature They are diverging from each other and as they mature they have these two needs one is you know Some kind of a wallet app the other working group that probably should be there is some kind of a Deployment focused working group that has Is you know Puts together Some of the common themes around deployment So the product work product of a working group should not be seen in the same light as The work product of a Project because most of the you know it's it's Lightly bound together and it's cross project most of the time And it's very difficult to elicit Support from people because they're not you know in most of these cases people are either employed by Technical companies or work full-time on these projects like fabric or Souto's or Indy Of course there is a character of people who come along to help you know with the coding but even they are you know either somehow able to Devote a hundred percent or you know eighty percent of their time to this to producing Artifacts like code but for the working groups. It's a different story. You know that's that's been our experience So so we have to rethink our approach to working group and what the artifacts they produce should be and I am proposing that Clive is wanting to produce some to actually create some mobile app You know maybe it can be the launching pad for you know a particular mobile apps targeted to a particular DLT but at the same time be thinking about how that could you know those kind of things could be generalized into something bigger than Just one DLT and Sorry to cut you up. We're kind of digressing away from the the working group Agenda item Yeah, we are Well, okay, we haven't we haven't closed on it and we only have a couple minutes left So I I think you know given that I didn't hear any pushback on You know sort of calling the vote. I think so the proposal as I understood it is basically to deprecate the requirements working group and I'm not sure how we archive if you will The the the products of the working group and then maybe Let me just speak up in favor of keeping the working through different sections I think that you know the proposal is basically to To deprecate the the requirements working group and thank Clive and and the others for their all their efforts So Todd you want to run our role? Yeah, I think Brian are you trying to yeah I didn't hear just one one last it's kind of the thing to for folks to think about as a reason for The requirements working group to stay which is all the time people ask us, you know how What are what are some use cases? What are some ways in which I would use? These underlying tools to meet, you know specific challenges in my industry and It's been very useful to say we have a set of use cases on the wiki that are abstractly defined that are You know You know about explorations from a Place where you can detach it from specific vendors to say here's how you would use Hyperledger technologies to address You know supply chain issues health care issues those sorts of things and so you know it may be that that we need to Reboot the requirements working group to do that But it's been useful to have somebody that's have a working group I feel like separate from from the individual projects as at least a place to direct that interest And maybe it just needs a reboot. I don't know but it feels like if we lost that working group We might lose that cross-project view of you know What are the kinds of ways you might use these technologies to solve those problems? I think Brian just to picking up on that I think maybe it might be good to take a couple of weeks and just look at that and just in Actually, Jeremy had done some work very early on When there was only a maybe fabric In terms of doing that almost like reverse engineering one of the capabilities of the interfaces of a Other project and surface those so that they can So that people coming with requirements can understand what those are I Think the TSC is ready in a rare moment of decisiveness and alacrity to act And I'd ask that we just continue on that stream So I remove that we take a vote to close the working group All right, so voting for for Closing a work group and archiving correct. Yes. All right all in favor. Please say hi Hi Any abstaining any opposed all right that passes unanimously. All right Thanks everyone. We're at end of game and I did send out the proposal for The new milestone and please weigh in also on The working group template discussion and we'll pick those up next week. So thanks everyone and Have a nice day