Post-Quantum Interop Call #23

Transcript

Um, let's get started. Uh, let's kick off with some client updates. Zam team, >> Ariel and everyone. Yeah. So our updates are that uh we are definite to uh implementation complete and we are ready to interrupt with other clients and uh for that uh Katya and Pa will basically uh uh try interrupt with other clients which whosoever are ready and uh I think in today's call uh people can indicate uh who are ready and uh we can take it from there. Apart from that uh on the

uh okay apart from that I think uh on the tooling front uh PA has been working on uh uh on on basically a plan of checkpoint Z for lean uh and uh we will we will be able to uh sort of integrate it and test it out in the net two and we have started reviewing DevNet 3 PRs as well and uh hopefully we will make good progress in tomorrow's breakout call and uh we have also added uh few more

metrics for the net 2 uh and uh I think we will basically uh now based on debugging so we'll keep updating ing uh the client and uh keep uh making the fixes in the spec if needed and in the client as well. Thank you. >> Uh could you quickly just kind of set the context for everyone about what the breakout calls uh topic is? >> Yeah. So breakout call topic tomorrow I think we are having at at 2:00 p.m. UTC which is uh exactly this time is uh basically net 3 spec PR discussions

uh because I think there are a lot of comments that uh we have and it will be better to just discuss them discuss that in person so that there isn't much to and fro that is needed and I think Camille can also explain the spec which would be good for all of us. Thanks so much. Uh Ram team >> sweet. Uh hi guys. So uh the past week our biggest our biggest uh uh focus has been to match the DevNet 2 spec. Uh so on a higher level we have matched the DevNet 2 spec uh with all the new functions and all the new data

structures that have been added. uh very minor things such as how the spec stores aggregated signatures versus how we store the aggregated signature strct uh I believe are currently different but we we are fixing that today and uh and and we're implementing the spec tests uh in our CI as well as uh I I don't know if the spec tests are up to uh up to the spec in lean spec uh but we're going to we're going to add that in our CI and once the spec tests are up to up to spec uh we'll be testing against the spec. Uh one other thing we added was uh we added syncing. So a a client joining in uh later later into the devet can sync uh

sync with other clients. Uh so so we have added a CI test for that as well and that has been working quite well. Uh I have I have some minor concerns regarding uh one of the functions in the spec like the block building in the spec. Uh but I believe we can raise that after the client updates are done. >> Awesome. Thanks Sheree. Uh clean. >> Oh yeah. Hey everyone. Uh from our side uh yeah we're working on stabilizing the nodes. So we uh yeah fix the uh out of memory issue. So it should be good on kind of long-term uh runs for clean and

u yeah also uh it stabilized the networking parts. So previously um yeah clean could accidentally think that it kind of owns the connection with the peer that already disconnected. So we fixed that. Um yeah and uh basically currently u working towards devet 2. So we kind of had the uh aggregation ready for some time already but now yeah kind of merging of the changes and yeah hope to get uh the stable image with devet 2 ready uh soon. So yeah, thanks.

>> Thanks. Uh Lantern. >> Uh yep. Hi everyone. Um so basically have implemented support for checkpoint sync. Um and um I also noticed in the lean spec uh there were some uh changes introduced um spec defined for how syncing should be done. So I've been aligning the logic that was implement implemented in lantern with the logic that has been implemented or defined in leanspec. Um and I've also uh been trying to debug issues with syncing. Uh for example, if there is a local DevNet that I run uh for DevNet 2 and uh it's been running for like multiple hours and then I try to sync sometimes the sync

ends up stalling. uh sync works fine for um if the devet's only running for like uh a couple of minutes. Um so I'm currently trying to debug the issues but um uh and also recently uh there was a I think PR uh 305 uh that was merged in leanspec uh by the ze team I believe uh and I'm currently implementing that uh for justification pruning in the state object um and uh yep I think that's that's the update from our side we will release the docker image when Once the tooling has been updated for lean quick start, we'll open a PR for it as well for DNA too. Thanks.

