FOCIL Breakout #1

Transcript

uh yeah thanks everyone for for coming I actually didn't really expect that many people so but it's great um there is no like not like a super like hard agenda for this session I think it was more about like um can of uh introducing everyone that's been working or is interesting in in foral um but there is like a couple of things I would love to have at the end of this meeting um okay maybe we should start with like some broad questions on like the actual design and and maybe like the the research part like are there like any outstanding questions or like

people are people like wondering uh what's going on with like the the design um is everyone familiar with it like are there like any questions on on the actual like research and design set of things or can we actually move towards um discussing more like implementations and and and the different clients and and who is going to work on what I think the one question I have is uh is there still going to be movement in the spec it seems like it's fairly well defined but do you guys expect um more PRS uh um so okay so on the spec itself on like the design itself I don't think

there will be much changes is to be honest like uh we were like going a bit back and forth uh when we were like trying to figure out where whether we wanted to maybe make a push for fil to use transaction hashes instead of full transactions at some point but um seems like we are going to settle with like full transactions and that's actually how the spec is right now um it's worth mentioning that the spec is way I would say like more established on the C than on the El side right now um but I I don't think like the poor principles behind like uh how things are done will change uh it's just about like maybe

maybe making like the E spec a bit more like like an actual PR rather than just like a formulate it uh as we did in the a the size limit for full transactions uh so it's a kiloby per I and we have 16 I committee members right now in the SP I guess it would be good to clarify the things that we're not going to include in this version one like uh blobs for example yeah blobs are not included and I mean another like uh thing that's not

included is a reward mechanism for committee members right now we just rely on alistic participation I think it's worth mentioning because uh I think it works fine as is because we have like cool properties like for example like we only need one I Committee Member to actually participate honestly for the mechanism to to work as expected um but yeah so it won't include blobs and it won't include like a specific reward mechanism uh for I committee members right now yeah FR franisco do you want to

maybe talk about uh yeah just uh basically something that is not quite done in the in the four Choice pack um which is not just specific to Fossil it's just one of these things that keeps you know for years sort of being a potentially interesting thing to do that helps this or that thing like it would be nice in pias as well potentially be nice in other in other places like epbs if we ever actually wanted to do that um is this basically block slot for Choice which is essentially uh the ability to say um I don't want this block to be to end up canonical and yeah basically saying if there is a majority of uh

people saying that um actually rejecting such a block from from the force Choice more or less uh so right now we don't have that and and that's the enforcement part of fossil will basically uh need to rely on something a bit weaker which would basically be that um if you don't get enough votes then the next proposer uh can reargue with with proposer boost um so it's it's a bit weaker because for one thing the kind of threshold to be reor is is um uh lower like or sorry higher like you you can um yeah I mean basically it's you don't get like a um honest majority kind

of uh level of of of security for this enforcement mechanism uh and the other thing is just that the next proposer might just decide not to do this like they might be colluding or whatever and so right now that's that's what the enforcement model is it's a bit weaker and we might eventually decide to to do this uh more like for Fortress construction which among other things would help fossil but um I think it's not like super urgent thing and it basically doesn't really touch any other part of the mechanism it's more like this kind of separate four Choice mechanism that that just happens to also help here um so I don't think it's really particularly yeah important to like to worry about this in terms of stability

of the spec yeah cool no that makes sense I I do feel like I also saw it like as a maybe separate EIP but we could also think of it as like a bundle if it actually help with a few upgrades we want to make uh at the same time um yeah does anyone have other questions on the design itself um it's properties attacks like anything that is uh on on your mind okay great um then we can maybe go

ahead and see who wants to do what which is a more of a coordination question but I think it's quite important right now cuz um so FAL co-authors I guess have been like started to work on some uh kind of implementation uh specifically uh we have Jacob that has worked on kind of the W and Lighthouse uh prototype I can link his note in the chat uh and then we have jiun that has been making progress on

G and parents that made a bit of progress on on prism as well so I think it would be important to like signal interest but also like commitment uh in terms of who want to like contribute on the fal implementation on what client and what what kind of like uh yeah what is how much time will you allocate to to this basically and then there were some good comments I I'll preface this but like yeah there were there were some good comments on um maybe like gev yeah will want to like focus on shipping p

