EIP Editing Office Hour #51 (EIP + ERC)

Transcript

[Music] oh [Music] welcome to EIP editing office hour

meeting 51 this is issue number 379 added on ecat herders EIP I GitHub repository uh we are joined by Sam Wilson thank you Sam for sharing screen joining us here today so let's proceed with the PLL request that those have been added maybe we start with the final one sure yeah we can do that yeah so what are we doing here hasn't been reviewed yet and we're just going into final easy enough the reverse looks good let's see if there's any discussion on

here no I don't think so okay so let's give this a read handl rever cont good cont conts okay y that looks great it's an easy one to move to final awesome uh I think that was the only proposal

for final and we got two for last calls let's take a look all right so two weeks from today is the 18th so let's start with okay secure messaging protocol and between users that's good this purpose the capability secure exchange encryption messages on chain users Comm the public use encryption but for

registration addresses interface also in numerations okay all right okay then we have reference

implementation good it seems fine and then what we have on their discussion through cool moving on 7628 so what's going on in here

[Music] all right ownership shares queriable transferable fractional ownership all right inip of ownership and Prof okay yeah so

what for for

speak represent with total life one and 762 p for this must already

exist let's go find out I guess not all right for okay

I can't do where the there's another one that I want to say here too yeah why do there's the total

shares for okay rational did they actually go over any of that probably not no Okay cool so we shall not be

approving that one and extending are we extending the date further yeah I'll edit it edit again when uh when they address those comments I just don't wanted to go into last call yet because it's going to get changed okay at least it should get changed very well so the next one is actually added to be moved to review but I feel like it should be in draft in the first place um this one's already been merged before I think 7750 yeah oh it is there okay it's just I yeah yeah draft for

review yeah this is correct all right so puros management [Music] compan Tok okay yeah this still feels messy but I'm not one to fix this

I don't know enough about like employment standards so um yeah we are now getting getting Diversified standards here yeah it's it's also just I don't feel like there's enough um substance behind this proposal like no no offense to the author or anything but it doesn't feel like this person is going to be developing a product based on the standard it just doesn't seem plushed out enough so I think this is just a standard that's destined to never be used you live there for longer yeah okay I was learning uh about uh the

process that is being proposed for rollup Improvement or the RPS that we are getting uh I was talking to one of the author and he mentioned that in order to move an rip uh they are looking for at least two implementations of that so I'm wondering like we I know we had discussed this in the past that we should not enforce implementation but do you think at least one implementation would make sense before we finalized that um I mean I I'm not in favor of that because like I don't want to have to go and hunt down implementations and judge their quality

and all of that crap right but you know it would be useful in this case to be able to say no I don't want to like I don't want to move this one forward because I know it's never going to go anywhere um okay but I don't have a like a rule to say that I can't move it forward so like this can go into review it's just uh yeah I we can encourage the author to maybe look for someone who is open to implement it would be nice to have but definitely not a mandatory

for for all

right 793 I have one more question for you Sam yeah I have noticed that um some of the proposals have multiple authors and uh not all authors have GitHub ID added to it uh some has just the email address I'm wondering uh is there any set rule or maybe we would want to have a regulation around adding the GitHub because the author is being added to GitHub repository and we are not collecting his GitHub handle itself uh yeah so um the rule is as long as there's one GitHub handle to be able

to approve P requests that's good enough um if they don't have a GitHub handle they're just in the author's field for like credit um as like an author so as long as there's one that's fine all right yeah I noticed that in some of the ERC categories proposal they they have like one author whose GitHub handle is there and rest all is coming up with a project email ID like the project that is actually implementing the thatc yeah yeah yeah um I asked this specifically because um on cat Herer side we are developing an app where we are trying to uh like reward all the authors who have

