EIPIP Meeting #129

Transcript

[music] Heat. Heat. >> [music] >> Please >> Heat.

Heat. >> Heat. Heat. >> Heat. [music] >> All right,

let's Recording in progress. >> Welcome to EIP IP meeting number 129. Today is August 12 and the issue is added on Ethereum/PM GitHub repository with number 2159. On agenda, we have a a few call for inputs to be maybe uh looked into and then a few editors discussion item. We have pretty light agenda. So maybe we can get started. Um I know Sam uh you are on phone but would you be able to maybe talk about call for inputs?

>> I can certainly try. I don't know if you can understand me. >> Yeah, [laughter] we can hear you better now. Yes, please go ahead. >> Okay. Uh so first up we have uh allowing links to >> um unic code standards that still need to be merged. Um, don't know what that's waiting on. Probably just another editor approving it. Um, and yep, then we have um associate EIP editors. Um, which also just needs to be merged. So, yeah. Um, I feel like there are a few

other ones. or did we get those all merged? >> Uh I think there is one more which is open right now and that is um um strict rules for changing authors and the number is [music] 409. I'm I'm going to share the link [music] here in the chat for reference. What we can maybe do puja is uh if you could share your screen then Sam [music] can also take a look at your your screen.

>> That's my first uh thing and I have another thing because I want to directly ask this this is about [music] this uh EIP sorry this CFI which [music] is about allowing links to the Unicode technical standard and there's something very weird going on but I should actually reflect this earlier. [music] So this call for input is approved. Um yes because indeed Sam has also signal that that this is approved. Um and Sam has linked two uh links because there are two PRs. One is to ERC's and one is to EIP. And the thing is that I have approved both but only EIP's one is uh sorry only the ESC's one is being merged at the EIP.

>> Oh right there's a conflict. I completely forgot to fix that. I will go and take a look at that. >> Uh yes, but I feel that this is not entirely the problem because [music] the ERC one is uh Oh, wait. Sorry. No, that's not true. So, the EIP one also needs another approval from uh another EIP editor. So, that would mean that apparently we need three approvals uh here, which >> So, it's not counting me as an approval, right? Because I'm the EVA author.

Is that how [music] that one works? >> Okay. But would that mean that we need three approvals or two in >> I mean I I'm okay just force merging it if you are. I don't think we're going to get another approval on it. >> Okay. Yeah. Okay. That's that's [music] that might be. Yeah. >> Okay. I'll take care of that when I get back to you. >> All right. So the last one here is uh call for input for strict rules changing authors. Uh I'm just going to share my screen here. Strict rules for changing authors. I think the date is 15th of August. We do have time. Yam if you would like to briefly talk about what this call for input is.

>> Yes. So let me also open this URL. Um so the rule is or the well the idea is that um you are not allowed so this is already about the decision part so the office of an EIP are not allowed to change the offer list except [music] append to it uh and the reason for this is because um this is I think it's not a situation [music] has happened yet maybe I've written down that maybe some what looks like it has happened but Um [music] the thing is that I think that as an EIP offer you should be certain that uh you get a recognition of offering this EIP and there could of course at some point

like maybe not now but like in half a year or in a year or in two years there could be a conflict and maybe your [music] EIP is still in well let's say in in in review or in last it doesn't even matter then all the other EIP editors [music] sorry I must be correct all the other authors of this EIP then have the merge rights to um to delete all the other offers and to basically to take this EIP hostage. And what I mean by that is that there's like a conflict between the EIP uh the office of this EIP and um but uh like you can do this like very impulsive uh well the situation does not matter but the thing is that all the people on the authorship list can create a PR where they remove

all the other authors uh [music] and uh then basically take are then the only person who has like merge rights to this EIP. I think that we should prevent this. If you want to remove an EIP offer then uh either you are removing yourself and this should be also strict like u like how how do you prove that you are this person? I think that one of these um well the situation like another way to remove an office is like maybe you have updated your email address or something like this. Um [music] that might be more of like a side case but the thing is that um if you are on this offers list you do not

want to get removed because I think this is uh this is not right. The only way how you can be removed is [music] we check with this person like okay we have this PR open um and um they have to give their explicit approval for the removal of their um their um well them on the offership list and with then also the explicit [music] knowledge that they do also remove their merge rights to this EIP. Yeah, I'm >> Yeah, please.