and and and P which is completely Fair um I was thinking like we do have like some external contributors that are not C but that still want to contribute and help out so at least having like um some my kind of key point of contact people that external contributors can reach out to when if they want to help on a particular client will be super useful it's actually a good thing maybe we could post in the notes or in the channel and pin it is who's working on it for which clients um just to make it easier for us to interact if necessary

yeah um but maybe even here like who maybe just like can you don't be shy or maybe just write it in in the chat but like if you're interested in actually working on it um it would be good to like signal it here yeah from from te side we have been interested since the first version so ofel that kind of failed initially with several problems so definitely we are interested to to allocate some time uh following and maybe time to do some some experiments on on on this and maybe some interrupt but uh so far

I can't uh evaluate how much effort we going to put into this is something that we will start sharing uh into internally and then we come up with a kind of an allocation but definitely we would like to start working on it seems like is a definitely more um Yes stable spec uh because the initial effort was been a a little bit of a a way a waste of time because we started and then suddenly we got several problems and stopped but now I think this is much more mature so yeah that's

something we want to do okay great that's awesome and then uh will you be like the kind of point of contact person yeah definely I can I can be uh for sure uh for uh aak time zones uh poll will be probably the the one but wa we can reach as when um yeah I'm I'm already in the Old El uh channel so okay great yeah yeah that's cool yeah sometimes it's just about like uh people coming in and wanting to I don't know like ask a few questions

about like a resources or like places to where it's best to make their contribution so it's it's great to have sure sure you welcome to to DM me or ping me there okay work in progress pool request on on go etherum makes uh sense for sure um anyone else maybe Jun do you want to talk to talk about like what the the progress

you've made and maybe where you're at cuz you been working on get a bit right uh yes um so the get prototype implements actually quite most of the execution specs but it hasn't go through testing yet so I'm planning to run yeah and prism locally starting next week and um uh for the execution specs that the get prototype is uh it it follows it can be found at the link that I attach it at the chat

um so they are all implemented with its own unit tests but one question that I want to ask to El developers is that uh so there are three new engine apis and one of them is new payload V5 so and and that API checks if the new given payload follows in collusion list constraints or not except when the node is syncing so the El needs to tell if the node is syncing or not uh we one possible option is to use time and field of execution payload but I'm not sure if this is the convention of el to figure

it out so yeah no I mean in general we the node kind of knows when it's sying but um yeah I mean basically during the initial I me the the engine API is also the trigger for syncing so that's something to keep in mind it's like when the client starts up it's basically not syncing but then once the engine API is triggered and it detects that the block is the head block is kind of ahead then it will launch sync so then it's like but the there is like especially in G there isn't really like this central

place that manages the syncing status so that's maybe something that you are missing or if I understood correctly if that new payload V5 is called I can just safely assume that the node is not thinking I'm not sure about that assumption to be honest I mean they basically the engine API just gets called all the time but it's up to the execution layer to decide within if it's like currently in syncing status yeah and and cl calls uh El uh new payload even to do some basic

validation that doesn't can be done even if the node is um non syncing so does some checks over the block and then returns uh syncing and then goes into optimistic sync knowing that the Y is still doing his job and needs to take care of that so let me jump in and clarify uh Jin's question so um so basically at fossil there is this new constraint that the inclusion this constraint actually is enforced at the slot of so meaning that given the

current time samp we know what is the current slot is right so basically and this is only when the inclusion this matters basically so to clarify the question the question is more like uh we do not want to check inclusion this if it's not the current slot and whether it's okay to add that responsibility to the e mean mean that when I call new payload I don't want to check anything about inclusion this if it's not the current slot does that make sense yeah it's kind of a weird

constraint to be honest like I mean the the execution layer only knows what's the current slot based on the request it gets from the CL so I mean it has the head which is sort of the the latest and but it doesn't We There is never any place where we check like is this the current slot based on time okay yeah I mean that's a fair feedback so but again I think that this is just the first like breakout Cod it's probably too early to like dive into this type of implementation detail so maybe we can like uh yeah maybe we can I see Jun who has like a hack MD on the

engine AP I execution spec so maybe we can like uh he can open a PR and we can just leave the feedback there and go from there I mean I guess just fundamentally maybe just to to dig into it just a tiny bit um conceptually there are two different cases in the engine API right I mean during when the when the CL triggers the engine API for the first time and the El node is not synced then it will enter the syncing state but then once it has synced we kind of enter this other phase where we extend the chain in the e one by one and I guess in this mode we do want to actually enforce the inclusion list so