>> Thanks, Mer. Um, there is Manus on the call or anyone from Lighthouse? Uh okay, cool. Uh e lambda. >> Okay. Um hello. >> Hey. Yeah.

Uh we recently we yesterday reached the one uh feature parity. We are now testing with um running some local desk death net death nets with mainly with sim trying now trying to add other clients to test interoperability. Uh just to to expand on on this if lambda now follows the chain receives both blocks and stationations and computes the current heads justified and finance states with attestation publishing and block proposals.

Uh we are now um we also opened the PR on link quick start adding support for it lambda. Um we are now working on deet support with historical sync and DB persistent as the next priorities. >> Thank you. Um, anyone from the game team on the call?

You'd like to provide an introduction and uh just a quick update on where you're at? Thanks. >> Yes. Yes. Um, can you hear me? >> Hi. >> Yes. >> Yeah. Yeah. Good to be here. So, um, we have started uh develop engine um, last week. uh what we have done so far we have implemented the uh type system and serialization on uh the link spec we have also um implemented the clock and you know genesis so up next uh what we're going to be doing is uh uh state transition >> that's yeah that's where Oh yeah.

>> Awesome. Uh thanks so much and welcome to the call. Uh yeah, so I dropped some notes in the chat just regarding overall coordination of this effort. Uh I'd like to set aside you healthy portion of the call to discuss some of these overlying you know ideas and concerns and just the way that we uh the way that we all work together. Um, so it's a great opportunity for some of the the newer teams to be able to like have a say and and also get up to speed and uh we can you know work together to uh craft processes that are reflective of this this growing uh group effort. Um so

before we do that uh let's touch base make sure that there's are there any spec or research updates that uh people would like to highlight. I can give a brief a brief update about like the status of the spec. So um this week I have worked quite a lot about the minimal client stuff. Um now I I am quite I am full-time on on the spec and so what I have done is that I have added a bunch of modules um to fill the gaps. uh for example like

completing the peer-to-peer uh stuff adding like a mini databasing like using something inside Python so that I don't have to add any external dependency and I have the simplest possible thing just to test. Um I also added some sync stuff, some storage stuff, some basic validators, some CLI and a bunch of modules. I have not plugged them fully together for now, let us say and interrupt with other clients, but I have added this module so that we have all the pieces let us say to

build like a minimal client. Uh now I was waiting for couple of things. Um first like to have a proper signature aggregation with the Python bindings to be able to interoperate with Zim and Rim for example and all the other clients. Then um also um I added some tests some documentation. I am trying to make uh the spec really bulletproof so that um we have like full test coverage with a lot of tests added to test various edge cases that I discovered through the the

process. Um also this weekend I began like an effort uh to have like a PDF inside the spec in order to be like a kind of a companion to the spec. This is uh for for now not complete at all. I have just started the intro um the part about like the timing system and yesterday I added the SSD part. I can send a link uh to the chat right there. I didn't send like um a proper message into the telegram group not to pollute the discussion but I hope

that this will become like an an effort to uh make like a plain text English version of the spec with a lot of explanation a lot of uh drawings and stuff like that so that everyone can understand the finest details of lin consensus. that is uh mostly yeah the part about like uh spec updates. So yeah basically now my focus will be on trying to improve test coverage make the minimally client working and improve the book as well. Uh yeah, this is basically it in

terms of spec. Maybe I can continue uh about LINVM. I um I recently finished to transition the ZKDSL into a Python lax a Python like syntax. I can send it to you. Um, a file which is like a Python file which is used by the ZKD DSL compiler to compile to a low-level bite code that is used either for regression or for XMSS aggregation. It's not currently um executable by Python. we will need some

additional details but it's close of being executable in the sense that we I just need to to create some Python classes import proon etc and we should be able to have the full um recursion program and XMSS regression program written in Python and so easily we we will be able to easily add it to the spec and so This the goal here is to have a Python program which is at the same time the spec like it defines um how the how to verify a snark and also is at the same time used to compile

