 Alright, thank you. Welcome everyone to the weekly TSC call. As always, this is a public call. Anybody is welcome to listen in and participate. There is two requirements to doing so. The first one is to be aware and live by the antitrust policy, the notice of which is currently displayed. And the other one is the code of contact, which basically requires that everybody behave respectfully like a decent human being. So with that taken care of, I'm happy to jump right into the agenda just before we dive in. So, you know, you may have seen we got the report from Aries. We had not had one in a while that was an oversight. I'm sure this one happened again and we had a pretty good interesting report with a set of questions which I think, you know, go beyond the scope of Aries only. And so I thought this was worth putting them as general discussion topics rather than just, you know, keeping them as discussion for Aries. And, and so prior to that we'll have a presentation from our staff members, David and Ray, on the contribution campaign. So, right, there was this announcement in the agenda. I know David created the agenda. I think it was a copy over from last week. Is there anything new or just a reminder so that everybody knows. I think this is a copy paste. Yeah, but same thing. You know, just replay the last week's. Yeah, it remains relevant so I was like, I can leave it there as a good reminder. Is there any other announcement anybody wants to make at this point. No. All right. If not, then we can go ahead. So as I was saying we received the report from the Aries project. But then the two questions that were actually highlighted by Steven in the report. Do is there any questions from the TSE. They send a pretty comprehensive report. And what it looks to me like a very healthy project with contributions and implementations and any different ways, including users outside of hyperledger which is great. So there isn't. No, this is Angela. Maybe I would like to take the chance because I also I found interesting that I was supposed to use it also outside of a ledger. So the end I was feeling that apart, apart the presentation about tech tech this technical presentation that we are having. It would be interesting also if the project someone from the from the projects come and tell us about success story. The way they project has been used in production or to solve a real world problem that I would find very interesting person. That's a good point. And maybe, you know, this is one of the projects. I mean, Steven case you I think you do know because you participate in those calls. You know, we've we're now welcoming presentations that are more a bit more like you know gives us an opportunity to have a deeper dive into each project. If somebody from the areas project, we're willing to do that. I think that could be a, that could be a good topic. And as part of that presentation, you could indeed highlight the kind of uses that are being done outside of hyperledger and industry in general, that are kind of like in production to address Angelo's point. We'd be glad to do that. Sam's here as well. Nathan as well. I'm sure. And Troy is here as well so I'm glad to do that. It is certainly a popular topic these days with some sort of worldwide pandemic going on. Yeah, I realize that. All right, so let's try and schedule that for some future call was, you know, whenever it is convenient for you guys. You know, it's a really good chance up. All right, let's go to the queue. Hey, thanks for the opportunity so on days. Hello. Hello. Yeah, go ahead. We hear you. Okay, sorry. My mic shoulder red mark. So yeah, I'm on the ace right so I was, in fact, working through some of the examples. I don't hear him anymore. No, no, you're not. I think we lost him. Dano. So some of this discussion is put for later down in the question, but I guess I have one question for Aries. Are there any incubation statuses. They don't meet. Do they need all of them. I don't know. I don't know if they didn't know which ones they don't because this is also kind of a pit for that all incubating products projects. I would like them to see them reflect on the incubation statuses and the quarterly reports. So at least they're aware of what needs to happen next, if anything. Yeah, I think the big, the big issue with Aries is that because it's such a decentralized project, if you will. I think that we haven't come together, but I think at least two and probably three of the frameworks within Aries meet all of the incubation requirements. So, we could definitely go down that list and produce that back to the TSC if that's the question, but the more interesting one is just this. It's not a single thing. It becomes harder to say, well, you know, if you go incubation and then you go look at one of the frameworks, and it's nowhere near ready nowhere near a production use, how does that get conveyed. And that's, that's been the tricky part and probably why no one has stepped up to say, Oh, we should be out of incubation. We should be active, but I think we should be active. I think we've far exceeded the bar set for active. And to add a little bit more of the historical context here. The idea when we split apart Aries from Indy was that we would do some library refactoring on the libraries that for cryptographic information exchange that came out of Indy. And a lot of those library refactoring efforts either didn't happen or didn't happen the way we expected, meaning the frameworks that were written and go and in Python and in.net took on a bigger role inside of Aries and use the rest libraries the common rest libraries a little bit differently than we thought when we first started the project. And so the projects matured and got a lot more development effort more quickly than we expected but also some of those, you know, checklist tasks that we thought would happen early, got pushed out towards later. And now we are seeing those library factors come about and we're starting to see some of that effort or some of those tasks get checked off. But, but like what Steven said, they're not real, they didn't turn into the prerequisites towards stability that we thought they would be. And so it's probably fair to say we are active in all the sense that we would normally consider for a hyperledger project, but we haven't necessarily finished all of our goals in terms of a common core. And this gets to that next question of protocol, where we do have a common core in terms of everyone supports the same protocol and we can do interoperability testing and compatibility between all the frameworks. It just didn't happen the way we thought it would have. All right, so let me stop the discussion right there. I mean, I appreciate this and I want us to spend some quality time discussing those points but I put them on the agenda for later. Which to the part to the presentation part of the agenda, and then we can go back to those questions. I do agree with Daniel that I would, I think it would be interesting for you guys to actually look at the executor from incubation and see where you know where you stand because I think there's some disconnect there which hopefully we can clarify in the discussion later. Is there any other questions other than those major points, which we'll get back to. Sorry before I, I got dropped. Yeah, quick question so on the front I see different frameworks right and just from the documentation perspective for somebody who would like to start using it. I guess there is inconsistency in terms of how different agents work. If not, only the, I mean the API's which are exposed. Some of the functionality as well so would it be nice to document or have a separate repository which says, hey here is the common goal, which any of the areas agent would support. If you have a need for you to use a stick it and this is how you would use, or if you want to just use it as let's say component which sits in between your controller and actual blockchain layers then start using this for this specific blockchain. Is that are there any plans of organizing those kind of things short answer is that's already there. I'm going to go into a lot of detail but I'll defer but short answer is that is there may not be easily found. Obviously, if you haven't found it but it's there. All right, so if you on the side maybe in the chat can point Aaron to the right documentation. I think that would be good. All right, thank you. Let's get to the presentation and the contribution campaign. I will hand the floor over to David. Hello, are you able to hear me. Yes, we are. So for a little bit of context, this is an idea that came up at global forum last year. A number of people were involved in the idea, Tracy, Jess, right. I, you know, and others and we've also been talking about it, you know, on and off over this last year at the developer relations call that happens every month. And we did want to up level this a little bit and share it out because we did reach a milestone last year we came up with the idea we wanted to run a pilot to see if there are ways that we could help boost the number of contributors that are getting connected into projects and we did just complete a pilot we presented that information at the devil call and again just wanted to share this with you. So let me share my screen real quick. Are you able to see my screen. Yes. Great. Let's go through this quickly. If there are questions that's great. So I didn't want to take a ton of time but just to go through quickly. As a starting point I just want to point out that the new insights tool that provides a lot of metrics for the community which we haven't really had until recently is a really great resource I encourage everybody to go check it out. Let me pull some information from there around just the level the number of contributors of the last 24 months, and it basically shows that things are flat, you know there's a couple of dips in there but those are just artifacts of the holidays when things are a little bit slower. If you look at the rolling average green line you know it just shows that things are relatively flat over the last 24 months so the, the idea again of what we were trying to do last year was, can we take specific contribution opportunities and run a campaign around them that you know leverages all the best practices that we've learned for how to market what's going on in hyper ledger, and share that out and see if that makes a difference you know my observation is we haven't necessarily done that in the past we've promoted getting involved in hyper ledger and contributing to hyper ledger in general but you know, you know my I was making an assumption and I think many of us are making an assumption that people. don't have a hard time going from okay here's hyper ledger and how do I go from that to a specific contribution opportunity, just because of the nature of the community where there could be a little bit of, you know, lack of clarity about like okay I get hyper ledger as an umbrella there are all these different things happening but how do I find a specific thing that meets my, you know, interest and skill levels. You know we've got a bunch of different projects a bunch of different labs a bunch of different groups so we, our thought was if we run a contribution campaign very specific about these are, this is one of the things in the hyper ledger greenhouse and these are the specific opportunities, you know that you can do there, you know would that help connect people into, you know, contribute becoming a contributor so that's what we did. We picked. We talked to a number of different groups and the blockchain automation framework lab was just the one group that we ended up moving forward with first in the pilot so we, we've been working with the blockchain automation framework team. In the summer of last year, we helped them create a contribution landing page that really includes a number of different best practices about, you know what we thought would help easily create a pathway and support for people to get into that project and start contributing, and then we shared it on all the different hyper ledger channels that we have available to us and just was a huge help here helped us create a framework for you know what were the channels that we could use how do we use them. And so we're coming up with that campaign for us and this included running meetups using the hyper ledger website the wiki newsletters emails webinar social so basically let's the idea was with the test let's try to put this information on all the different channels we have available to us. You can see here for an example. The image I'm showing is a promo that we put on both the hyper ledger website on the participate page and the wiki main page just as an example of how we use those channels, and then we did that for a period of time over QQ for And then there's some data that I'll show right after this to show you what the impact was but I think the most important thing to share out, you know, here today is that by doing this we've created a number of assets that were used for this campaign that can be reused as templates for other campaigns, you know, and that means that contribution landing page I would encourage people to take a look at there again a number of things we put in there that I think are helpful, very clear instructions about how to get involved you know step by step you know video. We embedded the good first issues into the landing page itself you know we wanted to make it as easy as possible for people to find those things so you know remove some clicks for how to you know actually get connected to those opportunities. So anyway that's an example of one that an asset that could be used as a template. Reuses a template for other projects and then the campaign itself you know just did put, you know, an example to the gather of how do you use hyperladers channels and that could again be reused by other people so The intent was not to do this is a one off but the intent was to do this is a foundation for something that could be repeated. And then just as far as the results go I won't read this whole quote but this was from the main point of contact at Accenture, who was working with us on their side on the back team and you can see here they were very happy that they decided to do this campaign and they felt that this really catapulted their open source, you know, project in the community. There's an appendix to this that goes into a little bit more the details but you know I'll leave that to you to look at if you want to I did just want to provide a few really high level results for what the analysis was showed about how the campaign worked. In terms of new contributors there were seven non Accenture contributors that showed up and started contributing during the campaign. These came from a variety of different organizations. So it was really encouraging to see that not just the number of contributors but also the kind of the diversity of contributors, you know, grew over that time. And then a couple of things that were really that were very important to the team, you know they were really wanting people and not just to show up and contribute to an open issue but they wanted them to actually get involved in the campaign and the, you know, the dynamics of the community so the, the blockchain automation framework team when we asked them what are the things that you looked at to see if the campaign was successful or not they picked out these other two points one was planning calls. Again they wanted really, they wanted people, you know to show up and take part in the discussions and the planning for the project and so before that campaign. Every now and then they saw a couple of new people show up on a call but it wasn't consistent and there wasn't many many, and there wasn't very many but since September they really have seen consistent participation from several non Accenture participants so they really mark that as a sign of success. And then the chat channel. Yes, the number of people in the chat channel increase but again for the core team that we were working with what was really an indicator of success for them was that questions. So many questions have been asked, you know, asked in the channel as more people showed up but to them, the fact that answers were coming from other new community members was a real sign of success for them you know it's not just the people. The initial people who started the project who was always answering questions, you know they found it very satisfying that a new person who maybe had showed up a couple months ago are now also answering questions to the, to the newer people who are showing up. This is just the takeaway that we got from the, the BAF team about what were the metrics that you know really stood out for you so again wanted to share that and I think this was an indicator that you know we were able to you know use hyper ledger channels to connect people into this specific contribution opportunity. One thing that I think we could do to build on this beyond just reusing those templates that we created for other places but I think one thing that would be maybe a phase two in this pilot that I think would again be something that we could turn into a template is. One of the things that other people have shown up and started contributing, you know it's really key in an open source project to recognize contributions so one thing that came up as an idea. In this pilot that we're working with that team on is they were really interested in issuing digital badges, which is something that has happened in other open source projects so, you know, this is something that we have not done yet but I just wanted to share with you that this is an idea that's come up and if there's an interest in doing a deeper dive into a discussion of what would a contributor badges for hyper ledger look like we can come back. And talk through that because when the BAF team asked about that we did start to look into it and have started to put a plan together so anyway that's an idea. The idea for doing more with recognition is that you know it really incentivizes new people to show up if they're seeing something that seems like oh that'd be great I'd like to earn that myself, and I think very importantly, it helps keep those people who did make that contribution involved you know if you show up at an open source community make a contribution and then nobody says thanks or nobody you know really acknowledges you can feel like oh maybe I didn't do anything that people thought was worthwhile I do think this recognition piece is a really important part of, you know, this, this campaign idea, and I think it's really hard to over invest in recognition and open source community because there really is a return on investment and doing it so you know yes we recognize people today but would an additional layer of recognition in the community, you know be worthwhile or not so just throw that out there, we can talk about digital badges if people want to do a deeper dive on that we can come back and figure out what a plan would look like. And then to talk about next steps, you know, we did start talking to a number of groups last year about doing a contribution campaign pilot and one other project is in the works. In Q one, in Q one, we're wanting to do a campaign around translating technical documentation, you know the hyperledger fabric documentation team last year really started to work with more communities around the world to translate their materials so they had a Chinese translation now they have six or seven more additional translations based all from you know contributors in the community who showed up and wanted to do that so we're putting a video together showcasing that work and could do a campaign around that. In a couple months when the video is completed, and then Jess is recommended that maybe we do this on a quarterly basis so you can see on here we don't really know what q2 q3 or q4 would look like although you know again that's her recommendation that we do that and I think you know from my point of view, you know I think you know it would be great to do more of these I think you know now that we have done this once it will be easier to do this and again because again we have these reusable templates so I would be happy to help work with people on this as well. So what our thought on is next steps to kind of round out the schedule for the years to go to the maintainer calls for different projects share with them, you know the idea of, you know, being able to run a contribution campaign and see if there is interest from others and doing this, you know, I don't want to I don't want to make an assumption that there is but it is something that we now can do it. It's not going to be that difficult you know I think there's an easy set of things that we can do to really you know highlight what those contribution opportunities are and then we'll throw them into these channels using the process we've established and then again we can do the same process we can see measure the success of those build on you know what's working tweak what's not working as well and then maybe make this a very easy repeatable process. So that was all I wanted to share there are some additional things just to be aware if you want to take a look at the slides there's an appendix that goes a little bit more into the details of what what we actually did in the campaign and some of the other metrics we saw but this was more just a sharing of what happened and see if there are any questions. If I missed anything please feel free to add. Any questions for David. I see Mark has his hand up. Yeah, you mentioned there were seven new people for this effort. How many of them came from outside of hyper ledger versus, you know, current members. I don't know if we did we break it down that way I mean that we could we could go back and look at that to see if it's new, new to hyper ledger or just new to this lab. You know, I don't know. I. Good question. I'd have to get the data. It's, it's not something that I have at hand. Sorry. Not that big a deal. I was just curious. But I think that is a good question. I, you know, since we haven't done this before we didn't really know what were the most important metrics to look at but if, if kind of new to hyper ledger contributors is worth breaking down we can do that. All right. Anything else. I think I was pretty competing stories or should motivate other projects to want to take advantage of this. Yeah, and if other projects are interested it's a open invitation feel free to reach out to ride to me to Tracy. I just add, you know, trueners to the staff. Right. Without the staff we wouldn't have been able to do this and so I think this is been a really great experience from the blockchain automation framework group. And, you know, I highly recommend right like the staff is there to help us and this is one of the ways that they can help us so if you are thinking about how do you get more contributors. This is definitely a good way to to approach it. Yeah, thank you. I guess is all I have to say. Great. I'm glad to hear was a positive experience. Sounds good. All right, so if there is no further questions, I suggest we jump right back into those discussion points we started touching on earlier with regard to the areas report. But which, as I said, I believe, you know, bigger than areas which is why I wanted to address them in a more global way. There are actually two different points that are fairly, you know, independent from one another. The first one I think is easier and by the way, in case you haven't seen it, Brian sent one of these long email to the TSE list where you address these points from this point of view, and it's interesting read. And also, and I think, you know, so let's talk about this first part, which is the situation of areas which, you know, they feel like the executive area for incubation seem to be at odd with the, the structure of the areas projects where, as we heard earlier from Steve and they have different projects within Harry's itself. And each project is I mean all the projects are not the same level of maturity. And so they are not sure how to handle this situation. So, I don't mean to, you know, respond to to answer for the whole TSE obviously but let me start by saying, we need to be very clear and I know it's not. It's basically intuitive, but the status, as we've said repeatedly in the past, when we're discussing the executive criteria actually from incubation is that, you know, the status of the project has to do with the maturity of the project and the way the community is and not the maturity of the product. And so that's absolutely key. So, when I hear Steven said earlier, well, some parts, you know, some projects within areas are not anywhere as mature and others. I'm like, well, the fact that they are not ready for production is irrelevant to to this question as whether the project, you know, is entitled to to be moved to active status. So we need to be to be, you know, clear on that aspect and hopefully, you know, I mean, as you probably all know we are discussing badges. And if we have time, we could talk about this although I'm not sure we'll have time today. But there is, you know, great proposal done or put together on badging. And we may, you know, eventually move away from this status altogether. And but I don't know that it will help in this regard for that matter. But so I'd like to hear from others, you know, how they feel about this situation, you know, of areas and more generally speaking, you know, say a project. You know, having different projects within itself, and you know, at different levels, how do we handle that from a TSC point of view? Do we focus on, you know, what they have at least one project that qualifies therefore we can essentially say yes this project, you know, can move to active status, or do we say no, every one of them has to. I'll share one more piece before giving the microphone is that, you know, if I think of fabric in which I'm involved, you know, it's pretty clear that we've added other sub projects, you know, there are repositories that get started because we want to develop new path, new tools or whatever. And clearly, at least for a while, those can be fairly experimental and nowhere near the same level as the rest. And I don't think we should say, oh, the whole project is no longer clarifying as active status because now they have one of the sub projects that is completely at a different level of maturity. So based on that, I feel like it would be unfair to say a project like areas where there is this situation, you know, it stops them from moving out of incubation. So let's just put it, let me put that, let's get to the queue. So I'll run first. So I want to understand the question first here. So areas is I understand areas is a little different from the rest of the projects over there. So, can we define what project or sub project means with respect to areas and we'll take it up from there. Okay, let me let me give some context or why I'm asking this question. So let's say if areas is going to be a framework which is going to provide all those capabilities which we which we see in the agents right the current maybe it's in Python or the agent which is implemented over there. And if it really follows a spec, then we can just the project is called some any it could be implemented in any language of choice could be using any underlying DLT for that matter. As long as it follows this spec, then we define that as a project under areas. And is that how we are defining a project over here, or how are we categorizing or how are we defining a project or a sub project. Right, so let me just say, I see Nathan is on the queue next so that's perfect because I think Nathan can probably address that point but before we get there, I do want to highlight again. You know, we have had many discussions about, you know, this notion of projects of projects and whether we should recognize this and all. We said, you know, for better and for worse, we said we're not getting into the business of how each project gets organized. If they have some projects that's their business from a TSC point of view, we look at them globally as one project. So, you know, obviously, in this case it raises an interesting question which maybe kind of makes that less so obvious but that's what I think we are facing. Nathan, please. I think that the, there's kind of two sides to this discussion that I find really interesting. The first is, we want projects that have lots of diversity. We want to let lots of people come participate and write code the way that they want to scratch their own itches so so to speak. And so, allowing lots of people to do things in different ways and try lots of different things even if not everyone in the community agrees is kind of part of the premise of, in particular how areas has been organized. And that has led to more diversity within the project and a lot more contribution. The other side of this coin is we want the project to have a cohesive theme. We want everyone to be working together on the core use cases. And that's where we have the areas interoperability profiles and we test against a common spec, and we try to enforce, at least to some extent interoperability at least in that generalized sense. And this leaves us with this kind of interesting question of how much the same do all the frameworks need to be. So diversity is okay and how much do we all need to be doing the exact same thing. And we want to create a situation where people can try out a lot of stuff, and, and people can come and participate the way they want to, because that helps grow the community that helps make it more useful. And at the same time we want to have some back pressure that says, you know, you need to come conform and be part of what's going on in general. This is kind of that same struggle as Arno describes of what's the sub project what's its own project how much do we push and force that conformity. There's how much do we give people some space to try something new that might prove itself to be much better than what the rest of the community is thinking currently. All right, so does that help. It does answer part of my question. And those I still feel so I saw chart I'm seeing chart as well. So where Tracy is pointing out that we should really treat areas as a set of SDKs working. I mean, it's a project where we have different SDKs written. So on on that understanding right so when we have to consider the project as mature in this case, for example. If I have to again take up example of fabric for that matter, we know fabric has the core components which is available and then we judge it based on those things those parameters. And then there are SDKs available in multiple languages which all confront or follow the similar approach, or at least it has those agreement points saying that as long as SDK implements these features a B and C. We say it is compliant with fabric so it's a project of it. So just because fabric is in a maturity state doesn't mean the new SDK has to start with the same state. So similarly I'm still unable to understand the project and the subject division within areas. And since it is completely distributed in the sense that each, each implementation can have its own spec. So that's, we still need a common grounds on which to consider a project to be mature. For example, are we considering a Python implementation of areas to be mature? If so, then what are those parameters can we can we list them down so that let's say the go framework gets more stabilized can we compare it with this. So what are those points which what are the points which we need to map it against. How we define them. So could I could I respond I put my hand up. I'm not sure if Nathan was there but I'd like to respond. I think he forgot to put his hand down so go ahead Steve. Okay. So two things. One is just a note about what was just said which part sub projects use different specs. That is not the case. The core of the project is defining the the specs the RFCs and then having them all follow them. Different projects have gone with different versions of the specs at times. So that doesn't enable interoperability at that time, but all are progressing on the same specs in the same direction so that's not an issue. A very practical impact of having the word incubation on Aries is that people come to the hyperdegenerated community, knowing about Indy and Aries, and they look at Indy and say oh that's active whereas Aries is incubation so I'm going to just go to Indy because it's obviously more mature. The problem that creates is they are apples to apples of course. They're two different things. One is built on the other, but it causes a derailment and a misunderstanding in the community of people arriving. They go to the wrong place. They do the wrong things. They spend their time doing different stuff and it causes problems. So that's the very practical side of why I'd like to, you know, one reason why I've been pushing for a while to A, adjust the read means that people arrive too so we've done that. But we really haven't picked up this idea of transitioning from incubation because we have different thoughts of what does that mean, different understandings and that's what I'm trying to surface here. If the answer is just we need to put an application in as an Aries project to the TSC to say hey we should be marked as active. We can take that as the action and go forward. So I know that offline, I mean, we had a bit of an email exchange and write pointed you to the process to do just that. And I can only encourage you to really have a close look at this and do the, you know, go through the exercise of saying, okay, you know, where do we fail the executor. And that's where the, you know, the analogy with fabric doesn't quite work because fabric is a, you know, it has a single artifact essentially that it's producing now there's a bunch of other projects and, and other components to it that is, that is that make up the entire community and so on but, but fabric itself is the thing, the artifact that gets released. It has a number a single number on it and so on Aries is not like that at all Aries framework go has versioning Aries cloud agent Python has a versioning and that's where we've struggled to, you know, even think about that but your point is absolutely what we think and which is although we are aware of it and we've at a superficial level read through the criteria and then and struggled with it. I think the answer is we just go through it in detail and just say, we're going to pick the most mature framework or two frameworks and answer it for those and and submit. That's exactly what I was going to advise you to do, because I think it is doing and you explained it well earlier, you know, it's clearly doing a disservice to those, you know, project that are within Aries, the Aries umbrella, to not be seen as you know, in the right status. So, and, you know, for better and for worse, the current process we have for this status, you know, goes to a review by the TSE, and it has it's on the flaws, but at the same time it does provide for you know room for discussions and I think in this case, you can definitely make a case for why it should be considered, you know, qualifying for the change of status so I highly encourage you to look into it so with this being said I mean we only have so much time so I would like to switch to the next question that was also raised as part of the report that we heard Steven touch on that aspect, you know, he talks about the standards or the specifications they are developing as part of Aries, and it raises the question about, you know, does that have its place within hyperledger, and is that, you know, the right place. And if you've read the email from Brian, he makes it pretty clear, you know, that the initial intent was clearly not to have, I want to say standards work right specification development work happening in hyperledger and leave that to other organizations. And one of the reasons is definitely a legal reason, because standards work basically requires a pattern policy and a different legal framework let's say than what we have for open source. And if you start developing standards within the framework for open source, you might actually encounter issues down the line. And so the, the intent was well we're not going to get into this there's plenty of further organization that already working standards. So there's no reason we should do that here. Now, I know that Aries actually does it. And so that raises the question, and you know I give them credit for bringing it up to the TSE say okay, how do we deal with this, you know, and so obviously, I don't know that we necessarily want to tell them to stop doing this, go away and do that somewhere else. But this is a real issue we have to discuss. So I don't know. Yeah, Sam. So some additional commentary on this and this is actually a conversation I had a bit ago with with Brian. We have multiple forms of this happening. And the notable thing to bring up here is is the did com effort that is now a working group in the decentralized identity foundation, and that came about as a result of interest outside of the Aries community in using the did com standard. And, and we ran into this issue where, you know, for defining interfaces for use with within Aries projects. It's not an issue. If we're, if we're trying to go broad from that perspective then it really needs to find another home. So this gets a little weird in the sense that there are times where we have talked about interfaces within Aries projects, and then there's kind of fair amount of interest for people that want to use those outside and, and that's okay. But, but it starts to get into that weird area, where we're sort of seeking homes for things and so I just wanted to highlight that we have these two forms now we have, we have discussion that's happened just entirely within the Aries community so far, and pieces of it that have actually moved out into a different organization. And with those conversations happening there so I don't know that that gives us an answer, but it's a little more color to the, to the, to the situation. Well, I want to add one more thing to that and that is when standards are not implementation driven, they tend to get very disconnected from reality. And one thing that we found out of the stuff that's come out of the Aries community is it's much more readily codable and usable than a lot of the stuff we're seeing out of the other organizations where it's not attached to any implementation projects. So the closer we can get to the implementers the better. That's not to say that it has to happen inside of hyperledger or inside of Aries per se, but it means that that divorcing the standards work from the coding project has had a lot of symptoms of dysfunction in the past. Yeah, I had a quick question for Sam. current that what happens if you do move they did calm stuff out of Aries, and a bunch of non areas people come in and start moving in in directions that is contrary to the Aries, you know, mission direction, whatever. I mean, are you prepared for that kind of thing. I mean that's a really important question. And so let me tell you what's happened and what could happen, because I think both are relevant. What has happened is that the experience of the areas community has proved invaluable in the diff effort of there are a bunch of areas community members there involved. And there's it's been really nice to Nathan's point to say, in our experience in what we're calling did come v one which was, you know, grown inside of areas. This is true, you know, turned to be profoundly true and we haven't ever really received pushback about the things that the areas community has learned. I have to say, as a note, I'm very pleased with the direction that that the effort is going in that working group, and, and I see good things coming in the future to the second point of the piece of your question. And if that effort sprouted legs and walked off in a totally unanticipated direction, and the end result was something that was found not to meet the needs of the areas community, the areas community has no actual obligation to use the output of that new effort. One of the things that we did on purpose is we, we, we didn't want to stop the forward progress of the areas community simply because a new effort had actually begun. And that is true, we have continued to develop things and move forward as an areas community, though we anticipate and look forward to adopting did come v to because it is going in a direction that meets the needs of the areas community. So, if a project sprouts wings and flies off. There's actually no, you know, the areas community can say well that didn't work and that we can continue to do things within the areas community to serve our own needs. Does that answer your question, Dave. Yes, sorry, trying to find the meat button. Yeah, that totally answers it. I guess the answer is if that happens awesome if it, if it doesn't meet your needs then you'll just make do right you'll do something else. Then I had a follow up question. Have you guys considered the diff I mean it seems like the natural partner for standards to hyper ledger right. It is, and this is an interesting conversation because it depends on what you mean. For example, the diff has a credentials working group. So, as did come v to reaches maturity. It would make sense that the, the credentials and claims working group over there would actually say, Okay, hey, let's, let's grab the credentials protocols that have been, you know, developed inside of areas and then let's use that as a foundation for the next thing. That builds on top of that. The question about whether they're actually want that as a work item or whether that's something that they desire is still open. I think the problem that Stevens getting to here is what what is the what is this process actually look like. Do we have to reevaluate these one by one as they come up or is there some sort of like blanket understanding or thing that could apply to all of these, you know, different protocols or other protocols not just around credentials but around around like asset transfer and gathering signatures and all other things that could expand into this and so while I think we have maybe a good handle on like one or two of these things. I think the broader question remains and part of what could happen here is that we end up with a group. So the diff that would not be an inappropriate place that that actually takes over the coordination of these protocols generally speaking, which would leave the areas community to focus on which ones we're going to target from our code bases. Yeah, and implement them and implement them that that's already true like the areas interoperability profile version two that we're working on actually has external pointers to things developed elsewhere. So the the the credential manifest format at work at the deficit is one example of that with the same organization that and so it's not it's not a bad thing to have the areas folks pick an external thing and say that is a thing that we're going to include into the software development of our projects. So Sam to take this out of the TSE context. It sounds like we probably should have at least one follow up meeting to discuss the direction like it's almost like we need a free trade agreement and framework for how to move stuff from hyper ledger to diff, you know when it becomes too specky. Right, and I don't want to take up all the rest of the TSE time. So maybe I'll follow up with you and we'll have a bigger conversation because this seems this is starting to move into community architect land right like we need to have a bigger discussion with more people. Well, I think that's kind of the question, the heart of this. So to me, I mean, it's like, well, I would hate for us to say, guys, you can't do this, you need to stop it go to the somewhere this somewhere else. So my inclination is to say, no, keep doing this. And we should have whoever maybe it's Andy up the grove, you know, somebody from the Linux Foundation look into what we need to make that safe. Right, so that from a legal point of view, we have covered all the bases and that eventually, and let's be clear it's not about developing a standard per se because we're not going to declare we're doing standards, but we can develop specifications that are subtle, but subtle, but important, and that eventually those specs could be submitted elsewhere for, you know, standardization like W3C or other places, but we want not to have those specs be tainted in any way that will make it difficult for organizations like this to take that work over. So I think that's really what I think we, you know, we should look into and maybe sometimes it goes to diff, maybe it goes to elsewhere, that to me is not really the issue. And I'm happy to leave it to the community to figure out when they feel like, okay, we should bring it up to a different venue. But I feel like, you know, because they are working on the code, as we've heard, they like to write the spec at the same time and I've been there, I totally relate to this, you know, it's much nicer to develop your specs at the same times that you're doing implementation and can doing that feedback loop to make sure it makes sense is not just a piece of paper. And so I think they're inclined to keep doing this. So I would hate stopping it. I would again, you know, prefer that we focus on making sure they have the right framework to do this. Is there anyone else, Nathan, you still have your hand up. I don't know if it's from before. So this is I re raised my hand. I don't want to solve with policy what we can solve with patients. In particular, it took a long time to convince the broader community of kind of this agent interaction model, and that it wasn't really just a rest API and we could move on. And to get the spec right I think Arnold's intuition of, we've got to let let the organic process work and we need to put whatever guardrails we need in place in order to make that work. And that includes saying just anytime something looks speckey. There's a different repository right here for you and they've, they've agreed that we can just have that sandbox kind of as a permanent fixture of the project. We're not, I think it's picky about how that has to happen only that there is a positive forum where it's safe to make sure it happens. It's not that easy though, Nathan, right, because to put stuff into the diff, the contributors have to sign a contributor agreement. Don't I know it. Yeah, yeah, so I just don't want to gloss over some details. It's not that simple but yeah, it could be. It's just, yeah, there's extra roadblocks. I agree with you Dave but this problem has been solved many times and people like Andy at the group, make a living out of solving these problems. So, I don't want us to just say, Oh, we can do this. I think, you know, we, that wasn't my point. That wasn't my point I just didn't want to gloss over details for people here who haven't, you know, who haven't been in the nuts and bolts of the these kinds of things in the past. So to your point, so to your point Dave, I think that we can. I think that one of the things that hyperledger could do to assist this in the healthy for movement of communities is actually develop a process or figure out the right tooling in order to make that process of signing agreements, etc. So that this is easier to do in the future when it occurs. So, there's in a multi organizational scenario there's different pieces of different organizations do and I think that the diff has actually learned a lot about how to like sort of gain a work item, or a working group around something specific. And I think that one of the things that hyperledger could do is is make it easier for other organizations to build processes off of things that were born inside of hyperledger. And to avoid the complexities that come with with being standards creation based. I don't know exactly what that answer is but we've we've been through this once, and I think that that as we sort of pay attention to this, it might be something that hyperledger could actually do is basically sort of have a known ramp to that process. I think it is clear what has to happen and we know what you which crank to turn, and that happen. That's a really great suggestion it's like, we could build the recipe so next time we see this like oh we know what this is. Here's the recipe for how to deal with it. Right, which was someone comes and says hey we want to build standards off of this hyperledger thing. You're like, great turn this crank, and pops the foundation for you to build upon. Yeah, that's actually a really good idea. Good suggestion. Thanks. Okay, so I've only heard kind of supportive statements. I wanted to ask the TSC, those who the many who've been silent today that you know, whether anybody has, you know, objection or, you know, feels, you know, unsure about this direction. Because otherwise, I would say that, you know, for me the outcome of this discussion is to ask the staff to look into what it would take to, you know, set up the right legal framework for this kind of work to happen safely. I wouldn't pull talk, I mean I wouldn't say that this is standards development, we can call it like the pre standard development or something like this is legal room there but you know we have to be careful, those words are really loaded. And the problem is that every open source project hopes to develop hopes to become the standard. Right, so we also have to sort of tamp down the aspirations of every new little project who thinks this is going to be the global standard in X, right. I think you'd have to. With one specific implementation and like interfaces protocols that you want others to implement. Yeah, I get that I get that. We're out of time. So we're going to close on this. I haven't seen anybody raise their hand to my call for objections or concerns, expression of concern so I take this as an approval. And we'll discuss this further with the staff and see what Brian says. So with that said, let me close the call thank everybody for joining us today. I'll see you again next week.