perhaps yeah I mean we does it matter like I mean is it okay for the El to just decide it by itself when it will apply these rules or is it something that the consensus lay needs to have a hand in as well I mean is there going to be something like a flag from the consensus there that says uh please validate the ex the inclusion list for this block right so I think one way to do this is just like uh if the CL passes the inclusion list then you check if the CL doesn't pass it then you don't check so let's CL drive it and then the other design just we we can let the EO drive it as well meaning that if it's a

current slot then Co doesn't has anything then something's run then basically you will return error I honestly don't know what's the best way to go about this I am not like an engine API like expert in this regard but yeah I I guess this is something that we that we should get feedback from you and everyone else y oh yeah we will open uh PR and yeah be yeah be feedback all right so I will open up PR to gas repo following what we just discussed uh so the El will just trust CL about the

IL constraint so CL has a responsibility to pass iil only if the payload is for the latest slot okay that sounds great uh maybe a more like high level general question is uh how important is it to coordinate efforts between C and and yel like uh I mean we we've just seen it like you have like some crossover and like some questions but uh like do do both need to move at at the same speed or or not and same question with the with clients like uh do we we do we try to coordinate so

every client like moves at like sort of the same speed or should just people move at their own Bas and and other can catch up I think there's like two ways to do this I am sort of tackling the engine API first just because I think that's probably the part that's to me seems most most like complicated in a way so I think it's important to have like a good engine API definition that both CL and E agree upon so I just asked like Jim whether he can open a PR against the engine a repo and people can review that so I like for example u i i i i was

reviewing J Jacob W and there's like some discrepancy between jinhun and Jacob for example for example like Jacob he actually uses the payLo attribute to send inclusion this to the e meaning that once you do that it kind of becomes a net slot inclusion this property versus the current slot so yeah so I think it's kind of important to agree upon those detail so we can kind of um yeah so we can move towards the interrupt I guess I guess I guess there is another way we can go about implementing it that is just like Implement CL first just do the sync and do the validator client stuff and then

do the engine API last again I don't think it's a right or wrong way of doing this I mean it's also personal preference but for me I'm doing the engine API first okay great does anyone else have like an opinion on this or now it sounds like basically it's a matter of of preferences but maybe it would be nice to have like some coordination at first and so to move faster afterward speaking of move faster is there a timeline that would' like to set for uh

first evnet does anybody have a sense of how long implementation is going to take two weeks three weeks two months 10 years um I guess for prism I probably can do everything within let's say maybe within like within two weeks I mean it could be faster but I probably should pay more attention to Petra since that F5 is like slightly urgent but yeah I think within two weeks is very feasible to have some sort of basic interrupt working although that would get into the holiday so maybe end of January then

give people two weeks in January and then two weeks factor and shoot for initial timeline of the first death net say end of January maybe maybe I don't know people are also more than welcome to try local um death net I think like kosis for example is very feasible possible with that but yeah I think end of January sounds feasible there's uh any other person agree on the timeline okay enrio said makes sense uh what about people on the

maybe so I think it's also like about like the the question of like who amongst like the client devs um might think they won't have time to do it and would like to need help help for from external contributors yes so from NE mind uh I'm not sure who will be implementing it we need to discuss this it internally but I think end of January it's like a month and a half from now so we should be ready to to have someone to work on it and to to have something to to be able to join the that net

okay nice awesome and are there any other clients that are here yeah g I guess Felix or I mean we don't have we we literally have not looked at this proposal at all so for me it's just kind of something new anyway uh I know that um I think Gian is working on it yeah so I guess we will just just check out the diff there and then also just let see what's the scope I would just be very interested to hear from the experts here uh on this proposal what is the extent of the execution layer changes that is required could someone just give like a very

brief overview of like what the execution layer needs to do in this scheme so yeah so the execution layer needs to provide in Collision list when the CL requ request for it uh the exact construction algorithm is not specified but current G implementation just order member transactions By Priority V and then uh pick them up up until it reaches 8 ktes and the next thing is El needs to for testers El needs to verify if the payload follow those I constraints so it

checks if there is any transactions of inion list that is not included in the payload and if such transaction is found then it checks if it is possible to append the transaction at the end of execution payload so if the block is not full and if it is possible to upend the transaction at the end of the payload then the the payload is not following I constraints and the Third change is for proposer you need to hear all iil

