URL/URI Standard Working Group #2

Transcript

thank you all for joining uh this is the second brainstorming meeting in the direction of getting a few standard for uri and url for ethereum to have some context for listener we had our first meeting on may 23rd inviting wallet tab cip authors to understand where we are with the standard so already have one eip that is 681 url format for transaction request in final status but from the last meeting it looks like there is appetite for a few more eips depending on use cases thanks to luke who joined last meeting

and he has added usage for current schemes um in the working hack empty file that i have just shared with you all with another discussion the group also looked into two proposals eip four eight zero four by key and sam wilson and there was this other proposal eip5904 file loop though we could not reach any discussion on any of the proposals uh but they are merged as draft and can be found in eips repo for reference so that's for background meeting we have two action items proposed by matt i'm not sure if we have any update on that but yeah i would like to open the flow for sharing progress

and continue brainstorming wallet plus theft and maybe uh it is something that we can be reaching out but i know there are um this wallet dev discord channel did not send anything did you send any messages sam uh no no i haven't had a chance to write the um you are the url list standard yet so no worries yeah sorry i don't have any updates on the action items then okay not a very uh but um if there are any further suggestion in moving in the

direction i know there were like two proposals which were discussed and we could not reach on which one or either of them are good enough to be pushed forward um right i mean i didn't feel like the um the qr code you are uri for adding the networks was really moving in the direction that we want to be moving in but that doesn't preclude the author from continuing to push it forward i just think that it's best to you know come from it approach it from a different direction sorry i was looking for a mute button

yeah that's right uh that is available in the draft right now and if author wants to continue moving in that direction that is they are free to do that uh key you shared the proposal 4804 uh in the last meeting i see that is still in the draft status is there anything that you would like to add or share or maybe the progress or anything new on that proposal [Music] i'm not sure if you are talking you are on mute oh sorry yeah um so i probably will share my screen to

have a quick introduction of what 4804 is going to do and then and then we also uh give uh basically raise some questions on what we are going to fix with um for example what uncertainties that we are facing and how we want to adjust this so let me share screen yeah um so uh this is the basic form discussion of eip 4804 um so basically for e04 uh is can be truly a kind of like a http web 3 version of http

um so the format is quite straightforward if i using a very simple picture something like that basically it's going to replace the schema http with fdrf3 and then user is going to put uh what the contract is that the user wants to locate basically in http protocol it's going to locate our website two resources together with dns and ibhs uh in the western world which we will project that we should have some decentralized way to locate the resources while we can inherit some good properties of http uh spectrum equipment readable and also

other features like relative parts that widely use in http url so basically it replaced the dns with ens so here is an example of using uh ens dot eth as a contract uh which will be basically look at the contract on the target chain and then replace it with corresponding id address and then you can also provide user info and then and then port number is replaced by the chain id so that actually the whole link is quite similar to the http um so that we can easily use an existing uh for example a browser that picks up when example when there's a path uh in this web3 url

and then there's a relative path that i want to find the relative resources suppose it returns for some html svg any questions let me see oh i guess i was just wondering what the user info is used in in these in this context oh so yes the user info is basically when uh when we translate to a user message it will tell us what is the sender after a message um so this is the user input that we just directly borrow from uh http standard uh you know http uh

yeah um so and definitely it can also be moved to the query path um but feel like um this is kind of more like uh uh if we treat a schema here uh this is basically what we just put the rap3d part into the uh i would say red two power yeah um so um one application actually i'm thinking about that basically two applications in this narrow one application is basically kind of like a complimentary of json rpc basically we are able to using a simple link instead of query adjection with some parameter then we are able to for

example check some balance or call basically pro uh arbitrary method of a contract and return its value back um this is kind of like a complimentary options rpc another one that i feel like is more excited about is able to uh basically return kind of a web content that is generated by the uh by the contract itself so recently we see a lot of some some application like using on-chain contract that is able to generate a web content such as svg uh one example that we found in the market is called um they called cyber brokers

so they basically upload all the svg data to the blockchain and then um and then this is the one one actually we create a subcontract because they don't have a way to be able to display this their svg that is uh composed on top of the exterior directory so using our protocol uh so basically this is gateway uh so in investment this will be like something like that so we look look at this uh contract and call the random broker method together with the id of the mft token then it just call their contract and then we'll uh compose

