Ethereum Cat Herders URL-URI working group, 26 Jul 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: URL URI working group meeting 5

Description

Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/159
Notes: https://hackmd.io/@poojaranjan/URLWorkingGroup#Meeting-5

A

Welcome everyone to the fifth URL URI standard working group meeting from the past meeting next steps discussed, are Ricardo resurrect EIP 2400 from stagnant and move it to review I guess it is already done with the pull request number 5217.

A

There was another proposal in discussion that is 4804 and key was supposed to move the proposal from draft to review. This has also been done with the pull request. Number 5218 and one action item was for Loop to create a discussion thread at sem I, see the discussion thread has already been created and there are some ongoing discussion uh for people listening to this recording.

A

Maybe you may find the link to the discussion thread in the working document that is added in the YouTube description and, furthermore, Ricardo left a comment to discuss uh the status of eip831, which was uh which I was assuming is in the required section for EIP 2400. But apparently it is not.

A

um I have added this item for today's uh discussion and um just a piece of information like after the status of EAP 831 was brought as a concern in ech Discord. It was also discussed in the last eipip meeting and as of now, we can see at least two pull. Requests.

A

Number 5335 and 5338 are added with respect to these this particular proposal a31. So let's kick off today's meeting with this item, followed by further updates on other proposals that we discussed in the last meeting.

B

So Lizzy is here, welcome, Lee and thank you for moving on the eiph1.

C

Hello, thank you for pushing for it yeah, it's kind of uh the question. The only question is basically I'll, just also a thing to Sam uh for for doing the 67 um dependency there um yeah. The only question is basically they are um for the shortcut uh I'm missing a bit of context. I edited um and I think it should be no problem for most sites.

C

The question is, if it maybe at some point, becomes a problem um when we then register like the schema, because when we don't have two, you know currently now, I did it as an alias, so ethereum and Eve are allowed both um yeah the only question there is basically do we run into problems when we register it somewhere. If they are now.

A

So I have shared the link to the pull request. That is, a 5338 which is about uh eip67 to be published as withdrawn. I believe this is an um in association with the eav831 I have a concern, slash question here: eib 67. Actually there is no EIP in the EIP repository as 67.. It was an issue that was created. However, there was never a pull request supporting this issue idea. Also in the issue. It is mentioned that at this particular proposal is superseded with the EIP six eight one I believe um so yeah.

A

How can we move a proposal to withdrawn when it is not there.

C

And I think that would uh work with Sam's proposal rights, so he basically did a pro request now um published in 67 and Alexander. Also like approved, he just lost access to his old account, basically um yeah. It's a good way to get it in now that way, but it's also nice I think to have it there as context, because it's kind of important as context because, basically six eight um 831 basically um keeps backward compatibility.

C

So this uh yeah people is just an issue for a while, but still people were building on top of it. So it's you see it's just a 200 digit eaps one in the beginning, people didn't care that much about formal stuff. So um it's still an active thing, so I think it's good to get it in there.

C

Can almost work on it this time already, so thanks Sam for that um and I think it's good that way.

B

I have a question: there is another Eid, okay about the paid transaction. It doesn't uh because the a31 it was created after the eap6.

B

Let me remember the ap6 eight one transaction format for transaction requests made by Daniel a Nagi. So if you understand this, this camera, but it doesn't uh it's not dependent on h31. This is going to be solved.

C

uh A bit history, wise, I, just created 831, basically to break this whole thing apart a little bit that we don't have to repeat, you know all the time, the same uh so to make it a bit uh more Atomic there, uh so that other can build on top of that, so um I'm not yet sure if the trip depend on it, um not sure that it doesn't, but other ones do right, um and that was the whole idea that basically, we don't repeat ourselves in a lot of earps, but basically it was um foreseeable that more and more ipaps use UL standards like for payment for receipts for like then also the model connect stuff and uh so basically to build a small one and keep the EIP small.

C

And you know the duplicates things. That was the idea.

B

Okay, okay, I see your intent, but my my question is: can we fix this? Can we make six one eight one depend on A3 uh one two, so we because then we can have this uh dependency graph, where we can see everything that you that depends on this uh ethereum schema and also, and then it will inherit the Alias. That is also a good thing that, because we want to use the Alias also in this URL requirements or in anything that uses that.

C

Yeah, that's true, but I just feel like I'm, not that much into this EIP editing but I, see like uh 681 is final and I. Don't think can we still add it? Finally, so.