to the low-level ISA recussion program. That's it. Thanks Emil. Thanks Tom. Um so were there any other timely updates that people would like to uh discuss before we kind of jump to this more kind of broad coordination uh topic. >> Uh yes a quick flagging that um there are two changes after we merged the the dev2 spec comments. uh yesterday. So there's one uh spotted by Kaden. I think lean multisc and lean sec is not

compatible. Um but I think m already fixed that. So that's that's a new change. So the the multisc uh commit should be updated. Um and then there's a a justification refactor that just I think just got merged in as well. Um yeah, thanks. So uh Kaja >> hello everyone uh quick updates from my site I will share the links in the chat. So um for DevNet 2 um that would be great to have labels for Docker images uh for for the clients and uh we also have labels for peer connection metrics.

So um if you if you're able to implement them on your client, please uh it will be super helpful for investigating the connection issues. Um I also opened um an issue about default images. Just take a look into it. Uh it is connected with the uh next uh link quick start update. We are going to add config files to uh launch uh the tabets easy locally. So uh the DevNet one retrospective is finalized. So feel free to use it wherever you want to and we also added it to the link week start repo so not to to lose everything. Um so currently for

for the new clients um please add logs even if you don't have metrics uh at least logs uh are nice to have because uh when the clients fail it's not clear like why uh especially for new clients so we need to investigate this and for for DevNet 2 um the dashboards will be shared so I'm working on this currently um uh yeah that's it for my site thank you. >> Thanks, Sacha. Uh, Mercy, >> sorry. Um, I just wanted to point out something. Um, the one of the PR um or did mention about I looked into it and

there's sort of um the prover states went from three generic parameters to two and then the constructor also went from two arguments to one. So, there's kind of like um a file a mismatch. So, it needs to be updated. So I wanted to check if that is why the was failing and if I can run the PR and push if that is necessary. I dropped the link to the comments and to the issue I created in regards to this in lane multi-ig. This is issue 136 API mismatch. I I thought that he it had been fixed.

>> Uh this has been resolved. Yeah. >> And actually the reason uh is because um to be precise, limit uses a different version of pronig, but it should not be a problem. And so as as far as I understand, it has been fixed. >> Okay. I just need to check back the error I'm getting cuz I tried to update it and then rebuild. I was getting an error. That was why I flagged it. I had to pin to the latest commit. Then I had to check Kaden's PR which I noticed his the CI was failing. So I was thinking that's the same reason why the CI was

failing. So you're you're uh concerned that maybe it is not fixed. >> Uh I think you might have been looking at the wrong failure logs. >> I'm I'm not sure. I think this has been resolved from my recollection. >> Okay, I'll check back again. Thank you. Thanks Mercy. Uh Sheree, >> uh yeah, so I'm going to raise something that I I think uh is problematic in the

spec. Uh however, I'm not the spec expert, so someone can correct me if I'm totally off. Let me share my screen here. Uh I think I could share just this. Uh so so uh can everyone see my screen? >> Uh yes. So when I implement the spec one is to one I'm running into uh I'm running into an issue where the state root uh the computed state route does not match the uh state route in the block. Uh and I have I have a feeling that it's coming from here. Uh the compute the compute aggregated signature has this two-phase thing where it may create uh multiple uh multiple aggregation bits. So it would do 1 1 0 0

0 1 1 uh and and it it the aggregated stationation from from this function may be different from the attestations we have put into the candidate block uh right here. however the post state route is not uploaded uh is not uh does not process the final block. Uh so we run into we run into some uh assertion issues uh at at time of state transition. Uh I wonder I wonder if I'm completely off or uh is this a valid concern cuz when implementing it in our client, we weren't able to reach finalization uh due to uh due to uh this error.