contributed to um to an upgrade so for Petra upgrade I understand this is mostly for the core proposals for in pectra upgrade while we are looking into the database we would want to have all GitHub handle because the verification would be based on the GitHub so just wondering do you see the potential scope of having GitHub as a mandatory field uh we can definitely discuss more on EAB meeting but curious to hear your thoughts um I mean I the only reason that we have GitHub at all is for permissions if we didn't have to like if we could use just email I

would just use email um just because it's like I don't want to depend too heavily on GitHub for anything so so I wouldn't want to get mandatory all right yeah I was wondering more because uh this these proposals are being added on GitHub repository so there's no harm in adding their GitHub handle as well but I understand yeah right right it's there's no harm in adding it it's just I don't want to make it mandatory makes sense thank you um yeah so this one again here let's go and

see owners fees mod [Music] okay so you're removing that that's good mint token okay interface definitions sure yeah so I we did literally just review

another one of these earlier is that this one or this one so let's be this one yeah cool so we take this go over here here and then we'll do the opposite

here this one okay yeah I don't think there's anything wrong with this one just again not sure if there's any kind of a product behind this um well product

project you know what I mean um yeah let's let go ahead and do that so I think the next one is you you have already reviewed it and there are some todos so we can jump on to PR 798 sure so this is a some small changes there yeah yeah so I'm noticing that the changes

mentioned here is changing from EIP to ERC but if I understand correctly that's not a I mean that's good to have but that's not a requirement because we do have access to both right well these links won't work when once it's merged I don't think let me check um what's uh 137 yeah no I'm just I'm trying to think of a a recent one that um I mean I can just go here and take a look what [Music] 7,000 sure 7734 you probably link to something right no you don't all

right yeah there's one so if we go to code yeah they have to stay EIP if you them to yeah yeah so they they don't have to change it to ERC yeah they can't change to ERC um I'm not sure Sam I don't know if there is a way to check it I think you mentioned that both of them would work um in in one of the conversation with eips inside team so that's my high level

understanding I'm not sure of that is there a way to check it yeah I'm looking right now one sec okay so we want SLC Dash yeah so they are all EIP Dash there are no ERC dashes so I'm assuming that ERC DH doesn't work uh but now that proposal is not in the GitHub repository of EIP no the the files all get renamed uh in the build process okay perfect yeah got it so there's no need to do it

just keep it in EIP only yeah I think I think it actually breaks if you change them okay yeah yeah then we should not approve this one yep yeah h oh yeah and that was it right oh no we got a bunch of drafts all right yeah a bunch of drafts hey it's James again see all right let's go take a look this so these are from the last week um I don't know there may be some cases where you have already reviewed so we would skip whenever it is there yeah I don't

think I've looked this one yet or it's been changed since I did so okay forces Supply typ token diffusive token balance for

e for yeah I mean this is decent uh copyrights

right yep I'm okay with this all right ex aute call in reference implementation um this is updating a draft needs an approval by author verification cross mechanisms okay API for sending messages okay so what we need here okay speci messages across

change specifically transport okay being created as planned by the rollup c y [Music] okay interact the mail this seems very familiar to all of the other cross chain messaging ones send a message contract dispatch function receive messages process function yeah okay or we at

[Music] okay for okay

yeah this is pretty good um 673

7786 for 75

okay okay

okay verification okay F Tok gas rebates new20 compatible token CER design for Crush okay gas gas cool to security2 functionality gas re op transer

mechanism okay for for

for for for featur and gas optimization mechanisms

this person address inations by incorporating gas re system gas approvals okay here we go to Eeps and we go here okay

76 on4 four 946 get core

variables um for for

okay token name Tok symbol [Music] sure NE you actually to find any of that no okay

for for for

[Music] okay that's

all right I think that's the last one I'm going to do today um going get ready for my next call yeah thanks for hosting pja I'll see you in a few weeks I guess thank you Sam yes we'll do take care [Music] a [Music] oh

[Music] oh [Music] oh

[Music] [Music] oh

[Music] oh [Music] oh oh

[Music]