the uh svg uh content basically kind of like xml content and put it together and return to browser but in this way we don't really rely to any uh for example other servers like ipfs or centralized servers to uh basically render the uh the media and content on top blockchains kind of like uh you the user not only owns the nft but also owns the media data metadata of the nft together on the blockchain so question okay cool um

so so that that's the kind of application that we are now able to use in smart contract to build like a caller common gateway interface uh programs that can random html svg which stable brokers is is already done maybe more complications like png that we uh may observe in other blockchain that might have cheaper upload costs like example polygon or bsc um so some something that we feel like this in this way we are able to build the counterpart of rev3 versus the http web 2 way and be able to access locate this resources in a decentralized way and then we are able to uh um for example to to

to query them and then be able to uh display them in decentralized ways so one one interesting thing is like for example we have other ens domains uh to the rinkeby so this system four which is rankingb but yeah it's the message standard in call yeah and then so all the uh ens program uh we just upload it to the uh to the rinkeby testnet and so you can now just just directly access using the uh ens uh plus the uh with the chain id i'll take it with right now it's using the gateway method but definitely in the future we feel like once the standard is being mature

then we can build kind of like a extension in brave firefox uh that we are able to directly access the reserve resources and display on top of the browser without using any example dns or centralized servers so this is something that i think the applications for this standard yeah any questions i'm not sure i probably go too too fast or maybe can it make more smooth so yeah i think that was pretty understandable yep yeah thank you

yeah please glad yes so uh basically yeah the couple of questions that we want to further move this uh uh url to come with the final stage uh one question i think i think a lot of uh you you have raised is regarding what is the way is to put the user involved or two filled by the wallet um yeah it's the wallet is that is the part of logistic core that will autofill by the wallet when we for example connect wallet but at the same time this is uh another way that is directly accessing uh the web resources uh wire the uh this link so without using the json uh design

pc so this allows another way basically complementary way to access the blockchain resources uh using just link only so it can be done by both but we also provide an optional for the users to uh so let's go back to the to the standard um so so for example if you treat an email message when we call inside a uh if you're in gas um basically it will check uh pass have a field call uh that's actually there's a phone sorry this is there's a form field with a

message standard so uh um in json obviously basically people uh used to call the json rpc and supply this field to say hey what which water is calling uh the contract or estimated gas something like that and here is because we want to build another way that without using json rpc but human readable we are allowed to access these resources and tell what the contract will tell what's the corresponding return some value and then so here uh we provide another way to uh basically uh to tell what is who is going to call this contract uh and but actually most of

time probably doesn't need to be used because if user just created some somebody was the owner of nft uh what is the balance of somebody somebody else then the basically when the the core uh basically will provide kind of like uh parameters of the user going to be local called i feel like you were better if the portal wasn't wet three like yeah like uh we are still going to call this rap3 in 10 years um so yeah that's that's another thing that i was looking for uh basically public

my opinions um so because like this is more like kind of like h web 3 version of http um so um oppressing me social that was unrelated that was related to micah okay yeah definitely like evm is also an option for us but to uh to put it on the on the link which calls basically calling uh the evm uh results from vbn yeah um um so

so one is schema and then uh there are also a couple questions regarding um what if we want to return a type types like like example um when the smart contract returns a binary how they are able to pass this binary treaty like as a web content by default or just treated couple of type value and there are also couple of different formats that we also uh uh provide and so but yeah this is basically a couple of questions that we are uh uh we want to receive more uh opinions schema what was the best schema

what was the where to put the user info uh and then what's the how we are able to handle the tiger returns and what's the current leading one is it the one in the picture uh leading one yeah i think that's the one that's an eip is the one that's in the picture okay i guess like one thing to consider that i like don't really know how to trade off is that the in the picture there's not enough information i think to actually send the call because you need the exact type parameter of the methods and i don't think that that

this gives that to you is that wrong or is that right oh but for this the first this argument zero here yeah like if i were to do an eighth call here how do i know what balance of translates to when we're talking about the um call data the four bytes prefix yes yeah that's great questions so here like so first first path complement is master id is just should be a string and the rest of the arguments is just rest of parts that's just a list of arguments and so here there's a rule that will be automatically