>> I think this could be a valid concern. So maybe can you raise a PR to fix this in the spec? I mean so generally the way we implement it in the clients and uh in this spec so there can be divergences and uh uh so this particular thing can happen where we have not really addressed the changes that got created while doing aggregated test aggregated signatures because yes there are some duplicates that can happen in aggregated signatures the way we are aggregating them uh with the same attestation data.

So what you are saying could definitely be correct and uh uh so if you can open the PR I think we can review and circle back on it. >> Okay. Okay. >> And if if this is not possible or like if you have a doubt what could be really helpful is to have a situation where it breaks. I guess that you can find it with your rest code. >> Yeah. just just for me to analyze the situation because I'm not sure I fully understood what you mentioned there and I think that this is normal because the flow is complex there.

>> Okay. So I'll just get all the logs and I'll just make an issue to lean spec. >> Yeah regarding that would be the best. >> Amazing. Thank you. >> Yeah. So, so the best way to best way to proceed on this Shahik always is to add a test vector >> because when you add a test vector and it fails, it clearly shows that you know uh there is something wrong with the spec and then the aim is to >> uh correct the correct the spec so that correct the code so that the test factor passes basically it's testdriven development and I think uh this is something we can add over here to make sure that this particular case is addressed.

Sweet, sweet. I I'll go ahead with uh seeing if I can get a test vector and then I'll look at an issue. So uh that should be all good. Also shared I think like uh uh you might be facing a session error where you are trying to basically validate that there aren't uh two aggregated payloads that have same attestation bits and we I removed that check from spec uh from specs but because like there might be certain cases in which we basically aggregate uh using gossip signatures and we already have a aggregated payload and it it might have like a theme attestation bits uh bits. So I have implemented it in such a way in ze that it is not possible

but it is like independent of a specs at this point in time. So I think like there used to be a uh used to be a check where we were basically validating that we don't have two uh two aggregated attestations with the same attestation bits. Uh that check has been removed. I think you might have missed removing that check from uh from your implementation. So that might be the case. >> Sweet. Uh I'm I'm going to check I'm going to check for that. Uh I'm I'm going to check for that and I can I can share my findings uh if if that's not the case.

>> Okay, sweet. >> Yeah. So the best thing is just to add the test vector and it basically you know everything becomes evident. >> Amazing. So look uh great. Um so I'm going to I guess try to set the table for just this broader coordination discussion. I think it's uh you know what this is call number 23.

you know, we've really been sort of uh diligently like sort of trying to bootstrap this this effort uh for several months now and I think we've had a lot of success. We're all, you know, just kind of organically understanding what gaps need to be filled um how to work together. We're shipping new and novel technology and uh you know these are kind of nent client teams that are working together and nent repos and orgs um and and we're also welcoming a lot of new client teams to the effort. So um I don't know what if I do the math we're about six months in.

So, I think it's a it's a good opportunity to just kind of like take stock of things. And uh really what prompted this is the fact that we've got uh kind of concurrent DevNet uh efforts happening uh and being discussed within these calls and within the telegram channels. And um so I think yesterday and I I'll kind of let Tomas set the stage but you know I know as we all know he's been working on this uh PL this Python implementation uh and was looking for a stable DevNet 2 client to to build on and you know was looking at the Zam branches the re branches and um you know

just finding that there's like some incompatibility I guess with you know a delta between, you know, what he was expecting to find on the DevNet 2 branch versus the spec and across those different uh clients. And so it started to, I think, between that and then last week we had uh three DevNets being discussed on the call. So we had, you know, the longunning DevNet one, we had DevNet 2 in development, and we had DevNet 3 already being discussed in terms of spec. Um, you know, I think it was really like, okay, are we dangerously like uh taking our eye off

the ball by trying to uh parallel process multiple dev nets at once? And so floated out some of these conversations with a smaller group last night. And it seems like there's like a really uh strong you know alignment around the idea that hey having two parallel devets in development is a good thing and it's you know what we should really be uh cognizant you know like uh we should all agree upon that you know there's the DevNet that's in implementation phase and then there's call that DevNet in and then DevNet in plus one is in the specification phase and so these two things can can certainly happen, you know, at the same