submitted by iil committee members and then make a one inal list to pass your uh yeah so you need to pass that inion list to update your payload in the middle of building process so that changes um the the building how can I say like building building process currently implemented in the under minor. go file and yeah so most of it sounds like most changes are basically in the block construction so this is basically just coming up with the inclusion list is

what I'm understanding like that's that's the the most work but there must also be some place where we basically then validate this like inclusion list constraint in the block yes yes yeah yeah there is a particular way of of checking whether like transactions are valid that we kind of specified not as an naturual spec but like the rules are specified in the EIP and then maybe like it's a good uh place to mention that we um have ideas around like the inclusion rules that should be used like um because you know you can you can build your inclusion list based on many criterias and we want

a diversity of criteria to to probably uh be implemented there so it could be you know based on like the time transactions have been pending on on the M Pool uh and then like order by priority fee for example so we can we have ideas of like default but um yeah but it would be nice to mention like ideally we have like different clients uh that can Implement uh different uh rules because it makes the whole thing just harder to game okay so basically there's also some

Freedom of Choice there for the clients to come up with the incl like the freedom is in like coming up with the inclusion list right or yeah no yeah exactly yeah yeah so how you build your inclusion list in the first place there is some Freedom there I think we okay some attacks like we have thought of like very specific attacks like kind of mol flooding or like fossil flooding we have written about this quite quite a lot so we have like some defaults we have in mind but I think ultimately like coming up with like a A diversity of of rules as default is um will be like also something nice to to do uh yeah but yeah the freedom is in

building the inclusion list into space all right thanks yeah this was very helpful for me yeah and then to follow up on what do you one side I think most people uh like a testers The Proposal I mean they all have to basically do the same thing which is like monitoring like inclusion list that are broadcast by commit members and like making sure they they see the these inclusion list so they can either like propose an execution payload that follows the constraints or um validate

uh whether like the transactions in the IL were actually included in the payload and um determine whether they want to vote for it as a test I see there are some discussions in the chat about the actual size of ILS uh yeah what do people think I scrolling back now okay so I guess y 16 and why 8

kiloby it was a general puristic based on uh uh uh how much bandwidth you want to dedicate to to in general I guess that's what French was said uh so we just like didn't want to add like a too much load uh because every validator like every attester and the proposer will have to to run this so we don't want to P but like too much constraints uh especially on the bandwidth I we know it's already quite uh I it's like a Bott

n and yeah also seeing the IDE is targeting faka um just want to put it out there we'll see how it goes and everything but uh that's like the general ID we have in mind it's actually a really good point I mean we are in full hard Fork season maybe maybe that is to aggressive end of January to go February March to be realistic wait can you repeat sorry uh so it was uh Lucas brought up that uh we're in hard Fork season trying

to get to pectra and maybe it is kind of silly to I mean it to rush it or or to push it with such priority maybe February is better end of February yeah uh I mean yeah I'll let you all decide on how you want to to work on this but I feel like there is some kind of traction behind it um and I would leave it up to like people to see whether they want to to try and and move forward with this but uh yeah um I I think like you everyone will work at different speeds at the end of the day in any Cas right also plus one to that I think

like I I don't think like there should be like a hard deadline saying that like we must interrupt by then but I think what's more important is some sort of incremental progress that we have people like continuously looking at that at their free time even though it doesn't sacrifice like what is a priority right now which is Petra so basically if client team has free resources this is yeah uh just basically looking at this spe understanding the problem is very important yeah um I want to second that I also that's also why I mentioned like if like any

one needs like additional help help from external contributors because I feel like it's it's better to have like this kind of continuous iteration towards uh like a devet we all are comfortable with rather than having sort of breaks uh between the development and and the research and the whole process so I'd rather have like um clay and Dev saying well no we just want to focus on like the hard forks and and and shipping things right now which is completely fine and but then I I would love to maybe like find someone else to like try to start making progress and and maybe then they can review it rather than

having like this huge like breaks of like two month and nothing happens because there's a half for and then people have to get back on it and I don't know you lose a bit of the of the continuity maybe we take the approach of uh have another call I don't know if two weeks is the right timeline for the next call maybe we do you know two weeks into January just because the holidays are are right around the corner and then we can discuss timelines uh see who's got forward progress in order to maybe do some private net Dev Nets or or you know setting up kosis yeah uh I feel like maybe yeah start like first week of January might