detect those types even if if it's some uh format for example if it's pure integer then it will be just automatically su into 256 unless there's a specific explicit uh explicit type conversion uh before yeah so there's support for the explicit type definition like in the e yeah yeah so you can put that and then exclaimer mark and then your chords are eth you use the address type for this one yeah okay and yeah i think this is a good question really good question because here i feel like it probably we should convert it to explicit address for all the domain

because dot eth may be treated as a zuck.eth file because a file it can be ends with different suffix may collide with existing name service oh yeah so this is a good question sam mentioned so suppose we have do something with given string address or integer how it looks like so basically uh the pro so when uh i type something web3 and a contract and then i put a method master it's called do something and then suppose this is pure integer

then it will call you in 256 because the master id when when we translate it to the master id the mass id contains the integer itself so that it will become us like uh will be there's no ambiguity of the master iv if we just put it it can successfully detect the type and suppose it's addressed then it will be something that is 20 bytes hex then it will also be detected as edges and so the address will be also in the master id and so that it will be uh it will also create node uh ambiguity yes if it is built in 8 or in 60 then it has to be uh basically converted to something like this

yeah so is there an order that it'll attempt to do things in so like it'll try to parse it as you intake then u16 then you liking and go on and on and on and then or or does it like yeah how is that defined oh you should just fail obviously you could go down but um so right now we have limited uh ports that are limited types that will automatically detect it as yeah as you mentioned because right now autos type in general their parameter space is non-overlap so their order doesn't make too much difference uh because we also want to make this rule to be too complicated so the user can kind of

understand so right now you just automatically detect detect you into another v6 um and for other non-supported type it must be parameterized [Music] because your computer our most string support natively um string couldn't work because url could fill the most string uh yeah i think this character will kind of handle this and so i think in our test um so for example first first string let

me see uh all uh bytes that uh so actually there's another case that we can adjust the basically the the the skate issue for example for the streams of bytes um basically users can also use the hex way to to improve it it is less human readable but it can adjust also this ambiguity and force really string i do think this this should also work uh let me check some example again yeah so so in this case this will be converted to us a string with this pure like the string character of this before including okay yeah

yeah um there should be no ambiguity and especially once we support some more maybe name series then unstoppable domains then we should then make the meaning of the current url to be different uh this is the issue that we also found so i'm not sure what which ambiguity case right now we are discussing is um the string of bytes or [Music] um or perhaps a string that contains

does yep i think this is the basic logic uh regarding the the current uh automatic type yup this is something uh [Music] no uh left synthesis is just a nasal

step we're testing right now we are fully integrated with ens so for example using dns right now we can take example uh current the ens let me go to uh example of dns ems home page that's the ends that we register on top of the main chain um so it points to the the website the evm that is on another chain so so let me connect to this website you could check the so

yeah so for ems right now uh this we have implemented an interesting feature uh so connect the wallet okay uh so um this is the website we register basically right now it has a text record tells what is the uh basically three link and address and this is basically gives a change specific address which is points to our test net um and then this is shot name of the test net and also the contract address so in that way we are able to register the domain on ens by able to point to any address on ebn compatible chains

chain five i'll draw two bytes any number of files right 40 or should uh number of bytes of 20 or 13. oh okay yeah yep uh that's something that we should [Music] just um types bytes yeah yeah uh i think i can make it make a change on the on the roots

regarding the [Music] uh let me see the the base handling and and with the stream yeah i think that's something let me just make it make a copy of this so uh i know matt mentioned that he may have to leave a little early uh if there are any further recommendations for the improvement of this proposal maybe we can mention that and continue discussing in the next call yeah um that's that's pretty much all i

have right now uh definitely i will change make some changes on this auto detection yeah that's something that uh basically we are building a sidechain that is able to uh handle a large amount of shoddy data on top of evm so that we are able to reduce the upload cost of the building our decentralized website using the using the standard based on target standard and that requires a separate naming service no it's still using the ems because like we can use in the uns to point to the any blockchain so you're just using this

