URL/URI Standard Working Group #6

Transcript

welcome to url uri standard working group meeting six so i have shared agenda in chat we don't have tons of item on agenda today it's a short one and um yeah in the past meeting we did discuss about couple of proposals eip2400 there were not much uh discussion on idea for compact url so i have added that as the first item for this meeting today um i have seen uh there are some new comments added to the agenda with respect to this proposal and also to the fem of course so yeah uh trey if you would like to maybe uh start from adding points for this particular ascent

item uh sure um i only posted last night i should post it sooner um if anyone wanted to comment on it i'm linking it in the chat now but um i mostly specked out what um uh bolt 11 like payment request for ethereum would look like um with you know several of the tlv tag types that um trying to sort of one-to-one match uh what 681 supports in terms of different kinds of messages um thinking about it it actually makes sense to only have one like flat blob to encode um all of the call data that would get

passed instead of having separate arguments and then you could take that back apart again um with a signature either included in the message or if you not elsewhere somehow um and so that that actually can save some space because it's just more compact um i also did some more of a write-up on what the specific like transfer request format would look like i know there is some objection to that but i thought it'd be interesting to spec it out in case um that could convince anyone and i thought it was interesting because um if you use the more optimized versions of a more optimistic

versions of how to communicate some of this information like assuming we have some kind of global token contract registry that is generally agreed upon and we can refer to that instead of actually including the full addresses using like token lists or something um assuming you can do that and people have enos addresses then you actually end up with similar to in 681 really really short uh payment requests since you don't even need to include something like um like the signatures or the function names themselves so like like you don't need to say to call the transfer function um so i i don't know um i thought it was neat to spec that out

um aside from that uh i don't really have too much else to say aside from maybe some comments please yeah anyone have any thought comments on this comment i wasn't sure sort of what format to write this in um i didn't try to write it as it would be an e because i think that's premature but um yeah i'm mainly just trying to get people's opinions on it i

wonder if i was about to call on you some maybe as an eip editor or maybe as a facilitator for url you are in meeting there yeah i'll take a look at it yeah well thanks all right uh that is good maybe we can move on to the next item which is about the update since the last meeting the first sub item that is issue 67 i believe that is merged and that do not need any discussion any longer yeah because the proposal is already

added as withdrawn so i think uh the author should be good enough to use that in eip831 so yeah should be good to go thank you so we can maybe skip that and the next one is eip2400 that is already in review and we are joined by ricardo ricardo if you would like to share any updates on that where we are and if there is any roadblock that the group can help you with no i think that i will see what will happen with the you other eips that are dependencies that i actually removed the dependency but i plan to include it back

so once that's all set up i think we can move move to the next stage for that jp maybe i don't know the the other aips are already good to be used i think yeah please go ahead oh it's because i think one thing that we should probably um coordinate is is how we're going to be writing method signatures um because i know um uh keys uh eip has a different method for encoding uh like signatures so maybe we could come up with something that's similar between the two formats what do you mean by the function

signatures that are on the eip2400 yeah yeah exactly so they're they're um because you have it like as a quoted part of the query string um and i think we have a slightly different way of doing it in uh 4804 um yeah okay i will take looking 4804 sorry can you type the number like this four eight zero four yep i posted in the chat okay i think and we'll take a look here yeah and they i know they are different purposes

like you know one is to decode a transaction and one has like a way of like guessing at what the um function signature is but it'd be nice to have some kind of like uniform way of encoding this information sure one question for ricardo i'm sorry if i did not get it correct or i missed part of it uh did you mention that you were trying to get rid of dependencies like the required eips and it was added by someone so i tried to remove the dependency because it was not it was a stagnant dependency and it was not really like needed it was more like a

formal thing just included as a japanese so as but as it's it's getting finalized as well so i can use it in this eip as well so i prefer to use it to keep the definition i think it makes sense yeah i'd agree like the more links the better yeah right so as of now if i look into the proposal only one five five and six eight one are added as probably would add the other one later on but both these proposals are in final status so it should be good to go okay

so that's on eip 2400 um moving on to eip 4804 sam already mentioned that there is a need of coordination per method signature there um anything else you would like to add key um yeah i also have a discussion with sen um so actually one interesting discussion is can you hear me yes yeah you seem fine i think ricardo is unmuted yeah okay good so yeah um so one question is regarding

the uh so if it's going to depend on eip a31 and that is the ui format for ethereum uh one thing that actually um have some question is like right now the it's more defined uh general format defined for ui um but eip4804 is for url which will have the basic schema comma and then double slash um and some something so uh i'm suggesting that we can basically set up some prefix as the double slash with example web3 but i'm wondering whether if there is

any restriction or prefix or when we should put this kind of like the url format explicitly in a specification uh for example that before the prefix pro well we may have the double slash part as optional if it's designed for url so this is just uh one questions for dependency so um one question i have is is 4804 a url or uri um and i i'm not too familiar with the distinction between the two but uh yeah i'm just wondering about that um it's it is a url um but actually url is also a sub uh subclass of the ui

um so it's it's also a ui but it's more specifically a specific uh url similar to http right so so uh i guess the the difference would be a urn versus a url um so is uh my understanding is the url describes where to get a document as opposed to urn which doesn't describe where to get it and it's just a name so our 4804 urls are sorry our 4804 uris are the urns or the urls and i think technically they're a urn because they don't

give you like a server address to go to they they actually just give it a name and you have to look it up on ethereum but i'm not sure of the technicalities but anyways i don't think it's a problem to have slashes in the prefix that like it looks like you just can't start it with 0x so yeah i believe urns don't have a scheme prefix but i might be wrong about that yeah i'm not quite sure the difference between you are and um and you are l at ui and i'm pretty sure like um basically it is kind of like um