time. I think that we just want to make sure that we're working to time box that and have some cleaner processes so that things are clearly uh discussed and tracked uh across those DevNet era uh efforts. And I think that you know the sort of if that's the the the core the center of where coordination begins is in the GitHub PRs and the PM repo um it kind of emanates out from there and expresses itself in the way that we set up Telegram channels or um you know set up this call for instance. And so I just wanted to make sure that we're we're thinking about our our coordination

stack top top to bottom and that it's like it reflects the way that we are working. Um so I I put this like kind of six-part agenda um together to be able to talk about all of these things. Um I don't know in the diagnosis phase I guess like acknowledging some of the coordination challenges. Tamar you could speak to this because I think it's important for everyone to have like uh when I was an architect um you know a big part of like being able to hey like I'm an architect but I'm being asked to design a library or a bank or something.

I'm not a banker. I'm not a librarian. So you have to in design you have to like quickly develop uh empathy, right? And so like understanding like the perspective of how another type of contributor or person that engages in a system that you're designing would you know interact with it is going to help you design that system better. So I think having empathy you know from one client to the other client but also having empathy from a client perspective to like a specw writing perspective to metrics to research uh is important. So anyway, uh Tomas, maybe you could speak, you know, about some of the things that you're encountering and if anyone else wants to like jump in to like uh add

into like some areas that they view as have been problematic or uh you know uh challen particularly challenging. >> Yeah, sure. Yeah, thanks Will like for for the intro. So yeah um as I mentioned during my recap beginning of this call um I am currently working on like a minimal Python client. Um the goal of this is to make linspec both a spec where we have like spec writing like documentation that are appropriate for a spec meaning like very rich documentation uh proper test vectors, proper unit test

and all of this but also like a minimal client so that we are sure that everything works properly by running it and interoper interrupt with all the other clients That is an important point so that you as a client will be able to interrupt for example with a python client both zim rim it's lambda gig all of this so that you can test directly uh in front of the spec so that will be very nice even if the lin is not at all uh for production this is also like a nice room for uh checking new stuff with a peer-to-peer layer experimenting

extracting data from the the devet so that we can track metrics in Python, we can build like Jupyter notebook, we can build some plots and all of this. Um and so my goal there even if I know that my implementation is not complete at any point and um I used also like a lot of AI to build it. So I am expecting a lot of bugs. I am trying to strongly test it again test vectors but I was checking a bit um how to test interoper interoperation with all the other clients. So the most advanced one are like Zim and rim since you guys are there from the very beginning but kine

and like lantern and all of these but I am more familiar with rust and zig. So I decided like to try to interrupt with these two and I found that um like the the way you frame things is very different in Zim and reim for example in Zim you are working like on a specific branch for DevNet 2 in rim you are working under feature flag in Rust and I I I found that I am sure that you guys uh lost some times by debugging things related to the spec. For example, what you just mentioned Sherik at the during this call is a very good example of this

because you encounter like a bug in the blog building. But maybe this is due to the fact that Zim guys push these PRs because they they have encountered themselves like a bug in their client and so they push the PR and so you then as another client discovers the thing and so so I found that maybe there are like a misconnection between us not between you but between us so that maybe some also some merge that I am doing on the linspec are merged kind of silently and you don't see that and finally you discover that P has been merged like one month after and so you spend a lot of

times you guys debugging the things uh but the problem was due to like a merge and so I was thinking that also this is due to the fact that we are working on many many devets for example some of the team there are on devet one, some are on devet two and even some are thinking about devet three. So this is very difficult even when we send some message between us in technical groups on telegram for example if I mention the subject uh signature aggregation some of you guys are still on devet one so there is no aggregation so you don't understand at all what I am talking