too so they can be able to link the uh crosslink the address of different blockchains but then why are you showing the point w3q suffix in your eip as well and prioritizing it over ens even oh yeah actually oh yeah yeah yeah there's something when we start working and then we see we've if ems have rj for ems has an issue that cannot be addressed but later we found a text record can put any of the text so so it does say hey why don't we just fully integrate ems and we also have a proposal to ens uh for for this integration right

but i'm specifically talking about i understand that you're storing a key value pair inside your ens name if you go up three lines from where your cursor is right now to resolving address from name service providers the first bullet point is the ethereum name service and the second one is the w3q name service um and then in the section below it you are numbered list this time number one is fetching the w3q record from ens and number two is um okay fair all right so that essentially is how to load the data from ens could you elaborate on why there is a secret name service

specified uh w3q above however so disconnected from ens this this is from us this is all right but a couple lines above sorry a couple lines above okay right there yep w3 name service with suffix w3q yeah could you elaborate on that but for this one yeah this is the version that we just created on testnet to to double check the cost basically the uh the name service that is it's the same as ens but just running on top of us uh on top of the uh basic right now sidechain but right now we have the target is to fully

integrate with uns with this chain specific address that uns is now able to support so then is there a need for a w3 naming service in this eip no no no we don't need any uh it just can just using the uth name service and that's that's good enough to resolve all things you just provide like suppose like support suppose like for example we have uh unstable domains on property other blockchains main service they will tell us how they are able to recognize with

their suffix and be able to basically resolve their address from these name services yeah i think this is the old version so we can put the latest version here so in the latest version uh so we we are currently using that three text record and then uh saying that this can return a chance specific address so that we are now able to use in the ens to address another chain because our engineering fault like this is not an option so we have to rely on different lane service on different blockchains so that it can be located on different

blockchains smart conscious but now using the ip36770 now they're just using ens and then put the chain specific shot names and then now they're able to reference these addresses so this is basically the change of when we um say hey now we need extraneous service from different change resources now with this we're just using an ens and can do other things um yes yeah yeah sure i think this is a really good

point um so i can create another key for uh for resolving because you're already claiming the or at least um you're creating an eip at the moment to essentially reserve the entire not just the the web 3 um schema itself which you know is very broad web 3 is very broad it's not just evm calls right um and you're reserving an entire schema for that so putting hypothetically renaming the schema um

to to the test is something um furthermore the w3 name service i suppose with any name service you should just to to quote um resolve using the name service of your choice right so if that is an unstoppable domain then the browser or extension or whatever is resolving should just figure out how to do it themselves if it ends with w3q then they should just figure out how to do it themselves that should not be something specifically described in the specification right like that can be abstracted away um as previously stated but i feel like probably we can put ens uh in in here because like i think this in a small de facto

uh but you're you're using an ethereum proposal an ethereum improvement proposal in an attempt to modify and standardize a key value pair for an ens address correct uh for an ens at text records yes you're trying to claim the web three key for the text records of ens using an ethereum improvement proposal okay so probably that would be better in in the kind of like uh in that proposal so that can be that can be abstracted like that can be removed from your eip that is something that you need to discuss with ens themselves right um

and you can run a separate proposal for that there's a whole other process for that but that's not something i think that we decide on here does that make sense yeah sure because those are enos decisions yeah um yeah sure i think uh i can yeah definitely can propose specific uh on different basically uh name servers to see how that they can integrate it sure right and as much as i understand you'd like to have the web 3 key right um yeah i think you might the text record right um you might want to contemplate uh potentially settling for w3q

as the text record or something along those lines right uh or whatever the schema ends up being because we wouldn't want uh an acc i mean you're already following the original uri url spec so closely that in the hypothetical event somebody does not set this currently named web3 uh key value pair right on their ens record that it could be a url that looks like web3 but do you know how with most browsers if i type in google.com it automatically goes to https colon slash google.com right we wouldn't want somebody only

copying everything after the schema pasting it in there and instead of it automatically going to web3 colon slash automatically going to https and somebody has already claimed the contract name or somebody has already overtaken it in another way right because what will end up happening then is you can make 4804 urls right that are 4804 compatible your eip um but that if misentered ever so slightly goes straight to an https site which is a high risk of you know it's essentially introducing another vector for attackers to um