>> Uh Sam, uh please continue. >> Sure. Um, [music] I'm like I understand the reasoning [music] behind wanting to do this. I am not convinced that I want to, but that's not to say that I can't [music] be convinced. Um, because right now we have kind of the the permission model of you only add the authors that you [music] trust to your EIP and um then everybody has the same permissions. Whereas if we [music] um for example kind of like if we do it so that you can only remove yourself from the author list then um I think there's

a lot of opportunity for conflicts that we might have to step in on like let's say that you know there's um a split among the authorship and uh the authors may want to divide into two EIPs and half of them want to keep the original EIP and the other half, you know, both halves want to keep the original EIP number and then we have to step in and make a decision there. Um whereas the system we have now, everybody just um has full rights. So they can the f first one to act gets it.

I'm not sure that's necessarily the best [music] way to do it, but it is an objective way to do it. Um and I guess it's important to note that what we're really protecting here is ownership [music] of the EIP number. itself uh and the ability to modify that number. So like let's say um I remove um you know John Smith from my uh EIP number, they could just open a new EIP with a new EIP number of the same content removing me. So what we're really protecting here is just the EIP number and I'm not sure how valuable of a resource that is. Um yeah.

Yes. Okay. This [music] is actually like like I think two very good points because I would like generally agree that we do not want to step in uh in new situations. So um yeah, this could indeed lead to more complex situations. Yeah. Okay. It's is actually like a very interesting point because maybe I'm like also flagging this thing because maybe I'm I'm okay I'm I'm thinking a little bit because [music] you are right like the only thing what what we are doing is protecting the EIP number but I would also say that that this itself is maybe like um one [music] of the most

important things here because if at some point you uh you get a conflict and [music] uh there is an EIP which gets forked because of this because it's like a personal conflict between two of the office [music] and then one of the EIP is gets still and and this original EIP um gets uh still [music] and then this new EIP uh is the updated version I would say like like the actual version updated version [music] and this of course leads to confusion. Uh the question is then is this our problem or is this a problem for the community? Um, I guess I don't know. I I think that's indeed like a problem for for the for

the community. Um, but also yeah, I don't know like like like we know that the numbers uh I mean we recently had like a confusion about a certain number like I think this is something what is like very important what we should also recognize that this is very important. Um but yeah, I I think I'm starting to get convinced that we actually do not want to [music] create any changing rules for offers. Um and yeah, then the result is that it indeed will be like first come first served. So uh who opens the PR first and who gets it its merch first that that to remove everyone that's that's then the person who who

would win this this thing. But I guess that's a situation what maybe we should not even try to deal with. I don't know. >> Yeah. What do you think? >> I'm not sure. Yeah. Like I think it's it's definitely worth considering. I don't want it to sound like I'm just saying we shouldn't do this. I I just think that we have to be careful of the edge cases that that come up. um like like [music] I was just thinking about um like let's say you have uh an GitHub account that gets compromised and they don't want to remove themselves and they keep just griefing the EIP number. Um [music] and I mean that's that's an exceptional case that I think we can deal with just by removing them manually. But um just something to think

about. Yeah, I I don't know. I I do feel like we need something beyond just [music] first come first serve. I just I don't know what it is, >> right? [music] Yeah. Um Okay. May maybe just just thinking out loud because I think I'm I'm moving. Yeah. Well, maybe not like I I think that we should have something maybe maybe that's actually like a very good discussion because what you were saying is like this first confer I think that is um well good enough for now is maybe not the right term but but it it it works now. um but what he could maybe think of and of course this also [music] means like these ids have to be translated to

to uh to code [music] and sadly I do not have a lot of benefits yet to to to help on that. Um but the thing is that we maybe want to introduce something like if the like if an offer gets removed or something that we put this uh thing on hold uh for like a spec well a certain amount [music] of time um and that we can then quickly sense like okay if there's like no how do you say this um yeah not not not a blocking but if if there are like no objections then we can just merge it but if like someone opens an EIP, they remove another offer or like more offers, then I would think that the community would quickly flag

this as oh wow, this is very weird. And then maybe this this uh like we give this like some waiting period and then after a week or like two week, we mark this with a specific label. I don't know like what the correct term it is, but that we uh that this is being disputed or maybe that that's like the correct term, but but something like like this. Yeah, that's that's a pretty good idea. Like some kind of [music] um you have x amount of time to object to being removed and then if you don't you get removed. >> All right, for now I think uh anyway it has a few more days left for reviews by other editors. So let's keep it open and