about some of you are devet two so you are aware about what I am talking about and some of you are devet three already in their mind and so they think that we are doing recursive aggregation and so they don't understand why I am not talking about recursive thing and so this create a bit of a mess between between all of us uh so as you just mentioned will uh maybe like we should limit our scope to for example two dev nets um for example like we can have like one uh that is currently in progress by all of you guys as a team and one that is under

specification. But in this case, this should be very very clear for you guys which feature you should include in your debugging or in your daily basis workflow and which feature you should not take care about and reserve for later. That should be very clear otherwise like some clients will try to operate in the future other in the past and this will be a mess for this um I was thinking about different thing but because right now if I am looking even even me this is not very clear in my mind I have not a precise table where I

know uh the precise feature required for each devet and uh the status of all of the clients. That should be very helpful to do to do to say okay for DevNet 2 we need this feature this feature and this feature very precisely and without any u possible ambiguity. That means that okay this feature this feature this feature and okay we have a list of clients and we know that this client is able to do this feature but not this one and this one the other one. Okay, the three feature. So this is complete and so that this will allow us to to see uh clear I think also I love the idea of I know

that you pushed a lot of that in the lspec to have flags and milestone. This means that in the pull request if I search for specific pull request I can filter pull request by milestone. And for example, I can filter all of the puly requests linked to devet 2. And so that you could completely eliminate the PR linked to devet 3 and you can only focus on the PRs linked to devet 2. And for example, if I do a PR that has nothing to do with devet 2, that is just adding some test coverage for SSD like I merged just before the call. you can completely eliminate that from your mind

because you don't care. This is like basic SSD coverage and you use a library for that. So you don't care. Um that was like a point that I that I mentioned and also I think that the fact of you guys as team working on the spec. So for example, if like a team A is working on the specific part of the specs, this means that this team A has more experience and more like debugging on this part. But maybe all the other clients will not have this experience and so they will fight against the spec and against the different PRs and another team B can have more experience on the topic B and so the other the

other teams will also fight against um and so yeah that was basically my point to be sure that we are well organized also I know that there are many new teams coming and so these teams should be a bit late. Let us say we cannot ask a new team right now to be under devet 2. That is not possible. If you started yesterday, you couldn't be in Defet 2 for tomorrow. And so we should also bring clarity to these teams in order for them to have a clear vision to be able to ask questions and all of this stuff. Also we have like a versioning system in um in linspec in this file

where you have I I this is not updated but I have a PR to update it but this is like the commit related to the devet. This means that if you are a new client and you target devet one, you should stop yourself at the commit linked to devet one and you should not care about everything that is after otherwise it will be noise for you and you will have way too many confusion. So yeah the that was my my point. Uh yeah basically just uh as you mentioned will this was like to settle the basis uh as we have like a growing number of teams I

expect even more noise and even more things to come and so yeah we should have clarity. >> All right thanks so much Tam. Um, so I guess going down this list, I don't know if there's basically trying to get a a sense is there anyone that feels strongly that we would like if the it seems that people are converging on this idea that we would really work on two dev nets at a time.

Is there anyone that is adamantly against that or is there anyone like because it should only be a single DevNet or anyone that is adamantly against it because they feel like we need to have the ability to grow that scope even more. Okay, good. So I think that you know having consensus around the fact that we're going to be uh you know working primarily on you know the the one implementation DevNet and then you know the people that are more focused on specs are going to be looking at the research and the specs for the the coming DevNet is fantastic. Um and I think that that I want to do what I can

to make sure that the structure of this meeting better reflects that. So rather than probably having this kind of um persona based structure of clients research uh metrics so on so forth um I think it would be best to just like really focus on implementation you know devet in at the start of the call and devet in plus one at the you know beyond that if anyone has any thoughts around that I'd love to hear it um and So I guess the other the other place that I would also like people to give some real thought to is item number six on this