be okay like or first or second like start of January after the holidays are all p and everything reconvene so that be in like yeah a bit more than than two weeks we can say like three three weeks cuz it so it doesn't actually fall like like real holiday times but uh uh how does that sound like let maybe aiming for like the first week of January or beginning of the second or something yeah I think makes sense I can keep working on G to save their resources if it's okay with gath team and we also have I'm not sure about uh Jacob's progress but he's also working on light out and red

so um as long as we have some rough conent on the engine API specs maybe we can try to run DEET with two CL and two Els do you have any spec tests for the fossil or any kind of like hi integration testing I don't think we have it yet no I haven't seen it yet yeah I mean I just feel like that that is a little bit higher leverage

than doing Dev nuts because Dev nuts are especially at this this stage it's like what what can you really test and you can't repeat those tests that easily so it's like you made sure that the clients can speak to each other like you know kind of smoke test verification but I feel like we put a lot of efforts into these Dev Nets at early stages and I think it takes a lot of time to get this thing working and the time might be like morei if some test are written in Hive where the clients who are imp putting fossil just know that they could run

against Hive and once they pass this test Suite that that's like relatively good coverage no I mean the most important thing is just figuring out how to even test the application of these roles I mean since the heuristics are kind of arbitrary in the clients I mean I guess there must be some boundaries for what they are allowed to do in the inclusion list uh I'm not fully familiar with the proposal but if the client comes up with like an an inclusion list that's impossible to satisfy then I guess yeah I mean that that is also something that shouldn't really happen so there needs to be some kind of testing format that that basically make sure the clients behave in a sensible way and Hive is pretty ideal for that because you have the full functionality of the CLI available so you can send

transactions to it and then check that they get included when block building and things like that so you can actually just test the whole mechanics of like integration of the client's transaction pool together with that and stuff like that but then there also just need to be some hard test for the validation logic where it's like if the clients you know are supposed to check that the transactions that were in the inclusion List have been included then that thing just there needs to this needs to be in the testing Pipeline and I'm pretty sure that at this point we need to get the actual testing team involved and make sure they can fit it within their format and things like that and they are definitely busy right now just building test for Petra so they will not be there

second week of January ready to you know create tests for this like for them it's very much like they work on the fork until the fork is over and then they start with the next so yeah okay yeah I mean the second Point uh second application makes sense like actually enforcing like uh that transactions were included for the first one I I agree with Franchesco the the rules can be a bit uh hard to test cuz like it's a bit arbitrary and like you can you could like construct um inclusion this with no rules or with random things and they will still probably pass but um yeah on the on the test versus like Dev Nets part of thing I okay so maybe

it will be better to start with test but like testing teams won't like will never be ready to implement things by mid January or end of January so given this like if if it's if there is huge discrepancy like a resource constraints from like testing to people that can actually build build devet we can Al Al just like go by that and have interested people build what they are what they know uh how to build and then uh when testing teams are available they can chime in because I also feel like maybe if we wait for testing teams to be ready and not build anything in the meantime

it um it might not make sense so for sure since this is a very very very engine API driven proposal when it comes to testing the execution layer we have to make sure that the testing infrastructure for the engine API is up to date and at the moment it is kind of in a bit of a sorry state in Hive with the engine API testing because yeah especially for G it doesn't fully work with these tests anymore even because we removed a lot of functionality around the merge so basically the GU of today wouldn't really be able to you know perform the merge again but the test kind of still

expected to so that is something that needs to be picked up basically before we can start creating these kinds of tests just to make sure that the testing pipeline is actually working for the engine API yeah but I will just relay this to testing team as well just because we I'm already in discussions with them around this awesome yeah that that's what I was going to say if uh you well it's great if you can actually relate this to them and maybe I'll also try to reach out to some people in the testing team to at least check uh whether they are available and and if they need help there

anyone go I I I just have one one other question I mean there are other eips like epbs or something like this that people want to include in the next hard Fork did somebody already have a look how they are compatible if they are compatible or or if there are any any I don't know any any issues or something like this yeah we we did have a look uh there are quite a lot of back and forth in the inclusion list channel on The Ether andd Discord already about this exactly um terance obviously has been quite involved in both both proposals so um but we we've all look at this and and at least if I remember correctly there