a similar way as http including the format including the how the basic query and authority that's what i read from the document saying that if it's in discount format then it's truly like a url but definitely i can find a specific document however where the url is defined in the uh in the in the ui uh document i think there's one document that formally defined what's url and you can put it there and then to see hey whether uh in this ui format uh if there's a convenient way it's also be able to support url and and also precisely uh mentioned that 4804 is kind of like uil instead of like maybe

other no or maybe perhaps also a uf uim so so probably we need to some effort to dig in and find out the difference there okay cool yeah so i guess so one option is getting rid of the slashes uh putting the slashes as part of the prefix or uh changing 831 to optionally have slashes and i guess those are the three kind of paths we can take yeah but but i think uh even like with current formats we can still using the slashes uh yes this is definitely a sub case um but but just want to make it more clear that it can explicitly support this kind of like uh schema

slash and and prefix or something else something like that oh yeah url is a schema of uh okay so yeah so it's definitely not a url yeah okay yeah that's exactly what i'm looking at yeah cool awesome okay so i think that's just a small technicality but otherwise i think it's going well good yeah i think this is one um and so i'm going to basically clarify it and i think the rest is basic

of my minor because like for example i'm going to we are going to uh basically to um first how to how to make 4a04 to be compatible with existing content hash which is used also by ipfs this is one thing that we are also exploring but actually it doesn't change the current content of opporaco4 because as we discussed previously we are going to put it in a separate eip for uh for supporting different services um so right now the current format is still after some some changes then yeah and then we are also going to change their return types

to returns um so that will maybe perhaps that we are going to support both but we are recommending using returns because i know several services they are already supporting return types and they're asking me whether we can maintain the backward compatibility so so perhaps i may put both return types and returns by recommending using returns is that does that sound good um i i don't necessarily see a problem with supporting both i think um it would be better to define returns as like the canonical one and maybe have a note for

backwards compatibility because you want to write your standard as like how you want it to be seen and how you want it to be used uh and less as a document describing what's already there um because like yeah but yeah whatever you want to do is fine i think yeah yeah in general there are a couple of uh basically um company members approach me and saying that they would like to apply the standard and so they say well it's kind of like immutable uh format or it's a power compatible and i think that i think this is something that we are going to do so yeah i think um yeah yeah sam you're right yeah so basically it's it's better than we can just we will put uh fixing returns as kinetic

when say uh region types is optional but not recommended yeah great cool um that's pretty much all the updates yeah cool thank you so much on that uh update um i think uh that was the last item listed here on the agenda for today's discussion but there is one more question in my mind which i would like to share with all the participants here uh do we think that we need a bi-weekly meeting for this um out of the volatile meeting that is

there for uh like where we have all industry ebola developers and one meeting led by sam wilson i propose this because i believe that the participation there is wider than this meeting and also uh it will be good to share the updates plus question common concern in the group where we have more people giving more feedbacks yeah anyone has any thought i think if we want to get any feedback from wallet devs we should probably um merge the meetings um i put a link in the chat for a discord server that we host the meetings on if any of you want to join feel free

yeah and i see that the next meeting is planned on august 17 which is about a week from now i think it will be a good start for uh people uh to show up in that meeting and see how does it go they are already discussing about wallet and including discussion for uri uh would be a good addition great great yeah i think that that's a yeah that's a great place to yeah discuss yeah yeah and in addition to that like we can probably move the discussion that is related to a wallet discussion like core discussion to that wallet dev meeting however if there is any question common concern

related to the process of eip like there were a few proposals in stagnant status like 831 and 2400 which we try to bring it to the live status and start moving it pushing towards final if there are any questions around that if authors need help with that sam wilson is also planning to lead this another meeting that we have on tuesdays uh the next one is plan for tomorrow uh that is a basically called eip internship meeting we try to share that meeting recording for people who are interested with helping out with eip editing process however we take questions from any author of any category it's not only for core it can be um erc interface meta or anywhere if they

have any question related to the process they would like to understand and they would like the proposal to be reviewed with reviewers and every editor's fastest yeah they can always join the meeting eipip right uh uh no uh it's not eipip eipip is where we are discussing questions on eip process but if someone has individual eip for which they are looking help with is eip editors apprenticeship meeting definitely i'm gonna post the link in the same channel eip editor's channel or ethereum cathode is discard for discussion uh and we can probably divide this into two section code

discussion that is related to wallet and where it includes uh audiences like uh wallet developers or infrastructure provided move to wallet dev meeting and related to the process part we will move it to the internship meeting nice um so i think uh other than the uh general eips that we are discussing here i guess one proposal of tree which is not a good fit for either of the category i believe we can probably start discussing it in the wallet tab and then and when this comes into a live proposal it moves into eip uh draft form and then

we can take it in eip apprenticeship meeting does that sound reasonable to everyone i'm fine with it all right yeah sam so um i'm assuming that the next meeting is on august 17 uh is there anything that needs to be done to be adding these items on agenda or because we have discussed it in this week maybe probably we can just provide a brief update and move on uh if there should be an agenda thread in the discord if not i'll i'll make one and add you guys so okay that sounds good cool this looks like a quick meeting for today anyone wants to add anything else i'm going to update the notes in the

same hackindy document and share it in the discord channel probably that would be the last for this sort of meeting however we are open if we need any kind of any discussion um yeah definitely reach out and we'll try to have meetings well thank you everyone for joining us today i'm going to share the recording very soon on ethereum cathode race youtube have a great day thanks everyone yeah see you later