come in if that makes sense right because it'd be a lot easier to spoof certain urls so if there's a short name so for example if there's just something dot adhd then definitely it may translate to https but if we the user provider for schema uh no matter is vms web 3 or evm then i think that the browser yeah we will automatically say oh sorry either i cannot handle this uh oh oh this is something actually the the we have uh basically you want actual browsers to resolve um right yeah right now the browser uh so the firefox now is already supported this one you just resolve it and

translate it to the database uh just copy and paste it there so you got approval from firefox yeah we already have three extension because it has less restriction one so using an extension okay yeah so firefox is not officially affiliated with or approving of you using the web3 schema got it no not yet yeah it's just an extension yeah okay firefox let me show you so this is firefox so three by three

uh ems home page dot uh eth so you translate to the gateway and just and then it just go as the same as the uh what the crown yeah right so you're essentially building an entire eip around web3q sprinkling in a firefox extension sprinkling in an enos name and some other things right i mean around this standard erc404 the extension is not part of the

specification yes it's just a uh a way to allow the firefox uh basically users to directly type this and then convert right yeah but this specification was if i'm not mistaken [Music] a way to call evm functions right and not a way to sneak in quotation marks uh web3q into the eip no no it's just uh basically just work with evm it's just how to translate a url url to

our ebay message and so with this we can do a lot of applications uh take some on-chain web generation or even website or all kinds of things and then you also have it coupled with enos so that we are now able to reference this resource actually this trick a lot of people are saying hey how we are able to build on system of essentials websites yeah how to pass webster in the yeah

should we move to separate sure yeah uh let me stop my sharing yeah thank you thank you ki and look for this discussion it is important that we learn about the proposal and their statuses i would be happy to organize a peep in each session for this particular proposal to maybe explain it in a detailed way uh so it can be followed by other implementers and yeah i will be happy to connect with you uh offline to get this thing arranged

whenever you're ready for that all right uh coming back to uh like uh the main discussion here thank you to all the participants who have joined uh i see one new face here i mean one new name on the screen ricardo who is an author of eip at the moment this proposal is currently in stagnant status the proposal is url format for transaction receipts uh maybe ricardo if you would like to take some time and talk about the proposal briefly and let us know how do you feel about it and if you are interested in pursuing that proposal so yeah thank you so this proposal i've written some years

ago and i tried to extend an ex existing eip about the transaction requests and we were using the transaction requests standard in status to when you when you are in a chat you can ask someone to send you a transaction so uh this is one user who sends the request and then you need a way to answer back in a standard that the software can understand automatically so then me and my colleague my work colleague eric we

written the cip just to specify the transaction receipt and if there was some contract call to to translate because the you know the four bytes and you you want to be able to know exactly everything about the transaction both but for status we are basically using just a transaction receipt because for one user to another there is no contract calls or usually is just a uh normal transfer but of course if this is a your c20 token and then you have a transfer you have the match of that there are two it's a

little bit more complex something i don't like about the eip everything is is that it's it's not very elegant i mean it's a little bit ugly like the full name ethereum dash transaction and i feel like it could be better but it works it's simple and straightforward it's just that supports only ens the default ens because this is what we currently use in status and everything uses and we won't have no plans in supporting other thing than ens

that's it how do you feel about moving it from stagnant to final do you think anything as as the original author do you think you'd make any changes or leave it the way it is um i think it's it's working fine uh maybe we we could look better about the contract calls and something about the multi-chains because there is a parameter there that you can specify what is the chain id and

maybe we can make something better than that but for now i think it like i don't know audi of the use case because a lot of things are changing in the ethereum world with all these l choose and and it's supposedly at the time that when i've written it i've written it to be compatible with everything i knew that that is on the interior ecosystem but maybe something now changes um just to maybe add here um if i understand correctly you uh may not be very much interested into moving into different status and would like to bring some changes um

they if that's the case there is a status available on ethereum standard that is called like withdrawn um you can probably withdraw it or if you think that you can make some improvement to the present proposal and would like to continue doing it so you can let it live in statement for some more time and whenever you make those changes you can bring it back to draft or to review so we can start discussing it well since we are having this call now that i see that there is some interest in the community about this eip i can move it to final and