keep [music] the discussion continued on the discord channel and hope to get more responses by editors [music] in order to like decide where we would like to move forward. Um with that we are done with call for input. Maybe we can get uh to other items which are there for editors discussion. Enable bot check to check requires EIP status. [clears throat] Let me see what was there.

H come I think it is coming up from uh your discussion thread that was mentioned here. >> Yes, that uh is that up and running now? >> I have not tested it particularly. I don't know if it was tested by someone else on the call. If not, then maybe we can get back to it. Yeah. Let me quickly check what [music] this is about because I should know this because I apparently open over open over open over open this uh this this discussion.

Um >> yeah. Okay, it's I think it's about um [music] final status having references to non-final EIP and ERC. So uh uh apparently the bot was stopped to check uh that uh particular check that uh the PR status should not be uh is not important but uh I guess Sam has enabled it again. We might have to revisit and check if it is flagging any new proposal. Is that the correct understanding, Sam?

>> Uh, yeah. I believe I merged the poll requests. Uh, reenabling that. Uh, I'm just not sure if they work or not. I haven't checked. >> Okay. Um, it is on EIP repo, right? I I think it is working right now because I recently got a flag on this one and I can get back to you on that part, but that was >> it would be on both. Um I think the problem was that it wasn't checking on the ERC's repo. >> So hopefully it is now. >> Okay. All right. Uh so we will consider it to be done unless we come across any further cases of that or maybe we'll go back and check on that particular EIP if it is still um getting an easy pass or the bot has

enabled there. Uh all right. I think the next one is from the previous meeting. In the previous meeting, we discussed about an uh an action to be performed by EIP editors and that was with respect to an like not approving active EIP PR. Um generally the PR merge policy suggests that if a PR is open for over two weeks and it is like trivial changes and editors are convinced that those are fine, it can be merged. But it was decided that active EIP PR for which uh >> um authors can be found around should not be merged. So um in this PR I have

done three major changes. Number one I have tried to move the don'ts to the don'ts section. That's why you [music] can see all these reds and all these reds are already added here in the don't section. Earlier all of them were listed as parts of dos. So that's number one change. Number two change that has been done here is do not selfallocate EIP number to your proposal. So for a recent proposal 8363 it was noticed that author self-allocated the number 8361 which was already allocated to a different EIP. So I requested uh the author not to do that and he highlighted that he could not find this piece of information anywhere.

I did mention him that EIP editor or associate editor are the responsible person to provide this uh EIP number and it should not be self-allocated. [music] uh so his suggestion was like we should document it and that's why it is being added to contributing MD under don't section for author and I have also mentioned that uh they should wait for EIP editor and associate editor to take a look at the PR and get the number and the third thing okay yeah these are the three things yes please >> yes um about this this because this point what uh What happened with this EIP 83? Well, I already forgot the

number. But uh the thing is that indeed like if the offer and um I think that is actually correct because we are not like um it's actually like a very good question because this is Sam also mentioned this that's like just now like the EIP number is is maybe like one of the most uh the biggest thing what [music] we want to protect because if it goes out into the community like this is what people will talk about [music] like EIP X EI and if there's confusion about this like This is especially what at least I or I think that that we do not want and the office should also not want this by the way. So the thing is like how can we make this even more clear that uh people should not allocate their

[music] EIP members themselves. Um I would say that yeah I like I actually don't know because if you open a PR like you get like a sandbox [music] template uh or like a template comment what you can edit. Uh, I think I hope that people read that, but that's of course a question if people do that. But I also don't think that there is text in there which talks about the EIP number and I'm not not sure. Maybe Sam [music] you notice. >> I do know, but I can certainly add it if uh if it isn't there. Um, and we can also adjust the message that EW [music] prints out so that it says wait for an editor to uh to assign it if it doesn't already say that. Um, and the template as well.

Yeah, it seems like uh some of the peers are now coming up from bot, [music] right? Uh this uh clearly says that generated with cloud code. I don't know uh it [music] if it was from bot, but they definitely did not know the process. So in order to like facilitate uh this understanding, it is a good idea to have this mentioned at multiple places. It is already mentioned in the EIP1. [music] Sometimes new authors read it and sometimes they don't. But it does specify that EIP number allocation is the primary responsibility of editor and uh I'm just hoping that this contributing MD if it is being uh revisited by the authors or new authors should also contain this information and

having it on the EIP template will be a nice addition along with the message coming up from EIPW bot. So um this is um small corrections added to contributing.mmd. It would require at least two reviewers to approve and merge um the sharing in this meeting. Kindly take a look at it and yeah we can get this merged. >> Yeah maybe to quick yeah Sam please. >> Oh yeah yeah I can add it to the um the template [music] right now. Shouldn't be too hard. Awesome.