agenda which is comm's consolidation and async comms. Um I'm noticing that we have again this is kind of an organic effort that started um you know by you know creating this telegram channel. It's called post called postquantum and that's meant to be like the center focus of this effort and it's actually like one of the least used telegram channels because we also have like a ream channel a channel. It's great. All the teams have their individual channels but then there's also like kind of a a lean specs channel, a lean devet channel, you know, leads um all of these different forks.

And so um I guess it could make sense for us to uh kind of level set and you know there there there I don't know that there's any one golden you know silver bullet when it comes to these uh problems but there is an opportunity to either say hey we could really lean into discord where normal uh kind of DevNet efforts and you know consensus spine efforts uh take place in the ETH R&D uh server and we could have we have a the postquantum channel there.

people could really start to utilize threads and all these threads could take the place of these sub Telegram channels and that could be one path to help like consolidate these efforts and really people become much more diligent about referring to ongoing discussions and this like DevNet in DevNet N plus one uh you know shorthand. Um, and we could also just take the opportunity to create a Telegram channel that's a bit more robust that has actual threads in the Telegram channel. So, if there's a way of working that people are naturally just wanting to maintain, I can't imagine that we're going to be we're

going to find unanimity around this. Um my decision or you know like my advice would be to like either have a multi-threaded discord you know channel or a multi-threaded telegram channel rather than having a scattering of channels with different people in different channels and so visibility becomes difficult and conversations can become redundant. Um any thoughts on that? Yeah. >> Yeah. Um just two thing like one about like the topic we've mentioned before like before the meeting who shared this link where for example that is a way to

classify as I mentioned before um with like milestones and tags. So that for example if you go to this link you have all of the pull requests for example linked to the dev to the devet one and so you can filter by this and check PR by PR if you are okay with the spec. So yes, that is just a side comment about like the way we can better classify things and so I think that from right now I will make this mandatory for all of the PR that I am doing and I will try to do very uh focus on this uh to be able to retrive thing about what you mentioned will um about the the

discussion for for me that is a very important topic especially for technical discussion. Meaning for lin we have like indeed a lin a linspec channel where we are discussing technical uh topics. So that could be code exchange. Um that could be uh spec exchange uh sharing like links uh between teams and I feel like for me doing like Discord uh thread or like big Telegram groups with multiple sub discussion for me

that is the same at least personally we could use both. Uh this is perfect but um what is very important is to have this notion of thread where we can have separate discussion. Why? Because for example if we want to discuss both with a team A that is uh that is about devet one and a team B that is about devet three for example. Um if we do that in the same discussion this will be a mess because some of you guys will ask question about like devet one and some other will respond with the mind of devet three and so this will create big

confusion and that is not what we want. uh but instead if we have threads and we can uh directly answer to the question uh then we can have like separate discussion and be very clear and very independent uh in term of discussion I can for example have a thread about the team a that is with devet one and discuss devet one feature only with the mind of devet one and have another channel about a team that is deet 3 and discuss in this channel only about dem 3. So for me this notion of channel is very very important and we can do that on telegram on

discord but we should have this for for me because I think that currently in the lindspec dev channel um probably this is a big source of of confusion between all of us. >> Thanks so much. Uh Katya, >> yes, I've been supporting Discords as well because I also uh feel have this feeling lack of threads. Uh and another point uh why I vote for Discord is uh that we may have user groups in Discord.

So for example, if I want to tag only clients, so I I know that there is like client group and even if in this channel there are researchers or like um other people like uh contributors, I know that um these messages for client teams and I can tag them and if you worry about um a lot of notifications from the discord, it's it's very flexible. So you can just spend I don't know 30 minutes and mute all the channels you don't use and um for example unmute only if you are tagged so it make um less noise so if you care about notification it's very

flexible. Thank you. >> Thank you Kasha uh gadender. Yeah. So, I generally am more in favor of Telegram because I feel that Discord is bloated and uh sort of more noisy. But if we have outgrown Telegram, which it seems like we have, then it probably makes sense to go to Discord to be more efficient.