if you need it uh right now it's a draft because just i as far as i know it's just statement that is using it but if our people are going to use it we should move it to final we should just agree if everything is correct and if you feel something to improve i'm open to suggestions so so far status fully supports it um yeah from what i know uh i personally really like your eip um i see opportunity for it in a few applications not just in peer-to-peer messaging or in this case uh the way stage does messaging

but being able to do transfers between people or being able to get a receipt of a certain thing or some kind of feedback from a stagnant machine or some way to on paper um or through an email still provide a link to a transaction without specifically like needing to be affiliated with a certain scanning site or certain whatever um so i do like the appro proposal i have also written the ethiorl parser from bruno bar 79 uh the pr for it that introduces parsing of eip 2400 urls

so there is currently a javascript package available that allows you to take in one of these urls and then turn it into an object that simply says this is the prefix it's tx the address is this the variables are this etc etc etc um so there is already uh tooling written for it so when it comes to that even though it was created in 2019 or end of 2019 i um also think it is worth moving to final uh so something that you mention it uh for other use cases actually in status we have a problem that uh we can we don't know the

transaction history from from an address because when you send a transaction to some human address there is no notification you just know because you download the blockchain or you go to each or scan but we were thinking about using these transaction receipts and sending them in the waku network that is a like a whisper network and then you don't have to have an external service of course only wallets that implements this new mechanic would would send this transaction receipt to this decentralized whisper network

and then we we could like remove this a centralized server because right now status when when it's oh what's the wallet uh it needs to go twitter scan to download the transaction list and if we had something like this we could have like instantaneous you receive a transaction you you know immediately even when the transaction is painting so that's a way to improve the the ecosystem as a whole because right now painting transactions don't appear in states because of this so it's first needs to be included in a block yeah there is a lot of use cases we can find on top of i

already thinking about that but yeah and we needed other wallets to implement this using this transaction receipt to send you to your cool network and then we don't need that after scheme sounds good just again a piece of information here this new proposal is currently in draft status and it cannot be moved to sign final as yet this has to go through different statuses and the best one if you are willing to move ahead would be to move it into the review status by doing so you would be attracting uh eip editors and community review i'm assuming okay let me quickly

check yes i find a magician link here for discussion so we may have to start discussing again about this proposal and then probably reach two different wallets to get it implemented even if implementation is work in progress we can continue moving it towards final but the statuses has to be from draft to review to last call and then final from from review to last call there is no fixed duration whenever you are ready you can move the proposal from review to last call but once the proposal moves into the last call it has to stay there for 14 days and that 14 days is for aggressively getting feedback on the

proposal and then we can probably move it to the final starter okay i will work on that i will call it call the reviewers yeah yeah the moment you create a pull request and it is merged so uh i'm i'm sure that it will get attention from eip editors and obviously from the community when any whenever any proposal comes into active discussion people come forward and share their feedback and moreover the cata has also organized a video series on eip special in which you will get an opportunity to explain all about the proposal and maybe take some questions from community and yeah we will try to help you out to

share more about this proposal to get it implemented in one thank you i'm very happy well thank you so the idea of this call is to get uh moving the proposals which are already into stagnant status and uh help out getting consensus on like if there are more than one proposal of the same category serving the same use case as of now from the list it doesn't look like that there is any other eip which is in competition to that um please someone correct me if there is any and i'm missing on that if not then

um it's a good idea to move the proposal in competition to 2400 that's what yeah uh no there are none i think yeah i i i think it is the one only and thank you luke for adding all the use for current schemes that is helping us understand what we are looking for and probably giving us at least like you know uh which all usage standards we need to push forward so thanks for that how do people think about getting back on a call in next two week and see where we are on the progress i know in the last meeting we discussed about reaching out to different wallets we uh we were not able

to connect that but uh samantha earlier mentioned that he will try to reach out to them and even from our end we'll try to do so are we good on like the same time yep sure sounds good very well so yeah we still have couple of more minutes anyone have any final thoughts to share um i was wondering if any of you are coming to eath prague or east new york up in the next week or two weeks i can favorite me i'm not i'm so very sorry about that but we have some people in east prague

um yeah um if we would like to connect to people uh maybe you can mention it on the ethereum cathode does discord whoever are going there may be able to get into that okay thank you cool cool so well thank you everyone for joining us today we hope to continue discussion um uh you can also yeah you can also leave your comment thoughts feedback in the eip editors channel