>> Or or rather to the the pull request. >> Cool. Cool. Thanks. And maybe like I'm I'm not I'm going to propose like one thing and I'm not really sure if I want to propose this, but I will just say it because I'm thinking about this like now like u we had like a CFI uh lately about um adding like AI office where I said we should not do this because we do not want to promote any commercial product or any product at all. But what I do think uh because it is very likely or at least like super likely that the new EIP text are like well mostly going to be written by AI [music] u we can all have an opinion about this

that does not really matter but what I do think is that uh an AI should [music] know and an AI I mean in large language models LLM um should [music] know that they should not and they the LM should not allocate a number [music] to the happy. Um, but in order to do that, I think my uh like my proposal will be to [music] add a uh I do not know like if there is a standard for large language models [music] um uh files where they directly read from like I know that this is from cloud you have cloud MD [music] we do not want to add this I want to explicitly say but if there's like an >> there's um agents MD um and it's read by

I think copilot I let um codeex and oh uh chatgbt but it is not read by clog if I remember correctly. Okay, this this this sounds like a good thing because [music] agents.md is clearly not affiliated with any large language model. Um I feel like we should add like [music] an agent MD and I think we should just start with a very simple thing. do not allocate a number because this is like the the thing what we what what we want to uh to to to well to protect and that's that's also good for everyone because we do not want to have any confusion about these numbers like ESC this or EIP that we don't don't want that um I think I can open this PR um

and I will keep it in draft until I'm convinced myself that I want to do this but I think this is a very good thing what we should should do for both EIBs and ERC's >> I I've added a um GitHub copilot instructions file for code reviews. Um [music] just because I was getting really annoyed that it was giving terrible code reviews. Um so yeah, I guess we could do something with agents. MD. Um [music] yeah, I think that's a good idea. Um also I I can't make pull requests right now because it seems like GitHub is down. Is that happening for anybody else or just me?

No, >> GitHub is up. So, uh yeah, >> it's on it's on the uh their status page. Yeah, their [music] their poll requests are down right now. >> All right. Uh so I assume um Yohham, whatever change you propose is going to be with another PR, right? Um there's no blocker for this present one which is there to update contributing.mmd. Is that a correct understanding? >> Yes. Yes.

>> All right. All right. Uh so it requires two editors approval. Kindly take a look and uh yes we will move into the next one. So the next one is Glamsterdam Meta E73 to the review status. I know it's open for a while about a month now and uh um we were discussing like why we are not moving it to last call and still struggling to get it moved to the review status. So I'm still waiting on author's approval in order to move this proposal but I noticed because I was under impression that everything will be fine and it could be worked but I noticed there is another EIPW um bot check [music] and that suggested that EIP8066

is not in the review status. Upon checking it uh appeared that um this PR was merged 4 days ago that basically adds a mascot to the Meta E. Um it was unclear to me. It was unclear to me like were there any decision of including mascots on meta e or we discussed about it and aside that this EIP is in draft status so I don't think it's appropriate to merge it and have the meta e being blocked at this maybe editors [music] can yeah let me know what they think about it

>> um who approved the mascot merge >> uh the author. >> Okay. Then yeah, we just follow the process. They that has to go to review. and if it doesn't, we can't move the meta to review. Um if you want to make a meta another meta proposal that doesn't contain the mascot, we could we could do that. That would be the the alternate path forward. >> Yeah, I'm finding a disconnect over here. like you know when we are we are discussing these things in codev meetings like uh this is what we are doing anything should not just sneak in and if it has to be there it has to be documented somewhere I'm having hard

time getting approval on meta moving from draft to review and I'm seeing all these changes I I noticed another change about this particular EIP 8254 this was never added as a PFI in meta but this was directly added as a DFI in this meta. So I I don't know what to do here. I wanted to like check it with editors. Do they have any suggestion on this? How we can improve this process that we do not catch up with these kind of surprises. >> I mean chastise the authors of the meta e I guess would be my suggestion. Um just tell them [music] not to be dumb.

Um the the other option is we just create the meta ees although I really don't want to have to do that. Um >> yeah maybe to to to okay the first thing I [music] want to say is that I I find this incredibly funny because uh this this this mascot is is bugging the the reviews that of of Amsterdam. I mean I [music] I I find this incredibly hilarious to be honest. Um and like no dis disrespect to any of these EIPs of course. So I think uh just to react on on Sam's [music] suggestion I