So, I'm fine if we want to move to Discord for all the benefits that have already been articulated. Ka >> yeah I forgot to mention that there is also opportunity to make kind of private chats if like if if it's too noisy if that makes sense uh even though we are in public so it's just for discussion so at least uh there is this option to reduce the noise if it's uh we can start and then we'll See, >> awesome. Thanks so much. Uh, okay. So,

I I've got 20 votes on Telegram versus Discord. Uh, unfortunately, there's no like clear winner. So, we'll continue to uh keep an eye on that. I I do want to make time for some of these other uh artifacts that are just as important and ways of working coordination tooling. Um O is there anything that you've been instrumental in uh creating these milestones and the highle docs? Um you know last week uh Mercy volunteered to put together uh the readiness checklist.

there's a a link to a draft I believe in in the comments um which is really great. I think the instinct is to like consolidate that into those highle documents. Um and also Tom has uh sort of circulated some of the the comparison matrices that are seen on say ETH proofs um to like really kind of help give people a visual understanding of you know client parody across uh devets and the different uh test cases. Um is there anything that you can share with us in terms of uh work that's you know what's working, what's not, what could be

improved uh along those lines and of course anyone else uh feel free to jump in on you know PR visibility coordination tooling uh things of those nature. Um, for me, I think you and Toma already covered um everything that I made, especially on like the the GitHub labels and milestone. Um, that pretty much captures um what I was doing. Um I guess on the checklist. Um yes, so I I don't really have any any strong feedback on that. It looks good. Um yeah, the only concern is that it's uh it's where where to place it. I would prefer that the

it's merge or somehow stays inside the the PM repo so that everyone has like you know access to to make pull requests on it. Um and then it it it gets yeah it it can be referenced for as long as as the PM repo stays. Um yeah, pretty much that. And I think um from from what Thomas suggested like something similar to to east proof I think Mercy already has a tables close to that. So we could also just basically yeah just use that in in the document.

Um if you want to show that somewhere I can just get lean road map to just like read from GitHub um repo and then show that on the website. Um that's that's possible. That sounds great. Um, I think in the spirit of just iterating and uh shipping and you know trying to improve upon things um because we're all working in Telegram and like right now I'm looking at the poll

results basically I'd like to try a couple of weeks maybe if we give ourselves from now until a lot of us are going to be together in can uh where we can like have an even deeper retro to like do this next iteration on the way that we work uh by just saying okay we're going to create a a discord that has multiple channels in it uh we're going to restructure this call to really reflect you know the devet in devet n plus1 work uh we're going to you know really try to uh drive this call from those milestone views in GitHub. We're going to merge in those readiness checklists into the highle documents. Um

basically uh start off by trying to make those uh operational improvements and give it you know a couple more weeks and then um you know into March uh we'll be together we'll have ship uh hopefully two more dev nets and we can um kind of you know determine if we want to take any additional steps to uh adjust even further. How do people feel about uh feel about that?

I got one thumbs up, two thumbs up, three thumbs up, exploding thumbs up. All right, so we'll give that a shot. Um I will you know probably um circulate a couple of uh channel options with people for setting up the Discord or sorry the uh the Telegram and um you know we want to keep it very lightweight uh allow it to just kind of like uh develop organically but to not have channel creep. I think that anything more than like eight channels is gonna overwhelm people and

we're gonna we're gonna lose a separate Discord server. Uh sweaty emoji face. Um all right. So we will uh we'll take it from there. Thank you all for uh entertaining or you know being a part of this uh coordination conversation. We've got the the breakout call tomorrow. Um, anyone want to make a last pitch on what the topic is and uh I believe it's all DevNet 3 specifications and then if anyone wants the invite and they're not on the invite uh who should they reach out to?

So they can reach out to their team's lead or they can just uh DM us me or O I think. >> Perfect. >> All right. Thank you all very much. >> Thank you everyone. >> All right. Have a good one guys. Thank you guys. >> Thanks everyone. >> Bye. Understand?