 All right, welcome everyone to the April 28th Hyperledger technical stern committee call. As you're all aware, two things we must abide by the first one is the antitrust policy notice that is currently being displayed on the screen. And the second is our code of conduct, which is linked in the agenda. So the first announcement that we have today is the standard one that we have hyperledger dev weekly developer newsletter goes out each Friday. If you have something that you would like to include in that please add a comment to the wiki page that's linked in the agenda. The second one is the hyperledger global forum happening in September. And the CFP closes tomorrow. So if you haven't yet got your CFP submitted, please do so now. And if you hadn't noticed, there are also workshops that were added on the, I guess, Wednesday so maybe now this is September 12 through the 14. If you have a workshop that you'd like to present, please consider adding that as a CFP as well. Any other announcements that anybody has. Okay. So there's no other announcements. The quarterly report fabric came in last week I see that there was nine of 14 folks who have reviewed that so far I did not see any comments that came in. Any comments at this point about fabric that we should talk about in the CSC meeting. Okay, so no, and then also the sauteed report did come in already. It was due today I think it came in yesterday or the day before. There have been a few people who have had an opportunity to review that. But if you haven't, please do so this week. And that's all we have for the reports. So as far as discussion. I know you created a. Issue slash PR for talking about what happens when projects don't have a maintainer policy, what the default policy should look like as well as what we should do if there is an activity in the repository to any of the repository so did you want to walk us through kind of where we're at with this PR. So I phrase this a general inactivity policy, and it addresses two aspects of inactivity at first, when a maintainer goes inactive and when a repository goes inactive. So the proposal for the maintainer inactivity policy is there is, you know, the last line gives the out. If a project has its own policy use their policy. If they adopt a ridiculous policy TSE will probably push back on it, but haven't seen any ridiculous policies yet. So the default policy if no one specifies one and we probably need to figure out what this timeframe is, is that if a maintainer hasn't contributed within three four six months. They'll be retired from active active maintainer. And most projects have this date called an emeritus maintainer people who used to have privileges, but no longer have them but they want to you know respect their contributing role in the past. They list them as emeritus. And when you become emeritus you lose all your maintainer rights privileges responsibilities accountability and all that that goes along with it. So as part of that, we would take you out of the rail with GitHub groups. We would remove the ability to write codes and repository to have your reviews approve them you can still participate. But what's what's being removed is your right privileges. So we define, you know, basically that what we're going to track is what GitHub can attribute to activity, and they can track a lot you do a comment on one issue and it marks it is active. So to do nothing for six months I think for three months or four months or six months and I'm, I'm personally leaning towards six months but I'll let the TSE will vote and figured out and workshop it together. If you haven't done anything as much as comment on an issue in six months, you're probably far separated from the project so it's probably time for you to go. So there are some clauses for what happens if this sneaks up on you because you're doing another project. If you work with it with a PR for a week you'll get an ad mention, and it'll say hey we're moving you to emeritus and if you say totally forgot about this I'm going to contribute. You get one three month extension to continue contributing and maintain your privileges. And this is there to be nice to people who get caught up in other life issues or other work issues. You know, it's the more than gentle nudge that you need to contribute or you know we're going to, you know, you're going to need to turn in your right privileges. And also one final clause that just because your marriage is doesn't mean you can become maintainer again, but it would be through the same process. So that's a quick overview of maintainer policy. The repository and activity policy is the same but different. There's a separate couple of reasons one the time frame is 12 months. No releases in 12 months or no commits in six months, but a continual rolling extension is something that might be needed, because there are projects out there who are basically, you know, the frameworks and they almost never change. And if they don't have any dependencies there's no security risks. There's no requirement for it to need to be updated. So as long as they keep every 12 months every six months saying hey we're still alive. I see no reason to force the the roll away of the repository. And how do we done as it would be marking it as archived under GitHub which can be undone. But the goal here is to put some sort of a, you know, the garbage collection on repositories that got forgotten about or moved on from so they'll clutter up new covers when they come in and say well let's look at all these basic repositories and I have no idea which repository works being done on what's relevant what isn't relevant. So we try and keep it fresh so that the repositories for project need to be vouched for or worked on every 12 or six months or whatever standard we propose there. So those are the two aspects of an activity. And basically you know to keep a, you know, keep keep keep things tidy and put some objective standards to it. Any comments. So this is another question more in regard to who makes the call when there is contentioned for instance, I mean, especially the last part right the repository next video. It implies that somebody is going to make a judgment call right. So, what we've, what I've seen so far is that you can run reports and you'd use the report from GitHub and right now it's the hyper ledger staff has best access to those commit logs to generate these reports. So it would either be a TSC responsibility or be hyper ledger staff responsible and we should probably clarify that in this policy that's a good point. That's my point exactly. Thanks. Arun. Hey, can you hear me now. Yep. Now I can hear you. Okay, so thanks for putting up this proposal so have potentially few questions and open areas that we still need to address with this proposal right for instance. I guess I pointed out that in the proposal in a case of, let's say some maintainers maintaining multiple projects and not just one. So it is true for some of the projects that we have for instance. There's no exact sort of and great for instance right so the maintainer site, the group is still the same. And I know they work on some of the projects, when it is time for that project otherwise for those repositories it's mostly untouched for a while, unless somebody else comes in and add some additional patches or it requires some maintenance activity to be done because the dependency that alerts that comes in. So otherwise mostly that there's no much contribution going on into those I don't think so we can specifically put that in a time timeline in the sense we cannot say this can be done in three months or six months. And that was my point as well in a way. The time boundary for such topics is difficult so probably there should be another clause alongside the time boundary. I'm not denying that time boundaries is a bad idea. Maybe we need additional. Let's say option alongside that so that we could better measure it the intention over here. So that's one what standard would it be and what it applies with repositories or maintainers. It would be both so the reason I'm saying yeah that was about that was my second point about repositories so let's talk about some of the projects that do not get much updates for a longer period right for instance. A project that is fairly stable or the SDK deposit race, which, unless we think of adding additional feature capabilities, or one of the dependency that SDK depends on itself has not gone bad. I mean, there are very less instances where we would think of considering adding a new patch on top of it. So let's also go to, let's say, the consensus library implementations in some of the projects. So for these, the updates may not happen. Sometimes may not happen within three months frame, or maybe we cannot time bound we cannot put it in a time boundary. So that's one of my question if we can address. One thing through the repository there is no limit to extensions. If every 12 months you say no really it's fine, then it won't be archived. And I think that addresses the issue of the judgment calls and what's a judgment call. And it's what this policy says is every 12 months, someone needs to pass judgment on it from within the project saying, yes this is good yes this is being kept up to date or you know what it's time to clean it up. So versus the maintainer, which is kind of a forced outing, because there are security risks, but there's also a security risk clause repository that if your security vulnerabilities are piling up, then it needs to be closed. There is there is judgment calls and the timeframe we keep it like 12 months, we don't have to do it as often. And I see a room for this hand down. Peter. I don't have an alternate to time. I think I like the timeframe of three months, but in addition to that if we can have something else, which says, if there was no update done at all for the project and we cannot expect you to contribute something so time doesn't really count in such case. Maybe. Can you write, can you write a proposal for what that might be and put it in the PR. Sure, if we can discuss and I'm happy to put it out as a comment. I mean I we need a specific counter proposal just you know it should be something different. Doesn't move this forward. So, a specific camp proposal would be best. Peter. Yes, I just wanted to say I like the timelines. I also agree that the longer ones should be picked so for maintainer activity instead of freedom so I would also go with six months. And just a quick idea would be specific on that renewal or extension for projects where there's just happens to be a legitimate need for them to be the way that would actually trigger the rules. Could we or should we add questions for this on the quarterly report so that it's sort of an automatic thing that we notice instead of instead of it going the way where we notice that they haven't contributed anything and then we try to archive the project and then they say oh it's it's all good because of this and this and this. I'm glad of that and should they be able to just say this somehow on the quarterly reports proactively. That would also apply to labs as well and I don't know the lots of quarterly reports. Okay. Yeah, that makes it trickier. Okay, well that's all I had other than that I really like the proposal, every. So thank you for that. Cool, Nathan. First, I say I agree with Peter on the longer time frames are typically better because you know it's easy for things to get. I think the administrative burden of trying to do things on a more continuous cycle can be caught quite high. And I would also say that I like the idea of bundling the question of what repositories are active or not active in with other projects that we can. The idea of once a year somebody from the staff says how's your project doing. How can we help you and by the way which of these repositories we retired feels a lot better than kind of a random email showing up that says you better do something or this is going to go away because at least a lot of the projects I've worked on it's easy for those emails to get lost in the shuffle, there's a lot of other things going on at the same time. And I also like the idea of maybe having the ability to have some sort of like standing orders in repository for example, if a component if a system is broken out down into multiple GitHub repositories. Looking at the activity and aggregate is sometimes better than looking at any one individual repo, because one of the repositories might just be glue that hooks everything else together and it might not need to be changed. I think this idea of, you know, well, asking it 12 months covers that pretty well. I don't know that we need to do anything more than that. But I think it would be good to clear space for someone like right to be able to say, put a note in the in the in the main maintainers file or put a note somewhere that says what the, what the decision of the maintainers is on this one. That way I don't have to bother asking more often. Something like that might make it easier to do the work. And then the last thing I was going to say is from a PR and a talking about the project standpoint I like calling emeritus maintainers, maintainers, and I think for the most part with our projects. The emeritus maintainers are folks we'd love to recruit back we haven't had very many folks who, you know, we'd rather they never came back, I think for the most part, those emeritus maintainers we like to say, if they were to show up and start contributing, we would put them back in really quickly. And I think that the text of this covers that quite well. I think the only other note there is sometimes there's someone that's been doing a lot of work with the project who I would treat as an emeritus maintainer, even though they never went through the project cycle. Sometimes it's because they were someone who did a lot of code contribution before it became a hyper ledger project, or sometimes it's someone who's done a lot of contribution to the project outside of its code. For instance, someone who's worked with the education and documentation group and done a lot of advancement of the project without necessarily contributing to the source code repository directly. Is it okay if we just treat those folks as emeritus maintainers as well. My feeling is, is it is, but it's kind of a, how does that each particular project want to deal with that. And that's on that project should have its own standard on that, and it opens up another can of words do we need to standardize the maintainer life cycle way too deep for today's discussion and I think we would need to see if something's not working needs to be standardized before we go down that path but yeah, all good points. Tracy. Yeah, so I think it's important to note that this is a default policy if the projects haven't defined their own policies. So, plus, this policy could be overridden if a project actually writes their own policy. So, some of the concerns that people have about this project is somewhat special and so therefore might want to have their project out longer. You know, then, otherwise, I think could be taken care of by just overriding the default policy that is being proposed here. I also because of that would suggest that three months is the appropriate time because otherwise you're looking at nine months that somebody could possibly do nothing be considered a maintainer on a project. You know, three months plus an additional three months for the total of six months. So I will be the one who says that, you know, everybody else is going towards six months is the way that we should go for that but I would suggest three months as the default policy. And if you don't like that you can override the policy, because I think in general we would want people to write their own policies not use the default one, because I think each community and each project is going to be different in handling things. And I would say that if people are not responding to the PR that their repositories going to go inactive and they're probably not even looking at that repository of the PRs and issues in that repository so I'm perfectly fine with saying like, why, why make this more difficult, let's just make a PR if people don't respond then after, you know, I personally I think we should put in if they don't respond after a week, then it gets, then it gets resolved that PR gets merged. So, those are the points that I think I have to make on this particular conversation. Yeah, hi. So, I think, other than the timeline, we should have another parameter like how much the particular repository being used, number of downloads, because I can take an example like yesterday I was looking at one of the project and I see is archived. So maybe in terms of the user kind of low confidence that I should use this repository for my projects or because archived is up to date or not. So, great kind of maybe changing the status of archiving is we can consider the other parameters like what I'm mentioning. One of the things about archive is it's an indicator that this project's not being maintained. So whatever state we would go to we want to make sure that it carries that same weight up. You're using a maintained code. So I don't know how best to communicate that and get have other than archiving at me. So, okay. Arno. Yeah, I totally agree with what you just said and in fact my comment is somewhat related to this, which is, you know, and I've heard several people. We all kind of seem to naturally want to give people more time rather than less. But there's a downside to doing this, which is what we communicate to the, to the, to the world to the community out there. What we shouldn't do is just because we're trying to be nice and give you plenty of time is in fact, let projects be inactive. And the community not being aware that this project is actually not really being maintained for the development and so on. And people will come, they will start using it, they will ask questions, maybe submit even PRs and those things don't get even processed, because there is actually nobody, nobody in there that's actually working on the project. And so I think we need to balance this, you know, with this idea that well, it doesn't hurt, you know, we can let them be. Yeah. And to add to that, how do we communicate that in a really constructive way because, you know, I don't, I'm a little worried that our repository policy might conflict or force our hand in an uncomfortable way on the project life cycle policy. If we have something like an add on tool to a blockchain that's really much less active and maybe rightly so, I, it would be really hard if the, if the maintainers and repository inactivity policy forces all the code into archive. When we haven't finished the life cycle of the project or finished doing the retirement of the project itself. I think I like the idea of forcing the issue, because it can kick some of the maybe users of a repository to take action and participate in pull requests and make sure that the security fixes are being done. I just, it seems like there may be a gap there that we have to address if one of these projects actually goes into severe inactivity. And I agree there's other metrics which you look at like, you know, your, your, your penances are the dependencies up to date using up to date versions that don't have active CVs against them. And I'm wondering if that might be a better indicator that it's time to archive a project than just the time frame because if you have no dependencies and it is one thing really well like say, calculate the check hash. No one can sit open forever without any modification because you know how often our security issues posted against the hashing algorithm happens but it's really rare. So my quick thought of this policy. I don't think it's ready for vote today. I'm going to split this into two separate PRs. Because I think the issues of maintainers and repositories are quite orthogonal and how we judge repositories and I'm going to work on the maintainer one first and try and move this forward again next week for some iteration. One question though is that I think we need to get a better feedback on sooner or later is whether this should be a Hyperlegic Foundation staff issue for the maintainer default policy, or is it a TSC default issue. If the staff could give an opinion on what they think it should be. Hi, I'm staff. Hi staff. All right. Hi. Yeah, I'm, I'm. I think that the data can come from staff, because I'm just for full transparency I get this data from the audit log. So, I don't want to, you know, give broad ability to read the audit log. It's fine if the data comes from staff. If the data is then provided to TSC members, or specific TSC members to make these decisions that's fine, but I think getting the data for the near future is going to, it's going to remain a staff activity. Cool. So I'll revise this for next week. I think the two things to think about would be to one have a formal vote on the duration and then I'll update the stuff on the report. So I'll get this right for next week and then we'll iterate on repository. I'll post which PR I'm going to post that to after I get the staff stuff fixed and if people could chime in with their ideas because it's it's a much deeper well I think than the maintain our policies, mostly because we don't have a default repository and activity policy. So I did say in chat. I was looking into. Well, I said it in the TSC channel on discord. I looked into it and Kubernetes is much different. It's not as much different project, but it is much harder to become a maintainer to get a commit bit in a Kubernetes project. And it's much harder to lose your commit bit. I think if we transitioned over a longer timeline to something like Kubernetes policy about what it takes to get a commit bit because right now they're free. Then we could look into something like they're much longer 18 month timeline. So that's just food for thought. I agree in the standards for onboarding should be about as extensive as the standards for offboarding to the commit bit. So it should be reflective and equal, equal things. If it takes a lot to get it should take a lot to take it away. But Kubernetes is a very special beast for sure. 18 months is a long time but it's probably going to take you two years to get that commitment. Okay. So that's it for this discussion. So I'm not going to ask for a vote for on this today. It's not ready. All right. Thanks. Any other TSC business before we move on to the task force discussion, maybe just to point out that David did put an email out to the TSC list if you haven't already yet about some additional policies that he'd like to have us review and weigh in on. Let's take a look at that this week. Right. Thanks. So quickly wanted to bring out the point that I'm not bring brought out and now call and security task force was Friday. It's it's mainly regarding the agenda for the task force and putting it putting and making sure that we are proceeding towards that agenda. And I know in the specifically within security task force we started with something in mind and then it went all over places and probably think thanks are not reminding that in last week's call. We will focus purely on the first open question that came up and then further proposing it to the TSC in the coming weeks probably put up a proposal on that. And that was one of the topics that we will diversify the efforts that we are putting in over there. And probably there might be a new working group proposal out of that discussion. So just wanted to get a quick heads up on that. Any working group or new task force. Given the way it's going on right now it would be a new working group proposal. Do we still have working groups. They're not very active but they do we do we still do we still accept working groups that we decided working groups, new working groups are not going to be formed and existing working groups could stay but new working groups are not going to be formed. I don't remember that decision. Yeah, you have to go back and take a look at that. You might be right I'm sorry you would have to do that. Okay, I can't remember if that's what we actually decided or if that was just part of the discussion. What we did decide right is we removed the timeframe limit on working groups and turn them and the, the, the, the expectation that they would deliver some, some product like a documentation. And we said we said for things that have very specific deliverable, it will be task forces, but the working groups can remain for discussions. And so, I think, you know, what Aaron is talking about is basically we started from the, this idea of, oh, you know, I brought up that open SSF issued published guidelines on how to deal with disclosure with never TV closures. And I said we should look into what it means for us. And the discussion as Aaron was talking about is, you know, kind of leaned into all sorts of like security related issues, you know, into watching technology. And so we thought, okay, this is a broader topic that, you know, probably deserves a working group. It's more discussion based on what we're thinking about. Okay. Yeah. Okay. Yeah, because I remember at some point we had talked about like technical interest groups, right, replacing the working groups. I know we didn't go there but yeah, okay. Yeah, let us know where it goes. And I will also see if I can round up the discussion that we had about working groups in general so that I can at least respond back to my own question. Yeah, I mean we could possibly create a different task force but I think the problem is that, you know, the timeline is quite extensive here we don't really know how long it would take to cover the topic so that's why I thought working group was most suitable for us. All right, sounds good. Anything else that anybody wants to bring up. No. Okay. So yeah, last time we talked about the project camera's website revamp. We had a couple of action items. One that Jim took for us, which was this functional grouping proposal that he's come back with. I just wanted to discuss it here with the task force focused right so people might not have had a chance to look at this or respond to this. These were the kind of tags that were specified on the website and these were the suggested tags. Well, I wanted to stop to comment. I don't know if you're done with the intro. No, no, I think, I think, yeah, I'm looking for feedback and thoughts on the proposal and if there's anything that we should add so I think we are ready for comments. Okay, so first I noticed there is two lines deployment automation, one with bevel the other was cello. I think those should be merged. Yes. Yes, good point. And the other question I had was with the, the, the firefly being listed the long cactus in interoperability surprised me, because I remember, I haven't looked in firefly, I don't know how it has evolved, but I remember, you know, quite specifically I had asked about that aspect. When the firefly proposal came up. And my understanding was that firefly, it provides more like a portability feature, which is that you can write your application independent of the blockchain framework being used underneath. But essentially when you run an instance of firefly, you choose which underlying technology you use, and you can't quite change as dynamically or connect it doesn't allow you to connect different types of networks together, which is what characters are. So I mean Jim is here maybe you know it'll set me straight I don't know it, I was very surprised by that. So, yeah, and I remember Jim, you and Angela. Yeah, Angela, who brought it up earlier. Maybe I can clarify a little bit. I think it's, it'd be great if if Peter can comment on this as well. One of the options to do interop is in fact, just through a centralized component that coordinates events and transactions across the chains, listening to events for request on one chain and then submit a transaction from another and vice versa. And that's exactly what firefly does, which is a component that you deploy and control that can be connected to multiple, multiple underlying blockchains. We have most of the demos you see it's only talking to one blockchain but under the cover it can do multiple blockchains. So more and more firefly will be used in that mode. So it naturally becomes sort of a centralized way to do interop. And there are decentralized way and trustless components to do interop, but going through a centralized component to coordinate across different chains that's a pretty legitimate way to do interop. And that's, that's not what other people think interop is. So we'd love to hear from Peter. I think you just touched on the right question is, you know, what do we want the word interop to be used for right. I mean what you're describing to me is not really interoperability but maybe I'm wrong. This doesn't fit my expectation. I mean, because what you're talking about this kind of centralized interoperability, any application can do that. Yes. Except when you do that you have to write a whole bunch of stuff that talks to those different chains and far fly because far fly makes that very easy. It makes it a pretty, pretty good choice to do that kind of thing. Okay, I think this is overloading the term in a way that, you know, kind of. Yeah, with me but I understand your point of view. Honestly, the main. The message around far flies connectivity. But it happens to fulfill a interop requirement. But if we think that confuses confuse people. Honestly, I'm not, but it seems to be more than one. People that express concerns with this. We'll have to hear other people's. Not around this. Maybe we could add another category called integration, which it would be to me at least that word implies more of the basic mechanical feature that was just described and then interoperability would mean, you know, the broader scope and what would expect it to be. And then that way. People will still understand that it's adjacent, but then there's different levels. It's like a scale. So interoperability would mean, you know, all the things that we're expecting is from cross-chain asset transactions being the pinnacle of it. That's my personal opinion. And then integration would just mean things like data sharing through events, event subscriptions, or data copying, things there. It's fairly mechanical and, you know, as Arnold said, well, it's pretty easy for any application to do this, but still there are tools out there that will make it much easier. And they deserve a category that we could call integration. Just an idea. Yeah, I like the term. It makes sense to me, maybe we could call it connectivity slash integration gateway and lump those together there. Yeah, maybe a follow-up. Do we want to clarify cross-chain interop as being focused on trustless models only? To me, interop covers all of them. If you look at technologies in the open, POA bridge, for example, POA network, the bridge they're using, which is a pretty popular token bridges, right, that hooks up Ethereum with other chains. The component they use is exactly the kind that Farfly has, and it's an interop component, but it's a trusted implementation. Because the cactus community want to focus on trustless only implementations, which I know, you know, the current cactus code base with YUI, Weaver, all tend to focus on. I think that'll clarify a lot of things. You know, just focus on chain verification of states in another chain and don't rely on any trusted centralized components anywhere. This will just, this will clarify things and not cause these kind of confusions. Well, for cactus, I would say the answer is that we want it all, so not just trustless, but also trusted. And then different levels of trust, you know, all the full spectrum of it, with as much flexibility as possible. So that's why I was thinking that the interop category could be a super set of the integration, but I'm also open to somehow re-vectoring that, but it's not. So if we say that cactus only does trustless, that will not be true because they're aiming for a wider scope. That really makes sense to have another role then. No, never mind. I was going to propose cross chain, trust the interop and then have for life in there. But I don't know if that improves things. Maybe it could. I mean, the only thing I guess we want to try and avoid is having a very large number of categories because then it loses value. But maybe this is just that one exception where we could just go for it. So I'm personally not against that. I don't know about the rest of the team here. I mean, we do have three different, well, I'm sorry, two different DLTs, right, tags, if you will. So maybe let's try this, Tracy, add another role behind below this, cross chain, trust the interop and then put firefly in there or cross chain interop. Yeah. So this, this document is available for concurrent editing. So if anyone would like to help Tracy with edits, you can just jump in. Yeah, this is the, this is the TC meeting minutes. I'm just reading it and it's directly there for anybody who's interested. So if we do this, do we need to add the word trustless to this one then Jim. Yeah, let's go ahead and do that and then remove firefly from that role. Does that work for the folks who had concerns. In my opinion, cross chain trusted interop and integration gateway mean about the same thing. So that seems like one road to me. I don't want to be difficult but this row and this row. Then would you put cactus in this row? Yeah. May I? Yes, please, Andrew. Yeah, to me, this is even worse personal from a recent I say this from a research point of view, this is even worse. It's even more confusing on a subject that is very delicate. It's not just even in the trusted setting. How, how would you allow rollbacks? Where are the keys? So I would go very delicate with this input. It's like saying that we can put fabric under verifiable credential credentials decentralized ID just because fabric has identity mixer support. We also have technically we also fabric sports verifiable credentials, but that would be misleading. That my personal opinion from a research point of view this nonsense. Yeah, I mean I can see your point with fabric could go under the verifiable data registry DLT right. There's actually people who are trying to make that reality by creating the correct smart contracts and interfaces to make that happen through areas, right. So, definitely, I think we, it is potentially a step too far, Nathan. Well, my first comment is if, if someone's deployed fabric is a verifiable data registry I think it's healthy for them to claim the tag, because it shows what's actually going on in the community and helps people understand what's possible. But the second is, we need to come back and ask ourselves what's the audience for these tags, especially when we have a lot where there's only one project underneath each tag. We're trying to communicate with new newcomers to the ecosystem right because it, it's okay that, you know, us as TSC or maintainers would agree yeah that tag seems seems truthful. It's not helpful if it doesn't say something to a newcomer that lets them know where they should start or what they should read, or what they should do next. I think that's a good point, Nathan, to think about who our audience is for these tags, and the reason that we're creating these tags in the first place. Jim. Yeah, I guess I'm the only goal I'm trying to achieve with this. This would be just to remove far fly from anything really to interrupt and be done with it, because it's not designed for that. What I'm trying to enable is where enterprise permission chain is today. You see, majority of the people who need quote unquote interop, picking up far fly use it and be done with it, rather than trying to do the more sophisticated cactus model, which is designed more for trusting parties trying to do interop. I think where the enterprise decentralized landscape is today. A trusted model would be sufficiently useful and likely to be adopted first. So the fall on trustless way. That's what that's where my head is, and not getting them to realize far fly can help, like, take care of 60% or even more of that task would be a shame. On the other hand, I realized looking at this right now it's it's more confusing than before. So I don't know what's, what's the best way maybe we can start with not having far fly at all and then I don't know what's what's possible later. But but I think my point still stands. Peter. I was just going to say that I can see everybody's points. I kind of agree with all of them in a way. So, that's just a really hard question because the underlying complexity of the software pieces that you're talking about is more than what you can easily express in a short little table like this. So there, it is bound to happen that there will be sort of friction points where people disagree just because it has to be simplified down somehow. And then some information will be lost. I'm not very opinionated on this. And I also feel like, because I maintain characters, maybe I'm a little bias. So, yeah, I'm totally flexible. That's it. Andrew. Yeah, I must admit this at this point I'm a bit concerned if it's true what Jim said that many are using firefly to to achieve interoperability I'm wondering under which assumption they are doing this. Are they exposing themselves to risks that they don't understand something like this. That's just the following if firefly believes to be a tool for interoperability, write down a page, even a paper to a conference, and where where this model is described in details so people can better understand what they would they expose in the F2, when they use this model that allegedly firefly allows to use that I will be it's much more we are doing a job for our, we're doing a service for our community, not just say he kept people are using it for that purpose. Good luck I hope they are using for in the right way. Peter you're so happy to end up is it just a no worse. Okay, so we have like seven minutes left before the top of the hour. I think this is a good discussion and I think the remaining question is, are there other sort of pads that people would see that we should add to this that aren't here. We don't see a hand. If you do come up with something definitely, you know, so I guess I want one more one more question sorry. I mean, I think I forget who but somebody talked about you know what is the end goal and should we I mean should a goal be to only have one category for each project. I mean, right now I think we have, we have a pretty good list. I like the categories there is one thing is indeed which is in two roles. Is that something that's really necessary or should we try to say no let's just have one. I don't think it matters actually how many. And that's why I said I don't know what the goal is maybe we don't care. I think the goal was to be able to have the tags on like this webpage. See if I can, I probably can't open it here. But you can see general purpose DLT. So, in the case of India it would have two of them right general or not general purpose but the verifiable data registry DLT and the verifiable credentials decentralized identity tag associated with it. Now, if we think that, you know, another project should have a additional tag, because that's what people are going to go to the website and look for. And then, you know, maybe we need to think about, is there another tag that we should add to this list. Okay. Yeah, so the reason I had it in both places is verifiable data registry is kind of a term that was invented. So many of the discussions I had with the maintainers of areas in India. It's not a very recognizable term as verifiable credentials or the ID, right. That's that's the main reason I feel like in the deserves those more recognizable labels. That's why, but the registry term more accurately describes what it does. I'm not against it, let's be clear. I'm just like, when I looked at the list. This is the one kind of, you know, I don't want to say oddities because it sounds negative which is not what I'm trying to convey. It's just like, you know, it's a unique case. Yes. Any other project is only in one row, I think. So. Okay. It's okay. I will have to I guess see how that ends up looking on the actual website when it goes out to see if it's too much. But I do think it's worthwhile pulling out that it is that the, it is a DLT but it also had some additional functionality built on top of it, specifically for the decentralized identity use case. So, you know, it's not a general purpose DLT so it's going to be some other sort of DLT and I think that's the name that it was given here. So, I know we're about ready to be finished with this conversation. We didn't make it very far through what I wanted to discuss. There is a new confidence page that I created here website personas which I think is this one that I would appreciate offline if people could add to this things that they think that people visiting the website are visiting it for so that we can at least have a general idea of the sorts of things that we would need to do when it comes to the website itself. And then the other piece that we didn't have time to get to is this new proposed getting started page that David and the team has come up with for us to review and provide feedback on. So maybe we can do that also in an offline fashion, since we won't be meeting again for another one month to talk through this so I think it's worthwhile to do some work offline while we have the opportunity for those folks who are interested in participating in this task force. So, with that, I think I'm going to close for today and look forward to seeing some input if you back on the website personas on this new getting started page. There is a chat channel for the project families. There is a task force that exists in discord, so please join us there for additional discussions and things that you want to add to to what you're seeing here, coming out of the work that's being done offline. So with that, I'm going to close the meeting. Thank you all for joining and participating. Thank you. Thank you.