do absolutely not think that we should do uh the meta because this is I think beyond the scope of what we are doing. Um because if we do that then we go we will [music] get like much more involved with also the governance process and I think that is not what we should do at all. Uh this is like part of ACD and this is not part of the of the EIB process. Um the other thing is that and I think this is like the most important thing because we should also um check with the office of this EIP. So this is of course the meta EIP. It's uh I would say like a very important one because this EIP describes what was cons sorry that's that's not I should be

careful here what EIPs were denied for inclusion um but also the EIP what are currently scheduled for inclusion and uh this is like very important for the entire ecosystem but of course we also wanted to move forward because I mean a label what is above this EAP which [music] says draft um that's that's that that does not sound like I don't know it it it looks like like a little bit weird [music] I would say so we will indeed want to move this to review or maybe I'll wait to last call like something something [music] like that um the thing is that the office of this EIP [music] should be aware of this and but I think but this is just my feeling like I I [music] do not know for sure but I think

that uh in general um that the responsibilities [music] of this might not be entirely known um also maybe by the office of this [music] EIP. So this is like the process of ACD and also EIP uh process um that if you want to move this thing to review then all the EPS referenced are all also into uh uh also should be at least in in review. Um and for instance like like uh these meas like the thing is that uh the approval of the EIP offers for this they should also know that if [music] they if any reference to a an EIP is being added

that also means that that reference should [music] be in the uh required phase before we can move this meta to [music] this new stage. Um, and my feeling is that this might not be uh be super clear to the EAP office. Um, [music] and if that's the case, like I think we can we can just check this. So maybe maybe we should just follow up about [music] this, but uh I my perception perception is this um that that this might be like like I would not say a problem, but just something to to to let the EP office of the meta know.

Um and also with the explicit notice that I like I'm not going to do it. I do not want to take over a meta piece. >> I have a quick question here. I'm I'm failing to understand this part. So if I'm looking at this pull request, it only took approval of author. It did not wait for approval of editor. While the PR that I have created is waiting for both author and editor. Uh you're you're changing status. >> Uh-huh. So for change in like um minor edits, they do not require approval.

Okay. Got it. >> No. Yeah. Exactly. >> Yeah. Yeah. Yeah. So it was simply approved by the author and that's why it got merged and Yeah. I I don't know somehow I missed this one and I figured it out after 4 days. Cool. Um from this discussion what I'm going to do is I will bring it up in the next uh ACD meeting. talking about it like there is no um mention of adding mascard to the meta e. So first of all do we have an agreement of including it and if we do then it should be documented in some of the process document and the second thing is if we want to include the EIP number that has to be either uh higher

status or finalized. finalized is better because that cannot be open forever or unless we decide to keep [music] it living whatever the decision is. So yeah that's what we are going to do about it. Yeah, Puja my suggestion [music] would be to actually first ping um Nixo or well maybe not Nixo but one of the EP offers on uh Ethereum R&D [music] about this so on discord um the uh agenda of tomorrow is like super packed and I'm not going to say that that our discussions are like less valuable because that's absolutely the case but I feel that these uh discussions [music] might um be better

to do async. Um although I would also say that okay like I my feeling is and this is maybe also where where maybe your confusion comes [music] from that we have the ACD process and we also have the EIP process and these are like completely independent [music] processes. So uh like to to to PFI to CFI to SFI like an EIP that is that has [music] nothing to do with EIP offers that's completely in the governance of the ACD process. Uh which is fine we should also not change that. [music] Um but the fact that we now see that we might be [music] I will not say like clashing but we are looking we are running into these kind of um well problems I would say because EIPs

are getting added and these are in the wrong status and then from the EIP editor uh perspective or from the EIP ecosystem uh we get in trouble because we simply cannot move this EIP forward. Uh so I think at least for the um for for the ACD process it should be known that we should not quickly add like these EIPs like these are not about these are not about like the the core EIP so these are not like technical these are more about the process like okay we have this mascot uh but that we should be a little bit more careful to add these because this might slow down the process for instance to move this EIP to preview [music] for instance Understood. Yeah. Uh I'll definitely do

that. Generally the process I follow is I document everything as an ag like you know comment to the ECD agenda and then bring it to the all code dev [music] discord channel so people can follow the link and respond appropriately. Uh but I can take the otherwise approach as well given the agenda [music] is fully packed there. All right, with that we can move on to the next item. Um, dispute resolution. I don't [gasps] uh know if we have any kind of progress on that. I certainly did not get a chance to maybe work on the dispute resolution working group. Does anyone got a chance to take a look at it or has anything to share or add on that?

