LF Decentralized Trust TAC Meeting - 2026/09/17

Um, hey everyone, welcome to Linux Foundation decentralized trust technical advisory council meeting on 17th September 2026. Before we get started, couple of reminders for everyone. First one is antitrust policy. We do have participants from across several organizations. We request um everyone to be abide to abide by uh rules that govern u that are applicable to different states and federal or foreign competition laws. The second one uh is reminder for everyone that we welcome everyone in all our public meetings and uh because of the diversity we have be respectful to each other and um allow some time for others to express in the meeting. If you have any uh thing that you would like to bring up, please feel free to raise your hand and we can uh go in um preference order of how somebody raises the hand. Going into our announcements for the day, we do have standard developer newsletter announcement. Um a quick note to everyone that um the announce I mean the announcements that you post here be it related to projects or RFS RFC's or requesting for people to get started on a project or making a release announcement um the um the way you would express that um content is now simpler. All you have to do is go to the GitHub uh go to the link that is listed in the meeting agenda and raise an issue there and and that should be picked up in the next weekly newsletter and moving to the next section. So we u I mean moving to the next announcement item. So we do have the TC elections coming up for the year. Um the timelines are approaching very close and um I would request all the all the TAC members that uh if you know any community members that be best represented within the tag, please do reach out to them or please nominate them for the role. And um the timelines are very similar. will have elections starting um sometime in October or like early November and then going into having new packaged by um by like November. All right. Uh I forgot. So Ry, thanks Ryan for reminders. So we did adopt um that nominations are to be self nom I mean are to be self-nominated um in one of our previous years. So if you know someone um who can be best represented please do reach out to them ask them for self nomination and um we'll go from there. Moving to the uh next announcement. So we do have a working group get call and um thanks Henrik for initiating it and this is an excellent opportunity for for all of us to get involved and and get started on this collaboration and um Henrik would prefer this to be more of a kickoff call trying to engage all the participants. So uh it's not going to be like where somebody speaks and then everybody listens but it's more going to be where uh all the participants are going to engage and and discuss in a in a structured fashion. Moving to the next section. So uh we'll come back to uh both annual reports and media reports in a in a while as part of our agenda items. So I'll directly switch over to um moving to the discussion items for the day. Um so few quick reminders I know like this topic has been pushed in the past two three weeks but I I did want to bring it up again. So our the the way lab proposals are reviewed or like the lab proposals are submitted into the community that process has changed and um earlier the process was somebody raises a pull request in into the GitHub um repository and that pull request used to receive comments and then uh the people who created that pull request they used to go and go through and review process edit and uh they they used to work through a template and all that but the new process is um in in a much simpler way a pre-created template is provided to them on a GitHub page and um all they have to do is fill up that GitHub page and submit that as an issue and the process I mean the expectation from pack members or labs stewards is that we review the um GitHub issues with new lab proposals and we on those I would like um maybe David or Ry um to chip in here and and talk about it in much I mean talk about it again. >> Yeah, thanks Arun for putting that on the agenda and you really covered it. I just wanted to make sure people were aware of the new process and and just to talk through it again. Um because we did have some we had I posted on Discord yesterday, we had some lab proposals that have been in for a while and haven't had votes yet. So I just wanted to make sure that um people were aware what the new process was so those could get uh reviewed. But um also just wanted to see if anybody had any questions about the new process. I know we reviewed it a little bit the other day. um maybe a couple weeks ago on a call and people had some feedback for us on the new process. So if people have questions or comments about that, we could talk about it that as well. >> This is D. Sorry, I clicked open and not the hand raised fast enough. Um it I've used the the new process a couple of times. The one issue that it raises for me is the old process allowed the submitters to keep and us to keep working on the proposal sort of collaboratively and this new one doesn't really let us um like it let them change the content in a in a very tagged way like a PR does. Um so there's a limitation in this as long people need to be aware think aware of it. It's a little like if you ask someone to add sponsors or to do this um in the old way, it was a little simpler and more direct, more transparent that you were asking them to update the PR itself. So, I'm not sure if that that the flow is is as optimal as the old one was, even though the old one was probably not um as easy to manage um for stack. No, that's helpful feedback. And again, I think I had mentioned it a couple weeks ago. You know, if if we try this new process for a while and we realize it's not working as well as the other one, we can certainly revisit. But no, appreciate the the feedback. And I see that Enrique put a thumbs up to your comment too. So um >> yeah, >> any other comments, questions [snorts] about the process? >> Yeah, I think I I share the same kind of views um as mentioned. I think the new process makes you review it more from um like global view of the proposal. It doesn't let you pinpoint on specific things. So I I reviewed I think three or four today and the ones that were outstanding and it just felt like I couldn't really pinpoint specific things. I do wonder maybe I know the pain points of branches and stuff. I do wonder right if there's a way where we could have PRs that are parked somewhere. They don't they don't have to be into main right into a different sort of branch or some some system and then eventually when we all vote with them we do the work of just the [clears throat] final version moving it to a a PR against the main branch. So we still have like a working tree somewhere we could discuss with the proposal but it's not always keeping up to date and DCO checks and everything and there's a there's a final PR then that gets merged and that's a that's something we could we could try out in the future. But yeah, those those were my thoughts. I found it a little bit more difficult um to review things especially it's a big block of text. I normally clone the repo down and render the markdown so I can can view it more nicely. So you can do that as well. >> Thank you. is um so sorry. Yep. Um um I've seen like in some cases it allows us for for us to see the history of all the edits on an issue. If let's say the um the submitter of that issue edits it, I believe it allows us to see what edits were made. But that's still um like an additional step that we um we generally get to I mean get to do other than like looking through the pull request and getting to know what changed otherwise any any other comments or thoughts on that process I'll just say that again. Thanks for the feedback. I, you know, since we have four proposals in right now, I'd say let's get through this current batch and then in a week or two or so, we could talk about, you know, any of these changes if we want to make going forward. But thanks for everybody for reviewing the proposals and the process we have currently right now just so we can get those addressed. Thanks David. Um so thanks for also bringing up on the pending lab proposals. So we do have [clears throat] I mean um if you can scroll a bit on the pending lab proposals. So we do have these um I mean the lab proposal section and yep um so we do have a pending lab proposals for review. If you haven't had a chance to look at uh these proposals please do give it to review. Um, one of the new lab proposals that we received in the past week is the uh uh the last one I believe it is pronounced as tear is application privacy and remaining um issues were pending for review um since I mean even before last week. Uh I request members if you if you get a chance sometime today please do take a look with these lab proposals. If you have any suggestions on um where the project teams make it benefit with existing community projects please do advise them. Enrique. >> Yeah. One thing, um, in the last few months, I'm seeing that we are starting to review more labs as a TAC, but what's really happening with the lab stewards? Um, they should also be reviewing this. Like, is it that we don't have a big group of lab stewards that are capable of reviewing it? Like, seems like we're taking on more of this uh review um approach than originally intended. So I just want to highlight what's the why are we push being pushed so much when we haven't even reviewed loads of midyear reports for the projects. >> Yeah I mean that's a good question. We've had several stewards over the past you know year or so um retire um so we just have fewer fewer stewards than before. I think there's only I'd have to double check, but I think there's only currently two stewards who aren't in the TAC. I think Marcus is a steward and the TAC member. So, we do have I think three or four uh uh stewards currently, but some of those people are also TAC members. So, there's just not that many stewards right now. I mean, we could have a whole conversation about recruiting more and that's great. And if you have ideas for people who would be a good steward, certainly, you know, let us know and we can reach out. But that's that's the situation. We've had some people retire >> and the lab steward is also a voting process or it's more like a volunteer and then approval mode. >> Yeah, it's been a volunt if somebody raises their hand and expresses interest. I mean, yeah, there hasn't been in in the past like a voting process for it. It's just more like interest in the role. >> Okay. Thank you. I did think that there was at some point um the TAC was approving there there would be a vote on new lab stewards but that was a while ago so and I don't want to rat hole on it so >> thanks hard David >> oh no nothing else to add >> makes sense. Um yeah, I I I do acknowledge that uh currently we do have multiple things depending on view. Um we could look at divide and concord kind of a approach if we feel like that could bring down some of the workload and um maybe like we can share learnings among other T members. maybe briefly talk about either these proposals or or the media reports and see if that can speed up the the process. I'm open to suggestions on how we can move forward. Um and let us think it through. I'll move to the next discussion item for the day. So um moving to the next discussion item, we do have multiple media reports pending for review. Um I know like we did we did bring up few of them in the past week but they were not uploaded um since then. Um Dan I see you have your hand raised but quickly completing my thought process. If you have anything you would like to bring up on any of these media report without going into um each one one at a time, please do bring it up. If not, um I would say let's review and then highlight things that we are concerned about from these projects. D >> I I was just going to say we have Steven Curran on the call from the Anon Creds uh review. Um and I'm not sure if we have other people on the call. Um, and he was here last week and we didn't get to his ancred one. I'm wondering if we could do that one first if Stephen's still here. >> Yeah, >> I'm here. Although hear more about uh OWF than um, but yes. >> Okay, >> we didn't get to that either last week. Sorry. >> I I know. So, I was just trying to be courteous here. Um and and I was the reviewer for this one and it is you know as I say it's it's a it's a mature and stable project. Um there's still the discussion around um uh the adoption of a noncreds 2 going on. Um, but Stephen and I had a little back and forth about whether um focusing on a um on a noncreds one and it being mature and stable and if bumping it to graduated would help um bring the boost of PR and awareness help bring more um people to the community and um I don't know Stephen if you want to put in a few words about your thoughts on that. I that's what the one thing I thought we could help in the life cycle process is acknowledge that an onred one has a viable adopt adoption curve. Um it though there were some I think um issues around connectivity to the actual end users of it and what we were getting is adoption the real contacts we have were people who have integrated it into things but not not um actually the adopters themselves. So I'll pause for a minute and Stephen if you want to put in your two cents here. >> Sure. I I mean the tricky part is just um there is you know very little interest it seems at the project level. Um my understanding is it's still broad relatively broadly used by a number of organizations by a number of ecosystems and and because it's so complete and easy to use that that it is used and continues to be used because it's harder to move on to other things or or things like that. But um you know there's no meaningful participation happening at the project level. Um, and that's what I don't know. So, I just think status quo I just default to status quo on that. Now, you've had the idea of of moving it to graduation and maybe that would encourage people. >> Um, I I don't know. Um, >> it's it just takes effort to do that and I just haven't I've got limited effort in these areas and that hasn't been the highest priority. That's for me. That's the bottom line. >> Yeah. Okay. So, so if you read through the notes in the um u midyear review, that's the discussion that we had. Um so I'm going to park it for now, Stephen, because of the resource constraints. Um and but approve the the midyear report or make a motion to approve the the midyear report. >> Thank you. >> Do we have any seconds? One question from my side here. Um, just want to understand so the the reason the V2 of Anon creditreds is not successful even though it's being completed is because of fragmentation in the in the market. Is that is that the the answer or is there something more deep on on that? >> Yeah. I mean to me an onredit V2 is um far and away the most complete implementation available. Actually I shouldn't say that. um um in the BBS space um approach to ZKP credentials um the the Longfellow work being done by um the folks at Google and beyond it's now being picked up by others is really uh gaining momentum and those not aware of it you should um be familiar um particularly as um OWF moves over to um LFTT uh there is good progress being made there. um the implementation in and on creds to support both PS signatures and DDS signatures and plug in making it um useful for other um potential schemes is incredibly powerful but um uh it it just is not getting pick up and and 2 just is completely stalled so it's not going anywhere. Um the focus in the BBS community is just getting IETF approval and and people are just doing what I you know you sort of consider the basics at moving it forward versus actually um having an implementation that people can use directly in a in a um common way and that's what an onra one uh absolutely did it you know was a completely uh a complete solution and there just isn't one for next generation which is what you would consider BBS and then we get into uh you know and that's not even getting into code quantum. So um that's the challenge is it's just the time window is not been there. So an v2 is basically um completely solved a fantastic code base is out there. it could be used in a second, but um just no interest in anyone picking it up. And then uh V1 just continues to roll along, gets um maintenance updates, but that's about it. Um over over time um and uh not not particularly there's no interest in um in moving it forward or adding to it or things like that. Would would you say that what's the relationship between V1 and V2? From what you're you're saying, they seem to be completely different code bases and completely different projects even like approach solutions, right? >> Um yes and no. Um the thing that Anocritz one did beyond what any other ZKP solution is it it had um a set of um combination of data structures and protocols to implement um credential exchange. V2 uses essentially the same ones but adds flexibility, adds one more abstraction that allows for um plugging in different algorithms and um enhancing the the ZKP power that you have like um um the nonr one has selective disclosure and um you know condition um conditions is uh very simple conditions. Um and on v2 has much has more complex capabilities, the ability to compare value between two um credentials and but not um not present the actual value but but represent that they are prove that they are equal. So an equality claim and things like that. um a range proof uh other things like that that are are are more powerful capabilities that open up more ways um but the general flow is between an onredit V1 and V2 is the same. So while there are uh much easier to plug it in or or to upgrade an instance of an encred one to two and um Oracle did a pile of work on that. um the Oracle Labs folks did a pile of work where they actually had a higher level interface and were able to um use it for um three different implementations of EKPS and onres one two and the doc labs implementation. So uh not completely different but yes a new codebase because it dealt with different algorithms different underlying cryptographic algorithms. >> Yes. I'm just trying to share the sentiment and and the PR I agree with is like it just see it does seem loads of adoption for non credits. It does seem like a great candidate for a graduate project just may maybe the versioning scheme that actually the marketed versioning scheme of version two feel in that stagnant kind of version makes it feel like it's not going anywhere but has loads of production use cases right in V1. So that's why I was just trying to understand if it was like just a feature add-on like a 1.1 over a complete reimagining of the system which is a V2. >> Yeah. I mean there was enough breaking change and so on that it be it was considered V2 um when it was created. So yes. >> Okay. Thanks thanks for the for the information there. No, I I've made a motion to accept the report as is. Is there a second? >> Do we have a second motion? >> Yeah, I can second that. >> Thank you so much. Um, okay. So, I'm going to go through the list. Um, Kevin, how did you vote? >> Yes. >> Enrique, >> yep. >> Diane, >> yep. Rama, >> yes. >> Arun, >> yes. >> Y, >> yes. >> And Matthew, >> yes. >> All right. Thank you so much. The motion passes. Thanks, Stephen. >> Thank you. Much appreciated. >> Right. Thanks, everyone. Is there another report that uh TAC has reviewed that we should bring it up for discussion or any concerns that you have come across from any other reports? If not, um quick reminder to everyone. Let's review. Oh, I see Matt you're raising hand. >> Hey Erin, sorry. Yeah, thank you. Um yeah, I guess I I I kind of had some questions around this with the non-grades one although um um looking at the fabric annual report uh midyear report um felt like a really good example of something that that's come up a few times um and is really really kind of clearly visible in the fabric report. the fact that it's a it's a single project from an LFD point of view, but has two really really discreet areas of development and and the report is really clear. It's a really really good report, but it has really uh clearly defined the two parts of fabric as having two um life cycle recommendations. um and and in indeed talks about fabric as graduated and fabric x as incubating. Um and I think and touched on this a bit v1 and v2 very very different situations. Um and I think there are kind of two things that the tc would benefit from talking about. I I think this report is fine given that the current constraints are that it's hard to to clearly distinguish different levels. you know, there are no there's no way of saying different parts of this project should be in different kind of graduated status. Um, and generally I thought the report was pretty good and fabric X is clearly a really kind of growing active area, but I I I think we keep hunting down the road the lack of granularity we have for projects that have lots of repos and the life cycle stages that we we're kind of uh stuck with um in [clears throat] that you we just have incubating graduated and um it feels like there's there's maybe more you know even for a non-grad v1 I put a small comment in the for one that the the report talked about all the activity really being maintenance mode activity. So I just didn't want us to drop that, you know, keep punting those conversations down the road because it's come up a few times and I don't think we've ever really kind of done anything about it. >> So is Fabric X in this case like a complete rebuild and it's a complete different codebase or the share things. into several new repos. Um I I don't know if there's much shared code between it. Um it looks like quite different maintainer groups and one of the questions I put on there was whether or not there was an expectation fabric contributors would inevitably slowly move towards fabric X development or not. Um that all feeds into its status. Fabric X has far fewer developer. I think two maintainers was was was the what the report said compared to fabric which is many more than that I think. >> So could it be a complete separate project in terms of the life cycle? I I think um almost certainly could be. I what I'm conscious of is um that being the kind of the way that we solve the fact that we don't have a lot of granularity or ways of distinguishing between between different bits of a single project. And I know Firefly has this lots of repos that they are actively developed to a very varying degree >> but that doesn't necessarily mean they should all be split off as different FDT projects. >> I kind of want to differentiate between granularity at the level of plugins. >> Yeah. >> So if you have a core architecture of a project and some plugins have different granularity like I see in the fabric report they have series of labs they've included as part of the project review right in the mid year. those are considered like a different granularity, different sort of life cycle than their other um repos over the overall project. >> Yeah. >> Without being a different rebuild. So I do I do agree that we can't we can't stop bunting this because we hitting it across most of the projects. Love to hear what other thinks are as well. do >> um to throw um more into this one. Um as the OWF projects um plan on transitioning over um one of the approaches we're planning on taking is to essentially um bring back the band that is that was Aries. We're not going to call it Aries, so you know, don't go there. Um, but we are planning on having um something like or or considering I shouldn't say planning because I I haven't talked to everyone involved but um we're getting positive feedback on the idea of something like identity agent framework and things like Acupy and Credo uh and VCX um projects from O open wallet coming over to LFTT as a single project. Um, a lot of the reason for that will be the GitHub management um overhead and and being able to deal with that. the fact that there are common maintainers across them. But a big part is also the administrative overhead of um the regular reports um the you know uh tax appearances and so on which have not been um are considered overhead for a a a project where the maintainers are primary developers that are are are working on their own on the on the code and working on their own. um ventures and things like that. So um it [clears throat] would be useful for feedback for us because that's the plan um or the the direction we're looking at doing as we plan to propose a project for LFTT coming from OWF. Thank you, Stephen. Any comments Don't hear any. >> Well, I guess a direct question would be should we not do that? just for my benefit because I think your comments are very valuable when you say should we not do that. Could you just clarify what that was? >> So, so at OWF there's about three or four different projects all of which came out of hyperledgeries. Mhm. >> Um as we move back to LFDT, our preference right now seems to be again um we've not got full commitment but is to come back as a single project. that creates the same sort of situation you've got with with Fabric X, which is um that there will be different levels and the projects themselves will sort of figure out how to archive repos and things like that, but we'll do it more at a repo level. Um we'll continue to make announcements that are tied to the name of the project. So, Acupi and Credo will continue to exist in in our concept, but but we want to go as a single project within LFTT because we largely do the same thing, just different approaches to the same thing. And we want to reduce the overhead and have fewer projects, fewer um things to do related to running the project and allow maintainers that um do that sort of thing to to handle the administrative side of it and let the developer uh the developer maintainers focus on code and and releases and things like that. So >> yeah, I I um I I definitely see that and I think it I think um small numbers of projects is fine. And I think I think it's probably important not to not to confuse lots of repos with the number of discrete broad areas of of development under a project. So if you take like Fabric X is a really good example, loads of repos. Um, and I think it's up to the project to decide how they manage those repos, what their life cycle is, how mature they are, what who who can contribute and commit to each one. So, all those kind of day-to-day tasks. But I think if you look at the report, there are two really clearly distinct areas of development under under the fabric banner. Um, and I think I think for the for Aries, I think I think um you don't want to have loads and loads of discrete projects each with their own overheads of the reports and so on. And I think I think um I I personally I I I think that's fine. I think it's I think it's how you how you um uh bundle together areas of work under a project that you feel are a single area of active development for that project. So that if someone says um project Aries is in graduated status, you have a reasonably good feel for that means kind of most most of the stuff that falls under that project is in that is in that status. Um, if you've got really different things all under the same banner where you're literally saying these two [clears throat] are in totally different project life cycles, it starts to become really hard to to for someone who's looking at the project to know what state is like in quotes fabric. Um, because there's no there's now, you know, it's hard to hard to know what someone means by fabric. Is it the original fabric or is it fabric eggs? Um so I I I think most people on the call will understand adding adding the overhead of lots of reports for for lots of very small projects is not is not a good way forward. Um, so yeah, sorry about that. >> No, for me it's like the governance and leadership of of that project is is really the important part for me. And I think as a TSC when we review these projects that may have certain maybe archives or deprecated parts of it, we shouldn't um kind of deduct points in that manner of a graduate project if it has some plugins that are the found that's normal life cycle, right? Um so I think keeping together is is better because it gives um obviously right less less work and less management for all these maintainers but we have to give some guidance to project that that they should be deprecating or they should be putting something on the readme when parts of the project are different status right um and now that they own their own organizations they have more freedom to do so right so if they want to name repos different way or have different tags on repos or or read me to to show this is an experimental feature. It doesn't neglect the whole the whole view of the project. Um yeah, >> sorry, Stephen. >> Let Steven go. Yeah. >> Okay. Um first, please don't ever let's not ever say Aries again in the project. So, I really apologize for bringing it saying it that way. Um that's not the plan. Um and that's just lighthearted. Um you you are with respect you're really saying you want it both ways and that's the tricky part of that I'm trying to get to. Um we are our plan like Credo and Acupy are pretty independent projects. They both do the same thing. Um one in Python, one in Typescript. Um they share common Rush libraries but those are outside of the project. Those are dependencies that are elsewhere. um and they essentially have different life cycles, different marketing uh and so on. But um we would find it easier to have them under a common GitHub organization and a and and have that overhead all dealt with so the developers can deal with it and um and as well as I say this other overhead administrative. So, I'm not sure how to read your It's good to have fewer projects, but not good to have them at different um places in life cycle and things like that because that could happen. Um it's not right now. They're both very mature. Um but we're we're planning on bringing along component parts that are just sort of um helpers with it. Um, an answer to the Wii question, it's right now it's the Acupay and and Credo projects at OWF. And there's a couple of other ones that are called projects right now, but are really um the same community and we plan on bringing them as part of it. That's the we Thank you. >> Yeah. So, while you all were talking, I was counting and so I was counting some of those sub projects and there was about 18 things called projects under there. And so the idea of having 18 mid-year reports and annual reports is kind of daunting. So I'm I'm interested in because we had something similar to happen with this with Trust Rover IP. It's similar but different. They have so many different working groups under them that they roll up their report into those and those different sub working groups are act considerably a lot like projects. Um and those are at different levels too and it doesn't stumble us that much in trust over IP. They have other oops they have other issues. Um but in the in the reporting we we do sort of have a precedence of having multiple things with other um life cycle stages in them in the standards world not in the code world. So like I am leaning towards having OW an OWF annual report with subsections. Um but then I Stephen what you just said is it's pretty much a ACI and credo and it's not 18 those some of those would be subsumed. Um, so I'm just trying to figure out, do we tease out ACPA and Credo and put them as reports and then put everything else under OWF or can we make an umbrella structure taxonomy for OWF that enables different life cycles? You got 13. I can see someone counting um better than I am in the in the comments. Yeah. So, Stephen, go ahead. >> Yeah. So what we're doing is more not looking at it as what's a project at OWF and and bringing OWF in as a single project. We're more looking at it as what are the things that are common and um that that are that have a commonality to them. Um and and also asking the different projects OWF projects again this word is so overloaded. um but uh to see you know whether there's interest and so on. So I would expect that um for example multipath and all of its um uh we will ask multipath if they're interested in in being part of an identities identity agent framework or whatever we call it um project at LFTT um and and we'll see what they think. Um um but right now, you know, it's just the ones where there's a commonality of functionality in it and not just oh because they're at OW, we just pull them all together. So I think Trust Over IP did that and it's a it's a single project. No, we don't expect to do that. is more um where we see it logical that they come together into a set of sub projects that make up a single project at LFTD. >> So is there a just to follow on quickly is there a timeline for coming back to the TAC with sort of a taxonomy absolutely okay. Yeah, like I'm I'm actively trying to get in the next week to two um uh a way to put together a project proposal to go to um LFT Cap. >> Okay. >> I mean, essentially, we're we're making new projects, right? We're we're going through the full process of starting from scratch with a project. And so, I'm what I'm doing right now is seeing who's willing to um go in as a single project. Again, combination of of logical and and willing. If if some project at OWF wants to stay independent, that's their choice. If they want to combine and it makes sense, um that's good. But we don't have that consensus across OWF for example. So for those who would who would not who would not come in that taxonomy under whatever the framework name is um they would have to put in their own proposals to come over so we see yes. >> Okay. So, and you think >> you think maybe by by the end of next week or maybe shall we give you two weeks you'll have some report back for us about what to expect in the proposals. >> Again, I don't speak for OWF or at a broader level. Um, what I'm saying is I'm recruiting projects that I think make sense or could make sense and saying, "Hey, do you want to do this or do you want to go and put your own proposal in?" I think that's the the sort of approach we're taking and then in a couple what I'm encouraging is to see if we can get to in a couple of weeks have a set of of projects that we would we would have. Um, I think there's another there's another movement. for example, um there's a whole set of labs that are um TypeScript libraries and all of those are instead of being single labs combining into a single project. And I think that makes sense as well. Um but that would be independent of what I'm talking of of the one I'm of the one project I'm talking about. >> Thanks, Ste. Sean. Yeah, I'll keep this really quick. Um, [clears throat] both Stephen and Diane answered most of the questions I was going to answer, but um, we right now have 13 projects which would be classified as graduated or incubating. We've got, uh, roughly 19 labs. Um, Stephen just talked about the projects [clears throat] formerly known as ARIES, which moved over to OWF and became independent projects possibly combining back at LFDT. We absolutely support that. We've given all the projects uh notification of what's happening. We've told them they've gotten till the end of the year to make their application to the LFDT to you know apply to become LFDT projects. They have and and the other option is they can archive um and archiving is perfectly okay. And we also gave them some updated guidance that um if they want to combine they absolutely absolutely are welcome to do that. Steven was the first to to to both point that out, but also to start working on, you know, what a combination might look like. He just mentioned the four labs. Uh it's actually three labs plus one um growth project are considering combining into one lab because they they are a good fit together. They were originally contributed by different maintainers. They were each separate individual tools that anybody could use. They think it they're going to go farther together than they were apart. We absolutely support that. Um, [clears throat] I'm talking to three projects right now about just archiving. So, I am hoping in the next couple of weeks to give this TAC as well as the OWF TAC a breakdown of where we are with proposals and who's moving to where and who's archiving. Uh, this is going to be an ongoing migration between now and the end of the year. We've also made it clear to all the maintainers at OWF if they do not choose to archive and they do not choose to propose to LFDT, they will be archived at the end of the year. This is not an open-ended, you know, forever. We're we're we we're working on getting this done now. We want to get the applications in. If the TAC does not have time, uh Christmas week to weigh in on proposal, that's fine. That can roll over to the next year, but the proposal has to be in before the end of the year or else they're going to get archived. Um and and we are I can't speak for any of the projects, but I can speak uh in my context as staff is we're working with the maintainers where they need help. We are giving advice where they need help. And in some cases, I might be asking TAC members to talk to an OWF maintainer if they've got a very specific question of, you know, do I fit here, do I fit there? But for the most part, um a lot of our senior projects came from LFDT a couple years ago. They're I've joked, we're not changing religions. We're just going to a church on the other side of town where Sean and Ry also work. So, it's it's we're hoping to keep this uh this transition as lightweight as possible. >> Thanks, Sean. >> Thanks, Stephen, for sharing your perspective and and all the effort on on that front. So that was one of the topics I want I did want to bring up for discussion today and um we look forward to the proposals and we also request if possible if if these proposals are in uh by the time the LFD tack collections to happen. We do request um the the OW of the current OW of project maintenance and uh to to do participate in this election process. Okay. Um moving to the next discussion item for the day. So we kind of covered uh the um OWF project migration plan and and timeline and we we really look forward to to those. Um quick reminder so we did have a couple of topics that were not closed from our previous discussions. The first one was there was a proposal on change in meeting time and as of what I saw yesterday the when the ended it had three approvals and three nazs with few obstains um it's did not go through so so um like we did not have clear majority on changing the meeting time should we I mean Um, Matthew, I'm not sure if you you [clears throat] >> Yeah, thanks. Yeah, I mean, um, I I think it's pretty reasonable, you know, if if we we aired it, we had a discussion and we had a vote and it didn't pass, I you know, I'm I'm not going to push back against that too hard. I know there there were a number who just didn't vote. And so, you know, may maybe if everyone looked at it and um checked the time, thought it was was workable, then then it would have passed. But at the same time, several people voted against it. And I'm conscious that changing times doesn't work for everyone. And um you know I I I I suggest that you know personally I'm totally happy that we part of the discussion now. Maybe with a new group of uh TAC members in the new year there'll be a fresh round of discussions about time time zones that work. Anyway, um so I would just keep it in mind across the TAC that the core dev calls for Ethereum are really useful for for people who are on this call as well often. So um uh but yeah I I'm kind of appreciative that it got ahead and we had a bit of discussion and a vote and and you know that's that's the that's the way it came out. >> Thanks Matthew. So quickly shifting the focus back on um to the next topic that was pending from our past weeks of discussion. This is on this move pretty much the entirety of last week we had discussion with this movement. Now VIA on our on our call and um there was a request from VIA that we wait for two months and then we look back and then see if smooth is able to resolve and they did bring up multiple concerns especially with respect to opening up all the resources in public um repositories like they did come across some issues with the um uh the discoverability of some of the vulnerabilities and things like that and and um I know like tag did not have a strong um opinion as to should we continue with the project at the same time there was no consensus on should we move it to a lab and I want to bring it up again like you know we have like five minutes left in this meeting any thoughts or comments on the project So we we have to park forward we wait and watch or we ask project that um like it's best that you start growing in lab and eventually make sure you back and um incubate So u if there are no thoughts I do have a personal bias on um how we portray some of these uh to the community for instance we don't want a case where we ask product to move into a lab and then they eventually come back in two months and say hey we are prepared let's go back to incubation. At the same time, we definitely want to make sure that project is adhering to all the standards that we have in place, especially all the gaps that Marcus has identified and uh that definitely is a big concern. But given that project team explicitly requested for additional time, I'm uh I mean that's my personal view that we gave them the time that they requested but we time box it and um if that is if there's no um yeah is Matthew I see you raised your hand. >> Hey sorry I yeah didn't mean to interrupt you what you were saying. Um yeah apologies I couldn't attend last week when which is when I think there was quite a lot of discussion. Um um I think my my my personal view from um from the fact it's kind of come to and fro to and fro a bit is that if if it moves to a lab and then it and then it does come back fairly soon afterwards. Personally, I don't think that's too too big a problem [clears throat] and I do think it's been quite a distraction on the TAC meetings for a while. And I also think that if if they if they're really really engaged enough that this is kind of a um they jump on it and then they're back as a as an incubating project pretty soon afterwards. I I don't see that as a bad thing. It's a really good indicator to the TAC that actually, you know, there's some issues to out about like timeliness of reports and stuff. I I think without without the TAC following through on some of its some of its kind of guidelines and regulations for what constitutes an incubating or a graduated project not to the letter I know some you know the numbers of contributors the number of orgs for each project a lot [clears throat] of projects have places where they down a little but I think for the amount of of kind of the number of gaps and the amount of extra time they've been given I personally vote if we have having a vote for them to be moved to a lab from from today. Um there isn't enough time really to have that discussion. So I'm happy to to propose a vote for next week's meeting or via a PR. I don't know how what a PR for that would look like that it moves back to a lab. Um and and I we could maybe just vote on it next next week, but I we're right on the hour, so people are probably wanting to drop now, but I we we could make that the first item on next week's agenda. It's a it's a threeminut thing. It's the vote. If it doesn't if it doesn't pass and they stay as an incubating project, then by by definition, they get the extra time that they've been talking about. So it doesn't distract next week's meeting too much. Thanks Martin. Okay. Um I I quick reminders please do review any pending project reports or the new labs that we have and request community members to participate in the D collections and know we are on top of ours. Thank you everyone for today's participation. See you again in a week's time. >> Thank you everybody. >> You