URL/URI Standard Working Group #5

Transcript

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 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 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 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 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 so Lizzy is here welcome Lee and thank you for moving on the eiph1 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 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 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 how can we move a proposal to withdrawn when it is not there 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 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 can almost work on it this time already so thanks Sam for that um and I think it's good that way 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

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 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 and you know the duplicates things that was the idea 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 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 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 okay are all 681 URLs like compatible 831 urls yes okay yeah yeah so that's fine then 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 yeah so I guess so 831 describes a family of URLs and then 681 is a specific type of 831 URI is that yeah exactly okay exactly yeah 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 of it did somebody register uh web 3 as a prefix I think that might have happened yeah I didn't register um I mean ethereum comma graph three I don't think so no no just just web three yeah I registered on right I am a yeah 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 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 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 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 the the original author is is on the pr now so 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 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 okay 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 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 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 yeah and mentioned 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 yeah any final question comment related to this topic before we move on to the next one 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 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 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 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 that would be awesome that's reasonable yeah 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 yeah just um if anyone has any other feedback then I'd like to hear it in the thread so thanks foreign added there it doesn't relate to this

other effort this is an effort to actually make a machine only standard right 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 okay I think it was just to clarify that is something totally different yeah it's a separate effort not trying to like compete it's

complementary 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. just for people listening and yeah that's about item number two 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 no 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 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 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 yeah anyone here has any question otherwise this can also be added in the

discussion to link 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 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 something like that yeah I'm just asking right like I don't actually know yeah 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 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 exactly great [Music] well okay uh that was the last item as per the agenda any other thing people would like to discuss foreign 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 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 so yeah okay 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 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 [Music]

27. it's Wednesday so 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 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 pick me oh yeah he's leading that uh okay I'll put the link uh in here one second I think this is the right one if it's not sorry 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 thank you thank you everyone for joining you all happy thank you good rest of your day bye-bye