Yeah. All right. In that case we can come back on this item whenever we are ready. [laughter] Um [music] and the next one is from the other working group which is EIP working group. I know there were some progress last week. I wonder if there is anything else to share on EIP working group. >> so we're we're talking about the the Rust implementation of the rendering system. Yeah. Okay. So, [music] um I think at this point, uh unless we get some some buyin [music] from the other editors, I'm just going to drop the

project. [music] Um I think it's too much work for not enough gain if we're not all on board with it. And if I'm the only one driving it forwards, then I I don't think it should move forwards. >> All right. >> Yes. maybe to to to to [music] jump on that. Yeah, Sam, I simply did not have the the the the time to have well the time. Of course, you always can dedicate time, but I simply did not have the bandwidth yet to to to take a look at this. I also completely understand your point about um [music] the amount of work versus uh well the at least the perceived perceived gains what what we

should get from there. Um, I cannot promise this, but uh I certainly want to take a look at at this at least um because [music] I think like that this is like it's it's super super important. But uh yeah, I I will try to to at least [music] take a take a look at this. >> Okay. Um yeah, I mean yeah, I I I just want to kind of put it on record that I'm I am very neutral about continuing it right now. So yeah, >> very well moving ahead. Um I am not sure if we are making any progress in automating the EIP numbering

since the transition of protocol support team. I have not seen anybody taking up that responsibility. If anyone here on the call is aware may want to share otherwise we can perhaps drop this item from agenda for future until we get someone on board. Yep. Okay. Let's taking a look at it. There are a lot of feedback but yeah there's no one [music] actively working on it.

So we can perhaps drop this one. Cool. And from the previous action item I was taking a look at it. Uh I think we have okay this PR is already merged right now. But um uh there are quite a few item in EIP723 that still needs um attention and we would be looking into uh there is an open PR for non-final EIP merge policy that was decided and on action item section uh I think we have covered everything except for this [music] EIP lab team um I don't know if anyone on the call

would like to maybe uh talk about that if not then we can bring it back in the next All right. Uh with that I think we are pretty much covered. Taking a quick look at the editor schedule we are full for okay we we can just need for September 8 otherwise we are full for the month of August. So we are good uh with office hour and on EIP inside August uh I'm assuming okay okay so this is for the August we have received seven

draft seven review and uh one in the last call in the ERC section. Yep. This is uh the just the starting of the month. So we have uh about uh 15 status transition entries and yep pretty good people can take a look at this [music] report for details of this month. Yeah the final item on agenda which I wanted to bring it to everybody's attention was um a community hub application that we have shared uh with the [music] Devcon India team. uh we want to organize an EIP hub. That hub will be a 4-day dedicated space and uh

this would be open for every participant. The idea is we try to provide different kind of EIP related information with the with this hub. For example, the first day could be about the generic information about the EIP process and all. Second day could be dedicated to protocol related process and governance related processes. Third day could be um application standard and the fourth day to be catering to the um enterprise community. Uh this is what the EIP hub is and what we are planning to do there. We are looking for programming partners who may be able to own specific day maybe application day, enterprise day or protocol day. Whoever are building tools or working in the

direction of EIP supporting Ethereum open community with whatever they have with respect to EIP, please reach out to us or or you can also uh leave your comments uh here and uh we will be happy to like have you in this [music] group. We definitely require some support and I hope whoever editor is planning [music] to join the DVC con show up one day. Nice. I will definitely uh be here. Of course. Yeah. Nice. Very cool.

Well, thank you. And that's pretty much it for today's agenda. Do we have any specific date in mind for the next meeting? Do we want to keep it on the [music] 3rd Wednesday or um sooner? 16th September is the third Wednesday. If that's work, that works for everybody, we can keep it there. >> Could be fine. I think it might hit all wallet devs. Uh they're on the same day, but I think that might be okay.

>> Mhm. Yeah. Yeah, I can see all wallet devs. Um but yeah, there is a gap of an hour, but 9th September is also fine. Yes, Sam, you would want to do the 9th September? be at Ruscon from the 9th of September. So I don't think I can do that one. >> Okay. And then in that case, let's keep it for 16th September at 1600 UTC >> for the next. >> All right. Thank you everyone for joining us here today. See you in the next one. Take care.

>> Thanks. >> What's up?

Thank you. Heat >> up here.