is no like inherent like incompatibilities between the proposals there might be like some small overlap in like the timing resources that are like uh well like the timings you have to adjust so that Force and and epbs can coexist this like without making like sacrifices uh but uh but there is no like inherent incompatibilities at all yeah to add on to that to add on to that I think it's better to treat them as different proposals don't like tily couple them but with epbs we do get that four Choice the block SL thing that Fresco mentioned earlier for free but also we could also do it as an

independent EIP as well so yeah I think it's better toat them as independent proposal yeah Matthew two small questions just from an implementation standpoint or discussion standpoint um does anybody have an issue moving this to Tuesday the call Tuesday the 7th uh so that is just for APAC it's 10 p.m.

on Friday night it makes it hard for the weekend here kind of a small thing if there's not a big deal um just a question and then we could do that in Discord um and then the second question is about uh just how the discussion happens uh telegram is a great medium but uh I'm curious if anybody else agrees that the difficulty of discussion in Telegram and Discord and Twitter and all of the the various communication mediums makes it a little disjointed uh if maybe we could avoid using the telegram Channel um just as a general uh point of uh discussion um and

move it to Discord to that iil list that uh that was mentioned at the beginning um and try to avoid the private discussion curious what everybody's thoughts about that are yeah I I agree I think uh it's also early enough that we can do that uh like if we can actually have a push and like everyone contribute in the uh Discord uh Channel instead of uh in telegram groups I think it's a right time to Signal it um yeah I think a good combination would be like Discord discussions plus uh we have this site uh that we will try to uh keep up to date let me link

it June actually worked on okay and um yeah what I want to do with this is to keep keep it up to date and maybe like keep like the different um you know GitHub BS and and uh and progress on implementation quite up to date there on like the different clients so people can just like go there and click on it uh so we'll probably dedicate a section to to that and update it according to to progress so it's we have like a common place that's kind of stable and not like a Discord like thing that keeps moving

on uh that everyone can check maybe a small C is like if any external contributor for example or more like Junior Dev is interested in contributing like still feel free to reach out by Telegram and like asking me questions or anyone questions like uh and then we can like take it to the public like it shouldn't be like a blocker for anyone to to try and and ask questions uh about the proposal in general or or implementation or whether they want to

help um yeah maybe leading to that cuz we are running out of time uh I know I I recognize in the call like some external contributors that signaled interest in helping um if anyone who like wants to uh say something and like uh yeah no it's probably a good time so if there are contributors that would like to prototype this in never mind yeah sure go ahead uh we we free to collaborate uh not sure if more much

people uh a lot of people know C though so might be a blocker right no but well that's that's good for you to Signal it though are people happy to sh I'm happy what what like what do people

think generally about about like the timelines and like the F oh if I can comment faka is already quite big so that's definitely like I have uh flashbacks from pectra right so when we try to cram a lot of things and we in the end had to chop some things and it looks already stretched yeah it's probably quite early

anyways okay uh man have just message me and say he is interested in maybe helping with the lighthouse so that's something that can work I will talk to to Jacob about it who's been working on it too is anyone from like house here no okay well I'll I'll just reach out and and talk to to Jacob then and then yes okay I see discussions about the the scheduling already of course I'm a bit biased so I would like also

to uh be uh shipped as soon as possible because I do think we have a quite obvious and big problem with sensorship resistance right now but um it's probably also like quite early to talk about it and would be nice to have um everyone like Lo in if we actually consider talking about the inclusion everything okay any last uh out standing questions or comments or otherwise we can just uh call it the end of the first foral

break uh so are we changing the meeting times um yeah I couldn't follow the the chat uh is can anyone like a speak uh I think Matthew asks if we can change it to Tuesdays yeah this is completely fine to to me uh I think I have a weekly and others have a weekly meeting unless I'm mistaken on Tuesdays uh weekly

yeah okay maybe let's let's like schedule the the next go first uh and then like talk about like a regular C Cadence but uh on Tuesday for the next school for example it would work and and then we can just go from there and I feel like it depends on the progress too like if if people are have like a lots of questions and comments and progress on the implementation might make sense to do it weekly but otherwise we can maybe like do it by weekly or something maybe that's something we can discuss on next go based on like how everyone progressed uh why don't we put a poll on the Discord Channel U and just put some times up and see what works for most people as that sound yeah sounds

great okay awesome uh yeah well thanks a lot everyone for attending uh I'm actually very excited about like seeing some uh some progress on the implementation side after like having worked on it on the research side for a while um so yeah it's it's great to to see you all and um uh let's meet after the holidays after the vacations and uh yeah thanks for being here