D

Yeah correct so 681 is, is frozen so but, like you can kind of say that 831 is a superset of six eight one, so I mean it kind of works. You just don't get the dependency graph.

E

D

Are all 681 URLs like compatible 831, urls.

D

B

D

Yeah, so that's fine, then.

C

So 681 is just more uh like an improved 67, which was kind of a simple idea from Alex from the beginning, and he then basically took it over because Alex had this idea and information that was never, as you said, c uh was never really published, so they pushed it forward.

C

D

So I guess so: 831 describes a family of URLs and then 681 is a specific type of 831. Uri is.

E

That yeah, exactly okay, exactly yeah.

C

The idea wasn't also like if we like at some point register it. You know we don't have to tell them all the specific use cases we can just like tell them both a31 uh and the rest. uh You know, otherwise it gets too complicated. Yeah you've got a lot of use case on top.

D

Of it did somebody register uh web 3 as a prefix I think that might have happened.

D

E

I didn't register, um I mean ethereum, comma graph. Three I, don't think so.

D

No, no just just web three.

E

Yeah I registered on right I am a yeah.

A

So if I understand, there is one big problem that is of EIP 67, which obviously Assam has created a proposal, but uh because Alex may not have the access to it. It is very difficult to have it approved by him and because this is also um being added as a pull request for the first time, I wonder some. Can we have couple of other authors added here and I?

A

Also wonder that, should it be started with the status of withdrawn or should we follow the traditional path of draft to withdrawn, but with a couple of co-authors added, maybe you or maybe liggy or yeah,.

D

um I I'm, not a fan of creating like useless pull requests just to follow the flowchart in eip1, but I mean if that's what we need to do. That's what we need to do.

A

Okay, because to get merged in the first place, it has to be either coming from the author or someone from the team of authors, be there to Champion the proposal or Push It Forward yeah.

D

The the original author is is on the pr now so.

C

The other problem is, he is with a new GitHub user because he lost the access to the old GitHub user and has a new one. Now, that's the problem, I think foreign.

D

Yeah, we'll figure that out that's like an EIP discussion. It's not really URL related, so we'll we'll deal with it.

A

A

Okay, so uh coming back to Ricardo uh I, remember uh you added this as a comment here. um Is there anything that you would like to clarify for this proposal, or are we good in there.

B

I think that sorry I think that everything is good about the uh what we are just discussing now. I I am very happy to see that we can do so. I I will do a pull request to eap2400 to request to yeah at the back. The dependency there and yeah yeah I think that that's it I think that that solves the problems that I have.

A

Right so did you just mention that uh the present eip2400, which is already in the review status I, don't see eip-831 as a as in required section. You are planning to add that to the required section.

B

A

B

Properly back on the on the document, because I had to remove it to able to move forward because I was not sure if Luigi was going to to answer or move forward the that EIP so as as he came here in in did all this I I'm happy to put it back because I really like the the what what he did to actually separated and so other eaps. Can he build on top of it? I think I think that this makes sense.

A

Yeah any final question comment related to this topic. Before we move on to the next one.

A

Cool, um so that was item number one and moving on to item number two, uh that is progress on idea for compact URL proposal, I see a thread and um yeah I, don't know if anyone has any update or would like to talk about uh this discussion that is ongoing on FM thread.

F

um Yeah so I I left a few comments describing like my perspective and like potential ideas for like a binary payment request, format that you could like more efficiently encode onto a QR code um and also some other related ideas. I was having um Luke seemed interested in some of them objectionable to other ones, um but I, don't know how much people read over it, but um any questions.

F

Foreign well, if not, then I think um what I might do sooner rather than later was um yeah. That's in in the com. The chat there there's a link to the thread.

F

um I might write up like a draft spec not as an EIP, but um just like to get some ideas of like what should be included in like a more conservative version of this and then like extensions for what I think might be more useful to have later on um and I guess. I'll share it in the ech Discord um for feedback.

A

F

Would be awesome, that's reasonable, yeah.

A

Thank you yeah. That would be awesome, I mean if you can create a draft, and we already have a place where people can go ahead and discuss and share uh their comments and feedbacks related to that proposal. We can take it from there.

F

Yeah, just um if anyone has any other feedback, then I'd like to hear it in the thread. So thanks foreign.

B

Added there, it doesn't relate to this other effort. This is an effort to actually make a machine only standard right.

F

uh Not necessarily machine only but something that's like not something you would write out like as a URL, that a human would read um it's something that you could like very compactly store on a QR code um as like one example, but um because there's a few bits in there about the rationale um that goes more into it.

B

Okay, I think it was just to clarify that is something totally different. Yeah.

F

It's a separate effort not trying to like compete. It's complementary.

A

Cool so yeah, the link is added in the working document for reference so uh for people to leave a comment feed their thoughts, whatever they have in fem. Another thread number is 9906.

A

just for people listening and yeah. That's about item number two.

A

Moving on to the item number three, that is progress on eips. We discussed two proposals: EIP 2400, URL format for transaction receipts; I, believe we discussed Ricardo. Is there anything else that you would like to add for that particular proposal? Okay,.

B

A

All right, thank you so much. This proposal is now out of a stagnant. This is in the review status, so anyone looking into the URL format transaction receipt, please feel free to um leave. Your comment on discussion link provided in the proposal and obviously the EIP editors will be reviewing it further and yeah. If there is any Improvement suggestion, you would be getting it in the next pull request.

A

um The next proposal is EAP 4804 web 3 URL to evm call message translation. This was in draft and I see. The proposal has already been moved in review status. uh Key if you have any updates to share with the group.

E

um We don't have too much updates uh so I basically uh response some comments regarding uh some ambiguity of the, for example, arguments and also um non-existing of uh message ID, but I haven't seen the further questions so right now, it's uh I guess no further questions since last meeting.

A

Yeah, anyone here has any question otherwise. This can also be added in the discussion to link.

D

So is there any reason to not make this a 831 style URL or or do we want to keep them with sep like separate.

E

Yeah I think that's a good question, um so uh so you mean uh using the ethereum as the schema and also kind of like maybe last three as the prefix yeah.

D

Something like that, yeah I'm, just asking right like I, don't actually know yeah.

E

I think that that could be a a big, basically uh another kind of like uh another way to uh basically present the URL, uh but that, but definitely using uh about three schema. That would be uh shorter, but definitely we can say hi. This is basically abbreviation of the uh a61 and also we also register uh last three schema. That is a further abbreviation of of um no W3 schema, so just two letter, uh okay, so another abbreviation of web3. So definitely we can I can make it uh to basically two types of the schema.

E

You know if y804, including the full name, are based on beef, 681 and then, but the rest of format should be uh the same, so just changing the schema prefix. That is what you mean.

D

A

Well: okay, uh that was the last item. As per the agenda, any other thing people would like to discuss foreign.

E

So one question um so regarding the review process um so uh from reveal to Pixelmon last code to find out what is any flexible reviewer will, step in or need to be automatically assigned or I need to find a reviewer to uh to go to this process.

D

um Yeah, so review is kind of um it's more of a signal to the ecosystem that you're not expecting to change the EIP, so people can start playing around with it. um You there's no formal, like reviewer, that's the EIP editors are going to assign. um If you want to get feedback on it, you should probably find the people yourself like these people here are probably the people that should review it.

D

E

A

Yeah, that's right, and maybe at some point if it is not merged and it is uh waiting for for the review at some point, it will be brought up in the EAP editors apprenticeship meetings. There generally we try to discuss some of the ercs. However, for this ERC we already have this working group where we can discuss it formally, uh but sometimes it is also discussed there and you can or maybe collect feedback from there.

A

Well, thank you. This looks like a short meeting. uh I have one last announcement that is for wallet have the next meeting is planned soon right, yep.

A

D

A

It's on 27th July at 12, 30, PM EST. Obviously, people in this group are already there in that Discord Channel, but people who are listening. If you are interested there is a Discord Channel dedicated to volatile devs. So please join the channel and be a part of the discussion there.

A

That is not there on the protocol calendar uh because uh that is not directly related to protocol. However, it is for applications, so we do not add it in the calendar, but you can find the information uh like I will try to edit it on the event calendar. Just.

D

A

Oh yeah he's leading that uh okay.

D

I'll put the link uh in here. One second I think this is the right one. If it's not sorry,.

A

All right, yeah I, think that's all from the item that were listed for discussion today. um If people want we can meet again in two weeks if there are progress to discuss and if there are any further eips that people would like to be added for considering like moving um forward towards the final status, please feel free to leave a comment on agenda and we can bring it up in the next meeting and let's hope that we move all these proposals like in Fast Forward mode.

A

Thank you. Thank you. Everyone for joining you.

B

All happy thank.

A

You good rest of your day.

D